LEVEL 3 NON-PROPRIETARY SECURITY POLICY FOR

Transcription

1 LEVEL 3 NON-PROPRIETARY SECURITY POLICY FOR Luna PCI-E Cryptgraphic Mdule and Luna PCI-E Cryptgraphic Mdule fr Luna SA (Used as a Standalne Device that includes cnfiguratins Clning [CL] and Key Exprt [CKE]; and as an Embedded Device in Luna SA that includes cnfiguratins Clning [CL], Signing N Clning [SNC], and Key Exprt [CKE]) DOCUMENT NUMBER: CR-3397 REVISION LEVEL: 21 REVISION DATE: Nvember 16, 2015 SECURITY LEVEL: Nn-prprietary Cpyright SafeNet, Inc. ALL RIGHTS RESERVED This dcument may be freely reprduced and distributed whle and intact including this cpyright ntice. SafeNet, Inc. reserves the right t make changes in the prduct r its specificatins mentined in this publicatin withut ntice. Accrdingly, the reader is cautined t verify that infrmatin in this publicatin is current befre placing rders. The infrmatin furnished by SafeNet, Inc. in this dcument is believed t be accurate and reliable. Hwever, n respnsibility is assumed by SafeNet, Inc. fr its use, r fr any infringements f patents r ther rights f third parties resulting frm its use. Dcument is uncntrlled when printed.

2 PREFACE This dcument deals nly with peratins and capabilities f the Luna PCI-E Cryptgraphic Mdule and Luna PCI-E Cryptgraphic Mdule fr Luna SA in the technical terms f a FIPS cryptgraphic mdule security plicy. Mre infrmatin is available n the Luna PCI-E and ther SafeNet prducts frm the fllwing surces: The SafeNet internet site cntains infrmatin n the full line f security prducts at Fr answers t technical r sales related questins please refer t the cntacts listed belw r n the SafeNet internet site at SafeNet Cntact Infrmatin: SafeNet, Inc. (Crprate Headquarters) SafeNet Canada, Inc Millennium Drive Belcamp, MD Telephne: TTY Users: Fax: Clnnade Rad Suite 200 Ottawa, Ontari K2E 7M6 Telephne: Fax: SafeNet Sales: SafeNet Technical Supprt: U.S Internatinal SafeNet Custmer Service: U.S EMEA +44 (0) APAC Page 2 f 46

3 TABLE OF CONTENTS Sectin Title Page 1. INTRODUCTION Purpse Scpe Overview SECURITY POLICY MODEL INTRODUCTION Functinal Overview Assets t be Prtected Operating Envirnment SECURITY POLICY MODEL DESCRIPTION Operatinal Plicy Mdule Capabilities Partitin Capabilities FIPS-Apprved Mde Descriptin f Operatr, Subject and Object Operatr Rles Accunt Data Subject Operatr Subject Binding Object Object Operatins Identificatin and Authenticatin Authenticatin Data Generatin and Entry Trusted Path Remte PED Operatin M f N Authenticatin Limits n Lgin Failures Access Cntrl Object Prtectin Object Re-use Privileged Functins Cryptgraphic Material Management Page 3 f 46

4 3.6.1 Key Clning Key Mask / Unmask Key Wrap / Unwrap Cryptgraphic Operatins Self-tests Firmware Security Physical Security Secure Recvery EMI / EMC Fault Tlerance Mitigatin f Other Attacks LIST OF TABLES Table Title Page Table 1-1. FIPS Security Requirements... 7 Table 3-1. Mdule Capabilities and Plicies Table 3-2. Partitin Capabilities and Plicies Table 3-3. Object Attributes Used in Access Cntrl Plicy Enfrcement Table 3-4. Apprved Security Functins fr SafeXcel Table 3-5. Apprved Security Functins fr SafeXcel Table 3-6. Apprved Security Functins Firmware Implementatin Table 3-7. Allwed Security Functin fr the Firmware Implementatin Table 3-8. Nn-FIPS Apprved Security Functins Table 3-9. Mdule Self-Tests Table A-1. Rles and Required Identificatin and Authenticatin Table A-2. Strengths f Authenticatin Mechanisms Table A-3. Services Authrized fr Rles Table A-4. Access Rights within Services Table A-5 Keys and Critical Security Parameters Used in the Mdule Page 4 f 46

5 LIST OF FIGURES Figure Title Page Figure 2-1. Luna PCI-E Cryptgraphic Mdule... 8 Figure 2-2. Luna SA (with PCI-E Installed), Luna PED and ikeys... 8 LIST OF APPENDICES Appendix Title Page APPENDIX A. SECURITY POLICY CHECKLIST TABLES APPENDIX B. LIST OF TERMS, ABBREVIATIONS AND ACRONYMS Page 5 f 46

6 1. INTRODUCTION 1.1 Purpse This dcument describes the security plicies enfrced by SafeNet Inc. s Luna PCI-E Cryptgraphic Mdule and Luna PCI-E Cryptgraphic Mdule fr Luna SA 1. The Luna PCI-E cryptgraphic mdule can be used as fllws: A standalne device, which includes the fllwing cnfiguratins: Clning [CL]; and Key Exprt [CKE]; r An embedded device in Luna SA, which includes the fllwing cnfiguratins: Clning [CL], Signing N Clning [SNC], and Key Exprt [CKE]) This dcument applies t Hardware Versin VBD-05, Versin Cde 0100; Hardware Versin VBD-05, Versin Cde 0101; Hardware Versin VBD-05, Versin Cde 0102; and Hardware Versin VBD-05, Versin Cde with Firmware Versins , , and Scpe The security plicies described in this dcument apply t the Trusted Path Authenticatin (Level 3) cnfiguratin f the Luna PCI-E cryptgraphic mdule nly and d nt include any security plicy that may be enfrced by the hst appliance r server. 1 Als knwn as the K6 r the cryptgraphic mdule. 2 The Hardware Versin may als be displayed as VBD , VBD , VBD , r VBD Bth types f displays represent the equivalent Hardware Versins f the Luna PCI-E cryptgraphic mdule. 3 Frm the perspectives f functinality and physical security, Hardware Versin VBD-05, Versin Cde 0100 (r VBD ); Hardware Versin VBD-05, Versin Cde 0101 (r VBD ); Hardware Versin VBD-05, Versin Cde 0102 (r VBD ); and Hardware Versin VBD-05, Versin Cde 0103 (r VBD ) are equivalent. Page 6 f 46

