Cryptographic module related work in ISO/IEC JTC 1/SC 27/WG 3

Last updated: 2019-03-04

For several years the value of conformance testing against the FIPS 140-2 specification has been well accepted, and the assurance gained through validated conformance has been specified (with varying degrees of rigor) in several other markets. For example:

• Other governments that use either FIPS 140-2 or ISO/IEC 19790: These include: 
• Canada, who partners with NIST in operating the CMVP as a joint endeavor between NIST and the Canadian Centre for Cyber Security (CCCS), a branch of the Communications Security Establishment (CSE); 
• Japan CMVP which is part of the  Information-technology Promotion Agency (IPA). JCMVP developed and operate a validation program (similar to that used in the US and Canada) in support of procurement in compliance with the Japanese Standards for Information Security Measures for the Central Government Computer Systems;
• Korea Cryptographic Module Validation Program (KCMVP)
• Spain (CCN)
• Turkey (TSE)
• 
  
• Several Common Criteria national schemes who may often draw from cryptographic module or cryptographic algorithm validations in their own assurance work. These include:
• US: NIAP who specify that NIST crypto algorithm validation program certificates be obtained in support of CC evaluations.
• 
  
• In 2013, an ENISA survey shows that 89% of respondents report using at least some product with a NIST FIPS certification, while 80% of use at least one Common Criteria certified product. 
• The UK’s information commissioner’s office and Treasury Solicitor’s Department, both of which recommend using FIPS 140-2 validated encryption products.
• The Health industry. For example, the HITECH act provides for "safe harbor" from the costs of patient notification as well as the reputational risk if the data was protected  using encryption. The approved encryption processes to claim safe harbor are those that comply with the requirements of the Federal Information Processing Standards (FIPS) 140-2.
• The Financial industry. This industry has long referenced use of FIPS 140-2 and its predecessors as a best practice. More recently, the Payment Card Industry has drawn heavily from FIPS 140-2 in their endeavors to obtain cryptography assurance within PCI environments and systems in several of their standards.
• Voting Systems. The Electoral Assistance Commission’s Voluntary Voting System Guidelines recommend the use of FIPS 140-2 for cryptography in voting systems.
•  Digital Cinema. FIPS 140-2 is specified in the digital cinema specification, V1.2.

Despite the obvious usefulness of the standard and the assurance that is gained from programmatic testing and validation of the results, it has been long recognized that a US government-produced standard (and US government validations) may not be appropriate for scenarios beyond the US Government regulation and so, in 2003, a project was initiated by ISO/IEC JTC 1 sub-committee 27 which focuses on IT security techniques. The project was allocated to Working Group 3, and the assigned editors and experts from the US, France and Japan led the international coordination to produce the first edition of ISO/IEC 19790 which was published in 2006.

A comparison of FIPS 140-2 and ISO/IEC 19790 is given in the blog "ISO's cryptographic module work".

A similar blog on ISO's work related to ISO/IEC 15408 (Common Criteria)  is also avilable. There is some overlap.

Work from ISO/IEC JTC 1/SC 27/WG 3 related to cryptographic modules

The work in ISO is not restricted to the specification and the associated test requirements. There are several other work items that have been published or are currently being developed in SC 27/WG 3. These include:

Requirements and testing

IS 19790:2012: Security requirements for cryptographic modules

Specifies security requirements specified intended to maintain the security provided by a cryptographic module.

This core standard is currently in it's second edition,  Note that the standard has been updated with a corrigendum in 2015.

IS 24759:2014: Test requirements for cryptographic modules

Specifies the methods to be used by testing laboratories to test whether the cryptographic module conforms to the requirements specified in ISO/IEC 19790:2012/Cor.1:2015. It also specifies the requirements for information that vendors provide to testing laboratories as supporting evidence for conformance testing.

This standard is currently in it's second edition,  Note that the standard has been updated with a corrigendum in 2015.

Deployed Modules 

DRAFT ISO/IEC TS 20540 Guidelines for testing cryptographic modules in their operational environment  

Describes the guidelines that may be used in operational testing of cryptographic
modules which are deployed as part of a security system. The operational tests are performed to determine the suitability and proper usage of a cryptographic module in its intended environment.

Non-Invasive attacks

