LunaCA3 Security Policies DOCUMENT CLASS: Overview CODE NAME: n/a SECURITY LEVEL: Unrestricted ORIGINATOR: Wayne A. Reed DEPARTMENT: Engineering DATE ORIGINATED: 24 August 1998 DOCUMENT NUMBER: 802509 VERSION: 1.20 PROJECT NO: 5500-100 PRINTED BY: Wayne Reed PRINTED ON: 09/24/98 at 7:44 AM APPROVALS Manager, Firmware Development Roger Hebb Date Chief Technical Bruno Couillard Officer Date V.P., Engineering Wayne Reed Date (c) Copyright 1997-98 Chrysalis-ITS, Inc. All rights reserved. Canadian 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. ‚Revision History eee : 21 August 1998 | Created document from Luna2 Security Policies; addressed comments from DOMUS. Revised TPV key single function bit; added a statement on physical security; added key cloning domain identifier and M of N shares as required parameters for the SCP in level 3 mode. 21 September 1998 | Modified copyright and security classification. 24 August 1998 Quariou_— LunaCn? Security Dolieioe Document #802509 V1.20 Table of Contents 1. Introduction . 1.1. Purpose... 12. Scope... 1.3. Intended Audience. 2. LunaCA? Overview 3. Security Policy Tools 3.1. Fixed Policy Vector (FPV)...... 3.1.1. Number of SO Login Fails Allowed.. 3.1.2. Secret Key Policy... 3.1.3. Private Key Policy... 3.1.4. Token Security Policy 3.2. Cryptographic Algorithm Vector (CAV) 3.3. Token Policy Vector (TPV) 3.3.1. Number of User Login Fails Allowed .................. 3.3.2. Minimum/Maximum Authentication Code Lengt! 3.3.3. Local Policies............ RE ENEEEER u Identification and Authentication (I&A) stenenserenes stanersenaes m? Discretionary Access Control (DAC) M of N Activation .... Object Reuse... References....... SE p N ® œ B Unrestricted Chrysalis-17h Overview— LunaCA3 Security Policies Document #802509 V1.20 Unrestricted Chrysalis-I15 ii Quaniaw LunaCn? Soourity Dalieioo Document #802509 V1.20 1. Introduction 1.1. Purpose This document describes the security policies implemented by the LunaCA? PC Card (LunaCA? token) and how the design of its firmware enforces these policies. 1.2. Scope This document addresses the LunaCA? token’s security policies. 1.3. Intended Audience The intended audience for this document is: the LunaCA® Engineering and Product Management Team, external agencies for validation or endorsement of the LunaCA? token; selected industry partners; Prospective customers; and potential users of LunaCA® that want to understand the security policies of the product for FIPS operations. The reader of this document should be familiar with the PKCS#11 standard [PKCS#1 1] defined by RSA Laboratories. 2. LunaCA° Overview The LunaCA? token securely stores data and keying material inside its cryptographic boundary. The LunaCA’ token 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 LunaCA’ token can be used to perform any cryptographic or key/object management functions, the token must receive a valid operator identity (also known as a user number), as well as valid authentication code. 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. The token has the ability to distinguish two categories of 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 LunaCA* 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 its own authentication code initially assigned under control of the SO, which is used internally to protect the data the user owns. The LunaCA’ token Protects critical security parameters as defined by [FIPS 140-1]. For the purposes of a LunaCA? token, critical security parameters are the SO's and users’ authentication codes. These critical security parameters can only be exchanged with a LunaCA® token through a separate data port. Attached to this separate data port via the PC Card reader is a PIN Entry Device or PED. With the PED, a user can store a pseudo randomly-generated authentication code on a Datakey® serial memory key (Datakey device). To access the cryptographic material on a LunaCA’ 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 SO and/or user authentication codes. Unrestricted Chrysalis-I15 1 Overview — LunaCA3 Security Policies Document #802509 V1.20 As per FIPS requirements, the LunaCA’ token also enforces the use of a separate data port for input and output of plaintext cryptographic key components and plaintext authentication data. The key cloning domain identifier and M of N shares are plaintext cryptographic key components and, hence, are protected through the use of the separate data port. The LunaCAŸ token meets and is validated against FIPS 140-1 level 3 physical security requirements. For example, one aspect of physical security is through tamper evidence provided by the case: an attacker cannot get into the LunaCA*token and access plaintext keys in an operational state. Contact Chrysalis-ITS for more details of the physical security used to protect the LunaCA*token. 3. Security Policy Tools The LunaCAŸ token provides two levels of security policy enforcement. A vector that is loaded on the token during manufacturing dictates the first level of security. This vector, called the Fixed Policy Vector (FPV), establishes an envelope of security that cannot be modified after manufacturing. The second level of security is provided by policy vector that can be modified by the token's SO. This vector is called the Token Policy Vector (TPV), and consists of a series of policy settings that can be established and modified by the token's legitimate SO. Unrestricted Chrysalis: IIa 2 Qvarviow .. LunaCA2 Socurity Bolieioe Document #802509 V1.20 3.1. Fixed Policy Vector (FPV) The FPV contains the settings necessary to enforce policy rules that apply across a wide range of token users, regardless of their organizational policies. For example, one bit in the FPV defines whether the token can be exported. In an exportable version, the token provides a reduced set of algorithms and imposes limitations on maximum key lengths as required by export regulations. The FPV cannot be modified by the SO or any of the users. 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 CRC computation. The format of the FPV is a 32-bit vector that is divided into four fields of eight bits. These fields and their contents are defined in the following sections. 3.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 security measure prevents an impostor from cracking the SO's authentication code on the token. 3.1.2. Secret Key Policy The following table defines the flags that identify the security policies that are followed for secret key objects. Description is bit determines whether a secret key object must always be made sensitive or if it can be determined by the high-level application using thet token. When this bit is set, all secret keys stored on the token are sensitive. e keys are encrypted when in the flash memory and they can be extracted only outside of the token in encrypted form using the GESC_WRAP_KEY function. his bit must be set for FIPS-compliant tokens. PV_KEY_POLICY_NO_CREATE his bit determines whether a secret key object can be created by a external application using the token, instead of being generated by the token. When this bit is set, an external application cannot create a secret ey on the token; it is not possible to enter a secret key in plain text form oı the token. 3.1.3. Private Key Policy The following table defines the flags that identify the security policies that are followed for private key objects. Unrestricted Ehrysalis-I15 3 Overview — LunaCA3 Security Policies Document #802509 V1.20 oken through PKCS#11. When this bit is set, all private keys stored on the token must be flagged as sensitive whether or not the high-level applicatio equested this flag when the keys were created. When this bit is set, all his bit determines whether a private key object can be created by a external application using the GESC_CREATE_OBJ call, instead of being 3.1.4. Token Security Policy The following table defines the flags that identify the security policies that dictate the behavior of the token in general. is bit determines whether the token can be exported. When this bit is set, he token is configured for the domestic market and cannot be expot lis bit is verified internally every time a cryptographic function implying is bit indicates that the token is intended for use in a server environment] hen this bit is set, server operations are enabled. For a LunaCA’ token, his bit is not set. his bit is used by the firmware to determine whether the token was loaded ith Cryptographic Algorithm Vector (CAV). When this bit is set, CAV is present. This setting is intended for tokens that were manufactured before} his bit determines whether RSA private keys can be wrapped. When this bit is set, an RSA pri be wrapped. bit is set, the token can be configured to perform M of N activation. M of is a principal feature of a LunaCA” token. lis bit determines whether RAW RSA operations can be performed on the token. When this bit is set, RAW RSA operations are allowed. RAW RSA provides access to RSA to perform encrypt and decrypt operations on data ithout any padding. his bit determines whether the token can participate in key cloning. Wher lis bit is set, key cloning can be performed. Key cloning is a principal eature of a LunaCA’ token. his bit determines whether a custom command module can be loaded onto the token. When this bit is set, a custom command module can bei aded onto the token. lis bit must be cleared (i.e., Zero) for FIPS-compliant tokens. lis bit determines if the serial communication port must be used to enter authentication code. When this bit is set, an authentication code cai the serial communication port. When this bit i IFPV_SECURITY_POLICY_SPECIAL_CLONING PV_ENABLE_CCM PV_PIN_MUST_USE_SP Unrestricted Chrysais-M1a 4 Quarviaw _ LunaCA2 Socurity Polieioe Document #802509 V1.20 Description leared, authentication codes are entered via the host ‘computer. Use of he serial communication port is a principal feature of a LunaCA® token. is bit must be set for FIPS 140-1 level 3-compliant tokens. his bit determines if the serial communication port must be used to enteı Ihe M of N secret. When this bit is set, the M of N secret can only bei entered through the serial communication port. When this bit is cleared, the M of N secret is entered via the host computer. Use of the serial communication port is a principal feature of a LunaCA® token. is bit must be set for FIPS 140-1 level 3-compliant tokens. his 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 iain identifier can only be entered through the serial communicatioı When this bit is cleared, the key cloning domain identifier is entered a the host computer. Use of the serial communication port is a principa feature of a LunaCA’ token. his bit must be set for FIPS 140-1 level 3-compliant tokens.. 3.2. Cryptographic Algorithm Vector (CAV) CAV contains a series of flags that identify which cryptographic algorithms are active on a token. One bit is. defined for each algorithm that the token firmware can perform. When set, the token can perform a triple-DES encryption operation. | CACAV_RC4_ENCRYPT | When set, the token can perform an RC4 encryption operation] When set, the token can on operation. When set, the token can perform an RC5 encryption operation. When set, the token can ption operation. When set, the token can perform a CAST decryption operation. When set, the token can perform a CASTS decryption operation. | CA.CAV Mp2 | When set, the token can perform an MD2 operation. | | CA.CAV_MD5 When set, the token can perform an MDS operation. | [ CA.CAV SHAT When set, the token can perform an SHA:1 operation | CA.CAV_RSA "| When set, the token can perform an RSA operation. | When set, the token can perform a DSA operation. When set, the token can perform a Diffie Hellman operation. There are two fields in CAV that each consist of four bits. These fields represent the major and minor version of CAV. Unrestricted Chrysalis-I15 5 ET Overview — LunaCA3 Security Policies Document #802509 V1.20 a | CA_CAV_VERSIO INOR These four bits represent the minor version of the CAV vector. 3.3. 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. The format of the TPV is a 32-bit vector that is divided into four fields of eight bits. These fields and their contents are defined in the following sections. 3.3.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 erase. 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. 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. Under control of the SO, the USER receives a new authentication code (e.g., a new Datakey device). 3.3.2. Minimum/Maximum Authentication Code Length These two fields define the minimum and maximum length restrictions for a USER's authentication code. 3.3.3. Local Policies The following table defines the flags that identify the security policies that dictate the behavior of the users on the token. | m |] PV_USER_ZEROIZE his bit determines whether the token can be zeroized by a normal user or if only the SO can zeroize the token. his bit indicates whether the token is centrally controlled. ven this bit is set, it indicates that a valid token user can zeroize the token. This bi enables using the token in an environment where the SO is not commonly used. a ts. PV_USER_FW_UPDATE he token’s SO can update the firmware. When this bit is set, a normal user can perform the firmware update. PV_M_OF_N_ACTIVATION is bit determines whether M of N activation is required for a user to gain access to] he token. When this bit and the FPV_SECURITY_POLICY_USE_M_OF_N bit in he FPV is set, the token is not activated until the required number of parts to a split secret have been entered. PV_KEY_ATTRIB_ LOCK is 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 established. For example, if this bit] is set and a DES key is created for encryption and decryption, these attributes Unrestricted Chrysalis-M1a 6 Qvarviow LunaCA2 Soaurity Dalieioe Document #802509 V1.20 Description ged to wrap and unwrap once the key exists on the token. his bit determines whether a key can be used to perform multiple types of operations (i.¢., 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. For symmetric keys, a single function is considered to be a Pair of related functions such] aS encryption/ /ption, wrapping/unwrapping, or sign/verify. . With the validated elease of LunaCA”, multiple use of a key is allowed regardiess of the value of PV_KEY_SINGLE_FUNCTION. en performing a signing operation, the private key used may have been generated locally or provided by an external source. In most environments, 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 it is set, it indicates that externally generated keys cannot be used for signing operations performed by the token. 4. Identification and Authentication (1&A) The LunaCA’ token enforces an identity-based user authentication policy. For normal users, the user number and a valid authentication code (e.g., 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 a valid authentication code is required. Note: Normal users also have a text-based name associated with them. The name corresponding to a particular user number can be queried from the token. PV_SIGNING_KEY_LOCAL ‘The authentication codes for the SO and users can be changed at any time by their respective owners. The SO can also re-instate users with lost authentication codes. Re-instating users does not affect the eryptographic material and data owned by the user and protected under the old authentication code. The LunaCA? token implements policy that limits the number of login attempts. This feature prevents an exhaustive search approach for finding the authentication code of the SO or user. The implementation of this feature differs from that of an SO authentication code search and that of a user authentication code search, For a user authentication code search: . If “n” consecutive user logon attempts fail, the token flags the event in the user's authorization vector (UAV). This locks out the user until the SO logs back on to the token and unlocks the user. (The value of "n" is defined by the SO in the TPV.) For an SO authentication code search: . If “n” consecutive SO logon attempts fail, the token is zeroized and its operational state goes to ZEROIZED. (The value of "n" is defined in the FPV, which is defined when a LunaCA’ token is manufactured and cannot be modified without invalidating the CRC value of the software load.) 5. Discretionary Access Control (DAC) Every data object on the token can be public or private. Private data objects are labeled with a number that Corresponds to the owner and can be accessed only by the legitimate owner. A user cannot create a key or certificate object as a public object. Only data objects can be public or private. The token does not allow for any granularity of ownership other than that of individual or public (i.e., a data object cannot be owned by two users and restricted from other users). Also, the ownership of an object implies read/write/modify/execute access to the object, which means full access rights to the object. Unrestricted Chrysalis-I18 7 Overview — LunaCA3 Security Policies Document #802509 V1.20 6. MofN Activation LunaCA’ 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 LunaCA” 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. 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. 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. 7. Object Reuse The token enforces an object reuse policy in that every object is allocated a portion of memory (flash or SRAM). The policy also ensures that no other objects are placed in the same memory location unless all previous memory content are initialized and purged. When cryptographic functions are performed, a cryptographic context is created to hold data required by the function (e.g., a DES key schedule for a DES function or an MDS chaining vector). The cryptographic context only exists in SRAM memory and is not assigned to any functions except those defined by its owner. The memory assigned to a cryptographic context is always purged of its content before being handed over to a function. 8. References [FIPS 140-1] FIPS PUB 140-1: Security Requirements for Cryptographic Modules, Federal Information of Processing Standards Publication, U.S. Department of Commerce and National Institute of Standards and Technology, 1994 January 11. [PKCS#1 1] PKCS #11: Cryptographic Token Interface Standard, RSA Laboratories, Draft 1, version 2.01, September 12,1997. 9. Notes Datakey is a registered trademark of Datakey, Inc. Unrestricted Ehrysalis-IT5 8