Zephyr Prng

  • Randomness is hard (esp embedded)
  • Randomness is important
  • What do we have now
    • Entropy Good, but few devices are supported. Also, most aren’t suitable for use in making keys
    • “random” Useful for things like network backoff, etc. Not useful at all for cryptographic purposes
  • I propose a cprng API (Cryptographic Pseudo Random Number API).
  • Implementations
    • FIPS 140-2 (NIST SP 800-90A)
      • mbed TLS: CTR-DRBG, HMAC-DRBG.
      • Tinycrypt: ctr-prng, hmac-prng.
      • mbed TLS manages reseeds and such, tinycrypt does not.
    • NIST SP 800-90A/B
      • Testing requirements on entropy source. Very hardware specific.
      • Works well with HW specific entropy sources.
      • Documentation will probably have to come from manufacturer.
      • Health testing: startup checking of entropy source, and two simple tests on the entropy as it comes in to detect it stopping to produce entropy.
    • Fortuna
      • Similar to ctr-drbg, but better equipped to handle attacks on entropy source. Also tries to recover from the state leaking, although djb argues that this is kind of pointless, as someone who can read the prng state can also read the private keys.
      • More set up for “external” entropy collection. Gather on interrupt timing, disk latency, network packet timing, etc.
      • Not as useful on an embedded device. Maybe sensor “jitter” would be useful.
      • Also oriented more toward a system where entropy is constantly added (at about 10/second). Less useful for something that is off.
      • Not as useful when there is a good HW entropy source.
      • Probably depends on particular application, maybe should make this available.
      • Not approved for FIPS 140-2. The approved algorithms “unnecessary” extra work in the key erasure. If someone doesn’t need FIPS 140-2, Fortuna’s generator would be more efficient. (Key erasure is needed so that state recovery cannot be used to recover previously generated output.
    • Does the CPRNG state need to be held on the trusted side, and this becomes a secure call type interface.
  • Proposal:
    • Create a CPRNG API for Zephyr. Simple base-level API: init, reseed, generate.
    • Additional optional API to handle NIST health test requirements.
    • sys_rand32_get() stays as a lfsr, or may gets fixed to xor-shift+ or ‘*’. No point in the complexity of Mersenne Twister or WELL.
    • Multiple implementations, mbed TLS and tinycrypt, possibly a local Fortuna implementation.
    • Choice of ctr or hash. Ctr is faster, but if system is otherwise not using a cipher will require more code. This seems unlikely as any application needing cryptographic random numbers. Maybe CTR is sufficient.