atsec’s ACVT service is operational

atsec is proud to announce that the Automated Cryptographic Validation Testing (ACVT) service is operational.

The atsec Cryptographic Security Testing (CST) laboratory is the first ever to achieve operational status with the Automated Cryptographic Validation Protocol (ACVP) production server operated by NIST. atsec's ACVP tools are fully implemented and functional. After the test results for all types of algorithm testing offered by the ACVP server were validated by NIST, atsec’s CST lab was granted access to the ACVP production server. atsec performed the algorithm testing on its SHA and HMAC implementations used in the atsec ACVP Proxy, which is the very first ACVT project to demonstrate that the NIST ACVP production server is now in business.

With this privileged access, the atsec new service uses the ACVP production server to automate the process of testing the implementation correctness of cryptographic algorithms and related functions, and offers a much more efficient and effective process in the awarding of certificates by NIST.

Certificates of implementation correctness are awarded by the cryptographic algorithm validation program; these certificates being required as a pre-requisite for cryptographic module validation as well as for Common Criteria evaluations in the U.S.

Mr. Stephan Mueller, one of atsec’s Principal Consultants, has worked closely in the development of the client program to test the NIST ACVP demo server, which has greatly helped NIST’s successful launch of the ACVP production server. He commented on this collaboration between atsec and NIST.

“NIST is to be congratulated on this important milestone in the development of the ACVT program. A program which provides assurances in the security of IT systems implementing cryptography as well as supporting developers by providing the capabilities to test in synch with modern development timescales.”

Dr. Yi Mao, atsec Laboratory Director, also commented.

“We applaud NIST’s initiative in launching the ACVT program and are proud of assisting them in achieving this historically significant milestone. Cryptography is the hard core that provides information security. Automated testing is the way forward to sustain the high demand of the much-needed assurance at the core of security. It’s an extremely exciting moment, and empowered with ACVT, we can immediately benefit our existing and new customers by taking their algorithm validation down a fast path.”

Find out more at:
atsec’s cryptographic algorithm testing service page.
NIST’s Automated Cryptographic Validation Testing (ACVT) project.

Collaboration and Openness to the Rescue of Entropy

This past September was my conference month. I first went to the 14^th International Common Criteria Conference (ICCC) in Orlando, Florida and then a week later I was at the 1^st International Cryptographic Module Conference (ICMC) in Gaithersburg, Maryland.

The theme of the ICCC this year was a collaborative approach. The conference directed the CC community to adopt the Collaborative Protection Profile approach (cPPs). The task of the protection profile development and maintenance is shifted from the CC Development Board (CCDB) to various Technical Communities (TCs). TCs are expected to gather experts from the Industry, Government, and Academia to ensure the cPPs stay current in the world of fast-evolving technologies. The CC User Forum (CCUF) will be playing an increasingly important role facilitating the communication between the cPP consumers and cPP developers.

The opening speech of the ICMC was delivered by Charles H. Romine, Director of the Information Technology Laboratory at NIST. Openness of NIST was the core of the speech. NIST has held open competitions for AES and SHA-3. NIST even reopened the public comment period for SP 800-90 series of crypto standards in the interest of openness to give the public a second opportunity to view and comment on the standards. NIST acknowledges the challenges (e.g., such as several-month long review pending queue) that the Cryptographic Module Validation Program (CMVP) is facing and invited all ideas from the audience and public for improvement.

One of the common features of both conferences was the heated discussions on RNG and entropy. The ICMC had three presentations devoted to this topic:

• How Random Is Random?, Helmut Kurth, Chief Scientist, atsec information security
• Entropy: Order from Disorder, Tim Hall and Apostol Vassilev, NIST
• SP 800-90 – Reviewing The Standard, Stephan Mueller, Principal Consultant and Evaluator, atsec information security

The ICCC had the following presentations on general cryptography, as well as RNG and entropy in particular:

