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.]
> 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"? 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. > I downloaded the code and spot-checked it quickly. On the whole, it > looks like a really clean and professional implementation. Thanks for that initial assessment. While we're proud of the work we've done, we deliberately open-sourced the daemon in order to invite such scrutiny. > ekeyd-1.1.3/device/frames/pem.c defines a function pem64_decode_bytes(). > This function takes an incoming sequence of chars (possibly supplied by > an attacker), promotes them to int values, and uses them to dereference > a fixed-sized array 'inverse_dictionary[128]'. > > Thus when built with compiler settings which treat char as signed, an > attacker can supply corrupt PEM64 strings which, rather than decoding > correctly, can be instead read from chosen locations of the 128 bytes of > space prior to the start of inverse_dictionary. If char is unsigned, the > bad guy can read subsequent bytes. > > If the daemon was built on a good day, it will just have uninteresting > stuff in those locations. On a bad day, you'll end up with key material > there. 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. 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. 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. Thank you for your comments. If you have more and wish to discuss them directly with us, then please feel free to email [email protected] since that does get seen by all the relevant people. Regards, Daniel. -- Daniel Silverstone http://www.digital-scurf.org/ PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69 _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
