OWL: Bias in the Workplace

Professor Joan C. Williams, Hastings Foundation Chair; Director, Center for WorkLife Law; University of California, Hastings College of the Law.

I had read Joan's book - What Works for Women at Work - and LOVED it, so I was so happy to see Oracle brought her onsite! Her book was well researched and science based, and gives lots of great everyday strategies for women in today's workplace.

She interviewed more than 100 successful women, and did additional research. Ninety-six percent of all women interviewed had experienced  at least one type of bias at work.

She wrote an article for Harvard Business Review, "Why We Hate Our Offices: And how to build a workspace that you can love".

The first type of bias is "Prove it Again!" syndrome, experienced by 68% of the business women and scientists she interviewed.

One gentleman she interviewed had transitioned from being a woman, and stayed in the same field of science. He overheard people, who were confused about who the female was with the same last name, that "his work s so much better than his sister's". He doesn't have a sister - that was his work, published when he was a man.

There is the "stolen idea" syndrome - you expect great ideas to come from men, so don't hear it when it comes from a woman.

Women's and men's mistakes are remembered differently, and many of these same biases also apply across racial lines. For example, people were asked to review a legal memo - the same memo, with the same errors - but when reviewers thought they were reviewing a document by a black man - they found more errors.

What's the most important factor in determining networks?  Similarity, attractiveness and location.

