The nature of the cryptographic functions contained in any particular CSP depends on what task the CSP was designed to perform. For example, a VISA cryptographic hardware token would be able to digitally sign credit card transactions on behalf of the card's owner. A digital employee badge would be able to authenticate a user for physical or electronic access.
A CSP can perform one or more of these cryptographic functions and services:
Every CSP must provide secured storage of private keys. Applications may query the CSP to retrieve private keys stored within the CSP. The CSP is responsible for controlling access to the private keys it secures. The application must prove it is authorized to use the private key. A passphrase or other credentials are required for this purpose. Credentials can be provided by a callback function invoked by the CSP and implemented by the requester to identify and authorize the user or process requesting the private key. Most CSPs are capable of importing private keys created by other CSPs and providing secured storage for such keys.
Applications can create complex execution models for interacting with one or more CSPs, while a given CSP implementation can have a much simpler execution model. For example, an application could attach to the same CSP multiple times with different threads of execution each time. Each thread would get the appearance of having exclusive access to the CSP. Meanwhile the CSP may be implemented according to a single-threaded model. Additionally, the CSP may be managing multiple installed cards or multiple portable card slots on the system. An application may attach to the same CSP once for each card, as it looks like a different CSP, even though there is a single instance of the CSP attached to the CSSM.
Most applications use the CSSM CSP-APIs directly to request cryptographic operations. Applications also use CSP services indirectly through the certificate-based services of another add-in module (such as a trust policy).
Cryptographic service providers, whose capabilities may change after installation, may make dynamic requests to update profile information stored in the Module Directory Services relation for CSPs, or return that information directly to applications upon request through the CSSM-defined API.
Software CSPs are convenient and portable. Software CSPs can be carried as an executable file on common forms of removable media. The components that implement a CSP must be digitally signed, to authenticate their origin and integrity. This requirement extends to composite implementations involving both software and hardware. Multiple CSPs may be loaded and active within the CSSM at any time. A single application may use multiple CSPs concurrently. Interpreting the resulting level of trust and security is the responsibility of the application or the trust policy module used by the application.
CSSM defines a higher-level interface, based on keys and keypairs associated with certificates. The Cryptographic Services Module Manager defines a Service Provider Interface (SPI) that more closely resembles typical CSP APIs, and provides CSP developers with a single interface to support.
Embracing legacy CSPs, the CSSM architecture defines an optional adaptation layer between the Cryptographic Services Module Manager and a CSP. The adaptation layer allows the CSP vendor to implement a shim to map the CSSM SPI to the legacy CSP's existing API, and to implement any additional management functions that are required for the CSP to function as an add-in module in the extensible CSSM architecture. New CSPs may support the CSSM SPI directly (without the aid of an adaptation layer).
A CSP may or may not have a multi-threaded implementation.
It is anticipated that some CSP add-in modules will span SPI functional boundaries. For example, a smart card may also register as a data storage module that contains private keys and symmetric keys in tamper-resistant storage.
Security-conscious applications use these high-level concepts to provide authentication, data integrity, data and communication privacy, and nonrepudiation of messages to the end-users.
The CSP may implement any algorithm. For example, CSPs may provide one or more of the following algorithms, in one or more modes:
CSPs provide additional services:
The application's associated security context defines parameter values for the low-level variables that control the details of cryptographic operations. Applications use CSPs that provide the services and features required by the application. For example, an application issuing a request to EncryptData may reference a security context that defines the following parameters:
Most applications will use default (predefined) contexts. Typically a distinct context will be used for encrypting, hashing, and signing. For a given application, once initialized, these contexts will change little (if at all) during the application's execution, or between executions. This allows the application developer to implement security by manipulating certificates, using previously-defined security contexts, and maintaining a high-level view of security operations.
Application developers who demand fine-grained control of cryptographic operations can achieve this by directly and repeatedly updating the security context to direct the CSP for each operation, and by using the Cryptographic Services API pass-through feature.
The pass-through feature allows a highly knowledgeable application to call low-level CSP functions that are not available through the common Cryptographic API. The CSP Module Manager (CSPMM) will either reject the call or pass it through to the selected CSP. The CSPMM will not alter the result of the request, or generate other side effects based on the request. The philosophy of CDSA and the numerous services provided by CSSM is to reduce the need for applications to work at this low level.
Application processes may use the unique cryptographic services provided by a CSP via a pass-through capability in the Cryptographic Services API. The parameters to the pass-through interface include a security context, a CSP-specific function name, and the arguments to the function. After determining the authorization for the call (based on the invoking process, the CSP selected by the security context, and the specific function requested), the call is passed through to the specified CSP. The application process is responsible for the correctness of the arguments supplied to the call.
Key management
Every CSP is responsible for implementing its own secure, persistent storage and management of private keys. To support chains of trust across application domains, CSPs must support importing and exporting both public and private keys. This means transferring keys among remote and possibly foreign systems. The ability to transfer keys assumes the ability to convert one key format into any other key format, and to secure the transfer of private and symmetric keys (as required).
Each CSP is responsible for securely storing the private keys it generates or imports from other sources. Additional storage-related operations include retrieving a private key when given its corresponding public key, and wrapping private keys as key blobs for secure exportation to other systems.
Note that each CSP will create and manage its own private-key database. If an application requires that more than one CSP perform operations using the same private key, then that key must be exported from some source and imported to all CSPs needing to use it. Wrapping keys as key blobs manages the problem of different key formats among different CSPs. This assumes that the key length is acceptable to all CSPs using the same key.
Each CSP defines and implements its own key-management functions. Recent CSP implementations, such as Microsoft's Crypto API, define internal storage formats and key-blob wrappers for exporting keys outside of the CSP. CSPs will exchange private keys through secured communication protocols (such as wrappers), rather than through access to a shared database for private keys.
The CSMM API defines how private keys will be passed up and down through the layers of the CDSA, but it does not specify how private keys will be stored within the CSP.
| Contents | Next section | Index |