FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module & GLOBO’ FIPS 140-2 Non-Proprietary Security Policy Globo Plc Mobile Cryptographic Module Software Version 1.0 Document Version 1.1 September 17, 2014 Prepared For: Prepared By: ” g . © GLOBO wW Safelogic Globo Plc SafeLogic Inc. 190 High Street 530 Lytton Avenue Tonbridge - Kent Suite 200 TNO 1BE U.K Palo Alto, CA 94301 www.globoplc.com www.safelogic.com Document Version 1.01 © Globo Plc Page 1 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module Abstract This document provides a non-proprietary FIPS 140-2 Security Policy for Globo Plc Mobile Cryptographic Module. Document Version 1.01 © Globo Plc Page 2 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module Table of Contents 1 Introduction .. 1.1 About FIPS 140 1.2 About this Document. 1.3 External Resources .... 1.4 15 U OU U WU Wu 2 Globo Plc Mobile Cryptographic Module . 2.1 Cryptographic Module Specification 2.1.1 Validation Level Detail . 2.1.2 Approved Cryptographic Algorithms . 2.13 Non-Approved Cryptographic Algorithms. 2.2 Module Interfaces 2.3 Roles, Services, and Authenticatio! 2.3.1 Operator Services and Descriptions... 2.3.2 Operator Authentication.. 2.4 Physical Security... 2.5 Operational Environment … 2.6 Cryptographic Key Management. 2.6.1 Random Number Generation. N 2.6.2 Key/Critical Security Parameter (CSP) Authorized Access and Use by Role and Service/Function 2.6.3 Key/CSP Storage... 2.6.4 Key/CSP Zeroization.. 2.7 Self-Tests.... 2.7.1 Power-On Self-Tests 2.7.2 Conditional Self-Tests 2.73 Cryptographic Function 2.8 Mitigation of Other Attacks. 3 Guidance and Secure Operation 3.1 Crypto Officer Guidance... 3.1.1 Software Installation... 3.1.2 Additional Rules of Operation... 3.2 User Guidance . 3.2.1 General Guidance . Document Version 1.01 © Globo Pic Page 3 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module List of Tables Table 1 - Acronyms and Terms Table 2 — Validation Level by FIPS 140-2 Section .. Table 3 — FIPS-Approved Algorithm Certificates... Table 4 - Logical Interface / Physical Interface Mapping Table 5 - Module Services, Roles, and Descriptions ... Table 6 - Module Keys/CSPs Table 7 - Power-On Self-Tests.... Table 8 - Conditional Self-Tests ..... List of Figures Figure 1 — Module Boundary and Interfaces Diagram.... Document Version 1.01 © Globo Plc Page 4 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 1 Introduction 1.1 About FIPS 140 Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Communications Security Establishment Canada (CSEC) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. The NVLAP accredits independent testing labs to perform FIPS 140 testing; the CMVP validates modules meeting FIPS 140 validation. Validated is the term given to a module that is documented and tested against the FIPS 140 criteria. More information is available on the CMVP website at http://csrc.nist.gov/groups/STM/cmvp/index.html. 1.2 About this Document This non-proprietary Cryptographic Module Security Policy for the Globo Plc Mobile Cryptographic Module from Globo Plc provides an overview of the product and a high-level description of how it meets the security requirements of FIPS 140-2. This document contains details on the module’s cryptographic keys and critical security parameters. This Security Policy concludes with instructions and guidance on running the module in a FIPS 140-2 mode of operation. Globo Plc Mobile Cryptographic Module may also be referred to as the “module” in this document. 1.3 External Resources The Globo Plc website (www.globoplc.com) contains information on Globo Plc services and products. The Cryptographic Module Validation Program website contains links to the FIPS 140-2 certificate and Globo Plc contact information. 1.4 Notices This document may be freely reproduced and distributed in its entirety without modification. 1.5 Acronyms The following table defines acronyms found in this document: Document Version 1.01 © Globo Plc Page 5 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface BT BlueTooth CMVP Cryptographic Module Validation Program co Crypto Officer CSEC Communications Security Establishment Canada CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DSA Digital Signature Algorithm EC Elliptic Curve EMC Electromagnetic Compatibility EMI Electromagnetic Interference FC Federal Communications Commission FIPS Federal Information Processing Standard GPD General Purpose Device GUI Graphical User Interface HMAC (Keyed-) Hash Message Authentication Code KAT Known Answer Test MAC Message Authentication Code MD Message Digest NVLAP National Voluntary Laboratory Accreditation Program NIST National Institute of Standards and Technology os Operating System PKCS Public-Key Cryptography Standards PRNG Pseudo Random Number Generator PSS Probabilistic Signature Scheme RF Radio Frequency RNG Random Number Generator RSA Rivest, Shamir, and Adleman SHA Secure Hash Algorithm SSL Secure Sockets Layer Triple-DES Triple Data Encryption Algorithm TLS Transport Layer Security USB Universal Serial Bus Table 1 — Acronyms and Terms Document Version 1.01 © Globo Plc Page 6 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2 Globo Plc Mobile Cryptographic Module 2.1 Cryptographic Module Specification The Globo Plc Mobile Cryptographic Module provides cryptographic functions for Globo Plc mobile products and solutions. The module's logical cryptographic boundary is the shared library files and their integrity check HMAC files. The module is a multi-chip standalone embodiment installed on a General Purpose Device. All operations of the module occur via calls from host applications and their respective internal daemons/processes. As such there are no untrusted services calling the services of the module. 2.1.1 Validation Level Detail The following table lists the level of validation for each area in FIPS 140-2: FIPS 140-2 Section Title Validation Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services, and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 Electromagnetic Interference / Electromagnetic Compatibility 1 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A Table 2 - Validation Level by FIPS 140-2 Section 2.1.2 Approved Cryptographic Algorithms The module’s cryptographic algorithm implementations have received the following certificate numbers from the Cryptographic Algorithm Validation Program: Document Version 1.01 © Globo Plc Page 7 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module CAVP CAVP LE any Certificate for Certificate for ios Android AES 2126 2125 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC- SHA-384, HMAC- 1297 1296 SHA-512 DSA, DSA 2 667 666 FIPS 186-2 POR Ver: Sig Ver- 1024-bit F186-4 PQG Gen: 2048 & 3072 (using SHA-2) PQG Ver: 1024, 2048 & 3072 (using SHA-1 and SHA-2) Key Pair: 2048-bit & 3072-bit Sig Gen: 2048-bit & 3072-bit (using SHA-2) Sig Ver: 1024-bit. 2048-bit & 3072-bit (using SHA-1 & SHA-2) ECDSA, ECDSA2 320 319 FIPS 186-2 PKG: Curves (P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B- 233, B-409 & B-571) PKV: Curves All P, K&B FIPS 186-4 PKG: Curves (P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B- 283, B-409 & B-571) PKV: Curves All P, K&B Sig Gen: (P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B-283, B-409 & B-571) (SHA-2) Sig Ver: Curves P-192, P224, P-256, P-384, P-521, K-163, K-233, K-283, B- 163, B-233, B-283, B-409 & B-571 (any SHA size) K-409 & K-571 (SHA-1) Document Version 1.01 © Globo Plc Page 8 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module RSA (X9.31, PKCS #1.5, PSS) 1095 1094 FIPS 186-2 ANSIX9.31 Key Gen: 2048-bit, 3072-bit & 4096-bit Sig Gen: 2048-bit, 3072-bit & 4096 bit (any SHA size) Sig Ver: 1024-bit, 1536-bit, 2048-bit, 3072-bit & 4096-bit (any SHA size) PKCS1V15 Sig Gen: 2048-bit, 3072-bit & 4096-bit (any SHA size) Sig Ver: 1024-bit, 1536-bit, 2048-bit, 3072-bit & 4096-bit (any SHA size) PSS Sig Gen: 2048-bit, 3072-bit & 4096-bit (any SHA size) Sig Ver: 1024-bit, 1536-bit, 2048-bit, 3072-bit & 4096-bit (any SHA size) FIPS 186-4 ANSIX9.31 Sig Gen: 2048-bit (using SHA-2) Sig Ver: 1024-bit, 2048-bit, & 3072-bit (any SHA size) PKCS1 V15 Sig Gen: 2048-bit & 3072-bit (using SHA-2) Sig Ver: 1024-bit, 2048-bit, & 3072-bit (any SHA size) PSS Sig Gen: 2048-bit & 3072-bit (using SHA-2) Sig Ver: 1024-bit, 2048-bit, & 3072-bit (any SHA size) SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 1850 1849 Triple-DES 1352 1351 Note: the use of two-key Triple DES for encryption is restricted through December 31%, 2015: the total number of blocks of data encrypted with the same cryptographic key shall not be greater than 2420. After December 31, 2015, two-key Triple DES shall not be used for encryption. RNG (ANSI X9.31) 1092 1091 SP 800-90 DRBG (Hash_DRBG, HMAC_DRBG, CTR_DRBG, Dual_EC_DRBG) 234 233 CVL (ECC CDH KAS) 29 28 Table 3 - FIPS-Approved Algorithm Certificates Document Version 1.01 © Globo Plc Page 9 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2.1.3. Non-Approved Cryptographic Algorithms The module supports the following non-FIPS 140-2 approved but allowed algorithms: * RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of encryption strength; non-compliant less than 112 bits of encryption strength) * EC Diffie-Hellman (key agreement; key establishment methodology provides between 112 and 256 bits of encryption strength; non-compliant less than 112 bits of encryption strength) The following algorithms are disallowed as of January 1, 2014 per the NIST SP 800-131A algorithm transitions: * FIPS 186-2 DSA (using SHA-1): PQG Gen- 1024-bit * FIPS 186-4 DSA * FIPS 186-2 RSA * FIPS 186-4 RSA Document Version 1.01 Key Gen- 1024-bit Sig Gen- 1024-bit PQG Gen, 1024-bit (any SHA size) Key Gen, 1024-bit Sig Gen, 1024-bit (any SHA size), 2048-bit & 3072-bit using SHA-1 ANSIX9.31 Key Gen 1024 & 1536 ANSIX9.31 Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA-1 PKCSIV15 Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA-1 PSS Sig Gen 1024 & 1536 (any SHA size); 2048, 3072 & 4096 using SHA-1 ANSIX9.31 Sig Gen 1024 using SHA-1 PKCSIV15 Sig Gen 1024 using SHA-1 PSS Sig Gen 1024 using SHA-1 © Globo Pic Page 10 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module * FIPS 186-2 ECDSA PKG: Curves P-192, K-163 & B-163 Sig Gen Curves All P, K&B * FIPS 196-4 ECDSA PKG: Curves P-192, K-163 & B-163 Sig Gen Curves P-224, P-256, P-384, P-521, K-233, K-283, K-409, K-571, B-233, B-283, B-409 & B-571) (using SHA-1) P-192-, K-163 & B-163 (any SHA size) 2.2 Module Interfaces The figure below shows the module’s physical and logical block diagram: Interface = ABC Interface = A BC Interface = ABCE Vo rca Operating System App Center WIFI / BT Data/Power Transceiver Transceiver Port MC [ce NETT ( N Comms Apps Processor Processor [EEE SIR REN] ( GPS N = Ciphertext (“interface Legend \ A= Data Input B= Data Output C= Control Input D =Status Output E=Power Gyroscope Audio Codec ! ' = Plaintext Accelerometer M = Logical Boundary Interface = CD O2 = Physical Boundary Figure 1- Module Boundary and Interfaces Diagram The interfaces (ports) for the physical boundary include the Data/power port, WIFI / BT Transceiver, RF Transceiver, and LCD. When operational, the module does not transmit any information across these Document Version 1.01 © Globo Plc Page 11 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module physical ports because it is a software cryptographic module. Therefore, the module’s interfaces are purely logical and are provided through the Application Programming Interface (API) that a calling daemon can operate. The logical interfaces expose services that applications directly call, and the API provides functions that may be called by a referencing application (see Section 2.3 — Roles, Services, and Authentication for the list of available functions). The module distinguishes between logical interfaces by logically separating the information according to the defined API. The API provided by the module is mapped onto the FIPS 140- 2 logical interfaces: data input, data output, control input, and status output. Each of the FIPS 140- 2 logical interfaces relates to the module’s callable interface, as follows: FIPS 140-2 Interface Logical Interface Module Physical Interface Data Input Input parameters of API function Data/power port calls WIFI / BT Transceiver RF Transceiver Data Output Output parameters of API function | Data/power port calls WIFI / BT Transceiver RF Transceiver Control Input API function calls Data/power port WIFI / BT Transceiver RF Transceiver LCD Status Output For FIPS mode, function calls LCD returning status information and return codes provided by API function calls. Power None Data/power port Table 4 — Logical Interface / Physical Interface Mapping As shown in Figure 1— Module Boundary and Interfaces Diagram and Table 5 — Module Services, Roles, and Descriptions, the output data path is provided by the data interfaces and is logically disconnected from processes performing key generation or zeroization. No key information will be output through the data output interface when the module zeroizes keys. 2.3 Roles, Services, and Authentication The module supports a Crypto Officer and a User role. The module does not support a Maintenance role. The User and Crypto-Officer roles are implicitly assumed by the entity accessing services implemented by the Module. Document Version 1.01 © Globo Plc Page 12 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2.3.1 Operator Services and Descriptions The module supports services that are available to users in the various roles. All of the services are described in detail in the module’s user documentation. The following table shows the services available to the various roles and the access to cryptographic keys and CSPs resulting from services: Service Roles csP / Algorithm CUS Module Crypto Officer | None CO: initialization execute Symmetric User AES Key, Triple-DES? Key User: encryption/decr read/write/execute yption Digital User RSA Private Key, DSA Private Key User: signature?* read/write/execute Symmetric key User AES Key, Triple-DES Key User: generation read/write/execute Asymmetric key | User RSA Private Key, DSA Private Key User: generation read/write/execute Keyed Hash User HMAC Key User: (HMAC)* HMAC SHA-1, HMAC SHA- 224, HMAC SHA- read/write/execute 256, HMAC SHA-384, HMAC SHA-512 Message digest User SHA-1, SHA-224, SHA-256, SHA-384, SHA- User: (SHS) 512 read/write/execute Random number | User PRNG Seed and Seed Key User: generation read/write/execute Show status Crypto Officer | None User and CO: User execute Self-test User All CSPs User: read/execute Zeroize Crypto Officer | All CSPs co: read/write/execute Table 5 - Module Services, Roles, and Descriptions 2.3.2 Operator Authentication As required by FIPS 140-2, there are two roles (a Crypto Officer role and User role) in the module that operators may assume. As allowed by Level 1, the module does not support authentication to access services. As such, there are no applicable authentication policies. Access control policies are implicitly defined by the services available to the roles as specified in Table 5 — Module Services, Roles, and Descriptions. + Two-key Triple-DES is restricted and only available for legacy use in accordance with SP800-131A. ? Note that per SP800-131A, issuing 1024-bit signatures with SHA-1 is disallowed as of the end of 2013. * Indicates non-Approved services if non-Approved key sizes are utilized (<112 bits) Document Version 1.01 © Globo Plc Page 13 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2.4 Physical Security This section of requirements does not apply to this module. The module is a software-only module and does not implement any physical security mechanisms. 2.5 Operational Environment The module operates on a general purpose device (GPD) running a general purpose operating system (GPOS). For FIPS purposes, the module is running on this operating system in single user mode and does not require any additional configuration to meet the FIPS requirements. The module was tested on the following platforms: * iOS 5.1 0n iPad 3 * iOS 6 on iPad 3 * iOS 7 on iPad 3 * Android 4.0 on Galaxy Nexus Compliance is maintained for other versions of the respective operating system family where the binary is unchanged. The GPD(s) used during testing met Federal Communications Commission (FCC) FCC Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined by 47 Code of Federal Regulations, Part15, Subpart B. FIPS 140-2 validation compliance is maintained when the module is operated on other versions of the GPOS running in single user mode, assuming that the requirements outlined in NIST IG G.5 are met. 2.6 Cryptographic Key Management The table below provides a complete list of Critical Security Parameters used within the module: Storage Storage (Lin Output Keys and CSPs ca ons Method vee nt Zeroization LUE AES Key RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD Triple-DES Key RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD RSA Public Key RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD RSA Private Key* | RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD Document Version 1.01 © Globo Plc Page 14 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module Storage QUE Input Output Blei ocations Method Method Method LEGER ae DSA Public Key RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD DSA Private Key* | RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD HMAC Key* RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD PRNG Seed RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD PRNG Seed Key RAM Plaintext API call None power cycle CO: RWD parameter cleanse() U: RWD Integrity Key Module Plaintext None None None CO: RWD Binary U: RWD EC DSA Private RAM Plaintext None None power cycle CO: RWD Key cleanse() U: RWD EC DSA Public RAM Plaintext None None power cycle CO: RWD Key cleanse() U: RWD EC DH Public RAM Plaintext None None power cycle CO: RWD Components cleanse() U: RWD EC DH Private RAM Plaintext None None power cycle CO: RWD Components cleanse() U: RWD EC DRBG Entropy | RAM Plaintext None None power cycle CO: RWD cleanse() U: RWD ECDRBGSValue | RAM Plaintext None None power cycle CO: RWD (Seed Length) cleanse() U: RWD EC DRBG RAM Plaintext None None power cycle CO: RWD init_seed cleanse() U: RWD HMAC DRBG RAM Plaintext None None power cycle CO: RWD Entropy cleanse() U: RWD HMAC DRBG V RAM Plaintext None None power cycle CO: RWD Value (Seed cleanse() U: RWD Length) HMAC DRBG Key | RAM Plaintext None None power cycle CO: RWD cleanse() U: RWD HMAC DRBG RAM Plaintext None None power cycle CO: RWD init_seed cleanse() U: RWD R=Read W=Write D=Delete * Indicates non-Approved services if non-Approved key sizes are utilized (<112 bits) Table 6 - Module Keys/CSPs The application that uses the module is responsible for appropriate destruction and zeroization of the key material. The module provides functions for key allocation and destruction which overwrite the memory that is occupied by the key information with zeroes before it is deallocated. Document Version 1.01 © Globo Pic Page 15 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2.6.1 Random Number Generation The module uses ANSI X9.31 and DRBG for creation of asymmetric and symmetric keys. The module accepts input from entropy sources external to the cryptographic boundary for use as seed material for the module’s Approved RNGs. This external entropy source provides an estimated minimum amount of 93 bits of entropy, which limits the strength of the generated key. The module performs continual tests on the random numbers it uses to ensure that the seed and seed key input to the Approved RNG do not have the same value. The module also performs continual tests on the output of the approved RNG to ensure that consecutive random numbers do not repeat. 2.6.2 Key/Critical Security Parameter (CSP) Authorized Access and Use by Role and Service/Function An authorized application as user (the User role) has access to all key data generated during the operation of the module. 2.6.3 Key/CSP Storage Public and private keys are provided to the module by the calling process and are destroyed when released by the appropriate API function calls or during power cycle. The module does not perform persistent storage of keys. 2.6.4 Key/CSP Zeroization The application is responsible for calling the appropriate destruction functions from the API. The destruction functions then overwrite the memory occupied by keys with zeroes and deallocates the memory. This occurs during process termination / power cycle. Keys are immediately zeroized upon deallocation, which sufficiently protects the CSPs from compromise. 2.7 Self-Tests FIPS 140-2 requires that the module perform self-tests to ensure the integrity of the module and the correctness of the cryptographic functionality at start up. In addition some functions require continuous verification of function, such as the random number generator. All of these tests are listed and described in this section. In the event of a self-test error, the module will log the error and will halt. The module must be initialized into memory to resume function. The following sections discuss the module’s self-tests in more detail. 2.7.1 Power-On Self-Tests Power-on self-tests are executed automatically when the module is loaded into memory. The module verifies the integrity of the runtime executable using a HMAC-SHA1 digest computed at build time. If the Document Version 1.01 © Globo Plc Page 16 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module fingerprints match, the power-up self-tests are then performed. If the power-up self-test is successful, a flag is set to place the module in FIPS mode. Document Version 1.01 © Globo Plc Page 17 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module TYPE DETAIL Software Integrity Check * _HMAC-SHA1 on all module components Known Answer Tests” * AES encrypt/decrypt * AES GCM * AES CCM + XTS-AES + AES CMAC + Triple-DES CMAC + EC Diffie-Hellman + HMAC-SHAI + HMAC-SHA224 * HMAC-SHA256 * HMAC-SHA384 * HMAC-SHA512 * RSA + SHA-1 + SHA-224 + SHA-256 + SHA-384 + SHA-512 + X9.31 RNG + SP 800-90 DRBG (Hash_DRBG, HMAC_DRBG, CTR_DRBG, Dual_EC_DRBG) + Triple-DES encrypt/decrypt Pair-wise Consistency Tests + DSA + RSA *__ECDSA Table 7 - Power-On Self-Tests Input, output, and cryptographic functions cannot be performed while the Module is in a self-test or error state because the module is single-threaded and will not return to the calling application until the power-up self-tests are complete. If the power-up self-tests fail, subsequent calls to the module will also fail - thus no further cryptographic operations are possible. ® Note that all SHA-X KATs are tested as part of the respective HMAC SHA-X KAT. SHA-1 is also tested independently. Document Version 1.01 © Globo Plc Page 18 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 2.7.2 Conditional Self-Tests The module implements the following conditional self-tests upon key generation, or random number generation (respectively): TYPE DETAIL Pair-wise Consistency Tests * DSA * RSA * ECDSA Continuous RNG Tests * Performed on all approved PRNGs Table 8 — Conditional Self-Tests 2.7.3. Cryptographic Function The module verifies the integrity of the runtime executable using a HMAC-SHA1 digest which is computed at build time. If this computed HMAC-SHA1 digest matches the stored, known digest, then the power-up self-test (consisting of the algorithm-specific Pairwise Consistency and Known Answer tests) is performed. If any component of the power-up self-test fails, an internal global error flag is set to prevent subsequent invocation of any cryptographic function calls. Any such power-up self-test failure is a hard error that can only be recovered by reinstalling the module’. The power-up self-tests may be performed at any time by reloading the module. No operator intervention is required during the running of the self-tests. 2.8 Mitigation of Other Attacks The Module does not contain additional security mechanisms beyond the requirements for FIPS 140-2 Level 1 cryptographic modules. * The initialization function could be re-invoked but such re-invocation does not provide a means from recovering from an integrity test or known answer test failure Document Version 1.01 © Globo Plc Page 19 of 20 FIPS 140-2 Non-Proprietary Security Policy: Globo Plc Mobile Cryptographic Module 3 Guidance and Secure Operation 3.1 Crypto Officer Guidance 3.1.1 Software Installation The module is not available for direct download to the general public. The module and its host application are to be installed on an operating system specified in Section 2.5 or one where portability is maintained. 3.1.2 Additional Rules of Operation 1. The writable memory areas of the module (data and stack segments) are accessible only by the application so that the operating system is in "single user" mode, i.e. only the application has access to that instance of the module. 2. The operating system is responsible for multitasking operations so that other processes cannot access the address space of the process containing the module. 3.2 User Guidance 3.2.1 General Guidance The module is not distributed as a standalone library and is only used in conjunction with the solution. The end user of the operating system is also responsible for zeroizing CSPs via wipe/secure delete procedures. If the module power is lost and restored, the calling application can reset the IV to the last value used. Document Version 1.01 © Globo Plc Page 20 of 20