Samsung Kernel Cryptographic Module FIPS 140-2 Non-Proprietary Security Policy version 1.8 Last Update: 2014-07-11 ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 1. Introduction ..................................................................................................................................... 4 1.1. Purpose of the Security Policy .......................................................................................... 4 1.2. Target Audience ..................................................................................................................... 4 2. Cryptographic Module Specification ...................................................................................... 5 2.1. Description of Module .......................................................................................................... 5 2.2. Description of Approved Mode ......................................................................................... 5 2.3. Cryptographic Module Boundary ..................................................................................... 7 2.3.1. Software Block Diagram ........................................................................................... 7 2.3.2. Hardware Block Diagram ......................................................................................... 7 3. Cryptographic Module Ports and Interfaces ........................................................................ 9 4. Roles, Services and Authentication ........................................................................................ 9 4.1. Roles ........................................................................................................................................... 9 4.2. Services ..................................................................................................................................... 9 4.3. Operator Authentication ....................................................................................................11 4.4. Mechanism and Strength of Authentication ...............................................................11 5. Finite State Machine ................................................................................................................... 12 6. Physical Security.......................................................................................................................... 12 7. Operational Environment ......................................................................................................... 12 7.1. Policy ........................................................................................................................................ 12 8. Cryptographic Key Management ........................................................................................... 13 8.1. Random Number Generation .......................................................................................... 13 8.2. Key Generation ..................................................................................................................... 13 8.3. Key Entry and Output ......................................................................................................... 13 8.4. Key Storage............................................................................................................................ 13 8.5. Zeroization Procedure ........................................................................................................ 13 9. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) .............. 13 10. Self-Tests ....................................................................................................................................... 14 10.1. Power-Up Tests ................................................................................................................... 14 10.2. Integrity Check ................................................................................................................... 14 10.3. Conditional Tests ............................................................................................................... 14 11. Design Assurance ..................................................................................................................... 15 11.1. Configuration Management .......................................................................................... 15 11.2. Delivery and Operation ................................................................................................... 15 12. Mitigation of Other Attacks ................................................................................................... 15 ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13. Glossary and Abbreviations .................................................................................................. 16 14. References ................................................................................................................................... 16 ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 1. Introduction This document is a non-proprietary FIPS 140-2 Security Policy for the Samsung Kernel Cryptographic Module. It contains a specification of the rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a Security Level 1 multi-chip standalone software module. This security policy, v1.8, is for the revalidation of the Samsung Kernel Cryptographic Module to include information about new test platform and minor code changes. The security policy from the previous validated version of the module can be found on CMVP validation website under certificates #1648 and #1915. 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 cryptographic module, as implemented, satisfies the stated security policy, and  it describes the capabilities, protection, and access rights provided by the cryptographic module, allowing individuals and organizations to determine whether it will meet their security requirements. 1.2. Target Audience This document is intended to be part of the package of documents that are submitted for FIPS validation. It is intended for the following people:  Developers working on the release  FIPS 140-2 testing lab  Crypto Module Validation Program (CMVP)  Consumers ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2. Cryptographic Module Specification This document is the non-proprietary security policy for the Samsung Kernel Cryptographic Module, and was prepared as part of the requirements for conformance to Federal Information Processing Standard (FIPS) 140-2, Level 1. The following section describes the module and how it complies with the FIPS 140-2 standard in each of the required areas. 2.1. Description of Module The Samsung Kernel Cryptographic Module is a software only security level 1 cryptographic module that provides general-purpose cryptographic services to the remainder of the Linux kernel. The crypto module runs on an ARM 7 processor. The following table shows the overview of the security level for each of the eleven sections of the validation. Security Component Security Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 3 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A Table 1: Security Levels The module has been tested on the following platforms: Module/Implementation Processor Device O/S & Ver. Samsung Kernel ARM 7 Samsung Galaxy S5 Android KitKat 4.4.2 Cryptographic Module (SKC1.4.1.3) Table 2: Tested Platforms 2.2. Description of Approved Mode When the module is initialized, the self-tests are executed automatically at the loading time and the module enters FIPS mode if the self-tests pass. A kernel proc file is set to indicate if device is in FIPS 140-2 approved mode or in error state. The error state flag is used for the value of the process file /proc/sys/crypto/fips_status (return 0 if in FIPS mode; return 1 if in FIPS Error.) Users can check the module status from the main screen, start the Settings application, go to “About Phone”, and status is displayed in the listings. In the Approved mode the module provides the following approved functions:  AES (CBC, ECB) which can be C (aes-generic) or Assembly (aes-asm) implementations. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice.  SHA-1, SHA-224, SHA-256, SHA-384, SHA-512. SHA-1 can be C (sha1) or Assembly (sha1- asm) implementations.  RNG (ANSI X9.31) using AES 128-bit when called with fips(ansi_cprng)  Triple-DES (CBC, ECB)  HMAC (with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512) The cryptographic module provides 2 implementations of AES and SHA-1: regular C or streamlined assembler codes which are loaded in kernel module form. Note, if both implementations are loaded in the kernel, the respective implementation can be requested by using the following cipher mechanism strings with the initialization calls (such as crypto_alloc_blkcipher or crypto_alloc_hash):  AES regular C code: “aes-generic”  AES assembler code: “aes-asm”  SHA-1 regular C code: “sha1-generic”  SHA-1 assembler code: “sha1-asm” The AES and SHA-1 implementation can also be loaded by simply using the string “aes” or “sha1” with the initialization call. In this case, the AES and SHA-1 implementation whose kernel module is loaded with the highest priority is used. In Samsung Kernel Cryptographic Module, assembler implementations are defined to have higher priority than the regular C implementation for both AES and SHA-1. Thus, only one of these implementations can be executed with an initialization call. Kernel Crypto API implements the following Non-Approved algorithms, which shall not be used in the FIPS 140-2 approved mode of operation. Any use of the non-Approved functions will cause the module to operate in the non-FIPS mode implicitly:  DES  Twofish  MD4  MD5  ansi_cprng  ARC4  Pcompress  AES-XCBC  CRC32c  Deflate  LZO ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2.3. Cryptographic Module Boundary 2.3.1. Software Block Diagram Physical Boundary Application Samsung Kernel Cryptographic Module Kernel Boundary Logical Boundary Figure 1: Software Block Diagram The binary image that contains the Crypto API module for the appropriate platform is as follows:  boot.img (version SKC1.4.1.3) Related documentation:  S/W Detailed Level Design v1.15  Samsung Kernel Cryptographic Module FIPS 140-2 Security Policy (this document) Note: The master component list is provided in Section 2.10 of S/W Detailed Level Design document. 2.3.2. Hardware Block Diagram This figure illustrates the various data, status and control paths through the cryptographic module. Inside, the physical boundary of the module, the mobile device consists of standard integrated circuits, including processors and memory. These do not include any security-relevant, semi- or custom integrated circuits or other active electronic circuit elements. The physical boundary includes power inputs and outputs, and internal power supplies. The logical boundary of the cryptographic module contains only the security-relevant software elements that comprise the module. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. Physical boundary Figure 2: Hardware Block Diagram ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3. Cryptographic Module 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 file, /proc/sys/crypto/fips_status, the status of the module is also provided at user interface Power Input Physical power connector Table 3: Ports and Interfaces 4. Roles, Services and Authentication 4.1. Roles Role Services (see list below) User Encryption, Decryption, Random Numbers Generation, Digest Creation Crypto Officer Initialization of Module Table 4: Roles The Module meets all FIPS 140-2 level 1 requirements for Roles and Services, implementing both User and Crypto Officer roles. The Module does not allow concurrent operators. The User and Crypto Officer roles are implicitly assumed by the entity accessing services implemented by the Module. No further authentication is required. The Crypto Officer can initialize the Module. 4.2. Services See section 1.2 for the complete list of approved and non-approved cryptographic services. This table only covers the approved services. Role Algorithms and CSP Modes FIPS Standards Access Services Approved (Read, (Cert #) Write, Execute) User AES encryption and 128, 192, ECB, CBC Cert #2809 FIPS 197 R, W, EX decryption 256 bit keys User AES (Assembly 128, 192, ECB, CBC Cert #2810 FIPS 197 R, W, EX implementation) 256 bit keys encryption and decryption User HMAC (with SHA-1, At least 112 N/A Cert #1760 FIPS 198-1 R, W, EX SHA-224, SHA-256, bits HMAC SHA 384, SHA 512) key User HMAC (with SHA-1 At least 112 N/A Cert #1761 FIPS 198-1 R, W, EX Assembly bits HMAC implementation) key User SHA-1, SHA-224, SHA- N/A N/A Cert #2357 FIPS 180-4 R, W, EX 256, SHA-384, SHA-512 ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. Role Algorithms and CSP Modes FIPS Standards Access Services Approved (Read, (Cert #) Write, Execute) User SHA-1 Assembly N/A N/A Cert #2358 FIPS 180-4 R, W, EX Implementation User Triple-DES encryption 2 key & 3 CBC, ECB Cert #1687 SP 800-67 R, W, EX and decryption key User RNG 128 bits AES-128 Certs #1275, ANSI X9.31 R, W, EX seed and #1276 seed key Crypto Initialization N/A N/A N/A N/A N/A Officer User, Self-Test 256 bits N/A N/A N/A R, EX Crypto (Self-test is executed HMAC value Officer automatically when for integrity device is booted or test restarted) User, Check Status/Get State N/A N/A N/A N/A R Crypto Officer User Zeroization AES key, N/A N/A N/A R, W, EX Triple-DES key, HMAC key, seed and seed key Table 5: Approved Services Note: The module supports 2-key and 3-key Triple-DES. Restriction applies to the 2-key Triple-DES 20 that at most 2 blocks of data can be encrypted with the same key in Approved mode according to SP800-131A. Two-key Triple-DES encryption will be disallowed by NIST after 2015. The following table identifies the non-FIPS-approved services: Role Algorithms and Services CSP Access (Read, Write, Execute) User DES 56 bit keys R, W, EX User Twofish 128, 192, 256 bit keys R, W, EX User MD4 N/A R, W, EX User MD5 N/A R, W, EX User ansi_cprng (non-Approved RNG) Seed R, W, EX User ARC4 Various key sizes R, W, EX User Pcompress (Partial N/A R, W, EX (de)compression) User AES-XCBC (RFC 3566; The AES- 128 bits keys R, W, EX XCBC-MAC-96 Algorithm and Its Use With IPsec) User CRC32c N/A R, W, EX ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. Role Algorithms and Services CSP Access (Read, Write, Execute) User Deflate (Data compression N/A R, W, EX algorithm) User LZO (Data compression N/A R, W, EX algorithm) Table 6: Non-Approved Services The cryptographic module is part of the kernel image. The following documents provide a description and API functions of the cryptographic services listed above:  Linux system call API man pages provided in chapter 2 of the Linux man pages obtainable from git://github.com/mkerrisk/man-pages.git  Linux kernel internals including interfaces between kernel components documented in the book ISBN-13: 978-0470343432  Linux kernel driver development documentation covering the kernel interfaces available for device drivers: ISBN-13: 978-0596005900  Functional Design document provided by Samsung is available upon request. 4.3. Operator Authentication There is no operator authentication; assumption of role is implicit by action. 4.4. Mechanism and Strength of Authentication No authentication is required at security level 1; authentication is implicit by assumption of the role. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5. Finite State Machine For information pertaining to the Finite State Model, please refer to the Functional Design document. 6. Physical Security The Module is comprised of software only and thus does not claim any physical security. 7. Operational Environment This module will operate in a modifiable operational environment per the FIPS 140-2 definition. 7.1. Policy The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded). The external application that makes calls to the cryptographic module is the single user of the cryptographic module, even when the application is serving multiple clients. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8. Cryptographic Key Management 8.1. Random Number Generation The Module employs an ANSI X9.31 compliant random number generator for creation of random numbers. Note: the RNG seed is the tuple {V key DT}, where those values are defined in ANSI X9.31 Appendix A.2.4. The calling user provides the seed and seed key, usually by obtaining bits via get_random_bytes() from the Linux-provided /dev/random pseudo-device which is provided by the underlying Operating System. The caller must ensure that the seed and seed key for the DRNG is inserted into the DRNG consistent with FIPS 140-2 requirements, i.e. that they are not identical. Failure to comply with this requirement will cause the module to go into an Error state. 8.2. Key Generation 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. Seeds for random number generation are imported into the module. 8.3. Key Entry and Output The module does not support manual key entry or key output. Keys or other CSPs can only be exchanged between the module and the calling application using appropriate API calls. 8.4. Key Storage Keys are not stored inside crypto module. A pointer to plaintext key is passed through. Intermediate key storages are immediately assigned to Zero. 8.5. Zeroization Procedure The zeroization mechanism for all of the CSPs is to replace 0s in the memory which originally store the CSPs. For more details on zeroization API functions, please refer to the Functional Design document which is provided by Samsung upon request. 9. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) Lab Name: PCTEST Engineering Laboratory, Inc. FCC Registration: #90864 The test device which runs the module conforms to the EMI/EMC requirements specified by 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B (i.e., for home use). For information related to FCC ID of the devices, please refer to the Functional Design document which is provided by Samsung upon request. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10. Self-Tests Self-test uses the existing Crypto API tcrypt module to perform known-answer self-test of algorithms. The module is configured as a built-in kernel module instead of a loadable module as is the case of Linux Crypto API. Tests of all FIPS-approved algorithms are executed. The self-tests are run during early-kernel startup when built-in kernel modules are initialized. Self-tests can also be invoked by the user by restarting the device. When self-tests are done successfully, an indication will be shown in the settings menu. A binary integrity test will then be performed in call from tcrypt. If self-test or integrity test fail, an error flag (static variable) is set, an error code returns to the API function caller to indicate the error, the module enters in an error state (FIPS_ERR), and Crypto APIs that return cryptographic information is blocked. 10.1. Power-Up Tests At module start-up, Known Answer Tests are performed. These tests are automatic and do not need operator intervention. If the value calculated and the known answer does not match, the module immediately enters into FIPS_ERR state. Once the module is in FIPS_ERR state, the module becomes unusable via any interface. The module implements each of the following Known Answer Tests separately:  AES encryption and decryption tested separately, with and without AES assembler  Triple-DES encryption and decryption tested separately  HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, with and without SHA1 assembler  SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, with and without SHA1 assembler  ANSI X9.31 Random Number Generator 10.2. Integrity Check At build time -  Calculate a hmac(sha256) of only the module code (available in .text, .rodata, .init.text and .exit.text sections of kernel image).  Once generated, the build time hmac of the module code is updated in the kernel image itself as a read-only data. At run time –  Calculate a hmac(sha256) of only the module code, available in running kernel on the device (.text, .init.text, .exit.text and .rodata sections of running kernel) If this run-time hmac is same as build time hmac, Integrity test is considered passed. If calculated and stored values do not match, set error state, FIPS_ERR. 10.3. Conditional Tests A continuous random number generator test is performed during each use of the Approved RNG. If values of two consecutive random numbers match, then crypto module goes into error state. A CRNG test is also implemented for the Linux provided /dev/random RNG which is usually used by calling user for seeding the Approved RNG. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11. Design Assurance 11.1. Configuration Management For version 1.4.1.3 and onwards, Perforce is used as the repository for both source code and documents. All source code and documents are maintained in internal server. Release is based on the Changelist number, which is auto-generated. Every check-in process creates a new Changelist number. Versions of controlled items include information about each version. For documentation, revision history inside the document provides the current version of the document. Version control maintains the all the previous version and the version control system automatically numbers revisions. For source code, unique information is associated with each version such that source code versions can be associated with binary versions of the final product. The source code of the module (version SKC1.4.1.3) available in the Samsung internal Perforce repository, as listed in Functional Design document, is used to build target binary. 11.2. Delivery and Operation The crypto module is never released as Source code. The module sources are stored and maintained at a secure development facility with controlled access. This crypto module is built-in along with the Linux Kernel. Product that does not need FIPS 140-2 certified cryptographic module may decide to change the build flag CONFIG_CRYPTO_FIPS in Kernel config. The development team and the manufacturing factory share a secured internal server for exchanging binary software images. The factory is also a secure site with strict access control to the manufacturing facilities. The module binary is installed on the mobile devices (phone and tablets) using direct binary image installation at the factory. The mobile devices are then delivered to mobile service operators. Users cannot install or modify the module. The developer also has the capability to deliver software updates to service operators who in turn can update end-user phones and tablets using Over-The-Air (OTA) updates. Alternatively, the users may bring their mobile devices to service stations where authorized operators may use developer-supplied tools to install software updates on the phone. The developer vets all service providers and establishes secure communication with them for delivery of tools and software updates. If the binary is modified by unauthorized entity, the device has a feature to detect the change and thus not accept the binary modified by an unauthorized entity. 12. Mitigation of Other Attacks No other attacks are mitigated. ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13. Glossary and Abbreviations AES Advanced Encryption Specification CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CMT Cryptographic Module Testing CMVP Cryptographic Module Validation Program CSP Critical Security Parameter DES Data Encryption Standard FSM Finite State Model HMAC Hash Message Authentication Code MAC Message Authentication Code NIST National Institute of Science and Technology O/S Operating System RNG Random Number Generator SDK Software Development Kit SHA Secure Hash Algorithm SHS Secure Hash Standard TDES Triple DES UI User Interface 14. References [1] FIPS 140-2 Standard, http://csrc.nist.gov/groups/STM/cmvp/standards.html [2] FIPS 140-2 Implementation Guidance, http://csrc.nist.gov/groups/STM/cmvp/standards.html [3] FIPS 140-2 Derived Test Requirements, http://csrc.nist.gov/groups/STM/cmvp/standards.html [4] FIPS 197 Advanced Encryption Standard, http://csrc.nist.gov/publications/PubsFIPS.html [5] FIPS 180-4 Secure Hash Standard, http://csrc.nist.gov/publications/PubsFIPS.html [6] FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC), http://csrc.nist.gov/publications/PubsFIPS.html [7] SP800-67 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, http://csrc.nist.gov/publications/PubsFIPS.html [8] ANSI X9.31 Digital Signatures Using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) ©2014 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact, including this copyright notice.