1 changed files with 297 additions and 0 deletions
Unified View
Diff Options
+ 297
- 0
content/2021/05/nearly-complete-rng-guide.html
View File
| @@ -0,0 +1,297 @@ | |||||
| --- | |||||
| title: Nearly Complete Guide to RNG on a microcontroller | |||||
| description: > | |||||
| How to initialize and run an RNG on an STM32L151CC microcontroller. | |||||
| created: !!timestamp '2021-05-18' | |||||
| listable: false | |||||
| time: 12:00 PM | |||||
| tags: | |||||
| - security | |||||
| - rng | |||||
| - microcontroller | |||||
| --- | |||||
| Security depends upon cryptography and which in turn depends upon a | |||||
| Random Number Generator (RNG). An RNG is used for key generation (both | |||||
| symmetric and asymmetric) and key negotiation (session establishment). | |||||
| The later is an absolute requirement to ensure that communications can | |||||
| be secured. The former (key generation) can be used at first boot for | |||||
| personalization, but isn't necessary as it could be done when personalizing | |||||
| the device at programming or first deployment. | |||||
| There are two types of RNGs, the first is a True Random Number Generator | |||||
| (TRNG). This is one that takes some non-deterministic process, often | |||||
| physical, and measures it. Often, these are slow and are not uniform, | |||||
| requiring a post processing step before the are useful. | |||||
| The second type is a Pseudo Random Number Generator (PRNG)<label | |||||
| for="sn-drbg" class="margin-toggle sidenote-number"></label><input | |||||
| type="checkbox" id="sn-drbg" class="margin-toggle"/><span | |||||
| class="sidenote">[NIST](https://www.nist.gov/) also refers to a | |||||
| PRNG as a Deterministic Random Bit Generator (DRBG).</span>. PRNGs | |||||
| take a seed, and can generate large, effectively unlimited when seeded | |||||
| properly, amounts of random looking data from them. The issue is than | |||||
| if someone is able to obtain the seed, they will be able to predict | |||||
| the subsequent values, allowing breaking security. | |||||
| The standard practice is to gather data from a TRNG, and use it to seed | |||||
| a PRNG. It used to be common that the PRNG would be reseeded, but I | |||||
| agree w/ djb (D. J. Bernstein) that once seeded, no additional seeding | |||||
| is needed<label for="sn-entropy" class="margin-toggle sidenote-number"></label> | |||||
| <input type="checkbox" id="sn-entropy" class="margin-toggle"/> | |||||
| <span class="sidenote">See his blog post | |||||
| [Entropy Attacks!](https://blog.cr.yp.to/20140205-entropy.html)</span> | |||||
| as modern PRNGs are secure enough and can generate enough randomness | |||||
| that their state will not leak. | |||||
| There are lots of libraries and papers that talk about how to solve the | |||||
| problem for RNGs on a microcontroller that may not have an integrated | |||||
| [T]RNG block, but I have not been able to find a complete guide for | |||||
| integrating their work into a project where even a relative beginner | |||||
| could get it functional. | |||||
| This article was written as I developed the | |||||
| [lora-irrigation](https://www.funkthat.com/gitea/jmg/lora-irrigation) | |||||
| project. This project will be used as an example, and the code reference | |||||
| is mostly licensed under the 2-clause BSD license, and so is freely | |||||
| usable for your own projects. | |||||
| Sources of Randomness | |||||
| --------------------- | |||||
| As mentioned, most microcontrollers do not have a dedicated hardware | |||||
| block like modern AMD64 (aka x86-64) processors do w/ the RDRAND | |||||
| instruction. Though they do not, there are other sources that are | |||||
| available. | |||||
| The first, and easiest one is the Analog Digital Converter (ADC). Even | |||||
| if the ADC pin is tied to ground, the process of digital conversion is | |||||
| not 100% deterministic as there are errors in the converter or noise | |||||
| introduced on the pin.<label for="sn-adcnoise" | |||||
| class="margin-toggle sidenote-number"></label><input type="checkbox" | |||||
| id="sn-adcnoise" class="margin-toggle"/><span class="sidenote">The article | |||||
| [ADC Input Noise: The Good, The Bad, and The Ugly. Is No Noise Good | |||||
| Noise?](https://www.analog.com/en/analog-dialogue/articles/adc-input-noise.html) | |||||
| talks about this.</span> | |||||
| The data sheet for the microcontroller will help determine the expected | |||||
| randomness from the part. In the case of the | |||||
| [STM32L151CC](https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-ultra-low-power-mcus/stm32l1-series/stm32l151-152/stm32l151cc.html) | |||||
| that I'm using, Table 57 of the data sheet lists the Effective number | |||||
| of bits (ENOB) as typically 10 bits, which is a couple bits short of | |||||
| the 12 bit resolution of the ADC. This means that the 2 least | |||||
| significant bits are likely to have some noise in them. I did a run, | |||||
| and collected 114200 samples from the ADC. The [Shannon | |||||
| entropy](https://en.wikipedia.org/wiki/R%C3%A9nyi_entropy#Shannon_entropy) | |||||
| calculated using the empirical probabilities was 2.48.<label | |||||
| for="sn-shannonenropy" class="margin-toggle sidenote-number"></label> | |||||
| <input type="checkbox" id="sn-shannonenropy" class="margin-toggle"/> | |||||
| <span class="sidenote">Now this is not strictly Shannon entropy, as the | |||||
| values were calculated from the experiment, and Shannon entropy should | |||||
| be calculated from the a priori probabilities.</span> Discarding the | |||||
| 0's (which makes up over half the results) improves the entropy | |||||
| calculation to 3.29. The | |||||
| [min-entropy](https://en.wikipedia.org/wiki/R%C3%A9nyi_entropy#Min-entropy)<label for="sn-min-entropy-fwdref" class="margin-toggle sidenote-number"></label>, | |||||
| <input type="checkbox" id="sn-min-entropy-fwdref" class="margin-toggle"/> | |||||
| <span class="sidenote">Forward reference: | |||||
| <a href="#min-entropy-awk">min-entropy awk script</a></span> | |||||
| a better indicator of entropy, calculation is 1.2 bits, and if all the | |||||
| 0's are dropped, it improves to 2.943. This does help, but in the end, | |||||
| subtracting the data sheet's ENOB from the ADC resolution does result | |||||
| in an approximate estimate of entropy. | |||||
| It is possibly that a correlation analysis between samples could | |||||
| further reduce the entropy gathers via the ADC, but with sufficient | |||||
| collection, this should be able to be avoided. | |||||
| The second is using uninitialized SRAM. It turns out that this has | |||||
| been studied in [Software Only, Extremely Compact, Keccak-based Secure | |||||
| PRNG on ARM Cortex-M](https://dl.acm.org/doi/10.1145/2593069.2593218) | |||||
| and [Secure PRNG Seeding on Commercial Off-the-Shelf | |||||
| Microcontrollers](https://www.intrinsic-id.com/wp-content/uploads/2017/05/prng_seeding.pdf). | |||||
| Depending upon how the SRAM is designed in the chip, it can create a | |||||
| situation where each bit of SRAM will be indeterminate at boot up. | |||||
| Both of these papers studied a similar microcontroller, an | |||||
| STM32F100R8 to the one I am using, a STM32L151CC. | |||||
| I ran my own experiments where I powered on an STM3L151CC and dumped | |||||
| the SRAM 8 times and analyzed the results. I limited my analysis to | |||||
| 26863 bytes the 32 KiBytes of ram (remaining was data/bss or stack, so | |||||
| would not change, or was zeros). I then calculated the min-entropy for | |||||
| each bit across power cycles and the resulting sum was 11188, or | |||||
| approximately .416 bits per byte. This is 5.2% and in line with what | |||||
| the later paper observed for a similar device. | |||||
| Part of using a source of randomness is making sure that it is usable. | |||||
| In the case of the ADC, each reading can be evaluated against previous | |||||
| reads to ensure that the data being obtained is possibly random. In | |||||
| the case of SRAM, this is more tricky, as the state of SRAM is static, | |||||
| and short of a reset, will not change. This means that to use SRAM, | |||||
| proper analysis of the device, or family of devices, need to be evaluated | |||||
| for suitability. There are cases where a device's SRAM does not provide | |||||
| adequate entropy, as discussed in the papers, and so this method should | |||||
| not be used in those cases, or not solely relied upon. | |||||
| The following is an `awk` script for calculating the min-entropy of the | |||||
| provided data. Each sample must the first item on a line, and each sample | |||||
| must be a hexadecimal value w/o any leading `0x` or other leading | |||||
| identifier: | |||||
| <pre id="min-entropy-awk" class="language-awk fullwidth"><code># Copyright 2021 John-Mark Gurney | |||||
| # This script is licensed under the 2-clause BSD license | |||||
| function max(a, b) | |||||
| { | |||||
| if (a > b) | |||||
| return a; | |||||
| else | |||||
| return b; | |||||
| } | |||||
| { | |||||
| v = ("0x" $1) + 0; a[NR] = v; | |||||
| maxv = max(maxv, v); | |||||
| } | |||||
| END { | |||||
| tcnt = length(a); | |||||
| me = 0; | |||||
| for (bit = 0; 2^bit <= maxv; bit += 1) { | |||||
| cnt0 = 0; | |||||
| cnt1 = 0; | |||||
| for (i in a) { | |||||
| tbit = int((a[i] / 2 ^ bit) % 2); | |||||
| if (tbit) | |||||
| cnt1 += 1; | |||||
| else | |||||
| cnt0 += 1; | |||||
| } | |||||
| v = -log(max(cnt0, cnt1) / tcnt) / log(2); | |||||
| print "bit " bit ":\t" v; | |||||
| me += v; | |||||
| } | |||||
| printf "total:\t%0.3f\n", me; | |||||
| } | |||||
| </code></pre> | |||||
| It is also possible that there are other parts of the board/design | |||||
| that could be a source of randomness. The project that started this | |||||
| journey is using [LoRa](https://en.wikipedia.org/wiki/LoRa) for | |||||
| communication. It turns out that the sample code for the radio chip | |||||
| ([LoRaMac‑node](https://github.com/Lora-net/LoRaMac-node)) implements | |||||
| a [random interface](https://github.com/Lora-net/LoRaMac-node/blob/7f12997754ad8e38a84daa85f62e7e6c0e5dbe59/src/radio/radio.h#L154-L163). | |||||
| The function just waits one milisecond, reads the RSSI value, takes | |||||
| the low bit and repeats this 32 times to return a 32-bit word. There | |||||
| are issues with this as I cannot find any description of the expected | |||||
| randomness in the data sheet, nor in the code. It also does not do | |||||
| any conditioning, so just because it returns 32-bits, does not guarantee | |||||
| 32-bits of usable entropy. I have briefly looked at the output, and | |||||
| there does appear to be higher lengths of runs than expected. Another | |||||
| issue is that it's collection takes a while, as the fastest is 1 bit | |||||
| per ms. So, assuming the need to collect 8 bits for 1 bit of entropy | |||||
| (pure speculation), that means at minimum 2 seconds to collect the | |||||
| 2048 bits necessary for 256 bits of entropy. | |||||
| Uniquifying | |||||
| ----------- | |||||
| One of the other ways to help ensure that a microcontroller is to | |||||
| integrate per device values into the PRNG. This does not guarantee | |||||
| uniqueness between boots, but it does make it harder to attack if an | |||||
| attacker is able to control the other sources of randomness. | |||||
| In the case of the STM32L151 chip I am using, there is a unique | |||||
| device id register. The device register is programmed at the | |||||
| factory. Because it is unknown if this unique id is recorded by the | |||||
| manufacturer, and possibly traced through the supply chain, and no | |||||
| guarantees are made to both the uniqueness or privacy, it has limited | |||||
| use to provide any serious additional randomization. | |||||
| Another method, is to write entropy at provisioning time. This can be | |||||
| done in either flash memory or EEPROM, which may have a more granular | |||||
| write access. | |||||
| Using SRAM | |||||
| ---------- | |||||
| The tricky part of using SRAM is figuring out how to access the | |||||
| uninitialized memory. Despite having full access to the environment, | |||||
| modifying the startup code, which is often written in assembly, to do | |||||
| the harvesting makes an implementation less portable. Using standard | |||||
| C, or another high level language, makes this easier, *but* we need to | |||||
| know where the end of the data and bss segments are. This is where | |||||
| looking at the linker script will come in. | |||||
| A linker script is used to allocate and map the program's data to the | |||||
| correct locations. This includes allocating memory so that all the | |||||
| code and data fits in flash, but also allocating ram for variables, and | |||||
| stack. Often there will be a symbol provided that marks where the data | |||||
| and bss sections in ram end, and the heap should begin. For example, | |||||
| in [`STM32L151CCUX_FLASH.ld` at lines 185 & | |||||
| 186](https://www.funkthat.com/gitea/jmg/lora-irrigation/src/commit/91a6fb590b68af1bcd34f776d4a58c89ac581c7d/stm32/l151ccux/STM32L151CCUX_FLASH.ld#L185-L186) | |||||
| it defines the symbols `end` and `_end`, the later of which is often | |||||
| used by `sbrk` (or `_sbrk` in my project's case in | |||||
| libnosys<label for="sn-sbrk-sample" class="margin-toggle sidenote-number"></label><input type="checkbox" id="sn-sbrk-sample" class="margin-toggle"/> | |||||
| <span class="sidenote">A sample `_sbrk` is in [utils_syscalls.c](https://www.funkthat.com/gitea/jmg/lora-irrigation/src/commit/91a6fb590b68af1bcd34f776d4a58c89ac581c7d/loramac/src/boards/mcu/saml21/hal/utils/src/utils_syscalls.c#L67-L83), | |||||
| though this particular implementation is not used by my project.</span>) | |||||
| to allocate memory for the heap. Using sbrk is the easiest method to | |||||
| access uninitalized SRAM, but modifying or adding a symbol can be used | |||||
| if your microcontroller's framework does not support sbrk. | |||||
| Putting it together | |||||
| ------------------- | |||||
| It is accepted that integrating as many difference sournces of entropy | |||||
| (TRNGs) is best. This ensures that as long as any single soruce is | |||||
| good, or each one is not great, but combined they provide enough | |||||
| entropy (preferably at least 128 bits), that the seeded PRNG will be | |||||
| secure and unpredictable. | |||||
| As some sources are only available at first boot, e.g. SRAM, it is | |||||
| best to save a fork of the PRNG to stable storage. In my | |||||
| implementation, I decided to use EEPROM for this. I added an | |||||
| additional EEPROM section in the linker script, and then added a symbol | |||||
| [rng_save](https://www.funkthat.com/gitea/jmg/lora-irrigation/src/branch/main/strobe_rng_init.c#L39) | |||||
| that is put in this section. This should be 256-bits (32-bytes) as | |||||
| the savings of smaller does not make sense, and any proper PRNG when | |||||
| seeded with 256-bits will provide enough randomness. Writing to EEPROM | |||||
| does require a little more work to have the code save to this region, | |||||
| rather than RAM, but the STM32 HAL layer has functions that make this | |||||
| easy. | |||||
| It would be great if where the PRNG seed could be in read-once, | |||||
| write-once memory to ensure that it can be read, mixed in with any | |||||
| additional entropy, and the written out, but I do not know of any | |||||
| microcontroller that supports this feature. | |||||
| Part of this is is to ensure that the the state between the saved | |||||
| seed, and the PRNG state used for this boot is disjoint, and that if | |||||
| either seed is compromised, neither can be backtracked to obtain the | |||||
| other. In the case of [strobe](https://strobe.sourceforge.io/papers/strobe-latest.pdf), | |||||
| the function [strobe_randomize](https://www.funkthat.com/gitea/jmg/lora-irrigation/src/branch/main/strobe/strobe.c#L319-L331) | |||||
| does a RATCHET operation at the end, which ensure the state cannot be rolled | |||||
| back to figure out what was generated, and as the generated bytes does | |||||
| not contain the entire state of the PRNG, it cannot be used to | |||||
| reconstruct the future seed. | |||||
| Another advantage of using EEPROM is the ability to provide an initial | |||||
| set of entropy bytes at firmware flashing time. I did attempt to add | |||||
| this, but OpenOCD, which I use for programming the Node151 device, | |||||
| does not support programming EEPROM, so in my case, this was not | |||||
| possible<label for="sn-eeprom-flash" class="margin-toggle sidenote-number"></label><input type="checkbox" id="sn-eeprom-flash" class="margin-toggle"/><span class="sidenote">Despite not using it, the infrastructure to generate perso entropy is still present in the [Makefile](https://www.funkthat.com/gitea/jmg/lora-irrigation/src/branch/main/Makefile#L152-L157).</span>. | |||||
| I could have added an additional source data file to the flash, but | |||||
| figured that the other sources of entropy were adequate enough for my | |||||
| project. | |||||
| {# | |||||
| Conclusion | |||||
| ---------- | |||||
| Modern microcontrollers do have a number of sources of entropy that can | |||||
| be used. With a little bit of work, a PRNG seed can be saved between | |||||
| resets, allowing for more secure operation, and even preloading of | |||||
| entropy. #} | |||||