Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1 Project/Component Working Name:
Kernel Cryptographic Framework support for FIPS 140-2
1.2 Name of Document Author/Supplier:
Anthony Scarpino
Technical Description
The Interface taxonomy is Consolidation Private.
The Release taxonomy is Patch/Micro
Diff-marked draft manpages, cspi design, and header files are included
in the case directory.
Background
Among the many requirement FIPS 140-2 documents, one is that of
each algorithm modules in the boundary to perform a POST (Power-On
Self Tests) when an algorithm modules loads. A FIPS 140 boundary is defined
as a set of binaries that will be verified before crypto operations are
allowed from any binary in the boundaries.
Another requirement is that the API, which FIPS 140 support is provided
through, cannot operate until the boundary has been verified by approved
FIPS 140 means.
In the Kernel Cryptographic Framework, a providers (or algorithm module)
registers with the kcf kernel module when it loads using the existing
Service Provider Interface (SPI). This allows the Cryptographic
Framework to know what functions the provider supports, among many other
things, before the provider is allowed to operate.
Simply by defining a POST function does not the make the module
FIPS 140-compliant. This is just one piece of the validation process with
which involves a lab that specializes in FIPS 140 validations.
Proposal
For POST support, extending the existing SPI so algorithm modules
can register an entry point for a POST function, it allows kcf to
orchestrate the running of POST for each of the algorithm modules
when the framework is configured in FIPS 140-2 mode.
This case would add another structure to the crypto_ops(9s),
crypto_fips140_ops(9s) and increment the SPI version to 4.
The algorithms modules that support FIPS 140 will be modified to use
the version 4 SPI entry point (spi.h). crypto_fips140_ops will contain
one entry point:
void (*fips140_post)(int *);
With regard to preventing operations on FIPS 140 boundary modules until
the boundary has been verified. In nearly all the cases modifying
existing code can support this operation, but random is the exception.
The kcf random API requires two new functions that will delay
operations until the boundary can be verified. The existing random
functions must remain untouched because some consumers of those
functions cannot operate properly immediately without random data.
All consumers using random, desiring to operate under FIPS 140-2
compliance, must use the new APIs. This case does not change the
RNG or PRNG at all.
The new functions are:
int random_get_bytes_fips140(uint8_t *ptr, size_t len);
int random_get_pseudo_bytes_fips140(uint8_t *ptr, size_t len);
Compatibility
The SPI interface was introduced by PSARC 2001/553. The have
been incremented by PSARC 2005/576 and PSARC/2007/092.
The kernel kcf module will remain backwards compatible with
version 1, 2, and 3 providers.
Bug/RFE Number(s): 6870299
Exported Interfaces:
+--------------------------------+---------------------------+--------------+
| Interface | Classification | Comments |
+--------------------------------+---------------------------+--------------+
| impl.h | Consolidation | include file |
| | Private | |
| | | |
| spi.h | Consolidation | include file |
| | Private | |
| | | |
| ioctladmin.h | Project Private | include file |
| | | |
| sched_impl.h | Project Private | include file |
| | | |
| random.h | Contracted Consolidation | include file |
| | Private | |
| | | |
+--------------------------------+---------------------------+--------------+
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
