Cryptography has been known for decades to protect sensitive or secret information from unintended personnel while the information was delivered via unsecured channels. By encryption, a message is transformed into a form unreadable by anyone without a secret decryption key. Encryption is the only way known so far that can protect the privacy of information traveling in unsecured networks. Cryptography may also be used to protect the integrity of information by a process called message authentication and verification [FIP85]. The process involves the calculation of a computer checksum based on the message to be sent. The checksum is sent along with the message to a recipient, who may recompute the checksum and verify that the message was not modified in transit.
To meet the increasing demand for information security, many vendors have designed and marketed cryptographic products. Though capabilities vary among these products, most of them provide a common set of cryptographic functions, including message encryption/decryption, message authentication/verification, and key management functions. Currently, two types of cryptosystems prevail: the secret-key cryptosystem and the public-key cryptosystem. Regardless of the technique used, each has some keying information to protect and manage, thus each needs a properly implemented key management system.
To protect the secret information such as users' secret keys from unwanted disclosure, cryptographic functions are frequently implemented in firmware or hardware and protected by tamper-proof casings. This component is frequently referred to as a cryptographic module (CM), which is a set of hardware, firmware or software, or some combination thereof, that implements cryptographic logic and/or processes [FIP94]. The cryptographic module may also be used to generate new keys and to encrypt keys for storage. The FIPS 140-1 [FIP94] details the security requirements for cryptographic modules. It is obvious that without proper protection to the cryptographic module, any security service provided by it is totally useless.
To use these security products, vendors normally provide executable programs that users can load into their host computers and execute. Frequently, high-level procedure calls are also provided to permit customized application programs in the host computer to interface with the CM and request security services through these cryptographic service calls. The cryptographic service calls may be referred to as the cryptographic application program interface (API) by some vendors. It is likely that different vendors may provide different cryptographic APIs for their products, since each product is designed and implemented differently. It is even possible that different cryptographic products from the same vendor may have different sets of APIs. It is felt that a standardized interface for basic cryptographic functions will be very beneficial for application programmers. If all the cryptographic modules manufactured in the future can support this standard cryptographic service interface, an application program written for a particular CM may well be ported to work with a different CM without any modification. The Security Technology Group of the Computer Security Division at NIST has been developing such a generic set of cryptographic service calls to be published as a FIPS guideline and proposed it for an IEEE POSIX security interface standard. The set of cryptographic service calls has sustained several reviews within and outside the Division, however, since it is still a draft document, future modification is possible.