7 1.3 Overview The cryptgraphic mdule meets all level 3 requirements fr FIPS as summarized in Table 1-1. Table 1-1. FIPS Security Requirements Security Requirements Sectin Level Cryptgraphic Mdule Specificatin 3 Cryptgraphic Mdule Prts and Interfaces 3 Rles and Services and Authenticatin 3 Finite State Machine Mdel 3 Physical Security 3 Operatinal Envirnment Cryptgraphic Key Management 3 EMI/EMC 3 Self-Tests 3 Design Assurance 3 Mitigatin f Other Attacks 3 Cryptgraphic Mdule Security Plicy 3 2. SECURITY POLICY MODEL INTRODUCTION 2.1 Functinal Overview The Luna PCI-E cryptgraphic mdule is a multi-chip embedded hardware cryptgraphic mdule in the frm f a PCI-Express card that typically resides within a custm cmputing r secure cmmunicatins appliance. The cryptgraphic mdule is cntained in its wn secure enclsure that prvides physical resistance t tampering. The cryptgraphic bundary f the mdule is defined t encmpass all cmpnents inside the secure enclsure n the PCI-E card. Figure 2-1 depicts the Luna PCI-E cryptgraphic mdule and Figure 2-2 depicts the Luna SA appliance, with the Luna PCI-E mdule installed, shwing the PED and ikeys used fr authenticatin. A mdule may be explicitly cnfigured t perate in either FIPS Level 2 r FIPS Level 3 mde, r in a nn-fips mde f peratin. Cnfiguratin in either FIPS mde enfrces the use f FIPS-apprved algrithms nly. Cnfiguratin in FIPS Level 3 mde als enfrces the use f trusted path authenticatin. Nte that selectin f FIPS mde ccurs at initializatin f the cryptgraphic mdule, and cannt be changed during nrmal peratin withut zerizing the mdule s nn-vlatile memry. A cryptgraphic mdule is accessed directly (i.e., electrically) via either the Trusted Path PIN Entry Device (PED) serial interface r via the PCI-Express cmmunicatins interface. A mdule prvides secure key generatin and strage fr symmetric keys and asymmetric key pairs alng with symmetric and asymmetric cryptgraphic services. Access t key material and cryptgraphic services fr users and user applicatin sftware is prvided thrugh the PKCS #11 prgramming interface. A mdule may hst multiple user definitins r partitins that are cryptgraphically separated and are presented as virtual tkens t user applicatins. Each partitin must be separately authenticated in rder t make it available fr use. This Security Plicy is specifically written fr the Luna PCI-E cryptgraphic mdule in a Trusted Path Authenticatin (FIPS Level 3) cnfiguratin. Page 7 f 46

8 Cryptgraphic Bundary Figure 2-1. Luna PCI-E Cryptgraphic Mdule Figure 2-2. Luna SA (with PCI-E Installed), Luna PED and ikeys Page 8 f 46

9 2.2 Assets t be Prtected The mdule is designed t prtect the fllwing assets: 1. User-generated private keys, 2. User-generated secret keys, 3. Cryptgraphic services, and 4. Mdule security critical parameters. 2.3 Operating Envirnment The mdule is assumed t perate as a key management and cryptgraphic prcessing card within a security appliance that may perate in a TCP/IP netwrk envirnment. The hst appliance may be used in an internal netwrk envirnment when key management security is a primary requirement. It may als be deplyed in envirnments where it is used primarily as a cryptgraphic acceleratr, in which case it will ften be cnnected t external netwrks. It is assumed that the appliance includes an internal hst cmputer that runs a suitably secured perating system, with an interface fr use by lcally cnnected r remte administratrs and an interface t prvide access t the mdule s cryptgraphic functins by applicatin services running n the hst cmputer. It is als assumed that nly knwn versins f the applicatin services are permitted t run n the internal hst cmputer f the appliance. It is assumed that trained and trustwrthy administratrs are respnsible fr the initial cnfiguratin and nging maintenance f the appliance and the cryptgraphic mdule. It is assumed that physical access t the cryptgraphic mdule will be cntrlled, and that cnnectins will be cntrlled either by accessing the mdule via a direct lcal cnnectin r by accessing it via remte cnnectins cntrlled by the hst perating system and applicatin service. The cryptgraphic mdule is designed t perate between 0 and 60 degrees Celsius. 3. SECURITY POLICY MODEL DESCRIPTION This sectin prvides a narrative descriptin f the security plicy enfrced by the mdule in its mst general frm. It is intended bth t state the security plicy enfrced by the mdule and t give the reader an verall understanding f the security behaviur f the mdule. The detailed functinal specificatin fr the mdule is prvided elsewhere. The security behaviur f the cryptgraphic mdule is gverned by the fllwing security plicies: Operatinal Plicy Identificatin and Authenticatin Plicy Access Cntrl Plicy Cryptgraphic Material Management Plicy Firmware Security Plicy Physical Security Plicy These plicies cmplement each ther t prvide assurance that cryptgraphic material is securely managed thrughut its life cycle and that access t ther data and functins prvided by the prduct is prperly cntrlled. Cnfigurable parameters that determine many f the variable aspects f the mdule s behaviur are specified by the higher level Operatinal Plicy implemented at tw levels: the cryptgraphic mdule as a whle and the individual partitin. This is described in sectin 3.1. Page 9 f 46

