Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. Further, Novell, Inc. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc. reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to notify any person or entity of such changes. This product may require export authorization from the U.S. Department of Commerce prior to exporting from the U.S. or Canada. U.S. Patent Nos. 4,555,775; 5,157,663; 5,349,642; 5,455,932; 5,553,139; 5,553,143; 5,594,863; 5,608,903; 5,633,931; 5,652,854; 5,671,414; 5,677,851; 5,692,129; 5,758,069; 5,758,344; 5,761,499; 5,781,724; 5,781,733; 5,784,560; 5,787,439; 5,818,936; 5,828,882; 5,832,275; 5,832,483; 5,832,487; 5,859,978; 5,870,739; 5,873,079; 5,878,415; 5,884,304; 5,893,118; 5,903,650; 5,905,860; 5,913,025; 5,915,253; 5,925,108; 5,933,503; 5,933,826; 5,946,467; 5,956,718; 5,974,474. U.S. and Foreign Patents Pending. Novell, Inc. 1800 South Novell Place Provo, Utah 84606 U.S.A. www.novell.com Novell Trademarks For a list of Novell trademarks, see the final appendix of this book. Third-Party Trademarks All third-party trademarks are the property of their respective owners. Contents 5 Contents Foreword 7 1 Introduction 9 1.1 Overview of FIPS 140-1 Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2 Cryptographic Channels 11 2.1 Data Input/Output Channel. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.2 Command/Status Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Security Requirements 13 3.1 Cryptographic Modules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2 Module Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 Roles and Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.1 User Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3.2 Crypto Officer Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4 Cryptographic Key Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1 FIPS Approved Key Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2 Key Distribution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3 Key Entry and Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.4.4 Key Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.5 Key Destruction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5 Self-Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5.1 Startup Self-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.5.2 Conditional Self Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4 Operating Modes 23 4.1 FIPS-Approved Algorithms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 A Appendix A -- CCS API Definitions 25 6 NICI 2.0 Client Security Policy for Windows 95/98 Foreword 7 Foreword This document describes the functionality of Novell® International Cryptographic Infrastructure (NICI) in compliance with requirements of the Federal Information Processing Standard (FIPS) 140-1 standard for cryptography. The cryptographic standards implemented within NICI will help ensure that cryptographic products developed according to FIPS standards will be interoperable industry-wide. 8 NICI 2.0 Client Security Policy for Windows 95/98 Introduction 9 1 Introduction Novell® International Cryptographic Infrastructure (NICI) consists of a set of modular components that have been implemented on a number of different platforms. Server-oriented versions have been implemented on Novell NetWare®, Microsoft* Windows* NT* 4.0, and Sun* Solaris* 2.6, with other hardware platforms and operating systems in process. Client-oriented versions have been implemented on Windows 95/98 and Windows NT to date. The present version of the NICI code supports:  DES (FIPS 46-3 and 81)  Triple-DES  SHA-1 (FIPS 180-1)  RSA (X9.31) Non-FIPS approved algorithms that also are supported include:  Diffie-Helman (PKCS#3)  RSA* encryption/decryption (PKCS#1)  MD2  MD4  MD5  HMAC-MD5  HMAC-SHA-1  RC2  RC4  RC5 10 NICI 2.0 Client Security Policy for Windows 95/98  CAST128  PKCS#12 Password Based Encryption (PBE)  UNIX* Crypt  LMdigest (CIFS)  TLS-KeyExchange-RSASign  NetWarePassword 1.1 Overview of FIPS 140-1 Categories The Novell NICI 2.0 Client Security Policy for Windows 95/98 conforms to FIPS 140-1 Level 1, as shown in the following table, with category levels tested for the NICI 2.0 Windows 95/98 Client. Table 1 FIPS 140-1 Test Category Levels FIPS140-1 Test Category Level Cryptographic Modules 1 Module Interfaces 1 Roles and Services 1 Finite State Machine Model 1 Physical Security 1 Software Security 1 Operating System Security 1 Key Management 1 Cryptographic Algorithms 1 EMI/EMC 1 Self Tests 1 Cryptographic Channels 11 2 Cryptographic Channels FIPS 140-1 defines a cryptographic boundary, and as well as channels though which information is allowed to enter and leave the cryptographic boundary. Defining such channels is normally straightforward for developers of hardware modules, but developers of software modules are faced with the task of choosing an appropriate set of channel definitions. 2.1 Data Input/Output Channel FIPS 140-1 requires the definition of Data Input/Output (I/O) and Command/ Status channel interfaces. NICI defines these interfaces through the Controlled Cryptographic Services API. The API provides the means to input and output data and to determine the status of the module. The Data Input/Output and the Status interface are active only during the User and Crypto Officer States. 2.2 Command/Status Channel The FIPS 140-1 Control interface is used to initiate the NICI Module. It is activated by the operating system when an application program asks the operating system to attach NICI and causes it to commence operation. It may also be activated when the operating system commands NICI to shut down. Otherwise, it is active only during the User and Crypto Officer States, if and when commands are issued via the API in the form of procedure calls. A selected API call initiates a specific action, which constitutes “control.” It should be noted that, under this definition of what constitutes a “channel,” such I/O ports that might be considered channels in other contexts are not FIPS 140-1 channels. 12 NICI 2.0 Client Security Policy for Windows 95/98 In particular, this applies to the internal I/O channel or bus, to any networking or other cards or boards with external interfaces, and to any internal cryptographic processors or accelerators that do not have their own independent I/O (external) ports. This would also apply to the case of a removable Smart Card or removable PCMCIA bus card, which would be considered inside of the cryptographic module boundary when it is in use. SecurityRequirements 13 3 Security Requirements 3.1 Cryptographic Modules NICI consists of a set of software modules designed to run on a wide variety of modern operating systems and hardware platforms. This particular Security Policy document pertains to the NICI configuration, running on a Windows* 95/98 platform, which is a VXD primer. In FIPS 140-1 terms, NICI consists of a set of hardware, software, and firmware that make up a “multi-chip standalone module.” The cryptographic boundary is effectively the outer cabinet that contains the computer, including the CPU processor(s), any and all storage media (hard disks, diskettes, etc.), any embedded cryptographic accelerators or smart cards, and any network ports or other forms of interfaces. Since NICI must be able to store at least one permanent key, the Key Storage Keys, in order to be able to securely wrap and unwrap other keys, that key is stored in an obfuscated form, along with a backup version. 3.2 Module Interfaces NICI meets the FIPS 140-1 Level 1 requirements for Roles and Services, including provision of one or more User roles and a Crypto-Operator role. In the case of a User, all functions are exercised through a common Application Programming Interface (API). The packaging of these systems may vary, depending on the operating systems’ platform characteristics. Access to the NICI functionality is provided by API calls from both C-language and Java* programs. 14 NICI 2.0 Client Security Policy for Windows 95/98 In the case of a Crypto Operator, some functions are exercised through the same API, but other functions—such as installing the system, installing the license materials, and zeroizing the permanent Key Storage Keys—are carried out by separate programs that only the Crypto Operator can exercise. 3.3 Roles and Services Novell NICI 2.0 is FIPS 140-1 Level 1 compliant for Roles and Services. The available services are documented in Appendix A, “Appendix A -- CCS API Definitions,” on page 25. 3.3.1 User Role A single User role is supported in NICI. A “User” is an application program, running as a single process (but perhaps multi-threaded), that has been linked with the Novell NICI interface library. After authentication to the User state, the User program is able to perform crypto operations via the API set defined in the Controlled Cryptography Services Software Development Specification (CCS) document. 3.3.2 Crypto Officer Role A single Crypto Officer role, the NICI Administrator, is supported in NICI. The purpose of the NICI Administrator is to set up, configure, and reconfigure the NICI software. In addition, the Crypto Officer can migrate or clone a given NICI server (or client) from one platform to another, even across operating systems and hardware platforms, and after the process has completed, zeroize the obfuscated Key Storage Keys of the original NICI instance if required. 3.4 Cryptographic Key Management NICI provides extensive cryptographic key management services and facilities, and is unique in addressing these requirements from a cross- platform, general-purpose networking perspective. Compatible key management is provided for all cryptographic modules, including client and server implementations, on all supported platforms and for all algorithms, including secret key (symmetric) and public key (asymmetric) algorithms. Secret keys and private key are protected from unauthorized disclosure, modification, and substitution. Public keys are protected against unauthorized modification and substitution. SecurityRequirements 15 The Cryptography Manager (XMGR) function within NICI is exclusively responsible for implementing all key management functions, enforcing key use policies, and providing algorithm management services to the XLIB and other XMGR layer. 3.4.1 FIPS Approved Key Generation The G function in the pseudo-random generator described in FIPS 186-2 is constructed using the SHA-1 hash function with b=512. See (http:// csrc.nist.gov/fips/fips186-2.pdf). The “mod q” operation was eliminated by choosing q > 2512 . The distributed seed material and installation time entropy is thoroughly mixed together using the FIPS-approved PRNG algorithm to create a cryptographic master seed, from which several unique working key generation seeds for each class of cryptographic keys are generated by NICI. Once the different working key generation seeds have been generated, individual keys and random numbers are themselves derived cryptographically using the same FIPS-approved key generation algorithm. 3.4.2 Key Distribution 3.4.2.1 NICI Wrapped Keys Wrapping of keys is the mechanism that NICI provides for applications to obtain the value of secret or private keys for storage outside of NICI or for distribution among different instances of NICI. Various keys are provided by NICI for wrapping other keys. The same key (or corresponding private key of the same key pair) must subsequently be used to unwrap a wrapped key in order for it to be reloaded into NICI. The key-management keys discussed below are all generated using algorithms from among the installed XENG modules, and with attributes conforming to the key usage policies that are in effect for key management. Those that are described below as being persistent are stored securely by NICI as an integral part of its infrastructure to persist across system shutdowns and restarts. 16 NICI 2.0 Client Security Policy for Windows 95/98 No means is provided for unauthorized applications to obtain any of the secret or private key-management keys (persistent or transient, wrapped or unwrapped) for storage or distribution outside of NICI. For purposes of distributing NICI’s internal key-management keys as a part of system initialization, interfaces, known as XINIT modules, for wrapping and unwrapping them are provided for use only by other portions of the operating system that are trusted to participate in the initialization of NICI and its environment. Key-wrapping keys may also be generated at the request of applications, which are then responsible for their secure storage (for example, by wrapping with any of the keys described in this section). 3.4.2.2 NICI Session Keys Session Keys A unique session key is shared between a NICI client workstation and each NICI server instance. Session keys are intended only for wrapping of keys for distribution between clients and servers or between two servers. Each session key generated by the server is a transient symmetric key. 3.4.2.3 Key Wrapping Attributes When a key is wrapped for storage or transmission outside of NICI, sensitive attributes such as secret or private key values are encrypted, and an integrity check value is used to protect the integrity of all attributes. Nonsensitive attributes can be stored in the clear outside NICI. (NICI public-key key- wrapping keys are stored or transmitted outside of NICI in X.509-compliant certificates for which NICI itself is the certification authority. These keys may not be used as server or end-user keys.) An integrity check value, which is calculated cryptographically based on a symmetric wrapping key, ensures both the integrity of the key (that the key’s attributes have not been accidentally or intentionally modified) and the authenticity of the key (that it originated in NICI and was not crafted outside of NICI). SecurityRequirements 17 However, keys that are wrapped using a public key cannot have their authenticity guaranteed without some additional mechanism that makes use of either a secret or private key whose value is not exposed outside of NICI. For example, a digital signature would serve this purpose. Such signatures are not required as part of the wrapping mechanism because that would excessively limit the flexibility and use of the key distribution mechanism in NICI, as well as the possible performance impact. Therefore, at the discretion of the application requesting the wrapping, the integrity check value on a wrapped key’s attributes may optionally be calculated using one of NICI’s internal secret key-management or private CA keys described above, independent of the wrapping key that the application uses to protect sensitive key attributes. If the private CA key is used, a digital signature is then used as the integrity check value in the wrapped key. If a secret key is used, the integrity check value is a form of message authentication code (MAC) and the secret key here is called a sealing key. In either case, any instance of NICI that possesses the same key-management key or corresponding CA public key can then depend on the integrity of the associated attributes when reloading the wrapped key. Otherwise, these attributes must be considered only advisory in nature. To maintain the integrity of NICI’s own protection mechanisms, keys whose authenticity is not assured by one of the mechanisms described here cannot be used to wrap other keys or to generate or verify NICI public-key certificates. 3.4.3 Key Entry and Output NICI does not possess a manual key entry method; all keys are entered electronically. Aside from the Crypto Operator’s role in distributing configuration data (used under the control of the Crypto Operator at installation time), all keys are entered under the User’s control via the API interface. There should seldom, if ever, be a requirement for a User to directly enter into or output from NICI a raw, plaintext private or secret key. There are two exceptions to this general rule. The first is for compatibility with other systems, where the human user has a personal cryptographic key and no way to securely store it except for a password-based encryption mechanism. The second is not really a key injection or extraction per se, but rather a protocol-dependent key distribution mechanism which NICI itself does not yet support directly, via a Cryptographic Library (XLIB). The integrity and the confidentiality of such are provided by the protocol. 18 NICI 2.0 Client Security Policy for Windows 95/98 3.4.3.1 Password-Based Encryption (PBE) Wrapped Keys Password-Based Encryption (PBE) is frequently required when interfacing with other, non-NICI systems such as browsers, S/MIME e-mail clients, and certain authentication methods. Since many of these applications are software-based, and since most of them run on non trusted platforms such as Windows 95/98, the only economically feasible way of protecting those keys is to use a Password-Based Encryption mechanism. NICI implements the PKCS #12 recommendation for password-based encryption and decryption. With this scheme, the key to be protected is encrypted in a randomly generated intermediate key of suitable strength (depending on export requirements and algorithm availability). The intermediate key is created by hashing an arbitrarily long password or passphrase entered by the user, and then truncating the key as required to meet the key management policy constraints. PKCS #12 builds into this scheme a deliberate slow-down mechanism that requires hashing and rehashing the password many, many times before decrypting the intermediate key. This is to provide some level of protection against an off-line password guessing attack. The time taken is small by human standards (a second or less) but the amount of computer time required to do an exhaustive search would be very large. 3.4.3.2 Key Injection and Extraction The NICI CCS API defines key injection and extraction functions, but their use is not recommended. 3.4.3.3 Protocol Support At the present time, protocol support for unwrapping keys that have been wrapped in a User’s private key has been provided for SSL, IPSEC, and IKE. 3.4.4 Key Storage When keys have been unwrapped within NICI (that is, within the confines of the NICI cryptographic module boundaries), they are kept in the clear (in plaintext form) in order to minimize the latency and overhead when using them. SecurityRequirements 19 3.4.4.1 Key Storage Keys As mentioned previously, the server’s Key Storage Keys are written to the operating system, which is protected against unauthorized access. However, because of the importance of this key, it is also thoroughly obfuscated, in a manner intended to require very considerable reverse engineering to break. Whenever a Key Storage Key is used to wrap another key for storage, the Key ID of that Key Storage Key is included in the wrapped key. In this manner, any previously generated, wrapped, and stored keys will be accessible, even if a new Key Storage Key is generated later. The KeyID contained in the wrapped key format also includes a unique ID to that particular machine and process, in order to help ensure that the correct Key Storage Key is being used to unwrap a particular key. At a minimum, this protects against the possibility that the wrapped key has been moved, migrated, or merged onto a new server, perhaps along with the data it protects, but somehow the correct Key Storage Key has been left behind. The integrity check in wrapped keys will catch this. If some form of compromise of the Key Storage Key file should occur, all previously generated and wrapped keys on that server would potentially be compromised as well. This is unavoidable in a software-based key management system. However, because of the entropy added at NICI installation time, the attacker would not gain access to the new keys, except by reattacking the Key Storage Key file. 3.4.5 Key Destruction When the particular NICI context associated with the usage of a set of keys is closed, all keys associated with that context within NICI are zeroized in memory. When NICI itself is closed within a given process, assuming it is closed gracefully and not by a system crash or power outage, all keys in all contexts are zeroized. The destruction of the current and all previous Key Storage Keys in the Key Storage Keys file should be an extremely rare event, since it would effectively make it impossible to recover any previously wrapped keys. The only time this would be likely to occur would be if a particular machine were to be decommissioned and taken out of service, presumably after all of the information had been migrated to another machine. 20 NICI 2.0 Client Security Policy for Windows 95/98 Since the ability to zeroize all keys might make possible a very serious Denial of Service attack, NICI does not provide a specific tool or function to cause this to occur. Instead, in this event it is the Crypto Operator’s responsibility to perform a complete low-level hardware formatting and reinitialization of the hard disk, thoroughly scrubbing the disk to make certain there is no readable residue. Various commercially available file scrubbing utilities can be used to perform this task. 3.5 Self-Test NICI conforms to the FIPS 140-1 Level 1 requirements for self-test. The required startup self-tests are performed every time the NICI is started by the operating system, prior to transitioning to the User state. If the self-tests do not run correctly, NICI will not start, and an error indication will be returned via the API if NICI is called. 3.5.1 Startup Self-Tests NICI satisfies the requirements for FIPS 140-1 Level 1 for Power-Up Self- Tests 3.5.1.1 Cryptographic Algorithms Test The SHA1 test runs the known answer tests described in Appendices A and B of FIPS Publication 180-1, Secure Hash Standard. See (http:// www.itl.nist.gov/fipspubs/fip180-1.htm) or (http://csrc.nist.gov/fips/fips180- 1.pdf). DES and triple DES run the known answer tests described in NIST Special Publication 800-20, Table A.4, rounds 0 through 18. Both DES and Triple DES are operating in CBC mode with only an eight-byte IV. In the case of triple DES, the key in Table A.4 is repeated three times so as to test Encrypt- Decrypt-Encrypt with the same key in each stage. Similar procedures are in effect for RSA (X9.31). 3.5.1.2 Critical Functions Test The nature and design of NICI precludes successful completion of the cryptographic algorithm tests and the Software/Firmware tests without all critical functions operating properly. Successful completion of these tests is sufficient to indicate that all critical functions are operating properly. SecurityRequirements 21 3.5.2 Conditional Self Tests The following tests are performed as specified for each test. 3.5.2.1 Pair-Wise Consistency Tests for Public/Private Key Pairs When a public/private key pair is generated, the key pair is tested for pair-wise consistency. The public key is used to encrypt a plaintext value and checked to ensure that an identity mapping did not occur, and then the private key is used to decrypt that value and the value compared to the original. If the values are not identical, the test fails. If the keys are to be used only for the calculation of a signature, then the consistency is tested by the calculation and verification of a signature. These tests are applied to RSA keys. 3.5.2.2 Software/Firmware Load Tests At present, the NICI module is a self-contained unit (a device driver, VXD), and no other modules are loaded by NICI. Therefore, these tests are not applicable to NICI. 3.5.2.3 Continuous Random Number Test The continuous random number generator tests specified in FIPS PUB 140-1. Security Requirements for Cryptographic Modules, Section 4.11.2 (see (http:/ /www.itl.nist.gov/fipspubs/fip140-1.htm) or (http://csrc.nist.gov/fips/fip140- 1.pdf)) will be applied to the operating specific random entropy generator routines prior to their being used to generate a cryptographic key, seed, or cryptographic random number. They will be applied independently, both before and after any cryptographic processing to add entropy or whitening. This will test both the entropy generator and the results of the key generation function. 22 NICI 2.0 Client Security Policy for Windows 95/98 OperatingModes 23 4 Operating Modes 4.1 FIPS-Approved Algorithms It is the application programmer’s responsibility to only use FIPS approved algorithms if FIPS 140-1 Mode is required. See (http://www.itl.nist.gov/ fipspubs/fip140-1.htm). The CMVP supports a Web site that lists the current approved FIPS algorithms (http://csrc.nist.gov/cryptval). 24 NICI 2.0 Client Security Policy for Windows 95/98 Appendix A -- CCS API Definitions 25 A Appendix A -- CCS API Definitions For complete descriptions, please refer to the Controlled Cryptography Services Software Development Specifications document available from Novell. API Description CCS_Init Initializes the CCS library CCS_Shutdown Closes the CCS library CCS_GetInfo Return information about the CCS interface CCS_GetPolicyInfo Determines the policy constraints on key attributes for a given key type and usage CCS_GetKMStrength Returns the key management strength level CCS_GetRandom Returns a random number CCS_GetAlgorithmInfo Obtain information about a specific algorithm. CCS_GetAlgorithmList Obtain information about the algorithms available in the system. CCS_GetMoreAlgorithmInfo Obtain variable-length information about an algorithm. CCS_CreateContext Create a cryptography context. CCS_DestroyContext Destroy a cryptography context. 26 NICI 2.0 Client Security Policy for Windows 95/98 CCS_DestroyObject Destroy a CCS object. CCS_FindObjectsInit Initialize a search for objects that match a template. CCS_FindObjects Continue a search for objects that match a template. CCS_GetAttributeValue Obtain the value of one or more object attributes. CCS_SetAttributeValue Modify the values of one or more object attributes. CCS_DataEncryptInit Initialize a data encryption operation. CCS_Encrypt Encrypt single-part data. CCS_EncryptUpdate Continue a multi-part encryption operation. CCS_EncryptFinal Finish a multi-part encryption operation. CCS_EncryptRestart Reinitialize an encryption operation. CCS_DataDecryptInit Initialize a data decryption operation. CCS_Decrypt Decrypt encrypted data in a single part. CCS_DecryptUpdate Continue a multi-part decryption operation. CCS_DecryptFinal Finish a multi-part decryption operation. CCS_DecryptRestart Reinitialize a decryption operation. CCS_Obfuscate Obfuscates an input string. CCS_DeObfuscate De-obfuscates an input string. CCS_pbeEncrypt Encrypt data in a single part using a password and password-based algorithm as described in PKCS#5 or PKCS#12. API Description Appendix A -- CCS API Definitions 27 CCS_pbeDecrypt Decrypt data in a single part using a password and password-based algorithm as described in PKCS#5 or PKCS#12. CCS_pbeSign Generate signature for input data in a single part using a password and password-based algorithm as described in PKCS#12. CCS_pbeVerify Verify input data and its signature in a single part using a password and password-based algorithm as described in PKCS#12. CCS_pbeShroudPrivateKey Encrypt a PKCS#8 private key using a password and password-based algorithm as described in PKCS#5 or PKCS#12. CCS_pbeUnshroudPrivateKey Decrypt and load an encrypted PKCS#8 private key using the password and the password-based algorithm as described in PKCS#5 or PKCS#12. CCS_LoadPFXPrivateKeyWithPassword Loads zero or more private keys encrypted in a password from a PKCS#12 PFX structure. See PKCS#12 document for details. Only PKCS#8 private keys are supported. CCS_LoadPFXCertificateWithPassword Loads zero or more X.509 certificates and public keys in those certificates from a PKCS#12 PFX structure. The certificates either can be encrypted in a safe bag or can be in plain form. See PKCS#12 and RFC 2459 documents for details. CCS_DigestInit Initialize a message-digesting operation. CCS_Digest Digest data in a single part. API Description 28 NICI 2.0 Client Security Policy for Windows 95/98 CCS_DigestUpdate Continue a multi-part message- digesting operation. CCS_DigestFinal Finish a multi-part message-digesting operation. CCS_DigestRestart Reinitialize a message-digesting operation. CCS_SignInit Initialize a signature operation. CCS_Sign Sign data in a single part. CCS_SignUpdate Continue a multi-part signature operation. CCS_SignFinal Finish a multi-part signature operation. CCS_SignRestart Reinitialize a signature operation. CCS_SignRecoverInit Initialize a signature operation with data recovery. CCS_SignRecover Sign data in a single part, with data recovery. CCS_SignRecoverRestart Reinitialize a signature operation with data recovery. CCS_VerifyInit Initialize a verification operation. CCS_Verify Verify data in a single part. CCS_VerifyUpdate Continue a multi-part verification operation. CCS_VerifyFinal Finish a multi-part verification operation. CCS_VerifyRestart Reinitialize a verification operation. CCS_VerifyRecoverInit Initialize a signature verification operation with data recovery. CCS_VerifyRecover Verify a signature on data in a single part, with data recovery. API Description Appendix A -- CCS API Definitions 29 CCS_VerifyRecoverRestart Reinitialize a verification operation with data recovery. IKE_Sign Sign using an IKE Authentication Phase 1 authentication algorithm. The algorithms and mechanisms are described in RFC 2409: The Internet Key Exchange. IKE_Verify Verify using an IKE Authentication Phase 1 authentication algorithm. The algorithms and mechanisms are described in RFC 2409: The Internet Key Exchange. CCS_GenerateKey Generate a secret key. CCS_GenerateKeyPair Generate a public-key/private-key pair. CCS_WrapKey Wrap (i.e. encrypt) a key for storage or distribution external to CCS. CCS_UnwrapKey Unwrap (i.e. decrypt) a key. CCS_InjectKey This is the raw (i.e., plaintext) key injection function that is used for legacy applications with raw key access, and required to use NICI with their existing raw keys. CCS_ExtractKey Extract attributes of a key, including its value (NICI_A_KEY_VALUE) attribute. CCS_LoadCertificate Load a public-key certificate, verify its signature and load the resulting public key. CCS_LoadSelfSignedCertificate Load a self-signed public-key certificate, verify its signature and load the resulting public key. CCS_LoadUnverifiedCertificate Load a public-key certificate and the resulting public key without verifying the certificate signature. API Description 30 NICI 2.0 Client Security Policy for Windows 95/98 CCS_GenerateCertificate Create and sign a public-key certificate. CCS_GenerateCertificateFromRequest Create and sign a public-key certificate whose public key is provided by a PKCS #10 Certification Request. CCS_GetLocalCertificate Return a public-key certificate or local portion of the certification path for one of the NICI-predefined public keys. CCS_GetCertificate Return a public-key certificate or complete certification path for one of the NICI-predefined public keys. CCS_GenerateKeyExchangeParameters This is the parameter generation stage of a key agreement algorithm. CCS_KeyExchangePhase1 This is the phase 1 of a key exchange algorithm. CCS_KeyExchangePhase2 This is the phase 2 of a key exchange algorithm. API Description