Since it is well known that combining entropy from statistically independent hardware sources can improve robustness from an information-theoretic and cryptographic perspective in order to improve resilience against hardware failures or partial compromise, I wonder whether it would not only be possible (because it certainly is), but also desirable, to be able to access the raw output stream from the built-in HRNG at the operating system level as well.
The motivation for interested users should be self-evident.
An additional benefit for Nitrokey could be increased demand for its devices.
Is there any specific information available about the hardware used in the various Nitrokey models (since identical hardware alone does not imply either statistical independence or a measurable security benefit)?
A simple table listing the different Nitrokey models and their components (or at least the entropy source used by the HRNG / IC that generates entropy) would be very helpful.
The rationale behind this idea is that quite a few modern PCs have rather weak HRNGs (when you run the relevant tests).
With such a project, users would be able to introduce more entropy into their cryptographically weak systems simply by connecting a few keys via a USB hub.
(I am deliberately omitting the importance of all other components involved, such as power supply and the environment, so as not to unnecessarily complicate the text.)
The intention of my question actually has been to find someone here who already has this information inside his mind. It was certainly not my intention to generate yet another meaningless comment to the internet.
Nice collection of info.
Can you share an example of a modern PC platform that was found to have weak “HRNG”? Ideally with a reference what tests suggest it.
I put “HRNG” into quotes, because very few PC platforms have dedicated hardware RNG, usually the term is used in approximation referring to CPU instructions, which in turn is in theory not far off to what a secure element provides in a certified form. I have not looked in detail of your list, but can imagine the rack-mount Nitrokey hardware HSM2 you list does have dedicated RNG hardware.
To give my 2 cent answer to your question: You can already get random from a secure element RNG of a Nitrokey. The question is more what to use it for. To mix it into an existing random pool, you do need to have very tight control the USB interface is working/not manipulated/interrupts to call it not blocking the system, etc. All that control in turn requires to block the system for other tasks. It’s not an ideal interface for it, particularly to use it in a homebrew “production” mix.
It’s different if you, say, need to generate a key in a situation where you don’t know how reliable the system rng is (e.g. a VM/VPS/Windows - jk). In this case it can get you certainty of a verified source. It’s very different when you use it for its regular use-case - to generate keys on-device (inside the secure element). In this case you can most certainly rely on it doing its function, the capabilities its certification prescribes without external interference.
Since my test runs took place some time ago, I’m afraid I can’t provide any screenshots or other data to substantiate this statement with specific data points. However, anyone can verify these results by running the corresponding tests on their own machines.
I would also be very interested in seeing the results of similar test runs posted here at some point.
The real point is this: My idea would never have come about if the tests hadn’t yielded the expected results.
As for the tests themselves, it’s worth taking some time to explore the GitHub project pico-rng. There you’ll find documentation and references that allow you to gradually work your way to the relevant findings. My personal tests were conducted on an older HP ZBook - admittedly, not exactly modern hardware. On the other hand, given the developments of recent years, particularly those affecting sustainability and our environment, it should be clear that we will need to use our resources much more responsibly in the years ahead. Those resources naturally include computer hardware. Choosing not to use the latest hardware generations should not mean having to compromise even a basic level of security, even if achieving that level is admittedly only possible to a limited extent.
Here is the link to the relevant project:
There you’ll also find references to the entropy tests, which you can easily run yourself.
It should be noted, however, that I consider the overall approach taken by this project to be rather questionable. One tool was removed without prior notice or explanation and converted into a paid version after the project owner had undoubtedly benefited from contributions by the community to improve the software’s quality. In my opinion, that intention should have been communicated openly from the outset. That said, I’m still a Nitrokey fan, although I also believe there is considerable room for improvement.
I am well aware that the idea of using USB-connected Nitrokeys exclusively as random number generators has its limitations. However, the original idea is that it should be possible to use both the Nitrokeys’ primary functionality and their RNG capabilities in parallel—without introducing an additional software layer. At the moment, for example, nitropy can generate a small block of random data. However, this is by no means equivalent to the way standard system entropy sources work on Linux, which applications can access through the kernel’s random devices. That functionality is simply not available in this case.
Of course, Nitrokeys are by no means the only option I have considered. They are simply one possible approach to implementing a project like this. Other secure elements could certainly be used as well. However, in this case everything else—including the connection to the PC—is already in place, allowing the project to get started much more quickly.
This is a project idea that I intend to pursue further. The only limiting factors are the unfortunate fact that each day is limited to 24 hours, along with the biological necessities that require me to spend a significant portion of that time on unavoidable activities such as sleeping.
I see additional entropy from hardware tokens as essential during key generation. Embedded systems or fresh booted VMs/Containers may have inadequate state in the PRNG. In the past there was also an attempt to weaken the Linux kernel RNG. CPU flaws could lead to weaker randomness be it intentionally or because of a bug. By mixing different entropy sources, one could mitigate this so it is considered a good practice e.g. by BSI. For important use cases I would even consider using dice rolls as only source. For crypto wallet seed phrases: low/predictable entropy has been identified as attack vector and people lost money due to that years after they generated their wallets. Just 3 rolls of 20 dices with 20 sides each would get you sufficient entropy for 24 word BIP39 seed phrases to mitigate that.
The Nitrokey HSMs (aka SmartCard-HSM) are all using NXP JCOP with a SmartMX security controller. All build-in RNGs are evaluated as part of the Common Criteria process using AIS-20.
Newer chips (4.x firmware / JCOP4) are rated DRNG.4, while the 3.x series (JCOP3) is rated DRNG.3 and the older 2.x is rated DRNG.2.
You have to somewhat trust the CC process, as very little is published about the internal construction of the RNG. Typically they use a PRNG to seed a DRNG. From personal experience I can tell that the BSI is very picky about RNGs, which is why they are specifically working on the AIS-20 and AIS-34 documents. I would say, if it is good for the BSI, then it should be good for the rest of us as well (unless you are paranoid enough to see a conspiracy behind any government activity).
No. Just a statement that I even use for important crypto operations true sources of randomness that I fully control. The dice rolls are physical, an offline python script then converts them into 24 BIP39 words and then they can be imported into a hardware wallet.
One of the main points of this thread was precisely NOT to rely solely on a single source for generating random data.
If it were actually possible to design randomness in software in such a way that no repetitions were possible, then HRNGs wouldn’t exist. That’s exactly why DPRNGs rely on an HRNG as the source for their initial state (as far as my humble brain has understood it—corrections are always welcome).
After all, using different hardware sources will certainly yield different data, all of which could be combined. That was the basic idea.
Of course, there’s nothing stopping an imßplementor from integrating other sources of randomness in addition to security tokens (sources that react to environmental radiation, various sensors, etc.).
Of course, the implementor would have to make sure that he’s actually using different hardware (ICs) for every single source of data. It would desireable, of course, to know exactly how they work. But maybe starting by taking small steps before trying to run is the way to go.
From personal experience I can tell that the BSI is very picky about RNGs, which is why they are specifically working on the AIS-20 and AIS-34 documents. I would say, if it is good for the BSI, then it should be good for the rest of us as well (unless you are paranoid enough to see a conspiracy behind any government activity).
Well, following the incident described below, I no longer rely on software or hardware certificates, or any other certifications for that matter, but much prefer to rely on hard, measurable facts—just as any scientist should (were it not for the financial dependencies within the scientific community).:
2013–2014 - NSA surveillance affair
After the Snowden revelations, critics argued Germany - including BSI - had underestimated foreign intelligence threats and relied too heavily on U.S. technology. BSI itself was not responsible for NSA operations but was criticized for limited awareness and insufficient defensive capabilities.
History has shown all too often that those in the know are frequently mistaken or have ulterior motives that create dependencies which, quite simply, should not exist if one is to maintain an objective perspective.
You should indeed be very clear about the terminology. You start the thread by implying the tokens have a HRNG of some sort, next compile a helpful overview titled as follows:
and continue to use HRNG as a term, although it remains unclear where the individual classification you use stems from. Did you copy terms like “Certified hardware RNG”, “Integrated hardware TRNG” of technical specifications, marketing material?
For the approach you are taking, to develop a way to utilise different entropy sources to mix into an existing pool, you first need to qualify the existing pool.
For example, a regular base may be a Linux system running a mainline kernel with its associated config. If you settle on the Linux terminology, it is a CSRNG that has config knobs to be turned into a certified DRNG if needed (also why some distros offer FIPS compliant cryptography modules). If you feed additional entropy sources into it, it would usually be a tainted kernel for starters, losing any possible DRNG certification. Nothing to care about too much, since you don’t rely on it. So, your approach is to take entropy from sources that are from a ‘certified’ RNG to mix into a CSRNG pool. Do you see where I am getting at? You can’t “improve” a generated entropy pool, but none of the sources you have available provide true entropy anyway. Your approach appears to be to distort it, so that you don’t run a risk of it being in a controlled state (which is what the Linux kernel does, it controls the state of the entropy pool very closely, across reboots).
Not to complicate it further, you better:
(a) state the platform you use for the project (e.g. on the zbook)
(b) state what the entropy pool you want to generate is going to be used for. It makes a difference for your design from the outset, if it is for an online system that constantly needs new entropy, an air-gapped system (when you could perfectly throw some dice into the mix) to generate secrets.
(c) just use your own RNG terminology for the project, e.g. L(atte)RNG, to avoid ambiguity and the most bikeshedded topic in cryptography (entropy qualification).
Yes, thanks for the link; I’m familiar with that device.
But maybe it’s time to simply set aside all this USB overhead in security-critical areas and finally provide operating systems and applications that rely on good random data with exactly that kind of data directly in memory (via Thunderbolt, PCIe, and IOMMU), rather than struggling with USB shortcomings and USB protocols?
As I understand it, a solution like this could have existed years ago - and perhaps should have - since the necessary features have been available for about a decade, both at the kernel level and on the Thunderbolt side.
At first glance, such an approach seems to make much more sense from a purely technological standpoint than the USB solutions currently available on the market.