10 The Identificatin and Authenticatin plicy is crucial fr security enfrcement and it is described in sectin 3.4. The access cntrl plicy is the main security functinal plicy enfrced by the mdule and is described in sectin 3.5, which als describes the supprting bject re-use plicy. Cryptgraphic Material Management is described in sectin 3.6. Firmware security, physical security and fault tlerance are described in sectins 3.8 thrugh Operatinal Plicy The mdule emplys the cncept f the Operatinal Plicy t cntrl the verall behaviur f the mdule and each f the partitins within. At each level, either the mdule r the partitin is assigned a fixed set f capabilities that gvern the allwed behaviur f the mdule r individual partitin. The Security Officer (SO) establishes the Operatinal Plicy by enabling/disabling r refining the crrespnding plicy elements t equate t r t be mre restrictive than the pre-assigned capabilities. The set f cnfigurable plicy elements is a prper subset f the crrespnding capability set. That is, nt all elements f the capability set can be refined. Which f the capability set elements have crrespnding plicy set elements is pre-determined based n the persnality f the partitin r manufacturing restrictins placed n the mdule. Fr example, the mdule capability setting fr dmestic algrithms and key sizes available des nt have a crrespnding cnfigurable plicy element. There are als several fixed settings that d nt have crrespnding capability set elements. These are elements f the cryptgraphic mdule s behaviur that are truly fixed and, therefre, are nt subject t cnfiguratin by the SO. The specific settings 4 are the fllwing: Allw/disallw nn-sensitive secret keys fixed as disallw. Allw/disallw nn-sensitive private keys fixed as disallw. Allw/disallw nn-private secret keys fixed as disallw. Allw/disallw nn-private private keys fixed as disallw. Allw/disallw secret key creatin thrugh the create bjects interface fixed as disallw. Allw/disallw private key creatin thrugh the create bjects interface fixed as disallw. Further, plicy set elements can nly refine capability set elements t mre restrictive values. Even if an element f the plicy set exists t refine an element f the capability set, it may nt be pssible t assign the plicy set element t a value ther than that held by the capability set element. Specifically, if a capability set element is set t allw, the crrespnding plicy element may be set t either enable r disable. Hwever, if a capability set element is set t disallw, the crrespnding plicy element can nly be set t disable. Thus, an SO cannt use plicy refinement t lift a restrictin set in a capability definitin Mdule Capabilities The fllwing is the set f capabilities supprted at the mdule level: Allw/disallw nn-fips algrithms available. Allw/disallw trusted path authenticatin (allwed and must be enabled in Level 3 cnfiguratin). Allw/disallw partitin grups. 4 The nmenclature used fr these setting is based n PKCS#11. Page 10 f 46

11 Allw/disallw clning. Allw/disallw masking 5. Allw/disallw unmasking. Allw/disallw Krean algrithms 6 Allw/disallw SO reset f partitin PIN. Allw/disallw netwrk replicatin (set t disallw). Allw/disallw frcing change f User authenticatin data. Allw/disallw Remte PED (RPED) peratins. Allw/disallw external Master Tamper Key (MTK) split strage Allw/disallw Acceleratin Allw/disallw High Assurance (HA) mde CGX Partitin Capabilities The fllwing is the set f capabilities supprted at the partitin level. All capability elements described as allw/disallw sme functinality are Blean values where false (r 0 ) equates t disallw the functinality and true (r 1 ) equates t allw the functinality. The remainder f the elements are integer values f the indicated number f bits. Allw/disallw changing f certain key attributes nce a key has been created. Allw/disallw user key management capability. (This wuld be disabled by the SO at the plicy level t prevent any key management activity in the partitin, even by a user in the Crypt Officer rle. This culd be used, fr example, at a CA nce the rt signing key pair has been generated and backed up, if apprpriate, t lck dwn the partitin fr signing use nly.) Allw/disallw incrementing f failed lgin attempt cunter n failed challenge respnse validatin. Allw/disallw Level 3 peratin withut a challenge Allw/disallw activatin. Allw/disallw autmatic activatin. Allw/disallw High Availability. Allw/disallw multipurpse keys. Allw/disallw peratin withut RSA blinding. Allw/disallw signing peratins with nn-lcal keys. Allw/disallw raw RSA peratins. Allw/disallw private key wrapping Allw/disallw private key unwrapping. Allw/disallw secret key wrapping Allw/disallw secret key unwrapping 5 A SafeNet term used t describe the encryptin f a key fr use nly within a SafeNet cryptgraphic mdule. 6 Krean algrithms include SEED, ARIA, and KCDSA. Page 11 f 46

12 Allw/disallw RSA signing withut cnfirmatin Number f failed Partitin User lgins allwed befre partitin is lcked ut/cleared (default is 10; SO can cnfigure it t be 3 <= N <= 10) The fllwing capabilities are cnfigurable nly if the crrespnding capability/plicy is allwed and enabled at the mdule level: Allw/disallw private key clning. Allw/disallw secret key clning. Allw/disallw private key masking 7. Allw/disallw secret key masking. Allw/disallw private key unmasking. Allw/disallw secret key unmasking. The fllwing tables summarize the mdule and partitin capabilities, shwing typical capability settings fr Luna PCI-E cryptgraphic mdules used in the fllwing cnfiguratins: Luna PCI-E prduct cnfiguratins: Key Exprt (CKE), and Clning (CL); and Luna SA prduct cnfiguratins: Key Exprt (CKE), Clning (CL), and Signing N Clning (SNC). An X indicates the default capability setting fr each cnfiguratin f the mdule. Greyed-ut rws indicate that the crrespnding capability setting is nt used as a default fr any mdule cnfiguratin. Table 3-1. Mdule Capabilities and Plicies Descriptin Capability CKE CL SNC Plicy Cmments Nn-FIPS algrithms available Passwrd authenticatin Trusted path authenticatin Allw X X X Disallw Allw Disallw X X X Allw X X X Disallw SO can cnfigure the plicy t enable r disable the availability f nn-fips algrithms at the time the cryptgraphic mdule is initialized. The cryptgraphic mdule must perate using FIPS-apprved algrithms nly. Must be disabled in FIPS mde SO can cnfigure the plicy t enable r disable the use f passwrds withut trusted path fr authenticatin. The cryptgraphic mdule must perate using the trusted path and mdule-generated secrets fr authenticatin. SO can cnfigure the plicy t enable r disable the use f the trusted path and mdule-generated secrets fr authenticatin. The cryptgraphic mdule must perate using passwrds withut trusted path fr authenticatin. 8 7 Masking is perfrmed using a FIPS-apprved encryptin algrithm with a key that is held nly by the cryptgraphic mdule. 8 One and nly ne means f authenticatin ( user passwrd r trusted path ) must be enabled by the plicy. Therefre, ne f the authenticatin capabilities must be allwed and, if ne f the capabilities is disallwed r the plicy setting disabled, then the plicy setting fr the ther must be enabled. Page 12 f 46

