<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 22, 2014 at 12:46 PM, Jerry Leichter <span dir="ltr"><<a href="mailto:leichter@lrw.com" target="_blank">leichter@lrw.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Oct 22, 2014, at 10:01 AM, Bill Cox <<a href="mailto:waywardgeek@gmail.com">waywardgeek@gmail.com</a>> wrote:<br>
> As for downsides....  Also, the possibility of having it reprogrammed by an attacker who intercepts it in the mail remains an issue, since most users will not likely re-flash their device.  I am not sure if the flash can be dumped securely over USB, or if an attacker can mod the program to deliver the original firmware, hiding the malware.<br>
Sounds like a great application for "sparkly nail polish" security.  Paint over the access points - the outside screws, the chips and on to the board, over a piece of tap sealing the USB - with one of those nail polishes with sparkly bits in it.  Take photos of each spot and deliver separately from the device itself, preferably through multiple channels (e.g., send in a separate envelope, and put signed copies on line).  The exact speckle pattern is random and as far as I know impossible to duplicate.  It's also easy to check "by eye".<br>
<span class="HOEnZb"><font color="#888888">                                                        -- Jerry<br>
<br></font></span></blockquote><div><br></div><div>So long as we're considering threats such as interception in the mail, I think we should look at a more detailed threat model.  The most obvious use for a TRNG is as an additional entropy source for a Linux server's entropy pool.  I would like to assume:<br><br></div><div>- An attacker, Mallory, is logged in as a regular user, but for some unexplainable reason is unable to obtain root access.<br></div><div>- The attacker know the *exact* state of the Linux entropy pool at time == 0<br></div><div>- There are 0 bits of entropy in the pool, and the pool is blocking on a read by gnupg which is trying to create a strong cryptographic key.<br></div><div>- The user of gnupg is being careful to not allow his new key hit disk in any non-encrypted form<br></div><div>- Fortunately, this system has a OneRNG key attached.<br><br></div><div>What attacks can Mallory mount?  One problem with my review of OneRNG so far is I have not looked at any source code, even though it's open source!  Such a review eventually should be done in depth by multiple people, but for now, here's two attacks this code needs to defend against:<br><br></div><div>- attacks that try to guess the random bits being added to the entropy pool<br></div><div>- attacks against the OneRNG's functioning properly<br><br></div><div>Do we care about cache-timing attacks?<br></div><div><br></div><div>To guess the random bits, Mallory might do a cache-timing attack.  To defend against it, first you need to do never branch based on the data from the OneRNG.  I need to go back and fix this in my infnoise driver.  It's easy to get this wrong.  This is particularly easy to get wrong if you do any health monitoring, like I do, in the driver.  OneRNG does health monitoring on the USB key, which is secure against cache timing attacks.<br><br></div><div>Even harder is doing no data based memory addressing.  A statistical analysis such as what rngd does will read and/or write data to a lot of places that depend on the TRNG data.  My infnoise driver also does this, reading from a memory location addressed by the last 14 bits of TRNG output, to find the expectation that the next bit will be a 1 or 0.  Does the OneRNG driver look for a string of only 0's or 1's coming from the device, and stop the driver if only 1's or 0's are output?  If you do, you help defend against faulty OneRNG devices, or devices that Mallory has compromised.  However, by incrementing the 0's memory location for every 0, and the 1's memory location for every 1, you give Mallory the possibility of a cache-timing attack.<br><br></div><div>So, it is unclear to me whether it makes sense to worry about this cache-timing attack.  The more extensive the health server-side health monitoring, the more cache-timing susceptible we are.  For now, I'll just point out these cache-timing attacks, but wont worry about whether the improved health monitoring justifies the security hole.  If you use rngd, there's no point in worrying anyway, since it will violate cache-timing defence rules far worse than your driver.<br></div><br><div>Can an attacker directly attack the OneRNG?  For example, it would be bad for the OneRNG to be accessible to Mallory in user space.  I would prefer that it only be accessible by the daemon feeding the entropy pool (rngd?).  Adding udev rules for users to use the OneRNG could be dangerous.<br></div><div><br></div><div>Can Mallory can load the system down and cause the OneRNG daemon to be swapped to disk?  If so, Mallory wins if he can gain physical access to the disk later.  Therefore, *all* buffers containing TRNG output should be considered as sensitive as passwords, and should be allocated in non-swappable memory using mmap, and a secure zeroing function (such as secure_zero from the Bake2 source) should be used to clear all TRNG bits after they are fed to /dev/random (using ioctl).<br><br></div><div>Can Mallory cause any kind of time-out in the USB communication, by causing high system load?  My infnoise driver does the bitbang hack to control the clocking of the circuit on the board from the infnoise driver.  If left unclocked for too long, the voltage in the INM drifts to 0, allowing Mallory to guess the next several bits when clocking starts again.  To defend against this, I will have to measure the time between packets read from the INM and when it is too long, I'll have to drop the packets.<br></div><div><br></div><div>I think the hardware design of OneRNG is excellent for security.  A solid code review of the driver probably is in order at some point, however.  This stuff is *very* easy to get wrong - my infnoise driver needs a lot of work, and I'll bet most TRNG drivers out there don't even consider the security of the TRNG bits against things like swapping to disk.<br><br>Bill<br></div></div></div></div>