IS 17825:2016: Testing methods for the mitigation of non-invasive attack classes against cryptographic modules

Specifies the non-invasive attack mitigation test metrics for determining conformance to the requirements specified in ISO/IEC 19790 for Security Levels 3 and 4. The test metrics are associated with the security functions specified in ISO/IEC 19790. Testing will be conducted at the defined boundary of the cryptographic module and I/O available at its defined boundary.

The test methods used by testing laboratories to test whether the cryptographic module conforms to the requirements specified in ISO/IEC 19790 and the test metrics specified in this International Standard for each of the associated security functions specified in ISO/IEC 19790 are specified in ISO/IEC 24759. The test approach employed in this International Standard is an efficient "push-button" approach: the tests are technically sound, repeatable and have moderate costs.

DRAFT ISO/IEC TR 20085-1: Test tool requirements and test tool calibration methods for use in testing non-invasive attack mitigation techniques in cryptographic modules — Part 1: Test tools and techniques.

DRAFT ISO/IEC TR 20085-2: Test tool requirements and test tool calibration methods for use in testing non-invasive attack mitigation techniques in cryptographic modules — Part 2: Test calibration methods and apparatus

TR 30104:2015: Physical Security Attacks, Mitigation Techniques and Security Requirements

This technical report provides guidance and addresses the following topics:

• a survey of physical security attacks directed against different types of hardware embodiments including a description of known physical attacks, ranging from simple attacks that require little skill or resource, to complex attacks that require trained, technical people and considerable resources;
• guidance on the principles, best practices and techniques for the design of tamper protection mechanisms and methods for the mitigation of those attacks; and
• guidance on the evaluation or testing of hardware tamper protection mechanisms and references to current standards and test programs that address hardware tamper evaluation and testing.

Cryptographic functions, algorithms and protocols

Note that the specification of cryptography and security mechanisms  is handled in WG 2: I have not listed their related work here. A full list of SC 27 work can be found in the ISO Standards Catalogue.

DRAFT IS 18367: Cryptographic algorithms and security mechanisms conformance testing

Intended to provide the basis for testing the implementation correctness of cryptographic algorithms published by ISO.
Conformance testing assures that an implementation of a cryptographic algorithm or security mechanism implementation is correct whether implemented in hardware, software or firmware or in a specific operating environment. Testing may consist of known-answer or Monte Carlo testing, or a combination of test methods. Testing may be performed on the actual implementation or modeled in a simulation environment.

2016: This document is in the late stages of development and is expected to be published before the end of 2016.

IS 29128:2011: Verification of cryptographic protocols: 

Establishes a technical base for the security proof of the specification of cryptographic protocols. It specifies design evaluation criteria for these protocols, as well as methods to be applied in a verification process for such protocols. It also provides definitions of different protocol assurance levels consistent with evaluation assurance components in ISO/IEC 15408.

DRAFT ISO/IEC 20543: Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408

Describes testing and evaluation methods for determining the acceptable randomness of non-deterministic and deterministic random bit generators for use in cryptographic applications.

Physically unclonable functions (PUFs)

DRAFT: ISO/IEC  20897:Security requirements, test and evaluation methods for physically unclonable functions (PUFs) for generating non-stored security parameters

2016: This standard is currently under development.

Competence

DRAFT ISO/IEC TR 19896-1: Competence requirements for information security testers and evaluators: Part 1: Introduction, concepts and general requirements

Provide the fundamental concepts related to the topic of the competence of the individuals responsible for performing IT product security evaluations and conformance testing. Provides the framework and the specialised requirements that specify the minimum competence of individuals performing IT product security evaluation and conformance testing using established standards.
This will support the goals of ISO CASCO conformity assessment by contributing standardized requirements for competency supporting ISO/IEC 17024.

 DRAFT ISO/IEC TR 19896-2: Competence requirements for information security testers and evaluators: Part 2: Knowledge, skills and effectiveness requirements for 19790 testers

This standard will establish  a baseline for the competence of ISO/IEC 19790 testers and validators with the goal of establishing conformity in the requirements for the training of ISO/IEC 19790 testing and validator professionals associated with cryptographic module conformance testing programs.

About testing and validation of conformance to ISO/IEC 19790

Now that there is an internationally recognized set of standards for the specification and testing of cryptographic modules, a base set of cryptographic standards and fundamentals, as well as a means of testing their implementation correctness, all the needed tools are in place for various authorities to develop validation programs - and use of the tools provide for consistent testing, validation, and certification of conformance to the ISO standard.

This is already happening.

• In Japan, IPA operates a cryptographic module validation program with ISO/IEC 19790 as a basis known as the JCMVP.  At the ICMC in 2013, Japan announced that a memorandum of understanding between the JCMVP and the CMVP.
• in Korea, the Korean Cryptographic Module Validation Program (KCMVP ) was established in 2005 and uses ISO/IEC 19790 as a basis for their program specifying the Korean approved set of cryptographic algorithms and security functions.
• A validation program in Spain for cryptographic modules is based on the ISO standards
• A validation program in Turkey for cryptographic modules is based on the ISO standards
• Other national programs are under consideration 

With the development of validation programs using the standards -- and perhaps even one day mutual recognition by different programs -- the needs of the commercial sector around the world can be addressed. This would help developers and vendors of cryptographic modules to address markets on a multi-national basis (and may even help address some of the issues apparent in the critical infrastructures and the international supply chain).

To successfully offer such a service, a validation program must define the operational activities that are vital to a successful program. These activities include:

• accrediting test laboratories
• making program policies
• defining the approved cryptographic functions,
• establishing algorithm implementation testing and validation
• establishing a management system for validating and certifying the testing results
• providing any necessary interpretations of the standards
• dealing with comments, requests, and issues from labs and vendors
• policing the certificate and logo usage 

WG3 have produced a document that provides additional guidance on this topic:

ISO/IEC 15443  ("FRITSA")

ISO/IEC TR 15443-1:2012:  Security assurance framework -- Part 1: Introduction and concepts

ISO/IEC TR 15443-2:2012: Security assurance framework -- Part 2: Analysis

Substantially revised in 2012. Part one gives a discussion of the nature of security assurance, providing a framework for further discussions and documents. Part 2 of this technical report describes the "criteria for criteria". It discusses security assurance schemes, and how these themselves can be evaluated. While some schemes are of high quality, others may not be. What criteria can be used to tell?

By Fiona Pattinson

The ISO Cryptographic Module Testing Family

Call for Papers for the Second International Cryptographic Module Conference

Mark Your Calendar: ICMC 2014, November 19-21, Hilton Washington D.C., Rockville, MD

ICMC brings together experts from around the world to confer on the topic of cryptographic modules, with emphasis on their secure design, implementation, assurance, and use, referencing both new and established standards such as FIPS 140-2 and ISO/IEC 19790.
We are focused on attracting participants from the engineering and research community, test laboratories, government organizations, the procurers, deployers and administrators of cryptographic modules and academia. Our program consists of one day of workshops and tutorials, followed by two days of 30 minute presentations (plus 15 minute for questions). We solicit proposals for high quality papers and relevant workshops that will be of interest to the community involved with cryptographic modules on topics below. Visit www.ICMConference.org for complete information.

Topics

• Management of Cryptographic Modules in the Field
• Standards: Including FIPS 140-2, ISO/IEC 19790, FIPS 140-3
• Physical Security and Hardware Design
• Key Management
• Random Number Generation
• Side Channel Analysis, Non-invasive Attacks
• Choice of and Implementing Cryptographic Algorithms
• Cryptographic Modules Implemented in Open Source
• Hybrid Systems, Embedded Systems
• Tools and Methodologies
• Other Cryptographic Standards

The committee favors vendor-neutral presentations that focus on the practical design, testing and use of cryptographic modules. Product vendors are encouraged to recruit clients and partners who are front-line implementers as presenters.

Dates

• Abstracts: April 10, 2014
  All prospective authors must submit their abstracts and workshop proposals using this link: http://icmconference.org/?page_id=24
• Review and comments: May 18, 2014
• Acceptance notifications: July 17, 2014
• Final versions due: October 23, 2014

Workshops/Tutorials: November 19, 2014
Presentation of papers: November 20-21, 2014

For any questions regarding submissions or the conference in general, please contact us at info@icmconference.org.

Presented with the cooperation of:
CMUF
Cryptographic Module User Forum

The Top 3 Mistakes When Starting a FIPS 140-2 Project

by Steve Weingart

1. Starting without the standard in mind
Probably the biggest problem causing issue in a FIPS 140-2 validation project is when the developer decides to ‘back into’ the standard after the fact. Trying to validate a product that was developed without being mapped to the standard is more difficult at the very least and has a potential for failure at the worst.

FIPS 140-2 has many specific system requirements including: self-test on start-up, where the integrity of the module has to be verified and all cryptographic functions have to be run against known answer tests to ensure correct operation. The entire lifecycle of the cryptographic keys has to be managed, from how they are created; to how they are used, transported, stored and ultimately how they are destroyed (or zeroized in FIPS 140-2 parlance). How random numbers for key creation are generated, how user authentication is performed and which cryptographic algorithms are used (and in what context), are also functions that have to be performed in a compliant manner.

When the developer comes to a validation test lab with a cryptographic module that is missing required components, or has implemented them in a non-compliant way, it always makes the validation process more difficult, more time consuming and ultimately more expensive for the developer.

The best time to start with the standard is when the design and architecture are first beginning. Reading the standard for the general overview, then really getting into the details of the Derived Test Requirements and Implementation Guidance documents (all available at the NIST Cryptographic Module Validation Program website) will get you started down the best path to a successfully validated FIPS 140-2 cryptographic module.

2. Being unaware of your responsibilities
As in #1 above, many customers come to test labs not knowing anything about their part in the validation process. Validation is a team effort. The developer must supply the lab with all of the required documents and artifacts for testing, but that is really only the beginning. It is the open support and cooperation - both ways - that allows the project to go smoothly and quickly. The relationship between the lab and the customer should not be adversarial. We are all on the same side. The goal is to get your product validated, but the lab has to meet that goal by assisting and guiding you in meeting every requirement. It is not the lab that issues the Certificate of Validation; it is issued by the CMVP (Cryptographic Module Validation Program) at NIST in the U.S., and the CSEC (Computer Security Establishment Canada) in Canada. Both of those agencies review the final test report and then usually ask the lab for clarification on several points, sometimes sending us back for some additional evidence, before issuing the certificate. So it is you and the lab working together to present your case to the program, and we really have to be a team.

The best way to set up for this teamwork is to choose your lab early in the development process. That way the lab can start to review your architecture and design early on, hopefully saving you from going down any non-compliant paths. The lab can also provide training on the FIPS 140-2 standard and its requirements, as well as perform a readiness assessment to go over your design in detail, before the formal validation process begins.  Going down this path is probably the best way to make sure your validation experience is a good one.

3. Expecting a “rubber stamp”
After seeing the first two pitfalls above, this one may seem redundant, but unfortunately it’s not. Many folks never get it that receiving a Certificate of Validation for your product is not just a matter of paying some money, tossing some documentation over the fence and waiting for the Certificate to arrive. The FIPS 140-2 process entails documentation review, code review, testing of your product both in its normal state, as well as in induced error states and more testing to see if your security protection mechanisms work as claimed. This work is performed by highly trained engineers and each of these tests and reviews must be formally documented. The final report often runs 50+ pages and is what NIST and CSEC review. It is a serious process and it is backed up by months of serious work for each validation. As a customer, you definitely get a lot of work for your time and money.

I hope this gives a bit of insight into the FIPS 140-2 validation process and helps to prepare you and your product for an easier and successful path to a Certificate of Validation.

FIPS 140-2 and ISO standards

Last updated: 2016:11:10

atsec customers who have projects for testing, validating, and certifying cryptographic modules for the US government market are intimately familiar with the FIPS 140-2 standard. This standard and its associated supporting documents are produced and published by NIST. Together, the suite of documents define the specification and testing requirements for a cryptographic module that is used by the US Federal government to meet their requirements under the Federal Information Security Management Act (FISMA) of 2002.

For several years the value of conformance testing against the FIPS 140-2 specification has been well accepted, and the assurance gained through validated conformance has been specified (with varying degrees of rigor) in several other markets. For example:

• Other governments that recognize the assurance provided. Most noteworthy is Canada, who partners with NIST in operating the CMVP as a joint endeavor between NIST and the Communications Security Establishment of Canada (CSEC). There are  examples of others, such as the Japan CMVP which is part of the  Information-technology Promotion Agency (IPA). They developed and operate a validation program (similar to that used in the US and Canada) in support of procurement in compliance with the Japanese Standards for Information Security Measures for the Central Government Computer Systems.
• Several Common Criteria national schemes who may often draw from cryptographic module or cryptographic algorithm validations in their own assurance work.
• The UK’s information commissioner’s office and Treasury Solicitor’s Department, both of which recommend using FIPS 140-2 validated encryption products.
• The Health industry. For example, the HITECH act provides for "safe harbor" from the costs of patient notification as well as the reputational risk if the data was protected from using encryption. The approved encryption processes to claim safe harbor are those that comply with the requirements of the Federal Information Processing Standards (FIPS) 140-2.
• The Financial industry. This industry has long referenced use of FIPS 140-2 and its predecessors as a best practice. More recently, the Payment Card Industry has drawn heavily from FIPS 140-2 in their endeavors to obtain cryptography assurance within PCI environments and systems in several of their standards.
• Voting Systems. The Electoral Assistance Commission’s Voluntary Voting System Guidelines recommend the use of FIPS 140-2 for cryptography in voting systems.
•  Digital Cinema. FIPS 140-2 is specified in the digital cinema specification, V1.2.

Despite the obvious usefulness of the standard and the assurance that is gained from programmatic testing and validation of the results, it has been long recognized that a US government-produced standard (and US government validations) may not be appropriate for scenarios beyond the US Government regulations.

So, in 2003, a project was initiated by ISO/IEC JTC 1 sub-committee 27 which focuses on IT security techniques. The project was allocated to Working Group 3, and the assigned editors and experts from the US, France and Japan led the international co-ordination to produce the first edition of ISO/IEC 19790 which was published in 2006 (and was very familiar to those with knowledge of FIPS 140-2).

The abstract of ISO/IEC 19790

Most of the differences between the ISO version and the FIPS version of the cryptographic module specification were those of internationalization. References to US legislation were removed and reliance on the US algorithm suite was modified (so that an authority could specify their own preferred set of algorithms, protection profiles, random number generators, and key establishment techniques). Terms referencing the CMVP were replaced by “approval authority,” and the terminology was updated to include “Sensitive Security Parameters” (SSP),  “Critical Security Parameters” (CSP), etc. Technically, the specification was very similar to FIPS 140-2.

The abstract of ISO/IEC 24759

In 2008 a companion document, equivalent to the NISTs “Derived Test Requirements” for FIPS 140-2, was published. ISO/IEC 24759:2008: Information technology -- Security techniques -- Test requirements for cryptographic modules.

This document pair provided the basic requirements for forming an approval authority independent of the CMVP.

In 2008, with drafts of FIPS 140-3 from NIST becoming publicly available, ISO decided to also revise their standard with the intention of publishing a revision of ISO/IEC 19790 as close as possible to the final release of FIPS 140-3. ISO communicated with NIST for status as NIST wrestled with the high volume of comments they received regarding FIPS 140-2, but finally, ISO took the lead in moving their specification forward to cope with evolving technologies and enthusiastic input from the many experts and nations represented in ISO. This second revision of ISO/IEC 19790 was published in August of 2012. (It is available for purchase from ISO’s online store or from your favorite purveyor of standards.)

The companion test requirements document, ISO/IEC 24759, is currently undergoing revision and will be published when the final draft is approved by the ISO voting members.

Also in the works is a project to specify the necessary standards to enable implementation testing for cryptographic algorithms and other security functions. This project aims to enable an authority to develop a program along the lines of NIST’s cryptographic algorithm validation program (CAVP) that provides the pre-requisite assurances for the fundamental functions employed in cryptographic modules.

Testing and validation of conformance to ISO/IEC 19790

Now that there is an internationally recognized set of standards for the specification and testing of cryptographic modules, a base set of cryptographic standards and fundamentals, as well as a means of testing their implementation correctness, all the needed tools are in place for various authorities to develop validation programs - and use of the tools provide for consistent testing, validation, and certification of conformance to the ISO standard.

This is already happening.

