On 01/28/2011 05:43 AM, Daniel Silverstone wrote:
On Thu, Jan 27, 2011 at 12:03:26PM +0000, Marsh Ray wrote:
[Disclaimer: I work for Simtec and worked on the Entropy Key. We are honestly
interested in frank and open discourse about the device and in that spirit, my
comments follow.]
Cool
For example, this key requires a daemon to operate. On *nix this will
probably be running as root, or at least as a user with privileges to
talk to USB and lie to /dev/random about how much real entropy it has.
Why do you say "lie"?
Well, I was thinking about what the min-privilege such a device would
need. Even though most folks will probably just end up running this code
as root, in theory the driver needs to be able to only do a few things:
* talk to the USB device, preferably in an exclusive sort of way
* supply data to the kernel pool
* convince the kernel pool that the supplied data contains a certain
amount of entropy (the main value proposition of the product)
Thus, IF the driver/daemon for this device were compromised, we could
expect that the attacker would gain (as a minimum) local privileges
which enable him to 'lie' to the kernel about the amount of entropy its
pool contains.
I ask since in the case of the Entropy Key we can be
reasonably confident that it really is true entropy, and on top of that we work
very hard to *under* estimate the amount we tell the kernel.
That's good, I certainly didn't mean to imply that you guys would
intentionally lie. Just that an attacker who pwned the daemon probably
could.
Your comments about pem.c are inded valid to a degree. In order to be feeding
data to this function you'd need to either be root on the box, or else have
physical access to plug in a nefarious USB device which contains the same
secret key information as a real entropy key authorised to operate on that box.
In either case, you have "lost" already.
But then why does this code exist at all?
Why bother with all the negotiating of authentication keys if we are
expected to trust the integrity of the USB devices?
Are you sure a local-USB attacker would need to know a secret key? It
looked to me like the pem.c code ran before packet authentication (e.g.,
it was used to un-PEM the MAC itself).
The only thing the daemon would do
with an attacking USB device would be to attempt to reset it and wait for a
serial number packet from the device. That packet, while PEM encoded, would
have to be well MACced and thus any attack would simply result in the state
machine inside the daemon deciding that the device was bad and getting no
further through the system.
If you have found a way to leak key material (or even a serious attack vector
which could cause crashing via bad PEM input data) then I'd love to see it.
If the key material happened to land in the right 128 bytes of RAM, I
think there's a good chance that some variant on the padding timing or
POET attack could obtain it quickly.
If nothing else, you could obtain the memory addresses of load modules,
if defeating ASLR/PaX is a useful step in further exploitation.
We're always grateful to receive patches (or just directed ideas for improving
the codebase). I have put "harden pem.c" on my TODO list.
You could securely overwrite dynamic memory before free()ing it. I
didn't see that happening.
Regards,
- Marsh
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
