[Cryptography] OpenSSL and random

John Denker jsd at av8n.com
Mon Nov 28 18:10:15 EST 2016


On 11/28/2016 10:13 AM, Salz, Rich asked off list:

> And what should openssl do for everyone in the meantime?

OK, that got my attention.  That seems to be an offer to
accept more than a fair share of the responsibility.  That's
nice, especially compared to the opposite:
    https://www.av8n.com/physics/not-my-job.htm

If somebody is eager to do the Right Thing™ we should all
encourage and support the effort, within reason, while
keeping an eye on what's possible and what's simply not
possible.

One tiny step in the right direction would be to upgrade the
openssl documentation, to include a warning.  Here's a first
draft, to start the discussion:
	Some platforms are insecure and cannot be made secure.
	There is nothing the user can do about this except
	to switch to a different platform, and there is very
	little openssl can do to detect the problems, let
	alone fix them.

That leads to the question of what, if anything, openssl could
actually do that would help.

For starters, as some guy named Hippocrates pointed out, we should
try to not make things worse.  That's tricky, because some folks
might come to trust openssl and then be led down the garden path,
no matter how many warnings there are in the documentation,
especially if the warnings are non-specific and non-constructive,
and especially given that nobody ever reads the documentation.

Taking the next step down that road, we ought to ask whether it
is possible for library packages (or anybody else) to *detect*
the most prevalent security problems.

  Clearly the problem is not solvable in the general case.  If
  some genius has written the root password on the underside of
  the machine, no library package is going to detect that.

  Also if Alice has booted from a "Live CD" such that essentially
  everything is a replay of the previous boot, it is very hard for
  the system itself to detect that.  Eve knows, but Alice doesn't.

  Hypothetically we could detect that the system is booted from
  a Live CD and warn the user, but that would lead to a bunch of
  false positives, because not all Live CDs are insecure, and
  falsely crying wolf is terrible from a security point of view.

  All this is related to the fact that if we just analyze the
  outputs, a poorly seeded RNG looks an awful lot like a properly
  seeded RNG.  Eve knows the difference, but Alice quite plausibly
  might not.

To summarize this subsection:  This might be one of those odd situations
where it is easier to fix the problem than to detect it.  Also it's a
bit like a cancer vaccine:  By the time you have detected the problem
it might be too late, so it's really better to prevent it.

Here's a more-or-less constructive checklist.

1a) Do the ioctls to find out whether /dev/random thinks it has plenty
of so-called «entropy».  Entropy isn't exactly the right concept,
and the kernel doesn't account for it properly, but even so, if
there is "plenty" of it, you have reduced the attack surface by
many orders of magnitude.

1b) Grab some bytes from /dev/random and stuff them into /dev/urandom.
This step is unnecessary in "most" cases, since "most" versions of
/dev/urandom tend to re-seed themselves more than enough.  In any
case, once you're sure urandom has been seeded, use it for whatever
you need to do.

2a) If the CPU supports RDRAND and/or RDSEED and/or a HWRNG device,
it is exceedingly likely that /dev/random is already using that,
so this reduces to case (1), but if not, you can grab some random
bytes and stuff them into /dev/urandom, then proceed as above.

Beware that /dev/hwrng can easily block, especially on a VM guest.
So if you just check that the device exists, you can't assume that
/dev/random has benefited from it.

Beware that an unwise reseeding strategy is for all practical
purposes a denial-of-service attack on the upstream source(s)
of randomness.

3a) If neither (1) nor (2) is successful, and/or if you don't trust
whatever sources are being used, see if there is an audio system.

Maybe the simplest thing is to just bundle something like Turbid
with openssl, and tell people to use it.  I've been slowly working
on a second-generation Turbid, with the goal of making it easier for
Muggles to use.  For one thing, it uses a GUI, rather than relying
on a bunch of arcane cmdline commands.  Also I broke the documentation
into two parts: a set of down-and-dirty instructions for the user
in a hurry, plus a much deeper discussion for the aficionados. 

If you're running on a distro (perhaps a Live CD) that doesn't have
Turbid but does have arecord, you can check for a noise.wav file
in some path.  Make the path part of the openssl configuration.  If
the file exists, and has plausible contents, and has a trusted owner
(either root or the current user) and sensible permissions, and
isn't too old (certainly not before the current boot), then you
can stuff that into /dev/urandom and proceed as above.

If the platform doesn't have an audio system, tell the user to
spend a few dollars on a USB audio dongle.  A user who refuses
to do that is not serious about security.  At least when the
non-serious user gets pwned everybody will know it was his own
fault.  We gave him multiple opportunities to do things right.

3b) If the noise file does not exist, you can try to create it.  This
is gross hackery, but it's better than nothing.  Get the user to open-
circuit the audio input.  On a desktop this is trivial;  on a laptop
it might require a bit of wood or plastic(*) with a diameter of 3
or 3.5 mm to stuff into the mic port.  Then:
   arecord --disable-softvol -d 3 -f S32_LE -r 44100 /var/run/noise.wav

Play it back to make sure it sounds OK.  Then proceed as in (3a).

     (*) Consider using one tine of a plastic fork, or perhaps
     the ink tube from the inside of a cheap ballpoint pen.
     Seriously, folks, this is not tricky or expensive.

4) When booting from a Live CD, e.g. when bringing up a new system,
or bringing up a system with a crashed disk, instruct the user to
prepare a thumb drive.  The user ought to be doing that already,
to bring over personal keys et cetera, but make sure it also has
a random seed file.  Unless another trusted source is more easily
available, openssl should check for the existence this, then stuff
it into /dev/urandom and proceed as above.

This is yet another case were a one-dollar piece of hardware
solves a problem that is simply not solvable by software alone.

5) Ship a tool that allows people to download a Live CD image,
munge the image to add a unique random seed file, and only then
burn the image to CD.

I have some code that more-or-less does this, although I haven't
looked at it recently.

This works hand-in-hand with some of the grub enhancements that
Ard Biesheuvel has been talking about.

This doesn't seem particularly central in the set of things that
people expect of openssl ... but if you are serious about being
super-responsible and diligent and doing the Right Thing™ then
things like this will help.  Ship the necessary tools with openssl
in the short term and push them upstream in the slightly-longer
term.



More information about the cryptography mailing list