Read random bytes from Gnuk potentially frequently without destroying the card

[Damien Goutte-Gattat]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20221120/fd23cba8/attachment.sig>