OneRNG – Open Hardware Random Number Generator(onerng.info)
onerng.info
OneRNG – Open Hardware Random Number Generator
http://onerng.info/
16 comments
Back about 25 years ago I wanted to build a PC card to generate better random numbers. The idea I had at the time was to build in a set of four or five FM/AM radio receivers into this card and have them hop ratio stations constantly at, well, random intervals. Then I'd use the digitized audio signals in some combination to feed a random number generator. I thought it was a good idea at the time. Well, I didn't have enough experience yet to know just how much I didn't know. Never built it.
On a related note, is there any device out there that lets you create a private key and "burn" it to that device in a way that the key cannot be taken off the device and you instead use the device the same way you use SSH_AUTH_SOCK?
Ultimately, it would be nice to have a way where private keys can not be copied.
Ultimately, it would be nice to have a way where private keys can not be copied.
Total layman question here, but how does an avalanche diode work?
That's awfully complicated for a hardware RNG. A channel-hopping receiver? The classic solution is a radiation source, which quantum mechanics says is random.
http://www.fourmilab.ch/hotbits/hardware3.html
http://www.fourmilab.ch/hotbits/hardware3.html
From the same site, quantitative analysis:
"The chi-square test is the most commonly used test for the randomness of data, and is extremely sensitive to errors in pseudorandom sequence generators. The chi-square distribution is calculated for the stream of bytes in the file and expressed as an absolute number and a percentage which indicates how frequently a truly random sequence would exceed the value calculated. We interpret the percentage as the degree to which the sequence tested is suspected of being non-random. If the percentage is greater than 99% or less than 1%, the sequence is almost certainly not random. If the percentage is between 99% and 95% or between 1% and 5%, the sequence is suspect. Percentages between 90% and 95% and 5% and 10% indicate the sequence is “almost suspect”. Note that our JPEG file, while very dense in information, is far from random as revealed by the chi-square test.
Applying this test to the output of various pseudorandom sequence generators is interesting. The low-order 8 bits returned by the standard Unix rand() function, for example, yields:
"The chi-square test is the most commonly used test for the randomness of data, and is extremely sensitive to errors in pseudorandom sequence generators. The chi-square distribution is calculated for the stream of bytes in the file and expressed as an absolute number and a percentage which indicates how frequently a truly random sequence would exceed the value calculated. We interpret the percentage as the degree to which the sequence tested is suspected of being non-random. If the percentage is greater than 99% or less than 1%, the sequence is almost certainly not random. If the percentage is between 99% and 95% or between 1% and 5%, the sequence is suspect. Percentages between 90% and 95% and 5% and 10% indicate the sequence is “almost suspect”. Note that our JPEG file, while very dense in information, is far from random as revealed by the chi-square test.
Applying this test to the output of various pseudorandom sequence generators is interesting. The low-order 8 bits returned by the standard Unix rand() function, for example, yields:
Chi square distribution for 500000 samples is 0.01, and randomly would exceed this value more than 99.99 percent of the times.
Chi square distribution for 500000 samples is 212.53, and randomly would exceed this value 97.53 percent of the times.
Chi square distribution for 500000 samples is 249.51, and randomly would exceed this value 40.98 percent of the times. "
Maybe it is more complicated as a concept, but the implementation is much more simple. They're using a MCU with integrated radio, it's almost free to add the RF source to the base system only using the avalanche diode.
A HV geiger tube and embedding a radiation source would be much more complicated / expensive to build, especially on small scale.
A HV geiger tube and embedding a radiation source would be much more complicated / expensive to build, especially on small scale.
The channel hoping is just a bit of software. It costs $0.00 in additional hardware. Software complexity is a big deal in a TRNG. The KISS rule applies big-time here. The more complex the software, the more likely it is a significant flaw will be found and exploited. It remains unclear to me whether there should even be a microcontroller on a USB TRNG. Without one, we can eliminate the complexity from the USB key itself, but we have to move the whitening and health monitoring to the driver. It is unclear to me if making the driver more complex opens it up to enough additional attacks that the system is less secure overall.
[deleted]
I'm not sure about you, but I don't really think I'd want to keep even the minor sources of radiation described on that page in my pocket.
It's much much easier to build from cheap parts than something with a radiation source.
What part is in fact that complicated?
Well, I'm happy to see that for once, they understand that the single most important thing is that it's verifiable.
So many crypto-related systems ask you to trust the provider implicitly it's not even funny.
I don't care who you are, if I can't look at the source (all the way down) of your product and build it myself, it's not going to make the cut as a "secure" system. You can provide additional guarantees and proofs, but showing me the source is item number 0.
Sure, it's not perfect, but it's much closer to perfect than any alternatives.
So many crypto-related systems ask you to trust the provider implicitly it's not even funny.
I don't care who you are, if I can't look at the source (all the way down) of your product and build it myself, it's not going to make the cut as a "secure" system. You can provide additional guarantees and proofs, but showing me the source is item number 0.
Sure, it's not perfect, but it's much closer to perfect than any alternatives.
> if I can't look at the source (all the way down) of your product and build it myself, it's not going to make the cut as a "secure" system
Other have already linked to https://www.fourmilab.ch/hotbits/hardware3.html and if your biggest concern is verifying it, then what could be simpler than detecting radioactive decay events?
Other have already linked to https://www.fourmilab.ch/hotbits/hardware3.html and if your biggest concern is verifying it, then what could be simpler than detecting radioactive decay events?
> You can provide additional guarantees and proofs, but showing me the source is item number 0.
And item number 0.5 is allowing me to build the source and upload it to a pristine EEPROM chip.
And item number 0.5 is allowing me to build the source and upload it to a pristine EEPROM chip.
as part of our kickstarter we'll be offering programmers as an added reward - you can build the image from source and program your device - and we hope you do and share the results with the world
You can't program it over the USB (although we could) we consider that that would be a security problem - and given recent security issues with programmable USB devices ....
You can't program it over the USB (although we could) we consider that that would be a security problem - and given recent security issues with programmable USB devices ....
Oh, I was considering that as part of the "build it myself" point, but yeah, totally.
A good CS-PRNG can take a modest amount of entropy and store it in a way (internal state) that you trust it can't be recovered by the attacker. From this they can generate a nearly endless supply of random output. That, as I understand it, is /dev/random vs. /dev/urandom/.
So it's nice to have a good reliable source of entropy, but you can also consider how protected is the internal state, aka the place you stick that entropy? The better protected the CS-PRNG state, the less entropy you actually need.
If you trust the CS-PRNG state, then hardware entropy sources won't matter much to you, because you just don't need that much entropy. When you start streaming entropy from many sources, it's probably to consistently update internal state over time because you don't fully trust that the state is secure.
It should make no difference either way in the quality of the output (directly pulling entropy versus CS-PRNG output). Because the necessary amount of output to reverse-engineer state is almost infinite, the output of a properly implemented CS-PRNG is highly trusted. And they're really nice algorithms that have well reviewed implementations.
So it's nice to have a good reliable source of entropy, but you can also consider how protected is the internal state, aka the place you stick that entropy? The better protected the CS-PRNG state, the less entropy you actually need.
If you trust the CS-PRNG state, then hardware entropy sources won't matter much to you, because you just don't need that much entropy. When you start streaming entropy from many sources, it's probably to consistently update internal state over time because you don't fully trust that the state is secure.
It should make no difference either way in the quality of the output (directly pulling entropy versus CS-PRNG output). Because the necessary amount of output to reverse-engineer state is almost infinite, the output of a properly implemented CS-PRNG is highly trusted. And they're really nice algorithms that have well reviewed implementations.
Yeah, but you have a reliable source of entropy you don't need to get a lot of random numbers from your CSPRNG before reseeding.
This seems sound. However, I'm in doubt about some of their points:
> You can ask it to dump the current firmware to you
It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it?
> You can see all the components on the board
The fact that I can see these tiny thingies doesn't do much good either? Can I, seeing them, tell what they do? No.
Building one of these yourself seems to solve both problems. Not trying to undermine it or anything, just curious what others think of it.
> You can ask it to dump the current firmware to you
It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it?
> You can see all the components on the board
The fact that I can see these tiny thingies doesn't do much good either? Can I, seeing them, tell what they do? No.
Building one of these yourself seems to solve both problems. Not trying to undermine it or anything, just curious what others think of it.
Note: I'm Paul the designer
You're completely right someone could put some other firmware on the image but have it return the correct one - we solve this by:
- padding the image to the size of the ROM (256k, the runtime image is ~10k)with random data making it incompressible - signing the image (including the random bit) so that the image can't be altered
On a linux system the udev install script kicks off a process that starts with verification of the firmware image and finishes with putting it into service if verification passes.
This is open hardware - you can program it yourself, we'll be releasing both the hardware design and all the software in a little while - along with programmer for doing it - you just wont be able to create an image signed by us - but you can sign images and share them with your friends.
Note: what you can't do is program the device over the USB
As far as lifting the lid and verifying what's underneath is concerned we don't expect every user to open it and look at the board and understand how it works (we hope some people will and will verify our work) - but what you can do is look under there and verify that the board looks the same as images that we publish.
You're completely right someone could put some other firmware on the image but have it return the correct one - we solve this by:
- padding the image to the size of the ROM (256k, the runtime image is ~10k)with random data making it incompressible - signing the image (including the random bit) so that the image can't be altered
On a linux system the udev install script kicks off a process that starts with verification of the firmware image and finishes with putting it into service if verification passes.
This is open hardware - you can program it yourself, we'll be releasing both the hardware design and all the software in a little while - along with programmer for doing it - you just wont be able to create an image signed by us - but you can sign images and share them with your friends.
Note: what you can't do is program the device over the USB
As far as lifting the lid and verifying what's underneath is concerned we don't expect every user to open it and look at the board and understand how it works (we hope some people will and will verify our work) - but what you can do is look under there and verify that the board looks the same as images that we publish.
padding the image to the size of the ROM (256k, the runtime
image is ~10k)with random data making it incompressible -
signing the image (including the random bit) so that the
image can't be altered
Why not pad it with something that's already compressed, but which has information content, like a nice jpeg or something?
well you have to consider me (the designer, the guy putting the original code in the device that you want to verify and make sure that it's not someone else's code) as trustworthy. After all I'm the one who's trying to protect the integrity of my product, I'm not going to give you a compressible bitstream if I can possible help it - and I'm going to publish the bitstream I am using so you can check
I think the parents point is that you generated the random-bitstream somehow, starting from a specific seed. If you know the seed, you could regenerates the random bitstream with a lot less bytes (=secretly compressible).
So now you have some extra room left on the ROM to embed your malicious firmware and still be able to dump the original full 256k.
If you start with a known image/photo (not yours, some public domain), that after encryption/compression is exactly the amount of padding you need (or cut-off), you have your padding-bitstream that is a lot harder to regenerate from a seed.
Edit: clarification
So now you have some extra room left on the ROM to embed your malicious firmware and still be able to dump the original full 256k.
If you start with a known image/photo (not yours, some public domain), that after encryption/compression is exactly the amount of padding you need (or cut-off), you have your padding-bitstream that is a lot harder to regenerate from a seed.
Edit: clarification
Glad you asked - we have a book [1][2] for this, at least up to 405.5 KiB.
[1] http://en.wikipedia.org/wiki/A_Million_Random_Digits_with_10...
[2] http://www.amazon.com/Million-Random-Digits-Normal-Deviates/...
[1] http://en.wikipedia.org/wiki/A_Million_Random_Digits_with_10...
[2] http://www.amazon.com/Million-Random-Digits-Normal-Deviates/...
or we could use a hardware RNG ..... and run it through a whitener just to make it more interesting ....
The point is - you can verify it yourself. Without trusting anybody else.
Dumping the firmware means you can ensure it's not been modified (presumably from when you uploaded it to the device yourself).
Being able to inspect components means you can ensure it's still exactly as you built it. And if you haven't, you can visually check that it does what it says it does.
If you're not technically competent to make this verification, you can ask somebody you trust and who is to do it for you.
Dumping the firmware means you can ensure it's not been modified (presumably from when you uploaded it to the device yourself).
Being able to inspect components means you can ensure it's still exactly as you built it. And if you haven't, you can visually check that it does what it says it does.
If you're not technically competent to make this verification, you can ask somebody you trust and who is to do it for you.
None of the images show the other side of the board, but unless every trace is visible, it will be difficult to non-destructively inspect. If its only a 2 layer board then this just means scratching off the white silkscreen, which wouldn't be too bad. If its more than 2 layers, you would have to have access to an X-ray machine.
it's a two layer board - no buried wires or vias - by design there are very few wires on the bottom layer, none under the noise source (we want to contain the noise) - you can see all the wires without removing the solder mask just by holding it in the right light
we'll be publishing the layout files of course
we'll be publishing the layout files of course
How do we verify the internal microcode and switch fabric of the TI CC2531?
IMO it seems like simply trusting the large block diagram that says "USB PHY" is a very weak point in the design.
IMO it seems like simply trusting the large block diagram that says "USB PHY" is a very weak point in the design.
Still, a USB phy is required. How would you solve this problem? Would a FTDI USB chip be more palatable?
Who knows. Perhaps a Verilog implementation on an FPGA? Discrete gates and GPIOs galore?
Sarcasm and FTDI chips aside, I'm hoping the point was clear. Guess it wasn't.
Using USB as the physical transport from dongle to CPU just introduces more black boxes in a system where everyone was bragging about no black boxes. But since we're past the age of parallel ports and discrete GPIOs on these machines, there doesn't seem to be an easy answer.
Sarcasm and FTDI chips aside, I'm hoping the point was clear. Guess it wasn't.
Using USB as the physical transport from dongle to CPU just introduces more black boxes in a system where everyone was bragging about no black boxes. But since we're past the age of parallel ports and discrete GPIOs on these machines, there doesn't seem to be an easy answer.
> It can dump the firmware but it can still execute something else than this (or in addition to) this firmware, can't it?
Well, of course, in theory. In practice the total amount of firmware space is limited. It's rather large, as these things go, at 256 or 512 KB depending on the exact model.
If it dumps a firmware close to that size, which passes scrutiny by several people, I would say that the risk that the chip still manages to contain a firmware which creates bad random data and a fake firmware is rather slim.
Of course it's not impossible, and if you made it a contest (which, perhaps it is to some people) I'm sure it could be done.
It's hard to trust digital systems of this complexity; what if you decide you don't trust TI (the makers of the microcontroller) in the first place, for instance? Building your own processor at this performance and size level isn't trivial.
Well, of course, in theory. In practice the total amount of firmware space is limited. It's rather large, as these things go, at 256 or 512 KB depending on the exact model.
If it dumps a firmware close to that size, which passes scrutiny by several people, I would say that the risk that the chip still manages to contain a firmware which creates bad random data and a fake firmware is rather slim.
Of course it's not impossible, and if you made it a contest (which, perhaps it is to some people) I'm sure it could be done.
It's hard to trust digital systems of this complexity; what if you decide you don't trust TI (the makers of the microcontroller) in the first place, for instance? Building your own processor at this performance and size level isn't trivial.
the actual firmware is far smaller than that (see my explanation about how we pad it out above) - essentially the way you verify it is by compiling the (open) source and getting the same binary image
(and then of course one verifies the source by inspection)
(and then of course one verifies the source by inspection)
> Building one of these yourself seems to solve both problems.
I'd love to see a 3D printer that specifically built verifiably secure hardware.
I'd love to see a 3D printer that specifically built verifiably secure hardware.
Ah, but can you trust the c̶o̶m̶p̶i̶l̶e̶r̶ 3D printer?
Suggestion for modification: Call it OpenRNG instead of OneRNG. In every second sentence i read the word open. Its obviously a main purpose.
I'm curious why they chose to use an avalanche diode which doesn't generate quantum-random numbers, unlike a reverse-biased transistor.
As far as I'm aware, this means you could effect the numbers, by varying temperature.
As far as I'm aware, this means you could effect the numbers, by varying temperature.
https://news.ycombinator.com/item?id=7728216
> This article seems to be talking about using quantum effects for random number generation.
> The devices you point to use the semiconductor avalanche effect (http://en.wikipedia.org/wiki/Avalanche_breakdown) which is a thermal effect.
> > Most noise is quantum noise (including the one quoted, even though electron avalanche is a classic phenomenon, in semiconductors it's going to have quantum effects)
> > But in the end it doesn't matter, any unpredictable, non manipulable source of randomness is fine. Other sources of noise in electrical circuits (apart from quantum noise origins) are interference (like the 60Hz hum, radio interference, and even background radiation)
> This article seems to be talking about using quantum effects for random number generation.
> The devices you point to use the semiconductor avalanche effect (http://en.wikipedia.org/wiki/Avalanche_breakdown) which is a thermal effect.
> > Most noise is quantum noise (including the one quoted, even though electron avalanche is a classic phenomenon, in semiconductors it's going to have quantum effects)
> > But in the end it doesn't matter, any unpredictable, non manipulable source of randomness is fine. Other sources of noise in electrical circuits (apart from quantum noise origins) are interference (like the 60Hz hum, radio interference, and even background radiation)
I doesn't matter.
And being in a semiconductor it is a quantum process (in fact most sources of noise in circuits are quantum in origin - not that it matters)
And being in a semiconductor it is a quantum process (in fact most sources of noise in circuits are quantum in origin - not that it matters)
That's untrue, just because it's a semiconductor, doesn't mean it can't generate data effected by non-quantum properties such as temperature.
"it can't generate data effected by non-quantum properties such as temperature"
And do you think quantum effects are not affected by temperature? REALLY?!
Start here http://ecee.colorado.edu/~bart/book/distrib.htm
And do you think quantum effects are not affected by temperature? REALLY?!
Start here http://ecee.colorado.edu/~bart/book/distrib.htm
actually it is a reverse biased transistor
Aha cool, is the schematic online?
Every TRNG I've seen so far that uses "zener noise" is actually using the reverse breakdown voltage across the emitter-base junction of a cheap NPN transistor. This is a zener diode! The reason this form of zener is used is simply because the fab does not bother to put in any effort to reduce the avalanche noise. Noise like that makes zeners sold as zeners unpopular.
Zener avalanche noise is unpredictable. How is an attacker supposed to guess when the next electron/hole pair is going to be created in the depletion region? Physically, what happens is the emitter-base junction is reverse biased, turning it into a diode that is blocking current from flowing from the emitter to the base. Every once in a while, due to thermal noise and likely quantum effects, an electron jumps up a valence level, creating an electron/hole pair in the middle of the reversed-biased N/P junction, where there is a strong electric field. This launches the electron in one direction and the hole in the other, where they gain speed rapidly. The electron has higher mobility and will gain enough speed to bang into other electron/hole pairs, creating an avalanche of electrons.
There is no known way for anyone to guess when the next avalanche will occur, or how large it will be, so long as there is no outside signal controlling this effect. Implemented poorly, it can just put out power supply noise, and not true unpredictable entropy. Implemented well, it is a solid, reliable, cheap, and fast entropy source. It is absolutely critical that a zener noise TRNG has an open auditable design!
As for "quantum" effects, I consider that marketing fluff. What we need is provable, reliable unpredictability, not some radioactive decay or photon emission. We don't need 100% unbiased unpredictability either, just a signal that cannot be predicted with much accuracy.
Zener avalanche noise is unpredictable. How is an attacker supposed to guess when the next electron/hole pair is going to be created in the depletion region? Physically, what happens is the emitter-base junction is reverse biased, turning it into a diode that is blocking current from flowing from the emitter to the base. Every once in a while, due to thermal noise and likely quantum effects, an electron jumps up a valence level, creating an electron/hole pair in the middle of the reversed-biased N/P junction, where there is a strong electric field. This launches the electron in one direction and the hole in the other, where they gain speed rapidly. The electron has higher mobility and will gain enough speed to bang into other electron/hole pairs, creating an avalanche of electrons.
There is no known way for anyone to guess when the next avalanche will occur, or how large it will be, so long as there is no outside signal controlling this effect. Implemented poorly, it can just put out power supply noise, and not true unpredictable entropy. Implemented well, it is a solid, reliable, cheap, and fast entropy source. It is absolutely critical that a zener noise TRNG has an open auditable design!
As for "quantum" effects, I consider that marketing fluff. What we need is provable, reliable unpredictability, not some radioactive decay or photon emission. We don't need 100% unbiased unpredictability either, just a signal that cannot be predicted with much accuracy.
not yet, the actual RNG circuit is pretty standard - we'll put up the eagle files, along with the software sources, before we open the kickstarter
If it's faster, could you put up a .png of the schematic?
Also, the CC2531 looks like a QFN. Does it come in any hand-solderable packages?
Also, the CC2531 looks like a QFN. Does it come in any hand-solderable packages?
There's an almost current schematic on the "Theory of Operation" page:
http://moonbaseotago.com/onerng/theory.html
few (any?) chips that do 2.5GHz RF come in chips with traditional pins (too much inductance).
QFNs are completely hand solderable (with hot air, solder paste and a pair of tweezers)
http://moonbaseotago.com/onerng/theory.html
few (any?) chips that do 2.5GHz RF come in chips with traditional pins (too much inductance).
QFNs are completely hand solderable (with hot air, solder paste and a pair of tweezers)
> It even has a “tinfoil hat” to prevent RF interference
Isn't this a problem in the US, being against the famous part 15 of the FCC rules:
«Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
Isn't this a problem in the US, being against the famous part 15 of the FCC rules:
«Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation.»
I'm fairly sure that the "accept" does not refer to "absorb without any countermeasures". It's a bit poorly worded.
I think it refers to the fact that if your device fails due to interference below the legal limit it is your problem to fix, not the device that generated the interference.
I think it refers to the fact that if your device fails due to interference below the legal limit it is your problem to fix, not the device that generated the interference.
I always assumed that it refers to the fact that interference under certain limit should not permanently destroy the device even when such interference may cause the device to behave erratically.
You got it in the reverse; the shielding is to ensure conformance. It's part of the device.
Huh, interesting. What's the rationale behind the 2nd condition?
You have to design devices such that they don't fail when subject to interference.
Put a mobile phone near a radio, send a text. You hear some burbling. Imagine that burbling is picked up by an insulin pump - you don't wan the pump to increase or decrease the dose based on that burble.
See also analogue mobile phones which used to affect some gas station pump billing readouts. (CertInly some CB radios used to, whih caused bans, and phones are still banned in some stations today).
Put a mobile phone near a radio, send a text. You hear some burbling. Imagine that burbling is picked up by an insulin pump - you don't wan the pump to increase or decrease the dose based on that burble.
See also analogue mobile phones which used to affect some gas station pump billing readouts. (CertInly some CB radios used to, whih caused bans, and phones are still banned in some stations today).
I think I misread that. It's supposed to mean "this device must be able to accept any interference received"?
Note: I'm Paul the designer
Some background - this board is in late beta testing, we're going to kickstart it and release it (with papers scheduled at a couple of conferences) - it's hitting Hacker News a little early - but keep us in mind when we do finally release to the public - at the moment we haven't published the design - we'll be putting up both the firmware an hardware designs on GitHub when we think it's ready for the public (almost there)
If you want some idea of the code and development system it's largely based on the dev system for out IoT project:
http://www.moonbaseotago.com/cheaprf/
Meanwhile I'm happy to answer questions
Some background - this board is in late beta testing, we're going to kickstart it and release it (with papers scheduled at a couple of conferences) - it's hitting Hacker News a little early - but keep us in mind when we do finally release to the public - at the moment we haven't published the design - we'll be putting up both the firmware an hardware designs on GitHub when we think it's ready for the public (almost there)
If you want some idea of the code and development system it's largely based on the dev system for out IoT project:
http://www.moonbaseotago.com/cheaprf/
Meanwhile I'm happy to answer questions
> we're going to kickstart it and release it
Do you have any timescales for that yet, or are such decisions still heavily dependant on feedback from testing?
Do you have any timescales for that yet, or are such decisions still heavily dependant on feedback from testing?
testing is good, no known roadblocks, we planning on a Decemberish time frame, we think we have a final firmware load at this point.
We have a small pick-and-place machine/etc setup we'll do a small in-house run for those who want to pay a premium for early delivery and then possibly a slower run depending on demand.
We have a small pick-and-place machine/etc setup we'll do a small in-house run for those who want to pay a premium for early delivery and then possibly a slower run depending on demand.
> We have a small pick-and-place machine/etc setup
I've been in at the ground floor of a number of successful hardware startups. One of which had a number of pick and place machines, IR reflow ovens, and all sorts of related manufacturing equipment. So I'm quite familiar with the field.
My very simple, very emphatic advice about a "pick-and-place" machine is: NO NO NO NO NO, a thousand times N0!!!
Maybe it's something you have to do in NZ. But in some other parts of the world, if I blindfolded you and let you stumble around you would probably trip over a pick-and-place machine in about 5 minutes! They're everywhere.
In other words, unless your primary purpose is to bootstrap yourself into being a contract manufacturer, you have absolutely no business owning your own pick-and-place machine.
A design as simple as yours could be manufactured by almost anyone in the world. It's so simple that most of them could do it in their sleep.
Just contract the manufacturing out and be done with it.
Your quixotic effort at stuffing your own boards reminds me of the perhaps apocryphal story of, in the 1970's, WDC designing a chipset that was used in the DEC LSI-11 minicomputer.[1] They had a fab, and in one week they could make enough chips for DEC to sell minicomputers for a year. "Okay, the LSI-11 chips are done. Now WTF do we do with this fab for the other 51 weeks of the year???"
Yeah, in the old days IC fabs were cheap enough that everyone and his brother owned one. And they had large fixed costs. And unless they were utilized around the clock they lost money.
To a large extent stuff like pick-and-place machines are the same. Sure it's orders of magnitude cheaper. But still, maybe it takes you a week or two to build some of your boards. What do you do with your equipment for the other 50 weeks of the year? Is that the business you want to be in?
Of course, if that is the business you want to be in, then OK.
[1] http://en.wikipedia.org/wiki/Western_Digital#1970s
I've been in at the ground floor of a number of successful hardware startups. One of which had a number of pick and place machines, IR reflow ovens, and all sorts of related manufacturing equipment. So I'm quite familiar with the field.
My very simple, very emphatic advice about a "pick-and-place" machine is: NO NO NO NO NO, a thousand times N0!!!
Maybe it's something you have to do in NZ. But in some other parts of the world, if I blindfolded you and let you stumble around you would probably trip over a pick-and-place machine in about 5 minutes! They're everywhere.
In other words, unless your primary purpose is to bootstrap yourself into being a contract manufacturer, you have absolutely no business owning your own pick-and-place machine.
A design as simple as yours could be manufactured by almost anyone in the world. It's so simple that most of them could do it in their sleep.
Just contract the manufacturing out and be done with it.
Your quixotic effort at stuffing your own boards reminds me of the perhaps apocryphal story of, in the 1970's, WDC designing a chipset that was used in the DEC LSI-11 minicomputer.[1] They had a fab, and in one week they could make enough chips for DEC to sell minicomputers for a year. "Okay, the LSI-11 chips are done. Now WTF do we do with this fab for the other 51 weeks of the year???"
Yeah, in the old days IC fabs were cheap enough that everyone and his brother owned one. And they had large fixed costs. And unless they were utilized around the clock they lost money.
To a large extent stuff like pick-and-place machines are the same. Sure it's orders of magnitude cheaper. But still, maybe it takes you a week or two to build some of your boards. What do you do with your equipment for the other 50 weeks of the year? Is that the business you want to be in?
Of course, if that is the business you want to be in, then OK.
[1] http://en.wikipedia.org/wiki/Western_Digital#1970s
It really depends on the demand, I do plan on doing a small run myself - as I said as a kickstarter premium - that lets me test out the manufacturing support hardware (board test and programming jigs) and provide boards really quickly -if the volumes are high enough then yes, we're off to Shenzhen (I was there in May, I'll be back in December)
We have a CHEAP (~$8k) P&P machine, it's great for doing prototypes (you load it with the 10 most common components and hand place the rest) and VERY small production runs (10-20 panelised boards is probably a limit)
We have a CHEAP (~$8k) P&P machine, it's great for doing prototypes (you load it with the 10 most common components and hand place the rest) and VERY small production runs (10-20 panelised boards is probably a limit)
Newb question - The tinfoil hat is to block RF interference but part of the RNG is a channel hopping RF receiver. Those seem contradictory to me.
if you look closely at the pictures of the board
http://onerng.info/img/BoardAndTinfoilHat-800.png
there's a folded dipole under the copyright message sticking out from under the shield
The goal is to keep the internally generated noise inside, and to not couple into the antenna (where we're sampling external noise)
http://onerng.info/img/BoardAndTinfoilHat-800.png
there's a folded dipole under the copyright message sticking out from under the shield
The goal is to keep the internally generated noise inside, and to not couple into the antenna (where we're sampling external noise)
How does it compare to the NeuG? Which entropy source is better?
http://www.gniibe.org/memo/development/gnuk/rng/neug.html
Note: I've only glanced at NeuG, so this is an over-simplified repy. Neug relies on a few different A/D inputs as a noise source. The resolution of the A/Ds is only 12 bits, meaning it is not capable of reliably measuring thermal noise in the system. In any case, it does not seem to be trying to measure voltage on a high impedance node. Therefore the data passed will be power supply noise and other sources of external influence. These potentially can be influenced by an attacker, maybe even remotely. I do like this architecture for a TRNG, and I like that it is open, but I do not believe the creator of NeuG has put nearly the TRNG know-how into this design as OneRNG. Personally, I'm looking forward to signing up on the Kickstarter for OneRNG when it happens.
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.
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.
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
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
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.
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.
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)
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)
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.
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.
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.
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.
[deleted]
Or you could just use a shitty cheap webcam and take the lower bits of each pixel (or one pixel of each 8x8 block if the compression is bad).
The amount of randomness per second webcams generate is pretty insane, it's more than enough to feed the seed of a crypto PRNG function like Fortuna.
The amount of randomness per second webcams generate is pretty insane, it's more than enough to feed the seed of a crypto PRNG function like Fortuna.
There are plenty of decent sources of entropy, like webcams and sound cards. However, they all add parts we don't need, and they don't take any care to design with security in mind. Eventually, a good open hardware TRNG should be cheaper, more reliable, easier to use, and more secure than any of those solutions, IMO.
> they all add parts we don't need
What are you worried about exactly? Space? There are really really tiny cameras for smartphones that are mass-produced, and they are very noisy, which is perfect.
What are you worried about exactly? Space? There are really really tiny cameras for smartphones that are mass-produced, and they are very noisy, which is perfect.
A question for the designers (Paul?) about verifiability. In the software world you can effectively choose from 2 levels of review. You can (1) review the source code of a project and convince yourself it's fine. Or (2) you can assume/hope that experts have done that, download the software, and just verify you have an identical copy of what everyone else is reviewing. (Ideally using signatures of the authors and reviewers.)
Almost everyone who cares does step 2, assuming they do anything at all. Very few people are qualified or bother to review source code, but everyone who performs step 2 can feel pretty safe, as long as a release is big enough that it's getting reviewed by experts.
So, what's the hardware equivalent? If I'm not capable of reviewing the schema of this hardware, but someone I trust says "this is great", how do I at least know the one I bought is identical to the one she/he bought (or built) and reviewed? How do I verify the components? This seems like a difficult problem.
Almost everyone who cares does step 2, assuming they do anything at all. Very few people are qualified or bother to review source code, but everyone who performs step 2 can feel pretty safe, as long as a release is big enough that it's getting reviewed by experts.
So, what's the hardware equivalent? If I'm not capable of reviewing the schema of this hardware, but someone I trust says "this is great", how do I at least know the one I bought is identical to the one she/he bought (or built) and reviewed? How do I verify the components? This seems like a difficult problem.
I'm just brainstorming here ... but couldn't your software perform a test on the expected latencies and error rates of the hardware (on a very deep level) such that any additional (or subtracted) components would alter them in obvious ways ?
I suspect random device variances will screw up the accuracy of your tests.
Would it be possible to publish JTAG scan chain results. This isn't fool proof, any device not connected to the JTAG chain will not show up, and illegal devices may spoof their responses.
the simple answer is that we publish our schematics and layout, just like software
More generally, this is a pretty simple circuit the whole thing fits on a page (and we have a bit by bit explanation of how it works) looking it over is a 5 minute job, the firmware is far more complex.
More generally, this is a pretty simple circuit the whole thing fits on a page (and we have a bit by bit explanation of how it works) looking it over is a 5 minute job, the firmware is far more complex.
You run your "verified" software on hardware, right? How do you know the hardware is verified?
we publish the hardware design - in reality we have to run it on someone's chip, we've picked one that includes among other things AES, we just don't use that stuff, at some point we have to trust the CPU, and we use a CRC32 engine for minor whitening and stirring of our internal entropy pool - but crc32 is easy to verify (while AES is not)
more importantly we've chosen a platform that we think is unlikely to have already subverted by 3 letter agencies
more importantly we've chosen a platform that we think is unlikely to have already subverted by 3 letter agencies
I think the idea is that the components are simple enough in the case that it can be reviewed visually by inspecting the circuit board and comparing it to a signed/verified reference.
The last bit that is missing then is the chip's firmware, but apparently it is possible to get a dump of the firmware, so you can at least ensure it is what you expect.
It will be a pretty interesting problem for cases. How can you both make a case that is practical and lets you inspect components? Maybe encasing the circuit board in transparent resin would work, but then you can't reprogram it anymore (which might be a feature).
EDIT: Oh, that username rang a bell. Hi Chris :) Keybase.io FTW!
The last bit that is missing then is the chip's firmware, but apparently it is possible to get a dump of the firmware, so you can at least ensure it is what you expect.
It will be a pretty interesting problem for cases. How can you both make a case that is practical and lets you inspect components? Maybe encasing the circuit board in transparent resin would work, but then you can't reprogram it anymore (which might be a feature).
EDIT: Oh, that username rang a bell. Hi Chris :) Keybase.io FTW!
But I haven't seen anyone here mention ID Quantique, one of the companies that the "big boys" use for random numbers. They're in Switzerland: http://idquantique.com/
Admittedly not open hardware, but FWIW they claim:
The minor detail about buying from ID Quantique is that their cheapest USB product sells for about 990 euros, or about $1250.[1]
I know it's apples and oranges, but anyone interested in this product should at least be aware of some alternatives.
[1] http://idquantique.com/component/content/article.html?id=83