Requirements for Edge production devices
Hardware and software requirements for Edge production devices.
Tip: We recommend using a board with a Yocto build system. Our reference example board is Raspberry Pi 3B/3B+. This board is globally available, making development simpler. However, this board lacks a true secure boot feature and therefore is not recommended for production in environments where this type of security feature is required.
Hardware
| Capability | Requirement | Comments |
|---|---|---|
| CPU | 1 x Cortex-A7, 1 GHz or better. | Depends a lot also on the other services and algorithms run on the Edge. |
| RAM | 1 Gigabytes or more. | These requirements imply the typical whole hardware requirement. However, if you have other resource demanding services or algorithms, you might need more. Please verify your assumptions with your Linux distribution and application stack combination. |
| Storage | Minimum 4 gigabytes, 8 or more gigabytes recommended. |
These requirements imply the typical whole hardware requirement. However, if you have other resource demanding services, you might need more. The storage must be partitioned in a particular fashion for firmware update to work. Please verify your assumptions with your Linux distribution and application stack combination. |
| Networking | IP based networking, ethernet recommended. | Ethernet, Wi-Fi or similar high-bandwidth connection. Please note that Edge is aggregating the traffic from multiple devices, so it will need much more bandwidth than a simple client. |
| Root-of-Trust (RoT) | Recommended. | Secure memory for hardware root of trust. On-die flash as minimum. See note *1. |
| True Random Number Generator (TRNG) | Recommended. | See note *2. |
| Clock | Needed. | Either an - Real Time Clock (RTC) 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 reflash attacks. |
Notes:
*1 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.
*2For 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, you can implement software-based DRBG and rely on entropy or key injection during device production.