2017: Year in Review

What a year! I can't even begin to remember everything that happened, but here are some highlights and lowlights.

Highlights 

• After 20 years, I left Sun/Oracle and joined Intel as a Director of Software Engineering of Security Solutions Enablement for Data Center.  A long title that means my team works on security related projects, like Open Security Controller, that enable security on the Data Center. 
• I worked at Intel 21 years before, as an intern in their Folsom Engineering Services group (as an admin for Win 3.1, WinNT, Win95, AIX, Irix, SunOS and Solaris).  It was oddly like like putting on a comfortable pair of shoes coming back, but at the same time a very different company. A much faster moving place, a more inclusive place and more inventive place.
• My team has released two versions of Open Security Controller (0.6 and 0.8) this year! (like I said, fast moving!)
• I was appointed to the City of Mountain View's Bicycle/Pedestrian Advisory Committee, where I get to advise the City Council on such things like: transit projects, walk-ability of new building projects, how to improve dangerous and deadly intersections, and where to spend budget to improve biking and walking.  It's pretty fun! The committee definitely has diverse opinions and I have found the last twelve months on the committee to be quite a learning experience.
• I demonstrated, with my Oracle team, PKCS#11 and KMIP on Solaris at the RSA Conference Expo in San Francisco in February 2017.
• I read 24 books, covering 7,937 pages.
• I recorded the narration for 8 audio books for Learning Ally. These books are for the blind and others with reading disabilities.
• I did a police ride-a-long with the Mountain View Police Department! I was amazed at the officers compassion, how well they treated the citizens and how they were quick to de-escalate a situation.  I watched an officer arrest a man who had been drinking "since the early morning" and then brandished a knife at another man at Walmart. The man was belligerent when first approached, yelling and gesticulating.  The officer used calm tones, did a quick and calm search, secured the gentleman and proceeded with his investigation. I watched a situation go from tense to calm in a heartbeat. Yes, I used the word calm repeatedly - but that is the best way to describe what the officer did.
• I was on the Crypto Review Board for BlackHat USA, and got to attend!!
• Additionally, I was on the program review boards for International Cryptographic Module Conference (ICMC) and GreHack!
• I presented on PKCS#11 version 3.0 at ICMC.
• I became secretary of the PKCS#11 technical committee, a role change from co-chair.
• I reviewed scholarship applications for Learning Ally Scholars - every one of the students was incredible!
• My husband and I celebrated 10 years of marriage in Sausalito, CA.
• I saw all of my siblings and my parents this year! Most more than once! I didn't see enough of my nieces and nephews, though...  
• I did a few more Murder Mysteries, did photography for a couple of shows, and sang with the Lyric Victorian Carolers.
• Overall, I volunteered more than 179 hours.
• I went skiing!
• I stayed alive!

Lowlights

• I lost my uncle, Dan Bubb, my Dad's brother, to pneumonia.
• My dear friend Elisa was diagnosed with breast cancer in October and Comcast let her husband go from his job (along with the rest of his division) in December - just before Christmas.  Her battle continues, please consider donating.
• I suffered a major health crisis myself - on my first day of work at Intel, where I learned another highlight: Intel is a compassionate company, they were there when I needed them and helped me to get back on my feet and hit the ground running in my new role!  And, I didn't die :)

Any lowlights or highlights for you?

Here's to 2018!

Open Security Controller v 0.8.0 Released!

I am proud to announce that my team, and the OSC Community, have released the latest version of the Open Security Controller, version 0.8.0!

Open Security Controller (OSC) is a software-defined security orchestration solution that automates deployment of virtualized network security functions, like next-generation firewall, intrusion prevention systems and application data controllers.  This is our second release, and second release this year!

The new big features include:

• OpenStack Ocata support, and we continue to support Newton as well
• Kubernetes beta support - check it out and give us feedback
• Neutron Service Function Chaining beta support
• Multi-policy support
• Expose IP/Mac addresses for security group members
• Open source of our test automation!

Please do check out our release notes for more information, come on over to visit us on github, and join the community!

Job well done!

ICMC15: Improved Approaches to Online Health Testing in SP800-90 RNGs

David Johnston, Hardware Security Architect, Intel

There are two basic types of RNGs: big and fast, small and slow.

