Re: seeding /dev/random from a security key
On Tue, Mar 26, 2024 at 11:52 AM Björn Persson <Bjorn@rombobjörn.se> wrote:
>
> Jeffrey Walton wrote:
> > Out of morbid curiosity, what hardware are the servers using? RDRAND
> > and RDSEED have been available since about 2012, so it is mostly
> > ubiquitous nowadays.
>
> Do you mean I should add to the e-waste pile by throwing away working
> hardware and buy an entire new computer instead of buying a tiny dongle?
No, I was wondering about the server hardware. I would be surprised to
learn of something without Intel's SecureKey nowadays (assuming it is
x86{-64} based).
> > Be careful of rng-tools. It does not do a good job for non-mainstream
> > generators, like VIA's Padlock Security Engine. And rng-tools did not
> > support generators for architectures, like you would find on ARM,
> > aarch64 and PowerPC.
>
> I figure it can be used with devices it supports even if there are some
> other devices it doesn't support – but it looks like I'd have to build
> it from source myself.
Yeah, I've had to do that in the past. You will also (probably) need
to write a systemd unit file or two.
> > OpenSSL and GnuPG should be
> > able to extract the entropy from the card, and then use it to seed
> > /dev/{u}random.
>
> This job requires a daemon. OpenSSL is a library. Or do you mean its
> command-line tool? So how would I tell that to fetch random data
> through PKCS #11?
>
> GnuPG at least has a daemon called scdaemon. Is that what you mean? So
> how would I tell that to fetch random data through PKCS #11 and write
> to /dev/random?
For what you want to do, and if I am parsing it correctly... I would
write a daemon in C to collect the entropy from the source, then
extract the entropy from the bytes, and then insert the entropy into
the system's random number generator. For entropy extraction, take a
look at HKDF and Krawczyk's paper. Krawczyk does a good job of cleanly
separating entropy extraction from later stage key expansion.
The part about extracting the entropy from the source would use
OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}. Since this is a daemon
and not a driver, I believe you can use the shared objects.
I eat my own dog food. I've done similar in the past with both an
EntropyKey and custom on-board generator for a MIPS Creator CI-20 with
the jz4780-rng. For the EntropyKey, I did not even bother decrypting
the stream. I stuffed the encrypted stream right into /dev/random,
because the amount of entropy does not change regardless of the
formatting (encrypted vs unencrypted).
And you may find this interesting... Debian suffers entropy depletion
on /dev/random and can hang components that use it, including
/dev/urandom. It is easy for a userland process to do. All you need is
a stock Debian system _without_ an entropy gatherer like Haveged. Have
your program perform a big read on /dev/random with O_NONBLOCK. The
kernel will return every last bit of entropy it has, and then start
blocking processes. The only way to recover in reasonable time is to
run a daemon like Haveged. I reported it to the devs several years
ago, but there was no interest in fixing it.
Jeff
Reply to: