Presentation is loading. Please wait.

Presentation is loading. Please wait.

The Cryptographic Module Validation Program and FIPS 140-2

Similar presentations

Presentation on theme: "The Cryptographic Module Validation Program and FIPS 140-2"— Presentation transcript:

1 The Cryptographic Module Validation Program and FIPS 140-2

2 Security Specifications
Systems Protocols Smart Cards PKI Telecom Biometrics Healthcare Firewalls Operating Systems DBMS Web Browsers SSL TLS SMIME IKE EKE SPEKE IPSEC NIAP CygnaCom COACT SAIC TUVIT CSC Domus InfoGard Atlan Accredited Testing Labs ARCA EWA FIPS 140-2 Crypto Modules Encryption Hashing Authentication Signature Key Mgt. DES SHA-1 SHA-256 SHA-384 SHA-512 DES MAC HMAC DSA Wrapping D-H MQV RSA FIPS 171 RSA CMVP 3DES ECDSA DSA2 Skipjack RSA2 AES ECDSA2 Future Standard, Specification or Recommendation Standard in Progress Existing Standard Test Development in Progress Standard and Testing Available no Industry Standard,


4 Cryptographic Module Validation Program (CMVP)
Established by NIST and the Communications Security Establishment (CSE) in 1995 Original FIPS requirements and updated FIPS requirements developed with industry input Six NVLAP-accredited testing laboratories True independent 3rd party accredited testing laboratories Can not test and provide design assistance

5 CMVP Accredited Laboratories
EWA - Canada LTD, IT Security Evaluation Facility Domus IT Security Laboratory COACT Inc. InfoGard Laboratories Atlan Laboratories CEAL: a CygnaCom Solutions Laboratory Sixth CMT laboratory added in 2001

6 Applicability of FIPS 140-2
U.S. Federal organizations must use validated cryptographic modules GoC departments are recommended by CSE to use validated cryptographic modules International recognition

7 Flow of a FIPS 140-2 Validation
Vendor CMT Lab CMVP User Designs and Produces Tests for Conformance Validates Specifies and Purchases Cryptographic Module and Algorithm Cryptographic Module and Algorithm Test Results and Signs Certificate Security and Assurance

8 FIPS 140-2 Security Levels Security Spectrum
Not Validated Level 1 Level 2 Level 3 Level 4 Level 1 is the lowest, Level 4 most stringent Requirements are primarily cumulative by level Overall rating is lowest rating in all sections

9 Derived Test Requirements
Cryptographic module testing is performed using the Derived Test Requirements (DTR) Assertions in the DTR are directly traceable to requirements in FIPS 140-2 All FIPS requirements will be included in the DTR as assertions Provides for one-to-one correspondence between the FIPS and the DTR The DTR is a separate document from the FIPS standard. The DTR is an essential document to both the testing lab and as a starting point for the vendor. All assertions in the DTR are directly traceable to requirements in FIPS The DTR for the FIPS standard did not have directly traceable assertions and therefore in some areas there was ambiguity in the requirements. The one-to-one correspondence with the FIPS DTR will reduce this ambiguity as much as possible. The DTR will be available 6 months after the FIPS standard has been signed. However I am in the process of updating and reviewing the document and hope to have it out sooner. We will post it on the CMVP web pages as soon as possible.

10 Derived Test Requirements (concluded)
Each assertion will include requirements levied on the Cryptographic module vendor Tester of the cryptographic module Modules tested against FIPS will use the associated DTR The DTR was not only updated to reflect the one-to-one correspondence from the standard, but to reflect the knowledge gained in the use of the FIPS DTR by both vendors and the labs. Areas where the requirements were vague, or the testing requirements either unclear, confusing or impractical were changed. One item to point out: The DTR states very clearly what the vendor needs to know in regard to required documentation, and what specific testing will be done. Therefore early in a design cycle, these issues can be addressed so that when the product goes to a lab for testing, there hopefully will be few surprises.

11 Revalidations An updated version of a previously validated cryptographic module can be considered for a revalidation rather than a full validation depending on the extent of the modifications from the previously validated version of the module. Modifications are made to hardware, software or firmware components that do not affect any FIPS security relevant items. Signed Letter from Accredited Laboratory Modifications are made to hardware, software or firmware components that affect some of the FIPS security relevant items. Re-validation TE’s annotated as RE-Tested with an overall regression test performed

12 CMVP Status Continued record growth in the number of cryptographic modules validated Over 200 Validations representing nearly 250 modules All four security levels of FIPS represented on the Validated Modules List Over forty participating vendors

