Mailing List Archive

Read random bytes from Gnuk potentially frequently without destroying the card
Hi all,

Just for fun and because I have extra Gnuk tokens lying around, I'd like
to try writing a program for my libreCMC router that feeds the Linux
entropy pool with data from the token's true RNG. The help text for
scdaemon states
> # RANDOM <nbytes>
> #
> # Get NBYTES of random from the card and send them back as data.
> # This usually involves EEPROM write on the card and thus excessive
> # use of this command may destroy the card.

I note that the help text says "usually." Can anyone confirm whether
Gnuks specifically do a ROM write in this case?

If they still do the write, I have a follow-up question.

I also notice that OpenSC has the feature to get an arbitrary number of
random bytes from the card with its OpenPGP module (it's not limited to
256 like requests to scdaemon are), like this:
$ pkcs11-tool --generate-random 1024

I realize this isn't the list for OpenSC questions, but does this
probably use the same mechanism under-the-hood and hence invoke a write
as well, or is there a chance that it avoids the write?

Thanks for the excellent libre software, and happy hacking
Re: Read random bytes from Gnuk potentially frequently without destroying the card [ In reply to ]
Hi,

On Sunday, 20 November 2022 04:59:32 GMT John Scott via Gnupg-users wrote:
> I'd like to try writing a program for my libreCMC router that feeds the
> Linux entropy pool with data from the token's true RNG.

FYI, I wrote a similar program a few years ago: scdrand [1]. It uses
Scdaemon’s RANDOM command to extract random bytes from any Scdaemon-supported
token (be it a Gnuk token, an actual smartcard, a Yubikey, etc.) and feed them
to the kernel’s entropy pool.

I am not really using it anymore because I found that I had no longer any need
for it with recent Linux kernels, but it should still work.

Of course, this should not dissuade you from writing your own program. :)


> I also notice that OpenSC has the feature to get an arbitrary number of
> random bytes from the card with its OpenPGP module […] does this
> probably use the same mechanism under-the-hood

Yes. Both Scdaemon’s RANDOM and pkcs11-tool’s --generate-random work by
sending the token a ISO7816 "GET CHALLENGE" command, which instructs the token
to send back random bytes.

Whether “excessive use” of that command end up damaging the token, and what is
“excessive use”, ultimately depends on how that command is implemented
token-side.

In the specific case of the Gnuk token, the GET CHALLENGE command is
implemented using the same logic as the one used in NeuG [2]. I have not
looked in details how NeuG works, but given that it is specifically intended
as a random number generator, I’d say it’s safe to assume than using it as
intended cannot ”destroy the token”. :)

Hope that helps.

- Damien

[1] https://git.incenp.org/damien/scdtools
[2] https://www.gniibe.org/memo/development/gnuk/rng/neug.html
Re: Read random bytes from Gnuk potentially frequently without destroying the card [ In reply to ]
Damien Goutte-Gattat wrote:
> In the specific case of the Gnuk token, the GET CHALLENGE command is
> implemented using the same logic as the one used in NeuG [2]. I have not
> looked in details how NeuG works, but given that it is specifically intended
> as a random number generator, I’d say it’s safe to assume than using it as
> intended cannot ”destroy the token”. :)

No, it never destroy the token. So, for Gnuk Token, use it freely.

> # RANDOM <nbytes>
> #
> # Get NBYTES of random from the card and send them back as data.
> # This usually involves EEPROM write on the card and thus excessive
> # use of this command may destroy the card.

I didn't know this help text. I think that it's specific to Zeitcontrol
card.

For Gnuk on STM32F103 (not the emulation version), it runs ADC (Analogue
to Digital Converter) for randomness. It never destroy anything.

While intended usage of ADC is measurement of some analog input, we use
ADC to get noise (in theory, each sample has 0.5-bit of information,
nobody knows).
--

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users