Pelion Device Management Client Lite security considerations

Warning: If you're visiting this page from Device Management Portal, note that Device Management Client Lite versions 1.0 and later use X.509 certificates. This version of the Pelion documentation (4.2) applies only to pre-alpha versions of Client Lite.

Arm offers a security solution for two product categories:

• Products that are attractive targets to attackers because they handle critical data and functions, such as devices that control locks or heating systems.
• Products less attractive to attackers because they handle only non-critical data and functions, such as a thermometer that sends temperature information for monitoring purposes, but does not control the heating system.

Critical devices require the security benefits offered by the X.509 certificate-based solution. This is a heavy solution, however, and for non-critical devices, the performance cost can outweigh the benefits. For these devices, you might want to use the Pre-shared Key (PSK) solution that Device Management Client Lite offers.

When selecting your solution, you need to weigh the following issues.

Passing of the secret

PSK requires that the client and server (Device Management) share a secret, meaning the secret must be transported to both of them during the manufacturing process. Therefore, the device must trust the factory itself, and any chance of leaking the device-specific PSK must be eliminated.

After manufacturing, the device must also be secured, so that an attacker cannot easily gain the device-specific PSK from the device itself. The PSK should be stored in a secure area that cannot be read remotely, or even if the hacker has physical access to the device. Internal flash and Trust.Zone storage are safe enough, but external storage is not safe.

No forward secrecy

The PSK key flow:

1. The original device-specific bootstrap PSK ID-PSK pair is injected to the device during production and used by Device Management Client Lite

   Note: During development, you may include it as a hard coded value in the C file.

2. The device boots up for the first time, uses the device-specific bootstrap PSK ID-PSK pair and opens a secure (D)TLS connection to Device Management.

3. The device requests the LwM2M PSK from the bootstrap service.

4. If the connection succeeds, the bootstrap service gives the device an LwM2M PSK.

5. The device stores the LwM2M PSK secret and connects to Device Management using it.

PSK security considerations

If someone obtains the original bootstrapping PSK, they can then eavesdrop on the TLS transport and access all future LwM2M PSKs. The only recovery option is to reprogram the device with a new bootstrapping PSK, which is not typically viable for cheaper devices.

If someone manages to crack the LwM2M PSK, they can eavesdrop on traffic for that LwM2M TLS transport as long as the key is valid. There is no Diffie-Hellman key-switching available with PSK. The only way to get a new secret key requires re-bootstrapping the device, which is safe only if the original bootstrapping PSK is still secure.

PSKs have to be device-specific

Devices must never share the same PSK. This limits the damage to one device, in case a PSK is broken or leaked.

(D)TLS encryption

PSK uses 128-bit (D)TLS connection encryption. PSK uses the PSK_WITH_AES_128_CCM_8 cipher.

Device Management Client Lite does not support First-to-Claim

Because the PSK is shared beforehand, Device Management Client Lite does not support the First-to-Claim feature.