5
$\begingroup$

My app on Android uses the built-in motion sensors to collect seed-data for the PRNG (java.security.SecureRandom) that is later to be used for key-generation. The user is told to shake the device so the incoming data should be somewhat pretty random. Also, too slow movements are ignored in order to avoid getting only 0s as seed if the device was not moved during the time of "recording".

In detail: Teh length of the movement-vector is calculated ($l = sqrt(x^2 + y^2 + z^2)$) and $9.81$ is subtracted from it in order to ignore gravity. If $l$ is less than 81% of the sensors Peek value the set of values is ignored. Otherwise the resulting values for x, y, z are beeing muliplied by $2^{28}$ (because bit-shifting is not supported on floats in Java), then XORed. These values then fill an array like that:

dataStack[dataSetsRecorded++ % dataStack.length] ^= value;

The question is: is that a high entropy or can this be predicted (e.g. because most phone users would shake the phone up and down but not sidewise and tablet users would rather tilt than shake the device)? Thanks :)

Improve this question
$\endgroup$
7
  • 1
    $\begingroup$ Entropy according to whom? In other words, what is your attacker model? Does the attacker have software implanted on the phone? If so, the entropy will be very low. Is the attacker allowed to video record the user shaking their device and take it back to the lab to analyze it, modeling the motion sensor to try to figure out what measurements were generated? Possibly low entropy in this case too. Or is the attacker assumed to not have software on the phone and not be within distance to gather information about the shaking process? $\endgroup$
    – mikeazo
    Mar 5, 2014 at 12:16
  • $\begingroup$ No, i am not asking for code review. Im asking whether the data gathered from the sensors has enough entropy. For further explanation: the -9.81d is there to ignore gravity (and i hardly think that astronauts will ever be using that app). Worst case: the attacker has software running on the device. Expected case: the attacker gets the resulting public-key and has less effort to factor the key by guessing the directions the generating device was moved to. $\endgroup$
    – marstato
    Mar 5, 2014 at 12:45
  • 1
    $\begingroup$ I disagree with those who say this is off-topic (although you might want to get rid of the code, as it's superfluous to your question). You're basically asking whether external input collected via a device's sensors has high entropy, and is suitable for feeding into a well-vetted CSPRNG. You should check out this question ... I would say the same principles apply. $\endgroup$
    – hunter
    Mar 5, 2014 at 13:05
  • $\begingroup$ @hunter that is exactly what i am asking AND wheter the way i use it is flawed in any way (that dataSetsRecorded % dataStack.length thing). $\endgroup$
    – marstato
    Mar 5, 2014 at 13:59
  • $\begingroup$ The original code did ((int) x) ^ ((((int) y) ^ ((int) z)) << 16), which is not accurately summarized by XORed. Also it multiplied by the float obtained from 0xFFFFFFF, which is $2^{28}-1$. We still do not have a model of how $x$, $y$, $z$ are derived, and most importantly a failure model of that. Much of the art of TRNG design is checking the source of entropy against its likely failures, given a model of the source; see this. Also: I guess $x$ $y$ $z$ are about acceleration, not movement as presently stated. $\endgroup$
    – fgrieu ♦
    Mar 5, 2014 at 15:34

1 Answer 1

Reset to default
0
$\begingroup$

Read Toward Sensor-Based Random Number Generation for Mobile and IoT Devices, if it's not too late(!)

In summary, the extracted table below shows their findings. Those were that the three accelerometers in combination provided a good 24 bits of entropy for randomness extraction. The good bits are the black boxes in the table as per the note below it. The team got fairly good random results from their scheme.

heat map

I'd add the proviso that they used aggregated data from 37 devices. The results for a single device might vary...

Improve this answer
$\endgroup$
2
  • $\begingroup$ Too late for the app, but never too late for a good read :) thanks for the link. $\endgroup$
    – marstato
    Jul 26, 2017 at 22:18
  • $\begingroup$ Conditioning the gathered entropy is necessary for cryptographic use anyway; that is cheap, thus the simplest/best is to gather all samples (32 bytes here), not painfully paste the bits tested to vary (typical added cost is that of additional data in a hash input). The difficult part is testing for failure of the entropy source or/and determine if enough entropy has been gathered, and a better model than which bits vary (or sometime pass some NIST tests) is needed for that. $\endgroup$
    – fgrieu ♦
    Jul 26, 2017 at 23:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.