exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

csl95-08.txt

csl95-08.txt
Posted Aug 17, 1999

A Framework for Cryptographic Standards

tags | paper
SHA-256 | 1ad98e899cdd0e782210589ae652eb01d97c134cdea97fe646b12b688c1757e7

csl95-08.txt

Change Mirror Download

FIPS 140-1: A FRAMEWORK FOR CRYPTOGRAPHIC STANDARDS
On July 17, 1995, the National Institute of Standard and
Technology (NIST), Computer Systems Laboratory (CSL), established
the Cryptographic Module Validation (CMV) Program which validates
cryptographic modules to Federal Information Processing Standard
(FIPS) 140-1, Security Requirements for Cryptographic Modules.
Under this program, vendors of cryptographic modules use
independent, accredited testing laboratories to have their
modules tested. The program was jointly developed by NIST and
the Communications Security Establishment of the government of
Canada. Products validated as conforming to FIPS 140-1 will be
accepted for use by the federal agencies of both countries for
the protection of sensitive, unclassified information. The goal
of the CMV Program is to provide federal agencies with a security
metric to use in procuring equipment containing cryptographic
modules. The results of the independent testing, by accredited
laboratories, provide this metric. Federal agencies can choose
products from the FIPS 140-1 Validated Products List and know
that their FIPS 140-1 requirements have been met.

This bulletin discusses when and how FIPS 140-1 should be used
and examines the benefits that agencies can derive in using the
standard. While the bulletin highlights several critical issues
that federal agencies need to consider, agencies should rely on
FIPS 140-1 for precise applicability statements, requirements,
and policy for use.

FIPS 140-1 as a Framework Standard
A cryptographic module is that part of a system or application
that provides cryptographic services such as encryption,
authentication or electronic signature generation and
verification. A cryptographic module that is designed to meet
FIPS 140-1 incorporates cryptographic algorithms and functions
specified in related FIPS and other security features that are
necessary for the security of the module. The standard is
flexible in that it allows application or program managers to
choose the robustness of the security features and functionality
that is needed. The standard specifies four increasing security
levels to allow for cost-effective cryptographic solutions that
are appropriate for different degrees of data sensitivity and
different application environments. FIPS 140-1 defines the
framework for NIST's current and future cryptographic standards.

Background
Federal Standard (FS) 1027, General Security Requirements for
Equipment Using the Data Encryption Standard, was issued by the
General Services Administration in 1982. The standard prescribed
the minimum general security requirements for the implementation
of the Data Encryption Standard (DES) in telecommunications
equipment and systems used by the federal government. The
responsibility for FS 1027 was transferred to NIST in 1988 and FS
1027 was redesignated as FIPS 140.

NIST recognized the need to revise FIPS 140 to reflect the
evolving needs of users and manufacturers, and to incorporate
current trends and capabilities in technology. A notice was
published in the Federal Register in 1988 to solicit the views of
industry, the public, and federal, state and local governments
regarding the planned revision of FIPS 140. NIST received
numerous comments which encouraged the planned revision and
offered specific suggestions for changes.

The resulting revised standard, FIPS 140-1, Security Requirements
for Cryptographic Modules, was developed by a committee of
government and industry participants which was organized by NIST
in 1989. A Federal Register notice in 1991 announced the
proposed revision of the standard and requested comments from
government and industry. Numerous comments and suggestions were
received, many of which were incorporated into the final version
of the standard. On January 11, 1994, NIST issued FIPS 140-1 as
an approved standard, with an effective date of June 30, 1994.

Applicability
For all federal agencies, including defense agencies, the use of
encryption products which conform to FIPS 140-1 is mandatory for
the protection of sensitive unclassified information when the
agency determines that cryptographic protection is required.
Note that information covered by 10 U.S.C. 2315, commonly
referred to as the Warner Amendment, is excluded from this
requirement. Agencies are required to use the standard in
designing, acquiring, and implementing cryptographic-based
security systems within computer and telecommunications systems
(including voice systems).

