[Cryptography] grand principles and niggling details

[John Denker]

On 11/22/2016 01:03 PM, Ron Garret wrote:

> I am constantly surprised by how often discussions of randomness
> arise on this list, and how long they continue.  Everything that
> matters about randomness can be summarized in four bullet points

I really don't think so.

Let me offer a different list of grand principles:

  Principle #1:  In the security business, there are very few grand
   principles.  Mostly what we have is a boatload of niggling details.

  Principle #2: The details matter.  You have to get the details right.

In other words, it doesn't do much good to put four or five deadbolts
on the front door, if the back door and side window are standing open.

As a corollary:  Security is hard, and will always be hard.  The
defender needs to block every avenue of attack, whereas the attacker
only needs to succeed at one.

> 1.  You need two things: an entropy source, and a whitener.

When viewed long-term, from the 100,000-foot level, that is arguably
kinda almost true.  Entropy is the wrong word and the wrong concept,
but let's not get into that right how.  More importantly, as Rich Salz
and others keep asking, what are we supposed to do when we don't have
both of those things?  Just give up?

I say that is an excellent question, and No, usually we should not
just give up.  There is no single "silver bullet" solution, but there
are ways of handling most of the cases that come up, case by case.

   On the other hand, here are /some/ platforms that are not secure
   and cannot be made secure.  We should not give up on the overall
   goal, namely security, but sometimes we have to give up on certain
   petty subgoals (such as certain brain-dead platforms).  This is
   basic maze-running strategy:  Back out of the dead end so you can
   make progress toward the overall goal.
       https://www.av8n.com/physics/glorpy-maze.html
       https://www.av8n.com/physics/research-maze.htm



Here's a particular case:  Consider booting a system, called the
/target/ system, from a "Live CD" .iso image.  This includes the
case where we want to install an operating system on a brand-new
target machine.  It also includes maintenance situations, and
other situations as well.

1)  Observe that nobody actually uses CDs for this purpose anymore.
 For obvious reasons, they use USB flash drives.  You can get a
 brand-name 16GB thumb drive for about 6 bucks (with free shipping).
 The .iso image takes up less than 2 GB.

2) When I am working from a "Live" .iso image, I need more than
 just that.  I need various public keys, at least one private key
 (possibly highly restricted), dozens of useful little scripts, and
 many pages of notes on what to do and how best to do it.

3) Combining the two previous ideas:  When creating the bootable drive,
 it makes sense to partition it.  This commonly requires munging the
 .iso image so it can handle booting from a partitioned drive.  This
 is just another of the niggling details.
   http://manpages.ubuntu.com/manpages/xenial/man1/isohybrid.1.html

 The .iso image occupies the first partition.  On the second partition
 I put a file called carepackage.tgz containing my keys, scripts, notes,
 et cetera.  In other words, I use sneakernet to schlep files from my
 normal well-configured machine to the target machine.

*At this point I have done zero extra work in the name of randomness.*
 This is all stuff I needed to do anyway.

4) The script that creates the carepackage also does this:

      :; ( echo -en "\037\037"          # magic number; see file(1)
        /bin/dd if=/dev/urandom bs=510 count=1 status=none
      ) > ${sneaker}/random.seed

 You can think of this as like passing sourdough starter from someone
 who already has it to someone who needs it.  You don't need to create
 it from scratch.

5) I boot up the system in "Live" mode (as opposed to installer mode).
 At this point it has already mounted the first and second partitions
 on the boot drive.  That means it is super-easy for me to cat the
 random.seed file into /dev/random.

 At this point the Live system has not installed anything.  It has
 not cut any cryptographic keys.  It has not made any HTTPS or SSH
 connections.  It has not even mounted the main disk on the target
 machine.

      It has done some ASLR using some very dubious randomness,
      but I'm not gonna worry about that too much.

 One of the first things I do with the newly-initialized RNG is to
 rewrite the random.seed file on the flash drive.  That way, even
 if I have to re-use the drive immediately, there will be less risk
 of replay attacks.  

6) Now I can switch to "Installer" mode if desired.  When ssh and
 openssl are installed, the generated keys should be good enough ...
 certainly very much better than if the RNG had not been initialized.
 Similarly secure network connections can be established using decent
 nonces.

-------------------
Discussion

A) One weak point here is step 5.  If Joe Luser skips this step and
fires up the installer directly, the random.seed file is not put to
good use.

Suggestion:  Each distro should put a random.seed file in the .iso
image, near the top, outside of the squashfs system.  There is no
point in squashing random data anyway, and putting it outside makes
it easy to rewrite.  The isohybrid step already munges the .iso
image to make it bootable.  It would be very little extra work to
randomize the random.seed file, so that every "Live" drive on earth
has its own private, high-quality seed.

Another possibility:  The Live system could notice the random.seed
file sitting there on the second drive, and stir it into /dev/random,
without requiring any effort from the user.

B) The excellent grub-related ideas put forth by Ard Biesheuvel and
others don't solve the entire problem, because the "Live" flash drive
ordinarily doesn't use grub.  Instead there is a simple 440-byte
chainloader that gets stuffed into block 0.  This is another of
those niggling details.

C) Another weak point, related to item (A), is that the installer
does not bestow any randomness on the newly-installed system AFAICT.
This would be super-easy to fix.  The installer should use its own
RNG to randomize the /var/lib/urandom/random-seed file.

D) Another weak point is that you have to guard the flash drive from
now until the end of time, unless you destroy it by grinding or by
hot chemicals:
  https://www.av8n.com/security/private-data-storage.htm#sec-annihilate

That's because there is currently no such thing as "secure erase" on
typical flash memory chips.  Every past version of the random.seed
file is probably still there somewhere, and not overwhelmingly hard
for a determined attacker to find.  This is another of those niggling
details.  This is an entirely fixable problem.  One hopes that some
day soon the folks who write the drive firmware will start taking
security seriously.

Still, though, think about what we have accomplished with the sourdough
approach aka the sneakernet approach.  The bad guys can no longer sit
in their comfy chairs and succeed with a network-based attack on the
non-very-random number generator; instead they have to conduct a
black-bag job, to get the flash drive.  This greatly increases their
cost, including their risk of getting caught.  

I reckon for a vast segment of the market, this is good enough.  Others
may need higher security, but they presumably have a bigger budget, and
can afford to keep the flash drive locked up when not in use, and grind
it or barbecue it before disposal.