The National Institute of Standards and Technology (NIST) is the
US federal technology agency that works with industry to develop and
apply technology, measurements, and standards. One of the standards
published by NIST is the Federal Information Processing Standard Security
Requirements for Cryptographic Modules, referred to as FIPS 140-2.
FIPS 140-2 provides a standard that can be required by organizations
who specify that cryptographic-based security systems are to be used
to provide protection for sensitive or valuable data.
z/OS PKCS #11 cryptography is designed to meet FIPS 140-2 Level
1 criteria, and can be configured to operate in compliance with FIPS
140-2 specifications. Applications that need to comply with the FIPS
140-2 standard can therefore use the z/OS PKCS #11 services in a way
that allows only the cryptographic algorithms (including key sizes)
approved by the standard and restricts access to the algorithms that
are not approved. There are three modes of FIPS operation:
- The services can be configured so that all z/OS PKCS #11 applications
are forced to comply with the FIPS 140-2 standard. This is called FIPS
standard mode.
- For installations where only certain z/OS PKCS #11 applications
need to comply with the FIPS 140-2 standard, the services can be configured
so that only the necessary applications are restricted from using
the non-approved algorithms and key sizes, while other applications
are not. This is called FIPS compatibility mode. You can also
use FIPS compatibility mode to test individual applications to ensure
FIPS compliance before switching to FIPS standard mode.
- In FIPS no enforcement mode, ICSF will not impose FIPS
algorithm or key size restrictions unless the calling application
explicitly requests it.
ICSF installation options are described in the
z/OS Cryptographic Services ICSF System Programmer's Guide.
The installation option FIPSMODE indicates one of the following:
- FIPSMODE(YES, FAIL(fail-option))
- Indicates that ICSF is to operate in FIPS standard mode - all
applications that call ICSF PKCS #11 services will have a need to
run in FIPS 140-2 compliant fashion. Therefore, ICSF is to honor FIPS
140 restrictions pertaining to PKCS #11 algorithms and keys for all
applications that call ICSF PKCS #11 services.
ICSF initialization
will test that it is running on an IBM z Systems model type and version/release
of z/OS that supports FIPS. If so, ICSF initialization will also perform
a series of cryptographic known answer self tests. Should a test fail,
the action ICSF initialization takes is dependent on the fail option:
- FIPSMODE(YES, FAIL(YES))
- Indicates ICSF is to terminate abnormally if there is a failure
in any of the tests performed.
- FIPSMODE(YES, FAIL(NO))
- Indicates ICSF initialization processing is to continue even if
there is a failure in any of the tests performed. However, PKCS #11
support will be limited or nonexistent depending on the test that
failed:
- If ICSF is running on an IBM z Systems model type or with a version/release
of z/OS that does not support FIPS, most FIPS processing is bypassed.
PKCS #11 callable services will be available, but ICSF will not adhere
to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE
or those requests that explicitly ask for FIPS processing will result
in a failure return code.
- If a known answer test failed, all ICSF PKCS #11 callable services
will be unavailable.
- FIPSMODE(COMPAT, FAIL(fail-option))
- Indicates that ICSF is to operate in FIPS compatibility mode -
some selected applications that call ICSF PKCS #11 services will have
a need to run in FIPS 140-2 compliant fashion while others may not
be so restricted.
ICSF initialization will test that it is running
on an IBM z Systems model type and version/release of z/OS that supports
FIPS. If so, ICSF initialization will also perform a series of cryptographic
known answer self tests. Should a test fail, the action ICSF initialization
takes is dependent on the fail option:
- FIPSMODE(COMPAT, FAIL(YES))
- Indicates ICSF is to terminate abnormally if there is a failure
in any of the tests performed.
- FIPSMODE(COMPAT, FAIL(NO))
- Indicates ICSF initialization processing is to continue even if
there is a failure in any of the tests performed. However, PKCS #11
support will be limited or nonexistent depending on the test that
failed:
- If ICSF is running on an IBM z Systems model type or with a version/release
of z/OS that does not support FIPS, most FIPS processing is bypassed.
PKCS #11 callable services will be available, but ICSF will not adhere
to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE
or those requests that explicitly ask for FIPS processing will result
in a failure return code.
- If a known answer test failed, all ICSF PKCS #11 callable services
will be unavailable
Assuming all tests are successful, ICSF will honor FIPS 140 restrictions
pertaining to PKCS #11 algorithms and keys for selected applications
that call ICSF PKCS #11 services. This selection process is enabled
by the following function:- New CRYPTOZ Class resource profiles will allow the customer to
control the scope of FIPS 140-2 compliance at the token level. The
naming convention for these resources is:
- FIPSEXEMPT.token-name
- The levels of access are as follows:
- Profile not defined or Profile defined, caller has access NONE –
User not exempt. Algorithms and key sizes restricted as per FIPS 140-2.
For example: usage is treated as if ICSF was started with FIPSMODE(YES,
FAIL(fail-option)).
- Profile defined, caller has access READ – User’s use
of the token is exempt from the FIPS 140-2 algorithm restrictions.
A new vendor defined Boolean key attribute is
now supported, CKA_IBM_FIPS140. Applications may explicitly set this
at the time the key is created. The default value is FALSE. If set
to TRUE, ICSF will ensure that the key is only used in a FIPS 140-2
compliant fashion, and treated as if FIPSEXEMPT.
token-name access
NONE was specified.
Note: If CKA_IBM_FIPS140 is specified as a key
generation attribute, this would include the generation of the key
as well.
- FIPSMODE(NO,FAIL(fail-option))
- Indicates that ICSF should operate in FIPS no enforcement mode,
also known as FIPS on-demand mode. Applications may request strict
adherence to FIPS 140 restrictions when requesting ICSF services.
However, applications not requesting FIPS processing are not required
to adhere to FIPS 140 restrictions. FIPSEXEMPT.token-name profiles,
if they exist, will not be examined. If ICSF is running on an IBM
z Systems model type that does not support FIPS, requests
to generate or use a key with CKA_IBM_FIPS140=TRUE or those requests
that explicitly ask for FIPS processing will result in a failure return
code.
ICSF initialization will test that it is running on an IBM
z Systems model type and version/release of z/OS that supports FIPS.
If so, ICSF initialization will also perform a series of cryptographic
known answer self tests. Should a test fail, the action ICSF initialization
takes is dependent on the fail option:
- FIPSMODE(NO, FAIL(YES))
- Indicates ICSF is to terminate abnormally if there is a failure
in any of the tests performed.
- FIPSMODE(NO, FAIL(NO))
- Indicates ICSF initialization processing is to continue even if
there is a failure in any of the tests performed. However, PKCS #11
support will be limited or nonexistent depending on the test that
failed:
- If ICSF is running on an IBM z Systems model type or with a version/release
of z/OS that does not support FIPS, most FIPS processing is bypassed.
PKCS #11 callable services will be available, but ICSF will not adhere
to FIPS 140 restrictions. Requests to generate or use a key with CKA_IBM_FIPS140=TRUE
or explicitly ask for FIPS processing will result in a failure return
code.
- If a known answer test failed, all ICSF PKCS #11 callable services
will be unavailable.
If the FIPSMODE option is not specified, FIPSMODE(NO,
FAIL(NO)) is the default.
If any z/OS PKCS #11 application intends to use the services in
compliance with the FIPS 140-2 standard, then, in accordance with
that standard, the integrity of the load module containing the z/OS
PKCS #11 services must be checked when ICSF is started. This load
module is digitally signed, and, in order for applications using its
services to be FIPS 140-2 compliant, the signature must be verified
when ICSF is started. For more information, refer to Requiring signature verification for ICSF module CSFINPV2.
If any application will use PKCS #11 objects for AES Galois/Counter
Mode (GCM) encryption or GMAC generation, and will have ICSF generate
the initialization vectors, then you need to set ECVTSPLX or CVTSNAME
to a unique value. Refer to z/OS Cryptographic Services ICSF System Programmer's Guide for
more information.