TITLE: Luna Token Security Policies ABSTRACT: This document describes the security policies implemented by the Luna Token and how the design of its firmware and hardware enforces these policies. DOCUMENT NUMBER: CR-1356 ORIGINATOR: Terry Fletcher DEPARTMENT: Systems Engineering LOCATION OF ISSUE: Ottawa DATE ORIGINATED: October 29, 2001 CHANGE LEVEL: 4 CHANGE DATE: September 27, 2002 SECURITY LEVEL: None SUPERSESSION DATA: Document Number Change Level Security Level Page Number CR-1356 4 None Š Copyright 1997-2001 Chrysalis-ITS, Inc. All rights reserved. Communications Security Establishment (CSE) and National Institute of Standards and Technology (NIST) are granted the right to copy and distribute this document provided such reproduction is in its entirety. Document Number Change Level Security Level Page Number CR-1356 4 None i TABLE OF CONTENTS 1. Introduction............................................................................................................ 1 1.1. Purpose ............................................................................................................................................1 1.2. Scope................................................................................................................................................1 1.3. Application ........................................................................................................................................1 1.4. Intended Audience............................................................................................................................1 1.5. History of Revision............................................................................................................................1 1.6. References .......................................................................................................................................1 1.7. Glossary of Acronyms / Abbreviations .............................................................................................2 2. LunaŽ Token Overview......................................................................................... 2 3. Security Policy Overview ...................................................................................... 3 4. Operational Policy ................................................................................................. 4 4.1. Fixed Policy ......................................................................................................................................4 4.1.1. Number of SO Login Fails Allowed ...........................................................................................4 4.1.2. Secret Key Policy Bits - FPV.....................................................................................................4 4.1.3. Private Key Policy Bits - FPV ....................................................................................................4 4.1.4. Token Security Policy Bits - FPV ..............................................................................................5 4.1.5. Product Identification Bits - FPV ...............................................................................................6 4.2. Configurable Policy...........................................................................................................................6 4.2.1. Number of User Login Fails Allowed.........................................................................................7 4.2.2. Minimum/Maximum Authentication Code Length .....................................................................7 4.2.3. Local Policy Bits - TPV ..............................................................................................................7 4.2.4. Local Policy Bits ­ Extended TPV.............................................................................................8 5. Identification and Authentication (I&A) ............................................................... 8 5.1. Login .................................................................................................................................................8 5.2. Authentication Data and Trusted Path .............................................................................................9 5.3. Limits on Login Failures ...................................................................................................................9 5.4. M of N Activation (Luna CA3 and Luna RA3) ....................................................................................9 6. Token Access Control (TAC) .............................................................................. 10 6.1.1. Object Re-use .........................................................................................................................11 7. Physical Security Policy ..................................................................................... 11 8. Notes .................................................................................................................... 11 LIST OF TABLES Table 4-1 Secret Key Policy Bits - FPV ................................................................................................................. 4 Table 4-2 Private Key Policy Bits - FPV ................................................................................................................ 5 Table 4-3 Token Security Policy Bits - FPV........................................................................................................... 5 Table 4-4 Product Identification Bits - FPV............................................................................................................ 6 Table 4-5 Local Policy Bits - TPV .......................................................................................................................... 7 Table 4-6 Local Policy Bits ­ Extended TPV ......................................................................................................... 8 Table 6-1: Object Attributes Used in TAC Policy .................................................................................................. 11 Document Number Change Level Security Level Page Number CR-1356 4 None ii 1. INTRODUCTION 1.1. Purpose This document describes the security policies implemented by the LunaŽ PC Card (LunaŽ Token) and how the design of its firmware and hardware enforces these policies. 1.2. Scope This document addresses the Luna Token's security policies. 1.3. Application This document describes the security policies that apply to the following products: 1. LunaŽ CA3 2. LunaŽ RA3 3. LunaŽ RA 4. LunaŽ 2 5. LunaŽ DSM 1.4. Intended Audience The intended audience for this document is the Chrysalis-ITS Engineering and Product Management Team, external agencies for validation or endorsement of the Luna Token products; selected industry partners; prospective customers; and potential users of Luna Token products who want to understand the security policies of the products for FIPS operations. The reader of this document should be familiar with the PKCS#11 standard defined by RSA Laboratories. 1.5. History of Revision Revision Date Description 1 October 29, 2001 Combined CA3, Luna2 and Luna RA security policies. 2 February 6,2002 Removed former Appendix B (Policy Bit Settings) as obsolete. Minor wording changes to sections 4.2.1, 4.2.2 & 5.2 3 April 16, 2002 Extended security policy description to include Luna DSM 4 September 27, 2002 Add bold formatting to DES, 3DES wrapping mechanisms, revised description of fixed and configurable policies. 1.6. References Document No. Revision Author Title PKCS#11 V2.10 RSA Laboratories PKCS#11: Cryptographic Token Interface Standard, December 1999 FIPS PUB 140-1 Information Technology FIPS PUB 140-1: Security Requirements For Laboratory, National Cryptographic Modules, 11 January 1994. Institute of Standards and Technology Document Number Change Level Security Level Page Number CR-1356 4 None 1 1.7. Glossary of Acronyms / Abbreviations Term Explanation CAV Cryptographic Algorithm Vector CCM Custom Command Module CRC Cyclic Redundancy Check CSP Critical Security Parameters DAC Discretionary Access Control FPV Fixed Policy Vector I&A Identification and Authentication PED PIN Entry Device PIN Personal Identification Number SO Security Officer SRAM Static Random Access Memory TPV Token Policy Vector UAV User's Authorization Vector 2. LUNAŽ TOKEN OVERVIEW The Luna Token is a multi- chip standalone cryptographic device as defined in FIPS PUB 140-1. It securely stores data and keying material inside its cryptographic boundary. It also performs cryptographic operations on data provided by external applications using the keying material stored in the token. These abilities are defined as key management, object management, and cryptographic capability. Before a Luna Token can be used to perform any cryptographic or key/object management functions, it must receive a valid operator identity (also known as a user number), as well as valid authentication data. These two inputs are processed by the token during a "LOGIN" command. When this command has completed successfully, the token allows the user to perform operations based on the policy settings defined for that token. For a Luna CA3 or RA3 token, the authentication data must be entered using a Luna PIN Entry Device (PED), which provides a trusted path to the token, separate from the host platform. The token has the ability to distinguish between two categories of authenticated users: super-users and normal users. The super-user category is referred to as the Security Officer (SO) and the normal user category is referred to as the user. A token can have only one SO. The SO is allowed to perform all of the cryptographic, key and object management functions provided by the token, as well as a set of functions called the SO functions. These SO functions are available only to the SO, and they allow the SO to manage the token policy. For a Luna Token, there is no limit on the number of users that can be created by the SO. All users are subjected to the same policy settings as those established by the SO. However, each user has his or her own authentication code initially assigned under control of the SO, which is used internally to protect the data the user owns. Document Number Change Level Security Level Page Number CR-1356 4 None 2 The Luna CA3 and RA3 tokens protect critical security parameters in accordance with the requirements for FIPS 140-1 Level 3. In the case of these products, Critical Security Parameters (CSPs) are defined to be the SO's and Token Users' authentication codes, cloning domain identifier and M of N secret shares. These CSPs can only be exchanged with a Luna CA3 or RA3 token through a data path separate from the host platform (also known as a trusted path). The trusted path is provided via a dedicated data port on the PC Card reader directly to the token. The user interface to this trusted path is a PIN Entry Device or PED. With the PED, a user can store a pseudo randomly generated authentication code, the cloning domain identifier or M of N shares on Datakey serial memory keys (Datakey device). To enter any of these CSPs into the token, a user needs the token, a PED, a card reader capable of supporting communication between the token and the PED, and the Datakey devices containing the authentication data, cloning domain identifier or M of N shares. The Luna 2, Luna RA and Luna DSM tokens meet the FIPS 140-1 Level 2 physical security requirements. The Luna CA3 and RA3 token meet the FIPS 140-1 Level 3 physical security requirements. The physical security policy is described in section 7. 3. SECURITY POLICY OVERVIEW The security behaviour of the LunaŽ token is governed by the following security policies: ˇ Operational Policy ˇ Identification and Authentication Policy ˇ The Token Access Control (TAC) Policy ˇ Physical Security Policy These policies complement each other to provide assurance that cryptographic material is securely managed throughout its life cycle and that access to other data and functions provided by the product is properly controlled. Configurable parameters that determine many of the variable aspects of a token's behaviour are specified by the higher level Operational Policy implemented through two sets of policy parameters: the Fixed Policy and the Configurable Policy. They are described in sections 4.1 and 4.2. The Identification and Authentication policy is crucial for security enforcement and it is described in Section 5. The major security functional policy is the TAC policy. It is described in section 6,which also describes the supporting object re-use policy. Document Number Change Level Security Level Page Number CR-1356 4 None 3 Security audit is not performed by the Luna products. It is assumed that audit is a function provided by the environment. 4. OPERATIONAL POLICY The LunaŽ token employs the concept of Operational Policy Vectors to control the token's overall behaviour. The vectors control access to certain critical operations, such as token cloning, and establish security-critical information, such as the maximum number of failed login attempts. The Operational Policy is comprised of two sub-policies, each implemented through a policy vector: the Fixed Policy (Fixed Policy Vector) and the Configurable Policy (Token Policy Vector). The Fixed Policy is set as part of the manufacturing process and cannot be modified once set. The Configurable Policy is set by the Security Officer as part of token initialization and can be changed by a subsequent token initialization operation. 4.1. Fixed Policy The fixed policy is determined by the settings of the Fixed Policy Vector (FPV). The FPV contains the settings necessary to enforce policy rules that apply across a wide range of possible token usage scenarios and environments. The settings are described in the following sections. No Token User or SO can modify the FPV on a token. The FPV is put on the token when it is manufactured and remains in place until the token is destroyed or the firmware is erased. The integrity of the FPV is maintained through the same mechanism used to protect the executable code from being modified. This mechanism is a 32-bit Cyclic Redundancy Check (CRC) computation. 4.1.1. Number of SO Login Fails Allowed This field defines the number of consecutive failed login attempts that can be made by the SO before the token erases the flash memory to prevent illegal access to its contents. This is set to three (3) for all Luna Tokens. 4.1.2. Secret Key Policy Bits - FPV The following table defines the flags that identify the security policies that are followed for secret key objects. Table 4-1 Secret Key Policy Bits - FPV Setting Name Description 2 3 DSM RA CA RA 3 FPV_SECRET_KEY_SENSITIVE This bit determines whether a secret key object must always be made sensitive or if it can be determined by the high-level application using the token. When this bit is set, all secret keys stored on the token are sensitive. The keys are encrypted when in the flash memory and they 1 1 1 1 1 can be extracted outside of the token only in encrypted form using the LUNA_WRAP_KEY function. This bit must be set for FIPS-compliant tokens. FPV_SECRET_KEY_NO_CREATE This bit determines whether a secret key object can be created by an external application using the LUNA_CREATE_OBJECT call, instead of being generated by the token. When this bit is set, an external 1 1 1 1 1 application cannot create a secret key on the token; it is not possible to enter a secret key in plain text form on the token. This bit must be set for FIPS-compliant tokens. 4.1.3. Private Key Policy Bits - FPV The following table defines the flags that identify the security policies that are followed for private key objects. Document Number Change Level Security Level Page Number CR-1356 4 None 4 Table 4-2 Private Key Policy Bits ­ FPV Setting Name Description 2 3 RA CA RA 3 FPV_PRIVATE_KEY_SENSITIVE This bit determines whether a private key object must always be made sensitive or if it can be determined by the high-level application using the token. When this bit is set, all private keys stored on the token must be flagged as sensitive whether or not the high-level application requested 1 1 1 1 1 this flag when the keys were created. When this bit is set, all private keys are encrypted while stored in flash memory. This bit must be set for FIPS-compliant tokens. FPV_PRIVATE_KEY_NO_CREATE This bit determines whether a private key object can be created by an external application using the LUNA_CREATE_OBJECT call, instead of being generated by the token. When this bit is set, an external 1 1 1 1 1 application cannot create a private key on the token; it is not possible to enter a private key in plain text form on the token. This bit must be set for FIPS-compliant tokens. 4.1.4. Token Security Policy Bits - FPV The following table defines the flags that identify the security policies that dictate the behavior of the token in general. Table 4-3 Token Security Policy Bits - FPV Setting Name Description 3 2 DSM RA CA RA 3 FPV_DOMESTIC_FLAG This bit determines whether the token can be exported. When this bit is set, the token is configured for the domestic market and cannot be exported. This bit is verified internally every time a cryptographic function implying an encryption or a decryption is performed. If the bit is set, no restrictions exist on key sizes. If the bit is not set, a limitation of 56 bits is 1 1 1 1 1 applied to any symmetric keys used for encryption or decryption, and a 512-bit limitation on asymmetric keys used for wrapping and unwrapping operations. Signature and verification operations are not restricted in terms of key lengths. FPV_ENABLE_CLONING This bit determines whether sensitive objects on the token can be "cloned" to another similarly enabled token. When this bit is set, cloning is enabled. For a LunaRA token, this bit is tested in conjunction with the 0 1 1 1 1 FPV_RA_TOKEN bit to restrict the cloning of objects with the private key attribute set (i.e., CKO_PRIVATE_KEY). FPV_USE_CAV This bit is used by the firmware to determine if the CAV should be checked to validate the desired algorithm. Normally, this bit is clear, 0 0 0 0 0 which assumes all algorithms are valid. FPV_WRAPPING_TOKEN This bit determines whether RSA private keys can be wrapped. When this bit is set, an RSA private key can be wrapped. 3 Note: For Luna 2 and Luna CA tokens this setting is disabled to 0 0 1 0 1 ensure that a private key cannot be extracted from the token even in encrypted format. FPV_USE_M_OF_N This bit defines whether the token can perform M of N activation. When 0 0 0 1 1 this bit is set, the token can be configured to perform M of N activation. FPV_USE_RAW_RSA This bit determines whether RAW RSA operations can be performed on the token. When this bit is set, RAW RSA operations are allowed. RAW 1 1 1 1 1 RSA provides access to RSA to perform encrypt and decrypt operations on data without any padding. FPV_SPECIAL_CLONING This bit determines whether the token allows the factory-default Chrysalis-ITS key cloning certificate to be replaced. When this bit is set, 0 1 1 1 1 customers can create their own key cloning certificate. FPV_ENABLE_CCM This bit determines whether a Custom Command Module (CCM) can be loaded onto the token. When this bit is set, a CCM can be loaded onto 0 0 0 0 0 the token. This bit must be cleared (i.e., zero) for FIPS-compliant tokens. FPV_CCM_PRESENT_ This bit determines whether a CCM must be present before a firmware FWUPDATE update operation is allowed to proceed. When this bit is set, a CCM must be loaded on the token to perform a firmware update. Additionally, 0 0 0 0 0 the CCM must implement the PreModuleUpdate function. This bit is for an OEM version of Luna2 and does not apply to the Chrysalis-ITS Document Number Change Level Security Level Page Number CR-1356 4 None 5 labeled product. FPV_FORCE_RSA_BLINDING This bit determines whether the token must perform blinding, which introduces a random element to the time needed to complete an RSA operation. Blinding defeats timing attacks on an RSA operation. If this 0 0 0 0 0 bit is set, the token will always use RSA blinding (the TPV_FORCE_RSA_BLINDING bit will have no effect). FPV_PIN_MUST_USE_SP This bit determines if the serial communication port must be used to enter an authentication code. When this bit is set, an authentication code 0 0 0 1 1 can only be entered through the serial communication port. When this bit is cleared, authentication codes are entered via the host computer. FPV_MOFN_MUST_USE_SP This bit determines if the serial communication port must be used to enter the M of N secret. When this bit is set, the M of N secret can only 0 0 0 1 1 be entered through the serial communication port. When this bit is cleared, the M of N secret is entered via the host computer. FPV_KCV_MUST_USE_SP This bit determines if the serial communication port must be used to enter the key cloning domain identifier. When this bit is set, the key cloning domain identifier can only be entered through the serial 0 0 0 1 1 communication port. When this bit is cleared, the key cloning domain identifier is entered via the host computer. FPV_ALLOW_HA_RECOVERY With this bit set, the High-availability recovery mode is enabled. 0 0 0 1 0 4.1.5. Product Identification Bits - FPV The following table defines the flags that identify the configuration of the product. Table 4-4 Product Identification Bits - FPV Setting Name Description 3 2/DSM RA CA RA 3 FPV_XP_TOKEN This bit determines if the token is used in an XP style functionality, thus 3 allowing the KCV to be set indirectly (allows XP tokens to get a CA 's 0 0 0 0 domain vector). This allows the token to be initialized as either a FIPS Level 2 or 3 device at Init Token time; all keys must be volatile. FPV_LUNA_SSL_TOKEN 0 0 0 0 FPV_RA_TOKEN This bit determines if the token has the RA functionality which includes private RSA key extraction. In addition to the cloning restriction of private key objects (see FPV_ENABLE_CLONING), special component 0 1 0 1 key wrapping is associated with the LUNA_MECH_3DES_ECB mechanism. FPV_XPPLUS_TOKEN This bit indicates that the token is built upon XPplus-style hardware. XPplus hardware has: asymmetric math accelerators; extra RAM; non- 0 0 0 0 volatile RAM; tamper detection mechanisms which trigger interrupts and wipe non-volatile RAM. 4.2. Configurable Policy The configurable policy is determined by the settings of the Token Policy Vector (TPV). The TPV contains the settings necessary to enforce policy rules locally in an organization. For example, one bit in the TPV defines whether the token can perform a signature operation using a signing key generated by an outside process or if it must use an internally generated key for this function. The TPV can be modified by the token's SO. The TPV contents are used by the internal code to validate the operations performed by the token's user. Document Number Change Level Security Level Page Number CR-1356 4 None 6 4.2.1. Number of User Login Fails Allowed This field defines the number of consecutive failed login attempts that can be made by a user before the user gets locked out or the user's data is erased. This security feature prevents illegal access to the user's data and keys: it prevents an impostor from cracking the user's authentication code on the token. The default value, set at manufacturing time, is ten (10). Whether the user is locked out or the data is erased depends upon the "User Zeroize" bit. If the User Zeroize bit is disabled, too many failed login attempts results in the User getting locked out. In this case, a user must make a request to the SO to regain access to the token. The SO also provides a new password for the user. If the User Zeroize bit is enabled, too many failed login attempts results in the User being deleted. In this case, the User's identity and private data (including key material) are erased from the token. The SO must create a new user in order to continue. The new user will have no association with the previous (deleted) user. The default setting of the User Zeroize bit is enabled. 4.2.2. Minimum/Maximum Authentication Code Length These two fields define the minimum and maximum length restrictions for a USER's authentication data in a Level 2 validated token (e.g., Luna2 and Luna DSM). They have no effect on the length of the pseudo-random authentication data that is generated by Level 3 tokens (e.g., Luna CA3) and stored on the PED Key; that length is fixed at forty-eight (48) bytes. For Level 3 tokens, the Security Officer may, when the user is created, require the user to enter a PIN value of up to sixteen (16) digits via the keypad on the PED in addition to the 48-byte secret generated by the token. The PIN value is combined, within the PED, with the token-generated secret to form the value that is stored on the PED Key for the user. 4.2.3. Local Policy Bits - TPV The following table defines the flags that identify the security policies that dictate the behavior of the users on the token. Table 4-5 Local Policy Bits - TPV Default Name Description Setting 3 3 2/DSM RA CA RA TPV_USER_ZEROIZE This bit determines whether the token can be zeroized by a normal user or if only the token's SO can zeroize the token. When this bit is set, it 1 1 1 1 indicates that a valid token user can zeroize the token. When this bit is set, a user is zeroized after too many unsuccessful login attempts. TPV_USER_FW_UPDATE This bit determines whether the firmware can be updated by a normal user or if only the token's SO can update the firmware. When this bit is set, a 0 0 0 0 normal user can perform the firmware update. TPV_M_OF_N_ACTIVATION This bit determines whether M of N activation is required for a user to gain access to the token. When this bit and the FPV_USE_M_OF_N bit in the 0 0 0 0 FPV is set, the token is not activated until the required number of parts to a split secret have been entered. TPV_KEY_ATTRIB_LOCK This bit determines whether the flag attributes of a key can be modified once the key is a valid object on the token. When this bit is set, it indicates that the flag attributes of a key cannot be modified after they have been 1 1 1 1 established. For example, if this bit is set and a DES key is created for encryption and decryption, these attributes cannot be changed to wrap and unwrap once the key exists on the token. TPV_KEY_SINGLE_FUNCTION This bit determines whether a key can be used to perform multiple types of operations (i.e., use a key for encrypting, signing, and wrapping). When this bit is set, it indicates that keys can be used only to perform single functions. 0 0 0 0 For symmetric keys, a single function is considered to be a pair of related functions such as encryption/decryption, wrapping/unwrapping, or sign/verify TPV_SIGNING_KEY_LOCAL When performing a signing operation, the private key used may have been 0 0 0 Document Number Change Level Security Level Page Number CR-1356 4 None 7 generated locally or provided by an external source. In most environments, 0 it is preferable to have the signing/verifying key pair generated by the token and never extracted from it. However, in certain cases the signing keys are generated externally and loaded on the token for subsequent signature operations. When this bit is set, it indicates that externally generated keys cannot be used for signing operations performed by the token. 4.2.4. Local Policy Bits ­ Extended TPV The following table defines the flags that identify the security policies that dictate the behavior of the users on the token. Table 4-6 Local Policy Bits ­ Extended TPV Default Name Description Setting 3 3 2/DSM RA CA RA TPV_FORCE_RSA_BLINDING This bit determines whether the token must perform blinding on RSA operations. If the FPV_FORCE_RSA_BLINDING bit is on, RSA blinding is performed on the token regardless of this TPV bit. 1 1 1 1 However, if the FPV_FORCE_RSA_BLINDING bit is clear, the TPV_FORCE_RSA_BLINDING bit determines if the token will use RSA blinding. When the bit is set, blinding is performed. TPV_DISABLE_CLONING_BY_USER This bit determines whether a user or both a user and the token's SO are permitted to clone sensitive objects when the FPV_ENABLE_CLONING bit is set. If the FPV_ENABLE_CLONING bit is clear, no cloning is permitted and the TPV_DISABLE_CLONING_BY_USER bit has no effect regardless of its value. 0 0 0 0 If the FPV_ENABLE_CLONING bit is set and the TPV_DISABLE_CLONING_BY_USER is clear, both a user and the token's SO are permitted to clone sensitive objects. If the FPV_ENABLE_CLONING bit is set and the TPV_DISABLE_CLONING_BY_USER is set, only the token's SO is permitted to clone sensitive objects. TPV_XP_MUST_USE_SP This bit determines whether the token implements XP-type functionality. When this bit is set: all objects are stored in volatile memory; token KCV may be cloned from a different token; the token is 0 0 0 0 dual mode (i.e., whether the SP is required is defined at token initialization time); and, object headers are always modifiable, even in non-modifiable objects. TPV_ALLOW_HA_RECOVERY If enabled by the Fixed Policy Vector, with this bit set, High-availability 0 0 1 0 recovery is allowed. 5. IDENTIFICATION AND AUTHENTICATION (I&A) The Luna Token enforces an identity-based user authentication policy. Users are identified on the token by a user number, with the Security Officer having a special user number assigned. The Luna Token also supports three user roles: Public, Token User and Security Officer. Public users are unidentified and unauthenticated and may perform a limited set of functions, such as opening a session with a token and performing pre-defined diagnostics. A Public user cannot perform any cryptographic functions. The Security Officer (SO) is a privileged role whose primary purpose is to initially configure the token for operation and to perform security administration tasks such as user creation. The Token User is the normal operational role given to authenticated users on the token. Note: Token users also have a text-based name associated with them. The name corresponding to a particular user number can be queried from the token. 5.1. Login Document Number Change Level Security Level Page Number CR-1356 4 None 8 For a user to assume either the Token User or Security Officer role and perform cryptographic functions and other operations beyond those allowed for a Public user, the user must be identified and authenticated. For a Token User, the user number and valid authentication data (e.g., a password or the data stored on a Datakey device) must be provided to the token before access to private data and token services can be granted. For the SO, only valid authentication data is required. When M of N Activation has been enabled, as required by local security policy, no user can assume either the Token User or the Security Officer role before the M of N activation has been completed. 5.2. High Availability Recovery Support Luna CA3 provides an indirect login mechanism to support a capability for high availability recovery between two Luna CA3 devices. It permits a backup Luna CA3 device to share a common authentication state with the primary device within a given domain in order to allow automatic recovery of operations via the backup device in the event of a primary device failure. 5.3. Authentication Data and Trusted Path Authentication data can be provided in multiple forms. For the Luna 2, Luna RA and Luna DSM tokens, it is in the form of a user-generated password or Personal Identification Number (PIN) that is normally entered via the keyboard of the host computer. For the LunaŽ CA3 and RA3 tokens, the primary form is data that is randomly generated by the token, stored on a PED key and entered by the user for authentication. These tokens require that authentication data and M of N shares be entered using a trusted path separate from the host IT environment. In addition, when the user is initially created by the SO, the user may also be required to enter a separate user-generated authentication secret, of up to sixteen (16) digits, via the trusted path in addition to the randomly generated data. Level 2 tokens enforce minimum and maximum lengths on the user-generated secrets based on the settings of the Configurable Policy. For Level 3 tokens the authentication data length is always forty-eight (48) bytes. 5.4. Limits on Login Failures The LunaŽ tokens also enforce a maximum login attempts policy. The policy differs for an SO authentication data search and a Token User authentication data search. In the case of a Token User PIN search: ˇ If "y" consecutive user logon attempts fail ("y" is defined by the SO in the Configurable Policy) the token flags the event in the user's account data and handles the event as described in section 4.2.1. In the case of an SO PIN search: ˇ If three (3) consecutive SO logon attempts fail, the token is zeroized. It must be re-initialized to return it to operation. 5.5. M of N Activation (Luna CA3 and Luna RA3) Luna CA3 supports a token activation feature called M of N. The concept of the M of N activation capability provides protection of a secret by "splitting" it into "N" pieces, where any "M" of these pieces must be reassembled to reconstruct the original secret. The Luna CA3 feature is based on Shamir's threshold scheme. This scheme allows a secret value to be shared by "n" external recipients without risking any compromise to the secret. Document Number Change Level Security Level Page Number CR-1356 4 None 9 Initialization for M of N activation must be performed when there are no permanent sensitive objects stored on the token. Otherwise, there is a risk of corrupting objects stored in flash prior to generating the M of N set or after "deactivating" the feature. Management of M of N activation is an operational issue for the SO. The M of N secret splits may be shared by more than one token within a domain. This capability must be invoked at the time of initialization. This same capability may be used to duplicate the M of N secret splits for backup purposes. Note that for M of N activation to be effective, the values of M and N should be two or greater. Consider, for example, a 1 of 1 share to be of little value in securing activation of a token. 6. TOKEN ACCESS CONTROL (TAC) The Token Access Control (TAC) policy applies to all objects on the Token, in particular to private key and secret key objects, and covers the following operations: ˇ Create ˇ Read ˇ Copy ˇ Modify ˇ Destroy ˇ Generate ˇ Derive ˇ Wrap ˇ Unwrap ˇ Use (encrypt, decrypt, sign, verify) ˇ Clone The policy is summarized by the following statements: A user may perform an allowed operation on an object if one of the following two conditions holds: 1. The object is a "Public" object, i.e., the PRIVATE attribute is FALSE, or 2. The user owns the object. Allowed operations are those permitted by the Fixed and Configurable Policy settings and the values of the attributes shown in Table 6-1. The token does not allow for any granularity of ownership other than that of private or public (i.e., a data object cannot be owned by two users and restricted from other users). Also, ownership of an object implies full access rights to the object and those access rights cannot be individually assigned by the owner to other users (e.g., User1, as the owner of an object, cannot give read access to it to User2). Table 6-1 lists object attributes used in making TAC policy enforcement decisions, the values each can have and the impact of each attribute value on policy enforcement. These attributes may only be set and/or modified, within the restrictions established by the Fixed and Configurable Policies, by the SO and Token User. Document Number Change Level Security Level Page Number CR-1356 4 None 10 Table 6-1: Object Attributes Used in TAC Policy Attribute Values Impact TRUE ­ Object is private to (owned Object is only accessible to by) the user identified as the subjects (sessions) bound to the Access Owner when the object is user identity that owns the object. PRIVATE created FALSE ­ Object is not private to Object is accessible to all subjects. one user identity TRUE ­ Attribute values Key material is stored in encrypted representing plaintext key material form. For all FIPS-compliant are not permitted to exist (value products, this attribute is always encrypted) TRUE. SENSITIVE FALSE ­ Attribute values Plaintext key material is stored with representing plaintext key material the object and is accessible to all are permitted to exist subjects otherwise permitted access to the object. TRUE ­ The object's attribute The object is "writeable" and its values may be modified attribute values can be changed MODIFIABLE during a copy operation. FALSE ­ The object's values may The object can only be read and not be modified only duplicate copies can be made. TRUE ­ Key material stored with The ability to extract a key permits the object may be extracted from sharing with other crypto modules the token using the Wrap operation and archiving of key material. EXTRACTABLE FALSE ­ Key material stored with Keys must never leave the token. the object may not be extracted Private Keys in the CA3 and Luna 2 from the token are always treated as if this attribute is FALSE. 6.1.1. Object Re-use The access control policy is supported by an object re-use policy. The object re-use policy requires that the resources allocated to an object be cleared of their information content before they are re-allocated to a different object. 7. PHYSICAL SECURITY POLICY The Luna Token hardware shall be constructed in such a way that it will resist attempts to open the card or otherwise get at its internal circuitry and it will provide evidence of physical tampering by ensuring that any such attempt will leave the card in a state in which it is either inoperative or it is at least damaged to an extent that it cannot be restored to its previous condition. 8. NOTES Datakey is a registered trademark of Datakey, Inc. Document Number Change Level Security Level Page Number CR-1356 4 None 11 APPENDIX A. Cryptographic Algorithms Support FIPS-approved algorithms are shown in bold lettering. Encrypt/Decrypt: ˇ DES-ECB ˇ DES-CBC ˇ 3-DES-ECB ˇ 3-DES-CBC ˇ RC2-ECB ˇ RC2-CBC ˇ RC4 ˇ RC5-ECB ˇ RC5-CBC ˇ CAST-ECB ˇ CAST-CBC ˇ CAST3-ECB ˇ CAST3-CBC ˇ CAST5-ECB ˇ CAST5-CBC ˇ RSA X-509 Digest: ˇ MD2 ˇ MD5 ˇ SHA-1 Sign/Verify: ˇ RSA -1024 ˇ RSA -2048 ˇ DSA ˇ DES-MAC ˇ 3-DES-MAC ˇ RC2-MAC ˇ RC5-MAC ˇ CAST-MAC ˇ CAST3-MAC ˇ CAST5-MAC ˇ SSL3-MD5-MAC ˇ SSL3-SHA1-MAC ˇ HMAC-SHA1 ˇ HMAC-MD5 Generate Key: ˇ DES ˇ double length DES ˇ triple length DES ˇ RC2 ˇ RC4 ˇ RC5 ˇ CAST ˇ CAST3 ˇ CAST5 ˇ PBE-MD2-DES ˇ PBE-MD5-DES ˇ PBE-MD5-CAST ˇ PBE-MD5-CAST3 ˇ PBE-SHA-1-CAST5 ˇ GENERIC-SECRET ˇ SSL PRE-MASTER Document Number Change Level Security Level Page Number CR-1356 4 None 12 Generate Key Pair: ˇ RSA-1024 ˇ RSA-2048 ˇ DSA-1024 ˇ DH-1024 Wrap Symmetric Key Using Symmetric Algorithm: ˇ DES-ECB ˇ 3-DES-ECB ˇ RC2-ECB ˇ CAST-ECB ˇ CAST3-ECB ˇ CAST5-ECB Wrap Symmetric Key Using Asymmetric Algorithm: ˇ RSA-1024 ˇ RSA-2048 Wrap Asymmetric Key Using Symmetric Algorithm: 1 ˇ 3-DES-CBC Unwrap Symmetric Key With Symmetric Algorithm: ˇ DES-ECB ˇ 3-DES-ECB ˇ RC2-ECB ˇ CAST-ECB ˇ CAST3-ECB ˇ CAST5-ECB Unwrap Symmetric Key With Asymmetric Algorithm: ˇ RSA-1024 ˇ RSA-2048 Unwrap Asymmetric Key With Symmetric Algorithm: ˇ DES-CBC ˇ 3-DES-CBC ˇ CAST-CBC ˇ CAST3-CBC ˇ CAST5-CBC Derive Key Value: ˇ DH-1024 ˇ concatenate Base & Key ˇ concatenate Base & Data ˇ concatenate Data & Base ˇ XOR Base and Data ˇ Extract Key from Key ˇ MD2 Derivation ˇ MD5 Derivation ˇ SHA-1 Derivation ˇ SSL3-Master ˇ SSL3-Key & MAC 1 Although this is a mechanism that is supported by the base firmware, the FPV settings for CA3 and XPPlus prevent wrapping of asymmetric private keys. Document Number Change Level Security Level Page Number CR-1356 4 None 13 APPENDIX B. Session And Login States Required For Luna Commands Command No Session SO User To Session Open, No Logged Logged Module Open Login On On Token Main Module Commands LUNA_ZEROIZE LUNA_INIT_TOKEN LUNA_GET LUNA_GET_USV LUNA_SET_TPV LUNA_FW_UPDATE LUNA_CONFIGURE_SP Session Manager Commands LUNA_OPEN_ACCESS LUNA_CLEAN_ACCESS LUNA_CLOSE_ACCESS LUNA_GET_ALL_ACCESSES LUNA_OPEN_SESSION LUNA_CLOSE_SESSION LUNA_CLOSE_ALL_SESSIONS LUNA_GET_SESSION_INFO LUNA_EXTRACT_CONTEXTS LUNA_INSERT_CONTEXTS User Module Commands LUNA_GET_USER_LIST LUNA_GET_USER_NAME LUNA_LOGIN LUNA_LOGOUT LUNA_SET_PIN LUNA_INIT_PIN LUNA_CREATE_USER LUNA_DELETE_USER Object Management Module LUNA_CREATE_OBJECT LUNA_COPY_OBJECT LUNA_DESTROY_OBJECT LUNA_GET_OBJECT_SIZE LUNA_GET_ATTRIBUTE_VALUE LUNA_GET_ATTRIBUTE_SIZE LUNA_MODIFY_OBJECT LUNA_FIND_OBJECTS Random Number Generator Module LUNA_GET_RANDOM LUNA_SEED_RANDOM Key Management Module LUNA_GENERATE_KEY LUNA_GENERATE_KEY_W_VALUE LUNA_GENERATE_KEY_PAIR LUNA_WRAP_KEY LUNA_UNWRAP_KEY LUNA_UNWRAP_KEY_W_VALUE LUNA_DERIVE_KEY LUNA_DERIVE_KEY_W_VALUE LUNA_MFG_LOAD Cryptographic Algorithm Module LUNA_ENCRYPT_INIT LUNA_ENCRYPT_INIT_W_VALUE LUNA_ENCRYPT_INIT LUNA_ENCRYPT_INIT_W_VALUE Document Number Change Level Security Level Page Number CR-1356 4 None 14 Command No Session SO User To Session Open, No Logged Logged Module Open Login On On LUNA_ENCRYPT LUNA_ENCRYPT_FIFO LUNA_ENCRYPT_END LUNA_DECRYPT_INIT LUNA_DECRYPT_INIT_W_VALUE LUNA_DECRYPT LUNA_DECRYPT_FIFO LUNA_DECRYPT_END LUNA_DECRYPT_RAW_RSA LUNA_DIGEST_INIT LUNA_DIGEST LUNA_DIGEST_FIFO LUNA_DIGEST_KEY LUNA_DIGEST_KEY_VALUE LUNA_DIGEST_END LUNA_SIGN_INIT LUNA_SIGN_INIT_W_VALUE LUNA_SIGN LUNA_SIGN_FIFO LUNA_SIGN_END LUNA_SIGN_SINGLEPART LUNA_SIGN_UPDATE_KEY LUNA_SIGN_FINAL_DERIVE_KEY LUNA_VERIFY_INIT LUNA_VERIFY_INIT_W_VALUE LUNA_VERIFY LUNA_VERIFY_FIFO LUNA_VERIFY_END LUNA_VERIFY_SINGLEPART LUNA_GET_MECH_LIST LUNA_GET_MECH_INFO LUNA_SELF_TEST LUNA_SET_UP_MASKING_KEY LUNA_CLONE_AS_SOURCE LUNA_CLONE_AS_TARGET_INIT LUNA_CLONE_AS_TARGET LUNA_GEN_TKN_KEYS LUNA_LOAD_CERT LUNA_GEN_KCV LUNA_LOAD_CUSTOMER_VERIFICATION_KEY LUNA_M_OF_N_GENERATE LUNA_M_OF_N_ACTIVATE LUNA_M_OF_N_MODIFY Special Packet Processing Commands LUNA_IPSEC_INIT_NO_USER LUNA_IPSEC_PROCESS_PACKET LUNA_IPSEC_END LUNA_GEN_CRC32 LUNA_SCP_TEST Document Number Change Level Security Level Page Number CR-1356 4 None 15