Requirements for Client Linux production devices
Device Management Client runs on any Linux system.
Hardware and software requirements for Pelion Device Management Client production devices
| Capability | Device Management Client | Comments |
|---|---|---|
| CPU | Any CPU. *1 |
Any single-core capable of running Linux is enough. |
| RAM | 1 MB | Device Management Client itself is extremely light, but your Linux distribution and other parts of your stack can impact this significantly. Typical Linux boards have 256 MB to 1 GB of RAM which is typically more than enough for the Device Management Client. Verify your assumptions according to your Linux distribution and application stack combination. |
| Flash/Storage | Minimum 4 MB | Typical Linux distributions require at least 30 MB for the root FS. However, if you add heavy stacks, the size can easily grow up to 1 GB. The storage must be partitioned in a particular way for firmware update to work. Verify your assumptions according to your Linux distribution and application stack combination. |
| Networking | IP-based networking. | Ethernet, Wi-Fi or similar. For non-IP based connectivity, see Edge and its protocol translator capability. |
| Root-of-Trust (RoT) | Recommended. Secure memory for hardware root of trust. On-die flash as minimum. See note *2. |
|
| True Random Number Generator (TRNG) | Recommended. | See note *3. |
| Clock | Optional. | Either a - 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 | Recommended. | The secure boot module checks the integrity and authenticity of the firmware at boot time to protect the device from re-flash attacks. |
Notes:
*1 Device Management Client does not require any specific CPU. All 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 to use a local RoT, stored on die, which protects information stored on an external flash. The local RoT is stored on die in one-time-programming bits or an internal flash, with access control and optional write protection. This protects the device from physical access attacks (such as re-flash 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 (RNG) needs to be seeded with cryptographically strong entropy. The recommended practice to provide such a seed is to use TRNG hardware capability. Alternatively, if your platform has no TRNG, we offer software-based deterministic random bit generation (DRBG) and rely on entropy or key injection during device production.
Software stack
You need to choose an OS for your IoT Device. Device Management Client is pre-integrated with Mbed OS, which provides the capabilities described below. However, you can choose a different RTOS and port Device Management Client by implementing a Platform Abstraction Layer (PAL) for it. See the porting guide for more information. We provide a porting layer to Linux.
If you plan to use Device Management Client with an OS other than Mbed OS, you need to choose a platform and components that provide the following capabilities.
| Capability | Description | Comments |
|---|---|---|
| OS | * Mbed OS v5: See the compatibility matrix. * Linux: Ubuntu 16.04 LTS, Yocto v2.3.x |
For porting to other OS/RTOS, see the porting guide. |
| Storage | Flash and filesystem drivers. | |
| Networking | * Networking Drivers. * TCP/IP. * DNS resolver. * Optional (recommended): DHCP. |
* IP over the HW supported bearer. * DNS and DHCP simplifies the device configuration during deployment. |
| Crypto/TLS | Mbed TLS or equivalent Crypto and TLS/DTLS libraries. | You should configure Mbed TLS to use only the latest TLS cipher suites, because older ones become vulnerable. |
| TRNG Driver | Platform’s TRNG driver. Crypto module programmed to use the TRNG. |
|
| System Tick | System’s tick availability at a rate of at least one tick per millisecond (higher than one Khz tick). | The tick is the OS (platform) kernel system tick counter. |
| Software-reboot | Ability to software-reboot the device. | Required for tests and for Device Management Update. |
| Bootloader | Bootloader with firmware update capability. | Required for Device Management Update. Optional, if you do not use Device Management Update. We provide a bootloader you can use with Mbed OS and reuse in other platforms. |