[Cryptography] A review per day of TRNGs: OneRNG
waywardgeek at gmail.com
Thu Oct 23 06:51:02 EDT 2014
On Wed, Oct 22, 2014 at 12:46 PM, Jerry Leichter <leichter at lrw.com> wrote:
> On Oct 22, 2014, at 10:01 AM, Bill Cox <waywardgeek at gmail.com> wrote:
> > 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.
> 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".
> -- Jerry
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:
- An attacker, Mallory, is logged in as a regular user, but for some
unexplainable reason is unable to obtain root access.
- The attacker know the *exact* state of the Linux entropy pool at time == 0
- 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.
- The user of gnupg is being careful to not allow his new key hit disk in
any non-encrypted form
- Fortunately, this system has a OneRNG key attached.
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:
- attacks that try to guess the random bits being added to the entropy pool
- attacks against the OneRNG's functioning properly
Do we care about cache-timing attacks?
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.
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.
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.
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.
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).
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cryptography