You need to do online testing to be sure things are actually random, like a statistical test for nondeterministic part. Also need a logic integrity test for the deterministic part : BIST, SCAN, KAT

You can only test for a broken state - strong bias or a strong serial correlation coefficient (SCC).

Min entropy tests are too slow and data hungry to do online. All patterns are equally likely (even all zeros).  But, some patterns are characteristic of a broken state: strong bias or a strong serial correlation coefficient (SCC).

A nice test or "broken - maybe" Note the binomial distribution of short and long patterns in a number of fully random bits. Set bounds for each, then measure each over sample and check they are wall within the bounds. If outside, tag as unhealthy.  The bounds determine the false positive rate.

The advantage - it's cheap. A shift register, 6 comparators and 6 counters.  Spots all repeating patterns up to 6 bits in length and detects bias and correlation. Highly bimodal with stationary data of some bias and auto correlation. Intel CPUs do this over 256 bit samples and aims for 1% false positive.

For an entropy source OHT, what's an error when all patterns are equally likely?

The lower false positive rate means you'll like have a high false negative rate.  how do you know if this is really broken or not?

There's a basic principal: never throw away entropy. - Margaret Salter. If you discard the unhealthy tagged samples, you reduce the entropy. If you accept unhealthy tagged samples, you risk false negatives.  Simple: extract with output = MAC (last_output || MAC(Xi || ... || Xi+r), where n is the number of samples and  is the number of samples that contain the necessary number of healthy tagged samples. Also, mixed in are the unhealthy samples that aren't counted.  Suspicous of MACing over variable field length? See his references (#7).

Over many samples, remember just the 1 bit tag per samples, allos a test over lots of data without huge amounts of memory.  Count the N Healthy:Unhealthy ratio in the last M samples.  Intel CPUS have M=256 -> so the history statistic is over 64Kibit of data..

If it drops below the threshold of goodness, detect and offline.  Ideally, it never happens.

What makes pool feedback good? E.G. Intel's CPUs demand 768 bits of healthy entropy, MACed to 256 its of full entropy, but all intervening unhealthy samples are mixed in, so no entropy is thrown away and occasional false positives don't raise error response.

What's wrong with SP800-90C?

The ENRBG output offers a superset of the DRBG's cryptographic properties. Full entropy vs prediction computational complexity respectively So, a general purpose RNG needs both: DRBG for performance and ENRGBG for arbitrary strength keys and seeding..

The oversampling construction kills performance of DRBG output by forcing intervening reseeds. Unless you put in two DRBGs, doubling the area, doubling the failure rate...

You can add a BIW extractor, and a DRBG for XOR construction.

We wnat better reliability and performance without DRBG. A modern ful entropy ES+Extracot has higher bits/clock/um^2 than an AES-CTR-DRBG.  Best case of 128/10 clocks/31K gate equivalents = 4.13E-4bits per clock per gate (asymptotic as the gen:update ration -> 1.0).

And then we have FIPS 140-2, which has required tests that go beyond SP 800-90A. If you follow 4.9.2, which includes a data modifying test and throwing away data. This yields a radom stream trivially distinguishable from random. No 16 bit equal pairs in 1MByte data = Definitely not random, 16 are expected. It creates algebraic invariates Xi != Xi+1 for all output values, reducing entropy and helping algebraic attacks.

Intel refused to put this in its silicon because it may be a back door. The risk to Intel of having a back door is greater than the cost of not being FIPS compliant.

ISO 19790-2012 removed this test - so, let's hurry up with FIPSf 140-3.

But, still source constrained devices can't have hardware FIPS compliant RNGs because of the DRBG requirement.

Pool structures that use health tagging allow appropriate adaptive responses to entropy source failure and degrdation behaviour and instantaneous response to instantaneous ES failure.

The DRBG requirements of SP800-90C lead to a reduction in reliability and/or efficiency of RNGs and prevent SP800-90 compliant full entropy hardwar RNGs in resource constrained situations. FIPS 140-2 makes this worse.

Johnston has seen systems getting when to block flipped - that is , blocking when they have high entropy and not blocking when their entropy is low.  This is not a good plan, and has led to published papers.

The kernel's job is to do the mixing. While he knows that Intel's entropy source doesn't have a back door, but not everyone else knows that - or know that about their other sources - so, mixing is good.
Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!