# The Arizona Lottery's Not-So-Random Random Number Generator

Printable PDF

Random numbers -- really, truly random numbers -- play a very important role in security. Everything from key generation, nonces, shuffling, secure protocols, and many forms of challenge-response rely on unpredictable numbers. (For the purposes of this discussion, I won't go into the nuances of hardware-generated random numbers vs. cryptographically secure random number generators, whitening and entropy extraction, etc.)

There are many ways that things go wrong. Firmware engineers will often use the rand() function from the C standard library (often without seeding), either because they don't know any better, or because they feel they don't have a good alternative (no excuse!) Or they'll obtain a "good" random number, but then introduce a bias when converting that larger random number into a smaller range.

There are myriad ways things can go wrong. That's one of the reasons we devote an entire section to the topic in Barr Group's Embedded Security Boot Camp. In fact, I just taught the class last week to a group of students in Boston, and it was a lot of fun.

One of the things I discuss in the course is how things can go wrong with "random" numbers. One of the examples is the 2013 Arizona lottery; a "glitch" prevented the digits 8 and 9 from being drawn in certain positions. (A "glitch"? Really? Sounds like a bug, or something more nefarious, to me.)

Well, guess what? It's 2017, and the Arizona lottery is back, in an attempt to out-do itself, apparently now "technical difficulties" with the lottery's random number generator have resulted in the same winning numbers being generated repeatedly. Ooops. Quoting the article: "the machine generated the same winning numbers in multiple drawings for three different games."

Of course, this problem was very obvious. Most failures and problems with random numbers in security systems are more subtle and often go undetected for long periods of time.

Does your embedded product use random numbers as part of its security framework? If so, where do they come from? Is there a bias, even a slight one? (Are you sure?) If you suspect a bias, how are you removing it? Would your firmware detect a scenario where there is a failure in your random number generator?

Security is hard. Random numbers are one of the easier things to get right, but I've encountered a multitude of different problems while performing security audits / firmware reviews. Just think how difficult it is to get all the other things right when trying to secure a product.