13 FIPS 140-1 and FIPS 140-2 Validations by Year and Level (January 15, 2002)

14 2001 Validation Milestones
Certificate 200 December 18, 2001 FIPS Signed 05/25/01 FIPS DTR Available 11/15/01 FIPS Validations Accepted Certificate 150 May 23, 2001

15 Validated Modules By Type
Link/Frame Encryptors Radios/Phones Faxes Postal PC/Smart/Tokens PDAs Co-Processors Kernels/Toolkits Accelerators Routers/VPNs

16 FIPS Testing Begins FIPS Testing officially began November 15, 2001 FIPS Testing ends May 25, 2002 Testing laboratories may submit FIPS validation test reports until May 25, 2002 After May 25, 2002 all validations and revalidations must be done against FIPS 140-2

17 FIPS 140-2 - Testing Begins …
Agencies may continue to purchase, retain and use FIPS validated products after May 25, 2002. NIST has provided common algorithmic testing tool to Accredited Laboratories: Includes DES, Triple-DES and AES DSA and SHA-1 - to be integrated ECDSA available as separate tool – to be integrated RSA, SHA-{256,384,512}, DH, MQV - future

18 CMVP Status (concluded)
End of FIPS testing and beginning of FIPS testing and validations with new implementations of FIPS 197 (AES) expected to cause unparalleled growth Increasing international recognition of the CMVP and FIPS 140-2

19 Communications - Electronics Security Group (CESG) - UK December 28, 2001 CESG proposes the use of FIPS 140 as the basis for the evaluation of cryptographic products used in a number of UK government applications and encourages the setting up of accredited laboratories in the UK to perform these evaluations.

20 164 Cryptographic Modules Surveyed (during testing)
… Making a Difference 164 Cryptographic Modules Surveyed (during testing) 80 (48.8%) Security Flaws discovered 158 (96.3%) Documentation Errors 332 Algorithm Validations (during testing) (DES, Triple-DES, DSA and SHA-1) 88 (26.5%) Security Flaws 216 (65.1%) Documentation Errors Areas of Greatest Difficulty Physical Security Self Tests Random Number Generation Key Management

21 Participating Vendors (January 15, 2002)
Alcatel Algorithmic Research, Ltd. Ascom Hasler Mailing Systems Attachmate Corp. Avaya, Inc. Baltimore Technologies (UK) Ltd. Blue Ridge Networks Certicom Corp. Chrysalis-ITS Inc. Cisco Systems, Inc. Cryptek Security Communications, LLC CTAM, Inc. Cylink Corporation Dallas Semiconductor, Inc. Datakey, Inc. Ensuredmail, Inc. Entrust Technologies Limited Eracom Technologies Group, Eracom Technologies Australia, Pty. Ltd. F-Secure Corporation Fortress Technologies Francotyp-Postalia GTE Internetworking IBM Intel Network Systems, Inc. IRE, Inc. Kasten Chase Applied Research L-3 Communication Systems Litronic, Inc. M/A Com Wireless Systems Microsoft Corporation. Motorola, Inc. Mykotronx. Inc National Semiconductor Corp. nCipher Corporation Ltd. Neopost Neopost Industrie Neopost Ltd. Neopost Online Netscape Communications Corp. NetScreen Technologies, Inc. Network Associates, Inc. Nortel Networks Novell, Inc. Oracle Corporation Pitney Bowes, Inc. PrivyLink Pte Ltd PSI Systems, Inc. Rainbow Technologies RedCreek Communications Research In Motion RSA Data Security, Inc. SchlumbergerSema Spyrus, Inc. Technical Communications Corp. Thales e-Security TimeStep Corporation Transcrypt International Tumbleweed Communications Corp. V-ONE Corporation, Inc.

22 FIPS and FIPS 140-2 Derived Test Requirements (DTR) Annexes to FIPS 140-2 Implementation Guidance Points of Contact Laboratory Information Validated Modules List Special Publication


24 Pays accreditation fee Submits module for testing; Pays testing fee
Submits application; Pays accreditation fee Submits module for testing; Pays testing fee NVLAP Program Accredited FIPS 140-1 Testing Lab Cryptographic Module Vendor Conducts on-site assessment; Accredits labs NIST publishes list of NVLAP Accredited Labs Tests for conformance to FIPS 140-1; Writes test report Issue testing & implementation guidance List of NVLAP Accredited Labs Module’s Test Report Issue validation certificate To NIST/CSE for validation NIST/CSE Level # List of Validated FIPS 140-1 Modules NIST publishes list of validated modules

