Mistake on this page? Email us

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.


*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.