13 Descriptin Capability CKE CL SNC Plicy Cmments Remte PED Operatins Clning Masking Unmasking Krean algrithms 10 Partitin reset Netwrk Replicatin Frce user PIN change External MTK split strage Acceleratin HA CGX Mde Allw X X X Disallw Allw X X The cryptgraphic mdule can use Remte PED fr Trusted Path authenticatin. 9 Allwed in Trusted Path authenticatin nly. The cryptgraphic mdule cannt use remte PED fr Trusted Path authenticatin. SO can cnfigure the plicy t enable r disable the availability f the clning functin fr the cryptgraphic mdule as a whle. Disallw X The cryptgraphic mdule must perate withut clning. Allw SO can cnfigure the plicy t enable r disable the availability f the masking functin fr the cryptgraphic mdule as a whle. Disallw X X X The cryptgraphic mdule must perate withut masking. Allw X X X SO can cnfigure the plicy t enable r disable the availability f the unmasking functin fr the cryptgraphic mdule as a whle. Disallw The cryptgraphic mdule must perate withut unmasking. Allw Disallw X X X Allw X X X Disallw Allw X SO can cnfigure the plicy t enable r disable the availability f Krean algrithms fr the cryptgraphic mdule as a whle. The cryptgraphic mdule must perate withut Krean algrithms. SO can cnfigure the plicy t enable a partitin t be reset if it is lcked as a result f exceeding the maximum number f failed lgin attempts. A partitin cannt be reset and must be re-created as a result f exceeding the maximum number f failed lgin attempts. SO can cnfigure the plicy t enable the replicatin f the mdule s key material ver the netwrk t a secnd mdule. Disallw X X The mdule cannt be replicated ver the netwrk. Allw X X X This capability is set prir t shipment t the custmer. If enabled, it frces the user t change the PIN upn first lgin. Disallw The user is never frced t change PIN n first lgin. Allw X X X This capability is set prir t shipment t the custmer. It allws the use f external strage f the MTK split. Disallw External MTK split strage cannt be enabled fr the mdule. Allw X X X This capability is set prir t shipment t the custmer. It allws the use f the nbard crypt acceleratr. Disallw Remte authenticatin cannt be enabled fr the mdule. Allw This capability is set prir t shipment t the custmer. It allws the use f the HA CGX mde. Disallw X X X HA CGX mde cannt be enabled fr the mdule. 9 d in the Trusted Path cnfiguratin. Operatr can cnnect the cryptgraphic mdule t a Remte PED using Cmmand Line Interface (CLI) cmmands. 10 Krean algrithms are nly available upn custmer request. Page 13 f 46

14 Table 3-2. Partitin Capabilities and Plicies Descriptin Prerequisite Capability KE CL NC Plicy Cmments Trusted Path peratin withut a challenge User key management capability 11 Cunt failed challengerespnse validatins Activatin Trusted path authenticatin enabled Trusted path authenticatin enabled, Trusted Path peratin withut a challenge disabled Trusted path authenticatin enabled Trusted path authenticatin enabled Allw X X X Disallw Allw X X X SO can cnfigure the plicy t enable Trusted Path lgin using the PED trusted path nly, with n challenge-respnse validatin required. Must be disabled if either activatin r aut-activatin is enabled Challenge-respnse validatin required plus PED trusted path lgin t access the partitin. SO can cnfigure the plicy t enable the nrmal PKCS #11 user rle t perfrm key management functins. If enabled, the Crypt Officer key management functins are available. If disabled, nly the Crypt User rle functins are accessible. Disallw Only the Crypt User rle functins are accessible. Allw X X X Disallw Allw X X X Disallw SO can cnfigure the plicy t cunt failures f the challenge-respnse validatin against the maximum lgin failures r nt. Must be enabled if either activatin r aut-activatin is enabled Failures f the challenge-respnse validatin are nt cunted against the maximum lgin failures. SO can cnfigure the plicy t enable the authenticatin data prvided via the PED trusted path t be cached in the mdule, allwing all subsequent access t the partitin, after the first lgin, t be dne n the basis f challenge-respnse validatin alne. PED trusted path authenticatin is required fr every access t the partitin. 11 This capability/plicy is intended t ffer custmers a greater level f cntrl ver key management functins. By disabling the plicy, the Security Officer places the partitin int a state in which the key material is lcked dwn and can nly be used by cnnected applicatins, i.e., nly Crypt User access is pssible. Page 14 f 46

15 Descriptin Prerequisite Capability KE CL NC Plicy Cmments Aut-activatin High Availability Multipurpse keys Change attributes Operate withut RSA blinding Signing with nn-lcal keys Raw RSA peratins Trusted path authenticatin enabled Allw X X X SO can cnfigure the plicy t enable the activatin data t be stred n the appliance server in encrypted frm, allwing the partitin t resume its authenticatin state after a re-start. This is intended primarily t allw partitins t autmatically re-start peratin when the appliance returns frm a pwer utage. Disallw Activatin data cannt be externally cached. Allw X X SO can cnfigure the plicy t enable the use f the High Availability feature. Disallw X High Availability cannt be enabled. Allw X X X SO can cnfigure the plicy t enable the use f keys fr mre than ne purpse, e.g., an RSA private key culd be used fr digital signature and fr decryptin fr key transprt purpses. Disallw Keys can nly be used fr a single purpse. Allw X X X SO can cnfigure the plicy t enable changing key attributes. Disallw Key attributes cannt be changed. Allw X X X SO can cnfigure the use f blinding mde fr RSA peratins. Blinding mde is used t defeat timing analysis attacks n RSA digital signature peratins, but it als impses a significant perfrmance penalty n the signature peratins. Disallw Blinding mde is nt used fr RSA peratins. Allw X X X Disallw Allw X X X SO can cnfigure the ability t sign with externallygenerated private keys that have been imprted int the partitin. Externally-generated private keys cannt be used fr signature peratins. SO can cnfigure the ability t use raw (n padding) frmat fr RSA encrypt/decrypt peratins fr key transprt purpses. Disallw Raw RSA cannt be used. Page 15 f 46