• Cryptography and Common Criteria, Chris Brych (Safenet Inc.) and Ashit Vora (Cisco Systems Inc.)
• Modeling of Cryptographically Secured Channels (IPsec, SSH, TLS, DTLS) in ST/PP, Fritz Bollmann, German Federal Office for Information Security (BSI)
•  A New Evaluation Method for RNG, Ülkühan Güler, National Research Institute of Electronics and Cryptology, Turkey
• Entropy Sources – Industry Realities andEvaluation Challenges, Sonu Shankar, Cisco Systems, Inc.

The number of presentations at both conferences was not surprising since more and more Target of Evaluations (TOEs) rely on cryptographic support (i.e., class FCS functionality) for user authentication, data protection, secure communication, and trusted path/channels. Assessing the security strength of cryptographic algorithms and keys has become indispensable for the vulnerability assessment of a TOE.  The Random Number Generator (RNG) that provides the random source for a key determines the quality of the generated keys. A predictable RNG could lead to the downfall of the entire system. To avoid this Achilles’ heel, it’s crucial to have a well-designed and properly-tested RNG and entropy source.

COLLABORATION?

Both CC evaluations and FIPS 140-2 validations require scrutiny of the entropy source.  For example, Annex D of the U.S. Network Device Protection Profile (NDPP) v1.1 provides requirements for entropy documentation and assessment. The documentation of the entropy source is expected to be detailed enough to include the following:

• Design Description
  Documentation shall include the design of the entropy source as a whole, including the interaction of all entropy source components.
• Entropy Justification
  There should be a technical argument for where the unpredictability in the source comes from and why there is confidence in the entropy source exhibiting probabilistic behavior (an explanation of the probability distribution and justification for that distribution given the particular source is one way to describe this).
• Operating Conditions
  Documentation will also include the range of operating conditions under which the entropy source is expected to generate random data.
•  Health Tests
  All entropy source health tests and their rationale will be documented.

The CMVP is working on an Implementation Guidance (IG) on entropy analysis. The draft version has already been circulated among accredited labs for review and comments. Vendors can also provide feedback through their representing labs. Although the CMVP is still working on incorporating the feedback received from labs and vendors, the following requirements stated in the draft IG will likely remain unchanged in the final version, which currently states the following:

• The documentation shall contain a detailed logical diagram which illustrates all of the components, sources, and mechanisms that constitute the entropy source.
• The statistical analysis has to be performed on the raw, non-conditioned data. The testing lab is responsible for choosing the statistical tests and justifying their selection. Further, the lab shall explain what the result of each test means and how this result can be justified.
• A heuristic analysis of an entropy source along with the justifications of the entropy claims based on this analysis. This analysis shall always be included in the test report.

In theory, a thorough analysis on the entropy source coupled with some statistical tests on the raw data is absolutely necessary to gain some assurance of the entropy that plays such a vital role in supporting security functionality of IT products. While the statistical tests are useful to detect the patterns in the input data and hence to alert for low entropy cases, their passing results do not at all prove that there is sufficient entropy in the input data. For example, a sequence of 20-byte bit-strings obtained by consecutively applying SHA-1 function as a pseudo randomizer to an initial 20-byte of 0 bit-string may well pass all sorts of statistical tests, but it is obvious that there is no entropy in the 20-byte of 0 bit-string to start with. Therefore, the statistical tests alone cannot justify the seemingly randomness in the output strings. The statistical tests performed on the conditioned data are even more removed from reflecting the adequate entropy of the initial random value. If one is seriously investigating the entropy source to gain a certain level of assurance regarding its quality, then the requirements set forth for CC evaluation or FIPS validation are appropriate.

However, the requirements of entropy analysis stated above impose an enormous burden on the vendors as well as the labs to an extent that they are out of balance (in regard to effort expended) compared to other requirements; or in some cases, it may not be possible to meet the requirements.