Definition of a Cryptographic Module
A cryptographic module (cryptomodule) is a set of hardware,
firmware or software, or some combination thereof, that
implements cryptographic logic or processes. Examples include a
standalone piece of equipment such as a link encryptor, an add-on
encryption board embedded into a computer system, and a software
application running on a microprocessor such as a digital
signature application that services many other applications. If
the cryptographic logic is implemented in software, then the
processor which executes the software is also part of the
cryptographic module.

Structure of the Standard
FIPS 140-1 identifies eleven areas of security requirements over
the following four security levels:

The Level 1 requirements of the standard specify the basic
security requirements for a cryptographic module (e.g., the
encryption algorithm must be FIPS-approved). No physical
security mechanisms are required for the module beyond the
requirement for production-grade equipment. Level 1 allows the
use of integrated circuit (IC) cards (i.e., smart cards) and
software implementations which are utilized in general purpose,
single-user personal computers (PC). NIST believes that such
implementations are often appropriate in low-level security
applications. Smart cards enhance the security of most systems.
Since the card is kept in the user's possession, additional
physical security measures are often not necessary. Many vendors
use smart cards as a secure medium when distributing
cryptographic keys. The implementation of PC cryptographic
software may be more cost-effective than hardware-based
mechanisms.

Level 2 improves on the physical security of a Level 1
cryptographic module by adding the requirement for tamper
evidence through the use of tamper-evident coating or seals, or
pick-resistant locks. These requirements provide a cost-
effective means for physical security and avoid the cost of the
higher level of protection required at Levels 3 and 4. The basic
security concept is that the coating or seal placed on the module
would have to be broken in order to attain physical access to the
plaintext cryptographic keys and other critical security
parameters within the cryptographic module. Level 2 provides
role-based authentication which allows groups of users to utilize
the services of the cryptographic module without each user being
uniquely identified. For example, a set of security officers may
all use their own copy of the same physical key that is inserted
and turned to reset a cryptographic module to an operational
status. The cryptographic module can authenticate that the user
is a security officer; however, the module does not uniquely
identify which officer.

Level 2 requirements also allow software cryptography in multi-
user, multi-tasking systems when used in conjunction with a C2
or equivalent trusted operating system. The controls provided by
a trusted operating system are needed to maintain the security
necessary for protected information such as private or secret
keys, authentication information, the algorithm software, and
other necessary parameters.

A Level 3 cryptographic module has requirements that help to
prevent an intruder from gaining access to the cryptographic
keys, authentication data, and other security parameters held
within the cryptographic module. The covers and doors of the
module contain zeroization circuitry such that an unauthorized
attempt to open a cover or door will zeroize the keys,
authentication data, and other security parameters. The keys,
authentication data, and other security parameters are input to
the module through separate ports and trusted paths. The key
management requirements at this level specify split-knowledge
techniques. A split-knowledge technique ensures that a
cryptographic key is under the control of two or more users.
Each user has a key component which, individually, conveys no
knowledge of the resultant key. Level 3 allows software
cryptography in multi-user, multi-tasking systems when a B1 or
equivalent trusted operating system is employed.

A Level 4 cryptographic module provides an envelope of protection
around the cryptographic module. The intent of Level 4
protection is to detect a penetration of the device from any
direction (rather than just attempts at the cover or door covered
by Level 3 requirements) and respond by destroying critical
information before it can be acquired. For example, if one
attempts to cut through the cover of a cryptographic module, the
attempt should be detected and all critical security parameters
should be zeroized. Level 4 allows software cryptography in
multi-user, multi-tasking systems when a B2 or equivalent trusted
operating system is employed. A B2 operating system provides a
large number of assurances of the correct operation of the
security features of the operating system.

