8000 Stirring in entropy · Issue #154 · solokeys/solo1 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Stirring in entropy #154

New issue
8000

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
nickray opened this issue Mar 26, 2019 · 9 comments
Open

Stirring in entropy #154

nickray opened this issue Mar 26, 2019 · 9 comments
Assignees
@nickray

Comments

@nickray
Copy link
Member
nickray commented Mar 26, 2019 •
edited
Loading

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
@nickray nickray self-assigned this Mar 26, 2019
@manuel-domke
Copy link
manuel-domke commented Mar 26, 2019 •
edited
Loading

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
Copy link
Member Author
nickray commented Mar 26, 2019 •
edited
Loading

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 😁

@manuel-domke
Copy link
manuel-domke commented Mar 26, 2019 •
edited
Loading

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
Copy link
Member Author
nickray commented Mar 26, 2019

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
Copy link
Member
conorpp commented Mar 27, 2019

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
Copy link
Member Author
nickray commented Mar 27, 2019 •
edited
Loading

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
Copy link
manuel-domke commented Mar 28, 2019 •
edited
Loading

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
Copy link
Member Author
nickray commented Apr 2, 2019

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 solokeys/solo1-cli#18 now.

@manuel-domke
Copy link

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!

@nickray nickray mentioned this issue Jul 8, 2019
Closed
@nickray nickray mentioned this issue Aug 7, 2019
Open
@0x0ece 0x0ece closed this as completed Nov 3, 2019
@nickray nickray reopened this Nov 4, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nickray nickray

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@nickray @0x0ece @conorpp @manuel-domke
0