How does this play out in the workplace? In an org where people on top are a certain demographic, they are going to sponsor people who are like them (A sponsor is a mentor that is willing to spend their political capital to help their mentee's career).  Men tend to be judged on their potential, women on their results. This gets them stuck in the "prove it again" loop.

Women of color trigger two sets of negative stereotypes: gender and race.

When they interviewed scientists they were surprised that women of Asian descent reported the "prove it again" strategy more often then white women, even though we thought their was a stereotype that Asians were good at science. Apparently the women in this group were exempt from that positive stereotype.

So, how to get out of it? Well, prove it again - but try not to burn out. Keep careful, real-time records that track your accomplishments.  When you get compliments? Forward the email to your sponsor and manager.

How can manager's level the playing field for women?  Look around - who are you sponsoring. Is there a certain patter? do you need to widen out the group.  Male managers sometimes worry that taking a woman out to lunch or coffee would look "weird" - it doesn't. If you would do it with the men you were sponsoring, then it should be appropriate for women. Now, if you do a lot of your bonding in the men's locker room... then you need to think about doing this in ways where it wouldn't matter if you were sponsoring a man or a woman (mentoring, etc0.

Imagine you are sitting in a meeting and you see the stolen idea occur. How do you intervene? Lot's of ideas, but saying something is better than nothing. Something like, "thanks, Paul, for going back to that, I've been pondering that ever since Pam brought it up"

What if you are sitting in a meeting and you see men being judged on their potential; women on their performance - how would you intervene? This happens a lot when it comes to promotions, women are often already doing the job before they get the promotion.  One idea for getting around this: suggest evaluating the engineers first by their accomplishments, then by potential. Another: Are we being consistent here?  Or, now that we know what we're looking for, let's go back to the top of the pile and re-review everyone.

Often the most savvy way to call out bias is not to mention that's what you're doing :-)

What works for organizational prove-it again: set up precommitment to what is important (for promotion, for example), and when someone varies from there they need to have justification.

Women are expected to be nice and communal - and nice. Men are expected to competent and "agentic" (assertive, direct, competitive and ambitious).  Nobody thinks of a strong leader as "nice", so women often aren't even considered for leadership positions.

This varies by culture - US/Canada and UK believe a leader should be independent, risk takers, direct and focus on tasks. It's opposite in India/China/Japan: Interdependent, certainty, indirect and have a focus on relationships.

Ben Barres, the transgendered scientist, noted that "by far, the biggest difference is people treat me with respect. I'm interrupted less" since becoming a man.

How you stand and sit telegraphs power or submission. To demonstrate authority, stand with feet apart - stable.

Ellen Pao was described as both as "passive, too quiet at meetings" and "entitled, demanding".

Women get pressure to be deferential or play the office mom - always deliver, but never threaten. Women are pressured to do the office housework: planning parties, getting gifts, note taking, scheduling meetings, mentoring, and do the undervalued work (paperwork, etc).

But, if you're stern or say no - you're not modest or nice. You become the "B" word.

As a women, you need to claim your seat at the table and practice power poses. You need to learn how to get a word in edgewise - learn how to politely interrupt: "Oh, I'm sorry, I thought you were done."

What works for one woman won't work for another. You need to be authentic, and no when to say no (and how!).

Managers - how to handle "office housework"?  Don't ask for volunteers - women will be  under gender stereotype to volunteer. Assign true admin and housework to admins or true support personnel.  Possibly, for things like minutes, do a rotation.

Spread the load and set norms. For example, everyone does one "citizenship task" - sitting on committees, and everyone does their own ordering, billing, etc.

There was a non peer reviewed study on performance evaluations. Men got specific feedback. Women got things like "bossy, abrasive, strident, aggressive, emotional, irrational" - very strong prescriptive gender bias.

Women also are impacted by maternity bias - mothers are 79% less likely to be hired, are held to higher standards for punctuality, offered lower starting salaries and promoted less.

Indisputably competent and committed mothers are seen as LESS likable, particularly by women.

Mothers are not offered stretch positions because people assume she's busy with kids. Managers: don't assume! If she's the best person, offer it - and let her know that similar positions will be available in the future if now is not a good time.

There is this false sense that only one woman can get promoted, get an award, etc - so they will compete with each other, instead of working together.

A study found that not one female legal secretary expressed preference to work with a female lawyer as a boss.  "Females are harder on their female assistants, more detail oriented, and they have to try harder to prove themselves, so they put that on you."

Older women in the workplace discourage younger mothers from working part time after maternity leave, because "I worked full time right away and my kids are fine". That is, "I did it the hard way, why can't you."

One study found that women without children work more unpaid hours of overtime than anyone else in the workplace, seen as a pathetic spinster - so why can't you work these hours?

To get organizational change: do a "4 patterns assessment" - is bias playing out in everyday work interactions? Then develop an objective metric to test whether what women think is happening is, and make adjustments.

Example: given the study of performance reviews, companies should be reviewing their reviews for this language and see if it's mentioning bias based negative personality traits? Look at objective metric: promotion rates.  Interrupt: have someone trained to spot bias read all performance evaluations (or use an app), and redesign evaluations and provide workshops for your managers.

We all have unconscious bias. This is usually not malicious. But if you are ignorant, who's fault is that? We need to be aware and take action to counteract it.

ICMC15: Importance of Open Source to the Cryptographic Module Community

Chris Brych, Senior Principal Security Analyst, Oracle

Chris's talk will focus primarily on OpenSSL's history and potential future

The OpenSSL project has it's roots back to 1995 to the SSLeay project (Tim Hudson and Eric Young). In 1998, Tim and Eric joined RSA and started a new life and career in crypto development. There were still a lot of followers, Ben Laurie and Dr. Stephen Henson took over maintenance and changed the name to OpenSSL. In January 1999, 0.9.1 was released. Mostly maintained by volunteers. Today, we're at 1.0.2d.

There are 15 people around he world that work on OpenSSL, most are volunteers. There are 2 full time paid employees with plans to hire 2 m ore. No direct source of funding, they are relying on some private contributions and some donations.  Considering there are 7,098,576 web servers use OpenSSL (0.9.7 -> 1.0.2). This does not include application uses of OpenSSL, either, like routers.

In 2003 Steve Marquess, working for US DoD, embarked on a FIPS 140 project to validate a cryptographic toolkit derived from an OpenSSL distribution to get around exorbitant licensing fees from 3rd party toolkit vendors.  Needed a more cost effective solution.

There was a fork created in OpenSSL distribution to isolate the FIPS crypto into it's own distribution. There is a build process that is repeatable to build the exact same module that has already been validated. The hash was calculated over the fipscanister.o and verifying it with a hash published in the FIPS security Policy Document guaranteed that the same code that was validated could be used to build the FOM. Contiguous boundary created in memory that allowed for integrity checking.

This was based on the 0.9.7e distribution.  But, the DoD still wanted to make some changes to make it eve more secure.

The community saw value in someone else doing this work and started picking this up and then making contributions upstream to make it more secure.

Why use this? Well - it's free!  (subject to license restrictions).  If you're a small company, you can't afford the cost of 3rd party toolkits with FIPS support.

There's also low internal maintenance, because OpenSSL does it for you. Engineering can focus on new development features, new updates can be picked up and easily integrated and build on existing code base.

Since this was so widely accepted by many companies, many vendors stopped making their own crypto libraries. Many people, beyond the 15 core volunteers, contribute fixes.

There are disadvantages....

For example, if a bug has been publicly identified, it is out of your control - you have to wait for OpenSSL to create a fix.  You may need to wait on OpenSSL to re-certify itself, slowing down your business.  OpenSSL is not for everybody - the 80/20 rule applies here.

0.9.8 and 1.0.0 OpenSSL distributions will be EOL on December 31, 2015.  The FIPS Object Module version 1.2.4 (Cert #1051) will no longer be supported.

1.0.1 is EOL December 31, 2016 - so start thinking abou going to 1.0.2. FIPS Object Module cert #1747 is still supported by 1.0.2

But, 1.0.2 will only be around until December 31, 2019. Seems a long way out, but it will be here before we know  it. Then, we won't have anything to use #1747 with anymore.

NIST just published a draft of SPF 800-131A, r1 in July 2015, speifies non-compliant DH, ECDH and RSA in 2018.  the FIPS Object Module is not fully compliant with NIST SP 800-56A/B key agreemen. So only primitives testing for ECDH completed, KDF not tested. DH not tested as part of NIST SP 800-56A and RSA not compliant with SP 800-56B and OpenSSL does not plan to do this development.

1.1.0 is plan to be released in April/May 2016, which will include an API change. It will not be compatible with FOM 2.0.10.  That is, we lose our FIPS module!

This means that if organizations need FIPS and are now relying on OpenSSL, they will have to hire to complete this. Will have to make modifications of a code base containing over 500,000 lines of code - risky. What if they introduce other vulnerabilities?  Many vendors will have an OpenSSL validation - but they won't be the same. Confusing for end users.

Money won't solve the problem. OpenSSL is not interested, even if some vendor offered them money.

How can we solve this? if you're interested, please participate in the CMUF. We will have to get input from CMVP and the US Government needs to be involved.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Collateral Damage—Vendor and Customer Impact of Frequent Policy Changes

Joshua Brickman, Director, Security Evaluations, Oracle; Glenn Brunette, Senior Director and Chief Technologist, Cybersecurity, Oracle

Glenn started the talk.

Oracle is a big company, nearly 40 years old. Originally started with one products, but no has 1,000s of products with 400,000 customers across 145 countries.  This is a lot of variance, which makes doing FIPS 140-2 at Oracle a challenge.

Many of our products and delivered systems cannot change frequently, for example products used in medical trials.

Oracle has developed many products for FIPS 140: Solaris Cryptographic Framework, StorageTek, Java Cards, Acme Packet Session Border Controller, etc.  Also leverage third-party validated modules ("FIPS Inside") like RSA BSAFE Crypto J and OpenSSL.

It's not even simple when you talk about one product. For example, our Database interacts with several different crypto modules.

We do our best to educate our customers and internal developers, try to figure out how to compare apples and oranges and figure out operational decisions.

FIPS 140 can be easy to understand in one breath, and complicated to understand in the second. Is it approved or not?  Validated vs approved?  What modes and key lengths are you validated against?

We need to be more specific.  Marketing and product documentation might say: "We're FIPS validated! We're Encrypted" - but our customers want and need more details. Even saying a product uses AES may not be sufficient, as they need to know modes supported.

Module vs product validation.  Is "Oracle Weblogic" FIPS 140 validated?  What about Oracle Solaris? It could have multiple libraries and modules under the covers.

But, if you use "FIPS Inside" approach, you won't be listed on the CMVP website, so customer doubts vendor's sincerity.  Would be nice  if there was an official place to list folks leveraging FIPS Inside strategy.

Module versioning is not consistent with product versioning.  You can get away with very vague versioning schemes, makes it challenging for customers.

How do you map a product's cryptography to modules?  The big product, like an OS, may not validate every cryptographic module included in the system. Even if the OS vendor works really hard, they might only get 80%. How does your customer know if they are using one of the non validated uses cases?

Many times products do not ship with FIPS 140 on by default, so there is a challenge to even get it turned on. Then, customers layer products - particularly in the cloud space.

The NIST website can be very clear about when you should use FIPS, yet customers don't interpret this correctly. They may only be concerned with TLS, but actually using more.  They've sometimes done the horrible workaround to drop crypto, because they don't have a validated solution.  Some customers get this, others do not.

Lack of understanding at the customer site leads to a lot of problems. We need to plan for this when making future standards, so folks aren't taking the shortest path (which is usually the wrong approach).

Josh thinks there's a lot of hope, he sees progress coming around the corner.

It's clear that NIST/CMVP want the strongest crypto NOW for their customers. Vendors want the strongest crypto for their customers, with the least performance impact. Customers WANT this, but for a low price.

Remember the critical Shampoo algorithm: lather, rinse, repeat! This should apply to the CMVP process.

Vendors face big challenges, like: AES-GCM IV Generation.  In 2007 NIST issued SP 800-38D published, with two IG's.  In 2009 IG A.5 Key/IV pair uniqueness requirements  inside the physical boundary. In 2015 IG A.5 was overhauled, based on the discovery of 1 vendor's bad application that used all zeros for their IV - so we're all punished. Change came in August 2015, no grandfathering.

When we saw the new IG draft, we stopped all ongoing work to analyze the new IG. Oracle wrote up a proposal to mitigate the impact of the new IG while still meeting the spirit of the IG and sent it to CMVP.  Whiel waiting for a response, CMVP issued another IG. On August 5, still not responding to Oracle's comments, A.5 came out. How is that working with the vendors?

IG 7.15 published in August, again no grandfathering, and we found a project that got it's entropy from a 3rd party and we could not prove it.  the third party treated this as intellectual property, so they did not want to work with CMVP.  Oracle volunteered everything we did know to CMVP, and begged for a waiver. How do you build a business around that model?  Did everyone get a waiver?  Will our next project get a waiver?

How do we get out of that cycle?

Could form a technical community (CMUF working with CMVP). Take a page from NIAP and work together to solve problems. Take advantage of the fast resources of industry!  Create one for IGs, one for FIPS 140-4, etc.  Instead of throwing IG's over the wall, work together to come up with consensus.

We need time  to react - there MUST be time to transition. Every reactive response to IG is less time for industry to build product and fix bugs. [Note: by panicking to react, we may end up introducing worse issues.]

NIAP and NIST need to go back to being a partnership - see Entropy!

Negotiate with other crypto schemes to see if any mutual recognition can be negotiated.

We can do better by working together, so let's do that :-)

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: FIPS is FIPS, Real World is Real World and Never the Twain Shall Meet?

Ashit Vora, Co-Founder and Laboratory Director, Acumen Security

Ashit's journey has taken him from a Lab, then to a Vendor, and now back to a Lab.  He's seen the experience from both sides.  He's been working with FIPS 140-2 since 2003. The world has changed greatly since then, but the standard has not.

FIPS 140-2 has been approved since May 2001. It was very hardware focused, as that's what was common in the marketplace. There was only a small handful of approved algorithms.

There is a requirement that the standard is supposed to be updated every 5 years, so there was a draft of FIPS 140-3 in September 2005... a draft.  As of now, we *might* get FIPS 140-3 in May 2016, if it's delayed even a little bit it will turn into a long delay, as the standard has to be signed off by the Secretary of Department of Commerce - a political appointee, which will change when there is a new US President.

FIPS 140-2 is an open commercial project. The standard itself is 69 pages. Many vendors read that only and say, "I've read and understand the standard and we're ready!"  There are 127 pages of Derived Test Requirements, and 63 pages of implementation guidance.  IG was originally supposed to be an FAQ, but it has evolved to really be the new rules.

There are 287 requirements for FIPS, 50% of them are documentation requirements. More than 50% of the requirements are orthogonal to crypto.

OpenSSL has had 5 vulns in 2013, 22 in 2014 and 26 in 2015, but how many times has their FIPS module changed since 2013? Zero.

CMVP believes FIPS is a solutions, vendors think it's a means to an end (to sell to the government), and to the federal agencies it is merely a checkbox.

What is it really? A bit of everything and a bit of nothing. Ensures what is claimed has been implemented correctly - that's a good thing! At levels 1 and 2 little more assurance than the product implements crypto as per spec. FIPS validation does not mean the overall "cryptographic posture" of the system is secure.

The standard was developed with the best intentions, but it has not been able to change with our fast changing industry.  There have been a few improvements, like the changes for CRNG relaxation and possible relaxation on integrity checks.

COTS product - easy to buy a produce and open at your own leisure. Causes vendors to downgrade to level 1 or design prupose built "opacity shields". Tamper labels in a similar vein add nothing to security posture of the product. Products are rarely deployed with the opacity shields and tamper labels in place, they just don't fit on the rack. Plus, end users need to make modifications.

Real world: Key Management - possible to have a module FIPS validated w/out including key management at all. In fact MOST software libraries do not include key management.  This is a direct result of crypto boundaries shrinking!

Password requirements are rudimentary at best. No consideration for password complexity, frequency, etc.

Real World: OpenSSL. It is the MOST widely used cryptographic library in the world.  ost prevalent in networking products, but also showing up in IoT, etc. Many products gain FIPS compliance just by including OpenSSL.  That validation, however, does not cover TLS, key management - etc. Hence, the small boundary.

FCC/FSM and configuration management requirements do NOT add security.  The FSM (Finite State Machine) is almost always created AFTER the product is completed.

We have a test on software firmware load test, it checks that it's valid, but there is no root of trust.  A self signed cert gets you through this check.

Should follow the CC direction: use the standard as a base/toolkit and provide technology specific requirements (that map back to the standard).

Do not tie validations to specific versions. Allow for minor changes/bug fixes. Validations take a long time (12-18 months), but vendors tend to push fixes every month. Often very minor. Yes, there may be that one corner case where one vendor screws this up and makes a critical change - but why punish all vendors for one person's mistake?

Due to this, vendors are making VERY small boundaries, which means we're actually looking at a tiny portion of the security relevant system. Need to encourage larger boundaries, but that's only possible if engineers can fix small bugs.

Spend time on the most important sections: Section 1, Section 5 and Section 7.

Focus on key life cycle! Make those requirements more all-encompassing. Implementing crypto algorithms is easy (?!?), but key management is hard. [NOTE: it's all hard :-)]

Question what about making physical security optional?  Maybe, but it should be tied to the expected deployment environment. For example, a publicly accessible wifi access point might need to be more strict than a router buried in the bowels of a government building.

Randy Easter recommended just doing Level 1 for physical security, but Ashit noted that if they do everything else to Level 2 they will end up with a Level 1 overall validation. Randy noted that this is a matter of informing end customers - easier said than done!

Randy also wants to know how CMVP has relaxed rules w/out notifying the Secretary of Commerce?  Ashit noted that "that ship has sailed" with the Implementation Guidance.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Commonly Accepted Keys and CSPs Initiative

Ryan Thomas, FIPS 140-2 Program Manager, CGI Global Labs

Vendors understand their products and security, but are mystefied with how to list keys/CSPs in the way that the CMVP want.

The labs understand the requirements, and review any different types of vendor submissions that meet the requirements - and really want to provide something that is consistent and easy to review by CMVP.

Ryan has the idea to make life simpler, by creating a shared template for Keys and CSPs table.  He's gotten feedback already from CMVP.

Vendors will benefit from a pre-populated list that they can customize to your implementation - saves time and effort!

This isn't perfectly straight forward - will vary by software vs hardware modules.  Does it have persistent or ephemeral keys?  If it's software, likely are not making key storage claims.

Picture of template.....

Column #1 - Key/CSP Name. Mapped to NIST SP, ISO or IETF RFC - ie normalized names, a consistent and clear name that means the same thing to everyone.

Column #2 - Key/CSP type - type of key, algorithm and size.

Column #3 - Generation Input. Explain how the keys are derived or generated. If it's entered, specify if the CSP is entered electronically or manually/encrypted or plain text.

Column #4 - Output - encrypted or plain text

Column #5 - Storage. is it stored in memory, flash, HD, etc. ( encrypted or not). (there seemed to be 2 #4 columns,  so my numbering is off).

Column #6 - Use. how is the key used during module operation?  Needs to be mapped directly to an approved service that the crypto module performs.

Column #7 - Zeroization. How will the CSP be zeroized?  All possible techniquest need to be listed.

As for case studies, Ryan started with a "simple" IST SP 800-90A hash based DRBG.  Still found some inconsistencies.

More difficult are network protocols, like SSH, SNMP, IPsec and IKE - IKE is particularly tough.

TLS has a lot of potential rows, so want to work with the CMVP on this one as well, before showing to the public.

This will get posted to the CMUF (Cryptographic Module User Foundation?) site, contact Matt Keller if you need access.

Jennifer Cawthra, CMVP Program Manager, NIST - notes that this would really be appreciated, as it will help speed up their reviews, etc.  They are also looking for a security policy template - which the CMUF is also thinking of picking up.

From a vendor perspective, this looks pretty cool.  I think by having a standard template, we could then freely discuss with other vendors and not have to worry about disclosing some proprietary format, there could be websites to help walk us through, etc.


Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: CMVP Programmatic Status

Carolyn French, ITS Engineer, CSE; Michael Cooper, IT Specialist, NIST; Apostol Vassilev, Cybersecurity Expert, Computer Security Division, NIST

NIST will be increasing he fees for one year, cost recovery fees, so that they can hire contractors to work through the backlog.

In August 2015, NIST published a Federal Registry Notice seeking public comment on he potential use of certain ISO/IEC standards and crypto module testing, conformance and validation activities.  They did not get much feedback, other than complaints that this was a pay based set of standards.

Question on contractor strategy: we are now getting unusual questions and our labs have to spend time educating the contractors. Request for satisfaction with this strategy. Michael agreed it was  fair point, but that they have smart people.

Note on why they did not receive many comments: questioner said he's on the NIST public list, but the call for comments did not go there, it was only published on the federal register.  NIST noted it was posted to a few places, and asked their labs to reach out.

Question: while it looks like we're moving towards ISO standard, what would happen if we don't get it approved by Secretary of Commerce? Answer: you'd have to wait a loooong time for us to generate something else.

When the new standard is signed, folks will have 12 months to submit under the old standard.

CMVP queue is down from 12 months to 3 months, they are trying to get this down further. Part of the current delay waiting for the cost recovery funds to come in. This can be slow due to large companies' PO process.  Labs can speed this up by requesting the funding from their clients sooner - or possibly NIST needs to bill sooner?  For example, NIST should not wait until the test report is received, but rather send the bill when they are notified that there is a system under test - or some other time before the test report is submitted.

Post by Valerie Fenwick,  syndicated from Security, Beer, Theater and Biking!

ICMC15: SP800-90B: Analysis of Linux /dev/random

Stephan Mueller, Principal Consultant and Evaluator, atsec information security

Not only does Mr. Mueller work at atsec, but he also is a Linux kernel developer in his spare time. 

How do we define the noise sources for /dev/random:

• Disk I/O
• Block device number + 0x100 ||Jiffies || High-Resolution Timer
• Noise derived from access times to spinning platters

•  Human Interface Devices (HID)
•  Interrupts
• fast_pool: 4 32-bit words filled with 
• Jiffies 
• high resolution timer
• IRQ number
•  64 bit Instruction pointer of the CPU.

The output function is a SHA1 hash run over the output and put in the output pool.

How do we condition? The conditioner mixes data into input-pool, a non-approved mechanism according to SP800-90B. LFSR for 128 * 32-bit pool with full rank polynomial.  The goal is for bias reduction. The Disk/HID: bias added due to structure of data to be mixed into input_ool with MSB with rather static data (event numbers), middle bits with low entropy data (jiffies) and LSB with high-entropy data (high resolution timer.

There is a health test, but it is not compliant with SP800-90B.  they measure disk/HID and derivation of event time in jiffies. Minimum of all derivation is estimated entropy of event.  Limitation to 11 bits maximum per event. There is a claim that one bit of input data has less than one bit of entropy.  So, this covers continuous health test requirement and repetition count requirement (even though, again, it's not the test SP800-90B actually asks for).

All of these derivations are applied to all events, including startup - so, we kind of have a start up test.

Interrupts: implicit, without interrupt handling there is no live Linux kernel :-) 

There is no adaptive proportion test - entropy measurement considered equivalent.

The goal of identifying failures is met.

How to observe noise sources and LFSR/input_pool in a live Linux kernel, and unchanged Linux kernel and not ipact entropy calculation - answer: SystemTap! Though Heisenberg's uncertainty still applies, as it's changing timing by adding additional code paths. Akin to executing Linux on a slower system, therefor no impact on entropy estimates. [Note: I'm not sure I agree with that theory.]

Their test results:
General: Chi-Square for IID cannot be calculated and Chi-Square Goodness Fit cannot be calculated. For Disk/HID, only high-resolution timer tested due to main entropy source - other items were zero or close to zero entropy. But, when using lower 11 bits of timer, data is almost IID.  Looking at interrupts, each 32-bit word is tested individually. About half of IID test fail -> non-IID. 

General conditioner of IID: collision tests N/A due to no collisions, and all sanity checks always pass. 

Is the /dev/random on Linux good enough? Noise sources: using the min entorpy values for events and considering the maximum of 11 bits of entropy estimated per event, we pass SP800-90B. Additonal testing beyond SP800-90B shows that more than 6% of events are estimated to have 0 bits of entropy. About 20% of events are estimated to have 1 bit of entropy. Massive underestimation of entropy in noise sources.  For the conditioner: no change from noise sources. With entropy estimator enforced when obtaining random values - preventing random number output when there is too little noise. The passing of the noise source implies passing of the entire random number generator. Other pools feeding /dev/random and /dev/urandom are DRNGs!

Assumption of a certain structure of an entopy source. Straigh data path from noise source to output, and it's difficult to apply to noise sources maintaining an entropy pool

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

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!

ICMC15: A Look Into Hard Drive Firmware Hacking

Khai Van, Security Tester, Gossamer Security Solutions

Malware: malicious software, typically used to gain unsolicited access to computers. It comes in many forms: Trojan horses, viruses, bots, adware and worms.  They can be annoying or dangerous. You might lose your financial data, or other personal information.

When people hack hard drive firmware with a custom one, they can execute unwanted software, defeat hard drive encryption, read your secure files, etc.

Kaspersky Labs unearthed the "Equation Group", who uses cryptography (RC5, RC6 and AES).  Some of these attacks are more than 14 years old!  Many countries are impacted: US, Algeria, India, China, Russia, Egypt, and Mexico and more.

All major brands are impacted: Samsung, Western Digital, Seagate, Maxtor, Toshiba and Hitachi. Of the drives researched, it seems the only ones that were tested are HDDs with physical plates.  At this time, it seems PCB layout in SSDs are still being researched.


Jeroen Domburg, creator of spritesmods.com, has a way of accessing and overwriting the cache memory.

Jeroen was able to use an on-chip debugger (OpenOCD) to dump data and commands from the JTAG interface. Processors have read/write access to the cache memory. Data in the cache memory can be read/modified... so you can run injected programs in memory!  Flash can be dumped/replaced. Malicious programs can be written to flash memory to remain persistent.

Hard drive vendors can make remote firmware updates, unbeknownst to a user. This can be leveraged by an attacker.

Now, using a portable SPI programmer requires physical access. you'd probably notice a hacker walking around with and one accessing your datacenter.  So, firmware updates are more practical to attack.

The risk to consumers is that it is undetectable by traditional antivirus software. it is persistent, and survives wiping.  One of the attack involves installing a virtual OS that the hard drive could not detect or disable.

ICMC15: The Next Steps Toward A Scalable International Cryptographic Evaluation Process

Clint Winebrenner, Technical Lead, Product Certifications Security & Trust Organization, Cisco

How can we work together to eliminate time we're spending doing different validations for different companies. It's not just money to validate against different government standards, but also developer's time.

Is there a reference recommended list of cryptographic algorithms, covering encryption, decryption, etc?

Customers have to trust their vendor to do the right thing, to build software to be secure, safe and comply with RFCs and other standards.  The vendor has to trust the 3rd party test lab.

Trust, but verify. Need to verify that the evidence provided really verifies the algorithms. The testing should be repeatable across all bodies and processes.  It should be scalable, too.

What can we do about remediation? Engage experts from the industry and academia. We need to critically anlyze design from both a security and  performance perspective. Working with academia, industry and government to propose effective and scalable alternatives.

What if you trust the algorithm, but not the validation process?  We can modify existing process for algorithm validation, with methods to verify a sub-set of the effort.  Can we share more evidence?  Why not publish detailed algorithm validation results?

Could this get more complicated?  Yes - we can trust the vendor and the validation process, but not how the algorithm is used. So, we have to look at the protocol's too. Can we share protocol details for all systems under test?

If we can come up with an acceptable international evaluation process, we can have significant savings on time and more reliability.

ICMC15: Effective Cryptography—Or: What's Wrong With All These Crypto APIs?

Thorsten Groetker, CTO, Utimaco

Effective cryptography means it needs to work and be secure, but it also has to get you where you need to go quickly and calculate the results fast 

There are many well known crypto APIS - but there's something wrong with all of the.

PKCS#11 and security issues. There are numerous key extraction attacks known. Jolyon Clulow "on the Security of PKCS#11" and the Tookan project ("Attacking and Fixing PKCS#11 Security Tokens". There are CVE entries as well, but they don't necessarily note PKCS#11.

Why does PKCS#11 have these issues? Confusing sest of mechanisms and attributes - you need automated model checkers to determine secure configurations.  Functions are broken into fine grain operations, which opens the door to eavesdropping and insertion attacks. 

[Note: these are the opinions of the speaker, not my own, as with all my blogs from this conference]

PKCS#11 is not the worst of the bunch. These same attacks can be used against Microsoft CryptoAPI (CAPI), JCE/JCA and Mixed APIs. For example, under JCE/JCA there are wrap-decrypt attacks unless they are prevented by underlying devices. For CAPI, exchange keys can be also used to encrypt/decrypt data to open door to wrap-decrypt attacks.

Efficiency is development cost and time to market. If the team is more comfortable with an API, it will be easier for them to adopt and implement. 

"Simplicity is a prerequisite for reliability." - Edsger Dijkstra. (and hence for security)  Authentication should not be an after thought. We need multi-factor and multi-person (Mout of N) authentication. And don't forget about audit logging!

People tend to underesestimate the cost of data transfers - server -> CSP -> Middleware -> Network Appliance -> Driver -> HSM.  

If you implemented your cryptographic functions as atomic HSM commands it will be faster and more secure.

KMIP is trying to come to the rescue with the concept of batched requests.  This addresses some performance issues, but it is not suited as a general crypto programming paradigm.

Crypto apps running within the secure perimeter of an HSM will become the norm. Drivers include security, eas of use, performance, multi-tenancy, custom logging, portability and cost.  Thorsten believes that firewalling and binding a key to a specific app or device will become a hard requirement.

A PKCS#11 host program will have access to 50+ functions, 200 attributes [XXX - something got lost here - mechs were also mentioned] [Note: I don't believe there is really any PKCS#11 library that implements every mech, every attribute, every functions].

Don't forget how dramatically an easy-to-use API combined with firewalling and enabled 3rd party apps can change an established market. Think about how much things have changed from our old Nokia cell phones with buttons to an Android or iOS phone.

Managed languages make this even easier.

But are people really going to develop embedded apps for HSMs?

Introducing CryptoScript: You eed to write a script, load the signed script (automatically compiled under the hood and executed one where it spawns threads and registers functions as commands), and invoke newly registered CryptoScript commands from the host application in high level languages.

Inside the utimaco HSM there's a boot loader, OS, administrative modules , cryptographic modules and SXI (Cryptographic eXtended services Interface). CryptoScript is on top of all that.

The basic concept is to be small, efficient and portable under the MIT license for easy portability.  The language was pared down by removing application program interfaces, native debug I/F, aux lib and OS facilities. They've enhanced this by adding secure managed memory, command handling, authentication and secure messaging. 

CryptoScript does not allow direct memory addressing and no buffer/stack overflows.

Once you've got CryptoScript Modules - they are loaded in a virtual HSM, so they cannot direct the actual HSM file system and memory.

A question from the audience: If PKCS#11 sucks, due to complexity - how does the problem go away just because we implement it on the HSM?  Answer: the attack vector is removed, CryptoScript has better debugging, and it's faster to develop.
 
Post by Valeie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Department of Defense Cybersecurity

Marianne Bailey, Principal Director, Deputy CIO for Cybersecurity, Department of Defense

Their main goal: dependable execution in the face of  adversity.  Now everyone is focused on cyber security - at the highest level of security. Bailey is in the white house several times a week to non technical 4 star generals.

Cryptography is critical to the DoD.

Attacks by state and non-state actors are increasing each year, putting all of our assets at risk.  This results in loss of personal data and network outages. Anything with a computer can be attacked. This is not just an IT problem - many things are connected to each other.

We need to establish a culture of cyber discipline - breaches are often human error. Everyone has to understand the risk and must be accountable. Cyber hygiene: configure all computers to DoD standards, make sure every computer is protected, and eliminating the use of passwords by all users and administrators and instead using credentials issued by DoD.

Things haven't been going as fast as they want.  So, really putting alot of effort behind PKI infrastructure to get rid of passwords and role based access control. you can't do two things requiring different levels of privilege at the same time.

We see impersonations, privilege escalation. We have to watch, be aware and be able take action quickly.

Right now, too much of the nation is on the wrong side of these initiatives, which  means the attackers don't have to spend as much money or effort to attack us - but we still have to pay the price afterwards.

Commercial products should be implementing standards based cryptography, and follow other security standards.

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Cryptography, Moore’s Law, and Hardware Foundations for Security

Paul Kocher, President, Chief Scientist​, Cryptography Research

While crypto has continued to get better, and protocols have improved - we still are having massive security breaches.   the more complex our code get, the larger the code base gets - we increase our odds of more bugs.  If I have twice as much code, but the same amount of time to look at it, then the odds of missing bugs goes up much faster than linerally.

The Silver Bridge on US 35 in Ohio, built in 1924, collapsed in 1967, due to an engineering issue - gave us the term "fracture critical components".  How many "fracture-critical" elements are in a typical IoT device? DRAM, flash, storage, CPU logic, support logic. We're talking about billions of possible issues.

Our ability to understand simple elements often creates a false impression that we understand the complex system.just because you understand transistors, does not mean you understand a processor, let alone machine language.

We all make a bad assumption: software will be bug-free.  Almost every device you have is 1-3 bugs away from total compromise.Defect densisties re higher than we think.

For side channels, we mistakenly think that attackers only see the binary input/output data - not true! Power and RF measurements show tiny correlations to individual gates. 

Four properties for solutions to succeed. Hardware-based: it's the only layer where we know how to build reliable security boundaries. Deployable additively: legacy designs can't be abandoned, but ar e too complex to fix.  Addres your infrastructure: solutions that must address both in-device capabilities and manufacturing/lifecycle.  Best case: must have a very positive ROI. All stakeholders must benefit, and benefits must not depend on ubiquity.

We need to think about our security perimeters. If you put too much complexity in one boundary, catastrophic failure is more likely. We need to think like the military for how they store their ordnance - if one layer fails, nobody will have all of the munitions.

Software security is not scalable. No hope of eliminating bugs in existing software. CPU modes (like TrustZone, Ring0) haven't helped, despite decades of trying. Separate chips/modules only work for a small subset of uses cases - costly and distant from where security is needed.  He has the most hope fo ron-die security modules. 

Why? High performance, low power. When something is inside the die, it's cheaper to manufacture, lower latency, better performance.

The cost of putting in extra transistors to do security is largely immaterial today - and if you're bothered by it now, just wait 18 months. :-)

Chipmakers required solutions for in-device security and also solutions for enabling infrastructure. Cryptography Research's approach: CryptoManager Solution. Their CryptoManager protects the chip.

If you get twice the code, you aren't getting twice the most desirable features. You added the core features first!  BUT, by adding twice the number of lies of code, you're increasing complexity and adding bugs.

After all of these security breaches, some government agencies in other countries have switched back to the typewriter - it's more secure.

We have to come up with solutions, otherwise security risks will erase net benefits from new technology.  For example, what is the risk vs reward of having your air conditioner connected to Internet. It's great to have the repair automatically called when there is trouble, but does it create an attack vector into your house or office?

All of these security issues means job security for the people in this room, but we should sill try to do beter. :-)

Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Keynote: Current Issues in Cryptography

This year's conference has over 200 attendees from more than 18 countries and 18 sponsors. Oracle is one of them - we're sponsoring lunch today. :-)

Phil Zimmermann, Creator of PGP, Co-founder, Silent Circle

The last time I saw Phil speak was at DefCon2 - so I'm very happy to see him again!

Phil contested his introduction, which said PGP is the most widely used crypto software - because it's only for email, and nobody encrypts their email.  We don't have to worry about NSA cracking our crypto, because we're simply not using it.

People are more aware now that we are being watched, in part due to the revelations from Edward Snowden.The industry is coming up with new ways to push pervasive use of encryption.

Public Key infrastructure has spectacular failures, like an Iranian hacker subverting the system, turning over keys to the Iranian government, who then did man in the middle attacks against Iranian dissidents. 

Quantum computing is like nuclear fusion - we've been 5 years away from nuclear fusion for the last 50 years.  If we do actually get quantum computing, perhaps we'll actually get nuclear fusion! :-)

Phil's been thinking about quantum computing. When designing ZRTP, a protocol used for secure telephony, uses a federal Diffie-Hellman exchange and destroys the keys at the end of the call. There are elements in the protocol to deflect hackers - like only one chance to use a hash.

While we don't have quantum computing today, there's nothing to stop a government from storing your encrypted data from today to process later when computing power improves.  Intelligence agencies have a long term way of thnking and a lot of patience.

Had to develop ZRTP with the components he has at his disposal: DH ECC, and block ciphers.  Want to be able to set up new calls quickly, and still securely. Lots of things to think about here.

Zimmerman is finding that it's not just regular people wanting to hide their traffic from the intelligence community - corporations are worried, too.

Phil laments that we're losing our natural inclination for conversation privacy, thanks to the widespread use of telephones.  We shouldn't trust the phone companies. We should be able to still, essentially, whisper in each other's ears.

Even experienced cryptographers struggle to understand and explain trust models. Any crypto scheme that relies on the end user understanding a trust model will fail.  It needs to be so easy that anyone, even non technical people, can use it.

We focus on coming up with hard mathematical equations that wwe imagine our opponents factcing - but that's not how the NSA thinks about this.. They think of this as an engineering problem.  Thinking of harder math problems won't get us very far. They are fun, we feel smug - but that's not how the NSA works.

We have to think like the intelligence agencies - it can't just be about hard math.
 
 Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Validating a Virtual Module Without Guidance from CMVP

Steve Ratcliffe, TME, Cisco Systems

The concept of virtual computing came into being in the 1960s by IBM and MIT. It's come a long way since then - a long way just since 2001!  It is replacing physical machine infrastructures. The government is asking for this,  but there's not really any guidance from CMVP - so how do we do this?

Virtual systems are based on real physical normal systems, typically.  Is it hardware? Firmware or software?  CMVP will ask this question. 

Their system is built on op of hardware which is running an OS with executables. Then on top, a virtual OS with more executables and crypto modules. In between - the middle man - the hypervisor.

Webster defines virtual as not formally recognized, not real. But... we have it!

Think more about the difference between the brain and the mind.  The mind exists, but you can't touch and feel it like you can a brain. (ew!)

Customer love this - it takes less space and less power. What's not to love?

But, how do you test? Let alone validate?

Let's think about how FIPS 140-2 maps to the virtual world.

How do you define the boundary?  For software, we'd just identify the crypto module. But, as we're relying on the hypervisor - do we need to include that in the boundary?  It provides input into the virtualized environment, but it is not in the boundary.  Your boundary would be the same as it was on a non virtualized systems, just a bit different.

Firmware cannot be dynamically written or modified. Software can be, according to the CMVP. But, can you prove your virtual module is not modifiable? No... then you have a software module.

You don't own the hardware, you don't own the hypervisor, you don't own the firmware underneath - so you can't prove that the VMs are truly isolated.

What if the OS underneath is a trusted OS? Or you've created the hypervisor?

Situations vary greatly. 

[Note: I think we could have a different story on SPARC, where we do have one company that owns the chips, the hypervisor and the virtualization - but that's not a generic solution.]

The best you can easily get here is going to be level 1, unless you have specific hardware identified to provide physical protection - but then the physical layer is set, you can't change it. Doesn't buy you much.

Roles - keep it simple. Don't take stuff to CMVP that's going to cause them to ask questions :-)  There is an admin role that controls the hypervisor. That doesn't necessarily need to be in the security policy, but you better understand it. 

But, when does power-on start?  When the VM gets loaded, not when the hypervisor gets loaded.

Physical security? Doesn't really apply, as this is not a physical module! :-)

But... what is the operating environment?  We have an OS running on the virtual moduled. THis OS access is controlled by the hypervisor. The hypervisor could be controlling other VMs. Access to the hypervisor is still a questionable thing.

One of the requirements is you need to have a single operator mode of operation - CMVP says if you're in a server type setting, the server is the operator. [Note: huh?]  You have to say it's a server role - a process.   You do need to set this up as a protected environment. See IG 6.1 for more details.

A concern from the audience: what about entropy?  Could you starved by other VMs or by attacks on the hypervisor? These are all things you have to look at.

Key management should be just about the same. But, it's a little bit harder to talk about key storage,
like your keys will have to stay in the virtual module.

But, RNG is a very real concern. CMVP is recently really critical of this, though it really is a long term problem. Can you ask the hypervisor for entropy? We can't just trust everything.  Ideally, we like to get entropy from the hypervisor - but with a virtual system, it can't get directly to the hw entropy source.

Software entropy sources can be used to get around these unknowns - but is it as good?

There are multiple types of hypervisors: Type I and Type II. Type II is virtualization on top of a host OS (I would think about our classic zones).

VMware uses timing for entropy, KVM, XEN and Hyper-V are similar... but different. 

Each hypervisor should be treated as a new entropy process and source, each one should be tested and documented.

Hypervisor attacks are rare, but they are not immune. They are vulnerable at the network layer and from the host running on that hypervisor.

If they hypervisor is attacked, all of the VMs and the host itself are accessible to the attacker.  So, we really have to test these!

For self tests, you have to really think: when is power-on?  When the hypervisor starts?

Think also about how the module is delivered - with or without the hypervisor?

You may also want to address how you mitigate attacks against the hypervisor.

There is no guidance today, but that doesn't mean you can't validate. You just need to be honest and up front, and think about this in advance.

Last caveat: be careful what your sales team sells!  They probably won't understand FIPS and may sell an incorrect configuration.


Post by Valerie Fenwick, syndicated from Security, Beer, Theater and Biking!

ICMC15: Introduction to FIPS 140-2

Steve Weingart, Manager of Public Sector Certifications, Aruba Networks; Chris Keenan, Evaluator, Gossamer Security Solutions

FIPS area  series of U.S. Federal Information Processing Standards. Required by federal agencies, and recommended to state agencies. Financial companies are also requiring this. This is a joint scheme with Canada.

FISMA , put forth by George W. Bush in 2002, now makes it required.  The standard precludes the use of unvalidated cryptography in the federal government - it's considered "plain text" (ie no protection). If an agency violates this, they could lose their funding (though that hasn't happened, yet).

The CMVP, Cryptographic Module Validation Program, is a joint program between U.S. NIST (National Institute of Standards and Technology) and CSEC from Canada. The logo for a validation is the 50 stars for the US with a Canadian maple leaf on the front. :-)