The TOE Security Assurance Requirements specified in Table 2 of the NDPP is (roughly) equivalent to Evaluation Assurance Level 1 (EAL1) per CC Part 3. This is a rather bizarre phenomenon! The NDPP does not require design documentation of the TOE itself; nevertheless its Annex D does require design documentation of the entropy source--which is often provided by the underlying Operating System (OS). Suppose that a TOE runs on Windows, Linux, AIX and Solaris and so on, some of which may utilize cryptographic acceleration hardware (e.g., Intel processors supporting RDRAND instruction). In order to claim NDPP compliance and succeed in the CC evaluation, the vendor is obligated to provide the design documentation of the entropy source from all those various Operating Systems and/or hardware accelerators. This is not only a daunting task, but also mission impossible because the design of some entropy sources are proprietary to some OS or hardware vendors.

The vendors pursuing cryptographic module validation under FIPS 140-2 are facing the same challenge. While software modules often rely on the operational environment to provide an entropy source, hardware modules may use the third-party provided entropy source in an Integrated Circuit (IC). But regardless of whether the module is hardware or software based, the design documentation of the third-party provided entropy source is often not available. In addition, there is no externally-accessible interface to the third-party provided entropy source that would enable accessing the raw non-conditioned random data for statistical tests. These interfaces are inaccessible due to their security architecture, which if they were accessible, these interfaces may become an attack surface susceptible to the malicious manipulation of the entropy source.

In cases where the entropy source is from some open source OS such as Linux or perhaps even designed by the vendor themselves, the vendor may be able to provide the design documentation and raw non-conditioned data for test. However, this places a heavy burden on the testing labs to provide justifications for their methodology (e.g., selection of statistical tools) and then provide the analysis based on the justified methodology. Many labs raised their concerns at the ICMC that a task of this nature requires mathematicians with doctoral degrees and goes beyond the scope of the conformance testing that the cryptographic module validation program is bound to.

As we can see, from the requirements for entropy source to the fulfillment of these requirements, there is a giant leap. Asking each vendor and each lab for each CC evaluation or each FIPS validation to meet the requirements of entropy source as stated in the Annex D of the NDPP or in the draft FIPS 140-2 IG is a monumental task not commensurate with the expected effort, and even then the proposed result would still be beyond reach.

Instead of requiring the vendors and labs to find solutions for the entropy issue on their own, NIST should play a leading role not only in setting up the requirements but also in establishing a path to meet the requirements. Vendors and labs can join this effort led by NIST to put the necessary infrastructure in place, before expecting vendors and labs to evaluate the quality of the entropy. Here are some thoughts on how to establish such an infrastructure:

• NIST may hold open competitions for acceptable entropy sources and entropy collection designs with reference implementation in commonly-seen categories such as linear feedback shift registers (LSFRs), noisy diodes, thermal sampling, ring oscillator jitter, CPU clock readings, various human-induced measurements (e.g., the time intervals between the keystrokes). The end result would be a list of NIST-recommended entropy sources and their corresponding entropy collection mechanisms. Just like NIST-approved algorithm standards, the NIST-approved entropy source standard would regulate the entropy source design and implementation.
• NIST should set up test criteria (e.g., operational conditions, pre-requisites, variable lengths) and provide test tools to the accredited testing labs for validating entropy source. Just like the Cryptographic Algorithm Validation Program (CAVP), this can be Entropy Source Validation Program (ESVP).
• NIST would maintain a validation list for all of validated entropy sources.
• CMVP and NIAP (or perhaps even CCRA members) would reference the entropy source validated list.

With this infrastructure in place, the steep entropy requirements are broken down into several steps. The OS vendors and IC vendors, if they provide entropy source in their products, will be motivated to undertake the entropy source validation and make their product available on the NIST validation list. Vendors who need to make use of the third-party entropy source can look up the NIST validation list and make an appropriate selection. Labs performing the testing on the entropy source would use the provided test methodology and tool for the entropy source producer, and check the validation list for the entropy source consumer. After establishing the above-described infrastructure, the testing of the entropy source and maintenance of the validation list are manageable steps for the labs and vendors to follow.

