Requirements for embedded Client production devices
Hardware and software requirements for Pelion Device Management Client/Lite production devices.
Tip: If you are still in development, you can see Pelion Device Management-compatible devices on our Boards page.
Client hardware requirements for embedded systems
Reference numbers are from Mbed OS, but they are typically around the same ballpark for all embedded systems.
| Capability | Device Management Client | Client Lite | Comments |
|---|---|---|---|
| CPU | Performance as in Cortex-M3 or better. *1 |
Performance as in Cortex-M3 or better. *1. |
No specific CPU architecture requirements. CPU performance impacts (D)TLS handshake duration. |
| RAM - with eXecute in Place | 56 KiB minimum config 107 KiB maximum config |
47 KiB minimum config | Consumption depends a lot on network stack and configurations. Verify your assumptions with your application and board combination. |
| Flash | 112 KiB (minimal) | 60 KiB | Excluding firmware download area. See Embedded system RAM and flash consumption for more details. Verify your assumptions with your application and board combination. |
| Networking | IP based networking. | IP based networking. | Ethernet, Wi-Fi or similar. For non-IP based connectivity, see Device Management Edge and its protocol translator capability. |
| Root-of-Trust (RoT) | Recommended. | Recommended. | Secure memory for hardware root of trust. On-die flash as minimum. See note *2. |
| True Random Number Generator (TRNG) | Recommended. | Recommended. | See note *3. |
| Clock | Optional. | Not needed. | Either an - Real Time Clock or - some low-frequency crystal (for sleepy devices) or - SW clock (non-sleeping devices) that provides the device proper time. This is needed to handle any certificate validity time attacks. |
| Secure boot module | Optional. | Optional. | The secure boot module checks the integrity and authenticity of the firmware at boot time to protect the device from reflash attacks. |
Notes:
*1 Device Management Client (or Lite) does not require any specific Arm CPU, all of the code is C/C++ and as long as we have a working C and C++ toolchain, any CPU will do. Currently, porting has been done to multiple Arm, Intel x86, Intel x64 and MIPS architectures.
*2 Device identity and keys stored on the device need to be protected for their integrity and confidentiality. Some of these must be immutable.
The recommended practice is using a local root of trust, stored on die, which protects information stored on an external flash. The local root of trust is stored on die in a one-time-programming bits or internal flash, with access control and optional write protection. This protects the device from physical access attacks (such as reflash attacks) and software vulnerability exploitations, which extract the keys and remotely take over the device.
*3 For secure communication and secure device identity, a Random Number Generator needs to be seeded with cryptographically strong entropy. The recommended practice to provide such a seed is by TRNG hardware capability. Alternatively, if your platform has no TRNG, we offer software-based DRBG and rely on entropy or key injection during device production. The NUCLEO-F411RE board is an example of this.