> When a new hardware RNG is registered by the kernel, it is used right away to add entropy to the system.
If I understand correctly, the new hwrng will be used immediately if there's no current active hwnrg or if the new hwrng quality is greater than the current active one and no userspace hwrng was set [0].
Also the "it is used right away" link is pointing to [1], but I'm wondering if it should not be pointing to [2] instead?
You wouldn't XOR-combine, you would hash them together. Something like:
SHA256(32B from HWRNG-A || 32B from HWRNG-B)
still guarantees you 32 bytes of entropy if either HWRNG-A or HWRNG-B is compromised, and if HWRNG-A and HWRNG-B are both partially compromised you also get 32 bytes of entropy. XOR has weird failure modes (eg if HWRNG-A and HWRNG-B are correlated).
If you're looking to run software in a Nitro Enclave but work with it like a docker container or a Kubernetes pod, check out https://github.com/edgebitio/enclaver
I wish the article actually talked about the interesting nitro enclave specific features more. A lot of it just talks about the basic hardening of a Linux VM and writing secure applications.
> uncovering potential bugs that could compromise even these hardened environments
This seems to be a sensationalized statement. Apart from "trusting a black box" they didn't actually indicate an actual weakness, stating side-channel attacks as the obvious attack vector.
Not explicitly; they're a black box with a stated security model where you trust the hypervisor (vs SEV-SNP where you can get some guarantees against it), and attestation in Nitro is built around PCRs rather than the SEV-SNP launch measurement system which is built around VM state.
As the editor of this blog, I can assure you that AI did not craft the introduction. As a general rule, we include all the most relevant details in the above-the-fold section, allowing readers to quickly determine if the content warrants their time. This is consistent across all our blog posts.
Great article!
> When a new hardware RNG is registered by the kernel, it is used right away to add entropy to the system.
If I understand correctly, the new hwrng will be used immediately if there's no current active hwnrg or if the new hwrng quality is greater than the current active one and no userspace hwrng was set [0].
Also the "it is used right away" link is pointing to [1], but I'm wondering if it should not be pointing to [2] instead?
- [0] https://elixir.bootlin.com/linux/v6.11/source/drivers/char/h...
- [1] https://elixir.bootlin.com/linux/v6.11/source/drivers/char/h...
- [2] https://elixir.bootlin.com/linux/v6.11/source/drivers/char/h...
It's curious that only one HWRNG can be current at once.
Because adding more sources of randomness, even if they're lower quality, can't reduce the total randomness.
If the quality of HWRNG-A is 400 and HWRNG-B is 600, the quality of XOR(HWRNG-A, HWRNG-B) will be greater than 600.
You wouldn't XOR-combine, you would hash them together. Something like:
SHA256(32B from HWRNG-A || 32B from HWRNG-B)
still guarantees you 32 bytes of entropy if either HWRNG-A or HWRNG-B is compromised, and if HWRNG-A and HWRNG-B are both partially compromised you also get 32 bytes of entropy. XOR has weird failure modes (eg if HWRNG-A and HWRNG-B are correlated).
Is that a bit-wise OR? That seems like it would greatly reduce entropy. The probability of any given bit in A | B being 1 is 75%.
That is correct. By default, the new hardware RNG should be used. I'm surprised that this is actually a problem that trail of bits mentioned.
If you're looking to run software in a Nitro Enclave but work with it like a docker container or a Kubernetes pod, check out https://github.com/edgebitio/enclaver
I wish the article actually talked about the interesting nitro enclave specific features more. A lot of it just talks about the basic hardening of a Linux VM and writing secure applications.
> uncovering potential bugs that could compromise even these hardened environments
This seems to be a sensationalized statement. Apart from "trusting a black box" they didn't actually indicate an actual weakness, stating side-channel attacks as the obvious attack vector.
Can these use hardware support like SEV-SNP?
Not explicitly; they're a black box with a stated security model where you trust the hypervisor (vs SEV-SNP where you can get some guarantees against it), and attestation in Nitro is built around PCRs rather than the SEV-SNP launch measurement system which is built around VM state.
This is a very well-written article full of useful links.
WELL documented and a great read gents.
Why is the first section written by AI?
As the editor of this blog, I can assure you that AI did not craft the introduction. As a general rule, we include all the most relevant details in the above-the-fold section, allowing readers to quickly determine if the content warrants their time. This is consistent across all our blog posts.