The Eleven Security Requirements Areas
Cryptographic Module Specification requirements ensure that the
cryptographic module is explicitly defined. Modules must have
defined hardware components, software components, and firmware
components if applicable. The module must have a stated security
policy that is reflected in the design and intended use of the
module. The module must have every operational and error state
defined as specified in the Finite State Machine Model
requirements. The requirements in these areas help agencies to
determine exactly what a particular cryptographic product
consists of, help ensure that vendors use good design techniques
in building a cryptographic module, and allow NIST to more easily
determine if the requirements for a particular module have been
met.

Module Interface requirements help ensure that all information
flow and physical access to and from the module are well-defined
and controlled. At the higher security levels, requirements help
ensure that critical information such as authentication
information and cryptographic keys are not compromised when
entered or output from the module.

Roles and Services requirements help ensure that the module
supports defined authorized roles and corresponding services.
The module must also provide a mapping of the services to the
roles. At Level 2, the module must be able to authenticate that
an operator of the module can assume a specific role (i.e., role-
based authentication). At Levels 3 and 4, the module must be
able to uniquely authenticate the operator (identity-based
authentication).

Physical Security requirements help restrict unauthorized
physical access to the contents of the module and to deter
unauthorized use or unauthorized modification of the module.
Level 1 requires standard protection provided by production-grade
techniques. Level 2 requires that modules can show evidence of
tampering. Level 3 requires that modules zeroize unprotected
cryptographic keys, authentication data, and other important
information when the module detects tampering or an unauthorized
access attempt through the cover or doors of the module's
enclosure. Level 4 requires that modules respond as in Level 3;
however, the module must detect tampering or attempts anywhere on
the module's enclosure.

Software Security requirements apply to security-relevant
software or firmware that may be contained within the module.
These requirements help ensure that the software corresponds to
and has correctly implemented the defined security policy of the
module. At Level 4, more vigorous requirements require formal
proof of this correspondence.

Operating System Security requirements help protect cryptographic
software implementations in modules where untrusted software will
also be used. The Level 1 requirements allow software
cryptographic functions to be run on a general-purpose PC.
Requirements at the higher levels help ensure the security of
software cryptography in multi-user, time-shared systems by
requiring a trusted operating system.

Key Management requirements help ensure the security of
cryptographic keys throughout the cryptographic key life cycle.
Requirements in this area relate to key generation, distribution,
entry, use, storage, destruction, and archiving. FIPS approved
methods are required for key generation and distribution.
However, until a FIPS approved public key-based key distribution
technique is established, commercially available public key
methods may be used (e.g., the Diffie-Hellman public key
distribution technique). To prevent the compromise of
electronically distributed secret or private keys, requirements
specify that the keys should always be entered into or out of the
module in encrypted form. Manually distributed keys, which
should be protected using safeguards and procedures that are
beyond the scope of this standard, can be entered or output from
the module in plaintext form at Levels 1 and 2. Levels 3 and 4
requirements provide for applications where dual control of keys
are needed. This requires the module to support key entry by
either entering the key in encrypted form or using split-
knowledge procedures. Split-knowledge procedures force the key
to be entered or output as two key components.

The Cryptographic Algorithm requirement mandates that the module
implement a FIPS approved cryptographic algorithm. The current
FIPS approved cryptographic algorithms include: the Data
Encryption Standard (FIPS 46-2) and the Escrowed Encryption
Standard (FIPS 185) for encryption; the Computer Data
Authentication Standard (FIPS 113) and the Digital Signature
Standard (FIPS 186) for authentication and signature
generation/verification; and the Secure Hash Standard (FIPS 180-
1) for use when a secure hash algorithm is required. Modules
must meet the requirements within the respective standard of the
implemented algorithm. In addition to FIPS approved algorithms,
products may also contain other algorithms that are not FIPS
approved. However, an algorithm that is not FIPS approved may
not be used in lieu of the FIPS approved algorithm for government
applications.

Self-Test requirements help ensure that the cryptographic
processing of the module is operating correctly. These self-
tests check the cryptographic algorithm, software, and firmware
integrity and other vendor-defined critical functions.

Effective Use of FIPS 140-1
The following steps are recommended when implementing a
cryptographic system:

 Identify information resources and determine the sensitivity