16 Descriptin Prerequisite Capability KE CL NC Plicy Cmments Private key wrapping Private key unwrapping Secret key wrapping Secret key unwrapping Private key clning Secret key clning Private key masking Secret key masking Clning enabled, Trusted path authenticatin enabled Clning enabled, Trusted path authenticatin enabled Masking enabled Masking enabled Allw X Disallw X X Allw X X X Disallw Allw X X X Disallw Allw X X X Disallw Allw X SO can cnfigure the ability t wrap private keys fr exprt. Private keys cannt be wrapped and exprted frm the partitin. SO can cnfigure the ability t unwrap private keys and imprt them int the partitin. Private keys cannt be unwrapped and imprted int the partitin. SO can cnfigure the ability t wrap secret keys and exprt them frm the partitin. Secret keys cannt be wrapped and exprted frm the partitin. SO can cnfigure the ability t unwrap secret keys and imprt them int the partitin. Secret keys cannt be unwrapped and imprted int the partitin. SO can cnfigure the ability t clne private keys frm ne mdule and partitin t anther. Disallw X X Private keys cannt be clned. Allw X X X SO can cnfigure the ability t clne secret keys frm ne mdule and partitin t anther. Disallw Secret keys cannt be clned. Allw Disallw X X X Allw Disallw X X X SO can cnfigure the ability t mask private keys fr strage utside the partitin. Private keys cannt be masked fr strage utside the partitin. SO can cnfigure the ability t mask secret keys fr strage utside the partitin. Secret keys cannt be masked fr strage utside the partitin. Page 16 f 46

17 Descriptin Prerequisite Capability KE CL NC Plicy Cmments Private key unmasking Secret key unmasking Minimum / maximum passwrd length Number f failed Partitin User lgins allwed Secret key clning enabled Secret key clning enabled User passwrd authenticatin enabled Allw X X X This setting allws unmasking f private keys. Disallw Private keys cannt be unmasked Allw X X X This setting allws unmasking f secret keys. Disallw Secret keys cannt be unmasked 7-16 characters Cnfigurable Minimum:1, Maximum:10 Cnfigurable The SO can cnfigure the minimum passwrd length fr Level 2 mdules, but minimum length must always be >= 7. The SO can cnfigure; default maximum value is 10. Page 17 f 46

18 3.2 FIPS-Apprved Mde The SO cntrls peratin f a mdule in FIPS-apprved mde, as defined by FIPS PUB 140-2, by enabling r disabling the apprpriate Mdule Plicy settings (assuming each is allwed at the Mdule Capability level). T perate in FIPS-apprved mde, the fllwing plicy settings are required: Nn-FIPS Algrithms Available must be disabled. Additinally, fr peratin at FIPS Level 3: Trusted path authenticatin must be enabled (implies that passwrd authenticatin is disallwed r disabled), and Trusted Path peratin withut a challenge must be disabled if activatin r autactivatin is enabled. Cunt failed challenge respnse validatins must be enabled if activatin r aut-activatin is enabled. Raw RSA peratins can nly be used fr key transprt in FIPS mde The plicy settings fr Trusted path authenticatin may als be cnfigured in the case where Nn-FIPS Algrithms Available has been enabled. If the SO selects plicy ptins (i.e., enables Nn-FIPS Algrithms Available ) that wuld place a mdule in a mde f peratin that is nt apprved, a warning is displayed and the SO is prmpted t cnfirm the selectin. The SO can cnfirm that the cryptgraphic mdule is in FIPS mde by utilizing the hsm shwinf cmmand. With this cmmand, the fllwing message will be displayed, The HSM is in FIPS apprved peratin mde. 3.3 Descriptin f Operatr, Subject and Object Operatr An peratr is defined as an entity that acts t perfrm an peratin n a mdule. An peratr may be directly mapped t a respnsible individual r rganizatin, r it may be mapped t a cmpsite f a respnsible individual r rganizatin plus an agent (applicatin prgram) acting n behalf f the respnsible individual r rganizatin. In the case f a Certificatin Authrity (CA), fr example, the rganizatin may empwer ne individual r a small grup f individuals acting tgether t perate a cryptgraphic mdule as part f the cmpany s service. The peratr might be that individual r grup, particularly if they are interacting with a mdule lcally. The peratr might als be the cmpsite f the individual r grup, wh might still be present lcally t a mdule (particularly fr activatin purpses, see sectin 3.4.2), plus the CA applicatin running n a netwrk-attached hst cmputer Rles Page 18 f 46

19 In the Trusted Path Authenticatin cnfiguratin, the Luna cryptgraphic mdule supprts the fllwing authenticated peratr rles: the Security Officer (SO) and Audit Officer 12 at the mdule level plus Partitin Users 13 (als knwn by sub-rles Crypt Officer and Crypt User) fr each Partitin. The cryptgraphic mdule als supprts ne unauthenticated peratr rle, the Public User, primarily t permit access t status infrmatin and diagnstics befre authenticatin. The SO is a privileged rle, which exists nly at the mdule level, whse primary purpse is t initially cnfigure a mdule fr peratin and t perfrm security administratin tasks such as partitin creatin. The Audit Officer is a privileged rle, which exists nly at the mdule level t initialize, cnfigure, and manage secure audit lgging. Only the Audit Officer can initialize, cnfigure and manage the secure audit lgging feature. This allws fr a separatin f duties between an Audit Officer and the ther rles (e.g., SO, crypt fficer, and crypt user) that the Audit Officer is auditing preventing administrative and user persnnel frm tampering with the lg files and preventing the Audit Officer frm perfrming administrative tasks r frm accessing keys. The Crypt Officer is the key management rle fr each partitin. The Crypt User is an ptinal read-nly rle that limits the peratr t perfrming cryptgraphic peratins nly. Fr an peratr t assume any rle ther than Public User, the peratr must be identified and authenticated. The fllwing cnditins must hld in rder t assume ne f the authenticated rles: N peratr can assume the Audit Officer, Crypt Officer, Crypt User r Security Officer rle befre identificatin and authenticatin; N identity can assume mre than ne authenticated rle at the same time, e.g., Crypt Officer r Crypt User, plus the Security Officer rle, r Audit Officer, plus Security Officer. The SO can create the Crypt User rle by creating a challenge value fr the Crypt User. In the case f a partitin that supprts the Crypt Officer and Crypt User rles, the Security Officer can limit access t nly the Crypt User rle by disabling the User Key Management (see Table 3-1) plicy. Fr additinal infrmatin regarding rles and authrized services, please refer t Table A-1 and Table A Accunt Data 12 Within the cnfines f the peratinal use f the Luna cryptgraphic mdule, the FIPS term f Crypt Officer encmpasses the Luna cryptgraphic mdule rles f Security Officer and Audit Officer. 13 Within the cnfines f the peratinal use f the Luna cryptgraphic mdule, the FIPS term f User encmpasses the Luna cryptgraphic mdule rles f crypt user and crypt fficer, which are cllectively called the Partitin Users. Page 19 f 46

