Re: seeding /dev/random from a security key
On Tue, Mar 26, 2024 at 7:12 PM Björn Persson wrote:
>
> Jeffrey Walton wrote:
> > For what you want to do, and if I am parsing it correctly... I would
> > write a daemon in C [...]
>
> Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
> somehow. Writing and compiling a daemon is no less work than compiling
> an already written daemon.
>
> > 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}.
>
> RNGD 6 actually uses OpenSC's libp11, where it calls the function
> PKCS11_generate_random, which in turn calls the PKCS #11 function
> C_GenerateRandom.
It sounds like you have it sorted out. Good luck with it.
Jeff
Re: seeding /dev/random from a security key
Jeffrey Walton wrote:
> For what you want to do, and if I am parsing it correctly... I would
> write a daemon in C [...]
Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
somehow. Writing and compiling a daemon is no less work than compiling
an already written daemon.
> 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}.
RNGD 6 actually uses OpenSC's libp11, where it calls the function
PKCS11_generate_random, which in turn calls the PKCS #11 function
C_GenerateRandom.
Björn Persson
pgpOK5m0QGWIe.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Tue, Mar 26, 2024 at 11:52 AM Björn Persson 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
Re: seeding /dev/random from a security key
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?
> 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.
> 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?
Björn Persson
pgpia22PvZ5bD.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Mon, Mar 25, 2024 at 4:33 PM Björn Persson wrote:
>
> In a quest to acquire hardware random number generators for seeding
> /dev/random on servers that lack a built-in entropy source, I'm
> investigating how random data can be obtained from a security key such
> as a Nitrokey, Yubikey or a similar device.
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.
> RNGD version 6 from https://github.com/nhorman/rng-tools can fetch
> random data through a PKCS #11 interface, but the two versions of RNGD
> in Debian seem to lack that ability. Debian has rng-tools5 and
> rng-tools-debian, but not Neil Horman's version 6. Or am I just failing
> to find it?
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.
> SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain
> random data from a "smartcard"-compatible device, but I don't find that
> in Debian either.
>
> Does anyone know of another way to obtain random data from devices of
> this kind?
PKCS#11 is a standard interface. If the card provides a generator,
then the code is the same for all cards. OpenSSL and GnuPG should be
able to extract the entropy from the card, and then use it to seed
/dev/{u}random.
But keep in mind ... the kernel crypto folks effectively deprecated
/dev/random, and recommend using /dev/urandom for your random bits. Or
use getrandom(2). See .
Jeff
Re: seeding /dev/random from a security key
Andy Smith wrote: > EntropyKey is a dead product that can no longer be obtained I've seen several like that. They're permanently sold out, or the webshops are abandoned and half-broken. Pure random number generators that are actually possible to buy are rare. That's why I'm investigating whether security keys can be used instead. Security keys are available from multiple vendors, but it's hard to find any information about the random number generators inside them. > OneRNG is still in production. I tried to buy one of those a while ago, but I couldn't because the shop didn't like my card number. > On their mailing list however, there > is a recent discussion about whether there any point. The conclusion > seems to be "not really". Thread starts here: > > http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html > > The thread covers how to make rngd feed /dev/random from a OneRNG in > Debian 12, but it is no longer possible to tell if that does > anything useful. It is indeed harder to tell since Linux stopped keeping track of the entropy level, and it's now necessary to force-feed /dev/random periodically instead of waiting for the entropy level to drop. A random number generator is still useful on a server with no keyboard, no spinning disk and no RDRAND or similar processor instruction. Otherwise network traffic becomes the only source of entropy, and I'd rather not rely solely on events controlled by other computers. It also helps to mix entropy from multiple sources, in case one of them has a design flaw or a backdoor, or breaks down, or loses its driver like in Debian bug 1041007. Björn Persson pgpEuWy2nx_ME.pgp Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Mon, Mar 25, 2024 at 06:09:02PM -0400, e...@gmx.us wrote: > On 3/25/24 17:27, Andy Smith wrote: > > The thread covers how to make rngd feed /dev/random from a OneRNG in > > Debian 12, but it is no longer possible to tell if that does > > anything useful. > > If not from devices like this, from where does Debian get its randomness? random(4) (i.e. "man 4 random") gives a basic introduction to the topic, if you have manpages-dev installed.
Re: seeding /dev/random from a security key
On 3/25/24 17:27, Andy Smith wrote: The thread covers how to make rngd feed /dev/random from a OneRNG in Debian 12, but it is no longer possible to tell if that does anything useful. If not from devices like this, from where does Debian get its randomness? -- For is it not written, wheresoever two or three are gathered together, yea they will perform the Parrot Sketch. -- Rob on ASR
Re: seeding /dev/random from a security key
Hi, On Mon, Mar 25, 2024 at 09:24:23PM +0100, Björn Persson wrote: > Does anyone know of another way to obtain random data from devices of > this kind? I have some EntropyKeys and some OneRNGs. I have the rngd packaged in Debian feeding /dev/random from them. This had an actual noticeable effect in Debian 9 and earlier, but since the reworking of Linux's random subsystem I cannot demonstrate any benefit unless I disable all use of the RDRAND CPU instruction. EntropyKey is a dead product that can no longer be obtained but OneRNG is still in production. On their mailing list however, there is a recent discussion about whether there any point. The conclusion seems to be "not really". Thread starts here: http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html The thread covers how to make rngd feed /dev/random from a OneRNG in Debian 12, but it is no longer possible to tell if that does anything useful. I most likely will not be replacing these devices when they fail. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
seeding /dev/random from a security key
Hello! In a quest to acquire hardware random number generators for seeding /dev/random on servers that lack a built-in entropy source, I'm investigating how random data can be obtained from a security key such as a Nitrokey, Yubikey or a similar device. RNGD version 6 from https://github.com/nhorman/rng-tools can fetch random data through a PKCS #11 interface, but the two versions of RNGD in Debian seem to lack that ability. Debian has rng-tools5 and rng-tools-debian, but not Neil Horman's version 6. Or am I just failing to find it? SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain random data from a "smartcard"-compatible device, but I don't find that in Debian either. Does anyone know of another way to obtain random data from devices of this kind? Björn Persson pgp1OCs1ezY_B.pgp Description: OpenPGP digital signatur
