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.
