ABSTRACT
Secure communication requires strong cryptography and unpredictable cryptographic keys. The unpredictability comes from a random bit generator component call an entropy source. The entropy source is considered to be a black box (user’s perspective) that outputs bits of entropy from the noise source. Failure of an entropy source in the field may result in predictable outputs, which can undermine security and give access to potential attackers.
Design For Accessibility: Getting it right from the start
Health Tests of Entropy Sources on Arduino
1. Health Tests of Entropy
Sources on Arduino
By: Jose H. Rodriguez, Jr.
ITL, Computer Security Division
Cryptographic Technology Group
4th August 2016
2. Outline
• Problem
• What the project is about?
• Reasons and explanation of Health Tests
• Test environment
• Results
• Conclusion
• Future work
• Acknowledgements
• Questions?
3. Problem
• Crypto and security applications utilize random numbers and random
bits, but generating them is problematic.
• NIST SP800-90 series
• 90A: Deterministic algorithms
• 90B: Entropy sources
• 90C: Putting whole thing together
• SP800 – 90B describes how to design and test entropy sources
4. ENTROPY SOURCE
Problem
• Need unpredictable crypto keys.
• Unpredictability comes from
entropy source
• What’s an entropy source?
• A ‘black box’ that outputs random
bits that can used for crypto keys.
(User’s perspective)
Noise Source
• Failure here: (x) security
(x) attackers
• Health Tests counteract this
problem.
• Alerts for entropy loss
Unpredictable
Crypto Keys
System
Failed/entropy
loss
5. What the is project about?
• The aim of this project is to
study the practicality of
different entropy source
health tests in RBGs.
• Focus on health tests of SP800-
90B
• Repetition Count Test &
Adaptive Proportion Test (APT)
• Implemented on Arduino board
– applied to simulated entropy
sources
• Arduino used to imitate a real
world scenario
6. Health Tests • Detect large deviations of the
noise source with high
probability.
• Designed to raise an alarm for
significant decrease in entropy of
outputs:
1. Noise source failures
2. Failure in hardware
3. Faulty implementation
Health Test
7. Health Tests
• Types of health tests:
1. Start up
2. Continuous
3. On demand
• The SP800-90B gives two approved health tests
1. Repetition Count Test
2. Adaptive Proportion Test
• If these tests are utilized, No other tests are required
• Designed for minimal resources and on-the-fly computation
10. Test environment
• Repetition Count Test (RCT)
• Quickly detect failures
that cause the noise
source to get “stuck” on a
single output value.
11. Test environment
B = 1
C = [1 +
− log2 𝛼
𝐻
] -> 3
A is current sample
B = 4 thus
exceeding C= 3;
so system
failure!
12. Test environment
• Adaptive Proportion Test
(APT)
• Detects a large loss of
entropy; a value becoming
more frequently seen
than expected, given the
source’s assessed entropy
per sample.
13. Test environment
A is current sample value
B = 1
W = 4
C(excel) = CRITBINOM(W, power(2,(-H)), 1 - α) → 2
W = 4
No failure B = 3 exceeds C = 2 so
system failure.
14. Results
• Program memory usage:
• MAX: 32,256 bytes
• Original memory usage:
• Use to be 22% due to:
• Poor program design;
overthinking
• Certain functions; parseInt()
• Slowed down processing speed
15. Results
filename Test H alpha time (hr:min:sec) Failure detected?
Repetition 1 2^-6 0:00:09 yes
APT 1 2^-6 0:13:43 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 - no
Repetition 1 2^-6 0:00:10 yes
APT 1 2^-6 0:05:22 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 - no
Repetition 1 2^-6 0:00:10 yes
APT 1 2^-6 0:05:22 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 - no
Repetition 1 2^-6 0:00:10 yes
APT 1 2^-6 0:05:22 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 - no
Repetition 1 2^-6 0:00:10 yes
APT 1 2^-6 0:13:43 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 0:20:17 yes
Repetition 1 2^-6 0:00:09 yes
APT 1 2^-6 0:13:43 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 0:17:55 yes
Repetition 1 2^-6 0:00:12 yes
APT 1 2^-6 0:13:07 yes
Repetition 1 2^-10 0:00:48 yes
APT 1 2^-10 0:11:56 yes
Repetition 2 2^-6 0:00:03 yes
APT 2 2^-6 - no
Repetition 2 2^-10 0:00:07 yes
APT 2 2^-10 - no
Repetition 2 2^-6 0:00:04 yes
APT 2 2^-6 - no
Repetition 2 2^-10 0:00:07 yes
APT 2 2^-10 - no
Repetition 2 2^-6 0:00:03 yes
APT 2 2^-6 - no
Repetition 2 2^-10 0:00:07 yes
APT 2 2^-10 - no
Repetition 2 2^-6 0:00:04 yes
APT 2 2^-6 - no
Repetition 2 2^-10 0:00:07 yes
APT 2 2^-10 - no
NearUniform -1-stutter-64
NearUniform -1
NearUniform -1-stuck-16
NearUniform -1-stuck-64
NearUniform -1-stuck-128
NearUniform -1-stutter-16
NearUniform -1-stutter-128
NearUniform -2
NearUniform -2-stuck-16
NearUniform -2-stuck-64
NearUniform -2-stuck-128
• Arduino processes data sequences and detects
system failure.
• At a good rate
• Near Uniform
• Entropy levels follow a near uniform dist. with 1
bit of entropy (blue)
• Entropy levels follow a near uniform dist. with 2
bits of entropy (green)
• Stutter: repeats same value n times
• Stuck: repeats the same n symbols from the
failure point on
• H: assessed entropy/sample of the source
• Alpha: false positive probability
Generating random bits for crypto and using them for security purposes is a bit problematic. Reason being is that it is hard to tell if a bit string is sufficiently random, even with nice statistical properties. If the seed used to generate the bit sting is predictable, then so is the bit string. Thus NIST’s Special Publication 800-90 series is made to provide guidance on the construction and validation of Random Bit Generators in the form of DRBGs or NRBGs for crypto applications. Amongst these 3 recommendations, my project focuses on 90B in where it describes how to design and test entropy sources.
(Next slide)
Okay, so we need good unpredictability for crypto keys – this comes from the entropy source. [What’s entropy source?]/read bullet. All this randomness comes from the most crucial component known as the (*) noise source, which is the root security of the entropy source and for the Random Bit Generator as a whole. As the generated non-deterministic random bits flow from the Noise Source through the digitization and post-processing components, the raw data must go through some health tests before becoming the so desired (*) unpredictable output we need for crypto keys. Failure here results in predictable outputs which can undermine security and could give access to potential attackers. Health Tests can counteract this problem in where it will alert the system for entropy loss.
(Next slide)
The main purpose of this project is to study the “practicality” of different entropy source health tests in Random Bit Generators. The health tests I focused on were the Rep. Count Test and the Adaptive Proportion Test from the 90B publication. These tests were implemented on an Arduino Uno and applied to simulated entropy sources.
Why use and Arduino? It is most likely that real-world sources will use a low-end ARM processor, like this UNO, to manage their sources. Would like to see that the tests are light weight; to see if the test aren’t to demanding. So this is where these health tests will be running in. (Next-Slide)
Health Tests are an important component of the entropy source, because it aims to detect large deviations (catastrophic failures) of the noise source with high probability. The two tests mentioned earlier, are designed to raise an alarm for a significant decrease in entropy of outputs such as: (read the list)
(Next slide)
There are 3 types of health tests:
Start Up – perform after a reboot, they make sure the entropy source components are working as expected before operating.
Continuous – tests run indefinitely while the entropy source is operating.
On demand – tests that can be called at any time; not required particular testing during operation, but the ES must be CAPABLE of doing these tests.
**(Read this only) The type of health tests my project focused on belonged in the continuous test section within the 90B recommendation. The 2 approved health tests are: (RCT & APT)
These are the only 2 types of tests needed, because they are designed to require min. resources and to be on-the-fly computation, while noise source samples are being produced with no delay in availability of noise source samples.
(Next slide)
This is my test setup. Top left corner is my Arduino program. I made 2 programs, one for each health test. The top right hand side is my processing program. This is a new IDE that I ‘learned’ and utilized it to read simulated noise source samples. (Files underneath processing) I use processing to read the files and feed it through the Arduino’s serial monitor, using serial communication. As the Arduino process the given data and detects a failure … I record the data on an excel sheet.
(Next-Slide)
These health tests are designed the same way. We decided it would be cool to present it this way. The code is the only thing that distinguishes my designs, since each health tests is required to do something different when examining the noise source samples. I used the LCD screen to echo all the information sent from the processing program and display when a failure has occurred – also use a red led that flashes when failure occurs.
(Next Slide)
Give a quick definition and go to next slide for visual example.
B is your counter. C is your cutoff. A is your current sample. If A is the same as the next number of the sequence, then B++. If B exceeds C then system failure.
** If the run of the same value is too long, more than 3 in this example, the test raises an error.
A current sample. B counter. W is my window size. C is my cutoff (will be calculated in excel) using H and alpha.
The test counts the number of times the current sample value is repeated within a window size, if the sample value is repeated more frequently than the cutoff value…system failure.
These tests as mentioned before are meant to be designed to be light weight. So each test roughly used 14% of the total number of bytes the Uno has for memory.
(Next slide)
Once the Arduino processes the data sequences from the files and detects a system failure, with respect of the two different health tests, I record the time it took to detect a failure and if it did fail I marked it as yes/no.
What is the meaning of the file names and symbols?
A near-uniform distribution is what several of the 90B entropy estimation methods are designed for, because it provides a conservative upper bound on estimated entropy.
Each of the files has 6 variants with synthetic failures. There are 2 types: stutter & stuck
(read bullets)
The type of failure and variable ‘n’ are reflected in the file name.
Read H and alpha: bullet
(Next Slide)
(1) Conclusion of your results?
**Found out that RCT detect failures at a faster rate then APT
(2)Thoughts on this project?
**Still needed more files to test and didn’t get to touch the predictor health test. What this test does, is that it attempts to guess the next output of a noise source before it appears.
(3)Your thoughts of the SURF program? (Overall great)
(4)The Challenges you face and how did you overcome them?
*Trouble getting started
*Learn a new program with a language I don’t know (Java)
*LCD fails so had to use simulation.
{Overcame obstacles through persistence, friends, advisors}
(Next slide)
