A cryptographic module is a hardware or software device or component that performs cryptographic operations securely within a physical or logical boundary, using a hardware, software or hybrid cryptographic engine contained within the boundary, and cryptographic keys that do not leave the boundary.
NIST has championed the use of cryptographic modules. The Federal Information Processing Standard FIPS 140, Security Requirements for Cryptographic Modules, has served internationally as the main reference on cryptographic modules since 1994. The Cryptographic Module Validation Program (CMVP), jointly set up by NIST and the Communications Security Establishment Canada (CSEC), has been used since 1995 to validate cryptographic modules against the FIPS 140 specification, relying on an international network of accredited testing laboratories. The validation program has been very successful. FIPS 140 certification by the program is widely sought after not only for modules used in US and Canadian government applications, but also for modules used by other governments and modules used for commercial purposes unrelated to any government.
Unfortunately, the FIPS 140 standard has not been revised since FIPS 140-2 was issued in May 2001. Meanwhile, technological evolution has caused not just details but also the underlying philosophy of the standard to become outdated. An effort to revise the standard stalled after a draft of FIPS 140-3 was published in 2009. ISO 19790:2012 has been suggested as a candidate to succeed FIPS 140-2, but it only makes incremental changes.
At the International Cryptographic Module Conference that took place on November 4-6, 2015 in Washington DC, we made a presentation proposing three substantial changes that we believe should be included in a revision of FIPS 140 in order to bring the standard up to date.
First, encryption should be included as a method for protecting sensitive security parameters and data stored in a cryptographic module, as an alternative or a supplement to physical tamper resistance, with encryption keys derived from secrets kept by a hardware or cloud-based root-of-trust and/or supplied by a user.
Second, self-tests should be rethought: power-up or pre-operational self-tests should not be required for always-on battery powered devices or devices powered by NFC fields; computationally expensive tests that do not improve security, such as tests of a cryptographic algorithm against input/output data stored together with the algorithm, should be eliminated; on the other hand, continuous testing of the outputs of noise sources used by a random number generator, according to the recommendations in NIST Special Publication SP-800 90B, should be required.
Third, provisions should be made for faster and less onerous incremental recertification of a cryptographic module implemented within a rapidly-changing computational environment such as a mobile device. Such provisions may include: separate role-specific certification of module components (e.g. hardware, OS, software), with streamlined additional certification of a combination of components put together by a system integrator; and independent revalidation of different components at different times.
The conference was quite interesting, with technical and political controversy, as reported in this blog post.