• In Japan, IPA operates a cryptographic module validation program with ISO/IEC 19790 as a basis known as the JCMVP.  At the ICMC in 2013, Japan announced that a memorandum of understanding between the JCMVP and the CMVP.
• in Korea, the Korean Cryptographic Module Validation Program (KCMVP ) was established in 2005 and uses ISO/IEC 19790 as a basis for their program specifying the Korean approved set of cryptographic algorithms and security functions.
• A validation program in Spain for cryptographic modules is based on the ISO standards
• A validation program in Turkey for cryptographic modules is based on the ISO standards
• Other national programs are under consideration 

With the development of validation programs using the standards -- and perhaps even one day mutual recognition by different programs -- the needs of the commercial sector around the world can be addressed. This would help developers and vendors of cryptographic modules to address markets on a multi-national basis (and may even help address some of the issues apparent in the critical infrastructures and the international supply chain).

To successfully offer such a service, a validation program must define the operational activities that are the vital to a successful program. These activities include:

• accrediting test laboratories
• making program policies
• defining the approved cryptographic functions,
• establishing algorithm implementation testing and validation
• establishing a management system for validating and certifying the testing results
• providing any necessary interpretations of the standards
• dealing with comments, requests, and issues from labs and vendors
• policing the certificate and logo usage

What changed in the 2012 revision of ISO/IEC 19790?

The following gives some of the highlights of ISO/IEC 19790:2012 and those familiar with FIPS 140-2 will notice some differences. Of course, for the full specification the ISO standard must be consulted. The following is not intended to be a complete analysis, but rather highlights some of the key points that affect developers of complex cryptographic modules. These include:

• A Degraded mode of operation is introduced, which allows modules to provide cryptographic services in the event that some part is not behaving, but the other parts are acting as expected. In the 2008 standard, if one part is "sick" the entire module must refuse any services. This requirement has been quite restrictive but is now relaxed.
• The dependency on Common Criteria for the Operating Environment for modules aiming for Validation Level 2 or higher is removed. Instead, the new ISO version introduces some specific security requirements on the Operating Environment that must be tested and configured independently by the laboratory. This allows independent validation of Software Modules at level 2, which right now is practically not feasible.  
• New requirements for developer testing on the module have been introduced to complement the lab's testing. In this sense, the testing requirements become more aligned with what Common Criteria considers "developer" vs."independent" testing. This means that with the new revision, developers of cryptographic modules will have to spend time and effort to document their own security testing of the services the module provides, which is something they do not need to care about right now. Generally speaking, this is targeted towards increasing the assurance provided by the modules, but any assurance gained will heavily depend on how the different national programs develop their specific requirements and metrics for this activity.  

The new revision continues to specify four security levels. Below is a summary of the levels and the basic requirements of each:

Security Level 1

• At least one approved security function or approved sensitive security parameter establishment method
• Operation in a non-modifiable, limited, or modifiable operating environment
• No physical security mechanisms are required above production-grade components
• Any Non-invasive mitigation methods or mitigation of other attacks which are implemented are documented

Security Level 2

• Adds the requirement for tamper evidence, which includes the use of tamper-evident coatings or seals or pick-resistant locks on removable covers or doors
• Role-based authentication
• Software cryptographic module to be executed in a modifiable environment that implements role-based access controls or, at the minimum, a discretionary access control with a robust mechanism of defining new groups and assigning restrictive permissions through access control lists (ACLs), and with the capability of assigning each user to more than one group, and that protects against unauthorized execution, modification, and reading of cryptographic software

Security level 2 continues to be the highest security level attainable by a pure software module.

Security Level 3

• Additional requirements to mitigate the unauthorized access to SSPs held within the cryptographic module
• Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at direct physical access, use or modification of the cryptographic module and probing through ventilation holes or slits
• Identity-based authentication mechanisms
• Manually established plaintext CSPs must be encrypted, utilize a trusted channel or use a split knowledge procedure for entry or output
• Mechanisms to protect  a cryptographic module against a security compromise due to environmental conditions outside of the module's normal operating ranges for voltage and temperature
• Any Non-invasive mitigation methods that are implemented in the module must be tested against metrics for security level 3 that are defined in the standard
• Additional life-cycle assurances, such as automated configuration management, detailed design, low-level testing, and operator authentication using vendor-provided authentication information

Security Level 4

• Multi-factor authentication for operator
• The module includes special environmental protection features designed to detect voltage and temperature boundaries and zeroize CSPs
• Any Non-invasive mitigation methods that are implemented in the module must be tested against metrics for security level 4 that are defined in the standard
• Design verification by the correspondence between both pre- and post-state conditions and the functional specification

