Threat and trust models

From Randomness for cryptography
Jump to navigation Jump to search

Random number generation (RNG) for cryptography provokes the continuing arguments. The underlying disagreement may be more about trust and threat modes than RNG technology.

The discussion can be broken into roughly two camps:

Camp A’s primary outlook is corporate security, including e-commerce, and protection of corporate data.

Primary threats are cyber criminals, insider theft, tort liability, regulatory non-compliance (HIPPA, SEC, SOX, EU Data Protection Directive, etc.)

Camp B’s primary outlook is personal privacy, including protecting on-line chat, E-mail, disk encryption, alternative currency (eg bitcoin)

Primary threat is state actors, such as NSA and the Chinese equivalent, with defeating mass surveillance a primary concern

Both camps agree that good RNG is vital for crypto, but disagree on the meaning of good because they see different threats

Camp A viewpoint

  • Camp A seeks high quality, copious sources of entropy for crypto.
  • They seek reputable suppliers and are willing to trust them.
    • Have to trust someone (OS, CPU, HSM, hypervisor, crypto libraries, etc.)
  • Starting point is an analog device specifically designed to produce large quantities of uniformly random bits, e.g. comparing noise from two Zener diodes, ring oscillators, radioactive decay. (AIS31)
  • They employ elaborate statistical tests to ascertain how close a TRNG is to an ideal random bit source random design and to measure the rate at which entropy is produced. TRNGs that pass the tests and other criteria receive official certification (e.g. FIPS-140).
  • A subset of these statistical tests are used during operations to detect TRNG failure.
  • Whitening solve issues of analog bias, correlation and non-uniformity.
  • Statistical tests after whitening are permitted.
  • One high quality RN source is all that is needed.
  • TRNG CPU instruction is ideal, especially for diskless node initialization, virtualization. Eliminate vulnerabilities with I/O drivers.
  • For the most stringent security, prefer certified commercial Hardware Security Modules (HSMs), offering shielding from side channel attacks, tamper detection, zeroization.
  • Certification and compliance reassures corporate management and minimizes legal liability.
  • Applicable regulations may be prescriptive.
  • Adding an hoc alternate entropy input has risks.
  • As hoc entropy sources can change over time (e.g. HD->SSD), no guarantee they will continue to work over decades.
  • NIST SP800-90 model

Camp B viewpoint

  • RNG single point of failure
    • Ideal target for exploitation: silent, hard to detect, no back channel needed, no other back door, facilitates silent, remote attacks, needn't weaken security against others, suitable for mass surveillance 
  • Large intelligence organizations almost certainly actively exploiting cooked RNG, e.g. NSA (Snowden), China, Russia, cyber criminals 
  • Internet Secrets 1999
  • Purpose built crypto devices suspect. Manufacturers can be influenced (per NSA budget)
  • Certification process suspect
    • Stories of being forced to make sub-optimal decisions. Apple /dev/random frozen at 160 bits and 1999 design due to cost of recertification
  • Ad hoc entropy sources less likely to be back-doored. Why not combine more than one?
  • There exist safe ways to combine multiple random bit streams
  • Randomly seeded stream cipher adequate
  • Not much entropy needed for strong seed, 256 bits more than enough
  • Only need lower bounds
  • Linux vs FreeBSD&MacOS

Room for compromise?

Both sides have strong arguments

Other issues separate. Eg control of operating system, hyper visor, Ken Thompson compiler subversion, etc. Fix one leg of the table (here RNG) at a time