20 The mdule maintains the fllwing User (which can include bth the Crypt Officer and Crypt User rle per Partitin 14 ) and SO accunt data: Partitin ID r SO ID number. Partitin User encrypted r SO encrypted authenticatin data (checkwrd). Partitin User authenticatin challenge secret (ne fr each rle, as applicable). Partitin User lcked ut flag. An authenticated User is referred t as a Partitin User. The ability t manipulate the accunt data is restricted t the SO and the Partitin User. The specific restrictins are as described belw: 1. Only the Security Officer rle can create (initialize) and delete the fllwing security attributes: Partitin ID. Checkwrd. 2. If Partitin reset is allwed and enabled, the SO rle nly can mdify the fllwing security attribute: Lcked ut flag fr Partitin User. 3. Only the Partitin User can mdify the fllwing security attribute: Checkwrd fr Partitin User. 4. Only the Security Officer rle can change the default value, query, mdify and delete the fllwing security attribute: Checkwrd fr Security Officer Subject Fr the purpses f this security plicy, the subject is defined t be a mdule sessin. The sessin prvides a lgical means f mapping between applicatins cnnecting t a mdule and the prcessing f cmmands within a mdule. Each sessin is tracked by the Sessin ID, the Partitin ID and the Access ID, which is a unique ID assciated with the applicatin s cnnectin. It is pssible t have multiple pen sessins with a mdule assciated with the same Access ID/Partitin ID cmbinatin. It is als pssible fr a mdule t have sessins pened fr mre than ne Partitin ID r have multiple Access IDs with sessins pened n a mdule. Applicatins running n remte hst systems that require data and cryptgraphic services frm a mdule must first cnnect via the cmmunicatins service within the appliance, which will establish the unique Access ID fr the cnnectin and then allw the applicatin t pen a sessin with ne f the partitins within a mdule. A lcal applicatin (e.g., cmmand line administratin interface) will pen a sessin directly with the apprpriate partitin within a mdule withut invking the cmmunicatins service Operatr Subject Binding An peratr must access a partitin thrugh a sessin. A sessin is pened with a partitin in an unauthenticated state and the peratr must be authenticated befre any access t cryptgraphic functins and Private bjects within the partitin can be granted. Once the peratr is successfully identified and authenticated, the sessin state becmes authenticated and is bund t the Partitin User represented by the Partitin ID, in the Crypt Officer r Crypt User rle. Any ther sessins pened with the same Access ID/Partitin ID cmbinatin will share the same authenticatin state and be bund t the same Partitin User Object 14 A Partitin effectively represents an identity within the mdule. Page 20 f 46

21 An bject is defined t be any frmatted data held in vlatile r nn-vlatile memry n behalf f an peratr. Fr the purpses f this security plicy, the bjects f primary cncern are private (asymmetric) keys and secret (symmetric) keys Object Operatins Object peratins may nly be perfrmed by a Partitin User. The peratins that may be perfrmed are limited by the rle (Crypt Officer r Crypt User) assciated with the user s lgin state, see sectin 3.5. New bjects can be made in several ways. The fllwing list identifies peratins that prduce new bjects: Create, Cpy, Generate, Unwrapping, Derive. Existing bjects can be mdified and deleted. The values f a subset f attributes can be changed thrugh a mdificatin peratin. Objects can be deleted thrugh a destructin peratin. Cnstant peratins d nt cause creatin, mdificatin r deletin f an bject. These cnstant peratins include: Query an bject s size; Query the size f an attribute; Query the value f an attribute; Use the value f an attribute in a cryptgraphic peratin; Search fr bjects based n matching attributes; Clning an bject; Wrapping an bject; and Masking and unmasking an bject. Secret keys and private keys are always maintained as Sensitive bjects and, therefre, they are permanently stred with the key value encrypted t prtect its cnfidentiality. Key bjects held in vlatile memry d nt have their key values encrypted, but they are subject t active zerizatin in the event f a mdule reset r in respnse t a tamper event. Fr additinal infrmatin abut the clearing f sensitive data, see Sectin Operatrs are nt given direct access t key values fr any purpse. 3.4 Identificatin and Authenticatin Authenticatin Data Generatin and Entry The mdule requires that Partitin Users, the Audit Officer and the SO be authenticated by prving knwledge f a secret shared by the peratr and the mdule. A mdule cnfigured fr Trusted Path Authenticatin must be initialized using the PED t define the SO authenticatin data. Fr Trusted Path Authenticatin, a mdule generates the authenticatin secret as a 48-byte randm value and, ptinally fr a Partitin User, an authenticatin challenge secret. The authenticatin secret(s) are prvided t the peratr via a physically separate trusted path, described in sub-sectin 3.4.2, and must be entered by the peratr via the trusted path and via a lgically separate trusted channel (in the case f the respnse based n the challenge secret) during the lgin prcess. If a Partitin is created with Crypt Officer and Crypt User rles, a separate challenge secret is generated fr each rle. Page 21 f 46