25 FIPS 140-1: Basic Requirements
Defined module boundary. Finite State Machine specification. Defined security policy. Specification of roles and services. Selection of authentication mechanisms. Self-tests of algorithms, random number generators, and critical functions during power-on.

26 Cryptographic Algorithms
Must include at least one FIPS approved cryptographic algorithm. Data Encryption Algorithm (DES) Triple DES (allowed for U.S. Government use) Digital Signature Standard (DSA, RSA), Secure Hash Algorithm (SHA-1) Must meet requirements in FIPS algorithm standard.

27 FIPS Security Level 1 Specification of the cryptographic module boundary. Production-grade equipment. Logical separation of roles and services but no required authentication. FIPS approved key management. Allows software cryptographic services on a single user general purpose computer.

28 FIPS Security Level 2 Tamper evident coatings or seals, or pick-resistant locks. Role-based authentication to determine if an operator is authorized to assume a specific role and perform a corresponding set of services. Allows software cryptography in evaluated multi-user timeshared systems.

29 FIPS Security Level 3 Tamper detection and response for covers and doors. Identity-based authentication. Stronger requirements for entering and outputting critical security parameters and cryptographic keys. Trusted path requirements for modules using trusted operating systems.

30 FIPS Security Level 4 Envelope of protection around the entire cryptographic module. Environmental failure protection and testing. Formal modeling for software.

31 Differences Between FIPS 140-1 and FIPS 140-2
140-1 & 2 Tables of Contents FIPS 140-1 1. Overview 2. Glossary of Terms and Acronyms 3. Functional Security Requirements 4. Security Requirements 4.1 Cryptographic Modules 4.2 Cryptographic Module Interfaces FIPS 140-2 1. Overview 2. Glossary of Terms and Acronyms* 3. Functional Security Requirements 4. Security Requirements 4.1 Cryptographic Module Specification* 4.2 Cryptographic Module Interfaces * Section added or significantly revised

32 140-1 & 2 Tables of Contents (Continued)
FIPS 140-1 4.3 Roles and Services 4.4 Finite State Machine Model 4.5 Physical Security 4.6 Software Security 4.7 Operating System Security 4.8 Cryptographic Key Management FIPS 140-2 4.3 Roles, Services, and Authentication 4.4 Finite State Machine Model 4.5 Physical Security* 4.6 Operating System Security* 4.7 Cryptographic Key Management * Section added or significantly revised

33 140-1 & 2 Tables of Contents (Continued)
FIPS 140-1 4.9 Cryptographic Algorithms 4.10 EMI/EMC 4.11 Self-Tests FIPS 140-2 4.8 EMI/EMC 4.9 Self-Tests 4.10 Design Assurance* 4.11 Mitigation of Other Attacks* * Section added or significantly revised

34 140-1 & 2 Tables of Contents (Concluded)
FIPS 140-1 Appendices A: Summary of Documentation Requirements B: Recommended Software Development Practices C: Selected References FIPS 140-2 Appendices A: Summary of Documentation Requirements B: Recommended Software Development Practices* C: Cryptographic Module Security Policy* D: Selected Bibliography* * Section added or significantly revised

35 FIPS 140-2: Final Revisions
4.2 Cryptographic Module Interfaces Security Levels 3 and 4 Physical ports for input/output of plaintext CSPs shall be physically separate from other ports Logical interfaces for input/output of plaintext CSPs shall be logically separate from all other interfaces Requires implementation of a trusted path

36 FIPS 140-2: Final Revisions (continued)
4.6 Operational Environment Operating system definition expanded to operational environment general purpose operational environment refers to the use of a commercially-available general purpose operating system (i.e., resource manager) manages the software and firmware components within the cryptographic boundary Limited operational environment refers to a static non-modifiable virtual operational environment with no underlying general purpose OS Requirements in FIPS do not apply Modifiable operational environment refers to an operating environment that may be reconfigured to add/delete/modify functionality and/or may include general purpose OS capabilities Requirements in FIPS apply

37 FIPS 140-2: Final Revisions (continued)
4.10 Design Assurance Development Deleted requirements addressed in other sections of FIPS 140-2 Guidance Deleted security requirements for the IT environment Functional Testing and Test Coverage Deleted all requirements

Download ppt "The Cryptographic Module Validation Program and FIPS 140-2"

Similar presentations

Ads by Google