Most advice for proper IoT cybersecurity will mention the need for secure data in transit, aka SSL/TLS or IPsec. Let’s assume great protocol stacks, great crypto algorithm selection, and strong key sizes. Despite our best efforts, secure protocols all share a common Achilles heel. To achieve secure data-in-transit requires entropy. We are shining a light on this important problem with some simple-to-follow tips to ensure your entropy stays random and hackers can’t seize control of your devices.
Privacy Requires Entropy
We use encryption on the Internet to purchase items, access a corporate headquarters, or change the temperature on a thermostat. Prior to accessing these things, our communication connection must perform a secret handshake, a secure protocol handshake.
The handshake requires verifying the endpoint’s identity and establishing a shared secret. A binary tumbler churns the shared secret into session keys. Session keys are used for encryption and protecting our communications. The Achilles heel of all secure handshakes is entropy, or rather the lack of entropy. If the shared secret is predictable, the session keys are predictable; therefore, our communications are no longer private.
Device Entropy Sources
For devices, collecting entropy is challenging. There are few noise sources available in a connected device. Two classes of noise sources: physical noise sources use dedicated hardware (such as Zener diode, microphones, temperature); while non-physical noise sources use system data (such as the output of internal counters or time) or user activity (e.g., mouse movements) to generate entropy.
Ideally, there is a mechanism for health testing hardware components to ensure the noise sources are operating correctly. The entropy sources can be conditioned to reduce bias. Noise sources are generally very slow at producing entropy, and some dedicated noise sources have been discovered to degrade over time. Therefore, we tend to use hardware-based entropy for seeding a software-based cryptographically secure pseudorandom number generator (CSPRNG).
Clones Don’t Know They Are Clones
CSPRNG can be risky. For example, some connected devices are System-V based — i.e., no threads, processes-only. A forked process using a previously seeded CSPRNG will require reseeding; the two processes will share the same CSPRNG state and generate identical random numbers. When slicing and dicing encryption protocol code to fit in your device (i.e., porting code), be sure to reseed or condition forked processes CSPRNG state. Similarly, a cloned VM’s seeded CSPRNG will produce predictable numbers with its origin in a hypervisor environment. The growth of device hypervisors will open the door to this risk of predictable random number generators.
Random Tips
Tip 1: Exclusive-Or (XOR) entropy noise sources together without the risk of watering down the entropy strength.
Tip 2: The seed must be zero-ized once consumed by the CSPRNG initialization.
Tip 3: The memory space for the seed and CSPRNG should not be developed in high-level languages (i.e., Java, C#). A garbage collector will clone memory in flight; these private bits will be duplicated in memory 13x. (True story)
Tip 4: Seed length. NIST recommends a seed length of 384 bits for AES_CTR_DBRG. There is no harm by increasing the seed length.
Tip 5: Reseed and/or condition CSPRNGs appropriately.
Final safety net tip: Conditioning CSPRNG output at the protocol level (e.g., SSL library) is a good practice too.
