Public Randomness-Based Random Number Generator using Mobile Phone?

Question

I have an idea to create a True Random Number Generator that use randomness source from a smartphone sensors. My idea is to collect sensors data from a lot of smartphone using mobile apps and then the data is sent to the server to be processed using an algorithm to generate random number.

Is it a good idea to use that method to generate random number? and will it be better using a lot of device rather than just using one device only to generate random number? Can I call that method as Mobile sensor network?

Answer 1

Be careful about the phrase “True Random Number Generator”. There's a bit of hype in that phrase. You do not need to use a TRNG directly to do things like generate cryptographic keys — in fact, you should not, because all TRNG have biases, because even if the underlying physical process has a truly uniform probability distribution, it's impossible to build a perfect measurement apparatus. A good random number generator for cryptography is always hybrid: a cryptographically secure pseudo-random number generator ((CS)PRNG, also called a deterministic random bit generator ((CS)DRBG)), which is seeded by one or more entropy sources. A physical device whose purpose is to serve as an entropy source is sometimes called a “TRNG”, but a less misleading name is HRNG (hardware random number generator).

An entropy source needs to have two properties:

1. It needs to be unpredictable. It needs to depend on a physical process whose outcome cannot be predicted in advance. This is typically a either a chaotic physical process or a process with physically theorized unpredictability such as radioactive decay.
2. It needs to remain unpredictable even after the fact, i.e. its output needs to remain secret. An entropy source is no good if it's public. If your adversary can construct the same system state as you because they can read the same entropy sources, then they can generate the same keys that you're generating.

Obtaining entropy from outside is dodgy because it violates the second property. You have no way to know that the data you're collecting from smartphones is actually coming from a HRNG, and even if it is, you have no way to know that it's only sent to you and not leaked to anyone else.

Fortunately, if you do things right, then when you mix entropy sources, a bad source (not sufficiently random or not sufficiently secret) doesn't hurt: it'll contribute 0 to the total entropy of your system, but it won't nullify other, good entropy sources. So assuming that your server-side code is perfect and that at least one of your entropy sources is good, then the result is ok. The flaw in this argument is that code is never perfect.

All modern server hardware has a built-in HRNG. (If you don't trust it, you have no reason to trust the rest of the processor. So “I fear a backdoor in the processor's RNG” is not a valid argument.) Collecting additional entropy from outside has no benefit. It's a lot of infrastructure, meaning a lot of failure points and a large attack surface, for no benefit.

Gathering entropy in a distributed way like this does have a benefit for a very specific application: when you want to generate a public value which should be demonstrably random. In that case, allowing everyone to contribute their entropy, and using a public, deterministic way to combine all the submissions, does result in a demonstrably random value.

Answer 2

In theory yes it can work. There is precedent for this with:

• True random numbers generated by sensors
• Entropy of Androids motion-sensor data
• Towards True Random Number Generation in Mobile Environments (PDF)

So you can use the camera, accelerometer, compass and speaker. It think that there's even a horizontal level sensor in some phones. But there are three main obstacles that you'll have to overcome.

1. A golden standard true random number generator requires that (entropy in) > (entropy out). And usually by a lot more, say a factor of 4. Measurement of entropy is hard. There is NIST Special Publication 800-90B, Recommendation for the Entropy Sources Used for Random Bit Generation. See section 6. You'll spend for ever trying to use it properly, and in the end it's easier to simply use a compression tool like a PAQ derivative and divide by a safetly factor of 2. If you can't measure it, you can't manage it.

2. With initialisation, you get a form of warming up of the entropy sources. The entropy rate will measure as a lot lower until the sensors (and the person sporting the phone) settle down in some sort of routine. This will make restart testing a nightmare if you follow section 3.1.4 from the above NIST document.

3. Entropy sources have a nasty habit of slowly changing their parameters wrt time. The entropy generation rate will change drastically depending on whether the phone is at an exciting football match or in a quiet room whilst you meditate. Or the sensors can simply break when you drop the phone or get beer in the microphone. Don't forget that accelerometers are actually flexing mechanical devices (albeit made from semiconductor), with similar frailties to any moving instrument.

In summary, no one uses a mobile phone as a reliable TRNG. I guess it would be okay to generate one AES key after a day's play on a bouncy castle (get it?), but otherwise it will be very unreliable. Interconnecting several phones into a network will be equally unreliable as you'll have little control over what all the phones are doing. One might be down the toilet bowl. And you'd also have to transmit the entropy over the airwaves which are easily intercepted by either the network provider, or covert police network towers. Never transmit your entropy to no one.

Stick to a few Zener diodes and an Arduino. A reliable 10 kbits/s of true ransom bits is achievable with a little wiring and a few components. This is more than sufficient for personal one time pads and all the AES keys you'll ever need.