[149131] in cryptography@c2.net mail archive
Re: [Cryptography] cheap sources of entropy
daemon@ATHENA.MIT.EDU (John Kelsey)
Mon Jan 20 12:27:39 2014
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <r422Ps-1075i-E0F87A850AF04C7D9F27E6C50696D205@Williams-MacBook-Pro.local>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Mon, 20 Jan 2014 12:13:01 -0500
To: Bill Frantz <frantz@pwpconsult.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Jan 18, 2014, at 1:07 PM, Bill Frantz <frantz@pwpconsult.com> wrote:
...
> I have always looked at HSMs as black boxes built by people I don't trust. If I built it I would feel different, but you should be uncomfortable using my HSM. Getting mutually suspicious people to trust the same HSM is an interesting social/technical problem.
The problem is, nobody makes *everything* they use. A sufficiently resourceful attacker might attack your device on all kinds of levels, and you can't possibly check them all yourself. This has even been worked out by people with s lot of resources--classified systems apparently use a lot of off the shelf components now, for economic reasons. The folks who run those systems would love to be paranoid enough to verify everything in their system, but they can't--it would cost too much.
I spent some time running through this with e-voting, and the same problem exists everywhere--there's a limited amount you can do to verify your software and hardware if you want to be able to afford the final product, and even spending a lot more than you can afford, you can't really get trustworthy software or hardware. The plausible solutions there (which may be replicatable) are:
a. Use some kind of physical audit trail to allow detection of misbehavior.
b. Use some kind of electronic audit trail to allow detection of misbehavior, using other machines to do the checking and assuming an attacker can't compromise everything.
c. Use some clever cryptographic protocol to allow detection or prevention of misbehavior.
A good example of (b) is certificate transparency--we can't avoid trust in CAs if we want anything like conventional PKI, but we can make CA misbehavior *visible*.
It's possible to do similar things with crypto protocols, though I'm not sure how generally applicable they will be. Chaum had this idea of an "observer" which could prevent double-spending of e-cash but couldn't otherwise do anything bad. I wonder if something like that could be developed for various hardware crypto operations, so that at least you could get multiple independent machines checking on one another.
--John
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
