True Random Number Generation on an AtmelAVR Microcontroller

Josef Hlavac, Robert LorenczFaculty of Information Technology

Czech Technical University in PragueKolejnı 550/2, 160 00 Praha, Czech Republic

Email: {josef.hlavac,robert.lorencz}@fit.cvut.cz

Martin HadacekFaculty of Electrical Engineering

Czech Technical University in PragueTechnicka 2, 166 17 Praha, Czech Republic

Email: hadacmar@fel.cvut.cz

Abstract—We present a method of generating true randomnumbers on an Atmel AVR microcontroller. The jitter of thebuilt-in RC oscillator is used as the source of entropy to generate8 random bits per second. When implemented on the AVRButterfly demo board, our method needs no external components;otherwise, only an external oscillator is needed. We tested thegenerated random bitstream using the “sts” test suite by NISTand discuss the result. Finally, we suggest a possible way ofgenerating slightly more entropy and a method of avoidingexternal components altogether.

I. INTRODUCTION

Random number generation is a frequent requirement inembedded applications. Random numbers are used, for exam-ple, to control the behavior of computer-controlled opponentsin computer games, to simulate dice throwing, or to generatecryptographic keys.

The mentioned uses require various degrees of randomness.In some situations, it is sufficient to use a pseudo-randomgenerator whose output is deterministic but difficult to predictby a human. In other situations, such as in cryptographicapplications, generated bits must be truly random, otherwisethe security of the entire application could be compromised.

In this paper, we present a method of generating true randombits on an Atmel AVR microcontroller [1]. Although the AVRseries of 8-bit microcontrollers is not equipped with dedicatedhardware random number generation facilities, we show thatit is possible to get entropy from the built-in RC oscillator.We demonstrate our method on an AVR Butterfly demo board[2] with no extra components or modifications.

II. RANDOM NUMBER GENERATION

The ATmega169 microcontroller [1] on the AVR Butterflydemo board [2] can access several oscillators. The defaultconfiguration uses an on-chip RC oscillator for the systemclock, and can utilize an oscillator with an externally con-nected crystal as an asynchronous clock generator for theTimer/Counter 2 unit. There is also another built-in oscillatordedicated for the watchdog timer, which we do not use in ourdesign (but discuss its possible use later in this paper).

These oscillators are never perfectly stable. Their frequen-cies are influenced by many physical factors, such as the thesupply voltage or ambient temperature, and also subject toinherent jitter. It is important to note that the effect of these

Fig. 1. Principle of operation. The inherent jitter of the RC oscillator leadsto a different count being read in each interrupt handler invocation.

factors is significantly different on each of the oscillators.The crystal oscillator is much more stable in the entire rangeof operating conditions, while the RC oscillator, althoughcalibrated, exhibits significant variations. Even if the boardis kept in a stable environment and powered from a stabilizedsource, the RC oscillator exhibits easily measurable jitter.

The jitter of the RC oscillator is the source of entropy inour method. We use the crystal oscillator to time a constantperiod (1 second), and we count the number of cycles of theRC oscillator that occur during that time. In an ideal world,the cycle count would always be the same; however, in reality,we observed a difference of up to 2

12 clock cycles betweensuccessive measurements (0.2% of the total number of clockcycles).

Now, to generate the actual random bits, we use the fol-lowing method. The Timer/Counter 1 unit counts the cyclesof the system RC oscillator (running at the default setting of2 MHz). The Timer/Counter 2 unit with the crystal oscillator(32.768 kHz) and an appropriate prescaler configuration isused to generate an interrupt every 1 second. In the interrupthandling routine, the 16-bit value in the Timer/Counter 1register TCNT1 is read (that is, the number of clock cyclescounted modulo 2

16) and the TCNT1 register is reset to zero.Then, bits 1 through 8 are extracted from the retrieved 16-bitvalue and output as a part of the generated random bit stream.The interrupt handler then exits.

The principle of operation is depicted in Fig. 1.

V2-493978-1-4244-6349-7/10/$26.00 c©2010 IEEE

0

0.0001

0.0002

0.0003

0.0004

0.0005

0.0006

0x0 0x4000 0x8000 0xC000 0xFFFF

Fig. 2. Relative frequencies of generated “raw” values (cycle counts modulo216). Data in the graph were concatenated from two test runs under somewhat

different operating conditions; hence, two distinct Gaussian-like distributionsare present.

0

0.001

0.002

0.003

0.004

0.005

0x0 0x40 0x80 0xC4 0xFF

Fig. 3. Relative frequencies of extracted 8-bit values. These values are thenconcatenated to form the random bit stream. Their distribution is sufficientlyuniform.

III. RESULTS, TESTS AND DISCUSSION

For all tests, we used the NIST sts-2.0b suite described in[5].

First, it is necessary to determine which bits of eachmeasured value are sufficiently random. In order to do that,we tested bitstreams created by extracting a specific bit fromeach measured 16-bit value. The resulting 16 bitstreams werethen tested. As expected, the results show that bits 15–10 areobviously non-random – many P-values are below the 0.01threshold, and simply looking at the file one finds long runsof 1’s or 0’s. Bit 9 is still non-random (still many P-values arebelow the 0.01 threshold).

It is important to realize that bit 0 (the LSB) is also non-random. This is due to the fact that before an interrupt canbe serviced, the current instruction must be completed. MostAVR instructions take 1 or 2 clock cycles to complete, makingthe LSB highly dependent on the code being executed. Inan extreme case, when the code does nothing but wait forinterrupts in an infinite loop, the microcontroller only executesRJMP instructions, each of which takes 2 clock cycles, and

