1
$\begingroup$

I'm trying to get a random number for a STM32L0x1 MCU to use it in protocol SRP6a.

(I know that there are MCUs with an embedded hardware random number generator. But it would cost twice as much as the MCU I'm using right now.)

Now some questions arise:

  1. Would a "bad" random number seed (like reading values from ADC) negatively affect the security of SRP6a?

  2. If yes: how to get a "good" random number (random enough for SRP6a) on STM32L0x1?

  3. What about the following approach: a) Create the random number seed externally at the factory and save it in EEPROM of the MCU b) Every time the MCU is (re)started, run a one-way function (like a hash) on the seed, save that new seed and use it for the software random number generator.

$\endgroup$
1
$\begingroup$

Would a "bad" random number seed (like reading values from ADC) negatively affect the security of SRP6a?

Yes. At least, a reused random on the server side enables replay of a captured session. On the client side, I think (without detailed analysis) that a predictable RNG can be used to extract secret information allowing login, or even the password if it is weak.

How to get a "good" random number (random enough for SRP6a) on STM32L0x1?

That's a generic microcontroller with 32-bit CPU, RAM, Flash, EEPROM, ADC. This gives at least two options:

  • The one outlined in the question: use a Cryptographically Secure Pseudo Random Generator, seeded with a secret random value at factory, and it's state kept in permanent memory (e.g. EEPROM) from one invocation to the other. The difficulties are

    • Keeping the state secret (including, setting it up initially). If an adversary can use a JTAG port, poof goes security. There are other avenues of attack, e.g. power analysis.
    • Going from one state to the other atomically including in the event of power loss, perhaps at a moment chosen by an attacker. That's EXTREMELY difficult. That's significantly easier with RAM, if there is a battery backup of that.
      Update per comment: problem with atomic EEPROM update is that the underlying hardware does not provide it. When a byte erase or write gets interrupted by a power loss, what's read there (until another erase or program) is unspecified. Experience shows that it often is neither the old nor the new value, and sometime varies from one re-read attempt to the other, as a function of power supply voltage or temperature, and time. This is because individual bit cells of the EEPROM byte are left incompletely erased or written, giving no noise margin to the read comparator. Reliable atomic update is possible despite that, but hard to get right and test well. A prerequisite is to obtain some assurance that physically re-erasing (and/or over-programming) a byte that appears erased or (successfully programmed) is possible, rather that blocked by some driver (or worse hardware) trying to reduce EEPROM wear.
    • EEPROM eventually wears, and perhaps adversaries or just Murphy will induce repeated updates. I've witnessed contactless Smart Cards powered-up and activated with a sub-second cycle merely by being stored next to an NFC mobile phone, and have heard mildly credible anecdotes of bank Smart Cards destroyed in the process.
    • Choosing the CSPRNG correctly; not the hardest!
  • Leveraging some physical source of randomness, e.g. sample the 12-bit ADC (it can run at over 1 M sample/s) and post-process that (e.g. feeding enough samples into a hash and using the result as the random). The hardware can boil down to a single trace connected to an existing point at an appropriate voltage. The main difficulty is evaluating the appropriate number of samples, which can vary depending on environment (in particular temperature, nearby EMI source). Taking a lot of headroom is good, but often not enough: if an adversary has some level of access to the hardware, the approach often can be made to fail (e.g. by forcing the input of the ADC to a slightly higher voltage than the maximum, thus making the output of the ADC fixed to all-one; or by pouring liquefied gaz, lowering the temperature dramatically, making the ADC malfunction or/and reducing the amount of noise).

The two approaches can be combined, making a successful attack more difficult. But designing a robust random number generator, especially when an adversary has access to the device, is notoriously difficult.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Atomically updating the seed could be done by first updating it on every startup. Only if it has been updated, it should be used by the CSPRNG. If the device reboots exactly while updating the EEPROM, a possible solution could be to have 2 seeds and a short variable telling the device which seed to use. So while seed A is in use, I'd update seed B and after that save the variable to use seed B. If while updating seed B a reboot occurs, the device would once again try to update seed B. $\endgroup$ – trevor Sep 20 at 14:27
  • $\begingroup$ @trevor: the hard problem is not when making the update, but how. Hardware provides no atomic updating of EEPROM. I now expand on that in the answer. $\endgroup$ – fgrieu Sep 20 at 14:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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