Requirements areas

The security requirements are organized into 11 requirement areas; many of these areas have changes from those specified in FIPS 140-2:

1. Cryptographic module specification: This area includes the cryptographic module specification general requirements, the types of cryptographic modules, the cryptographic boundary and the modes of operations
2. Cryptographic module interfaces: This area includes the cryptographic module interfaces general requirements, the types of interfaces, the definition of interfaces and trusted channel requirements
3. Roles, services, and authentication: This area includes  the general requirements for roles, services, and authentication
4. Software/Firmware security:
5. Operational environment: This area includes general requirements for the operational environment, Operating system requirements for limited or non-modifiable operational environments, and Operating system requirements for modifiable operational environments
6. Physical security: This area includes requirements for embodiments, general requirements, requirements for each physical security embodiment and Environmental failure protection/testing requirements
7.  Non-invasive security
8. Sensitive security parameter management : This area includes general requirements, Random bit generators , Sensitive security parameter generation , Sensitive security parameter establishment , Sensitive security parameter entry and output , Sensitive security parameter storage, and Sensitive security parameter zeroization
9.  Self-tests: general requirements for self tests, pre-operational self-tests, and conditional self-tests
10.  Life-cycle assurance: This area includes the life-cycle general requirements, Configuration management , Design ,Finite state model , Development ,Vendor testing, Delivery and operation, End of life and Guidance documents
11.  Mitigation of other attacks

Summary of the security requirements by area and Security Level

ISO/IEC 19790:2012 summary of security requirements by Security Level

 The Annexes of ISO/IEC 19790:2012

    A.     Documentation requirements for each of the eleven requirement areas.
    B.     Details of the requirements for the contents of the non-proprietary security policy and the order of the contents. This aims to make the security policy document more consistent between vendors.
    C.     A default set of Approved security functions, referring to various ISO standards for block ciphers, stream ciphers, asymmetric algorithms and techniques, message authentication codes, hash functions, entity authentication, key management and random bit generation. As mentioned above, it is possible for an approval authority to supplement or supersede this Annex with their specific approved set of algorithms.
    D.     A list of the ISO/IEC approved sensitive security parameter generation and establishment methods. As mentioned above, it is possible for an approval authority to supplement or supersede this Annex with their specific requirements.
    E.      An empty list of the ISO/IEC approved authentication mechanisms. Since there are no ISO/IEC approved authentication mechanisms, it would be necessary for an approval authority to supersede this Annex with their own requirements.
    F.      An empty list of the ISO/IEC approved non-invasive attack mitigation test metrics. Since there are no ISO/IEC approved test metrics, it would be necessary for an approval authority to supersede this Annex with their own requirements.

But wait!!! There's more... Supporting work from ISO

The work in ISO is not restricted to the specification and the associated Test Requirements. There are several other work items that have been published or are currently being developed in WG 3. These include:

IS 19790 Security requirements for cryptographic modules

First published in 2006, based closely on the FIPS 140-2 standard, a second edition evolved the specification and was published in 2012.

A technical corrigendum has been processed, and a corrected reprint was issued in 2015.

 
IS 24759 Test requirements for cryptographic modules

First published in 2008, with a second revision in 2014. A corrected reprint was published in 2015

A minor revision is currently being processed for publication.

 

IS 17825: Testing methods for the mitigation of non-invasive attack classes against cryptographic modules

This International Standard specifies the non-invasive attack mitigation test metrics for determining conformance to the requirements specified in ISO/IEC 19790 for Security Levels 3 and 4. The test metrics are associated with the security functions specified in ISO/IEC 19790:2012.
The test methods used by testing laboratories to test whether the cryptographic module conforms to the requirements specified in ISO/IEC 19790 and the test metrics specified in this International Standard for each of the associated security functions specified in ISO/IEC 19790 are specified in ISO/IEC 24759.

This standard was first published in 2016.

IS 29128: Verification of cryptographic protocols

The goal of this International Standard is to establish means for verification of cryptographic protocol specifications to provide defined levels of confidence concerning the security of the specification of cryptographic protocols.

This standard was first published in 2011.

IS 20085: Test tool requirements and test tool calibration methods for use in testing non-  invasive attack mitigation techniques in cryptographic modules 