One may say that it sounds like a plan, but that’s easier said than done. I hope with NIST’s openness and NIAP’s collaborative approach, it is possible to rescue the vendors and labs from the currently impossible entropy requirements.

By: Dr. Yi Mao

A Dragon or a Worm?

According to the Chinese Zodiac calendar, 2012 is the Year of the Dragon. It has been long believed in Chinese culture that some “special” things of immense importance are assumed to happen in a dragon year. After attending the ICCC 2012 in Paris, I immediately realized that one such “special” thing that had happened was the announcement of the CCRA vision statement. The Chinese prophecy about a dragon year was manifested even from the commencement of CCRA - itself a seminal document that was published in 2000, which was another Year of the Dragon.

Article 2 of the CCRA states that the scope of the arrangement covers claims of compliance against any of the Common Criteria assurance components required for Evaluation Assurance Levels 1 through 4. This scope of arrangement has remained unchanged in twelve years until the recent announcement of CCRA vision statement. Although a full consensus on the entire statement has not yet been reached as noted in Double Vision by Sal la Pietra, it undoubtedly points to the future direction of CCRA.

The proposed fundamental changes are expressed most noticeably in item 5 of the vision statement: “Whenever applicable, cPPs should be applied instead of individual STs. The application of STs should be reserved for cases where cPPs do not exist or are not applicable and CCRA mutual recognition should be limited to EAL 2.” The changes are twofold with the dividing line being “To PP or not to PP," as the title of Ken Hake’s blog article indicates:

1. If a product is compliant to some applicable cPP, then it can be evaluated at the assurance level defined in the compliant cPP.
2. If a product is not compliant to any cPP, then the mutual recognized assurance level is limited to EAL2.

I welcome #1 above, but have difficulty understanding the intent of #2. Moreover, it’s a puzzling thing why #1 has to be accompanied by #2, since #1 does not logically imply #2.

The reason I welcome #1 is that the PP approach can provide the much needed assurance for those STs that are compliant to some PP. In the presentation titled “Introducing Assurance Measures for the Security Target” at the 9th ICCC, I discussed the weakness of CC where a flexible framework allows ST authors to freely define security problems for their products and sets very few restrictions on the acceptance criteria.

The enforcement of requiring an ST to be compliant to some PP tightens that loose end. PPs being developed by a Technical Community (TC) formed by the technology experts from vendors, labs, schemes, and end users is a promising solution to address the issue. TCs know best what threats the technology in question is facing, how to define the security problems that challenge this technology, and what vulnerabilities a product built upon this technology may have.

With the recently added “c” (where "c" stands for “collaborative”), cPPs are expected to be developed from the global expertise and to be mutually recognized among CCRA member nations. In theory, this is the most promising road to keep CC evolving with rapidly emerging technologies. In reality, how well this plan is going to play out depends on a number of assumptions, such as:

• A TC shall have well balanced knowledge in CC and a specific technology area for which a cPP is targeted.
• Stakeholders of the TC shall overcome their own diverse interests and be agreeable to reach consensus on a common set of security requirements for a certain technology area.
• cPPs shall be developed in a timely manner.
• cPPs shall be available to cover most of the technology spectrum.
• CCMC and CCDB will provide more concrete guidelines on cPP development.

Considering the challenges of upholding these assumptions, the future looks a bit more blurry than the bright theoretical picture that has been painted. Nevertheless, with everyone from the CC community providing constructive inputs to this joint adventure based on experience  accumulated in the past (e.g. Deep Thought on PPs by Fiona Pattinson and "How to Write a (good) Protection Profile" by Helmut Kurth), we can still keep a hope high and wish for the best: that one day plenty of high quality cPPs will be out there to support the vision statement in moving to the cPP-centric approach.

PPs in the past and cPPs in the future can definitely align the Security Functional Requirements (SFRs) for products in the same category, which are derived from well-understood security threats and better-tailored security problem definitions that are particularly fit for the technology in question. However, Security Functional Requirements and Security Assurance Requirements (SARs) are orthogonal in CC. A product with one single SFR may be evaluated at EAL4 while another product with a set of ten SFRs may be evaluated at EAL1. The SFRs do not correlate to SARs.

