| Internet Engineering Task Force | D. Lanz |
| Internet-Draft | L. Novikov |
| Intended status: Informational | MITRE |
| Expires: January 26, 2012 | July 25, 2011 |
Common Interface to Cryptographic Modules (CICM) Logical Model
draft-lanz-cicm-lm-01
This document defines an abstract model for high assurance cryptographic modules. It defines the relevant terminology and high-level descriptions of the types of services and operations offered by such modules. The goal is to provide a common vocabulary for discussing the programming of high assurance modules.
Comments are solicited and should be addressed to the mailing list at cicm@ietf.org.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 26, 2012.
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Sensitive data is increasingly under attack, whether in transit or at rest. The computer security community has responded to these threats by using cryptography to secure sensitive data. To counter the growing number and types of threats against systems processing sensitive data, module vendors have engineered a diverse set of cryptographic modules.
Systems that require cryptographic protection may use various cryptographic services including data encryption, signature generation, hashing, and keystream generation. Cryptographic modules providing these services and the key material they hold must be managed. All of these services have proprietary interfaces that differ significantly among module types, leading to the following problems:
To address these problems, this document outlines a logical model for the Common Interface to Cryptographic Modules (CICM) specification which offers module developers a set of standard programming interfaces for the set of operations supported by high assurance cryptographic modules. Although many Application Programming Interfaces (APIs) intended for commercial cryptography are available, the CICM specification was designed for high assurance environments, but may be used in other environments as well.
Modules do not require changes to support the use of CICM. A module-specific abstraction layer between the library implementing CICM interfaces and the module performs the needed translations between the CICM model of a module and the model presented by a specific module. This abstraction component may be provided by the module developer, a module embedder/integrator, or another interested party. This arrangement is analogous to manufacturers of computer peripheral devices providing platform or operating system-specific drivers for their peripheral devices.
The benefits of using standard interfaces to access cryptographic services include:
CICM is defined using Interface Definition Language (IDL) [IDL], a specification language that describes a software interface in a language-neutral way. The specification currently does not specify normative bindings for specific programming languages, although bindings for common languages can be generated from the IDL provided with the specification. However, normative bindings for one or more popular programming languages will be made available in a future release of the specification.
The use of IDL in CICM is not intended to either prescribe or preclude a particular communications protocol such as General Inter-ORB Protocol (GIOP) [CORBA] between programs in different address spaces or on different devices.
The CICM specification is written for computer programmers, software engineers, and technical architects with a background in data security and cryptography. Knowledge of object-oriented programming concepts is useful when reading IDL definitions. Software engineers may use the specification when developing software that integrates with cryptographic modules. Technical architects may use the specification when designing systems that incorporate cryptographic modules to secure data within the system or between systems.
Although the specification is targeted to software developers who will access module services using a compliant implementation, it also addresses module developers and others who implement library and other support software.
The CICM model should provide a common way to access the following services offered by cryptographic modules:
The following elements are not addressed:
A significant characteristic that differentiates CICM from other cryptographic interfaces such as Cryptoki [PKCS-11], GSS-API [RFC5554], and [JCA] is its ability to support cryptographic modules that separate two security domains. The use cases that follow capture this fundamental element of the CICM model. These use cases can be divided into two basic types:
The data-in-transit and data-at-rest use cases illustrated below incorporate multiple security domains, while the final use case depicts a transformation within a single domain.
The figure below shows a hardware device with an embedded cryptographic module providing encryption and decryption services between a secure and non-secure network. The secure side protocol logic subsystems access cryptographic services using CICM. In this use case, the High Assurance IP Encryptor (HAIPE) device uses CICM to enable the internal protocol logic of the device to access cryptographic services; the network to which the HAIPE device is connected does not interface to the protocol encryptor using CICM.
High Assurance IP Encryptor
+----------------------------.-----------------+
| HAIPE Cryptographic HAIPE |
Secure <-> Protocol <-> CICM <-> Module <-> Protocol <-> Non-Secure
Network | Logic . Logic | Network
+----------------------------.-----------------+
.
Security Domain
Boundary
Figure 1. First Data-in-Transit Use Case, HAIPE
The following figure depicts the same use case in its end-to-end configuration.
Security Domain
Boundary
.
+------------------------------.--------+
| HAIPE . |
( Secure ) <-> Protocol <-> CICM <-> Cryptographic <---+
( Network ) | Logic Module | |
+------------------------------.--------+ |
|
+-------------> ( Non-Secure ) <--------------+
| ( Network )
|
| +--------.------------------------------+
| | . HAIPE |
+---> Cryptographic <-> CICM <-> Protocol <-> ( Secure )
| Module Logic | ( Network )
+--------.------------------------------+
.
Security Domain
Boundary
Figure 2. HAIPE Use Case in End-to-End Configuration
A second data-in-transit use case shows a tactical secure radio with an embedded cryptographic module providing encryption and decryption services between a local host and a radio frequency environment. The functional blocks that make up the tactical secure radio are logically identical to those in the first example.
Tactical Secure Radio
+----------------------------.---------------------+
Host <-> Information <-> CICM <-> Module <-> Waveform <-> RF
| Processing . Processing |
+----------------------------.---------------------+
.
Security Domain
Boundary
Figure 3. Second Data-in-Transit Use Case, Tactical Secure Radio
The figure below shows a cryptographic module providing encryption services for data stored on a disk and decryption services for data read from a disk. A file system driver accesses cryptographic services using CICM. This use case could apply to a laptop computer that contains encrypted data; it would prevent access to sensitive data from a lost or stolen laptop.
Host .
+---------------------------------+ .
User <-> Word <-> File <-> CICM <-> Cryptographic <-> Disk
| Processor System | Module
+---------------------------------+ .
.
Security Domain
Boundary
Figure 4. Data-at-Rest Use Case
The following figure shows a cryptographic transform within a single security domain (it assumes that the transform does not change the classification of the data). The plaintext is conveyed to the module, transformed by an encryption algorithm, and results in ciphertext. This information is then returned to the same domain from which the plaintext originated. Other natural examples of a single domain use case include signing, which results in a digital signature; hashing, which results in a hash value; and keystream generation, which results in keystream data.
1. Query 2. Load
User <---------> Database <---------> Disk
Back end
|
+---------------> Cryptographic
3. Decrypt Module
Figure 5. Single Security Domain Use Case
The fundamental element of the CICM model is the MODULE -- an abstraction which refers to the cryptographic module and its capabilities. A single CICM library may provide access to multiple modules.
Each module contains references to information about the module, including the module manufacturer, serial number, and version numbers. Modules also defines attributes called MANAGERS that provide access to the services made available by the module.
Modules may require a host or user to authenticate to the module before the module will enter an operational state, allowing it to accept commands and perform cryptographic transformations. In some cases, a specialized, removable hardware component will perform or participate in the authentication. This hardware component is termed a HARDWARE ACCESS TOKEN in CICM nomenclature, although other communities may use different terminology. Most implementations that use hardware access tokens will transfer key material between the token and module, independent of CICM. In cases where access tokens are not supported, a user may provide authentication credentials to the module via CICM. In still other cases, support for multi-factor authentication will require a token and a user login. Note that the user and token holder may be different entities.
CICM provides interfaces that can be used separately or in combination with one another as appropriate for the system using them and for the authentication mechanisms offered by the module that is used by the system. Methods to manage module/token associations are available for systems where hardware access tokens are supported. Login methods and related user management methods are supported for systems that require user login.
The TOKEN MANAGER defines methods that support associating a token with a module, disassociating a token from a module, and disassociating a module from a token. The manager also supports retrieving a list of token associations on a module and module associations on a token.
The USER MANAGER defines methods that support adding users to and removing users from a module user database, and associating a user with a module-defined ROLE. The manager also supports listing the user database, and the roles defined and supported by the module.
The LOGIN MANAGER defines methods that enable a user configured on a module to login to and logout from a module.
The PACKAGE MANAGER defines methods that support importing and managing the executable images that reside on a cryptographic module. These methods enable module software/firmware PACKAGES to be imported and other software package management operations to be performed, including retrieving a list of packages, and activating or deleting a specific package.
The package manager enables packages to be imported into a module in segments rather as an atomic unit. This supports modules that must make special provisions to import executable images due to internal storage space limitations.
Modules generate log entries as they operate. The LOG MANAGER defines methods that support retrieving individual log entries or extracting an entire log from a module. Additionally, clients may clear individual log entries or the entire module log.
Modules may incorporate built-in tests to validate that module functionality is operating as designed. Some tests may be externally initiated. The TEST MANAGER defines methods that support host-initiated module tests.
The MODULE EVENT MANAGER defines methods that support registering/unregistering module-generated event notifications received by a client program. Clients can register custom-developed CALLBACK procedures, called LISTENERS, for specific module events. When the condition associated with a specific listener presents itself, the registered listener is called.
Examples of events for which listeners may be registered include:
Cryptographic modules use key material under their protection as one input to perform a cryptographic transformation. Keys
Once established on a module, they may be subject to client-initiated management operations or may be used as part of a cryptographic channel to effect cryptographic transformations.
CICM treats SYMMETRIC KEYS and ASYMMETRIC KEYSETS separately. An asymmetric keyset may comprise an asymmetric key pair, the public and private key components of a keypair, the digital certificate corresponding to the keyset public key, one or more verification certificates in the certificate chain of trust, and related public domain parameters.
The ASYMMETRIC KEY MANAGER and SYMMETRIC KEY MANAGER attributes allow for access to asymmetric keysets and symmetric keys, respectively.
Keys may be moved into a module in one of several scenarios. Each scenario is described in detail below.
Specialized hardware devices designed to transfer key from a key infrastructure component to a specific cryptographic module may fill key into a module without host involvement and thus no API interaction. In some cases, this process does not support transferring key metadata with a key. This requires host and API interaction to apply metadata to the key inside the module upon completion of the fill.
In some cases, key fill devices require host interaction to initiate a key fill. In such cases, the target key storage location or key tagging information can be specified prior to the initiation of the fill.
Keys may be imported directly or derived using a text-based secret provided by the user of the client program. Keys also may be generated on the module. Each case results in a persistent key.
A key also is implicitly established each time a channel is created using an asymmetric keyset and upon renegotiation. Keys resulting from channel-based key agreement are ephemeral; they are not generally managed outside of a channel. Ephemeral keys also may be destroyed when a channel is destroyed.
A facility to operate a key agreement protocol with an infrastructure component is supported. This facility also enables key material or key revocation information to be authenticated by one of the module's trust anchors, and then loaded into the module.
Methods to export key material out of a module are supported. A module may require wrapping the key material prior to export or may disallow this operation.
A method to locate a specific key on a module based upon identification information associated with the key is supported. In addition, the entire key database may be listed.
Key metadata may be retrieved and set for individual keys. Metadata elements include the key identifier, alias, and classification. Untagged keys that are imported via a fill device may require certain metadata to be applied after the conclusion of the load.
A number of management operations on keys are supported. Keys may be wrapped (cryptographically protected) in preparation for export, or unwrapped after import. All key material on the module can be zeroized either on a key-by-key basis or as a whole. There are also operations to perform key conversions and updates.
CICM supports various key management-related protocol messages including remote key functions (e.g., remote zeroize or rekey), infrastructure-initiated key revocation, and trust anchor management.
The CHANNEL is the fundamental construct under which one or more related cryptographic transforms are performed, and within which all details and attributes associated with the transform are encapsulated, including the path through the module. Most channels accept data from a port in the local security domain, transform the data, and output the result on a port in another security domain. A channel also may perform transformations within a single security domain, or may accept data for transformation in one domain and output the result in another. The channel type determines which ports must be specified when a channel is created.
Security Domain Security Domain
Boundary Boundary
. .
+--------.--------+ +--------.--------+
Client --(a) Cryptographic (b)---(c) Cryptographic (d) -- Client
Program X | Module | | Module | Program Y
+--------.--------+ +--------.--------+
. .
X local X remote Y remote Y local
port (a) port (b) port (c) port (d)
Figure 6. Local and Remote Port Nomenclature for Channels that Operate in Two Security Domains
Three classes of objects are fundamental to the creation and use of CICM channels. A CONTROLLER is used to configure and control a channel. A STREAM enables data to be sent to a module to be transformed, and transformed data to be received using a controller as a foundation. A CONDUIT is the sum of a controller and a stream. Thus, the term "channel" is only an abstraction representing the logical path through the module on which cryptographic transformations are performed.
+----------------------------------------+ | Channel | | | | +-----------------------+ | | | +--------------------+ | | | Controller | Conduit | Stream | | | +-----------------------+ | | | +--------------------+ | +----------------------------------------+
Figure 7. Relationship Between Channel, Conduit, Controller, and Stream
This division of responsibility makes channels very flexible. One client program can be responsible for creating and managing channels with a controller, and another can send data over this pre-configured channel for transformation using a stream. In some environments, data to be transformed never enters the host to pass through the API. Instead, it is clocked directly through the module. In this situation, a controller is configured, but no stream is configured since it would never be used. In other cases, a client program is required to configure the channel and pass data through the channel it configured. In this case, the client program configures a conduit, which incorporates a controller and a stream.
Both controllers and conduits accept symmetric keys, requiring that the client program configuring the channel and its remote peer share the same secret key. Alternatively, all peers may hold their own respective asymmetric keysets, requiring a key negotiation which, upon successful completion, results in each peer holding an ephemeral symmetric key. CICM supports a NEGOTIATOR for this purpose. A successful negotiation results in a negotiated controller or conduit.
CICM supports the following channel types:
CICM also supports hybrid channel types. A channel that simultaneously supports encryption and signature, resulting in both ciphertext and a final signature value, is a hybrid channel.
Each of the types above differs in the way it is configured, its configuration options, and how it handles the cryptographic transformation of data. Consider the following examples portraying the diversity of the channel types:
This diversity results from the fundamental characteristics of the cryptographic primitives that are being abstracted. The CHANNEL MANAGER defines the methods that support creating conduits, controllers, streams, and negotiators for each of the channel services listed above.
Creating a channel requires an awareness of the options available:
Selecting among these options enables the client program developer to determine what channel interface to use.
In cases where an asymmetric keyset is used, channels are created as a result of a key agreement protocol negotiation with a remote peer. To ensure that it is the expected peer, a human user at the client may validate information extracted from the peer's certificate. If the module uses a trusted display, the module communicates the peer information directly to the display. Based upon user input at the display, host-independent negotiation is continued or aborted. If no trusted display is available, the client program requests information about the remote peer, displays it at the host for user confirmation, and provides positive confirmation via the API that the peer is valid, allowing the negotiation to continue.
CICM defines interfaces to support encryption and decryption between two security domains or within a single security domain. Additional variants are defined including hybrid channels that can concurrently compute integrity values. Another set of variants provides methods to perform encryption/decryption with selective bypass.
If an asymmetric keyset is used to create a channel, a negotiation process is initiated, which results in a negotiated channel. Negotiated versions of hybrid channels also are available. For those negotiator versions that combine encryption with integrity value generation, negotiation applies only to the encryption key specified when the channel is negotiated, not the signature or MAC key.
Channel-based multiple key wrap/unwrap support is provided via a special channels for that purpose.
CICM also supports encryption/decryption channels that operate in coprocessor mode . These channels accept their input and return their output as part of the same method call. Where relevant, the integrity value or verification status (verified/not verified) is returned when the final block of the input has been presented for transformation.
Duplex channel configurations that use the same key to perform encrypt and decrypt transformations also are supported. Negotiated versions of the duplex channel also are available.
Bypass channels capable of defining a path through a module and then bypassing data from one security domain to a different domain are supported. Selective bypass also is supported on encryption and decryption channels.
Interfaces to compute and validate integrity values using asymmetric key-derived digital signatures or symmetric key-derived MACs are available. A variant on the sign and verify interfaces accepts a previously generated hash value in place of a message.
A channel to calculate a fixed-length cryptographic hash from an input message is available. Keyed hashes are supported by MAC channels.
Channels are supported to read keystream from a module.
Separate interfaces are defined to retrieve random or pseudorandom data from a module.
Only conduits and controllers (not streams) can manage channels. Negotiators can manage the negotiation aspects of a channel.
The management operations that can be performed on a channel are specific to each channel type, but the following general operations are supported:
Negotiators support the following general operations:
Managing state vectors is an important channel management capability. CICM provides a method to explicitly generate a state vector for those algorithms/modes that require a random initialization vector (IV), although modules may alternatively generate an IV as a byproduct of channel creation. CICM also provides a method to set the state vector on a channel. This may be used to:
Only conduits and streams (not controllers) can send data for transformation and receive cryptographically transformed data on a channel.
The data operations that can be performed on a channel or stream are specific to each channel type, but the following general operations are supported:
Although it is possible for multiple client programs to use the same stream, the model provides no facilities to coordinate the parties participating in the communication.
Certain channel services support receiving an "answer" from a channel. For example, signature and hashing channels accept variable amounts of data for transformation before returning a final, constant-sized "answer" (a signature or a hash) to the caller. HYBRID CHANNELS require sending/receiving data and receiving a final "answer" after a discrete unit of data has been transformed.
The figure below depicts the use of a hybrid channel. Plaintext is sent through CICM for transformation. The module performs encrypt and sign transformations on the plaintext data. Ciphertext resulting from the encrypt transform emits from the module in a different security domain than the one in which it originated. When it is finished presenting data for transformation, the client program requests the signature that results from the transaction.
.
Plaintext . Ciphertext
Host ---------> Cryptographic ---------->
<--------- Module
Signature .
.
Security Domain
Boundary
Figure 8. Hybrid Sign-Encrypt Channel Operations
Each type of channel supports a specific set of channel data operations. Channel types and the data operations they support are listed below:
Controllers and conduits can be grouped to enable certain characteristics to be shared. One characteristic may be the state vector associated with the channels. This supports environments where two or more channels with related security rules supporting a single operation are used within a system. Whenever a shared characteristic is changed on a controller or conduit in a group, the effect of this change is applied to all controllers/conduits in the group.
The CICM model defines methods that support managing module event notifications. Similar support is available at the granularity of an individual conduit/controller. Conduits and controllers define methods that support registering/unregistering channel-specific module-generated event notifications captured by a client program. Clients can register custom-developed callback procedures called listeners for specific channel events. When the condition associated with a specific listener presents itself, the registered listener is called.
Examples of channel events for which listeners may be registered include:
Conduits and controllers may be destroyed when their services are no longer needed. A channel is destroyed without regard for users who may have pending operations on the channel. Any ephemeral keys associated with the channel also may be destroyed. A stream ceases to function when its associated controller is destroyed. A destroyed channel is removed from any channel groups to which it belongs without effect upon other controllers/conduits in the group.
[RFC Editor: Please remove this section prior to publication.]
This document has no IANA actions.
Cryptographic modules are typically protected assets and most have built-in mechanisms for preventing unauthorized usage. Section 3.1 discusses several mechanisms for preventing unauthorized usage including using hardware access tokens and user login. Specific implementations may also consider the use of access control lists.
The log manager described in Section 3.3 may be used by some modules to report certain types of usage which may act as a type of audit log thereby providing information about inappropriate usage.
Many of CICM's channel types provide confidentiality services such as encryption and decryption as well as data integrity services such as hashing, MACing, signing, and verifying.
Hybrid channels provide a combination of confidentiality and data integrity service.
There are four broad categories of bypass that are supported: reading and writing full bypass; encrypting and decrypting with selective bypass. These services must be used with caution in order to avoid accidental or malicious bypass of protected data.
As described in Section 5, a negotiator is the primary mechanism for establishing that the peer entity is the one desired.
Similarly, the mechanism described in Section 4.1.3 ensures that the infrastructure component that is attempting to send data to the module is trusted.
This section contains a list of terms and their corresponding definitions as used in this model. Following the formatting convention in [RFC4949], each term is preceded by a dollar sign ($) and a space to facilitate automated searching.
$ alarm
$ asymmetric key
$ asymmetric keyset
$ asynchronous notification
$ attribute
$ authentication
$ authorization
$ blocking
$ buffer
$ bypass
$ callback
$ certificate
$ certificate revocation list (CRL)
$ channel
$ channel type
$ client program
$ conduit
$ controller
$ coprocessor mode
$ cryptographic module
$ cryptographic synchronization
$ cryptographic transform
$ driver
$ ephemeral symmetric key
$ event
$ event notification
$ grade
$ hardware access token
$ host
$ hybrid channel
$ iterator
$ key
$ key agreement protocol
$ key encryption key
$ key fill device
$ key fill interface
$ key infrastructure
$ key rollover
$ key tag
$ key unwrap
$ key update
$ key wrap
$ keystream
$ listener
$ local port
$ manager
$ message authentication code (MAC)
$ method
$ namespace
$ non-blocking
$ opaque data object
$ package
$ persistent key
$ policy
$ port
$ remote port
$ role
$ security domain
$ selective bypass
$ static key
$ stream
$ symmetric key
$ system
$ tamper
$ token
$ trusted display
$ zeroize