©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Samsung Kernel Cryptographic Module
FIPS 140-2 Non-Proprietary Security Policy
Version 1.16
Last Update: 2015-08-20
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 2
1. Introduction...................................................................................................................................3
1.1. Purpose of the Security Policy ................................................................................................3
1.2. Target Audience......................................................................................................................3
2. Cryptographic Module Specification..............................................................................................4
2.1. Description of Module.............................................................................................................4
2.2. Description of Approved Mode ...............................................................................................4
2.3. Cryptographic Module Boundary ............................................................................................6
2.3.1. Software Block Diagram..............................................................................................6
2.3.2. Hardware Block Diagram ............................................................................................6
3. Cryptographic Module Ports and Interfaces ..................................................................................8
4. Roles, Services and Authentication ...............................................................................................8
4.1. Roles ......................................................................................................................................8
4.2. Services..................................................................................................................................8
4.3. Operator Authentication.......................................................................................................10
4.4. Mechanism and Strength of Authentication .........................................................................10
5. Finite State Machine....................................................................................................................11
6. Physical Security.........................................................................................................................11
7. Operational Environment ............................................................................................................11
7.1. Policy....................................................................................................................................11
8. Cryptographic Key Management.................................................................................................12
8.1. Random Number Generation................................................................................................12
8.2. Key Generation.....................................................................................................................12
8.3. Key Entry and Output ...........................................................................................................12
8.4. Key Storage..........................................................................................................................12
8.5. Zeroization Procedure ..........................................................................................................12
9. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ....................................13
10. Self-Tests ...................................................................................................................................13
10.1. Power-Up Tests ...................................................................................................................13
10.2. Integrity Check...................................................................................................................13
10.3. Conditional Tests ................................................................................................................14
11. Design Assurance......................................................................................................................14
11.1. Configuration Management................................................................................................14
11.2. Delivery and Operation ......................................................................................................14
12. Mitigation of Other Attacks .......................................................................................................14
13. Glossary and Abbreviations.......................................................................................................15
14. References ................................................................................................................................15
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 3
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.16, 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, #1915, #2214 and #2337.
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
 Cryptographic Module Validation Program (CMVP)
 Consumers
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 4
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 cryptographic module runs on an ARMv8 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
Cryptographic Module
(SKC1.6)
ARMv8 Samsung Galaxy S6 Android Lollipop 5.0.2
Samsung Kernel
Cryptographic Module
(SKC1.6)
ARMv7 Samsung Galaxy Tab S2 Android Lollipop 5.1
Table 2. Tested Platforms
Note: Per IG G.5, CMVP makes no statement as to the correct operation of the module or the
security strengths of the generated keys when so ported if the specific operational environment is
not listed on the validation certificate.
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-Approved mode automatically if the self-tests pass. A kernel proc file is set
to indicate if device is in FIPS-Approved mode or in error state. The error state flag is used for the
value of the process file /proc/sys/crypto/fips_status (returns 0 if in FIPS-Approved mode; returns 1
if in FIPS Error.)
Users can check the module status by connecting the device to a PC and issuing the following
command, $adb shell cat /proc/sys/crypto/fips_status. (returns 0 if in FIPS-Approved mode; returns
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 5
1 if in FIPS Error.)
When the module is in the operational state, it can alternate service by service between FIPS-
Approved mode and non-FIPS mode.
The module provides the following CAVP validated algorithms in either FIPS Approved mode or
non-FIPS mode:
Algorithms Standards FIPS Approved
(Cert #)
AES (ECB, CBC) encryption and decryption with 128,
192, 256 bits key
FIPS 197 Cert. #3292, #3461
AES GCM encryption and decryption with 128, 192,
256 bits key, IV generated externally
SP 800-38D Cert. #3292, #3461
HMAC with SHA-1, SHA-224, SHA-256, SHA-384,
SHA-512
FIPS 198-1 Cert. #2090, #2207
SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 FIPS 180-4 Cert. #2731, #2857
Triple-DES (ECB, CBC) encryption and decryption SP 800-67 Cert. #1877, #1952
RNG with AES-128 ANSI X9.31 Certs. #1355
Hash-based DRBG with SHA-1, SHA-256, SHA-384,
SHA-512
SP 800-90A Certs. #750, #849
HMAC-based DRBG with SHA-1, SHA-256, SHA-384,
SHA-512
SP 800-90A Certs. #750, #849
Block Cipher (CTR) based DRBG with AES-128, AES-
192, AES-256
SP 800-90A Certs. #750, #849
Table 3. CAVP validated algorithms
Note: Due to the RNG transition in the end of 2015 listed in SP 800-131A, the ANSI X9.31 RNG
implemented in the module only operates in non-FIPS even though it has been validated by CAVP
and it meets the self-tests requirements described in section 4.9 of FIPS 140-2 standard.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 6
2.3. Cryptographic Module Boundary
2.3.1.Software Block Diagram
The binary image that contains the Samsung Kernel Cryptographic Module for the appropriate
platform is as follows:
 boot.img (version SKC1.6)
Related documentation:
 S/W Detailed Level Design v1.18
 Samsung Kernel Cryptographic Module FIPS 140-2 Non-Proprietary 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.
Figure 1: Software Block Diagram
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 7
Figure 2: Hardware Block Diagram
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 8
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
Power Input Physical power connector
Table 4. Ports and Interfaces
4. Roles, Services and Authentication
4.1. Roles
Role Description
User Perform general security services, including cryptographic operations and
other Approved security functions.
Crypto Officer Perform Initialization of Module.
Table 5. 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
The following table describes the services in FIPS-Approved mode:
Role Services Algorithms CSP Access
(Read,
Write,
Execute)
User Symmetric Encryption and
Decryption
AES with:
 ECB
 CBC
128, 192, 256 bits key R, W, EX
3-key Triple-DES
with:
 ECB
 CBC
168 bits key R, W, EX
User Keyed Hash HMAC with:
 SHA-1
 SHA-224
 SHA-256
 SHA-384
 SHA-512
At least 112 bits HMAC key R, W, EX
User Message Digest SHA-1, SHA-224,
SHA-256, SHA-384,
SHA-512
N/A R, W, EX
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 9
Role Services Algorithms CSP Access
(Read,
Write,
Execute)
User Random Number
Generation with “drbg”
Hash-based DRBG
with:
 SHA-1
 SHA-256
 SHA-384
 SHA-512
Entropy input string, seed, V
and C
R, W, EX
HMAC-based DRBG
with:
 SHA-1
 SHA-256
 SHA-384
 SHA-512
Entropy input string, seed, V
and Key
R, W, EX
Block Cipher (CTR)
based DRBG with:
 AES-128
 AES-192
 AES-256
Entropy input string, seed, V
and Key
R, W, EX
Crypto
Officer
Initialization N/A N/A EX
User Self-Test
(Self-test is executed
automatically when
device is booted or
restarted)
AES, Triple-DES,
HMAC, SHA and
DRBG
344 bits HMAC Key for
integrity test
R, EX
User Check Status/Get State N/A N/A R
User Zeroization N/A AES key, Triple-DES key,
HMAC key, seed
R, W, EX
Table 6. Approved Services
The following table describes the services in non-FIPS mode. Any use of these services with non-
Approved algorithms will cause the module to operate in the non-FIPS mode implicitly.
Role Services Algorithms CSP Access
(Read,
Write,
Execute)
User Symmetric
Encryption and
Decryption
DES 56 bit keys R, W, EX
Twofish 128, 192, 256 bits key R, W, EX
ARC4 Various key sizes R, W, EX
AES GCM mode (AES-GCM) 128, 192, 256 bits key R, W, EX
RFC 4106 AES GCM mode
(RFC4106-AES-GCM)
128, 192, 256 bits key R, W, EX
RFC 4543 AES GCM mode
(RFC4543-AES-GCM)
128, 192, 256 bits key R, W, EX
AES CTR mode (AES-CTR) 128, 192, 256 bits key R, W, EX
Triple-DES CTR mode (Triple-
DES-CTR)
112, 168 bits key R, W, EX
2-key Triple-DES 112 bits key R, W, EX
User Message Digest MD5 N/A R, W, EX
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 10
Role Services Algorithms CSP Access
(Read,
Write,
Execute)
User Random Number
Generation with
“ansi_cprng”,
“krng” or
“fips(ansi_cprng)”
ansi_cprng Seed R, W, EX
Krng Seed R, W, EX
fips(ansi_cprng)
Note: This is the CAVP validated
ANSI X9.31 RNG with AES-128;
however, it is disallowed after
2015.
128 bits seed and
seed key
R, W, EX
User Partial Compression
and Decompression
Pcompress N/A R, W, EX
User Error Detecting
Code
CRC32c N/A R, W, EX
User Data Compression Deflate N/A R, W, EX
LZO N/A R, W, EX
User Hashing GHASH N/A R, W, EX
User Multiplication
Function
GF128MUL N/A R, W, EX
Table 7. Non-Approved Services
Note: The module does not share CSPs between an Approved mode of operation and a
non‐Approved mode of operation. All cryptographic keys used in the FIPS-Approved must be
imported to the module via API input parameters while running in the FIPS-Approved mode. The
non-Approved RNG shall only be used for non-Approved services in non-FIPS mode.
The cryptographic module is part of the kernel image. The following documents provide a
description and API functions of the cryptographic services listed above:
 https://www.kernel.org/doc/Documentation/crypto/api-intro.txt
 http://www.linuxjournal.com/article/6451?page=0,0
 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.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 11
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.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 12
8. Cryptographic Key Management
The keys and CSPs in FIPS-Approved mode are described in the following table:
Algorithm Keys/CSPs Keys/CSPs
Input
Keys/CSPs
Output
Keys/CSPs
Zeroization
AES Key 128, 192 and 256
bits key
API input parameter N/A Call the zeroization API
function for block
cipher
Triple-DES 168 bits key API input parameter N/A Call the zeroization API
function for block
cipher
HMAC At least 112 bits
HMAC key
API input parameter N/A Call the zeroization API
function for hash
SP 800-90A
DRBG
Entropy input
string
The seed is provided
by the /dev/random
N/A Call the zeorization
API function for prng
SP 800-90A
DRBG
seed, V, C and
Key
N/A N/A Call the zeorization
API function for prng
HMAC with
SHA-256
344 bits HMAC
key for integrity
test
N/A N/A Not required to be
zeroized according to
FIPS 140-2 IG 7.4
Table 8. Key Input, Key Output and Key Zeroization for Keys/CSPs
8.1. Random Number Generation
The module employs an Approved SP 800-90A DRBG for creation of random numbers in FIPS
Approved mode. The entropy for seeding the SP 800-90A DRBG is obtained by calling the
get_random_bytes() function to collect random data from the Linux-provided /dev/random pseudo-
device provided by the underlying Operating System.
CAVEAT: The module generates random strings whose strengths are modified by available entropy.
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 cryptographic 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. It is the calling application responsibility to call the appropriate key zeroization API
function to zeroize the keys/CSPs after their use. For more details on zeroization API functions,
please refer to the Functional Design document which is provided by Samsung upon request.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 13
9. Electromagnetic Interference/Electromagnetic Compatibility
(EMI/EMC)
Lab Name: Samsung Electronics EMC Laboratory
FCC Registration: #451343
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.
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, the proc entry
for /proc/sys/crypto/fips_status will return 0. 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. The proc entry for
/proc/sys/crypto/fips_status will return 1 when the module is in ERROR state.
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
 Triple-DES encryption and decryption tested separately
 HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512
 SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
 SP 800-90A DRBG (Hash_DRBG, HMAC_DRBG and CTR_DRBG)
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.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 14
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 SP
800-90A DRBG. If values of two consecutive random numbers match, then cryptographic 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 SP 800-90A DRBG.
11. Design Assurance
11.1. Configuration Management
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.6) 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 cryptographic module is never released as Source code. The module sources are stored and
maintained at a secure development facility with controlled access.
This cryptographic 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.
©2015 Samsung Electronics Co., Ltd. This document can be reproduced and distributed only whole and intact,
including this copyright notice.
Page 15
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
DRBG Deterministic Random Bit Generator
FSM Finite State Model
GCM Galois/Counter Mode
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
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] SP 800-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)
[9] SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM)
and GMAC, http://csrc.nist.gov/publications/PubsSPs.html
[10] SP 800-90A Recommendation for Random Number Generation Using Deterministic Random
Bit Generators, http://csrc.nist.gov/publications/PubsSPs.html
[11] SP 800-131A Transitions: Recommendation for Transitioning the Use of Cryptographic
Algorithms and Key Lengths, http://csrc.nist.gov/publications/PubsSPs.html