22 The fllwing types f ikey are used with the Luna PED: Orange (RPV) ikey fr the strage f the Remte PED Vectr (RPV), Blue (SO) ikey fr the strage f SO authenticatin data, Black (User) ikey fr the strage f User authenticatin data, Red (Dmain) ikey fr the strage f the clning dmain data, used t cntrl the ability t clne frm a cryptgraphic mdule t a backup mdule, Purple (MTK Recvery) ikey fr the strage f an external split that allws the MTK t be restred after a tamper event. White (Audit Officer) ikey fr the strage f Audit Officer authenticatin data Any ikey, nce data has been written t it, is an Identificatin and Authenticatin device and must be safeguarded accrdingly by the administrative r peratins staff respnsible fr the peratin f the mdule within the custmer s envirnment Trusted Path In Trusted Path mde, user authenticatin is, by default, a tw-stage prcess. The first stage is termed Activatin and is perfrmed using a trusted path device (PED) which cnnects t the cryptgraphic mdule either directly ver a physical wire r remtely ver a secure netwrk cnnectin. The primary frm f authenticatin data used during Activatin is the 48-byte value that is randmly generated by a mdule and stred n the Black (User) ikey 15 via the trusted path. The data n the ikey must then be entered int a mdule via the trusted path as part f each Activatin prcess. Once Activatin has been perfrmed, the user s Partitin data is ready fr use within a mdule. Access t key material and cryptgraphic services, hwever, is nt allwed until the secnd stage f authenticatin, User Lgin, has been perfrmed. This typically requires the input f a partitin s challenge secret as part f a lgin peratin. Hwever, fr SO authenticatin and fr user authenticatin when the settings f the Partitin Plicy disable the use f challenge/respnse authenticatin fr lgin t a partitin 16, the presentatin f the ikey data (i.e., equivalent t Activatin) is all that is required t cmplete authenticatin. The default Partitin Plicy enables the use f challenge/respnse authenticatin fr the User Lgin stage. The authenticatin challenge secret (r secrets if the Crypt Officer and Crypt User rles are used) fr the partitin is generated by the mdule as a 75-bit value that is displayed as a 16-character alphanumeric string n the visual display f the trusted path device. The challenge secret is then prvided, via a secure ut-f-band means, t each external entity authrized t cnnect t the partitin and is used by the external entity t frm the respnse t a randm ne-time challenge frm a mdule. The encrypted ne-time respnse is returned t the cryptgraphic mdule where it is verified t cnfirm the User Lgin. Thus, when the challenge secret is required, bth the trusted path Activatin and the successful cmpletin f the challenge/respnse prcess by the external entity is required t authenticate t a partitin and have access t its cryptgraphic material and functins Remte PED Operatin The user has the ptin f perating the PED in the cnventinal manner (i.e., lcally 15 Or Black (User) PED key. Within this dcument the terms ikey and PED key are interchangeable unless therwise indicated. 16 Challenge/respnse authenticatin might, fr example, be disabled in a case where bth a cryptgraphic mdule and the attached applicatin server are lcated within a physically secured envirnment and the user is required t always be physically present t start the applicatin and authenticate t a cryptgraphic mdule via the PED. Page 22 f 46

23 cnnected t the cryptgraphic mdule) r remtely, cnnected t a management wrkstatin via USB. Remte PED peratin extends the physical trusted path cnnectin by the use f a prtcl that authenticates bth the remte PED and the mdule and establishes a ne-time AES key t encrypt the cmmunicatins between the mdule and the Remte PED. Once secure cmmunicatins have been established, all interactins between the cryptgraphic mdule, PED, and ikeys are perfrmed in exactly the same way as they wuld be when lcally cnnected. The lgical path between the mdule and the Remte PED is secured in the manner described belw. At the time it is initialized, the mdule generates a randm 256-bit secret, knwn as the Remte PED Vectr (RPV), stres it in its secure parameters area, and writes it t the Orange ikey, als knwn as the Remte PED Key (RPK). T establish the secure cnnectin, the RPK must be inserted int the PED. The PED extracts the RPV, and the PED and the cryptgraphic mdule then participate in an ephemeral Diffie- Hellman key agreement sessin. The derived shared secret is then XORed with the RPV t prduce the key t be used fr the sessin. An exchange f encrypted randm nnces is perfrmed t authenticate bth ends f the transmissin. All traffic between the PED and the cryptgraphic mdule is encrypted using AES M f N Authenticatin The Luna cryptgraphic mdule supprts the use f an M f N secret sharing authenticatin scheme fr each f the mdule rles. M f N authenticatin prvides the capability t enfrce multi-persn integrity ver the functins assciated with each rle. The M f N capability is based n Shamir s threshld scheme. The Luna cryptgraphic mdule splits the randmly-generated authenticatin data int N pieces, knwn as splits, and stres each split n an ikey. Any M f these N splits must be transmitted t the Luna cryptgraphic mdule by inserting the crrespnding ikeys int the Luna PED in rder t recnstruct the riginal secret. When the M f N set is distributed t recipients utside the mdule, the split data is cntained in M f N vectrs. A vectr may cntain ne r mre splits depending n the weight assigned at the time f generatin. Fr example, in the case f a three-f-five activatin setting, it may be desired fr A t receive the equivalent f tw splits whereas B, C and D nly receive ne each fr a ttal f five Limits n Lgin Failures The mdule als implements a maximum lgin attempts plicy. The plicy differs fr an SO authenticatin data search, a Partitin User authenticatin data search, r an Audit Officer data search. In the case f an SO authenticatin data search: If three (3) cnsecutive SO lgn attempts fail, a mdule is zerized. In the case f a Partitin User authenticatin data search, ne f tw respnses will ccur, depending n the partitin plicy: 1. If Partitin reset is Allwed and d, then if n ( n is set by the SO at the time the cryptgraphic mdule is initialized) cnsecutive peratr lgn attempts fail, the mdule flags the event in the Partitin User s accunt data, lcks the Partitin User and clears the vlatile memry space. The SO must unlck the partitin in rder fr the Partitin User t resume peratin. Page 23 f 46