The test methods for non- invasive attacks cover a broad area and are subject to more rapid changes than ISO/IEC 19790 and ISO/IEC 24759. 

This new project is to describe them in more detail based on the test metrics defined in ISO/IEC 17825. The document will address the specific tools, test bench setups, data capture and the determination of the pass/fail metric based on the collected data. The calibration of the tools, setup, etc. will also be addressed to ensure that test setups that may have different underlying components yield the same results.

This multipart standard will have two parts:
— Part 1: Test tools and techniques
— Part: 2 Test calibration methods and apparatus 

These new documents are still in draft.

TR 30104: Physical Security Attacks, Mitigation Techniques and Security Requirements

This technical report provides guidance and addresses the following topics:

• a survey of physical security attacks directed against different types of hardware embodiments including a description of known physical attacks, ranging from simple attacks that require little skill or resource, to complex attacks that require trained, technical people and considerable resources;
• guidance on the principles, best practices and techniques for the design of tamper protection mechanisms and methods for the mitigation of those attacks; and
• guidance on the evaluation or testing of hardware tamper protection mechanisms and references to current standards and test programs that address hardware tamper evaluation and testing.

This Technical Report was first published in 2015

IS 18367: Cryptographic algorithms and security mechanisms conformance testing 

This draft document is in the early stages of development and is intended to provide the basis for testing the implementation correctness of cryptographic algorithms published by ISO.

Conformance testing assures that an implementation of a cryptographic algorithm or security mechanism implementation is correct whether implemented in hardware, software or firmware or in a specific operating environment. Testing may consist of known-answer or
Monte Carlo testing, or a combination of test methods. Testing may be performed on the actual implementation or modeled in a simulation environment.

This International standard is currently being processed for its initial publication in 2016.

TR 20540: Guidelines for Testing Cryptographic Modules in their operational environment

This Technical Report will provide guidance for those choosing and operating cryptographic modules that have been specified and validated using ISO/IEC 19790 and ISO/IEC 24759 as a basis. It will help those needing to test that cryptographic modules are installed and operated in accordance with the module’s Security Policy document.

 This document is still in draft.

IS 20543: Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408

This new International Standard will specify methods to determine if the bit stream output of a non-deterministic or deterministic random bit generator has sufficient entropy for use in cryptographic applications. Guidelines for the evaluation and the statistical testing of Random Bit Generators are specified in this standard for the purposes of independent verification or validation by a validation authority.

Design and implementation of non-deterministic random bit generators are outside the scope of this International Standard.

This document is still in draft.

IS 20897: Security requirements, test and evaluation methods for physically unclonable functions for generating non-stored security parameters 

This new International Standard specifies the security requirements and the test methods for physically unclonable functions (PUFs). Specified security requirements include unpredictability and uniqueness of outputs for a batch of PUFs, reliability of outputs for a given PUF with a given input, and diffuseness (or unpredictability) of outputs for a given PUF under random inputs. The test methods consist of inspection of the design rationale of the PUF and comparison between statistical analyses of the responses from a batch of PUFs or a unique PUF versus specified thresholds.

This document is related to ISO/IEC 19790 which specifies security requirements for cryptographic modules. In those modules, CSPs and SSPs are the assets to protect. PUF is one solution to avoid storing security parameters, thereby increasing the overall security of a cryptographic module.

One application of PUF is the seeding of true random number generators. 

The document is still in draft. 

IS 19896: Competence requirements for information security testers and evaluators

This new standard aims to provide the minimum requirements for the competence of individuals performing testing and evaluation activities using ISO/IEC standards for evaluating or testing the security functionality of IT products.

The standard is a multipart standard with three parts:
— Part 1: Introduction, concepts and general requirements
— Part 2: Knowledge, skills and effectiveness requirements for ISO/IEC 19790 testers
— Part 3: Knowledge, skills and effectiveness requirements for ISO/IEC 15408 evaluators

 The documents are all in draft.

--- With thanks to the editors of ISO/IEC 19790 including Randall Easter, Jean-Pierre Quémard and Junichi Kondo and also the convener of SC 27's working group 3, Miguel Bañón, for their review of this text and for suggesting corrections and improvements.

By Fiona Pattinson

Director of Business Development and Strategy