Ensuring device identity and security: a crucial aspect of modern connectivity

“Device identity means establishing the authenticity of devices attempting to connect to services, services connecting to devices, and the data exchanged between them.”

When discussing secure firmware updates, an essential topic that often goes hand-in-hand is device identity. Device identity refers to the strategies, policies, and technical implementations that safeguard the communication of connected devices with the outside world. It’s worth noting that this concept isn’t limited to only “cloud-connected” devices. As emphasized in the draft of the European Cyber Resilience Act (CRA) (Annex 1, Section 3.h), security principles should extend to all communication channels, including devices capable of communication through hardware ports like USB and other industrial standards.

The need for device identity arises from the imperative to establish the authenticity of:

• Devices attempting to connect to services
• Services attempting to connect to devices
• The data exchanged between services and connected devices

The fundamental principles behind device identity revolve around well-known mechanisms of symmetric and asymmetric cryptography that employ encryption keys. Device identity hinges on how these keys and certificates are generated, stored, and managed, both by the devices themselves and the external services they connect to.

Depending on the specific use cases and security requirements, device identity can be implemented in a variety of ways. Some scenarios call for a unique security level for each individual device, entailing a distinct encryption setup for each. In other cases, it may suffice to have security applied at the group level that covers multiple devices.

Regardless of the scenario, the initial step is the same: equipping the device with the necessary tools for secure communication. This is typically accomplished before the device leaves the factory and can be referred to by a variety of terms such as “factory injection,” “factory initialization,” or “labeling.” It is critical that this process occurs within a secure and controlled environment in the factory.

This procedure also defines a device’s identity in its strictest sense, since a unique device ID is stored in the server and paired with a device certificate.

But what exactly are these “tools”? When we refer to tools, we are talking about the certificates and secret keys required to generate the data encryption key (DEK). The DEK is a symmetric key used to encrypt the exchanged data.

To summarize:

• To ensure security, data exchange between the device and the outside world is encrypted with a data encryption key.
• To guarantee the DEK’s authenticity, it is generated using certificates and private keys that are securely put in place before the device leaves the factory.
• The aforementioned certificates are also employed to verify the origin of the data.

In a manner similar to security principles in other domains, various approaches exist for managing the Data Encryption Key. It can be a permanent key, generated and stored on both sides, with the option for updates when needed, or it can be ephemeral, generated only when data transfer is necessary and then deleted. For instance, the use of Elliptic Curve Diffie-Hellman encryption enables securing communication between two actors over an insecure channel.

The process of generating and storing a permanent DEK is commonly referred to as a “pairing procedure” and may occur later when the device is installed at the client’s premises.

The choice between using ephemeral or permanent DEKs depends on the specific use case. For example, if a device is expected to receive data or firmware updates from a passive storage medium like a USB memory stick, ephemeral keys are not a suitable option, since they require real-time interaction from both sides. Pairing procedures also enable the categorization of multiple devices by client, by machine, and so on.

In cases where a high level of security is required, with each device necessitating its unique security encryption, all essential private keys and certificates can be generated within the device during the injection phase. Alternatively, these can be prepared in advance (still within the secure factory environment) and then stored in the device during the injection phase. This flexibility accommodates scenarios where a single DEK is desired for a set of multiple devices, such as those owned by a specific client.

Furthermore, these practices extend to handling licenses, particularly in device-as-a-service business models. If you require assistance with a device identity and security case, don’t hesitate to reach out and book a meeting with us.

Device Identity FAQs