Requirements for Linux production devices
Device Management Client runs on any Linux system.
| 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.