Corsec immediately began to engage with NIAP, our customer base, our network of testing labs, and contacts within various standards certifying bodies; seeking clarification on the announcement (referred to as “Labgram #106” and “Valgram #126”) to determine the impact it would have on our customers and to the industry as a whole.

Corsec recognized that there were inherent issues with the policy, and presented these concerns to NIAP. After weeks of collaboration, NIAP agreed to rescind the Labgram and on October 31, they made the following official announcement: “NIAP has decided that Labgram #106 will be archived and no part of it will be enforced.”

As a result, Transport Layer Security (TLS) cipher suites with RSA key agreement/key transport will continue to be accepted for use within National Security Systems for the foreseeable future (the full text of NIAP’s announcement can be found here). This announcement did provide valuable insight into NIAP’s thoughts regarding the use of TLS in National Security Systems. Corsec believes that NIAP will revisit this issue, potentially after updates to NIST Special Publication 800-56 are completed.

Corsec continuously monitors all industry announcements to ensure that our customers remain informed and advised on all policy and standards changes. If you have concerns about how changes in the industry may affect your existing certification or future certification strategy, please Contact Corsec for more information.

You can also stay up to date on news and updates to standards, certifications, and requirements by subscribing to our emails and newsletter, as well as following us on social media:

What do vendors have to do to meet the entropy testing requirements?

Vendors must prove to the testing laboratories that their entropy source conforms to the requirements in NIST’s Special Publication 800-90B. In general terms, this requires:

• Identification and specifications of the entropy source
• Identification of whether the entropy is independent and identically distributed (IID) or non-IID
• Justification as to the randomness of the entropy
• Subjecting a sampling of the entropy to statistical testing
• Proof that adequate health tests are implemented

If vendors are using third-party modules for their products, it’s best to choose those where access to information about sources of entropy is available. If a module has already been chosen, start a discussion with the third-party provider on how to best approach the entropy testing process. The key is that in the design process, vendors should look for solutions where they can get entropy that is as random as possible.

While nothing is guaranteed at this stage, our experience has shown that when accurately demonstrated, NIST generally accepts the justification of sufficient entropy stemming from the character device /dev/random, available in the Linux-based pseudo-random number generator (PRNG). The counterpart in that Linux-based PRNG, /dev/urandom, however, is not currently allowed by NIST due to its non-blocking characteristic.

Is there a way for product vendors to perform entropy testing on their sources before they enter into evaluation?

Unfortunately, there is really no way to know if a vendor will pass entropy testing at this stage. The most that can be done is to present arguments to a certification body, but because this is such a new area, there is no way to know for certain that an argument will stand up and something will pass.

There are test tools available that are helpful, and running a sample entropy output through one of these test tools can certainly give an indication of the sufficiency of the entropy source. A vendor can independently perform its own entropy testing against the NIST publication SP 800-90B—this is the gold standard right now. (The applicable concepts required to gauge whether the entropy source is sufficient are all outlined in that publication.) Vendors may, however, need some consulting help from a Cryptographic Security Testing laboratory for that. Engaging with a consultant early on may also help identify any red flags that could hold up the process (for example, the use of dev/urandom).

What tools can be used for entropy testing specifically?

No officially sanctioned tool exists for entropy testing. As it stands, the Cryptographic Security Testing laboratories are responsible for measuring entropy samples using their own methods and tools. Several third parties have created their own tools for entropy testing. Some tools are available in the public domain, and incorporate some or all of the NIST SP 800-90B requirements.

For instance, the Python testing tool is available upon request from CAVP to labs and vendors for entropy testing. It is a fairly primitive program, but can be useful and at some point there will be a GUI interface for it.

At this point in time, the Common Criteria schemes do not rely on the entropy testing tools, and including output in the Entropy Assessment Report is entirely optional.  Our experience indicates that CSEC (Canada) and NIAP (U.S.) are more interested in an explanation that the input to the entropy source (i.e. noise source) contains sufficient entropy itself to justify the encryption strength of the resulting keys that the TOE will generate. Any use of the tools would have to focus on the noise source data, which is problematic. Measuring the output of the entropy source, after post-processing of the entropy has occurred, does not appear to be acceptable.

How do you deal with third-party entropy sources if the vendor does not have access to all internal technical details?

It’s possible that a vendor may not have the source code or design information regarding the entropy source. Typically, if the entropy source is a True Random Number Generator (TRNG) such as one might find on certain processors, there may be sufficient specifications from the manufacturer detailing the product, such that the requirements of NIST SP 800-90B could be addressed.

Are vendors required to use a hardware noise source for entropy generation to be FIPS 140-2 validated or CC validated against a NIAP PP?

The use of a hardware noise source isn’t a requirement, but it is highly recommended. The entropy source identified by the vendor will be tested per the requirements of NIST SP 800-90 (as well as any supplemental FIPS or CC programmatic guidance), and an entropy testing verdict will be rendered.

Entropy that is found to fail the mathematical testing outlined in NIST SP 800-90, or entropy sources that contain inadequate health testing, will be considered insufficient by the laboratory.

While not required, there are some benefits to using hardware noise sources. There are commonly available hardware-based entropy sources that are built in to some CPUs (for example, Intel’s Ivy Bridge processors). These hardware-based solutions have been found to produce quality entropy very quickly, so are ideal for use in systems where the entropy pool can become quickly depleted.

How long is the process of evaluating entropy adding to evaluations?

For FIPS, the CMVP requires a report containing justifications, so it can add about a week of lab time onto the process — this includes all the components involved: source code review and writing the entropy justification. On the vendor end, there is then additional time. Because this is fairly new guidance, we can’t always estimate what CMVP will require. Labs are providing the information we believe we’re being asked for, but we’ll have a better feel for what is truly required in the future.

For Common Criteria in the U.S., there has been a starting gate implemented requiring that the entropy source be evaluated and approved prior to a vendor actually starting a CC evaluation. Turnaround times will likely improve, however the impact here is potentially quite large – for now one should assume a two-month to three-month delay waiting for entropy review. Because it’s so new, we’ve only just had our first submission approved in Canada, which fortunately occurs in parallel with the rest of the evaluation and therefore has less of an impact.

Panel members from Computer Sciences Corporation (CSC) are:

Lachlan Turner is the Technical Director of CSC’s Security Testing and Certification Labs with over 10 years of experience in cyber security specializing in Common Criteria. Lachlan served as a member of the Common Criteria Interpretations Management Board (CCIMB) and has held roles as certifier, evaluator and consultant across multiple schemes – Australia/New Zealand, Canada, USA, Malaysia and Italy. Lachlan provides technical leadership to CSC’s four accredited CC labs and is passionate about helping vendors through the evaluation process to achieve their business goals and gain maximum value from their security assurance investments.

Jason Cunningham leads the FIPS 140-2 program at CSC and has over 10 years of experience in IT security. Throughout his career, Jason has been involved in numerous security related projects covering a wide range of technologies.

Maureen Barry is the Deputy Director for CSC’s Security Testing and Certification Labs (STCL) and primarily manages the Canadian laboratory.  She is also a Global Product Manager responsible for developing, managing, and executing the Cybersecurity Offering program for STCL across four countries: Canada, USA, Australia and Germany.  She has almost 10 years of experience in Common Criteria in addition to over 10 years of experience in IT.

Corsec Lead Engineer Darryl Johnson was also a member of the panel discussing entropy testing and contributed to the writing of this post.

For help with your FIPS 140-2 or Common Criteria evaluation, or if you have questions about entropy testing and how it might affect your next evaluation, contact us.

I had the opportunity to discuss entropy with the great group over at Computer Sciences Corporation (CSC). The panelist included Lachlan Turner, Jason Cunningham, and Maureen Barry. In our first of a two-part series, our panel answers some questions to offer insight into what you need to know about entropy and how it could affect your Common Criteria or FIPS evaluation.

What does entropy mean?

The term entropy loosely translates to, “The degree of disorder or randomness in a system.” This is how we describe entropy in computing, although the term is also used in thermodynamics. For our purposes, however, it is the random data collected from electronic sources, for use in computing applications.

Entropy is a measure of randomness often expressed and measured by bits. The more entropy you have feeding into a given value, the more random that value will be.

Why is entropy receiving so much attention when programs are already testing cryptographic algorithms?

The self-tests implemented to test cryptographic algorithms are considered to be a health check, which ensures that they can mathematically and procedurally operate as they were intended to. This concept is different from that of entropy testing.

Most modern day cryptographic implementations rely on the use of sufficiently random data in order to ensure a high degree of secrecy when establishing shared secrets, or creating the data required to generate cryptographic keys. The random number generators that typically rely on this input to be random can only produce sufficiently random numbers if the input they require also contains a high degree of randomness. The entropy serves as that high degree of randomness.

When it comes to entropy, an old saying applies. “You will get out of it, what you put into it.” Since the quality and quantity of entropy is the foundation of cryptography, it’s vitally important that entropy be considered as part of the testing process.

What challenges do vendors face when trying to measure their product’s entropy?

The information coming from NIAP, CMVP, and the other validation program bodies is that vendors have to understand what sources contribute to their product’s overall entropy and how many bits of entropy are contributed by each source.  That can be quite difficult. Quite often the crypto modules that are used in products are created by third parties, and vendors don’t really know what happens “under the hood.”

Another challenge comes from the need to measure the entropy at the appropriate point in the overall process.  Many systems will take a value produced from entropy sources and “condition” it before using it as input to the random number generator.  However, testers want to see entropy measurements performed on the pure, pre-conditioning value, but these values cannot always be captured.

What are the requirements for entropy in Common Criteria and FIPS evaluations?

Thus far, the entropy requirements for CC and FIPS have only been loosely defined through draft publications. That is not to say, however, that there isn’t a framework in place. The Computer Security Division at NIST has completed a publication that encompasses the testing of entropy. It is anticipated that the concepts in the publication will soon form the basis of all future entropy testing for FIPS 140-2 (and possibly Common Criteria).

From a Common Criteria perspective, there is an NIAP-approved Protection Profile (PP) and within that PP is an annex with an entropy profile. From a practical standpoint, a vendor has to describe the entropy; that is, the vendor needs to document what entropy source is actually producing random data. Examples could be ring oscillators, keyboard key presses, noisy diodes, mouse movement, or disk input/output operations. The requirements are to describe what the sources are and then describe what is done with those random event values (i.e., what is done to condition them), and what is the interaction between the entropy source and the crypto module. There are also requirements around health testing.

In the end, vendors are required to provide a justification (supported either by test data or mathematical models) that demonstrates how many bits of entropy are being generated.  That justification must include a good argument for why it’s sufficient. This justification area is currently evolving and is a bit grey.

For FIPS, things are very similar to Common Criteria. The CMVP released guidance that says any type of analysis that provides information regarding sufficiency of a crypto module’s entropy will be considered — they understand that there is no perfect way to quantify it.  Statistical analyses can be conducted or source code can be analyzed to mathematically support a vendor’s claim that their entropy is sufficient for generating random numbers. NIST doesn’t really come right out and call it entropy. This process is part and parcel to the strength of the key generation method. They want to know everything that happens before the data goes to an approved RNG.

There is quite a bit of confusion right now about entropy — hopefully, we can clear a bit of it up. In our next post, we’ll dive a bit further into entropy testing, touching on what vendors need to do to meet the entropy requirements, what entropy testing tools are available, and how much time entropy testing is adding to evaluations.

Panel members from Computer Sciences Corporation (CSC) are:

Lachlan Turner is the Technical Director of CSC’s Security Testing and Certification Labs with over 10 years of experience in cyber security specializing in Common Criteria. Lachlan served as a member of the Common Criteria Interpretations Management Board (CCIMB) and has held roles as certifier, evaluator and consultant across multiple schemes – Australia/New Zealand, Canada, USA, Malaysia and Italy. Lachlan provides technical leadership to CSC’s four accredited CC labs and is passionate about helping vendors through the evaluation process to achieve their business goals and gain maximum value from their security assurance investments.

Jason Cunningham leads the FIPS 140-2 program at CSC and has over 10 years of experience in IT security. Throughout his career, Jason has been involved in numerous security related projects covering a wide range of technologies.

Maureen Barry is the Deputy Director for CSC’s Security Testing and Certification Labs (STCL) and primarily manages the Canadian laboratory.  She is also a Global Product Manager responsible for developing, managing, and executing the Cybersecurity Offering program for STCL across four countries: Canada, USA, Australia and Germany.  She has almost 10 years of experience in Common Criteria in addition to over 10 years of experience in IT.

Corsec Lead Engineer Darryl Johnson was also a member of the panel discussing entropy testing and contributed to the writing of this post.

For help with your FIPS 140-2 or Common Criteria evaluation or for additional questions about entropy testing and how it might affect your next certification, contact us.

ICMC was held September 24 – 26^th this year in Gaithersburg, MD. The first day contained pre-conference workshop sessions that offered introductions to FIPS 140-2, side-channel analysis and testing, and discussions about cryptography in a mobile world. The second and third day offered two tracks: the certification program track and the technical track. I’m just going to discuss the conference as a whole and where I believe and hope it is going.  If you would like to know more about the presentations, there are already several fantastic recounts of the each workshop and the extremely qualified presenters. Information can also be found on the conference website.

Unsure of what to expect for a first-time conference, especially one that sounded so technical, I was pleasantly surprised to see the number of representatives from both government (including NIST and CSEC) and private industry (including Blue Coat, McAfee, Symantec, and Cisco).  Attendees hailed from across the globe, including the U.S., Canada, the U.K., France, Japan, and Korea.

The Certification Programs Track, focused on FIPS 140-2 and CMVP validation program requirements and related topics. The technical track dug more into the nitty-gritty of cryptography, including fault injection and key management.  Presentations ranged from extremely technical, such as the discussions on entropy or Test Vector Leakage Assessments, to the non-technical, “Everything You Wanted To Know About Labs, But Where Afraid To Ask” panel session.  Each track was equally attended and offered energetic discussion.  There really were some great presentations. We even received an update on FIPS 140-3. More on that in a later blog post.

A great deal of the credit for such a positive conference experience goes to the host. Atsec Information Security, and Program Chair Fiona Pattinson in particular, did a fantastic job with hosting this conference. Fiona and her team set the informal tone early and kept it relaxed yet on schedule, throughout. It ran smoothly and was intimate, informative, and enjoyable. It was three days of getting together with some of the best minds in cryptography to discuss (and at times disagree about) the subject attendees are passionate about.  You know you’ve attended a good conference when you leave thinking about next year.

As I mentioned, planning for ICMC 2014 is already taking place. Early in October, a survey was sent to the more than 120 registrants from ICMC 2013. Questions soliciting feedback on the sessions and conference location were asked to determine what worked and what could be improved upon for next year. The results were collected and Fiona and a group of 12 others (including myself) have begun a series of conference calls to discuss the who, when, and where of next year’s conference. The committee meets via these calls every two weeks and will continue to do so leading up to the event. The first meeting was held last Friday to discuss the survey results, selecting a location for next year’s conference, dates, and schedule. Although there has been only one meeting, if that one meeting is any indication, ICMC 2014 will be an even bigger success than the inaugural conference.

To find out more about FIPS 140-2, follow Corsec on Twitter, LinkedIn, or subscribe to our blog

Many of the changes that are going on programmatically are just not relevant to the macro decisions that product vendors need to make for certification. While these changes might impact these decisions slightly, the main business drivers for certification do not change very quickly. As certification insiders, we tend to focus on the new and interesting things in our industry. If you are waiting for the change to stop before making a decision on certification, you will be waiting a long time indeed. In fact, many of your competitors will have leapfrogged you by completing their certifications while you are paralyzed with inaction.

The Common Criteria community is currently undergoing significant change. There are new Protection Profiles, new Technical Communities, new guidance from several schemes on what types of evaluations are acceptable, new requirements for entropy for certain evaluations. These changes are causing a lot of confusion. However, these “changes” are being made more rapidly than most product purchasers even understand them. Furthermore, some of these changes have been announced, rescinded, and a new change announced all in less time than a product could have gone through the certification process! However, through all of this, product vendors are successfully achieving certification of their products and meeting their customers’ needs.

The Cryptographic Module Validation Program, also known as FIPS 140-2, is also undergoing change. The new FIPS 140-3 standard is still in development. Recent implementation guidance can seem to change the rules for many product types.  Navigating a path through these changes can be difficult at times. However, product purchasers still require validated products, and product vendors who navigate this process are rewarded with more opportunities to sell their products.

The DoDIN APL process has probably undergone the least amount of change from a programmatic standpoint as far as my customers are concerned, but the most significant change from a sales applicability standpoint. More and more procurements are requiring products to be listed on the DoDIN APL. Understanding this and being aware of the trends for purchasing requirements is important in making a business decision around pursuing a product listing on the DoDIN APL.

After more than 15 years in the certification business, I have seen several periods of change similar to the one we are in now. As another great philosopher, Yogi Berra, once said “It’s déjà vu all over again.” Businesses that embrace change and navigate it skillfully have historically done well in this marketplace. Businesses that are paralyzed by change are often still waiting for the change to settle down while their competitors are successfully selling their already validated products.

Change is constant. Let Corsec help you through the today’s changes in the certification industry so that you can realize the true revenue potential in your products. Find out how we can help.