{"id":3608,"date":"2016-11-10T17:03:00","date_gmt":"2016-11-10T16:03:00","guid":{"rendered":"https:\/\/webdev.atsec.us\/?p=3608"},"modified":"2024-07-26T20:57:08","modified_gmt":"2024-07-26T18:57:08","slug":"fips-140-2-and-iso-standards","status":"publish","type":"post","link":"https:\/\/webdev.atsec.us\/fips-140-2-and-iso-standards\/","title":{"rendered":"FIPS 140-2 and ISO Standards"},"content":{"rendered":"\n<figure class=\"wp-block-image size-full is-resized\"><img loading=\"lazy\" decoding=\"async\" width=\"480\" height=\"480\" src=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/06\/atsec-at-contact-us.png\" alt=\"\" class=\"wp-image-2379\" style=\"width:275px;height:auto\" srcset=\"https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/06\/atsec-at-contact-us.png 480w, https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/06\/atsec-at-contact-us-300x300.png 300w, https:\/\/webdev.atsec.us\/wp-content\/uploads\/2024\/06\/atsec-at-contact-us-150x150.png 150w\" sizes=\"(max-width: 480px) 100vw, 480px\" \/><\/figure>\n\n\n\n<p>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<\/p>\n\n\n\n<p>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:<\/p>\n\n\n\n<ul>\n<li>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&nbsp; examples of others, such as the Japan CMVP which is part of the&nbsp; 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.<\/li>\n\n\n\n<li>Several Common Criteria national schemes who may often draw from cryptographic module or cryptographic algorithm validations in their own assurance work.<\/li>\n\n\n\n<li>The UK\u2019s <a href=\"http:\/\/www.tsol.gov.uk\/PanelCounsel\/pdf\/Encryption_and_Erasure_Guidance_for_Panel_Counsel_June_2012.pdf\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">information commissioner\u2019s office<\/a> and Treasury Solicitor\u2019s Department, both of which <a href=\"http:\/\/www.tsol.gov.uk\/PanelCounsel\/pdf\/Encryption_and_Erasure_Guidance_for_Panel_Counsel_June_2012.pdf\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">recommend using<\/a> FIPS 140-2 validated encryption products.<\/li>\n\n\n\n<li>The Health industry. For example, the HITECH act provides for &#8220;safe harbor&#8221; 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.<\/li>\n\n\n\n<li>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.<\/li>\n\n\n\n<li>Voting Systems. The Electoral Assistance Commission\u2019s Voluntary Voting System Guidelines recommend the use of FIPS 140-2 for cryptography in voting systems.<\/li>\n\n\n\n<li>&nbsp;Digital Cinema. FIPS 140-2 is specified in the digital cinema specification, V1.2.<\/li>\n<\/ul>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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 <strong>ISO\/IEC 19790<\/strong> which was published in 2006 (and was very familiar to those with knowledge of FIPS 140-2).<\/p>\n\n\n\n<p>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 \u201capproval authority,\u201d and the terminology was updated to include \u201cSensitive Security Parameters\u201d (SSP),&nbsp; \u201cCritical Security Parameters\u201d (CSP), etc. Technically, the specification was very similar to FIPS 140-2.<\/p>\n\n\n\n<p>In 2008 a companion document, equivalent to the NISTs \u201cDerived Test Requirements\u201d for FIPS 140-2, was published. <strong>ISO\/IEC 24759:2008<\/strong>: Information technology &#8212; Security techniques &#8212; Test requirements for cryptographic modules.<\/p>\n\n\n\n<p>This document pair provided the basic requirements for forming an approval authority independent of the CMVP.<\/p>\n\n\n\n<p>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<strong> ISO\/IEC 19790<\/strong> 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\u2019s <a href=\"http:\/\/www.iso.org\/iso\/home\/store\/catalogue_tc\/catalogue_detail.htm?csnumber=52906\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">online store<\/a> or from your favorite purveyor of standards.)<\/p>\n\n\n\n<p>The companion test requirements document, <strong>ISO\/IEC 24759<\/strong>, is currently undergoing revision and will be published when the final draft is approved by the ISO voting members.<br><br>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\u2019s cryptographic algorithm validation program (CAVP) that provides the pre-requisite assurances for the fundamental functions employed in cryptographic modules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Testing and validation of conformance to ISO\/IEC 19790<\/h3>\n\n\n\n<p>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 &#8211; and use of the tools provide for consistent testing, validation, and certification of conformance to the ISO standard.<br><br>This is already happening.<\/p>\n\n\n\n<ul>\n<li>In Japan, IPA operates a <a href=\"http:\/\/www.ipa.go.jp\/security\/english\/jcmvp.html\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">cryptographic module validation program<\/a> with ISO\/IEC 19790 as a basis known as the JCMVP.&nbsp; At the ICMC in 2013, Japan announced that a memorandum of understanding between the JCMVP and the CMVP.<\/li>\n\n\n\n<li>in Korea, the <a href=\"http:\/\/service1.nis.go.kr\/\" target=\"_blank\" rel=\"noreferrer noopener\">Korean Cryptographic Module Validation Program<\/a> (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.<\/li>\n\n\n\n<li>A validation program in Spain for cryptographic modules is based on the ISO standards<\/li>\n\n\n\n<li>A validation program in Turkey for cryptographic modules is based on the ISO standards<\/li>\n\n\n\n<li>Other national programs are under consideration&nbsp;<\/li>\n<\/ul>\n\n\n\n<p>With the development of validation programs using the standards &#8212; and perhaps even one day mutual recognition by different programs &#8212; 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).<\/p>\n\n\n\n<p>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:<\/p>\n\n\n\n<ul>\n<li>accrediting test laboratories<\/li>\n\n\n\n<li>making program policies<\/li>\n\n\n\n<li>defining the approved cryptographic functions,<\/li>\n\n\n\n<li>establishing algorithm implementation testing and validation<\/li>\n\n\n\n<li>establishing a management system for validating and certifying the testing results<\/li>\n\n\n\n<li>providing any necessary interpretations of the standards<\/li>\n\n\n\n<li>dealing with comments, requests, and issues from labs and vendors<\/li>\n\n\n\n<li>policing the certificate and logo usage<\/li>\n<\/ul>\n\n\n\n<h1 class=\"wp-block-heading\">What changed in the 2012 revision of ISO\/IEC 19790?<\/h1>\n\n\n\n<p>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:<\/p>\n\n\n\n<ul>\n<li>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 &#8220;sick&#8221; the entire module must refuse any services. This requirement has been quite restrictive but is now relaxed.<\/li>\n\n\n\n<li>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. &nbsp;<\/li>\n\n\n\n<li>New requirements for developer testing on the module have been introduced to complement the lab&#8217;s testing. In this sense, the testing requirements become more aligned with what Common Criteria considers &#8220;developer&#8221; vs.&#8221;independent&#8221; 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. &nbsp;<\/li>\n<\/ul>\n\n\n\n<p>The new revision continues to specify four security levels. Below is a summary of the levels and the basic requirements of each:<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security Level 1<\/h3>\n\n\n\n<ul>\n<li>At least one approved security function or approved sensitive security parameter establishment method<\/li>\n\n\n\n<li>Operation in a non-modifiable, limited, or modifiable operating environment<\/li>\n\n\n\n<li>No physical security mechanisms are required above production-grade components<\/li>\n\n\n\n<li>Any Non-invasive mitigation methods or mitigation of other attacks which are implemented are documented<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security Level 2<\/h3>\n\n\n\n<ul>\n<li>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<\/li>\n\n\n\n<li>Role-based authentication<\/li>\n\n\n\n<li>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<\/li>\n<\/ul>\n\n\n\n<p>Security level 2 continues to be the highest security level attainable by a pure software module.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Security Level 3<\/h3>\n\n\n\n<ul>\n<li>Additional requirements to mitigate the unauthorized access to SSPs held within the cryptographic module<\/li>\n\n\n\n<li>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<\/li>\n\n\n\n<li>Identity-based authentication mechanisms<\/li>\n\n\n\n<li>Manually established plaintext CSPs must be encrypted, utilize a trusted channel or use a split knowledge procedure for entry or output<\/li>\n\n\n\n<li>Mechanisms to protect &nbsp;a cryptographic module against a security compromise due to environmental conditions outside of the module&#8217;s normal operating ranges for voltage and temperature<\/li>\n\n\n\n<li>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<\/li>\n\n\n\n<li>Additional life-cycle assurances, such as automated configuration management, detailed design, low-level testing, and operator authentication using vendor-provided authentication information<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security Level 4<\/h3>\n\n\n\n<ul>\n<li>Multi-factor authentication for operator<\/li>\n\n\n\n<li>The module includes special environmental protection features designed to detect voltage and temperature boundaries and zeroize CSPs<\/li>\n\n\n\n<li>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<\/li>\n\n\n\n<li>Design verification by the correspondence between both pre- and post-state conditions and the functional specification<\/li>\n<\/ul>\n\n\n\n<h4 class=\"wp-block-heading\">Requirements areas<\/h4>\n\n\n\n<p>The security requirements are organized into 11 requirement areas; many of these areas have changes from those specified in FIPS 140-2:<\/p>\n\n\n\n<ol>\n<li><strong>Cryptographic module specification: <\/strong>This area includes the cryptographic module specification general requirements, the types of cryptographic modules, the cryptographic boundary and the modes of operations<\/li>\n\n\n\n<li><strong>Cryptographic module interfaces: <\/strong>This area includes the cryptographic module interfaces general requirements, the types of interfaces, the definition of interfaces and trusted channel requirements<\/li>\n\n\n\n<li><strong>Roles, services, and authentication: <\/strong>This area includes &nbsp;the general requirements for roles, services, and authentication<\/li>\n\n\n\n<li><strong>Software\/Firmware security:<\/strong><\/li>\n\n\n\n<li><strong>Operational environment: <\/strong>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<\/li>\n\n\n\n<li><strong>Physical security<\/strong>: This area includes requirements for embodiments, general requirements, requirements for each physical security embodiment and Environmental failure protection\/testing requirements<\/li>\n\n\n\n<li><strong>&nbsp;<\/strong><strong>Non-invasive security<\/strong><\/li>\n\n\n\n<li><strong>Sensitive security parameter management : <\/strong>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<\/li>\n\n\n\n<li><strong>&nbsp;<\/strong><strong>Self-tests: <\/strong>general requirements for self tests, pre-operational self-tests, and conditional self-tests<\/li>\n\n\n\n<li><strong>&nbsp;<\/strong><strong>Life-cycle assurance: <\/strong>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<\/li>\n\n\n\n<li><strong>&nbsp;Mitigation of other attacks<\/strong><\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\"><strong>The Annexes of ISO\/IEC 19790:2012<\/strong><\/h3>\n\n\n\n<p>&nbsp;&nbsp;&nbsp;&nbsp;<strong>A<\/strong>.&nbsp;&nbsp;&nbsp;&nbsp; Documentation requirements for each of the eleven requirement areas.<br><strong>&nbsp;&nbsp;&nbsp; B.<\/strong>&nbsp;&nbsp;&nbsp;&nbsp; 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.<br><strong>&nbsp;&nbsp;&nbsp; C.<\/strong>&nbsp;&nbsp; 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.<br><strong>&nbsp;&nbsp;&nbsp; D.<\/strong>&nbsp;&nbsp; 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.<br><strong>&nbsp;&nbsp;&nbsp; E.<\/strong>&nbsp;&nbsp;&nbsp;&nbsp; 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.<br><strong>&nbsp;&nbsp;&nbsp; F.<\/strong>&nbsp;&nbsp;&nbsp;&nbsp; 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.<br><em><\/em><\/p>\n\n\n\n<h1 class=\"wp-block-heading\">But wait!!! There&#8217;s more&#8230; Supporting work from ISO<\/h1>\n\n\n\n<p>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:<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/store\/catalogue_tc\/catalogue_detail.htm?csnumber=52906\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 19790<\/a>&nbsp;Security requirements for cryptographic modules<\/h4>\n\n\n\n<h4 class=\"wp-block-heading\">First published in 2006, based closely on the FIPS 140-2 standard, a second edition evolved the specification and was published in 2012.<br>A technical corrigendum has been processed, and a corrected reprint was issued in 2015. &nbsp;<br><a href=\"http:\/\/www.iso.org\/iso\/home\/store\/catalogue_tc\/catalogue_detail.htm?csnumber=59142\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 24759<\/a>&nbsp;Test requirements for cryptographic modules<\/h4>\n\n\n\n<p>First published in 2008, with a second revision in 2014. A corrected reprint was published in 2015<\/p>\n\n\n\n<p>A minor revision is currently being processed for publication.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/store\/catalogue_tc\/catalogue_detail.htm?csnumber=60612\" target=\"_blank\" rel=\"noreferrer noopener\">IS 17825<\/a>: Testing methods for the mitigation of non-invasive attack classes against cryptographic modules<\/h4>\n\n\n\n<p>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.<br>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.<\/p>\n\n\n\n<p>This standard was first published in 2016.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/iso_catalogue\/catalogue_tc\/catalogue_detail.htm?csnumber=45151\" target=\"_blank\" rel=\"noreferrer noopener\">IS 29128<\/a>: Verification of cryptographic protocols<\/h4>\n\n\n\n<p>The goal of this International Standard is to establish means for verification of cryptographic protocol specifications to provide defined levels&nbsp;of confidence concerning the security of the specification of cryptographic protocols.<br><br>This standard was first published in 2011.<br><br><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/search.htm?qt=20085&amp;sort=rel&amp;type=simple&amp;published=on\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 20085<\/a>:&nbsp;Test tool requirements and test tool calibration methods for use in testing non-&nbsp; invasive attack mitigation techniques in cryptographic modules&nbsp;<\/h4>\n\n\n\n<p>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.&nbsp;<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>This multipart standard will have two parts:<br>\u2014 Part 1: Test tools and techniques<br>\u2014 Part: 2 Test calibration methods and apparatus&nbsp;<a href=\"https:\/\/www.blogger.com\/null\" target=\"_blank\" rel=\"noopener noreferrer nofollow\"><\/a><\/p>\n\n\n\n<p>These new documents are still in draft.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/store\/catalogue_tc\/catalogue_detail.htm?csnumber=56890\" target=\"_blank\" rel=\"noreferrer noopener\">TR 30104<\/a>: Physical Security Attacks, Mitigation Techniques and Security Requirements<\/h4>\n\n\n\n<p>This technical report provides guidance and addresses the following topics:<\/p>\n\n\n\n<ul>\n<li>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;<\/li>\n\n\n\n<li>guidance on the principles, best practices and techniques for the design of tamper protection mechanisms and methods for the mitigation of those attacks; and<\/li>\n\n\n\n<li>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.<\/li>\n<\/ul>\n\n\n\n<p>This Technical Report was first published in 2015<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/search.htm?qt=18367&amp;sort=rel&amp;type=simple&amp;published=on\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 18367<\/a>: Cryptographic algorithms and security mechanisms conformance testing&nbsp;<\/h4>\n\n\n\n<p>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.<br><br>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<br>Monte Carlo testing, or a combination of test methods. Testing may be performed on the actual implementation or modeled in a simulation environment.<br><br>This International standard is currently being processed for its initial publication in 2016.<br><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/search.htm?qt=20540&amp;published=on&amp;active_tab=standards&amp;sort_by=rel\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">TR 20540<\/a>:&nbsp;Guidelines for Testing Cryptographic Modules in their operational environment<\/h4>\n\n\n\n<p>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\u2019s Security Policy document. &nbsp;This document is still in draft.<br><\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/search.htm?qt=20543&amp;sort=rel&amp;type=simple&amp;published=on\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 20543<\/a>:&nbsp;Test and analysis methods for random bit generators within ISO\/IEC 19790 and ISO\/IEC 15408<\/h4>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>Design and implementation of non-deterministic random bit generators are outside the scope of this International Standard.<\/p>\n\n\n\n<p>This document is still in draft.<\/p>\n\n\n\n<h4 class=\"wp-block-heading\"><a href=\"http:\/\/www.iso.org\/iso\/home\/search.htm?qt=20897&amp;sort=rel&amp;type=simple&amp;published=on\" target=\"_blank\" rel=\"noopener noreferrer nofollow\">IS 20897<\/a>:&nbsp;Security requirements, test and evaluation methods for physically unclonable functions for generating non-stored security parameters&nbsp;<\/h4>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>One application of PUF is the seeding of true random number generators.&nbsp;<\/p>\n\n\n\n<p>The document is still in draft.&nbsp;<br><\/p>\n\n\n\n<h4 class=\"wp-block-heading\">IS 19896:&nbsp;Competence requirements for information security testers and evaluators<\/h4>\n\n\n\n<p>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.<\/p>\n\n\n\n<p>The standard is a multipart standard with three parts:<br>\u2014 Part 1: Introduction, concepts and general requirements<br>\u2014 Part 2: Knowledge, skills and effectiveness requirements for ISO\/IEC 19790 testers<br>\u2014 Part 3: Knowledge, skills and effectiveness requirements for ISO\/IEC 15408 evaluators<br>The documents are all in draft.<\/p>\n\n\n\n<p><br><em>&#8212;<b>With thanks to the editors of ISO\/IEC 19790 including Randall Easter, Jean-Pierre Qu\u00e9mard and Junichi&nbsp;Kondo and also the convener of SC 27&#8217;s working group 3, Miguel&nbsp;Ba\u00f1\u00f3n, for their review of this text and for suggesting corrections and improvements.<\/b><\/em><\/p>\n\n\n\n<p><font size=\"2\">By Fiona Pattinson<br>Director of Business Development and Strategy<\/font><\/p>\n","protected":false},"excerpt":{"rendered":"<p>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 [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":2379,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[9,1],"tags":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3608"}],"collection":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/comments?post=3608"}],"version-history":[{"count":2,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3608\/revisions"}],"predecessor-version":[{"id":3684,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/posts\/3608\/revisions\/3684"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media\/2379"}],"wp:attachment":[{"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/media?parent=3608"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/categories?post=3608"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webdev.atsec.us\/wp-json\/wp\/v2\/tags?post=3608"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}