The US Government is not staffed to do all of this testing, so they let accredited  labs do it (NVLAP, National Voluntary Laboratory Scheme).  Then NIST can review the results. The labs are checked out every 2 years, including verbal tests.

The labs are not allowed to do any consulting, to prevent conflict of interest.  This is different than Common Criteria.  You can use a lab as a consultant, but then you need to use a different lab for your testing.

FIPS 140-2 is a conformance test, not a evaluation.

It is a back and forth process - never linear.

A cryptographic module is defined by its: Security Functionality and boundaries.  Choosing your boundary is extremely critical, particularly when it comes to making changes after you go into the process or have your certificate. A crypto module can be embodied in hardware, software, firmware or a hybrid.

Your goal is to protect against unauthorized use and unauthorized disclosure of secrets. We also want to make sure that the code has not be modified (integrity check) and prevent insertion and deletion of keys (critical security paramaters or CSPs).

History - we had Federal Standard 1027 in 1982, focusing on making secret phone calls.  then they started thinking about crypto, they turned 1027 into FIPS 140. Nothing was validated against it.  Eleven years later, we got FIPS 140-1 in 1994. It is meant to be reviewed and renewed every 5 years.  In 1999, the review started of FIPS 140-1 and we got FIPS 140-2 in 2001 - just a bit behind schedule.  There was a FIPS 140-3, but it seemed to get buried in the comments.