24 2. If Partitin reset is nt Allwed r nt d, then if n cnsecutive Partitin User lgn attempts via the physical trusted path fail, the mdule will erase the partitin. The SO must delete and re-create the partitin. Any bjects stred in the partitin, including private and secret keys, are permanently erased. In the case f an Audit Officer data search: If three cnsecutive Audit Officer lgn attempts fail, the Audit Officer accunt will be lcked fr 60 secnds. After the 60 secnd lckut timeut, the Audit Officer may attempt t lgn t the mdule again. 3.5 Access Cntrl The Access Cntrl Plicy is the main security functin plicy enfrced by a mdule. It gverns the rights f a subject t perfrm privileged functins and t access bjects stred in a mdule. It cvers the bject peratins detailed in sectin A subject s access t bjects stred in a mdule is mediated n the basis f the fllwing subject and bject attributes: Subject attributes: Sessin ID Access ID and Partitin ID assciated with sessin Sessin authenticatin state (binding t authenticated Partitin identity and rle) Object attributes: Owner. A Private bject is wned by the Partitin User assciated with the subject that prduces it. Ownership is enfrced via internal key management. Private. If True, the bject is Private. If False, the bject is Public. Sensitive. If True, bject is Sensitive. If False, bject is Nn-Sensitive. Extractable 17. If True, bject may be extracted. If False, bject may nt be extracted. Mdifiable. If True, bject may be mdified. If False, bject may nt be mdified. Objects are labelled with a number crrespnding t their partitin and are nly accessible by a subject assciated with the wning Partitin ID. Only generic data and certificate bjects can be nn-sensitive. Sensitive bjects are encrypted using the partitin s secret key t prevent their values frm ever being expsed t external entities. Key bjects are always created as Sensitive bjects and can nly be used fr cryptgraphic peratins by a lgged in Partitin User. Key bjects that are marked as extractable may be exprted frm a mdule using the Wrap peratin if allwed and enabled in the partitin s plicy set. Table 3-3 summarizes the bject attributes used in Access Cntrl Plicy enfrcement. 17 Extract means t remve the key frm the cntrl f the mdule. This is typically dne using the Wrap peratin, but the Mask peratin is als cnsidered t perfrm an extractin when clning is enabled fr the cntainer. Page 24 f 46

25 Table 3-3. Object Attributes Used in Access Cntrl Plicy Enfrcement Attribute Values Impact PRIVATE SENSITIVE MODIFIABLE EXTRACTABLE TRUE Object is private t (wned by) the peratr identified as the Access Owner when the bject is created. FALSE Object is nt private t ne peratr identity. TRUE Attribute values representing plaintext key material are nt permitted t exist (value encrypted). FALSE Attribute values representing plaintext data are permitted t exist. TRUE The bject s attribute values may be mdified. FALSE The bject s values may nt be mdified. TRUE Key material stred with the bject may be extracted frm the Luna cryptgraphic mdule using the Wrap peratin. FALSE Key material stred with the bject may nt be extracted frm the Luna cryptgraphic mdule. Object is nly accessible t subjects (sessins) bund t the peratr identity that wns the bject. Object is accessible t all subjects assciated with the partitin in which the bject is stred. Key material is stred in encrypted frm. Plaintext data is stred with the bject and is accessible t all subjects therwise permitted access t the bject. The bject is writeable and its attribute values can be changed during a cpy r set attribute peratin. The bject can nly be read and nly duplicate cpies can be made. The ability t extract a key permits sharing with ther crypt mdules and archiving f key material. Keys must never leave a mdule s cntrl. The mdule des nt allw any granularity f access ther than wner r nn-wner (i.e., a Private bject cannt be accessible by tw Partitin Users and restricted t ther Partitin Users). Ownership f a Private bject gives the wner access t the bject thrugh the allwed peratins but des nt allw the wner t assign a subset f rights t ther peratrs. Allwed peratins are thse permitted by the cryptgraphic mdule and Partitin Capability and Plicy settings. The plicy is summarized by the fllwing statements: A subject may perfrm an allwed peratin n an bject if the bject is in the partitin with which the subject is assciated and ne f the fllwing tw cnditins hlds: 1. The bject is a Public bject, i.e., the PRIVATE attribute is FALSE, r 2. The subject is bund t the Partitin User that wns the bject. Allwed peratins are thse permitted by the bject attribute definitins within the fllwing cnstraints: 1. A Partitin User in the Crypt User rle has access t nly the User peratins, and 2. The restrictins impsed by the cryptgraphic mdule and Partitin Capability and Plicy settings Object Prtectin The mdule cryptgraphically prtects the values f sensitive bjects stred in its internal flash memry. Sensitive values are prtected using AES 256 bit encryptin with three different keys each having a separate prtectin rle. The three keys used t prtect sensitive bject values are the fllwing: User Strage Key (USK) / Security Officer Master Key (SMK) this key is created by the cryptgraphic mdule when the User r SO is created. It is used t maintain cryptgraphic separatin between users keys. Page 25 f 46

26 Master Tamper Key (MTK) this key is securely stred in the battery-backed RAM. It encrypts keys as they are generated t ensure that they can nly be used by the cprcessr itself r with authrizatin frm it. Key Encryptin Key (KEK) this key is stred in battery-backed RAM in the mdule. It als encrypts all sensitive bject values and is used t prvide the decmmissining feature. The KEK is erased in respnse t an external decmmissin signal. This prvides the capability t prevent access t sensitive bjects in the event that the mdule has becme unrespnsive r has lst access t primary pwer Object Re-use The access cntrl plicy is supprted by an bject re-use plicy. The bject re-use plicy requires that the resurces allcated t an bject be cleared f their infrmatin cntent befre they are re-allcated t a different bject Privileged Functins The mdule shall restrict the perfrmance f the fllwing functins t the SO rle nly: Mdule initializatin Partitin creatin and deletin Cnfiguring the mdule and partitin plicies Mdule zerizatin Firmware update 3.6 Cryptgraphic Material Management Cryptgraphic material (key) management functins prtect the cnfidentiality f key material thrughut its life-cycle. The FIPS PUB apprved key management functins prvided by the mdule are the fllwing: (1) Deterministic Randm Bit Generatin (DRBG) in accrdance with NIST SP A sectin (2) Cryptgraphic key generatin in accrdance with the fllwing indicated standards: a. RSA bits key pairs in accrdance with FIPS PUB 186-2, FIPS PUB and ANSI X9.31. b. Triple-DES 112 bits 18 and 168 bits (SP ). c. AES 128, 192, 256 bits (FIPS PUB 197). d. DSA 2048 and 3072 bit key pairs in accrdance with FIPS PUB and FIPS PUB e. Elliptic Curve key pairs (curves in accrdance with SP ) in accrdance with FIPS PUB and FIPS PUB f. Diffie-Hellman key pairs. g. Key Derivatin in accrdance with NIST SP (Cunter mde). 18 T use the tw-key Triple-DES algrithm t encrypt data r wrap keys in an Apprved mde f peratin, the mdule peratr shall ensure that the same tw-key Triple-DES key is nt used fr encrypting data (r wrapping keys) with mre than 2 20 plaintext data (r plaintext keys). Please refer t Sectin 2 f SP A fr restrictin infrmatin regarding its use until December 31, Page 26 f 46