Design secure network products to meet FIPS 140-2 and Common Criteria standards

The good news for designers is that the FIPS 140-2 and Common Criteria security standards not only ensure good practices in establishing the security requirements, but also provide for a design evaluation process that is executed by an outside security laboratory to ensure successful implementation.

FIPS 140-2 overview
The U.S. National Institute of Science and Technology (NIST) is a world leader in validating the "correctness" of cryptography designs. The NIST FIPS 140-2 standard provides for the requirements, evaluation process, and validation certification of cryptographic products¹. FIPS 140-2 describes requirements for a number of security areas (See Table 1).

Click here for Table 1

The FIPS 140-2 standard defines four levels of security, called Security Level 1 through Security Level 4. A brief description of these four levels:

• Security Level 1: Provides the lowest level of security. Software-only products cannot meet any level higher than Security Level 1.
• Security Level 2: The first level to require some physical security requirements (i.e. tamper evidence). Also requires role-based authentication.
• Security Level 3: Requires identity-based authentication and high probability of tamper-detection.
• Security Level 4: Provides the highest level of security. Includes protecting a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature.

In addition to establishing cryptographic security requirements and design assurance processes to be used during the design, FIPS 140-2 and NIST define a process for an outside laboratory to evaluate product compliance. FIPS 140-2 also establishes a methodology for thorough evaluation.

The Computer Security Division of NIST, in cooperation with CSE of Canada, created a Cryptographic Module Validation Program (CMVP) that accredited twelve testing labs in the United States, Canada and Europe that provide early product assessment and identification of areas of non-conformance. Laboratories then typically develop a testing schedule to review compliance supporting documentation and perform independent testing. NIST also provides Derived Test Requirements for FIPS 140-2 (DTR) that describe methods that will be used by accredited laboratories to test whether the cryptographic module conforms to the requirements of FIPS PUB 140-2. The structure of the DTR also provides a thorough methodology so that security requirements are not overlooked.

Common Criteria overview
The scope of security involves more than just cryptography. Additional security areas must be addressed including vulnerability assessment, security auditing, and the effectiveness of design documentation. The Common Criteria for IT Security Evaluation is a security standard that is the result of a multi-national effort to harmonize differing national security requirements. Today, Common Criteria is supported by the International Standards Organization as ISO-15408. The Common Criteria standard ² is currently being updated and will be released soon as Version 3.0. This article utilizes the Version 3.0 structure for discussion.

The ISO-15408 standard itself is presented in four separate pieces. The Common Criteria (CC) contains three parts. Part 1 provides an overview of the Common Criteria process and defines requirements for two major documents, the Protection Profile (PP) and the Security Target (ST).

Part 2 provides descriptions of various Security Functions (SF) that can be considered for inclusion in the design of a product (See Table 3). Part 3 provides descriptions of Security Assurance requirements for the product (see Table 4). Finally, a fourth document called the Common Methodology for IT Security Evaluation (CEM) describes the methodology that evaluators use to check compliance for each required Security Assurance component. ISO-15408 provides for products to be evaluated at seven levels of security assurance (See Table 2).

The Protection Profile (PP) document establishes a set of security marketing requirements for a class of products to serve a specific market. The intent of the PP is to allow consumer groups and communities of interest to express their security needs, for instance a PP may address firewalls or for Java-enabled smartcards. The PP provides details on the level of security that must be met, including a description of security threats to be mitigated, and establishes security assumptions regarding the environment.

While the PP is the security marketing requirements document, the Security Target (ST) document is an implementation-dependent statement/specification of security needs for a specifically identified product called the Target of Evaluation (TOE). Common Criteria allows for two scenarios: (A) ST documents that claim to conform to a specific Protection Profile and (B) a "stand-alone" ST where no Protection Profile conformance is claimed.

The Security Target document must be certified by the Common Criteria process and becomes a public document. If the ST claims PP conformance, the ST must meet every requirement within the PP, or the ST will be found to be non-compliant.

Click here for Table 3

An interesting point regarding Common Criteria is that the "certification" of cryptographic mechanisms is usually left to the FIPS 140-2 process, rather than detailed in the Common Criteria standard. That is, a typical requirement in a CC Protection Profile document is to ask for FIPS 140-2 certification of the cryptographic module.

Click here for Table 4

Page 2: next page
Page 1 | 2