Then in 2006, work started on ISO/IEC 19790 - second edition came out in 2012. It's come up that ISO/IEC 19790 may become FIPS 140-3.

As you can see, we're behind on updates. [Note: and boy has crypto technology and CPU technology changed a LOT since 2001!]

There is the base document, FIPS 140-2. Read it once, keep it handy - but it won't be your end all guidance.  Focus right now is on Annex A (approved security functions), Annex B (approved p rotection profiles), Annex C (approved RNG) and Annex D (approved key establishment techniques).

Appendix B is pretty empty, as FIPS 140-2 has become detached from common criteria.

DTRs (Derived Test Requirements) is your daily document, that and Implementation Guidance.  Some people think the IG is more important than the DTRs - not true, both important.

If we do switch to ISO/IEC 19790, then the IG should revert to a blank document.

Each area in a module is validated between security levels 1-4.  The Overall Security Level is the lowest level awarded in any of the levels.  Most people just validate all components at the same level, but some customers (like the US Postal Service) will specify higher levels required for some functions.

There are eleven major functional areas. Some are very broad, others, like EMI/EMC are very hardware specific. All of these requirements are hard to "paste on" later.

You can claim "bonus" things - like doing RSA operations in constant time. In order to claim it, your lab has to prove it. Once approved, it can be listed in your certificate.