Without compliance to a commonly shared set of SFRs, products of the same category but from different vendors could hardly be compared to each other. The crucial role that a PP played (and that cPPs will continue to play in the future) is to provide the much-needed common set of SFRs for each technology area. The new trend for the highly expected cPPs is that they will go beyond SFRs and also provide well-tailored packages of SARs in place of the traditional EALs. That is also fine. After all, EALs 1-7 are just special kinds of pre-defined packages of SARs. The notion of assurance package is present in the current CC, and it’s not surprising to advocate the use of different packages of SARs to meet the various needs raised from different scenarios.

However, what puzzles me is the #2 (listed above). I have failed to find any logical implication that could possibly lead #1) to reach #2. I truly cannot understand the intent of #2. All I can see is that it will downgrade the importance of the CC and eventually backfire to hurt #1, which I have agreed upon with my whole heart -- despite the skepticism about its depending assumptions. Following are the reasons why.

Until there are a large number of cPPs publicly available that cover every corner of modern IT technology, there will be plenty of cases where a product is not compliant to any cPP -- not because the vendor deliberately does not want to be cPP-compliant, but because there simply is no existing cPP with which they can be compliant. There are always new emerging technologies, and innovative vendors come up with new products well before corresponding cPPs can be created. So, being non cPP-compliant would not be a vendor’s fault, but rather a consequence of their own innovation. Yet, their products would have to be limited by CCRA mutual recognition up to EAL2 if the vision statement were to become effective.

The goal of reaching “reasonable, comparable, reproducible and cost-effective evaluation results,” as stated in the section of Key points for future CCRA use, may explain the addition of a cPP-based approach, but it cannot be served as rationale to justify the downgrade of the current maximum, mutually recognized assurance level from EAL4 down to EAL2. Otherwise, one will get an undesirable implication: SARs that are not subordinate to EAL2 cause evaluation results which are not reasonable, not comparable, not reproducible, and not cost-effective.

If the SARs defined in CC part 3 can only be preserved up to EAL2, rendering the rest of the SARs as “trouble makers,” then CC would look really bad and its value becomes doubtful. Luckily, SARs are actually innocent. Blaming SARs above EAL2 as being responsible for irreproducible evaluation results is like blaming a French cuisine recipe simply because a novice Chinese cook was unable to reproduce the same dish made by an experienced French chef. As obvious as it is, the solution here is to adequately train the Chinese cook instead of banning the recipe! For the same reason, if the worry is that schemes from different nations tend to produce different results on some medium and high level SARs, then the CCMC should provide shadowing evaluation, supervision, or some other means to let newly joined schemes learn from an experienced scheme so that the desired reproducibility can be achieved.

I believe that holding the standard high and continually carrying the CC expertise forward is the right way to build up the CC's reputation. The attempt to lower the standard in order to accommodate novice schemes or to attract new nations to join CCRA is no different from demanding all restaurants only serve fast food in order to accommodate some restaurants that are unable to provide fine dining.

Regardless of undesirable implications, the CCRA vision statement seems to be pushing CC into its lower corner -- even for the cPP development. It’s really worrisome to read the statements in the Baseline requirement section, such as the following: "All cPPs shall include assurance components derived from the CC part 3 to a maximum of EAL2, or higher (up to EAL4) if the TC can demonstrate a rationale that shows the activities can be repeated between schemes."

If CC is envisioned as a passive tool box (as stated in item 6 of the CCRA vision statement) where most of the “advanced” tools will not be used and get rusty, and new tools will no longer be added, I cannot help asking how long this toolbox will remain useful.

While my colleagues seek to have their questions answered by the Oracle of Delphi and Deep Thought, I turned to my oriental ancestor Dragon. As a “Descendant of the Dragon," I have a spiritual pathway via meditation to feel the great existence of the Dragon. Gradually, little by little, his image appears – he has horns of a giant stag, head of a horse, eyes of a demon, neck of a snake, abdomen of a tortoise, scales of a carp, claws of an eagle, paws of a tiger and ears of an ox! Those are the nine resemblances to various animals described in the legend.

