On 08/01/2009 02:06 PM, Jerry Leichter wrote:

>  A while back, I evaluated a
> technology that did it best to solve a basically insoluble problem:  How
> does a server, built on stock technology, keep secrets that it can use
> to authenticate with other servers after an unattended reboot?  

This problem is routinely solved in practice.

> Without
> tamper-resistant hardware that controls access to keys, anything the
> software can get at at boot, an attacker who steals a copy of a backup,
> say - can also get at.  

1a) Don't put the keys on the routine backups, and/or
1b) secure the backed-up keys as carefully as you secure the machine 

2) If the machine itself is not secure, you have already lost the
game and there's no hope of securing any keys or certificates on
that machine.

> So, the trick is to use a variety of
> measurements of the hardware - amount of memory, disk sizes, disk serial
> numbers, whatever you can think of that varies from machine to machine

I see no advantage in that.  The only halfway-useful property that 
such data has is that it is not backed up by ordinary off-the-shelf 
backup routines.  That's not an important advantage because it is 
easy to arrange for *any* data of your choosing to be not backed up.
 -- If you routinely back up files, put keys in a special file.  
 -- If you routinely back up entire partition, put keys in a special 
  partition (or outside any partition).  
 -- If you routinely mirror entire drives, put keys on a special drive.  
This is all "stock technology".

Let's be clear:  If the attackers have penetrated the machine to the 
point where they can read the keys from a special file/partition/drive, 
they can read the hardware serial numbers etc. as well.

> .....  Since hardware does need to be fixed or
> upgraded at times, a good implementation will use some kind of "m
> unchanged out of n measurements" algorithm.  

That makes life harder for the good guys, and makes life easier for
the bad guys.  Just putting the keys on disk is far more reliable
and practical, especially during hardware maintenance (scheduled or 

On top of all that, there is the very serious risk of a dictionary
attack against the hardware serial numbers.  There's nowhere near
enough entropy in the hardware serial numbers.  There is incomparably
more entropy in a special file/partition/drive.

> Virtualization changes all of this.

That's yet another reason for not taking the hardware serial number
approach.  In contrast, a special file/partition/drive can be virtualized 
in a direct and natural way.

Bottom line:  Relying on hardware serial numbers etc. to defend keys 
is not recommended.  Vastly more practical approaches are available.

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to