You must define all entry and exit points. Data Input, data output, control input, status output.  At levels 3 & 4, physical ports must be physically separate.

A cryptographic module shall support authorized roles for opraors and corresponding services within each role. Multiple roles may be assumed by a single operator. If a crypto module supports concurrent operators, then the module has to maintain and track this.

Authentication mechanisms may be required within a cryptographic module to authenticate an operator accessing the module, and to verify that the operator is authorized to assume the requested role within the service of that role.

If you're level 1, no access control is required. Level two is role based, level 3 & 4 have identity based requirements.

You have to actually produce a finite state model. This is easier for old hardware engineer. You can't be in multiple states at one time. Think about the fatal error state: pretty much all states should fail there, if something goes wrong.  This is a bit different with ISO/IEC 19790, where you only have to shut down the stuff having problems.

For physical security, thanks to the credit card breaches from last year, we all have a single chip module in our pockets! (Smart cards embedded in our cards). For level 1, you can get away with using commonly available, well known chips.  A very common thing to use level 2 is a label that is torn if the sytem is opened or tampered with.  Of course, this means hackers, etc, have been focusing on how to remove labels and reapply them with no evidence - so sticker makers have had to step up.

At level 3, you could dip in epoxy or have a pick resistent lockable case.

For level 4, the lab can use ANY method they can imagine to attack your module. This is really, really hard. Do you have a good reason to get this?

