5 ms·

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being

If the avalanche diode is the main/primary source of entropy why do we need the CC2531? The super paranoid part of me is worried about the 802.15.4 radio being used as a vector to taint the RNG. Shouldn't an HW RNG NOT have any secondary communication method built in? I am guessing you guys added that because that's the platform you're working with for your IOT project, but it just seems a little overkill to me. The diode data acquisition and the USB comms could be easily done using any Cortex-M0 type micro.

Taniwha 12y ago
I think that's a fair point, I agonized over it for quite a while - the cc2531 was the USB device/ and stack I was building with at the time. This is the main reason why by default the device disables the RF source, you have to go out of your way to enable it by editing an /etc .conf file - however it actually does make a slightly better random stream
- WaywardGeek 12y ago
  Is it possible for this device to transmit over radio, or only receive? I certainly prefer only being able to receive, as transmitting seems like an attack vector. With the assumption that it only receives, I would strongly prefer that it be left on by default. Adding a second source to the CRC mixing can only improve entropy, even if the source is controlled by an attacker. Since the noise from the zener has no simple proof of it's entropy output rate, and it can vary over time, and because zener noise TRNGs have been known to be power-supply noise sensitive (not that your's is), having that second source gives me much more confidence in the device.
  - Taniwha 12y ago
    It could transmit, there is no transmit code in the firmware, in fact there's no real receive code, we turn on the receiver and sample the LSB of RF noise in the sampling DACs but don't enable any demodulation or framing. Turning both RNGs on only gets you a about half a bit/byte of extra entropy - but it is a great belt and braces sort of thing, makes it much harder to attack, especially since the sampling clock inside the device for both sources is not visible eternally Remember we don't use the output data directly, we mix it into the kernel's entropy pool (where it's whitened)
deleted 12y ago
[deleted]
rsync 12y ago
Look, I hate to be a wet blanket here, but this device cannot contain a radio. I don't care how trustworthy everyone involved is or how closely we all look at it. "Shouldn't an HW RNG NOT have any secondary communication method built in?" Yes, that would indeed be a best practice. Seriously. A radio. And not just any radio, but a software programmable, general purpose 802.x radio with a published spec, etc.
- WaywardGeek 12y ago
  Just throwing it out there... if the radio is a problem, I'd love for Paul and friends to replace both the radio and avalanche source with an "infinite noise multiplier", which I feel is more secure than either alone, but probably not as secure as these two very different sources together. However, that would delay things quite a bit. I'm hoping maybe version 2. Also, the wider community has zero experience with INMs, so it will take a while before such a source is generally accepted. Also, this concern about the radio requires someone to 1) hack the TRNG, and 2) have a nearby receiver. At that point, they probably could more easily just PWN your system, and forget about the TRNG. Paul is doing some clever things to make it very hard to hack his firmware, but a keyboard logger is still easy for an attacker with physical access, as is any number of attacks.

Taniwha 12y ago

I think that's a fair point, I agonized over it for quite a while - the cc2531 was the USB device/ and stack I was building with at the time. This is the main reason why by default the device disables the RF source, you have to go out of your way to enable it by editing an /etc .conf file - however it actually does make a slightly better random stream

WaywardGeek 12y ago
Is it possible for this device to transmit over radio, or only receive? I certainly prefer only being able to receive, as transmitting seems like an attack vector. With the assumption that it only receives, I would strongly prefer that it be left on by default. Adding a second source to the CRC mixing can only improve entropy, even if the source is controlled by an attacker. Since the noise from the zener has no simple proof of it's entropy output rate, and it can vary over time, and because zener noise TRNGs have been known to be power-supply noise sensitive (not that your's is), having that second source gives me much more confidence in the device.
- Taniwha 12y ago
  It could transmit, there is no transmit code in the firmware, in fact there's no real receive code, we turn on the receiver and sample the LSB of RF noise in the sampling DACs but don't enable any demodulation or framing. Turning both RNGs on only gets you a about half a bit/byte of extra entropy - but it is a great belt and braces sort of thing, makes it much harder to attack, especially since the sampling clock inside the device for both sources is not visible eternally Remember we don't use the output data directly, we mix it into the kernel's entropy pool (where it's whitened)

deleted 12y ago

[deleted]

rsync 12y ago

Look, I hate to be a wet blanket here, but this device cannot contain a radio. I don't care how trustworthy everyone involved is or how closely we all look at it. "Shouldn't an HW RNG NOT have any secondary communication method built in?" Yes, that would indeed be a best practice. Seriously. A radio. And not just any radio, but a software programmable, general purpose 802.x radio with a published spec, etc.

WaywardGeek 12y ago
Just throwing it out there... if the radio is a problem, I'd love for Paul and friends to replace both the radio and avalanche source with an "infinite noise multiplier", which I feel is more secure than either alone, but probably not as secure as these two very different sources together. However, that would delay things quite a bit. I'm hoping maybe version 2. Also, the wider community has zero experience with INMs, so it will take a while before such a source is generally accepted. Also, this concern about the radio requires someone to 1) hack the TRNG, and 2) have a nearby receiver. At that point, they probably could more easily just PWN your system, and forget about the TRNG. Paul is doing some clever things to make it very hard to hack his firmware, but a keyboard logger is still easy for an attacker with physical access, as is any number of attacks.