Requirements for embedded 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.
Reference numbers are from Mbed OS, but they are typically the same 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 | 56KiB minimum config 107KiB maximum config |
7KiB static 26KiB dynamic |
Consumption depends a lot on network stack and configurations. Dynamic number includes client, OS, TLS and networking stack. Verify your assumptions with your application and board combination. |
| Flash | 112KiB (minimal) | 63KiB | 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. | Optional. | Choose one: - A Real Time Clock. - Some low-frequency crystal (for sleepy devices). - Software 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++. As long as there is a working C and C++ toolchain, any CPU will do. 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.