There are requirements around the operational environment - the OS your module runs on.  The most common environment is a regular OS. Anything over level 1 is hard, you'll need signed updates and integrity checks. At level 2 and above, folks tend to use a non modifiable operational environment.

Key Management is a big one! Entire life cycle of the key - how are they created? where do they go? Can they be moved? How are you wrapping them?

Key management covers RNG and key generation, key establishment, key distribution, key entry/output, storage and zeroization. You can use the key management of another module.

This can be a problem with compiler optimizations - they will "help" you and leave you key in memory.

There are EMI (Electromagnetic Interference) and EMC (Electromagnetic Compatibility) requirements. EMI is to make sure the module doesn't interfere with other equipment. For EMC, in general, and FCC part 15 class A or B certificate is needed. WARNING: there are lots of fake FCC certificates and counterfeit labs out there.

This can be important as we're now having people analyze EMF signals to predict key materials.

Power up self tests require that you test everything when you start up. If the module fails, then it must enter an error state. All of the operations must be tested "one way" - that is, you cannot encrypt data and then decrypt it and claim success - that only proves you created a reversible operation, not that you're actually doing AES, for example.

There are also conditional tests - when a specific operation is invoked that requires it, like key generation or using random numbers. Again, if it fails - it must enter a failure state and do no further operations.

