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.
Stamps.com
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

23. ADDITIONAL BACKGROUND

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