Ted writes:
> [...]
>
> As far as yarrow versus the current design, I've certainly looked at
> yarrow, and I've certainly considered adding some of yarrow's design
> into my /dev/random implementation. Given that I strongly recommend
> that the 512 bytes of entropy be saved from /dev/random at shutdown
> time, and then written to /dev/random at startup time (without updating
> the entropy estimate), I question how realistic the attack scenario that
> Yarrow tries so hard to defend against.
This would be the "iterative guessing attack" the yarrow authors
design against to recover from state compromise.
One argument against the realism of the iterative guessing attack
might be you need root to obtain the state, and that if you have root
you can easily change other things to maintain ability to predict
crypto keys. Say like linking /dev/[u]random to /dev/zero, or
something marginally more subtle, or modifying target binaries, or
grabbing the target servers private key from /dev/keymem.
However probably just grabbing the pool state with ioctl RNDGETPOOL
and then getting out may be less likely to trigger alarms.
Arguments in favor of the attempts to recover from state compromise:
- The bootstrap problem -- where did /dev/random get it's start state
from before there was a seed file to load; all the entropy samples
went in small chunks, and if the machine was outputting randomness the
whole time, the attacker may be able to maintain the "iterative
guessing attack" right from install time.
- Situations where the server has no writeable media to store it's
/var/run/seed -- boot of CD or harddisk mounted read only plus /var
mounting on a ram disk. In this scenario the attacker gets to mount
- Distributions which don't include the shutdown and startup state
save and restore. (I've got an old slackware installation at home
with /dev/random, but no state saving and loading in /etc/rc.d/*).
- Default wrong permissions on /dev/[u]random -- discards any user
entropy (primarily an argument to persuade people to fix the
permissions).
If we buy these arguments, then Yarrow's conservative recovery
strategies are a good idea.
> I also feel very strongly that something like 3DES/AES counter mode is
> something which a crypto application which needs a lot of session keys
> should be implemented in user-mode ---- in a library, probably. There's
> no real reason why that needs to be implemented in the kernel ---
> /dev/random needs to be there because it's doing all of the sampling of
> the system environment, and the entropy pool needs to be stored securely
> and easily updated by the entropy collection routines.
>
> So it may be that the best way to handle things is to implement the
> upper level of a yarrow-like design in a usermode library, and which
> does its "catastrophic reseeding" by reading from /dev/random as
> necessary. Certainly that is my bias at this point.
It's certainly preferable to keep the line count in the kernel down.
Yarrow is quite complex.
However, unprivileged users can do DoS attacks against /dev/random --
cat /dev/random > /dev/null. This and the risk of server stall where
there is no input device means many people avoid /dev/random for
servers and use /dev/urandom. And use /dev/random just for long term
private key generation.
To use /dev/random as a source of state compromise recovery for a user
land yarrow, you'd want a way to be able to use non-blocking IO to
atomically read some chunk of bits (100 for fast and 160 for slow
reseeds with Yarrow-160) from /dev/random otherwise you'd still be
vulnerable to iterative guessing attacks based on other /dev/urandom
processes outputs. Looking at the /dev/random code, I think you'll
get a short read if not enough bits are available.
A more integrated yarrow can avoid the risk of DoS attack preventing
state compromise recovery by reserving some of the /dev/random output
for state compromise recovery and leaving the rest for /dev/random
users.
Adam
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