to and potential impact of losses. Determine security
requirements based on risk assessment and applicable
organizational security policies. Look at data sensitivity and
the environment in which the data is placed. Consider threats to
the data or application as a whole, and what level of risk is
acceptable. Define this level of risk.

 Determine the acceptable safeguards for the system under
review. Determine which cryptographic services provide an
acceptable safeguard. Define those security features that are
desirable for use in a cryptographic environment.

 Examine FIPS 140-1. Consider the requirements in each area.
Determine those requirements that specify the features that are
desired. Determine those requirements (if any) specified in FIPS
140-1 that were not originally considered. Specify the
appropriate level in each area of the standard based on the
acceptable level of risk.

 Obtain or develop cryptographic modules that meet or exceed
the selected levels.

While the security requirements specified in this standard are
intended to maintain the security of the cryptographic module,
conformance to FIPS 140-1 does not guarantee that a particular
module is secure. It is the responsibility of the manufacturer
of a cryptographic module to build the module in a secure manner.
Similarly, the use of a cryptographic module that conforms to
this standard in an overall system does not guarantee the
security of the overall system. The responsible authority in
each agency must assure that an overall system provides an
acceptable level of security.

Selecting an Appropriate Level
An application or program manager need not choose the same level
for all eleven requirements. The standard's flexibility allows
for choosing different levels among the eleven requirement areas.
Using this flexibility is encouraged. As an example, consider an
organization that will be using a digital signature generation
and verification software implementation on a multi-tasking,
multi-user operating system. The organization determines the
need to use a trusted operating system to protect the integrity
and availability of the encryption software for all system users.
The organization may require Level 2 Operating System
requirements. The organization then determines that solid key
management, including split-knowledge procedures, is critical in
this application and requires Level 3 Key Management
requirements. However, only Level 1 Physical Security
requirements for the system are necessary since the controls and
procedures used to maintain a secure facility and the personnel
operating the system are adequate in protecting the system
physically. As this example shows, a different level of the
standard can be chosen for the different areas covered by the
standard.

Determining Conformance to FIPS 140-1
The CMV Program validates cryptographic modules as conforming to
FIPS 140-1. The National Voluntary Laboratory Accreditation
Program (NVLAP), administered by NIST, accredits independent
testing laboratories to perform the FIPS 140-1 tests. Vendors of
cryptographic modules use these laboratories to have their
modules tested. The accredited laboratories send the test
results to NIST.

Based on the test results from these laboratories, NIST
determines the level of conformance to the standard and issues an
appropriate validation certificate of conformance. Since the
initiation date of the CMV Program was July 17, 1995, NIST
encourages federal agencies to begin specifying FIPS 140-1
validated products in their procurements. However, federal
agencies may accept written affirmation from cryptomodule vendors
as evidence of conformance to FIPS 140-1 until January 31, 1996.
After that date, agencies should procure only those products that
are either validated or have been submitted to an accredited
testing laboratory for testing. After January 31, 1997, federal
agencies should procure only products that have been validated by
NIST under the CMV Program. The list of validated products is
available electronically at http://csrc.ncsl.nist.gov.

Products that have been endorsed by the National Security Agency
as meeting FS 1027, or have been affirmed in writing as meeting
FIPS 140, can be purchased without NIST validation until June 30,
1997. After that date, agencies should purchase products only if
they have been NIST-validated. Agencies that purchase equipment
under the conditions above may continue to use the equipment
without requiring further affirmation or validation for
conformance to this standard. NIST maintains a list of products
that are available under the FS 1027 and FIPS 140 provisions.

For More Information
FIPS 140-1, the validated products list, and a listing of NVLAP
accredited laboratories are available electronically at
http://csrc.ncsl.nist.gov. FIPS 140-1 can also be obtained in
hard copy from the National Technical Information Service (NTIS)
at (703) 487-4650. Questions regarding the CMV Program should be
directed to Lisa J. Carnahan at (301) 975-3362 or
lcarnahan@nist.gov.
Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    0 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close