Non‐Proprietary Security Policy:  μMACE  Cryptographic module for the Motorola Solutions CRYPTR Micro which is used  in the AME product line               Version: R01.07.06 Date: February 4, 2015 Non-Proprietary Security Policy: µMACE Page 1 of 31 Table of Contents 1.  INTRODUCTION ............................................................................................................................................................... 4  1.1.  SCOPE ............................................................................................................................................................................. 4  1.2.  DEFINITIONS ................................................................................................................................................................ 4  1.3.  OVERVIEW ................................................................................................................................................................... 4  1.4.  µMACE IMPLEMENTATION..................................................................................................................................... 4  1.5.  µMACE HARDWARE / FIRMWARE VERSION NUMBERS................................................................................. 5  1.6.  µMACE CRYPTOGRAPHIC BOUNDARY ............................................................................................................... 5  THE CRYPTO BOUNDARY IS DRAWN AROUND THE µMACE AS SHOWN BELOW................................................ 6  1.7.  PORTS AND INTERFACES......................................................................................................................................... 7  2.  FIPS 140-2 SECURITY LEVELS ...................................................................................................................................... 8  3.  FIPS 140-2 APPROVED OPERATIONAL MODES ....................................................................................................... 9  3.1.  CONFIGURATION SETTINGS FOR OPERATION AT FIPS 140-2 OVERALL SECURITY LEVEL 3 .......... 9  3.2.  NON APPROVED MODE OF OPERATION ........................................................................................................... 10  4.  CRYPTO OFFICER AND USER GUIDANCE ............................................................................................................. 11  4.1.  ADMINISTRATION OF THE µMACE IN A SECURE MANNER (CO) .............................................................. 11  4.2.  ASSUMPTIONS REGARDING USER BEHAVIOR (CO) ...................................................................................... 11  4.3.  APPROVED SECURITY FUNCTIONS, PORTS, AND INTERFACES AVAILABLE TO USERS................... 11  4.4.  USER RESPONSIBILITIES NECESSARY FOR SECURE OPERATION........................................................... 11  5.  SECURITY RULES .......................................................................................................................................................... 12  5.1.  FIPS 140-2 IMPOSED SECURITY RULES .............................................................................................................. 12  6.  IDENTIFICATION AND AUTHENTICATION POLICY ........................................................................................... 15  7.  PHYSICAL SECURITY POLICY .................................................................................................................................. 17  8.  AES-256 GCM NON-INTERNAL IV GENERATION PROTOCOL .......................................................................... 18  9.  ACCESS CONTROL POLICY........................................................................................................................................ 19  9.1.  µMACE SUPPORTED ROLES .................................................................................................................................. 19  9.2.  µMACE SERVICES AVAILABLE TO THE USER ROLE VIA SDIO INTERFACE. ........................................ 19  Non-Proprietary Security Policy: µMACE Page 2 of 31 9.3.  µMACE SERVICES AVAILABLE TO THE USER ROLE VIA KVL INTERFACE. ......................................... 20  9.4.  µMACE SERVICES AVAILABLE TO THE CRYPTO-OFFICER ROLE. .......................................................... 20  9.5.  µMACE SERVICES AVAILABLE WITHOUT A ROLE. ...................................................................................... 20  9.6.  CRITICAL SECURITY PARAMETERS (CSPS) AND PUBLIC KEYS ............................................................... 21  9.7.  CSP ACCESS TYPES .................................................................................................................................................. 27  10.  MITIGATION OF OTHER ATTACKS POLICY ......................................................................................................... 31  Non-Proprietary Security Policy: µMACE Page 3 of 31 1. Introduction 1.1. Scope This Security Policy specifies the security rules under which the µMACE must operate. In addition to the security requirements derived from FIPS 140-2 are those imposed by Motorola. These rules, in total, define the interrelationship between the:  Module Operators,  Module Services, and  Critical Security Parameters (CSPs). 1.2. Definitions CBC Cipher Block Chaining CFB Cipher Feedback CSP Critical Security Parameter DES Data Encryption Standard DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm ECMQV Elliptic Curve Menezes-Qu-Vanstone IKE Internet Key Exchange IPSec Internet Protocol security IV Initialization Vector KLK Key Loss Key KPK Key Protection Key KVL Key Variable Loader LED Light-emitting diode OTAR Over The Air Rekeying PEK Password Encryption Key RAM Random Access Memory RNG Random Number Generator 1.3. Overview The µMACE provides secure key management and data encryption for the Motorola Solutions CRYPTR Micro which is used in the following broadband and LTE Systems:  ES400 phone  AME2000 line of secure phones  MCC7100 Dispatch Console 1.4. µMACE Implementation The µMACE is implemented as a single chip cryptographic module as defined by FIPS 140-2. Non-Proprietary Security Policy: µMACE Page 4 of 31 1.5. µMACE Hardware / Firmware Version Numbers The µMACE has the following FIPS validated hardware and firmware version numbers: Table 1: FIPS Validated Version Numbers FIPS Validated Cryptographic FIPS Validated Cryptographic Module Hardware Kit Module Firmware Version Numbers Numbers AT58Z04 R01.07.01 1.6. µMACE Cryptographic Boundary The µMACE in the block diagram below provides data security services required by the CRYPTR Micro product. The module is a single µMACE processor with the set of interfaces shown in the diagram below. Figure 1: µMACE Block Diagram Non-Proprietary Security Policy: µMACE Page 5 of 31 The Crypto Boundary is the µMACE chip as shown below. Figure 2: µMACE Non-Proprietary Security Policy: µMACE Page 6 of 31 1.7. Ports and Interfaces The µMACE provides the following physical ports and logical interfaces: Table 3: Ports and Interfaces Physical Logical interface Qty Description Port definition This interface powers all circuitry. Power 1 Power Input This interface does not support input / output of CSP’s. Clock Input. Clock 1 Control Input This interface does not support input / output of CSP’s. Tamper Input. Tamper 1 Control Input This interface does not support input / output of CSP’s. Self-test This interface provides status output to indicate all power-up self-tests Status Status Output 1 completed successfully. Indicator Reset 1 Control Input This interface forces a reset of the module. Control Input Provides an interface for factory programming and execution of SDIO SDIO Status Output 1 commands. All CSPs exchanged over this interface are always Interface Data Output encrypted when operating in FIPS approved mode. Data Input Control Input Provides an interface to the Key Variable Loader. The KEKs and TEKs Key Variable Status Output are entered in encrypted form over the KVL interface. All CSPs Loader (KVL) 1 Data Output exchanged over this interface are always encrypted when in FIPS Interface Data Input approved mode. Non-Proprietary Security Policy: µMACE Page 7 of 31 2. FIPS 140-2 Security Levels The µMACE can be configured to operate at FIPS 140-2 overall Security Level 3. The table below shows the FIPS 140-2 Level of security met for each of the eleven areas specified within the FIPS 140-2 security requirements. Table 4: µMACE Security Levels FIPS 140-2 Security Requirements Validated Level at Section overall Security Level 3 Cryptographic Module Specification 3 Module Ports and Interfaces 3 Roles, Services, and Authentication 3 Finite State Model 3 Physical Security 3 Operational Environment N/A Cryptographic Key Management 3 EMI / EMC 3 Self-Tests 3 Design Assurance 3 Mitigation of Other Attacks N/A Non-Proprietary Security Policy: µMACE Page 8 of 31 3. FIPS 140-2 Approved Operational Modes The µMACE can be configured to operate in a FIPS 140-2 Approved mode of operation and a non- FIPS Approved mode of operation. CSPs are not shared between FIPS Approved mode and non- FIPS Approved mode. The transition from a FIPS Approved mode to a non-FIPS Approved mode causes all CSPs to be zeroized. In response to the Version Query service request the module will return the following data which can be used to determine whether the module is operating at overall Security Level 3 or in a non-FIPS Approved mode. FIPS Status Information Item ID 0x06 FIPS Status Information Item Length 0x01 FIPS Status Information Item Data 1 byte indicating the FIPS operating status of the module. The possible values are: - 0x00 – Not operating in a FIPS approved mode - 0x03 – Operating in a FIPS 140 Level 3 approved mode The Version Query service can also be used to verify the firmware version matches an approved version listed on NIST’s website: http://csrc.nist.gov/groups/STM/cmvp/validation.html 3.1. Configuration Settings for operation at FIPS 140-2 overall Security Level 3 Documented below are the actions and configuration settings required for the module to be used in a FIPS 140-2 Approved mode of operation at overall Security Level 3. 1. Disable Clear Key Import. The Module Configuration service is used to configure this parameter in the module. When this configuration setting is disabled, clear key import will be disallowed. 2. Disable Clear Key Export. The Module Configuration service is used to configure this parameter in the module. When this configuration setting is disabled, clear key export will be disallowed. 3. Disable Key Loss Key (KLK). The Module Configuration service is used to configure this parameter in the module. 4. Disable Red Keyloading. The Module Configuration service is used to configure this parameter in the module. When this configuration setting is disabled, red key loading via the KVL interface will be disallowed. 5. Only Approved and Allowed algorithms installed. The module supports the following Approved algorithms:  AES-256 8-bit CFB (Cert. #1876) – used for symmetric encryption / decryption of keys and parameters stored in the internal database  AES-256 ECB (Cert. #1876) - for use with key wrap  AES-256 CBC (Cert. #1876) - for firmware upgrades  AES-256 CTR (Cert. #2146)  AES-256 OFB (Cert. #2146)  AES-256 GCM (Cert. #2146) Non-Proprietary Security Policy: µMACE Page 9 of 31  AES-128 ECB (Cert. #3089)  AES-128 CBC (Cert. #3089)  AES-128 OFB (Cert. #3089)  AES-128 CTR (Cert. #3089)  SHA-384 (Cert. #1619) – used for digital signature verification during firmware integrity test and firmware load test. Used for password hashing for internal password storage.  HMAC SHA-384 (Cert. #1313)  SP800-56A KAS (Cert. #28) – (key agreement; key establishment methodology provides 192 bits of encryption strength)  ECDSA P-384 (Cert. #263) – used for digital signature verification during firmware integrity test and firmware load test, and for key generation and signature generation. The module supports the following allowed algorithms:  AES (Cert. #1876, key wrapping; key establishment methodology provides 256 bits of encryption strength) – used for key encryption  AES MAC (Cert. #1876) – Used to provide authentication within APCO OTAR. AES MAC as used within APCO OTAR has been vendor affirmed and is approved when used for Project 25 APCO OTAR. The following non-Approved algorithms and protocols are allowed within the Approved mode of operation:  Non-deterministic Hardware Random Number Generator – used for IV and key generation. This NDRNG is NSA approved. 3.2. Non Approved Mode of Operation A non-FIPS Approved mode of operation is transitioned to when any of the following is true: 1. Clear Key Import is enabled. 2. Clear Key Export is enabled. 3. KLK generation is enabled. 4. Red Keyloading is enabled. It should be noted that The FIPS mode status is a persistent parameter; the module will maintain its FIPS mode (indicating this mode to the operator upon request), until the above parameters are changed. Non-Proprietary Security Policy: µMACE Page 10 of 31 4. Crypto Officer and User Guidance 4.1. Administration of the µMACE in a secure manner (CO) The µMACE requires no special administration for secure use after it is set up for use in a FIPS Approved manner. To do this, configure the module as described in Section 3 of this document. Note that all keys will be zeroized after the Program Update service has completed. 4.2. Assumptions regarding User Behavior (CO) The µMACE has been designed in such a way that no special assumptions regarding User Behavior have been made that are relevant to the secure operation of the unit. 4.3. Approved Security Functions, Ports, and Interfaces available to Users µMACE services available to the User role are listed in section 8.2. No Physical Ports or Logical Interfaces are directly available to the µMACE User, only indirectly through the host product in which the µMACE is installed. 4.4. User Responsibilities necessary for Secure Operation To ensure the secure operation of the µMACE the operator should periodically check the module for evidence of tamper. It is recommended that the µMACE be checked for evidence of tamper every 6 months. Non-Proprietary Security Policy: µMACE Page 11 of 31 5. Security Rules The µMACE enforces the following security rules. 5.1. FIPS 140-2 Imposed Security Rules 1. The µMACE inhibits all data output via the data output interface whenever an error state exists and during self-tests. 2. The µMACE logically disconnects the output data path from the circuitry and processes when performing key generation or key zeroization. 3. Authentication data (e.g., passwords) are entered in encrypted form. Authentication data is not output during entry. 4. Secret and private cryptographic keys are entered in encrypted form. 5. The µMACE does not support manual key entry. 6. The µMACE enforces Identity-Based authentication. 7. The µMACE supports a User role (SDIO interface and KVL interface), and a Crypto-Officer role. The module will verify the authorization of the operator to assume each role. 8. The µMACE does not support concurrent operators. 9. The µMACE re-authenticates an operator when it is powered-up after being powered-off. 10. The µMACE implements all firmware using a high-level language, except the limited use of low-level languages to enhance performance. 11. The µMACE protects secret keys and private keys from unauthorized disclosure, modification, and substitution. 12. The µMACE provides a means to ensure that a key entered into or stored within the module is associated with the correct entities to which the key is assigned. Each key in the µMACE is entered encrypted and stored with the following information:  Key Identifier – 16 bit identifier  Algorithm Identifier – 8 bit identifier  Key Type – Traffic Encryption Key or Key Encryption Key  Physical ID – Identifier indicating storage locations. Along with the encrypted key data, this information is stored in a key record that includes a CRC over all fields to protect against data corruption. 13. The µMACE denies access to plaintext secret and private keys contained within the module. 14. The Program Update service can be used to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the module. 15. The µMACE conforms to FCC 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B requirements. 16. The µMACE performs the following self-tests. Powering the module off then on will initiate the power up self-tests.  Power up and on-demand tests - Cryptographic algorithm test: A cryptographic algorithm test using a known answer is conducted for all cryptographic functions (e.g., encryption, decryption, authentication, and hashing.) for each Approved algorithm listed below. The test passes if the final data matches the known data, otherwise it fails. - AES-256 encrypt / decrypt known-answer tests for 8-bit CFB, ECB, and CBC Non-Proprietary Security Policy: µMACE Page 12 of 31 modes (Cert. #1876) - AES-256 encrypt / decrypt known-answer tests for OFB, GCM, and CTR modes (Cert. #2146) - AES-128 encrypt /decrypt known-answer tests for ECB, CBC, OFB, and CTR modes (Cert #3089) - SHA-384 known answer test (Cert. #1619) - HMAC SHA-384 known answer test (Cert. #1313) - SP800-56A KAS (ECDH and ECMQV) known answer test (Cert. #28) - ECDSA P-384: signature generation/verification known answer test (Cert. #263) - ECDSA P-384: key generation known answer test (Cert. #263) - Firmware integrity test: A digital signature is generated over the code when it is built using SHA-384 and ECDSA P-384 and is stored with the code upon download into the module. When the module is powered up the digital signature is verified. If the digital signature matches, then the test passes, otherwise it fails. - Critical functions test: - -the module performs a read/write test of the internal RAM at each power up. -Random Number Generator entropy test. This test runs two RNG statistical tests: a FIPS monobit test, and a FIPS “runs” test -  Conditional tests - Firmware load test: A digital signature is generated over the code when it is built using SHA-384 and ECDSA P-384. Upon download into the module, the digital signature is verified. If the digital signature matches, then the test passes, otherwise it fails. - Continuous Random Number Generator test: The continuous random number generator test is performed on all RNGs supported by the module (NDRNG). An initial value is generated and stored upon power up. This value is not used for anything other than to initialize comparison data. A successive call to any one of the RNGs generates a new set of data, which is compared to the comparison data. If a match is detected, this test fails; otherwise the new data is stored as the comparison data and returned to the caller. This testing is done for each 4 byte RNG data block, generated by the NDRNG. - Pair-wise consistency test (for public and private keys used to perform the calculation and verification of digital signatures): The ECDSA Public and Private Generated Signature Key pair is tested by the calculation and verification of a digital signature. If the digital signature cannot be verified, the test fails. 17. The µMACE toggles the Self-test Indicator interface within 2 seconds of power-up to indicate the Firmware Integrity Test, Firmware Load Test, Cryptographic Algorithm Test, and Critical Functions Test have completed successfully. The µMACE enters the Critical Error state and does not toggle the Self-test Indicator interface if the Firmware Integrity Test, Firmware Load Test, Cryptographic Algorithm Test, or Critical Functions Test fails. The Critical Error state may be exited by powering the module off then on. 18. The µMACE enters the Critical Error state and outputs a message over the SDIO interface to indicate the Continuous Random Number Generator Test and Pair-wise Consistency Non-Proprietary Security Policy: µMACE Page 13 of 31 tests have failed. The Critical Error state may be exited by powering the module off then on. 19. The µMACE does not perform any cryptographic functions while in an error state. Non-Proprietary Security Policy: µMACE Page 14 of 31 6. Identification and Authentication Policy The µMACE supports a User role and a Crypto-Officer role. The Crypto-Officer and User roles are authenticated with passwords. The Crypto-Officer and User passwords are initialized to a default value during manufacturing and are sent in encrypted form to the module for authentication. After authenticating, the Crypto-Officer and User passwords may be changed at any time. The User role is also authenticated by the KVL-BKK for OTAR and Store & Forward services. Table 5: Roles and Authentication Role Authenticati Authentication Strength of Authentication on Type Mechanism Crypto- Identity- Identity: a 4-byte Since the minimum password length is 14 Officer Based identifier is used to ASCII printable characters and there are identify the identity 95 ASCII printable characters, the and role. The probability of a successful random µMACE supports a attempt is 1 in 95 ^ 14 or 1 in single identity. 4,876,749,791,155,298,590,087,890,625. Crypto-Officer The module limits the number of Password: a 14-32 authentication attempts in one minute to character ASCII 15. The probability of a successful password is random attempt during a one-minute authenticated to gain period is 15 in 95 ^ 14 or 1 in access to all Crypto- 3.25117e+26. Officer services. User Identity- Identity: a 4-byte Since the minimum password length is 14 (SDIO Based identifier is used to ASCII printable characters and there are Interface) identify the identity 95 ASCII printable characters, the and role. The probability of a successful random µMACE supports a attempt is 1 in 95 ^ 14 or 1 in single identity. 4,876,749,791,155,298,590,087,890,625. User Password: a 14- The module limits the number of 32 character ASCII authentication attempts in one minute to password is 15. The probability of a successful authenticated to gain random attempt during a one-minute access to all User period is 15 in 95 ^ 14 or 1 in services. 3.25117e+26. User (KVL Identity- Identity: a 1-byte The probability of a successful random Interface) Based identifier is used to attempt is 1 in 2 ^ 256 which is less than identify the identity 1 in 1,000,000. Non-Proprietary Security Policy: µMACE Page 15 of 31 Role Authenticati Authentication Strength of Authentication on Type Mechanism and role. The µMACE supports a The maximum number of authentication single identity. attempts that can be performed over the KVL interface with the KVL-BKK in one KVL-BKK: a 256-bit minute is 745. Therefore the probability AES key is of a successful random attempt during a authenticated to gain one-minute period is 745 in 2 ^ 256 or 1 access to the in 1.55425e+74. services performed over the KVL interface. Non-Proprietary Security Policy: µMACE Page 16 of 31 7. Physical Security Policy The µMACE is a production grade, single-chip cryptographic module as defined by FIPS 140-2 and is designed to meet Level 3 Physical Security. The µMACE is covered with a hard opaque metallic coating that provides evidence of attempts to tamper with the module. Tampering with the module will cause it to enter a lock-up state in which no crypto services will be available. No maintenance access interface is available. Non-Proprietary Security Policy: µMACE Page 17 of 31 8. AES-256 GCM Non-Internal IV Generation Protocol In the case when the final IV value is not generated inside the module, but is generated using an internally-generated random value (salt) as described in the RFG (“GCM Key/IV Pair Uniqueness and Existing Protocols”), the following protocols shall be used:  For TLS with AES GCM as defined in RFC 5288, the IV (defined in section 3) consists of a salt that is generated internally to the module and a nonce_explicit that is passed in as it may be the sequence number.  For SRTP with AES GCM as defined in draft-ietf-avtcore-srtp-aes-gcm-10, the IV (defined in section 9.1) consists of a salt that is generated internally to the module and the Synchronization Source identifier, Rollover Counter, and sequence number are passed as parameters to the module.  For SRTCP with AES GCM as defined in draft-ietf-avtcore-srtp-aes-gcm-10, the IV defined in (section 10.1) consists of a salt that is generated internally to the module and the Syncronization Source identifier and the SRTCP index are passed as parameters to the module. The protocols mentioned above are being designed to be used with AES GCM and to prevent key and IV reuse as required by SP 800-38D. There are several documents that have been standardized or in the process of becoming standard for these protocols to use AES GCM. To generate the IV internally to minimize influencing the generation of IVs for these high level protocols, external parameters need to be passed in. Non-Proprietary Security Policy: µMACE Page 18 of 31 9. Access Control Policy 9.1. µMACE Supported Roles The µMACE supports the following roles:  User Role o SDIO Interface o KVL Interface  Crypto-Officer Role 9.2. µMACE Services Available to the User Role via SDIO Interface.  Validate User Password: Validate the current User password used to identify and authenticate the User role via the SDIO interface. Successful authentication will allow access to crypto services allowed for the User. Available in both FIPS and non-FIPS mode.  Change User Password: Modify the current password used to identify and authenticate the User Role via the SDIO interface. Available in both FIPS and non-FIPS mode.  Algorithm List Query: Provides a list of algorithms over the SDIO interface. Available in both FIPS and non-FIPS mode.  Logout User Role: Logs out the User. Available in both FIPS and non-FIPS mode.  Export Key Variable: Transfer encrypted key variables (KEKs, TEKs) out of the module over the SDIO interface. Available in both FIPS and non-FIPS mode.  Import Key Variable: Receive encrypted key variables (KEKs, TEKs, and ECMQV Private Static Key) over the SDIO interface. Available in both FIPS and non-FIPS mode.  Generate Key Variable: Auto-generate KEKs, TEKs, ECDH Public and Private Values, Public and Private Generated Signature Keys, ECMQV Public Static Key, ECMQV Public and Private Generated Ephemeral Keys, ECDH Shared Secret, and the KPK within the module. Available in both FIPS and non-FIPS mode.  Delete Key Variable: Delete KEKs, TEKs, ECDH Public and Private Values, ECDH Public and Private Generated Signature Keys, ECMQV Public and Private Static Keys, ECMQV Public and Private Generated Ephemeral Keys, and ECDH Shared Secret. Available in both FIPS and non-FIPS mode.  Edit Key Variable: Edit KEKs and TEKs managed by the module. Available in both FIPS and non-FIPS mode.  Key Check: Validate the correctness of a Key based on algorithm properties. Available in both FIPS and non-FIPS mode.  Encrypt: Encrypt plaintext data to be transferred over the SDIO interface. Available in both FIPS and non-FIPS mode.  Decrypt: Decrypt ciphertext data received over the SDIO interface. Available in both FIPS and non-FIPS mode.  Transfer Key Variable: Internally transfer key variables (KEKs, TEKs) between volatile and non-volatile memory. Available in both FIPS and non-FIPS mode.  Generate Signature: Generate a Signature and output result over SDIO interface. Available in both FIPS and non-FIPS mode.  Generate Hash: Generate a hash and output result over SDIO interface. Available in both FIPS and non-FIPS mode. Non-Proprietary Security Policy: µMACE Page 19 of 31  Generate MAC: This service generates a Message Authentication Code of a block of data to provide data integrity using a shared symmetric key  Perform Key Agreement Process: Perform a key agreement process to create a key in volatile memory. Available in both FIPS and non-FIPS mode.  Generate Random Number: Generate random data using the Non-deterministic Hardware Random Number Generator and output result over SDIO interface. Available in both FIPS and non-FIPS mode.  Key Query: Retrieve the metadata for a given key present in the module. Available in both FIPS and non-FIPS mode.  OTAR: Modify and query the KEKs and TEKs stored internally via the SDIO interface. 9.3. µMACE Services Available to the User Role via KVL Interface.  Store & Forward: Modify and query the KEKs and TEKs stored internally via the KVL interface.  Zeroize Keys via KVL interface: Zeroize KEKs and TEKs via the KVL interface.  Import Key Variable: Load encrypted KEKs and TEKs via the KVL interface. 9.4. µMACE Services Available to the Crypto-Officer Role.  Program Update: Update the module firmware via the SDIO interface. All keys (stored in RAM and non-volatile memory) and CSPs are zeroized during a Program Update. Available in both FIPS and non-FIPS mode.  Validate Crypto-Officer password: Validate the current Crypto-Officer password used to identify and authenticate the Crypto-Officer role via the SDIO interface. Successful authentication will allow access to services allowed for the Crypto Officer. Available in both FIPS and non-FIPS mode.  Change Crypto-Officer password: Modify the current password used to identify and authenticate the Crypto-Officer Role via SDIO interface. Available in both FIPS and non-FIPS mode.  Extract Action Log: Exports a history of actions over the SDIO interface. Available in both FIPS and non-FIPS mode.  Logout Crypto-Officer Role: Logs out the Crypto-Officer. Available in both FIPS and non-FIPS mode.  Configure Module via SDIO interface: Perform configuration of the module (e.g. time configuration, enable/disable clear key import, enable/disable red keyfill, etc.) via the SDIO interface. Available in both FIPS and non-FIPS mode. 9.5. µMACE Services Available without a Role.  Perform Self-Tests: Performs module self-tests comprised of cryptographic algorithms test and firmware test. Initiated by a transition from power off state to power on state. Available in both FIPS and non-FIPS mode.  Version Query: Provides module firmware version number and FIPS status over the SDIO interface. Available in both FIPS and non-FIPS mode.  Configure Module via KVL interface: Perform configuration of the module (e.g. OTAR configuration) via the KVL interface. Non-Proprietary Security Policy: µMACE Page 20 of 31 9.6. Critical Security Parameters (CSPs) and Public Keys Table 6: CSP Definition CSP Identifier Description Key Protection Key (KPK) This is a 256-bit AES key used to encrypt all other keys stored in non volatile memory. Generated internally using the Non- deterministic Hardware Random Number Generator. Stored encrypted with the UKPPK in non volatile memory (AES256- OFB). The KPK is not entered into or output from the module. Entry - n/a Output - n/a Storage – encrypted with the UKPPK (AES256-OFB) in non-volatile memory Zeroization - on Program Update service request Generation - Non-deterministic Hardware Random Number Generator UKPPK (Universal Key This is a 256 bit AES Key used for encrypting the KPK. Stored Protection Protection Key) unencrypted in RAM while in use; stored in plaintext in non- volatile memory and zeroized through the Program Update service. The UKPPK is entered using the Program Update service (encrypted using AES-CBC) and is not output from the module. Entry – on Program Update service request Output – n/a Storage – in plaintext in non volatile memory Zeroized – on Program Update service request Generation – n/a Key Variable Loader Black This is a 256 bit AES Key used for encrypting keys that are Keyloading Key (KVL-BKK) input into the module and output from the module via the KVL interface. Stored unencrypted in RAM while in use; stored in plaintext in non-volatile memory and zeroized through the Program Update service. The KVL-BKK is entered using the Program Update service (encrypted using AES-CBC) and is not output from the module. Entry - on Program Update service request Output - n/a Storage - in plaintext in non volatile memory Zeroized - on Program Update service request Generation - n/a Black Keyloading Key This is a 256-bit AES Key used for encrypting keys that are (BKK) input into the module and output from the module via the SDIO interface. Stored unencrypted in RAM while in use; stored in plaintext in non-volatile memory and zeroized through the Non-Proprietary Security Policy: µMACE Page 21 of 31 CSP Identifier Description Program Update service. Also stored encrypted on the KPK in non volatile memory. The BKK is entered using the Program Update service (encrypted using AES-CBC) and is not output from the module. Entry - on Program Update service request Output - n/a Storage - in plaintext in non volatile memory and encrypted on KPK in non volatile memory Zeroization - on Program Update service request Generation - n/a A 256-bit AES key used to decrypt downloaded images. The Image Decryption Key IDK is not output from the module. (IDK) Entry - on Program Update service request Output - n/a Storage - in plaintext in non volatile memory Zeroization - on Program Update service request Generation - n/a Traffic Encryption Keys 128 and 256-bit AES Keys used for enabling secure (TEKs) communication with target devices. TEKs are entered in encrypted form via the SDIO or KVL interface (AES Key Wrapping),). TEKs entered through the SDIO interface are encrypted with the BKK. TEKs entered through the KVL interface are encrypted with the KVL-BKK or KEKs. The TEKS are stored encrypted on the KPK (AES256-CFB8) in non volatile memory. TEKs are stored in plaintext in RAM only as long as needed. TEKs are output from the module on the SDIO interface encrypted using KEKs (AES Key Wrapping). . Entry – input encrypted with AES Key Wrap over the SDIO Interface or KVL interface Output – output encrypted with AES Key Wrap over the SDIO Interface Storage – stored encrypted on KPK with AES256-CFB8 in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation – internally derived through key agreement 128 and 256-bit AES Keys used for enabling secure Key Encryption Keys communication with target devices. KEKs are entered in (KEKs) encrypted form via the SDIO or KVL interface (AES Key Wrapping). KEKs entered through the KVL interface are encrypted with the KVL-BKK or other KEKs. KEKs entered through the SDIO interface are encrypted with other KEKs. The KEKS are stored encrypted on the KPK (AES256-CFB8) in non volatile memory. KEKs are stored in plaintext in RAM only as long as needed. KEKS are not output from the module. Entry – input encrypted with AES Key Wrap over the SDIO or KVL Interface Non-Proprietary Security Policy: µMACE Page 22 of 31 CSP Identifier Description Output - n/a Storage – stored encrypted on KPK with AES256-CFB8 in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation - n/a User Password The User Password is entered encrypted on the PEK (AES256- CFB8). The User Password is not stored in the module or output from the module. Entry – entered encrypted on the PEK with AES256- CFB8 Output - n/a Storage – a hash of the User Password is stored in non- volatile memory Zeroization – on Program Update service request Generation - n/a Crypto-Officer Password The Crypto Officer password is entered encrypted on the PEK (AES256-CFB8). After decryption the plaintext password is not stored but temporarily exists in volatile memory. The SHA-384 hash value of the plaintext password is stored encrypted on the PEK in non volatile memory. The SHA-384 hash of the decrypted password is compared with the SHA-384 hash value stored in non-volatile memory during password validation. Entry - entered encrypted on the PEK with AES256- CFB8 Output - n/a Storage - SHA-384 hash of the plaintext password is encrypted on the PEK in non volatile memory Zeroization – on Program Update service requests Generation - n/a Password Encryption Key This is a 256-bit AES Key used for decrypting passwords (PEK) during password validation. Loaded via the Program Update service. Stored in plaintext in non-volatile memory and zeroized through the Program Update service. Also stored encrypted on the KPK in non volatile memory. The PEK is not output from the module. Entry - on Program Update service request Output - n/a Storage - in plaintext in non volatile memory; encrypted on the KPK in non volatile memory Zeroization - on Program Update service request Generation - n/a Non-Proprietary Security Policy: µMACE Page 23 of 31 CSP Identifier Description Randomly generated internally by a Generate Key Variable Elliptic Curve Diffie- service request using Non-deterministic Hardware Random Hellman Private value Number Generator. Used to establish a shared secret over an insecure channel. Stored in plaintext in volatile memory. The Elliptic Curve Diffie-Hellman Private value is not entered into or output from the module. Entry - n/a Output - n/a Storage – in plaintext in volatile memory Zeroization - on Delete Key Variable or Program Update service requests and on power off Generation - on Generate Key Variable service request Randomly generated internally by the Generate Key Variable ECDSA Private Generated service request using Non-deterministic Hardware Random Signature Key (PGSK) Number Generator. Stored in non volatile memory encrypted on KPK; when in use it is in plaintext in RAM. The Private Generated Signature Key is not output from the module. Entry - n/a Output - n/a Storage – encrypted on KPK in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation - on Generate Key Variable service request The ECMQV Private Static Key is entered over the SDIO ECMQV Private Static Key Interface encrypted on the BKK (AES Key Wrapping). Used to establish a shared secret over an insecure channel. Stored encrypted with KPK in non volatile memory. The ECMQV Private Static Key is not output from the module. Entry – entered encrypted on the BKK with AES Key Wrap over the SDIO Interface Output - n/a Storage - encrypted on KPK in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation - n/a Randomly generated internally by the Generate Key Variable ECMQV Private Generated service request using Non-deterministic Hardware Random Ephemeral Key (PGEK) Number Generator. Used to establish a shared secret over an insecure channel. When in use it is in plaintext in RAM. The ECMQV Private Generated Ephemeral Key is not entered into or output from the module. Entry - n/a Output - n/a Storage - n/a Zeroization - on power off or Program Update service request Generation - Non-deterministic Hardware Random Number Generator Non-Proprietary Security Policy: µMACE Page 24 of 31 CSP Identifier Description Generated internally by the Elliptic Curve Diffie-Hellman Elliptic Curve Diffie- Algorithm. The Elliptic Curve Diffie-Hellman Shared Secret is Hellman Shared Secret output encrypted on a KEK (AES Key Wrapping) as part of the Diffie-Hellman key agreement protocol. Entry - n/a Output – output encrypted on a KEK with AES Key Wrap over the SDIO interface Storage – in plaintext in volatile memory Zeroization - on power off or Program Update service request Generation - internally by the Elliptic Curve Diffie- Hellman Algorithm Table 7: Public Keys Key Description ECDSA Public A 384-bit ECDSA public key used to validate the signature of Programmed Signature Key the firmware image being loaded before it is allowed to be executed. Stored in non volatile memory. Loaded during manufacturing and as part of the boot image during a Program Update service. The Public Programmed Signature Key is not output from the module. Entry - on Program Update service request Output - n/a Storage - in plaintext in non volatile memory Zeroization - on Program Update service request Generation - n/a Non-Proprietary Security Policy: µMACE Page 25 of 31 Elliptic Curve Diffie-Hellman Generated internally by the Generate Key Variable service request. Used to establish a shared secret over an insecure Public value channel. Stored in plaintext in volatile memory. The Elliptic Curve Diffie-Hellman Public value is generated internally and is output as part of the Diffie-Hellman key agreement protocol. Entry - n/a Output - in plaintext over the SDIO interface Storage - in plaintext in volatile memory Zeroization - on Delete Key Variable and Program Update service requests and on power off Generation - on Generate Key Variable service request Generated internally by the Generate Key Variable service ECDSA Public Generated request. A 384-bit ECDSA key used to validate signatures. Signature Key Stored in plaintext in non volatile memory. The ECDSA Public Generated Signature Key is output from the module in plaintext over the SDIO interface. Entry - n/a Output - in plaintext over the SDIO interface Storage - in plaintext in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation - on Generate Key Variable service request The ECMQV Public Static Key is generated internally by the ECMQV Public Static Key Generate Key Variable service request. Used to establish a shared secret over an insecure channel. Stored in plaintext in non volatile memory. The ECMQV Public Static Key is output in plaintext from the module over the SDIO interface. Entry - n/a Output - SDIO Interface in plaintext Storage - in plaintext in non volatile memory Zeroization - on Delete Key Variable and Program Update service requests Generation – on Generate Key Variable service request Generated internally by the Generate Key Variable service ECMQV Public Generated request. Used to establish a shared secret over an insecure Ephemeral Key channel. Stored in plaintext in non volatile memory. The ECMQV Public Generated Ephemeral Key is output from the module in plaintext over the SDIO interface. Entry - n/a Output - SDIO Interface in plaintext Storage - n/a Zeroization - on power off or Program Update service request Generation - on Generate Key Variable service request Input in plaintext over the SDIO interface. Used to establish a Remote Party Diffie- shared secret over an insecure channel. Stored in plaintext in Hellman Ephemeral Public volatile memory. Key Entry – in plaintext over SDIO interface Output – n/a Storage - in plaintext in volatile memory Non-Proprietary Security Policy: µMACE Page 26 of 31 Zeroization - on Delete Key Variable and Program Update service requests and on power off Generation – n/a Input in plaintext over the SDIO interface. Used to establish a Remote Party ECMQV shared secret over an insecure channel. Stored in plaintext in Ephemeral Public Key volatile memory. Entry – in plaintext over SDIO interface Output – n/a Storage - in plaintext in volatile memory Zeroization - on Delete Key Variable and Program Update service requests and on power off Generation – n/a Input in plaintext over the SDIO interface. Used to establish a Remote Party ECMQV shared secret over an insecure channel. Stored in plaintext in Static Public Key volatile memory. Entry – in plaintext over SDIO interface Output – n/a Storage - in plaintext in volatile memory Zeroization - on Delete Key Variable and Program Update service requests and on power off Generation – n/a 9.7. CSP Access Types Table 8: CSP Access Types CSP Access Type Description C – Check CSP Checks status of the CSP. D – Decrypt CSP Decrypts entered KEKs and TEKs using the BKK during CSP entry over the SDIO interface. Decrypts entered KEKs and TEKs using the KVL-BKK during CSP entry over the KVL interface. Decrypts entered passwords using the PEK during entry over the SDIO interface. E – Encrypt CSP Encrypts KEKs and TEKs prior to output over the SDIO interface using a KEK or BKK. G – Generate CSP Generates KPK, Elliptic Curve Diffie-Hellman private key or ECMQV private key. S – Store CSP Stores KPK in plaintext in non volatile memory. Stores plaintext BKK, PEK, or IDK in volatile and non-volatile memory (encrypted except IDK). Stores SHA-384 Hash of the Crypto-Officer password in non volatile memory (encrypted on PEK). Non-Proprietary Security Policy: µMACE Page 27 of 31 CSP Access Type Description U – Use CSP Uses CSP internally for encryption / decryption services. Z – Zeroize CSP Zeroizes CSP. Non-Proprietary Security Policy: µMACE Page 28 of 31 Table 9: CSP versus CSP Access Role Service CSP ECDH Shared Secret ECDH Private Value Crypto-Officer Role No Role Required ECMQV Private User Password ECMQV PGEK SDIO Interface ECDSA PGSK Crypto-Officer KVL Interface User Role User Role Static Key Password KVL-BKK UKPPK KEKs TEKs PEK KPK BKK IDK u, z, z z, s z z z z, s z, s z z z z z z 1. Program Update z s √ d, u, u √ 2. Validate Crypto-Officer Password z d,u, u √ 3. Change Crypto-Officer Password z, s d, u, u d g √ 4. Validate User Password z d, s, d, u, u g √ 5. Change User Password e,g z √ 6. Extract Action Log 7. Version Query √ 8. Algorithm List Query √ z √ z 9. Logout User Role √ 10. Logout Crypto-Officer Role d, e, d, e, d, e, u u u √ 11. Export Key Variable u u u d,e, d,e, d,e, u u u u u √ 12. Import Key Variable u s, u s, u s, u √ e, g, e, g, e, g, e, g, e, g, 13. Generate Key Variable u u √ s s s s s z z z z z z √ z 14. Delete Key Variable d,e, d,e, u d, s d, s d, s √ 15. Edit Key Variable d u, s u, s c c u c c c √ c 16. Key Check u u u u √ 17. Encrypt u u u u u u u u √ u 18. Decrypt √ 19. Perform Self-Tests d,e, d,e, d,e, d,e, d,e, u √ 20. Transfer Key Variable u, s u, s u, s u, s u, s u d, u √ 21. Generate Signature √ 22. Generate HASH Non-Proprietary Security Policy: µMACE Page 29 of 31 Role Service CSP ECDH Shared Secret ECDH Private Value Crypto-Officer Role No Role Required ECMQV Private User Password ECMQV PGEK SDIO Interface ECDSA PGSK Crypto-Officer KVL Interface User Role User Role Static Key Password KVL-BKK UKPPK KEKs TEKs PEK KPK BKK IDK d, u u √ 23. Generate MAC u d, u d, u d, u √ d, u u 24. Perform Key Agreement 25. Configure Module via SDIO √ interface √ 26. Random number generation d d u d d d √ d 27. Key Query √ 28. Configure Module via KVL interface z z √ 29. Zeroize Keys via KVL interface d, u, d, u, 30. OTAR e, z, e, z, √ s s d, u, d, u, 31. Store & Forward e, z, e, z, √ s s Non-Proprietary Security Policy: µMACE Page 30 of 31 10. Mitigation of Other Attacks Policy The µMACE is not designed to mitigate any specific attacks outside of those required by FIPS 140-2. Non-Proprietary Security Policy: µMACE Page 31 of 31