This will be a little "lazier" in ISO/IEC 19790. Currently, all tests must pass before you do anything. In ISO/IEC 19790 you'll be able to start using SHA2, for example, as soon as it's testing is done - even if other tests are still running.

To prove you've done it correctly, you have to prove to the lab that you can trigger the failure.  Some add a special flag that will always fail, or make a special version of your code that always fails.

For desgn assurance, you need to use the best practices by your developers during the design, deployment and operation of a cryptographic module - like coding standards, reviews, etc.
 
You can claim mitigation of attacks - this is optional - like shielding, timing attacks, etc. While optional, the lab has to verify it/witness it.

Okay - that's all done, what next?  Laboratory testing!

This is where the Derived Test Requirements (DTR) come in - repeatable and testable conformance. If you gave this module to any one of the 23 labs, it will pass or not pass for all of them.

Each entry in a DTR has 3 parts: the assertion (a direct quote from the FIPS 140-2  standard), requirements against the vendor to prove it, and finally a set of requirements levied on the tester of the module (ie the lab).

When you go through Cryptographic Algorithm Validation, it will prove you are using an approved algorithm in its approved mode of operation.  It can be a longer process, as you have to write a test harness, but the interaction with CAVP tends to be faster.

There is a NIST CAVS tool - but only the labs can see/use this tool, not you as a vendor. The lab generates test samples and sends them to the customer. The customer uses the samples as input and generates the cryptographic output, the customer returns the results to the lab. The lab checks the restults and if they mach, submits the results to the CAVP for the certificate.  You should have your own harness that takes the arcane CAVS input to verify your modules quickly as you're doing you work.  There are sometimes small variations you need to do.

Important things to remember: encryption and decryption are tested separately. in Counter mode, the test is performed on ECB mode and then the counter design is examined separately. t must be shown that a particular count can only be used once with a key.

If you want to limit the testing and churn, keep your boundary very small so you can reuse it.

If you have non cryptographically relevant changes, you can do a change letter (1SUB) - those can be very quick through CMVP, but your lab will have to review your code diffs and do some regression tests (so not free).  A partial revalidation (30% or less of your module has changed) will require a partial retest.  If you've changed more than 30%, then a full revalidation is requited.

Correctly and optimally defining your crypto boundary is the single most important decision you can make. Make it as SMALL as possible - but you can't leave things out!

This post by Valerie Fenwick, syndicated from Security, Beers, Theater and Biking!