the LSB stays constant.For the remaining bits 1–8, some randomness tests still

failed. These were the “Universal” test [6], which failed dueto insufficient length of the random sequence, and several outof many instances of the “NonOverlappingTemplate” test. Inthe latter case, the results should be still OK because at the1% level of significance, one can expect 1 in 100 tests to faileven if the tested sequence is actually random [5].

Then, we tested the final bitstream obtained by extractingbits 1–8 from each measured value. The results were againsatisfactory, with still not enough data to complete the “Uni-versal” test.

Fig. 2 shows the “raw” data – relative frequencies ofindividual encountered values. Notice that the graph showstwo distinct Gaussian-like distributions. This is due to the factthat the test data were obtained in two test runs, each undersomewhat different ambient conditions.

Fig. 3 shows the relative frequencies of 8-bit values ex-tracted from each 16-bit count. The distribution looks suffi-ciently uniform now.

IV. SUGGESTIONS FOR FUTURE WORK

A. Input capture unit

As mentioned above, the least significant bit of the retrievedtimer value must be discarded because it is not sufficientlyrandom. This is due to the fact that the value of Timer/Counter1 is read in an interrupt handler. To avoid this problem, onecould connect the Output Compare output of the asynchronousTimer/Counter 2 unit to the Input Capture input of theTimer/Counter 1 unit. This way, it would be possible to accessthe exact value in the TCNT1 register at the very momentof timer 2 overflow, avoiding the mentioned drawback andgaining one additional truly random bit.

Obviously, this method would require one additional ex-ternal component – a wire connecting the ICP1 and OCR2Apins.

Unfortunately, on the ATmega169 microcontroller, the ICP1signal shares a physical pin with the SEG22 signal (LCDsegment 22). Therefore, on our testing platform, the operationof the Input Capture unit interfered with the operation of theLCD. So, we did not explore this option further.

B. Watchdog timer

All Atmel AVR microcontrollers are equipped with a watch-dog timer. The primary purpose of the watchdog timer isto reset the microcontroller if the firmware stops workingproperly. The watchdog timer is essentially a counter that isclocked with an independent on-chip RC oscillator. Softwaremust periodically reset the counter; if it fails to do so, it isassumed that the software is not functioning correctly, and areset is triggered as soon as the counter overflows.

Instead of system reset, some AVR microcontrollers cangenerate an interrupt when the watchdog timer overflows.Thus, one could utilize the main RC oscillator and the watch-dog RC oscillator to generate entropy. This method wouldneed no external components besides the microcontroller itself.

V2-494 2010 2nd International Conference on Computer Engineering and Technology [Volume 2]

On the other hand, it needs to be verified whether the twooscillators are really independent (ruling out any parasiticdependencies) and how much entropy can be generated. Itwould also mean losing the built-in watchdog functionality, atleast while generating random numbers.

We did not test this method yet because the ATmega169microcontroller in our testing platform does not support watch-dog interrupts.

C. More testing

As mentioned in Section III, we tested the random numbergenerator using the NIST sts-2.0b test suite [5]. We alsoattempted to test the generator with two other popular testsuites, Diehard [4] and Dieharder [3]. However, these testsuites need a lot of data (10 to 11 megabytes for Diehard,and up to 2 GB for dieharder), and that will still take sometime to generate using our generator.

In addition, the random number generator should be testedunder a wider range of operating conditions, especially ambi-ent temperatures.

It also remains to be fully tested whether a shorter samplinginterval (less than the presently used 1 second) may leadto more entropy. The reasoning behind this idea is thatcertain fluctuations in the generated clock signal may averagethemselves out over a longer period. Indeed, preliminaryexperiments do suggest that a shorter interval may performbetter.

V. CONCLUSION

We presented a method of generating true random numberson an Atmel AVR microcontroller. The method generates 8random bits per second. That is not much; however, onemust remember that AVR microcontrollers have no dedicatedfacilities for generating true random numbers. We tested therandomness of the generated bitstream using the NIST sts testsuite, with satisfactory results; however, more testing needs tobe done before making final conclusions about the propertiesof the generator.

REFERENCES

[1] Atmel Corporation. “8-bit AVR Microcontroller with 16K Bytes In-System Programmable Flash ATmega169P, ATmega169PV.” DocumentNo. 8018N-AVR-08/09. 2009. [Online]. Available: http://www.atmel.com/dyn/resources/prod documents/doc8018.pdf

[2] Atmel Corporation. “AVR Butterfly Evaluation Kit – User Guide.” Doc-ument No. 4271C-AVR-04/05. 2005. [Online]. Available: http://www.atmel.com/dyn/resources/prod documents/doc4271.pdf

[3] R.G. Brown. “Dieharder: A Random Number Test Suite.” [Online].Available: http://www.phy.duke.edu/∼rgb/General/dieharder.php

[4] G. Marsaglia. “The Marsaglia Random Number CDROM, with TheDiehard Battery of Tests of Randomness.” Florida State University. 1985.[Online]. Available: http://www.stat.fsu.edu/pub/diehard/

[5] A. Rukhin et al. “A Statistical Test Suite for the Validation of Ran-dom Number Generators and Pseudo Random Number Generators forCryptographic Applications.” National Institute of Standards and Tech-nology. NIST Special Publication 800-22rev1. 2008. [Online]. Available:http://csrc.nist.gov/groups/ST/toolkit/rng/documentation software.html

[6] U.M. Maurer, “A Universal Statistical Test for Random Bit Generators,”Journal of Cryptology, vol. 5, no. 2, pp. 89–105, 1992.

[Volume 2] 2010 2nd International Conference on Computer Engineering and Technology V2-495