Solo: Stirring in entropy

[nickray]

In private conversation, @ThomasHabets suggested adding the possibility to add external entropy to the TRNG, in light of the ROCA Infineon incident.

E.g., if you need X bytes of entropy, allow user to provide X independent bytes of entropy (generated e.g. on desktop or otherwise auditable RNG). Use entropy := device_entropy XOR stir_in_entropy to generate key.

I think this is a great idea and we should do it (e.g. solo key reset --stir-in-entropy <some bytes in some easily digestible representation>)

cf. https://crypto.stackexchange.com/a/17660

[manuel-domke]

Indeed a great idea!
I'd recommend passing in the entropy via file source or having an option to pipe it in.
Reduces the possibility of your random bytes to become non-random (leaked).
Also saves some hassle with the representation.

[nickray]

With endless development resources and a different chip, we could also add USB OTG and let people pipe in your infinite noise or a OneRNG :grin:

[manuel-domke]

Doing it in software is probably the better way. Even if I love the idea of connecting them via OTG, this is not a way to go ;-)

Not seen any trustworthy self-auditing RNG's yet. OneRNG just mixes with a CRC (on-chip) function, if I'm correct. And the infnoise requires a special driver with whitening and health monitoring, which is in my opinion the safest way to audit an entropy source, but complex.

[nickray]

Right :) There is some diagnostics (SECS register, p. 662), but it's far from an "audit". We might want to separately integrate a basic "is the TRNG functioning" test in solo tool though. Something like stream solo key rng raw for a while, check it's not completely non-random.

[conorpp]

Currently there's a basic entropy test over 16KB in the testing tool.
https://github.com/solokeys/solo/blob/master/tools/testing/tests/solo.py#L32

[nickray]

For the record:

% time solo key rng raw|head -c 1048576 > random-MiB
solo key rng raw  7.06s user 2.22s system 9% cpu 1:40.32 total
head -c 1048576 > random-MiB  0.03s user 0.00s system 0% cpu 1:39.89 total

% ent random-MiB
Entropy = 7.999844 bits per byte.

Optimum compression would reduce the size
of this 1048576 byte file by 0 percent.

Chi square distribution for 1048576 samples is 226.57, and randomly
would exceed this value 89.96 percent of the times.

Arithmetic mean value of data bytes is 127.4872 (127.5 = random).
Monte Carlo value for Pi is 3.141964500 (error 0.01 percent).
Serial correlation coefficient is -0.000115 (totally uncorrelated = 0.0).

% ent -b random-MiB
Entropy = 1.000000 bits per bit.

Optimum compression would reduce the size
of this 8388608 bit file by 0 percent.

Chi square distribution for 8388608 samples is 0.39, and randomly
would exceed this value 53.47 percent of the times.

Arithmetic mean value of data bits is 0.5001 (0.5 = random).
Monte Carlo value for Pi is 3.141964500 (error 0.01 percent).
Serial correlation coefficient is 0.000192 (totally uncorrelated = 0.0).

cf. http://www.fourmilab.ch/random/

[manuel-domke]

No dought the RNG on the STM chip actually works fine, but as you already said, it's far from being auditable. Also, it's closed-source hardware. At least we know the entropy comes from an ADC.

So a way of mixing in entropy from more transparent sources would be great, but it's surely only something for advanced paranoia ;-)

@conorpp: Those tests don't run on every device, before a key is created - do they? This would be a solution to at least identify broken/defect RNG's, as silently failing entropy sources are pretty bad.
And what about that SECS register? Is it actually read before key creation?

The idea from @nickray is good, but I guess most users won't perform such a test. Maybe if it's integrated into a general self-test.

Imho, the firmware should at least verify the entropy source immediately before it's actually used (when no auditing is possible).

[nickray]

This seems to be a not-so-bad result:

% solo key rng raw | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests...
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 999
rngtest: FIPS 140-2 failures: 1
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 1
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=44.639; avg=82.640; max=19531250.000)Kibits/s
rngtest: FIPS tests speed: (min=4.994; avg=23.831; max=88.303)Mibits/s
rngtest: Program run time: 237760016 microseconds
solo key rng raw  16.45s user 3.82s system 8% cpu 3:58.20 total
rngtest -c 1000  0.80s user 0.02s system 0% cpu 3:57.76 total

In the other direction, we have https://github.com/solokeys/solo-python/pull/18 now.

[manuel-domke]

Just to add some fuel to the fire:
Yubikey quite recently had an issue with its use of random numbers.
https://www.yubico.com/support/security-advisories/ysa-2019-02/

It's worth noting that only the "FIPS" certified product lines were affected, which tells a lot about those security certifcations...

Even more fuel: https://www.zdnet.com/article/major-hsm-vulnerabilities-impact-banks-cloud-providers-governments/

A general problem is probably the high re-certification cost, resulting in lack of updates!
Long live open-source security hardware!