As powerful as he is, he can surely read my mind. Before I could murmur a word, he began talking to me in a calm and steady voice, saying, “You see, I am the highly respected extraordinary Dragon because I have the best features from various creatures. If these features are taken away from me, then I will become an ordinary worm.” He disappeared before the sound of his voice faded away.

Becoming a dragon or a worm is the choice to be made. I wish the CC community good luck, strength, and power to turn CC into a dragon!

by Dr. Yi Mao

Editors Note: If you would like to see why Dr. Mao is qualified for such an analysis, please check out her academic paper entitled "Generics and Metaphors Unified under a Four-Layer Semantic Theory of Concepts," which was co-authored by Dr. Mao and Dr. Bertand du Castel.

Understanding Information Entropy

In discussions of random number generation (RNG), people often talk about the term “entropy” as if it was interchangeable with the term “random.” For example:

• The random seed is taken from an entropy pool.
• Entropy bits are added to the pool from external sources such as mouse and keyboard activity, disk I/O operations, and specific interrupts.
• Cloned sibling Virtual Machines may have loads of entropy in each of their pools, but they are all the same entropy copied over from the same frozen state.
• A RNG seeded with insufficient entropy produces predictable keys.
• RNG failures are often rooted in bad entropy.
• Software systems face the security problem of lacking entropy.

Mathematically, information entropy is defined as the uncertainty associated with a random variable that represents the average information content one is missing when one does not know the value of the random variable.  This article is intended to bridge the gap between the common usage of the term “entropy” (as demonstrated in the above examples) and its mathematical definition. The goal is to explain what information entropy really is, the determining factors of entropy, how to analyze and justify an entropy source, and how to assess the quality of an entropy input. For a good understanding of all these topics, please read the full article.

by Yi Mao

Why and How to Get Cryptographic Modules FIPS Validated

While the modern information and communication technologies brings us the convenience of working from home, e-banking, e-commerce, as well as many public services accessible online, it highly demands the protection of sensitive information. Among a variety of information security approaches to build the defense in depth, cryptography is at the foundation of all information security in terms of confidentiality, authentication, non-repudiation, and data integrity. As cryptography has become increasingly mathematical in nature, its design and implementation can be error-prone. It will be wise to use the NIST approved cryptographic algorithms and have their implementations tested under Cryptographic Algorithm Validation Program (CAVP). Even after algorithm implementations are tested, things can still go very wrong if the cryptographic sensitive parameters are not well protected or well generated to begin with. This is where the NIST Cryptographic Module Validation Program (CMVP) comes to the rescue. The cryptography that is not validated by CMVP is viewed by NIST as providing no protection to the information or data; in effect the data would be considered unprotected plaintext. The validation program against the open FIPS 140-2 standards provides the following benefits:

• Modules that have undergone the CMVP validation provide cryptographically sound protections over sensitive data.
• Modules that have achieved FIPS 140-2 certification differentiate themselves from competing products due to their assured quality through an independent third-party.
• Vendors who take up the challenge of having their products tested under an open standard demonstrate their commitment to security and their dedication to perfect their products, which in turn helps them to build up a good reputation and gain the customers’ trust.
• Due to the widely recognized merit of FIPS 140-2 certification, the standard itself is also evolving to be an international standard under ISO/IEC FDIS 19790. Vendors with the FIPS 140-2 validation experience are well positioned to quickly advance to meet the requirements from the international standard for cryptographic modules. This surely helps vendors to penetrate and gain the international market.

The validation effort can start with training on FIPS 140-2 and other cryptographic-based standards as early as the initial phase of module design. If planned properly, the modules that are constrained to a validation budget may consider achieving the certification in two steps. For a more detailed discussion on why and how to get cryptographic modules FIPS validated, please read this article.

by Yi Mao