SecureParser® Version 4.7.0 Security Policy Revision 1.35 23 September 2010 © Security First Corp. 2010 All Rights Reserved. Copyright Security First Corp. May be reproduced only in its original entirety (without revision). Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Revision History Revision History Version Date Author Notes 0.01 01/11/2007 Infogard, Documentation Workshop (Infogard template) Security First Corp. 0.02 02/26/2007 Security First Accumulated changes to date after Corp. Documentation Workshop. 0.03 03/20/2007 Security First Added key sizes for DSA & RSA keys in Corp. Section 3 Modes of Operation 0.04 03/22/2007 Security First Added power-on self-test Corp. RSA encrypt/decrypt 0.05 04/20/2007 Security First Corrected Security Rule 25 to reflect PRNG is Corp. based on AES Encrypt, not AES Decrypt 0.06 05/22/2007 Security First Clarified that the same HMAC key is used for Corp. Data & Share authentication/integrity 0.07 06/07/2007 Security First Added Algorithm certificate numbers Corp. 0.08 06/12/2007 Security First Added entropy assessment details Corp. 0.09 07/11/2007 Security First Updates after Operational Testing. Corp. ECDSA added. Overview updated. 1.00 08/07/2007 Security First Final edit before submission Corp. 1.01 11/8/2007 Security First V4.5.1 revision for submission. Corp. Updated API section, removed references to (ISE input) single-threaded requirement, added references for libparser4.sys. 1.02 12/16/2007 Security First Title page updated. Corp. Page 2 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 (ISE input) 1.03 01/07/2008 Security First Responses to CMVP Comments. Corp. Additional V4.5.1 changes for clarity regarding (ISE input) Multi-threading and Kernel mode. 1.04 01/18/2008 Security First Responses to CMVP Comments round 2. Corp. All references to MS RSAENH.dll removed. (ISE input) Standard platform services are providing entropy. Security Rule 24:3 corrected. 1.05 01/31/2008 Security First Responses to CMVP Comments round 3. Corp. Clarification: Key entry/output is always encrypted. (ISE input) PRNG_Seed_Value rationale of strength modified as per CMVP suggestion. 1.1 08/15/2008 Security First V4.6 revision for submission. Corp. Updated API, added algorithms, added operating (ISE Input) systems. 1.2 02/02/2009 Security First V4.7.0 revision for submission. Corp. Updated API section, added description of RPU. (ISE input) Removed all operating systems but Ubuntu and the Windows kernel. 1.21 02-17-2009 Security First Removed function get_errorlog, it is disabled in Corp. FIPS mode. (ISE input) 1.22 02-20-2009 Security First Prior Track Changes accepted. Prior comments Corp. removed. Table 1: Level of Physical Security NA 1. (ISE input) Real picture for Figure 2 – Image of the Accelium 1.23 02-20-2009 Security First Added real picture of the RPU for Figure 2. Corp. Page 3 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 (ISE input) 1.24 02-23-2009 Security First Updated photos in Figure 2. Adjusted verbiage Corp. in the physical RPU section. (ISE input) 1.25 02-26-2009 Security First Clarified key wrapping description under Corp. Security Rules. (ISE input) 1.26 04-01-2009 Security First Final edits before CMVP submission. Corp. (ISE input) 1.30 08-06-2009 Security First Added Windows Server 2003 references in Corp. anticipation of update submission. (ISE input) Responses to CMVP Comments. 1.31 08-06-2009 Security First Minor formatting changes. Corp. (ISE input) 1.32 09-02-2009 Security First Updated for SW-only release. Corp. (ISE input) 1.33 11-18-2009 Security First More updates for SW-only release. Corp. (ISE input) 1.34 7/13/2010 Security First Updated for level 2 submission Corp. (ISE input) 1.35 9/23/2010 Security First Updated wording in Module Overview and Corp. Modes of Operation (ISE input) Responses to CMVP Comments Page 4 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 TABLE OF CONTENTS REVISION HISTORY ................................................................................................................................................ 2  1. MODULE OVERVIEW.......................................................................................................................................... 6  2. SECURITY LEVEL ................................................................................................................................................ 9  3. MODES OF OPERATION ..................................................................................................................................... 9  4. IDENTIFICATION AND AUTHENTICATION POLICY ............................................................................... 11  5. ACCESS CONTROL POLICY ............................................................................................................................ 11  ROLES AND SERVICES .............................................................................................................................................. 11  DEFINITION OF CRITICAL SECURITY PARAMETERS (CSPS)...................................................................................... 16  DEFINITION OF CSPS MODES OF ACCESS ................................................................................................................ 18  6. SECURITY RULES .............................................................................................................................................. 24  7. PHYSICAL SECURITY ....................................................................................................................................... 26  8. MITIGATION OF OTHER ATTACKS POLICY ............................................................................................. 26  9. REFERENCES ...................................................................................................................................................... 26  10. DEFINITIONS AND ACRONYMS ................................................................................................................... 27  Page 5 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 1. Module Overview The SecureParser® (SW Version 4.7.0) is a FIPS software-only module (hereafter known as “the module”) that operates on a multi-chip standalone general purpose computer. The module is a security and data availability architecture delivered in the form of a toolkit that provides cryptographic data splitting (data encryption, random or deterministic distribution to multiple shares including additional fault tolerant bits, key splitting, authentication, integrity, share reassembly, key restoration and decryption) of arbitrary data. The SecureParser accepts any type of digital data and cryptographically splits it into shares so that no discernible plaintext is transmitted across a network or is placed on a single storage device. During the parse process, additional redundant data may be optionally written to each share enabling the capability of restoring the original data when all shares are not available. The shares can be stored in geographically disbursed nodes providing for continuous access to online information. Each share contains a cryptographically strong integrity check that prevents tampering with the stored data and is immediately recognized by the other shares. Any change to the data in a share precludes that share from being used in the data rebuild process. The encryption, integrity and Information Dispersal Algorithm (IDA) session keys are encrypted with long-term, external workgroup keys, and a per-session key encrypting key that is shared and stored with the data. Data availability through redundant shares allows for a return to operations in the face of lost or corrupted shares due to environmental, malicious or accidental catastrophes. The SecureParser module is designed to be integrated at any point where data is written, retrieved, sent or received. Boundaries Figure 1 – Image of the Cryptographic Module Physical Boundary (case of general purpose computer) Logical Boundary Volatile Keystore Persistent Keystore Application Module’s SecureParser module toolkit dynamic link that uses exposed Data Input library: the module API Data Output libparser4.so, Linux toolkit Control Input libparser4.sys, Windows library Status Output All Secret and Private Key Entry/Output is encrypted. Logical Boundary Page 6 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 When operating on the Linux operating system Red Hat Enterprise Linux Version 5.1, the SecureParser cryptographic logical boundary is defined as containing the SecureParser libparser4.so. Seed values for the SecureParser’s random number generator are imported from standard operating system services within the physical boundary of the general purpose computer. When operating on Microsoft Windows XP Professional SP2 and Microsoft Windows Server 2003 SP2, the SecureParser module cryptographic logical boundary is defined as containing the SecureParser libparser4.sys. Seed values for the SecureParser’s random number generator are imported from standard operating system services within the physical boundary of the general purpose computer. Physical Boundary The SecureParser cryptographic physical boundary is the case of the General Purpose Computer (GPC) on which the libparser4 executable is instantiated. Ports at the physical boundary of the GPC are those typical of a GPC for connecting external devices such as keyboards, monitors, mice, and printers. These devices are outside the physical boundary of the cryptographic module and are excluded from the validation. Operating Systems & Platforms The SecureParser module has been tested on and found to be conformant with the requirements of FIPS 140-2 overall Level 2 on the following GPC operating systems: Red Hat Enterprise Linux Version 5.1, Microsoft Windows XP Professional SP2, and Microsoft Windows Server 2003 SP2. Operating System Hardware Platform Module File Name CC Validation Microsoft Windows XP Dell Optiplex GX620 libparser4.sys EAL4+ ALC_FLR.3 Professional SP2 (Intel Pentium 4) 07-FEB-08 CAPP Compliant Microsoft Windows Dell Optiplex GX620 libparser4.sys EAL4+ ALC_FLR.3 Server 2003 SP2 (Intel Pentium 4) 07-FEB-08 CAPP Compliant Red Hat Enterprise Linux SGI Altix XE240 libparser4.so EAL4+ ALC_FLR.3 Version 5.1 (Intel Xeon) 21-APR-08 CAPP Compliant Page 7 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Operational testing was performed on all the above operating systems. All operating systems used for module testing have been validated against the Controlled Access Protection Profile (CAPP), version 1.d, Protection Profile NoPP006 dated October 8, 1999. In accordance with FIPS 140-2 Implementation Guidance, the SecureParser will remain compliant with the requirements of FIPS 140-2 when operating on the following operating systems provided that the general purpose computer (GPC) uses the operating system configuration and modes specified on the referenced CC Certification Report: OS Configurations Evaluated in the Referenced CC Validation Microsoft Windows Reference: Section 8 of CC Certification Report Server 2003 SP2 http://www.commoncriteriaportal.org/files/epfiles/20080303_st_vid101 Includes R2, Standard, 84-vr.pdf#page=17 Enterprise, Datacenter, Dell Optiplex GX620; Dell PowerEdge SC1420; Dell PowerEdge x64, and Itanium SC1420; Dell PowerEdge 1800; Dell PowerEdge 2850; HP Proliant Editions; Windows XP DL385; HP rx1620 Bundle Solution Server; HP xw9300 Workstation; Professional SP2 and x64 IBM eServer 326m; IBM eServer 326m; Unisys RASCAL ES7000 SP2; Windows XP Embedded SP2 Red Hat Enterprise Linux Reference: Section 8 of the CC Validation Report Version 5.1 http://www.commoncriteriaportal.org/files/epfiles/st_vid10286- vr.pdf#page=14 SGI Altix XE servers (200 and 300 series, Xeon EM64T/x86_64 based); SGI Altix 400 and 4000 series (Itanium2/ia64-based) consisting of a customer selected combination of the following blade types: o Compute/Memory blade o Memory-only blade o Base I/O Blade o PCI-X expansion blade o PCI-Express expansion blade Compatible Platforms Page 8 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 2. Security Level The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140-2. Table 1 – Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 3 Module Ports and Interfaces 2 Roles, Services and Authentication 3 Finite State Model 2 Physical Security N/A Operational Environment 2 Cryptographic Key Management 2 EMI/EMC 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A 3. Modes of Operation Approved Algorithms In FIPS mode, the SecureParser module supports FIPS Approved algorithms as follows. The certificate #’s sited below have all been obtained by SecureParser module algorithm testing with the CAVP: Software (CPU) Algorithms: AES-CBC/ECB - 128/192/256 bit key Cert. #1381 AES-CTR - 128/192/256 bit key Cert. #1381 AES-GCM 128/192/256 bit key Cert. #1382 HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512 Cert. #813 SHA-1, SHA-256, SHA-384, SHA-512 hashing Cert. #1249 DSA sign/verify – 1024 bit key Cert. #448 RSA sign/verify – 1024/2048/4096 bit key Cert. #668 RNG Key Generation ANSI X9.31 with AES Cert. #754 ECDSA sign/verify – 521 bit key Cert. #173 Page 9 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Key Entry and Output All Key Entry and Output in FIPS mode must be in encrypted form. Plaintext keys are never entered or output from the module. NIST Key Wrapping per FIPS 140-2 Annex D using 128/192/256 bit keys. AES (Cert. #1381 key wrapping; key establishment methodology provides 128, 192 or 256 bits of encryption strength) for NIST Key Wrapping per FIPS 140-2 Annex D) RSA Key Wrapping per FIPS 140-2 IG 7.1 Acceptable Key Establishment Protocols, Key Transport using asymmetric keys [key wrapping] using k = 4096. RSA (key wrapping; key establishment methodology provides 128 bits of encryption strength). In FIPS mode the SecureParser module does not support any non-allowed FIPS algorithms. Configuring the module for FIPS mode The SecureParser module may be configured for FIPS mode by calling the module’s exposed module_initialize( ) API function with the calling parameter “fipsEnabled” set to true. Subsequent SecureParser module API calls that are used to further configure the SecureParser will have their calling parameters checked by the SecureParser based on the value of the “fipsEnabled” calling parameter used in the original module_initialize( ) API function call. These subsequent checks are used to insure that all FIPS mode configuration values are set properly. Operators can determine if the cryptographic module is running in FIPS versus non-FIPS mode via execution of the module’s module_getStatus( ) API function call, which is used to meet the FIPS area 1 requirements to achieve Level 3. The module_getStatus( ) API function call equates to the FIPS “show status” service and will indicate if a FIPS mode of operation has been selected. The module_getStatus( ) API call returns two items: • Whether the module is in FIPS mode (value set = 1), or non-FIPS mode (value set = 0) • The current FSM state of the module (MODULE_STATE enum) Once a FIPS mode of operation has been selected the module cannot transition into a non-FIPS mode of operation during the lifetime of the module instantiation in executable memory. Similarly once a non-FIPS mode of operation has been selected the module cannot transition into a FIPS mode of operation during the lifetime of the module instantiation in executable memory. Non-FIPS mode of operation The SecureParser module can be initialized into a non-FIPS Approved mode of operation by setting the “fipsEnabled” flag to 0 during the first call to the API function module_initialize( ). In non-FIPS mode, the module supports the option to not use encryption or message authentication coding. Applications cannot transition their use of the module toolkit library to/from FIPS mode and non-FIPS mode while the module is instantiated. The module must be shut down by the calling application and then restarted to transition to/from FIPS mode and non-FIPS mode. Note that the module does not have any persistent CSPs. All CSPs are zeroed when the module is shut down or transitions between modes. Page 10 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 4. Identification and Authentication Policy Assumption of roles The module utilizes identity based authentication, implementing User and Crypto-Officer roles. The module does not provide the authentication mechanism, the operating systems hosting the module have authentication implemented. The User and Crypto-Officer roles are assumed by the operator accessing services provided by the module. Authentication Authentication is provided by the host operating system. The passwords must be a minimum of 8 alphanumeric characters. The character set used for these passwords consists of those on a standard keyboard, with 128 possible characters; therefore, an attack would have to include 128^8 possible combinations. The resulting possibility of 1/128^8 chance of successful access is significantly less than 1/1,000,000. To exceed a one in 100,000 probability of a successful guess in 60 seconds, an attacker would need to enter approximately 12 billion attempts per second. That far exceeds the processing capabilities of the device. 5. Access Control Policy Roles and Services Services: • module_initialize. Initializes the module, sets FIPS mode or non-FIPS mode, performs self tests, and moves the module into an operational state. • parser_create. Allocates the memory for a Parser structure. There can be multiple parser instances within the module – they are all either in FIPS mode, or they are all in non- FIPS mode (determined by the module_initialize service). • parser_destroy. Deallocates the memory of a Parser structure. • parser_generateHeaders. Configures parser context and generates headers. • parser_restoreHeaders. Configures parser context based on headers with optional modifications. • parser_regenerateHeaders. Produces headers associated with an already-configured parser context. • parser_recoverHeaders. Recovers missing headers and places them in the output buffers that are unused. Page 11 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 • parser_setWorkgroupKeys. Changes the workgroup keys in an existing parser context. • keystore_getImportKey. Provides the RSA public key needed for asymmetric key wrapping for all key entry into the specified keystore of the module (note that each keystore will have its own ephemeral public/private keypair). • keystore_create. Allocates memory for a volatile KeyStore structure, and creates a non- persistent RSA public/private encryption keypair to be used for key import (note that each keystore will have its own public/private keypair). • keystore_destroy. Deallocates the memory of a volatile KeyStore structure. • keystore_addKeyFromBuffer. Imports a key into the specified volatile keystore structure. All imported keys will be RSA key wrapped and will need to be unwrapped by the module. Note: x509 certificates can be in the buffer, their public keys will be imported. • keystore_removeKey. Removes a key from the volatile keystore. • keystore_getKeyType. Returns the key type for the requested key. • keystore_getkeylength. Returns the key length for the requested key. • keystore_keyexists. True or False, the requested key exists or does not exist within the specified volatile keystore. • module_destroy: Zeroization, called by the application prior to (graceful) application termination. Zeroes non-persistent CSPs including the RSA import public/private keypair, and the volatile Keystores. ALL keystores and ALL parsers in memory are zeroed. • parser_parseData. Parses data from the input buffer into the output buffers. • parser_restoreData. Restores data from the output buffers into the input buffer. • parser_parseDataEx. Parses an array of input buffers into the output buffers. • parser_recoverData. Rebuilds all N data shares given only M input shares. • parser_getFieldOffsets. Returns an array of {share number, offset, length} tuples necessary to create M of N shares for a given M value and a set of “N of N” parsed shares. • parser_setFaultTolerance. Sets a new fault tolerance value (M). Designed for use with parser_getFieldOffsets(). Page 12 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 • parser_getHeaderInfo. Processes the header and returns information about specific header fields. • parser_getParsedLength. Returns the number of bytes needed for each output share when parsing. • parser_getRestoredLength. Returns the number of bytes needed for the original share when restoring. • module_getStatus: This service provides the current status of the cryptographic module including whether or not a FIPS Approved mode of operation has been selected. • Self-tests: Power cycle Table 5 – Specification of Service Inputs & Outputs Service Control Input Data Input Data Output Status Output module_initialize int fipsEnabled N/A N/A Success or ERROR_TYPE parser_create N/A N/A Parser **ret Success or ERROR_TYPE parser_destroy Parser *p N/A N/A Success or ERROR_TYPE parser_ Parser *p N/A uint8 **outputBuffers Success or generateHeaders KeyStore *ks uint32 ERROR_TYPE int L *outputBufferLengths int M int N IDA_TYPE idaMode ENC_TYPE encMode HASH_TYPE hashMode uint8 *encWgKeyId uint32 encWgKeyIdMem uint32 encWgKeyIdLength uint8 *macWgKeyId uint32 macWgKeyIdMem uint32 macWgKeyIdLength uint8 *idaWgKeyId uint32 idaWgKeyIdMem uint32 idaWgKeyIdLength AUTH_TYPE postAuthMode HASH_TYPE postHashMode uint8 *postAuthPubKeyId uint32 postAuthPubKeyIdMem uint32 postAuthPubKeyIdLength uint8 *postAuthPrivKeyId uint32 postAuthPrivKeyIdMem Page 13 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Service Control Input Data Input Data Output Status Output uint32 postAuthPrivKeyIdLength uint32 *outputBufferMems int outputBuffersCount parser_ Parser *p uint8 N/A Success or restoreHeaders KeyStore *ks **inputBuffers ERROR_TYPE HASH_TYPE hashMode uint8 *encWgKeyId uint32 encWgKeyIdMem uint32 encWgKeyIdLength uint8 *macWgKeyId uint32 macWgKeyIdMem uint32 macWgKeyIdLength uint8 *idaWgKeyId uint32 idaWgKeyIdMem uint32 idaWgKeyIdLength AUTH_TYPE postAuthMode HASH_TYPE postHashMode uint8 *postAuthPubKeyId uint32 postAuthPubKeyIdMem uint32 postAuthPubKeyIdLength uint8 *postAuthPrivKeyId uint32 postAuthPrivKeyIdMem uint32 postAuthPrivKeyIdLength uint32 * inputBufferMems uint32 * inputBufferLengths int inputBuffersCount int trustedShareNumber parser_ Parser *p N/A uint8 **outputBuffers Success or regenerateHeaders uint32 *outputBufferMems uint32 ERROR_TYPE int outputBuffersCount *outputBufferLengths parser_ KeyStore *ks uint8 uint8 **outputBuffers Success or recoverHeaders HASH_TYPE hashMode **outputBuffers uint32 ERROR_TYPE char *workgroupKeyId *outputBufferLengths uint32 workgroupKeyIdMem uint32 workgroupKeyIdSize, AUTH_TYPE postAuthMode char *postAuthKeyId uint32 postAuthKeyIdMem uint32 postAuthKeyIdSize uint32 *outputBufferMems uint32 *outputBufferLengths parser_ Parser * p N/A N/A Success or setWorkgroupKey char * encWgKeyId ERROR_TYPE s uint32 encWgKeyIdMem uint32 encWgKeyIdLength char * macWgKeyId uint32 macWgKeyIdMem Page 14 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Service Control Input Data Input Data Output Status Output uint32 macWgKeyIdLength char * idaWgKeyId uint32 idaWgKeyIdMem uint32 idaWgKeyIdLength keystore_ KeyStore *ks N/A uint8 *buffer Success or getImportKey uint32 bufferMem uint32 *bufferLength ERROR_TYPE keystore_create int minimumKeyCount N/A KeyStore **ret Success or ERROR_TYPE keystore_destroy KeyStore *ks N/A N/A Success or ERROR_TYPE keystore_ KeyStore *ks uint8* buffer N/A Success or addKeyFromBuffe uint32 bufferMem char *id ERROR_TYPE r uint32 bufferLength char *id uint32 idMem uint32 idLength char *passphrase uint32 passphraseMem uint32 passphraseLength IMPORT_TYPE importType keystore_ KeyStore *ks N/A N/A Success or removeKey char *id ERROR_TYPE uint32 idMem uint32 idLength keystore_ KeyStore *ks N/A KEY_TYPE *keyType Success or getKeyType char *id ERROR_TYPE uint32 idMem uint32 idLength keystore_ KeyStore *ks N/A uint32 *keyLength Success or getKeyLength char *id ERROR_TYPE uint32 idMem uint32 idLength keystore_keyExist KeyStore *ks N/A int *keyExists Success or s char *id ERROR_TYPE uint32 idMem uint32 idLength parser_parseData Parser *p uint8 *inputBuffer uint8**outputBuffers Success or uint32 inputBufferLength uint32 ERROR_TYPE uint32 inputBufferMem *outputBufferLengths uint32 *outputBufferMems int outputBuffersCount parser_parseDataE Parser * p uint8 ** uint8**outputBuffers Success or x uint32 * inputBufferMems inputBuffers uint32 ERROR_TYPE uint32 * inputBufferLengths *outputBufferLengths uint32 inputBuffersCount uint32 * outputBufferMems uint32 outputBuffersCount parser_restoreData Parser *p uint8 uint8 *outputBuffer Success or uint32 outputBufferMem **inputBuffers uint32 ERROR_TYPE uint32 *inputBufferLengths *outputBufferLength uint32 *inputBufferMems Page 15 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Service Control Input Data Input Data Output Status Output int inputBuffersCount int trustedShareNumber parser_recoverDat Parser *p uint8 uint8**outputBuffers Success or a uint32 *outputBufferLengths *outputBuffers uint32 ERROR_TYPE uint32 *outputBufferMems *outputBufferLengths int outputBuffersCount int trustedShareNumber parser_ uint32 headerMem DATAFIELD_TYP void *ret Success or getHeaderInfo uint32 headerLength Et uint32 *retLength ERROR_TYPE uint32 retMem uint8 *header parser_ Parser *p uint32 inputLength uint32 *ret Success or getParsedLength ERROR_TYPE parser_ Parser *p uint32 inputLength uint32 *ret Success or getRestoredLength ERROR_TYPE parser_ Parser * p N/A FieldOffsets * o Success or getFieldOffsets uint32 plaintextLength ERROR_TYPE int intendedM parser_ Parser *p N/A N/A Success or setFaultTolerance int newM ERROR_TYPE module_getStatus N/A N/A int *fipsEnabled Success or MODULE_STATE *state ERROR_TYPE module_destroy N/A N/A N/A Success or (Zeroization) ERROR_TYPE Self-Tests (Power N/A N/A N/A cycle) Definition of Critical Security Parameters (CSPs) The following are CSPs contained within the module: • Private_Import_Key_RSA_Unwrap: Used by the SecureParser module to unwrap encrypted keys sent to it by applications. All keys sent to the SecureParser will be RSA key wrapped by applications with CSP Public_Import_Key_RSA_Wrap. Note that each SecureParser keystore will have its own associated RSA public/private import keypair. • Workgroup_Key_Enc: Used to NIST key wrap internally generated encryption session key (Session_Key_Enc), also used to unwrap encryption session key when headers are being restored. • Workgroup_Key_Mac: Used to NIST key wrap internally generated integrity session key (Session_Key_Mac), also used to unwrap integrity session key when headers are being restored. • Workgroup_Key_Ida: Used to NIST key wrap internally generated IDA session key (Session_Key_Ida), also used to unwrap IDA session key when headers are being restored. • Session_Key_Enc: Used to encrypt all plaintext data prior to data splitting. Encrypted by Workgroup_Key_Enc using the NIST Key wrap and then placed into share headers. Page 16 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 • Session_Key_Mac: HMAC-SHA1, SHA256, SHA384, or SHA512 key used for ciphertext data integrity once splitting is complete. Encrypted by Workgroup_Key_Mac using the NIST Key wrap and then placed into share headers. • Session_Key_Ida: Random seed used as input to IDAs for adding randomness. Encrypted by Workgroup_Key_Mac using the NIST Key wrap and then placed into share headers. • Share_Integrity_Key_HMAC: Optional HMAC-SHA1, HMAC-SHA256, HMAC- SHA384, or HMAC-SHA512 key used for additional ciphertext share data integrity after data splitting. Never output. • Share_Integrity_Key_ DSA_Sign: Optional DSA Private Key (PEM or ANSI) used to sign ciphertext share data after the data splitting process. Never output. • Share_Integrity_Key_ RSA_Sign: Optional RSA Private Key used to sign ciphertext share data after the data splitting process. Never output. • Share_Integrity_Key_ ECDSA_Sign: Optional ECDSA Private Key (PEM or ANSI) used to sign ciphertext share data after the data splitting process. Never output. • PRNG_Seed_Key: Imported from standard operating system services within the physical boundary of the general purpose computer. Used to seed the module’s own FIPS ANSI X9.31 pseudo random number generator. Rationale of strength follows PRNG_Seed_Value description. • PRNG_Seed_Value: Imported from standard operating system services within the physical boundary of the general purpose computer. Used to seed the module’s own FIPS ANSI X9.31 pseudo random number generator. Must not be identical to PRNG_Seed_Key. Since the PRNG seed comes from the operating system, which is outside the logical boundary of the module, for the purposes of FIPS 140-2, the entropy of this seed may be assumed to be equal to the length of the seed. The seed length is 128 bits. • SecureParser PRNG_State: Internal state of the SecureParser’s PRNG (Cert. #584). Definition of Public Keys The following are the public keys contained in the module: • Public_Import_Key_RSA_Wrap: Used by applications to wrap keys they are sending to the SecureParser module. All keys sent to the SecureParser must be RSA wrapped. Note that each SecureParser keystore will have its own public/private key pair. • SW_Integrity_Key_DSA_Verify: Used for verification of the signed module executable during power-on self-tests. Hard coded in the module. • Share_Integrity_Key_DSA_Verify: Optional DSA Public Key (PEM or ANSI) used to verify ciphertext share data during the restoration process. Can be imported into the module from an X509 certificate. • Share_Integrity_Key_RSA_Verify: Optional RSA Public Key used to verify ciphertext share data during the restoration process. Can be imported into the module from an X509 certificate. • Share_Integrity_Key_ECDSA_Verify: Optional ECDSA Public Key (PEM or ANSI) used to verify ciphertext share data during the restoration process. Can be imported into the module from an X509 certificate. Page 17 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Definition of CSPs Modes of Access Table 6 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as follows: • G = Generate CSP • R = Read CSP • W = Write CSP • Z = Zero CSP Table 6 – CSP Access Rights within Roles & Services Ref. SecureParser Specification: 4.4 Critical Security Parameters Role Service Cryptographic Keys and CSPs Access Operation C.O. User X X PRNG_Seed_Key, G-Z module_initialize PRNG_Seed_Value, G-Z PRNG_State, W X X N/A parser_create X X Session_Key_Enc, Z parser_destroy Session_Key_Mac, Z Session_Key_Ida, Z X X Session_Key_Enc, G-R-W parser_generateHeaders Session_Key_Mac, G-R-W Session_Key_Ida, G-R-W Workgroup_Key_Enc, R Workgroup_Key_Mac, R Workgroup_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R PRNG_State, R-W X X Session_Key_Enc, R-W parser_restoreHeaders Session_Key_Mac, R-W Session_Key_Ida, R-W Workgroup_Key_Enc, R Workgroup_Key_Mac, R Workgroup_Key_Ida, R Share_Integrity_Key_HMAC, R X X Session_Key_Enc, R parser_regenerateHeaders Session_Key_Mac, R Session_Key_Ida, R Workgroup_Key_Enc, R Workgroup_Key_Mac, R Page 18 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Role Service Cryptographic Keys and CSPs Access Operation C.O. User Workgroup_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R X X Session_Key_Enc, R parser_recoverHeaders Session_Key_Mac, R Session_Key_Ida, R Workgroup_Key_Enc, R Workgroup_Key_Mac, R Workgroup_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R X X Session_Key_Enc, R parser_setWorkgroupKeys Session_Key_Mac, R Session_Key_Ida, R Workgroup_Key_Enc, W Workgroup_Key_Mac, W Workgroup_Key_Ida, W X X Private_Import_Key_RSA_Unwrap, G keystore_create Public_Import_Key_RSA_Wrap, G X X All CSPs in the keystore, Z keystore_destroy X X All keys that are imported, R-W keystore_addKeyFromBuffer Private_Import_Key_RSA_ Unwrap, R X X Specified key in volatile keystore keystore_removeKey structure Z X X Specified key in volatile keystore keystore_getKeyType structure R X X Specified key in volatile keystore keystore_getKeyLength structure R X X Specified key in volatile keystore keystore_keyExists structure R X X Public_Import_Key_RSA_Wrap, R keystore_getImportKey X X Session_Key_Enc, R parser_parseDataEx Session_Key_Mac, R Session_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R Page 19 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Role Service Cryptographic Keys and CSPs Access Operation C.O. User PRNG_State, R-W X X Session_Key_Enc, R parser_parseData Session_Key_Mac, R Session_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R PRNG_State, R-W X X Session_Key_Enc, R parser_restoreData Session_Key_Mac, R Session_Key_Ida, R Share_Integrity_Key_HMAC, R X X Session_Key_Mac, R parser_recoverData Session_Key_Ida, R Share_Integrity_Key_HMAC, R Share_Integrity_Key_DSA_Sign, R Share_Integrity_Key_RSA_Sign, R Share_Integrity_Key_ECDSA_Sign, R X X N/A parser_getHeaderInfo X X N/A parser_getFieldOffsets X X N/A parser_setFaultTolerance X X N/A parser_getParsedLength X X N/A parser_getRestoredLength X X N/A module_getstatus X X All CSPs (includes imported public Zeroization: keys and everything in the volatile module_destroy keystore), Z X X SW Integrity: Digital signature using Self tests (power cycle) Security First Corp. public DSA key SW_Integrity_Key_ DSA_Verify, R For each service listed in Table 6 above, the following identifies all CSPs that are entered into and output from the module during execution of each service. • module_initialize: o Entry: N/A. o Output: N/A. • parser_create: o Entry: N/A. o Output: N/A. • parser_destroy: Page 20 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 o Entry: N/A. o Output: N/A. • parser_generateHeaders: o Entry: N/A. o Output: Session_Key_Enc (encrypted with Workgroup_Key_Enc). Session_Key_Mac (encrypted with Workgroup_Key_Mac). Session_Key_Ida (encrypted with Workgroup_Key_Ida). • parser_restoreHeaders: o Entry: Session_Key_Enc (encrypted with Workgroup_Key_Enc). Session_Key_Mac (encrypted with Workgroup_Key_Mac). Session_Key_Ida (encrypted with Workgroup_Key_Ida). o Output: N/A. • parser_regenerateHeaders: o Entry: N/A. o Output: Session_Key_Enc (encrypted with Workgroup_Key_Enc). Session_Key_Mac (encrypted with Workgroup_Key_Mac). Session_Key_Ida (encrypted with Workgroup_Key_Ida). • parser_recoverHeaders: o Entry: Session_Key_Enc (encrypted with Workgroup_Key_Enc). Session_Key_Mac (encrypted with Workgroup_Key_Mac). Session_Key_Ida (encrypted with Workgroup_Key_Ida). o Output: Session_Key_Enc (encrypted with Workgroup_Key_Enc). Session_Key_Mac (encrypted with Workgroup_Key_Mac). Session_Key_Ida (encrypted with Workgroup_Key_Ida). • parser_setWorkgroupKeys: o Entry: N/A. o Output: N/A. • keystore_create: o Entry: N/A. o Output: N/A. • keystore_destroy: o Entry: N/A. o Output: N/A. • keystore_addKeyFromBuffer: o Entry: Workgroup_Key_Enc (encrypted with Public_Import_Key_RSA_Wrap). Workgroup_Key_Mac (encrypted with Public_Import_Key_RSA_Wrap). Workgroup_Key_Ida (encrypted with Public_Import_Key_RSA_Wrap). Share_Integrity_Key_HMAC (encrypted with Public_Import_Key_RSA_Wrap). Share_Integrity_Key_DSA_Sign (encrypted with Page 21 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 Public_Import_Key_RSA_Wrap). Share_Integrity_Key_RSA_Sign (encrypted with Public_Import_Key_RSA_Wrap). Share_Integrity_Key_ECDSA_Sign (encrypted with Public_Import_Key_RSA_Wrap). o Output: N/A. • keystore_removeKey: o Entry: N/A. o Output: N/A. • keystore_getKeyType: o Entry: N/A. o Output: N/A. • keystore_getKeyLength: o Entry: N/A. o Output: N/A. • keystore_keyExists: o Entry: N/A. o Output: N/A. • keystore_getImportKey: o Entry: N/A. o Output: Public_Import_Key_RSA_Wrap (plaintext). • parser_parseDataEx: o Entry: N/A. o Output: N/A. • parser_parseData: o Entry: N/A. o Output: N/A. • parser_restoreData: o Entry: N/A. o Output: N/A. • parser_recoverData: o Entry: N/A. o Output: N/A. • parser_getHeaderInfo: o Entry: N/A. o Output: N/A. • parser_getFieldOffsets: o Entry: N/A. o Output: N/A. • parser_setFaultTolerance: o Entry: N/A. o Output: N/A. • parser_getParsedLength: o Entry: N/A. o Output: N/A. • parser_getRestoredLength: Page 22 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 o No key Entry or Output. • module_getstatus: o Entry: N/A. o Output: N/A. • Zeroization: module_destroy: o Entry: N/A. o Output: N/A. • Self tests (power cycle): o Entry: N/A. o Output: N/A. Page 23 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 6. Security Rules The SecureParser cryptographic module’s design corresponds to the module’s security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140-2 Level 2 software-only module. 1. The SecureParser module interfaces shall be logically distinct from each other as defined by the SecureParser API for the following interfaces: Data Input; Data Output; Control Input; Status Output. 2. Status information shall not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 3. Data output shall be inhibited during self-tests, and while in error states. 4. Data output shall be disconnected from the module processes that perform key generation, and plaintext CSP zeroing (the module will not support manual key entry). 5. Two independent internal actions will be required to output data via the output interface through which sensitive restored plaintext share data is output. 6. Plaintext secret/private key output is not supported. No SecureParser API calls will permit secret/private key output. 7. The SecureParser module shall provide two distinct operator roles. These are the User role, and the Cryptographic-Officer role. 8. The SecureParser module shall not support concurrent operators. 9. The SecureParser module shall not support a maintenance role. 10. The SecureParser module shall not support a bypass capability. 11. The SecureParser module provides identity based authentication. 12. Explicit service API calls into the SecureParser module shall allow the implicit assumption of operator roles. 13. The SecureParser module includes the following operational and error states: Power on/off state; Crypto officer state; User state; Self-test state; Error state; Key/CSP Entry state. 14. Recovery from error states shall be possible by power cycling the module. 15. Secret keys, private keys, and CSPs shall be protected within the cryptographic module from unauthorized disclosure, modification, and substitution. 16. Public keys shall be protected within the cryptographic module against unauthorized modification and substitution. 17. An Approved RNG (ANSI X9.31 with AES) shall be used for the generation of AES cryptographic keys within the module. 18. An Approved RNG (ANSI X9.31 with AES) shall be used for the generation of RSA cryptographic key pairs within the module. 19. The PRNG seed and seed key shall not have the same value. 20. Compromising the security of the key generation method (e.g., guessing the seed value to initialize the deterministic RNG) shall require as least as many operations as determining the value of the generated key. 21. The SecureParser module shall associate all cryptographic keys (secret, private, or public) stored within the module with the correct entity (KeyID) to which the key is assigned. 22. The SecureParser module shall provide a method to zero all plaintext secret and Page 24 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 private cryptographic keys and CSPs within the module in a time that is not sufficient to compromise the plaintext secret and private keys and CSPs (service: module_destroy). 23. Power-on Self-tests will not require operator intervention, they will be performed automatically when the module is initialized. 24. The cryptographic module shall perform the following self-tests: a. Power up Self-Tests: i. Software cryptographic algorithm tests: 1. RNG KAT, covers AES Encrypt 2. AES Decrypt KAT (ECB mode with 256-bit key) 3. AES Encrypt and Decrypt KAT (GCM mode with 128,192, and 256-bit keys) 4. HMAC KATS using SHA-256, SHA-384, SHA-512, covers SHA-256, SHA-384, and SHA-512 hashing 5. DSA sign/verify using SHA-1, covers SHA-1 hashing 6. RSA-PSS sign/verify 7. RSA encrypt/decrypt 8. ECDSA sign/verify ii. Software/Firmware Integrity Test – DSA public key verification of a private key signature. Covers all module executables listed in Figure 1 - Image of the Cryptographic Module. b. Conditional Self-Tests: i. Continuous Random Number Generator (RNG) test – performed on each sample from the RNG (each sample will be 128 AES bits). ii. Pairwise consistency test – performed each time an RSA “import” key pair is generated inside the module. 25. If the SecureParser module fails a self-test, the module shall enter an error state and output an error indicator via the status output interface. 26. The SecureParser module, shall not perform any cryptographic operations while in an error state. 27. When the power-up tests are completed, the results (i.e. indications of success or failure) shall be output via the “status output” interface. 28. The operator shall be capable of commanding the module to perform the power-up self-tests at any time by power cycling the cryptographic module. 29. None of the mentioned hardware, software, or firmware components will be excluded from the module. This section documents the security rules imposed by the vendor: 1. An approved encryption mode and an approved integrity mechanism must be requested by calling applications to run the SecureParser module in FIPS Approved mode. 2. Workgroup keys shall be mandatory for the SecureParser module to run in a FIPS Approved mode. 3. Workgroup keys shall not be placed in data shares. 4. The SecureParser module shall encrypt all share data using AES session keys. 5. The SecureParser module shall provide for the integrity of encrypted data shares Page 25 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 using HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, or GCM. In addition an optional configurable second layer of integrity will be provided using either HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, HMAC-SHA512, DSA, ECDSA, or RSA. 6. All Secret and Private Keys entered via the module's keystore_addKeyFromBuffer( ) service are encrypted using RSA key wrapping. All Secret and Private Keys entered/output via the module's parser_parseData( ) and parser_restoreData( ) services are encrypted using NIST Key Wrapping. 7. Physical Security The requirements of Section 4.5 of FIPS 140-2 Physical Security are not applicable as the SecureParser is a software-only module which operates on a general purpose computer. 8. Mitigation of Other Attacks Policy The SecureParser module has not been designed to mitigate any specific attacks. 9. References OpenSSL: This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org) Page 26 Security First Corp. SecureParser Security Policy Version 1.35 Revision 9/23/2010 10. Definitions and Acronyms Share A partition of data created after the SecureParser is enacted to parse data. Mandatory Share A mandatory share is a share that must be present for the proper recovery of data. In other words, all mandatory shares must be available. The number of mandatory shares is denoted by L. Non-mandatory Share The SecureParser allows for the reconstruction of data with a subset of non-mandatory shares. The number of non-mandatory shares is denoted by N and the number of non-mandatory shares that must be available to restore is denoted by M. M of N In this document, we refer to M of N shares which is intended to mean M of N non-mandatory shares and L mandatory shares. For example, “without M of N shares...” means without at least M non-mandatory shares and L mandatory shares. Trusted Something that is trusted is known to meet its security assumptions. For example, a trusted share is known to be valid, untampered with, and otherwise uncompromised by any adversaries. Workgroup key This can be any encryption key that can be used to encrypt or decrypt data. Often it is a shared key between users of the application working together. Integrity Authentication key: This can be any key used for generating or verifying a MAC or signature of data. Information Dispersal Algorithm (IDA): An algorithm, possibly keyed, that divides information into multiple components. An IDA may add redundancy to allow the information to be recovered if some of the components are unavailable. Each IDA has an inverse algorithm that, when given some or all of the aforementioned components, produces the original information. Page 27