[Cryptography] OpenSSL and random

Mon Nov 28 19:48:22 EST 2016

I agree with your first three paragraphs, but your suggestions from that
point are the concern of the OS, not a library.

OpenSSL should call getrandom/getentropy/CryptGenRandom/SecRandom only. It
should not by default try to manage its own randomness pool because that
breaks silently. If necessary, clients could opt into an interface that
does this if they really need the performance.

On systems that don't support the above functions, it should refuse to
compile. The only way to make it compile would then be flags like
--with-dev-urandom, --with-dev-hwrng, --with-no-system-entropy or similar,
and they should not be defaults.

The controversy we perceive is manufactured by people who want backwards
compatibility on platforms that don't provide the right interface. Nobody
should be writing new code that tries to do magic with /dev/random or
/dev/urandom - those are legacy interfaces, to be used by knowledgeable
command line operators, not software.

Mark

On 28 Nov 2016 23:48, "John Denker" <jsd at av8n.com> wrote:

> 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.
>
> _______________________________________________
> The cryptography mailing list
> cryptography at metzdowd.com
> http://www.metzdowd.com/mailman/listinfo/cryptography
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20161129/68a5956d/attachment.html>