Security recommendations for any device that depends on random numbers (2013)
1–10 of 12 posts
Re: Security recommendations for any device that depends on random numbers (2013)
#2Btw, are there any hardware TRNGs like EntropyKey that have a keyed-encrypted channel (either PCIe or USB)? I was looking at Quantis, ComScire CryptoStrong, TrueRNG v3, TrueRNGPro, OneRNG, and the Linux hw_random source tree and haven't found anything similar. [0] EK was such an interesting product.
0. https://github.com/torvalds/linux/tree/master/drivers/char/h...
Re: Security recommendations for any device that depends on random numbers (2013)
#3Btw, are there any hardware TRNGs like EntropyKey that have a keyed-encrypted channel (either PCIe or USB)? I was looking at Quantis, ComScire CryptoStrong, TrueRNG v3, TrueRNGPro, OneRNG, and the Linux hw_random source tree and haven't found anything similar. [0] EK was such an interesting product. 0. https://github.com/torvalds/linux/tree/master/drivers/char/h...
This:
is not exactly what you're looking for out of the box, but it's open-source and it includes a HWRNG, so you could make it do what you want with some custom firmware. I would be happy to discuss a custom development for you if you don't want to do it yourself.
Disclosure: the SC4-HSM is my product.
Re: Security recommendations for any device that depends on random numbers (2013)
#4> In particular, suppose you are administering a remote machine, so that you don’t have access to the USB ports or the audio ports. It is entirely possible that there is no good way to install sufficient randomness. You need to prevail upon whoever has access to the remote machine and get them to provide something, perhaps a random seed file, or a virtual /dev/hwrng, or a real hardware-based solution (using the audio system or otherwise). If they can’t or won’t do that, you can plan on being hacked.
This is especially true for embedded systems, that often cannot provide good randomness due to extreme adversarial settings.
Smart cards will have anti-tamper true-random number generators (random number generators that are hardware-based). And even that is shady.
Re: Security recommendations for any device that depends on random numbers (2013)
#5Btw, are there any hardware TRNGs like EntropyKey that have a keyed-encrypted channel (either PCIe or USB)? I was looking at Quantis, ComScire CryptoStrong, TrueRNG v3, TrueRNGPro, OneRNG, and the Linux hw_random source tree and haven't found anything similar. [0] EK was such an interesting product. 0. https://github.com/torvalds/linux/tree/master/drivers/char/h...
This: https://sc4.us/hsm/index.html is not exactly what you're looking for out of the box, but it's open-source and it includes a HWRNG, so you could make it do what you want with some custom firmware. I would be happy to discuss a custom development for you if you don't want to do it yourself. Disclosure: the SC4-HSM is my product.
I'm not seeing a secure element in there (nor in the uC)... is there one? If not, why not?
Re: Security recommendations for any device that depends on random numbers (2013)
#6Earlier quoted context omitted.
This: https://sc4.us/hsm/index.html is not exactly what you're looking for out of the box, but it's open-source and it includes a HWRNG, so you could make it do what you want with some custom firmware. I would be happy to discuss a custom development for you if you don't want to do it yourself. Disclosure: the SC4-HSM is my product.
I'm not seeing a secure element in there (nor in the uC)... is there one? If not, why not?
There is no secure element but there is a hwrng built in to the SoC.
Re: Security recommendations for any device that depends on random numbers (2013)
#7Btw, are there any hardware TRNGs like EntropyKey that have a keyed-encrypted channel (either PCIe or USB)? I was looking at Quantis, ComScire CryptoStrong, TrueRNG v3, TrueRNGPro, OneRNG, and the Linux hw_random source tree and haven't found anything similar. [0] EK was such an interesting product. 0. https://github.com/torvalds/linux/tree/master/drivers/char/h...
What advantage do you expect go gain vs not encrypting the channel and then encrypting the entropy (with the same key) when you receive it?
If the bus snooping attacker can break the encryption he could do so with the over the wire copy too.
Is it a question of _authenticating_ the data from the device? If so-- avoiding the case where the bus attacker would replay randomness would require great care in protocol design.
Re: Security recommendations for any device that depends on random numbers (2013)
#8Earlier quoted context omitted.
I'm not seeing a secure element in there (nor in the uC)... is there one? If not, why not?
There is no secure element but there is a hwrng built in to the SoC.
So it isn't an HSM.
Calling a device an HSM comes with an expectation that it will resist tampering or intensive analysis. A standard microcontroller on an exposed PCB cannot fulfill that expectation.
Re: Security recommendations for any device that depends on random numbers (2013)
#9Earlier quoted context omitted.
There is no secure element but there is a hwrng built in to the SoC.
So it isn't an HSM. Calling a device an HSM comes with an expectation that it will resist tampering or intensive analysis. A standard microcontroller on an exposed PCB cannot fulfill that expectation.
It is an HSM notwithstanding that it does not contain a separate component marketed as a secure element. The SoC is not a "standard microcontroller" (well, it is, but not in the sense that you mean it here). The STM32F405RG has security features built in designed to secure proprietary firmware against industrial espionage. The same hardware features can be used to secure keys. I'd be happy to provide you with additional details, but I'd suggest starting by reading the documentation of the SC4-HSM and the the SoC.
Re: Security recommendations for any device that depends on random numbers (2013)
#10If you are interested in subject of high quality random sources, you may find this useful: there exists a project named League of Entropy [1] dedicated to reliable generation of public randomness based on group of servers with high-quality random sources (like lava lamps or seismic activity).
These distributed randomness beacon servers can also provide private random data. There exists a project with daemon [2] which collects entropy from distinct sources and produces secure output, which can be used to reseed Linux /dev/random and /dev/urandom. It may be useful for devices without reliable HW RNG.