EFJohnson Encryption Module (Software Version 1.0.0.5) FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Version 0.13 December, 2004 © Copyright 2004 EFJohnson, Inc. This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Table of Contents INTRODUCTION......................................................................................................................... 3 PURPOSE ....................................................................................................................................... 3 REFERENCES ................................................................................................................................. 3 DOCUMENT ORGANIZATION ......................................................................................................... 3 EFJOHNSON ENCRYPTION MODULE ................................................................................. 4 OVERVIEW .................................................................................................................................... 4 MODULE INTERFACES ................................................................................................................... 5 ROLES AND SERVICES ................................................................................................................... 6 RKP User Role ......................................................................................................................... 7 Crypto Officer Role .................................................................................................................. 7 User Role.................................................................................................................................. 8 Authentication Mechanisms ................................................................................................... 10 PHYSICAL SECURITY .................................................................................................................. 10 CRYPTOGRAPHIC KEY MANAGEMENT ........................................................................................ 10 Key generation ....................................................................................................................... 12 Key storage............................................................................................................................. 12 Key entry and output .............................................................................................................. 12 Key zerorization ..................................................................................................................... 12 SELF-TESTS ................................................................................................................................ 12 DESIGN ASSURANCE ................................................................................................................... 13 MITIGATION OF OTHER ATTACKS ............................................................................................... 13 SECURE OPERATION ............................................................................................................. 14 INITIAL SETUP ............................................................................................................................ 14 CRYPTO OFFICER GUIDANCE ...................................................................................................... 14 USER GUIDANCE......................................................................................................................... 15 ACRONYMS ............................................................................................................................... 16 © Copyright 2004 EFJohnson, Inc. Page 2 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Introduction Purpose This is a non-proprietary Cryptographic Module Security Policy for the EFJohnson Encryption Module from EFJohnson, Inc. This security policy describes how the EFJohnson Encryption Module meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 -- Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/cryptval/. The EFJohnson Encryption Module is referred to in this document as the Encryption Module, the EM, or the module. References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: · The EFJohnson, Inc. website (http://www.efjohnson.com) contains information on the full line of products from EFJohnson. · The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: Vendor Evidence document Finite State Machine Other supporting documentation as additional references With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to EFJohnson, Inc. and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact EFJohnson. © Copyright 2004 EFJohnson, Inc. Page 3 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. EFJOHNSON ENCRYPTION MODULE Overview The EFJohnson Encryption Module is a software cryptographic module that serves both as a key store and a cryptographic service provider for integration into an OTAR system as specified in the TIA/EIA Telecommunications Systems Bulletin, APCO Project 25, Over-The-Air-Rekeying (OTAR) Protocol, New Technology Standards Project, Digital Radio Technical Standards, TSB102.AACA, January, 1996, Telecommunications Industry Association and a 3DES/AES OTAR system as specified in ANSI/TIA-102.AACA-1-2002 titled, Project 25- Digital Radio Over-the-Air-Rekeying (OTAR) Protocol Addendum 1 ­ Key Management Security Requirements for Type 3 Block Encryption Algorithms. The module is accessible through an intuitive API, and provides an easy-to-use yet secure means of storing sensitive cryptographic keys. The Encryption Module meets level 1 FIPS 140-2 requirements and achieves level 2 in the "Roles, Services, and Authentication" and "Operation Environment" sections of FIPS 140-2. The following table details the level met in each individual FIPS 140-2 section. Table 1 - Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 2 4 Finite State Model 1 5 Physical Security N/A 6 Operational Environment 2 7 Cryptographic Key Management 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A The Encryption Module is composed of two binaries, the Cryptography and Key Storage Module (CKSM) and the Root Key Provider (RKP) service. The CKSM is a dynamic link library (CCEFFIPS.DLL) that serves as an interface into the module and provides cryptographic services, and the RKP service is an executable file (EFJRKP.EXE) that authorizes operators of the module. In FIPS 140-2 terminology, the EFJohnson Encryption Module is defined as a multi-chip standalone cryptographic module. The module is capable of running on any standard Personal Computer (PC) supported by Windows 2000, and, for the purposes of the FIPS 140-2 validation, it was tested on the Common Criteria (CC) certified EAL 4 augmented Microsoft Windows 2000 compliant with Controlled Access Protection Profile (CAPP) running on Dell OptiPlex GX400. The Windows 2000 CC evaluation report can be found at http://niap.nist.gov/cc- scheme/st/ST_VID4002.html. The Controlled Access Protection Profile (CAPP) © Copyright 2004 EFJohnson, Inc. Page 4 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. to which Windows 2000 conforms to can be found at http://niap.nist.gov/cc- scheme/pp/PP_CAPP_V1.d.pdf. The physical cryptographic boundary of the Encryption Module is the case of the PC, which completely encloses the module's components. The following diagram Cryptographic Boundary RKP User's Guide RK Install DSA Location Integrity Test Integrity Test API (Logical Root Key Service IPC Cryptography and Interface) Provider Key Storage Module EFJCSP RO (EFJRKP.EXE) (CCEFFIPS.DLL) RO R/W Keys R/W Users User Store SKEK MAC File SK Validates Validates Figure 1 - Cryptographic Boundary specifies the logical cryptographic boundary. Module Interfaces The Encryption Module runs on any of the hardware platforms utilized in the Windows 2000 CC certification. These evaluated configurations include the following hardware. · Compaq Proliant ML570 · Compaq Proliant ML330 (both 2-processor and 4-processor version) · Compaq Professional Workstation AP550 · Dell Optiplex GX400 · Dell PE 2500 · Dell PE 6450 © Copyright 2004 EFJohnson, Inc. Page 5 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · Dell PE 2550 · Dell PE 1550 The Encryption Module's physical ports are composed of the physical ports provided by the hardware platforms listed above. These standard PC ports include the monitor, keyboard, mouse, serial ports, parallel ports, USB ports, floppy disk drive, CD-ROM drive, and network ports. The Encryption Module's logical interface is the API calls of the CKSM, which provide the only means of accessing the module's services. Data inputs are certain function calls, including specific arguments to a function. These specific arguments are pointers to input data. Control inputs are also certain function calls, including specific arguments. However, these arguments control how the function is executed. Operational state of RKP service also acts as a Control Input for the module. The result of a function is data output. Some functions include an argument that specifies where the result (data output) should be stored. The return values of the functions are status outputs. The logical interfaces and their module and physical interface mappings are described in the following table. Table 2 - FIPS 140-2 Logical, Physical, and Module Interface Mapping PC Physical Port Module Interface FIPS 140-2 Logical Interface Keyboard, mouse, CD-ROM, floppy Function calls that accept, as their Data Input Interface disk, and arguments, data to be used or processed serial/USB/parallel/network ports by the module Hard Disk, monitor, and Arguments for a function that specify Data Output Interface serial/USB/parallel/network ports where the result of a function is stored Keyboard, CD-ROM, floppy disk, Function calls utilized to initiate the Control Input Interface mouse, and module and the function calls used to serial/USB/parallel/network port control the operation of the module Hard Disk, monitor, and Return values Status Output Interface serial/USB/parallel/network ports Power Interface Not Applicable PC Power Interface Roles and Services The module supports role-based authentication and contains three roles: RKP User role, Crypto Officer role, and User role. The Users, Crypto Officers, and the RKP User are all defined by accounts on the Windows 2000 Operating System, and these accounts then have permission mapped into the module (by the Crypto- Officer). Operators authenticate to the CC certified Windows 2000 Operating System using a username and password, and the Encryption Module provides authorization to the operators upon loading of the CKSM. The module supports multiple concurrent operators. © Copyright 2004 EFJohnson, Inc. Page 6 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. RKP User Role The RKP User is only used interactively (physical operator) to install the Encryption Module on the system. During installation, the RKP User creates an empty key store and establishes an initial Crypto-Officer. After installation completes, this role is no longer used by a physical operator. Since the RKP User is a member of the Windows Administrator group, all Windows Administrators can start or stop the RKP service. RsaCcefBootKeyStore function should not be executed upon an installed module. This is because, if this function is executed on an installed module, a new empty key store and a user store with one user will be created thus deleting all the previous keys and users. Table 3 - RKP User Services Functions Service Input Output Accessed CSPs Permission RsaCcefBootKeyStore Creates a new empty key MAC Key Status output Root Key, BootMAC Read/Write store and a user store with information, CO Key a single user, the initial user information CO from the installation program during initial system installation and configuration. Crypto Officer Role The Crypto Officer role has the responsibility of managing both the Key Store and the User Store. Managing the Stores comprises the ability to add or delete an individual key to or from the Key Store and delete all keys from the Key Store. The Crypto Officer is able to access all the system management functions as well as all the cryptographic functionalities of the module. The services available only to the Crypto Officer are provided in Table 4. Table 4 - Crypto Officer Services Functions Service Input Output Accessed CSPs Permission RsaCcefAddUser Adds a single file to the CKSM session Status output SKEK File MAC Read User Store. The file's handle, CO user Key name is derived from information the new user's (CO or End User) name, and their permissions. RsaCcefModifyUser Modifies the CKSM session Status output SKEK File MAC Read permissions of a CO or handle, user Key regular user in the user information store. RsaCcefDeleteUser Removes a CO or an CKSM session Status output -- End User from the handle, user name EFJEM User Store. (CO or End User) RsaCcefGenerateNewSkek Generates a new SKEK CKSM session Status output SKEK KEKs, SKEK Read/Write and either installs it into handle, new SKEK KeyInfo MAC Key, the EFJEM or returns it information SKEK File MAC to the caller. Key © Copyright 2004 EFJohnson, Inc. Page 7 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Functions Service Input Output Accessed CSPs Permission RsaCcefInstallNewSkek Installs a previously CKSM session Status output SKEK KEKs, SKEK Read/Write generated SKEK into handle, SKEK KeyInfo MAC Key, the EFJEM. information SKEK File MAC Key RsaCcefDeleteSkek Deletes a SKEK file CKSM session Status output SKEK KEKs, SKEK Delete from the disk. handle, current KeyInfo MAC Key, SKEK number SKEK File MAC Key RsaCcefDeleteKeyFile Deletes TEMP keys CKSM session Status output Root Key, SKEK Delete file, PERM keys file, handle, bit-field KEKs, SKEK current SKEK file, the flag parameter KeyInfo MAC Key, Root Key, or any SKEK File MAC combination of these. Key, KS Keys RsaCcefEscrowKeyStore Escrows all of the keys CKSM session Status output SKEK KEKs, SKEK Read in the PERM keys file handle, key handle KeyInfo MAC Key, to a key escrow SKEK File MAC structure. Key, KS Keys RsaCcefRestoreKeyStore Restores escrowed keys CKSM session Status output a) SKEK KEKs, a)Read to a PERM keys file. handle, key handle SKEK KeyInfo MAC b)Write Key, SKEK File MAC Key b)KS Keys User Role Users are allowed only to use the module to perform cryptographic functions. The Encryption module authenticates the Users using Windows 2000 SID and password. Users may use a key from the Key Store or a key that exists in memory to perform cryptographic functions. All the services provided for Users, are also available to Crypto Officers. Service descriptions and inputs/outputs available for Users are listed in the following table: Table 5 - User Services Functions Services Input Output Accessed CSPs Permission RsaCcefOpenFipsLibrary Initialize an EFJEM CKSM session Status output Root Key, SKEK Read session. handle KEKs, SKEK KeyInfo MAC Key, SKEK File MAC Key RsaCcefCloseFipsLibrary Uninitialize the EFJEM CKSM session Status output -- session. handle RsaCcefCreateKeyHandleGen Generate a new key CKSM session Status output a) KS key a) Read erate handle handle, key info, key b) SKEK KEKs, b) Write handle. SKEK KeyInfo MAC Key, SKEK File MAC Key © Copyright 2004 EFJohnson, Inc. Page 8 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Functions Services Input Output Accessed CSPs Permission RsaCcefCreateKeyHandleFro Create a key handle CKSM session Status output a) KS key a)Read/Write mInfo from key data handle, key info, key b) SKEK KEKs, b) Read handle. SKEK KeyInfo MAC Key, SKEK File MAC Key RsaCcefWrapKey Wrap a key CKSM session Status output a) KS key a)Read/Write handle, key info, two b) SKEK KEKs, b) Read key handles SKEK KeyInfo MAC Key, SKEK File MAC Key RsaCcefDestroyKeyHandle Destroy a key handle CKSM session Status output -- handle, key handle RsaCcefCreateBlockCipherM Create a MAC using CKSM session MAC, status KS Key Read ac block cipher handle, key handle, output data to MAC RsaCcefAddSeed Add seed CKSM session Seed, status handle, seed value output length E_SKEY_new Create a key object CKSM session Key object, a) KS key a)Read/Write handle, key status output b) SKEK KEKs, b) Read information SKEK KeyInfo MAC Key, SKEK File MAC Key E_SKEY_free Destroy a key object Key object Status output KS Key Delete E_SKEY_set_info Set key data to a key Key object, key Status output KS Key Write object object ID, key data E_SKEY_get_info Retrieve key data from Key object, key Key data, KS Key Read a key object. object ID status output E_CR_new Create a crypto object CKSM session key, Crypto object, -- algorithm ID, status output algorithm type E_CR_free Destroy a crypto object Crypto object Status output -- E_CR_set_info Add information to a Crypto object, object Status output KS Key Read cryptographic object ID, object information E_CR_encrypt_init Initialize a crypto Crypto object, key Status output KS Key Read object for encryption object, IV E_CR_encrypt_update Encrypt bulk input data Crypto object, data, Cipher, cipher KS Key Read data length length, status output E_CR_encrypt_final Finish the encryption Crypto object Cipher, cipher KS Key Read process length, status output E_CR_encrypt Encrypt the input data Crypto object, data, Cipher, cipher KS Key Read data length length, status output E_CR_decrypt_init Initialize a crypto Crypto object, key Status output KS Key Read object for decryption object, IV © Copyright 2004 EFJohnson, Inc. Page 9 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Functions Services Input Output Accessed CSPs Permission E_CR_decrypt_update Decrypts bulk input Crypto object, data, Plaintext, KS Key Read data data length plaintext length, status output E_CR_decrypt_final Finish the decryption Crypto object Plaintext, KS Key Read process plaintext length, status output E_CR_decrypt Decrypt the input data Crypto object, data, Plaintext, KS Key Read data length plaintext length, status output Authentication Mechanisms The module depends upon the Windows 2000 OS to provide a username and password based authentication mechanism. Each valid username has an associated role, and the username can only be used to gain access to the module with the associated password. The implementation is the one that is used by the CC EAL 4 certified Windows 2000 Operating system of the module. The minimum length of the password is 8 and the module requires the password to be alpha numeric. Also, the complexity requirement for password is it cannot be all numeric or all alphabets (26 lowercase and 26 uppercase letters). Assuming at least 90 characters with repetition, the chance of a random attempt falsely succeeding is 1 in 4,251,212,271,468,544. Physical Security EFJohnson Encryption Module is a software cryptographic module running on the Common Criteria (CC) certified Windows 2000 operating system, and the module's software is entirely encapsulated by the cryptographic boundary shown in Figure 1. The physical cryptographic boundary is the case of the PC. While purely a software module, the FIPS 140-2 evaluated platform must be a standard PC that has been tested for and meets applicable FCC EMI and EMC requirements for business use as defined by 47 Code of Federal Regulations, Part15, Subpart B. Cryptographic Key Management The Encryption Module contains numerous functions for performing cryptographic operations. RNGs, MAC functions, and symmetric algorithms use keys and/or CSPs to perform their respective operations. The module implements the following FIPS-approved algorithms (all statically linked from the FIPS validated RSA Crypto-C ME library version 1.7.2): © Copyright 2004 EFJohnson, Inc. Page 10 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. · AES (FIPS 197)­ ECB, CBC, CFB (128 bits), and OFB modes; 128/256 bit key sizes (certificate #26) · Triple DES (FIPS 46-3) - ECB, CBC, CFB (64 bits), and OFB modes; 1 keying option (certificate #135) · DES (FIPS 46-3 ­ for legacy use only) - ECB, CBC, CFB (64 bits), and OFB modes (certificate #186) · SHA-1 (FIPS 180-2) (certificate #121) · DSA (FIPS 186-2) (certificate #72) · FIPS 186-2 Deterministic RNG (FIPS 186-2 Appendix 3.1 Change Notice 1 with G function built from SHA-1) (certificate #14) The module implements the following non-FIPS-approved algorithms which must not be used while in a FIPS mode: · AES-MAC (Certification #26, P25 AES OTAR, vendor affirmed) The module supports the following critical security parameters: Table 6 - List of CSPs for the Encryption Module Key Key type Generation Storage Use Root Key 256-bit AES Internally generated during In non-volatile memory Encrypts the SKEK key installation using the FIPS 186-2 (hard drive ­ Windows RNG registry) plaintext BootMAC key 256-bit AES Internally generated during In non-volatile memory MACs the initial CO user key installation using the FIPS 186-2 (hard drive) encrypted by file. RNG the RK TDES SKEK KEK 192-bit key Internally generated by the FIPS In SKEK folder in non- Encrypts Key Store Keys 186-2 RNG , or externally volatile memory (hard generated and loaded into the drive) encrypted by the module RK AES SKEK KEK 256-bit key Internally generated by the FIPS In SKEK folder in non- Encrypts Key Store Keys. 186-2 RNG , or externally volatile memory (hard generated and loaded into the drive) encrypted by the module RK AES SKEK 256-bit key Internally generated by the FIPS In SKEK folder in non- MACs Key Store keys KeyInfo MAC key 186-2 RNG , or externally volatile memory (hard generated and loaded into the drive) encrypted by the module RK AES SKEK File 256-bit key Internally generated by the FIPS In SKEK folder in non- MACs Key Store files MAC key 186-2 RNG , or externally volatile memory (hard generated and loaded into the drive) encrypted by the module RK User password Windows Entered electronically Windows registry in Authenticate users to 2000 SID plaintext Windows OS password Key Store Keys DES, TDES, Internally generated by the FIPS In Key Store folder in Encrypts data or other AES-128, or 186-2 RNG , or externally non-volatile memory keys AES-256 generated and loaded into the (hard drive) encrypted by keys module SKEK EFJRKP Service DSA Public Externally generated by RSA Encrypted in hard drive Used to verify the Module Key Key size 512 and installed with the module and plaintext in volatile integrity of EFJRKP.EXE memory Key Storage DSA Public Externally generated by RSA Encrypted in hard drive Used to verify the © Copyright 2004 EFJohnson, Inc. Page 11 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. Service Module Keys size 512 and installed with the module and plaintext in volatile integrity of Key memory CCEFFIPS.DLL AES Decrypt Key AES-128 key Hard coded created on-site at Plaintext in hard drive Decrypts EFJRKP and RSA Key Storage Service Module Keys (DSA Public Keys) Key generation Root key and BootMAC key are generated during installation of the module. The symmetric keys placed in the module's key store are either generated internally by the module or imported into the module through its API. These symmetric keys can be imported into the module either in plaintext or encrypted form. DSA public keys are generated externally by the manufacturer and are installed with the module. AES Decrypt Key's raw data is hard coded in the module. Key storage The Root Key is stored in plaintext in the Windows Registry on the module's hard drive. The EFJRKP Service Module Key (public key) and Key Storage Service Module Key (public key) are stored encrypted on the module's hard drive and plaintext in the volatile memory. All other CSPs, other than User password and AES Decrypt Key, reside encrypted on the module's hard drive. AES Decrypt Key is stored in plaintext on hard drive. Key entry and output All symmetric keys are entered into or output from the module electronically. The symmetric keys can either be encrypted or in plaintext while crossing the cryptographic boundary through the API functions. Password is entered into the module electronically in plaintext. The Root Key and BootMAC Key generated by the configuration file, they do not exit the module. DSA Public Keys and AES Decrypt Key are hard coded and the module does not output them outside the module. Key zerorization The Crypto Officer is able to zerorize all the keys (Root Key, BootMAC Key, Symmetric keys) with RsaCcefDeleteSkek or RsaCcefDeleteKeyFile functions. Deletion of the Root Key will include a zerorization of the Root Key registry key (Win32 registry APIs is used), and deletion of this key will disable the module. When the context of a symmetric crypto object is no longer needed, a free function is called to free the context and to zerorize any key-sensitive material in the context. Hard-coded keys are zeroized when the module is deleted from the system. Self-Tests The Encryption Module runs power-up and conditional self-tests to verify that it is functioning properly. Power-up self-tests are performed during startup of the © Copyright 2004 EFJohnson, Inc. Page 12 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. module, and conditional self-tests are executed whenever specific conditions are met. The module implements the following Power-up self-tests: Software Integrity Test: The module employs a software integrity test in the form of DSA signature verification with SHA-1. Cryptographic Algorithm Tests: Known Answer Tests (KATs) are run at power-up for the following algorithms: · AES 128 KAT (ECB) · Triple-DES KAT (CBC) · DES KAT (CBC) · SHA-1 KAT · DSA sign/verify test at power up · PRNG KAT The module implements the following Conditional self-tests: · Continuous random number generator test If any of these self-tests fail, the module will output an error indicator and enter an error state. Design Assurance All the source code and associated documentation files are managed and recorded using the Concurrent Versions System (CVS). Additionally, Microsoft Visual Source Safe (VSS) version 6.0 was used to provide configuration management for the module's FIPS documentation. The VSS Administrator established a "/EFJEM" project in VSS and assigned read/write permissions to the engineers working on the project Mitigation of Other Attacks The Encryption Module does not employ security mechanisms to mitigate specific attacks. © Copyright 2004 EFJohnson, Inc. Page 13 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. SECURE OPERATION The EFJohnson Encryption Module meets overall Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS- approved mode of operation. Initial Setup The software module will be provided either preinstalled or on physical media by EFJohnson Company for exclusive use in their products. Before installing EFJohnson Encryption Module, the operator needs to ensure that the system runs EAL 4 augmented CC certificated Microsoft Windows 2000 Professional with Service Pack 3 operating system compliant with the Controlled Access Protection Profile. The module is also compatible to Windows XP Professional SP1, however they are not part of the validated configuration. The system must be installed, configured, and started before operators may utilize its features. The Encryption Module system installation must be performed by a properly privileged user (a Windows Administrator), who is deemed the RKP User. Additionally, to maintain the FIPS mode of operation, the operator of the module can only execute FIPS approved services. The AES MAC service cannot be used while in a FIPS approved mode. Crypto Officer Guidance Only Crypto officer can add another Crypto Officer or User to the CKSM User Group using RsaCcefAddUser function. The function has the following signature: int RsaCcefAddUser ( RsaCcefLibCtx libCtx, RsaCcefUserInfo *info ); The permissions field of the RsaCcefUserInfo structure is a bit field. The CO must create this argument by OR'ing together one or more of the permission flags, which outline what the user will be allowed to do. The following are the permission flags. RSA_CCEF_PERMISSION_DATA_ENCRYPTION RSA_CCEF_PERMISSION_DATA_DECRYPTION RSA_CCEF_PERMISSION_KEY_ENCRYPTION RSA_CCEF_PERMISSION_KEY_DECRYPTION © Copyright 2004 EFJohnson, Inc. Page 14 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. RSA_CCEF_PERMISSION_ADD_KEK RSA_CCEF_PERMISSION_DELETE_KEK RSA_CCEF_PERMISSION_ADD_TKEK RSA_CCEF_PERMISSION_DELETE_TKEK RSA_CCEF_PERMISSION_IMPORT_SKEK RSA_CCEF_PERMISSION_EXPORT_SKEK RSA_CCEF_PERMISSION_RESET_SKEK RSA_CCEF_PERMISSION_RESET_SIG_KEY RSA_CCEF_PERMISSION_RESET_ENC_KEY RSA_CCEF_PERMISSION_SECURITY_MANAGER The new user will be a CO if and only if the RSA_CCEF_PERMISSION_SECURITY_MANAGER flag is set. The Crypto Officer should be very careful to set the permission flags while creating a new User account. The User guidance described below also applies to the Crypto Officer. User Guidance Two functions are used by all Crypto Officers and regular Users to establish a session with the CKSM and to end that session, RsaCcefOpenFipsLibrary and RsaCcefCloseFipsLibrary. RsaCcefCloseFipsLibrary function must be called once for each call to RsaCcefOpenFipsLibrary. This function finalizes the CKSM session. Allocated memory associated with the library context is freed. The RKP server is contacted to manage the count of active CKSM sessions. Users may allocate different cryptographic object during the session. It is Users responsibility to destroy the objects, freeing up the memory before closing the session. © Copyright 2004 EFJohnson, Inc. Page 15 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice. ACRONYMS AES Advanced Encryption Standard API Application Programming Interface CAPP Controlled Access PP CC Common Criteria CKSM Cryptography and Key Storage Module CMVP Cryptographic Module Validation Program CO Crypto Officer CSP Critical Security Parameter DES Data Encryption Standard DSA Digital Signature Algorithm EAL Evaluation Assurance Level EM Encryption Module EFJEM EFJohnson Encryption Module EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communication Commission FIPS Federal Information Processing Standard KAT Known Answer Test KS Key Store MAC Message Authentication Code NIST National Institute of Standards and Technology OS Operating System PC Personal Computer PERM Permanent Key PP Protection Profile RKP Root Key Provider RNG Random Number Generator RSA Rivest Shamir and Adleman SHA Secure Hash Algorithm SKEK Storage Key Encrypting Key TEMP Temporary Key USB Universal Serial Bus © Copyright 2004 EFJohnson, Inc. Page 16 of 16 This document may be freely reproduced and distributed whole and intact including this Copyright Notice.