QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy Version 1.3 2014-10-22 Prepared for: Qualcomm Technologies, Inc. 5775 Morehouse Drive San Diego, CA 92121 Prepared by: atsec information security Corp. 9130 Jollyville Road, Suite 260 Austin, TX 78759 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy Table of Contents Copyrights and Trademarks.............................................................................................................. 3 1. Introduction ....................................................................................................................................... 4 1.1. Purpose of the Security Policy ................................................................................................. 4 2. Cryptographic Module Specification .......................................................................................... 5 2.1. Module description ..................................................................................................................... 5 2.1.1. Hardware description .............................................................................................................. 6 2.1.2. Software description ............................................................................................................... 6 2.1.3. Module Validation Level ......................................................................................................... 7 2.2. Description of Approved modes ............................................................................................... 8 2.3. Cryptographic Module Boundary ............................................................................................. 8 2.3.1. Hardware Block Diagram ....................................................................................................... 9 3. Cryptographic Module Ports and Interfaces .......................................................................... 10 4. Roles, Services and Authentication ......................................................................................... 11 4.1. Roles ........................................................................................................................................... 11 4.2. Services...................................................................................................................................... 11 5. Physical Security ........................................................................................................................... 15 5.1. Type ............................................................................................................................................ 15 6. Operational Environment ............................................................................................................ 16 6.1. Applicability ................................................................................................................................ 16 6.2. Debugger ................................................................................................................................... 16 7. Cryptographic Key Management ............................................................................................... 17 7.1. Random Number Generation ................................................................................................. 17 7.2. Key/CSP Generation Management ....................................................................................... 17 8. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ..................... 18 9. Powerup Tests ............................................................................................................................. 19 9.1. Self-tests .................................................................................................................................... 20 9.2. Cryptographic algorithm tests (known answer tests) .......................................................... 20 9.3. Integrity Test Summary............................................................................................................ 21 9.4. Conditional Tests ...................................................................................................................... 21 10. Design Assurance ....................................................................................................................... 23 10.1. Configuration Management .................................................................................................. 23 10.1.1. Software................................................................................................................................ 23 10.1.2. Hardware .............................................................................................................................. 23 10.2. Delivery and Operation .......................................................................................................... 23 10.3. Guidance ................................................................................................................................. 23 10.3.1. Crypto Officer Guidance ................................................................................................ 23 11. Application Programming Interfaces ..................................................................................... 25 11.1. User Space APIs .................................................................................................................... 25 11.2. Kernel Space APIs ................................................................................................................. 26 11.2.1. Block Cipher Algorithms ................................................................................................. 26 11.2.2. Hash/HMAC Algorithms ................................................................................................. 27 11.2.3. Random Numbers ........................................................................................................... 27 11.2.4. Status ................................................................................................................................ 27 © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 12. Mitigation of Other Attacks ....................................................................................................... 28 13. Terms and Abbreviations .......................................................................................................... 29 Copyrights and Trademarks Copyright ©2014 Qualcomm Technologies, Inc. This document may be reproduced only in its original entirety without any revision. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 1. Introduction This document is a FIPS 140-2 Security Policy for the QTI Cryptographic Module on Crypto 5 Core. It contains a specification of the rules under which the module must operate and describes how this module meets the requirements as specified in Federal Information Processing Standards Publication 140-2 (FIPS PUB 140-2) for a Security Level 1 module. It is intended for the FIPS 140-2 testing lab, Cryptographic Module Validation Program (CMVP), developers working on the release, administrators of the cryptographic module and users of the cryptographic module. For more information about the FIPS 140-2 standard and validation program, refer to the NIST website at http://csrc.nist.gov/groups/STM/cmvp/index.html. In this document, the terms “QTI Cryptographic Module on Crypto 5 Core”, “cryptographic module”, “QTI Cryptographic Module” or “the module” are used interchangeably to refer to the QTI Cryptographic Module on Crypto 5 Core. 1.1.Purpose of the Security Policy There are three major reasons that a security policy is required • It is required for FIPS 140-2 validation. • It allows individuals and organizations to determine whether the implemented cryptographic module satisfies the stated security policy. • It allows individuals and organizations to determine whether the described capabilities, the level of protection, and access rights provided by the cryptographic module meet their security requirements. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 2. Cryptographic Module Specification 2.1.Module description The Cryptographic Module (CM) is a multi-chip standalone software-hybrid module. The cryptographic services provided by the module are: • Data encryption / decryption utilizing symmetric ciphers, i.e.Triple-DES, and AES algorithms. • Random number generation based on a SP 800-90A CTR DRBG with a 128-bit AES derivation function. • Computation of hash values, i.e. SHA-1, SHA-256. • Message authentication utilizing HMAC-SHA1, HMAC-SHA256, AES CMAC, hashing algorithms. • Concurrent operations of hashing and ciphering using AES CCM. Table 2-1: Summary of FIPS and non FIPS algorithm in CM Kernel Invokes As FIPS Compliant Implemented Algorithms (.cra_driver_name) AES-128 CBC, AES-256 CBC encryption, decryption qcrypto-cbc-aes AES-128 ECB, AES-256 ECB encryption, decryption qcrypto-ecb-aes AES-128 CTR, AES-256 CTR encryption, decryption qcrypto-ctr-aes encryption, decryption (with AES-128 CCM, AES-256 CCM 1 qcrypto-ccm-aes message authentication code) encryption, decryption (with AES-128 XTS, AES-256 XTS qcrypto-xts-aes message authentication code) Triple-DES CBC encryption, decryption qcrypto-cbc-3des Triple-DES ECB encryption, decryption qcrypto-ecb-3des SHA-1 Hashing qcrypto-sha1 SHA256 Hashing qcrypto-sha256 HMAC-SHA-1 message authentication code qcrypto-hamc-sha1 HMAC-SHA-256 message authentication code qcrypto-hamc-sha256 AES-CMAC 2 message authentication code n/a DRBG random number generation n/a Kernel Invokes As Non-FIPS Compliant Implemented Algorithms (.cra_driver_name) DES CBC encryption, decryption qcrypto-cbc-des DES ECB encryption, decryption qcrypto-ecb-des encryption, decryption (with AEAD-SHA-1 AES CBC1 qcrypto-aead-hmac-sha1-cbc-aes message authentication code) encryption, decryption (with AEAD-SHA-1 AES CTR1 qcrypto-aead-hmac-sha1-ctr-aes message authentication code) encryption, decryption (with AEAD-SHA-1 DES CBC1 qcrypto-aead-hmac-sha1-cbc-des message authentication code) encryption, decryption (with qcrypto-aead-hmac-sha1-cbc- AEAD-SHA-1 Triple-DES CBC1 message authentication code) Triple-DES 1 Only available in the kernel interface. 2 Only available in the user interface. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy encryption, decryption (with Kasumi n/a message authentication code) snow-3g encryption, decryption n/a HW RNG Random number generation n/a 1. Crypto 5 hardware also provides Over The Air (OTA) f8/f9 algorithms as defined by the 3GPP forum (non-FIPS compliance). 2. Caveat: AES counter mode uses a 128 bit counter. The counter will roll over after 2^128 blocks of encrypted data. 2.1.1.Hardware description The hardware portion of the cryptographic module is the Crypto 5 Core, which resides in Snapdragon 805 processors (https://www.qualcomm.com/products/snapdragon/processors/805). The QTI Crypto 5 Core provides a series of algorithms (as listed in Table 2-1) implemented in the device hardware. 2.1.2.Software description The software portion of the cryptographic module consists of the QTI crypto engine (qce50) driver V5.f1 that provides common services for accessing the hardware Crypto 5 Core through the following two clients: • qcrypto driver (module provided for accessing CM by kernel space apps) • qcedev driver (module provided for accessing CM by user space apps) Figure 2-1: Cryptographic modules depicting the main driver modules, qcrypto, qce50, qcedev, containing services to access the QTI Crypto 5 hardware All actual cryptographic functions, with the exception of the DRBG, are implemented within the hardware. The qceXX software driver is independent of the platform. The qceXX (where XX is 50 for the current major version) driver provides the common services for hardware crypto access to the two drivers listed above. The software application (user space), qfipsverify, provides integrity checking for itself and the cryptographic software drivers. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 6 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 2.1.3.Module Validation Level The module is intended to meet requirements of FIPS 140-2 security level 1 overall. The following table shows the security level claimed for each of the eleven sections that comprise the validation: Table 2-2: Security Levels FIPS 140-2 Sections Security Level N/A 1 2 3 4 ✔ Cryptographic Module Specification ✔ Cryptographic Module Ports and Interfaces ✔ Roles, Services and Authentication ✔ Finite State Model ✔ Physical Security ✔ Operational Environment ✔ Cryptographic Key Management ✔ EMI/EMC ✔ Self Tests ✔ Design Assurance ✔ Mitigation of Other Attacks The QTI Cryptographic Module is classified as a multi-chip standalone hybrid module for FIPS 140-2 purposes. The logical cryptographic boundary for the module includes the CM software backed by hardware cryptography to support hardware-based cryptographic algorithms. Table 2-3 describes the platform where the cryptographic module has been tested: Table 2-3: Tested Platforms Module Name Hardware Software Version O/S & Android Version Version/Test Platform QTI Cryptographic Module Qualcomm Snapdragon 5.f1 Kernel: 3.10.0-ge984437-00001- on Crypto 5 Core 805 processor gaa2ad45 Android: 4.4 Table 2-4 describes the software that comprises the cryptographic module: Table 2-4: Tested Software Software Change ID in GIT Version Control System Description © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 7 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy qcedev Allows access to the CM from user Ic1c64f992b28f732b24d5d66449f7cef7b6e778b mode qcrypto Allows access to the CM from kernel Ic1c64f992b28f732b24d5d66449f7cef7b6e778b space qfipsverify Performs integrity checks Ia36df633f295d88d10f69a980a7d25147dfaf220 msm_rng Random number generator Ic1c64f992b28f732b24d5d66449f7cef7b6e778b 2.2.Description of Approved modes The CM supports a FIPS approved mode and a non-approved mode. All CSPs are kept separate between the two modes. The services available in each mode are specified in table 2-1. When a request for a non-approved mode service is received, the CM switches to non-approved mode, services the request, and immediately switches back to the approved mode. The CM is placed into the approved mode by performing power up self-tests consisting of a KAT self-test for each algorithm in the approved list and an integrity test. If either test fails, none of the cryptographic functions are available. Table 2-1 provides a summary of all security functions (both FIPS compliant and FIPS non-compliant). Table 4- 2, 4-3 and table 4-4 illustrate the role and corresponding services available to the Crypto officer and User. 2.3.Cryptographic Module Boundary The physical boundary of the module is the physical boundary of the device that contains the module. Consequently, the embodiment of the module is a Multi-chip standalone cryptographic module. In the following diagram, the bidirectional arrows depict the flow of the status, control and data. The logical boundary of the cryptographic module (in blue) overlaps both user space and kernel space. Figure 2: Cryptographic Boundary © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy The operations within the logical security boundary (the blue dotted region) use the ciphers from the hardware, Crypto Core (see Figure 3) that is included in the logical boundary. 2.3.1.Hardware Block Diagram The bidirectional arrows depict the flow of the status, control and data. Software drivers pass the parameters to the hardware and receive the results from the hardware. The CSPs, such as the encryption key, are given to the APIs. The hardware components which are not part of the crypto core pass the Critical Security Parameter (CSP) to crypto core. Therefore, they act as “pipes” without interaction with the CSPs. Figure 3: Hardware Block Diagram : Power in : Command/ data/ status/ CSP in : Command/ data/ status/ CSP out The CSPs are passed via memory and processed by the Cryptographic Module. All parameters to the hardware are provided via memory from qce50. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 9 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 3.Cryptographic Module Ports and Interfaces Table 3-1 Ports and interfaces FIPS Interface Ports Data Input API input parameters Data Output API output parameters Control Input API function calls Status Output API return codes, kernel log messages Power Input Physical power connector The User or Crypto Officer interacts with the CM in two distinct ways: 1. Powering on the CM 2. The application services (API’s) invoked by users For the application services, the logical interfaces of the module are the C language Kernel Programming Interfaces (KPIs). In detail these interfaces are the following: • Data input and data output are provided in the variables passed in the KPI and callable service invocations, generally through caller-supplied buffers. • Control inputs which control the mode of the module are provided through dedicated parameters. • Status output is provided in return codes and through messages. Documentation for each KPI lists possible return codes. A complete list of all return codes returned by the C language KPIs within the module is provided in the header files and the KPI documentation. Messages are documented also in the KPI documentation. Return codes will be in the header files. Once the kernel initializes the cryptographic module and the self-tests complete successfully, all cryptographic functions are made available to kernel services and user space. If any of the modules KAT fails, the module self- test causes the system to panic (see Section 9.1 for more details). To recover from a KAT failure a reboot of the kernel is required to reset the failure status. If the integrity tests fail the system will be operational, however all cryptographic functions are inhibited. The only way to recover from an integrity test failure is to reinstall the software and reboot the kernel. Caller-induced or internal errors do not reveal any sensitive material to callers. Cryptographic bypass capability is not supported by the module. The CM ensures that there is no means to obtain data from the cryptographic module by performing key zeroization. There is no means to obtain sensitive information from the cryptographic module. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 4.Roles, Services and Authentication 4.1.Roles The module supports two roles: a Crypto Officer role and a User role. The module does not support user identification or authentication that would allow the module to distinguish between the two supported roles. The Crypto Officer role is a purely administrative role that does not involve the use of cryptographic services. The role is not explicitly authenticated but assumed implicitly on implementation of the module’s installation and initialization. The User role has access to all of the module’s services. The role is not explicitly authenticated, but assumed implicitly on access of any of the non-Crypto Officer services. An operator is implicitly in the User or Crypto Officer role based upon the services chosen. If any of the User-specific services are called, then the operator is in the User role; otherwise the operator is in the Crypto Officer role. The customer who configures and installs the CM is considered to be a Crypto Officer. Additionally, a user powering up and initializing the device is assuming the Crypto Officer role. There is no enforced separation between the Crypto Officer and the User roles. As stated previously, the User or Crypto Officer role is based on the service or operation performed. Table 4-1 Roles Role Services (see Table 4-2) User Utilization of services of the module Crypto Officer Installation and initialization of the module. 4.2.Services The crypto module does not provide a bypass capability through which some cryptographic operations are not performed or where certain controls implemented during normal operation are not enforced. The following tables (Table 4-2 and Table 4-3) illustrate the role and corresponding services of the Crypto Officer and User: Table 4-2 Approved Services Service Roles CSP Modes Is FIPS Access Standard Approved? (Read, If Yes Cert Write, User CO # Execute) Symmetric Algorithms © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy Service Roles CSP Modes Is FIPS Access Standard Approved? (Read, If Yes Cert Write, User CO # Execute) ✓ AES encryption AES Symmetric Cert. 2839 Read/Write FIPS 197 CBC, and decryption key (128, 256 SP 800-38 [A,C,E] ECB, bit) CTR, XTS, CCM (only available on the qcrypto interface (kernel- kernel)) ✓ Triple-DES Triple DES CBC, ECB Cert. 1701 Read/Write FIPS 46-3 Symmetric key SP 800-38A (168 bits) Hash Functions ✓ SHA-1 None N/A Cert. 2388 Read FIPS 180-4 ✓ SHA-256 None N/A Cert. 2388 Read FIPS 180-4 Message Authentication Codes (MACs) ✓ HMAC-SHA1 HMAC-SHA1 N/A Cert. 1786 Write FIPS 198-1 key (key length at least 112 bits) ✓ HMAC-SHA-256 HMAC-SHA256 N/A Cert. 1786 Write FIPS 198-1 key with a length of at least 112 bits ✓ AES-CMAC AES Symmetric CMAC Cert. 2839 Write SP 800-38B key (128, 256 (only bit) available on the qcedev interface (user- kernel)) Random Number Generation © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 12 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy Service Roles CSP Modes Is FIPS Access Standard Approved? (Read, If Yes Cert Write, User CO # Execute) ✓ DRBG 800-90A Seed, Nonce CTR Cert. 501 Read SP 800-90A DRBG with AES 128 core and derivation function Table 4-3 Non-Approved Services Service Roles CSP Modes Access Standard (Read, Write, Execute) User CO Symmetric Algorithms ✓ DES DES Symmetric key CBC, ECB Read/Write n/a (56 bits) ✓ AEAD-SHA-1 AES Symmetric key CBC, CTR Read/Write n/a AES 3 (128 bits), HMAC- SHA1 key (key length at least 112 bits) ✓ AEAD-SHA-1 DES Symmetric key CBC Read/Write n/a DES3 (56 bits), HMAC- SHA1 key (key length at least 112 bits) ✓ AEAD-SHA-1 Triple-DES Symmetric CBC Read/Write n/a Triple-DES3 key (168 bits), HMAC- SHA1 key (key length at least 112 bits) ✓ Kasumi Symmetric key (128 n/a Read/Write n/a bits) ✓ Snow-3g Symmetric key (128, n/a Read/Write n/a 256 bits) 3 Also produces a Message Authentication Code © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy Service Roles CSP Modes Access Standard (Read, Write, Execute) User CO Random Number Generation ✓ HW RNG Entropy source, seed Combination of Read True RNG and HASH-DRBG Table 4-4 Queries and other Services Service Notes Roles Module Status Officer User Query mode Check if module in FIPS 140-2 mode No Yes Integrity Checks Powerup Test Automatic before first use Yes No Self-Tests Self-tests can be invoked by power cycling the cryptographic No Yes module Operational Correctness Tests RNG tests Continuously performed (automatic) Yes Yes Installation Yes No © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 14 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 5.Physical Security 5.1.Type The QTI Cryptographic Module is a software-hybrid module that operates on a multi-chip standalone platform which conforms to the Level 1 requirements for physical security. The hardware portion of the cryptographic module is a production grade component. The cryptographic module must be used in a COTS mobile device. The mobile device shall be comprised of production grade components with standard passivation (a sealing coat applied over the chip circuitry to protect it against environmental and other physical damage) and a production grade enclosure that completely surrounds the cryptographic module. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 15 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 6.Operational Environment 6.1.Applicability The operating system shall be restricted to a single operator mode of operation. The procurement, build and configuring procedure are controlled. The module is installed into a commercial off- the-shelf (COTS) mobile device by the customer. Therefore the operational environment is considered non- modifiable. 6.2.Debugger The use of a kernel debugger as well as a JTAG interface for debugging is prohibited. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 16 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 7.Cryptographic Key Management 7.1.Random Number Generation The random number generation uses a hardware/software hybrid solution. Hardware is used to collect random bits as the entropy seed for the software module to generate FIPS140-2 compliant random numbers. The software deterministic random bits generator (DRBG) gets entropy and nonce from the hardware RNG. The software DRBG used to generate pseudo random numbers is an SP 800-90A compliant CTR DRBG with an AES 128 core using a derivation function without prediction resistance. It does not process a personalization string or an additional input string. The implementation performs a continuous self-test, a health check, and a poweron self-test. The DRBG accepts 128 bits of entropy input and 64 bits of nonce as the seed from the underlying HW RNG. A re-seed process is applied to the DRBG, after it generates 2^31 blocks of data. When the DRBG is instantiated, it runs a self-test with a set of test vectors, and also runs a health check test to verify that the instantiation function and generation function is able to handle any incorrect parameter inputs, such as the input data length being a negative number, etc. The DRBG implements a continuous self-test verifying the random number generation. The output of the hardware RNG is subject to a continuous self-test. The DRBG self-test and run-time test performs the following steps: (1) Instantiate DRBG. (2) Reseed. (3) Generate random bits (do not output). (4) Generate random bits (as outputs). (5) Un-Instantiate. The self-test compares the output bits with pre-set expected output bits, from pre-set test vectors. In the run-time test, the output bits will be output to client for further verification by the client. 7.2.Key/CSP Generation Management The module does not provide any key generation service or perform key generation for any of its approved algorithms. Keys are passed in from clients via algorithm APIs. There is no manual seeding of the DRBG functions. For additional information about the DRBG refer to Section 7.1. The CM does not provide any asymmetrical algorithms. Manual key entry or key output capabilities are not provided. All CSPs can only be exchanged between the CM and the calling application or kernel code through the appropriate API calls which all occur within the physical boundary of the device and therefore may be passed from the application to the module in the clear. Applications or kernel code pass references to keys and similar sensitive information to the CM using API calls. It is the applications responsibility to destroy this information using FIPS Pub 140-2 compliant procedures. The CM itself does not destroy externally stored keys and secrets since it does not own these CSPs. Keys are not stored within the CM; however intermediate key material may reside in memory as clear data. All intermediate key storage and other CSPs stored or created by the CM are zeroized when processing completes. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 17 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 8.Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) The CM was tested for EMI/EMC and found to be compliant with FCC Part 15 subpart B (Household and Medical devices). Lab Name: UL Verification Services Inc. 47173 Benica Street Freemont, CA 94538 U.S.A NVLAP Lab Code 200065-0 FCC Registration Number: 0003758182 © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 18 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 9.Powerup Tests Powerup self-tests consist of software integrity tests and known-answer tests of algorithm implementations. The module integrity test is automatically performed during loading. If any of these tests fail, the module will terminate the loading process. The module cannot be used in this state. To recover from the error state, re-initialization is possible by doing a reboot to set it to power on state. Powerup self-tests are performed when the CM is initialized. Initialization is invoked by an application that is human user independent. All self-tests are performed as a single atomic action that has two possible results: success or failure. If the result is success, the CM becomes operational, if it is failure, the CM enters an error state and cryptographic functions cannot be performed. FIPS 140-2 explicitly allows that the on-demand test can be fulfilled with a power cycle of the module. Hence, a power cycle and its associated poweron self-test is the methodology used to perform the "on-demand" tests. The KAT self-tests are performed during loading by the probe functions which are part of the module init phase in the qcedev and qcrypto modules. If any of the tests fail, the module will cause the system to panic and all functionality to stop. The integrity test is performed by a user-space application. The modules comprising the CM are statically built into the kernel image; hence, verifying the kernel image inherently verifies the CM modules. If the integrity test fails, the CM enters an error state. In the error state, the CM will block all requests (qcedev will block user and qcrypto will block kernel function calls). If the integrity test passes, the CM proceeds to perform the DRBG KAT tests. The DRBG KAT is performed by the fips_ctraes128_df_known_answer_test() function. This function is invoked after the successful completion of the integrity test. If the test passes, g_fips140_status will be set to”3” and the CM will unblock the cryptographic requests. This causes the CM to enter FIPS operational mode. If the test fails, the module will cause the system to panic. Figure 9-1 shows the CM powerup test flow. Figure 9-1 Crypto module finite state powerup tests flow © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 19 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 9.1.Self-tests The CM implements self-tests to ensure proper functioning of the module Implemented self-tests include powerup self-tests and conditional self-tests. A continuous random number generator test is implemented as a conditional self-test. The powerup self-tests include known answer tests (KAT) and integrity tests of the CM binaries. There are four values for a global flag used to drive the powerup self-tests: • 1 - Known answer tests have succeeded • 2 - Integrity tests have succeeded • 3 - All tests have succeeded and FIPS 140-2 mode is enabled • 255 - This is the initial value and each successful stage of the poweron self-tests will change it to one of the previous values. If the integrity test fails the flag is set to this value that causes all cryptographic functions to be unavailable. The flag value is initialized to 255 that causes all requests to the CM to be blocked. The powerup self-tests proceed as follows: • The qcedev and qcrypto binaries run their respective KATs. If successful then the flag value is set to “1” and success is logged to dmesg. If the KATs fail the code causes the kernel and therefore the entire cryptographic module to shut down. • The qfipsverify binary performs an integrity test on itself and the kernel image that verifies the integrity of the CM binaries. If successful the flag value is set to “2” and a success is logged to dmesg. If unsuccessful, the flag is set to “255” causing all cryptographic functions to be unavailable. • The DRBG KAT is performed. If successful, the flag value is set to 3 which causing the CM to no longer block and the CM enters its FIPS 140-2 operational state and the success is logged to dmesg. If the KAT fails the code causes the kernel and therefore the entire cryptographic module to shut down. 9.2.Cryptographic algorithm tests (known answer tests) Table 5-1 Powerup Tests Algorithm Test AES encryption KAT AES decryption KAT Triple-DES encryption KAT Triple-DES decryption KAT SHA1 KAT SHA256 KAT HMAC-SHA-1 KAT HMAC-SHA-256 KAT AES-CMAC KAT DRBG KAT © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 20 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 9.3.Integrity Test Summary 1. During the build process The HMAC SHA-256 of the zImage (zipped image that goes into boot.img) and the HMAC SHA-256 of the integrity application (qfipsverify executable) are created and stored in relevant files. These files are made available in a read only partition on the target which are: • /system/usr/qfipsverify/bootimg.hmac (zImage verification HMAC) • /system/usr/qfipsverify/qfipsverfy.hmac (self-integrity application verification HMAC) a. The key that is required to create the HMAC SHA-256 signatures is hard-coded in the Makefile of the integrity test project. The HMACs are generated during build compilation time. The key is also hard coded in the program fips.c (the code that generates the qfipsverify binary) to allow generation of the HMAC SHA-256 values during bootup. 2. On the target: The user-space application qfipsverify is run as a service when the device boots up. The integrity test has two parts: • zImage verification a. The application reads raw bytes from the emmc partition which contains boot.img b. The zImage is then parsed and stored in a temporary buffer c. This temporary buffer is sent to qcedev via an IOCTL and the HMAC SHA-256 signature of the buffer is created using QCOM hardware d. In the user-space, the created HMAC digest is compared to the HMAC digest that is stored in bootimg.hmac. e. If the HMAC digests match, the test will proceed to perform the integrity application verification otherwise it enters the error state. • self-integrity application verification a. The application reads raw bytes from the application binary /system/bin/qfipsverify which is stored in a temporary buffer b. The temporary buffer is sent to qcedev via an IOCTL and the HMAC SHA-256 signature of the buffer is created using hardware c. In user-space, the created HMAC is compared with the HMAC that is stored in qfipsverify.hmac. d. If this portion of the integrity test passed, the CM proceeds to perform the DRBG KAT tests, otherwise it enters the error state. 3. The integrity test application (qfipsverify) is run once every bootup. If the HMACs match, the integrity tests are considered a success and the DRBG KAT is invoked. If even one of the two parts of the integrity test fails, the flag is set to ”255” and the CM will block all requests (qcedev will block user and qcrypto will block kernel function calls). The DRBG is implicitly blocked as it uses the qcrypto AES interface which as previously stated has been blocked. Both the zimage verification and the self integrity test have to pass in order for the whole integrity test to succeed. 9.4.Conditional Tests Each time entropy is requested from the hardware RNG, a 256 bit block is returned. The block from the first request for entropy is not used but rather stored for comparison purposes. From that point when a request for entropy is made, the 256 bit block returned is compared to the previous 256 bit block that was stored. If the comparison indicates the blocks are equal the test fails, and the CM goes into a panic mode. Similarly, when a request is made for random data from the DRBG, a 128 bit block is generated. The first request is not returned but stored for comparison purposes. When additional requests are made, the current 128 bit block is compared to the stored 128 bit block. If the comparison shows that the blocks are the same, the test fails, the CM causes the system to panic and all functionality stops. Otherwise, when then blocks are different, the conditional test passes and the DRBG will continue to output random bits to its client. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 21 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy The conditional test also runs during device bootup and DRBG driver initialization phase. After successful completion of the DRBG continuous test, the FIPS global status flag is set to ”3” and the build is in FIPS 140 -2 mode. Table 9-2 Conditional tests Algorithm Test DRBG Continuous test HW RNG (non-FIPS compliant) Continuous test © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 22 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 10.Design Assurance 10.1.Configuration Management 10.1.1.Software GIT is used for software (Android) source control and configuration management. GIT is an open source distributed revision control and SCM system. Every GIT working directory is a repository with complete history and full version tracking capabilities, not dependent on network access or a central server. The software (Android) code is in open source domain and is maintained by the Code Aurora Forum (CAF). 10.1.2.Hardware ClearCase, a version control system from IBM/Rational, is used to manage the revision control of the hardware code (Verilog code) and hardware documentation. The ClearCase version control system provides version control, workspace management, parallel development support, and build auditing. The Verilog code is maintained within the QTI ClearCase database. 10.2.Delivery and Operation The cryptographic module is delivered via GIT open source. When customers require urgent delivery of the code, a process known as the software bundle archive (SBA) can be utilized. The following compilation flags must be defined (set to true) in order to generate FIPS compliant code: 1. The CONFIG_FIPS_ENABLE flag, in kernel/arch/arm/configs/ a. refers to the “defconfig” file specific to the cipset for which FIPS compliant code is needed 2. The FIPS_ENABLED flag in device/qcom/common/common.mk If the above mentioned flags are not defined, the generated code is not FIPS compliant. 10.3.Guidance 10.3.1.Crypto Officer Guidance The Crypto Officer can use fastboot to install the crypto library as part of High Level OS image. To enable the QTI Cryptographic Module into the system, the boot image (with filename boot.img) and the system image (with filename system.img) must be compiled and loaded. The Crypto Officer must ensure that the following compilation flags are defined (set to true): • CONFIG_FIPS_ENABLE is defined in the kernel/arch/arm/configs/ file. This ensures the build process will include all FIPS related binaries. • The FIPS_ENABLED flag in device/qcom/common/common.mk The boot.img (containing statically linked kernel modules as cryptographic drivers) and system.img (containing integrity test and authentication data) can be generated by running the command: >mm –j4 at the root directory of Android build. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 23 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy After the build, the Crypto Officer can load boot.img and system.img to a device which is connected to a personal computer with USB cable. Android Debug Bridge (ADB) driver needs to be installed properly. The device enters fastboot mode with the following ADB commands: >adb shell reboot bootloader >fastboot continue Then, the following two commands load the two images: > fastboot flash boot boot.img > fastboot flash system system.img Once flashing is complete, reboot the device: >fastboot reboot This completes the loading of the QTI Cryptographic Module. To activate and set the CM to FIPS-operational mode, a power-cycle is done to invoke the poweron KAT self-tests and integrity tests (Refer to section, Self Tests). The Crypto Officer shall ensure that the User guidance (Section 11.1) is available to cryptographic module users. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 24 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 11. Application Programming Interfaces There are two interfaces into the CM, one from the kernel space and one from the user space. 11.1.User Space APIs Status The status of the cryptographic module is available via the following IOCTL: (Include File: linux/qcedev.h) QCEDEV_IOCTL_QUERY_FIPS_STATUS_IOR(QCEDEV_IOC_MAGIC, 11, fips_status) The returned value in fips_status is mapped by enum fips_status will present the current FIPS status as one of the following: FIPS140_STATUS_NA = 0 (Non FIPS build) FIPS140_STATUS_PASS = 3 (All tests passed and crypto engine is available) FIPS140_STATUS_FAIL = 0xFF (One of the tests failed, crypto engine is unavailable Random Numbers To obtain a random number from the DRBG read data from the hardware random number device file /dev/hw_random. The following example is how the UNIX dd command could be used to read 32000 bytes of random data from the DRBG: dd if=/dev/hw_random of=file bs=32 count=1000 Cryptographic Functions The following cryptographic functions are available via an IOCTL interface: • AES-128 (ECB, CBC, CTR, and XTS mode) • AES-256 (ECB, CBC CTR, and XTS mode) • AES CMAC • Triple-DES (CBC, ECB) • SHA1/SHA256 • SHA1/SHA256 HMAC All requests for service are synchronous. The invoking process will be put to sleep, waiting for completion of the request. Source and destination buffers must point to the same location. Use of different locations for the source and destination buffers is not supported. For performance reasons, buffers must use memory allocated using PMEM thereby allowing the memory to be shared between user space and the kernel. Additionally, when in AES CTR mode and issuing either an encryption or decryption request, a non-zero byte offset is not supported. Prior to invoking the ioctl, the application is required to open a file descriptor to the qcedev device as in the following example: fd = open(“/dev/qce”, O_RDWR); The user may then call the following ioctls with the file descriptor as the first parameter and a pointer to one of the following data structures (as appropriate) for the second parameter: qcedev_cipher_op_req – for cipher operations qcedev_sha_op_req – for hash/HMAC functionality The following Cipher IOCTLs are available to the user space applications: © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 25 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy • QCEDEV_IOCTL_ENC_REQ – for encrypting data • QCEDEV_IOCTL_DEC_REQ – for decrypting data The second parameter is a pointer to the qcedev_cipher_op_req structure defined in qcedev.h: The following hashing/HMAC IOCTLs are available to user space applications: • QCEDEV_IOCTL_SHA_INIT_REQ – initialize a hash/HMAC request • QCEDEV_IOCTL_SHA_UPDATE_REQ – for updating hash/HMAC • QCEDEV_IOCTL_SHA_FINAL_REQ – for ending the hash/HMAC request • QCEDEV_IOCTL_GET_SHA_REQ – retrieve the hash/HMAC for a data packet of a known size • QCEDEV_IOCTL_GET_CMAC_REQ – for retrieving MAC (using the AES CMAC algorithm) for data packet of a known size The second parameter to the IOCTL call is a pointer to the qcedev_sha_op_req structure defined in qcedev.h: The IOCTLs and the associated data request structures are defined in: kernel/include/uapi/linux/qcedev.h It is the callers’ responsibility to zeroize the ‘req’ data structure upon completion of the cipher operation. 11.2.Kernel Space APIs The following concepts are presented to simplify describing the remaining kernel space APIs. Page Vectors: A page is the fundamental unit of memory used by the kernel. Consider data that resides on a specific page, offset from the start of the page by a specific amount and of a particular length. The location of this data can be expressed as a page-based tuple or page vector: {page, offset, length}. Additionally, an existing kernel data structure called a scatterlist is used to operate on arrays of discontiguous page. Transforms: Transforms are objects that instantiate algorithms manage internal state and handle common implementation logic. A set of API transform wrappers are provided in the kernel to simplify transform use and allow the properties of the transform’s underlying algorithm to be queried. 11.2.1.Block Cipher Algorithms The cryptographic block ciphers provided by the CM to kernel space are only available asynchronously and include: • AES 128 (CBC, ECB, CTR, CCM and XTS mode) • AES 256 (CBC, ECB, CTR, CCM and XTS mode) • Triple-DES (CBC, ECB) The following pseudo-code demonstrates a typical calling sequence to the kernel to utilize the block cipher APIs from kernel space asynchronously: tfm = crypto_alloc_ablkcipher(“algorithm 4”, type, mask); 4 Also produces a Message Authentication Code iver_name for the algorithm specified in table 1 in section 2.1. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 26 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy req = ablkcipher_request_alloc(tfm, gfp-flag); ablkcipher_request_set_callback(req, transform-flag, _callback_function_ptr, &result); crypto_ablkcipher_setkey(tfm, key, keylength); crypto_ablkcipher_request_set_crypt(req, src, dest, numbytes, iv); crypto_ablkcipher_encrypt(req); crypto_free_ablkcipher(tfm); ablkcipher_request_free(req); 11.2.2.Hash/HMAC Algorithms The cryptographic block ciphers provided by the CM to kernel space are only available asynchronously and include: SHA-1/SHA-256 HMAC-SHA-1/HMAC-SHA-256 The following pseudo-code demonstrates a typical calling sequence to the kernel to utilize the hash/HMAC APIs from kernel space asynchronously: tfm = crypto_alloc_ahash(“algorithm”, type, mask); req = ahash_request_alloc(tfm, gfp-flag); ahash_request_set_callback(req, transform-flag, _callback_function_ptr, &result); crypto_ahash_setkey(tfm, key, keylength); crypto_ahash_request_set_crypt(req, src, dest, numbytes); crypto_ahash_digest(req); crypto_free_ahash(tfm); ahash_request_free(req); The functions and the associated data structures are defined in: linux/opensource/kernel/include/linux/crypto.h. 11.2.3.Random Numbers The output from /dev/hw_random is fed into /dev/random and from there into the standard kernel RNG. Therefore, to obtain a random number from kernel space use the standard kernel get_random_bytes(buff_addr, length) function. 11.2.4.Status The exported variable "g_fips140_status" (that can be read by any kernel module) is mapped by enum fips_status will present the current FIPS status as one of the following: FIPS140_STATUS_NA = 0 (Non FIPS build) FIPS140_STATUS_PASS = 3 (All tests passed and the crypto engine is available) FIPS140_STATUS_FAIL = 0xFF (One of the tests failed, and the crypto engine is unavailable) © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 27 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 12. Mitigation of Other Attacks The Mitigation of Other Attacks security section of FIPS 140-2 is not applicable to the QTI Cryptographic Module. © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 28 of 29 QTI Cryptographic Module on Crypto 5 Core FIPS 140-2 Security Policy 13.Terms and Abbreviations Advanced Encryption Specification AES Cryptographic Algorithm Validation Program CAVP Cipher Block Chaining CBC Cryptographic Engine CE Counter with Cipher Block Chaining-Message Authentication Code CCM Cryptographic Module CM Cryptographic Module Testing CMT Cryptographic Module Validation Program CMVP Commercial Off The Shelf COTS Crypto Officer CO Critical Security Parameter CSP Data Encryption Standard DES Federal Information Processing Standards Publication FIPS Finite State Model FSM Hash Message Authentication Code HMAC Input Output Control IOCTL Known Answer Test KAT Message Authentication Code MAC National Institute of Science and Technology NIST National Voluntary Laboratory Accreditation Program NVLAP Operating System O/S Qualcomm Technologies, Inc. QTI Random Number Generator RNG Software Bundle Archive SBA Source Code Management SCM Secure Hash Algorithm SHA Secure Hash Standard SHS Service Level Agreement SLA Strength of Function SOF Triple DES TDES Transform TFM User Interface UI © 2014 QTI/atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 29 of 29