Security Builder® FIPS Module
Version 6.5.0
FIPS 140-2 Non-Proprietary
Security Policy
BlackBerry Limited
July 12, 2022
2
Copyright © 2022 BlackBerry Limited
This document may be freely reproduced and distributed whole and intact including this
Copyright Notice.
This software contains trade secrets, confidential information, and other intellectual property of
BlackBerry Ltd. and its licensors. This software cannot be used, reproduced, or distributed in
whole or in part by any means without the explicit prior consent of BlackBerry Ltd. Such
consent must arise from a separate license agreement from BlackBerry or its licensees, as
appropriate.
Certicom, Certicom AMS, ACC, Asset Control Core, Certicom Bar Code Authentication Agent,
Certicom ECC Core, Certicom Security Architecture, Certicom Trusted Infrastructure, Certicom
CodeSign, Certicom KeyInject, ChipActivate, DieMax, Security Builder, Security Builder API,
Security Builder API for .NET, Security Builder BSP, Security Builder Crypto, Security Builder
ETS, Security Builder GSE, Security Builder IPSec, Security Builder MCE, Security Builder
NSE, Security Builder PKI, Security Builder SSL and SysActivate are trademarks or registered
trademarks of BlackBerry Ltd. All other companies and products listed herein are trademarks or
registered trademarks of their respective holders.
BlackBerry®, RIM®, Research In Motion® and related trademarks are owned by BlackBerry
Limited, used under license.
Patents per 35 U.S.C. § 287(a) and in other jurisdictions, where allowed:
www.blackberry.com/patents.
3
Contents
1 INTRODUCTION ...................................................................................................5
1.1 OVERVIEW................................................................................................................5
1.2 PURPOSE..................................................................................................................5
1.3 REFERENCES..............................................................................................................5
1.4 CHANGE HISTORY ......................................................................................................6
2 CRYPTOGRAPHIC MODULE SPECIFICATION............................................................7
2.1 PHYSICAL SPECIFICATIONS............................................................................................ 7
2.2 COMPUTER HARDWARE AND OS ..................................................................................9
2.3 SOFTWARE SPECIFICATIONS .......................................................................................10
3 CRYPTOGRAPHIC MODULE PORTS AND INTERFACES ........................................... 10
4 ROLES, SERVICES, AND AUTHENTICATION ........................................................... 12
4.1 ROLES AND SERVICES................................................................................................12
4.2 OPERATOR AUTHENTICATION.....................................................................................16
5 FINITE STATE MODEL.......................................................................................... 17
6 PHYSICAL SECURITY ........................................................................................... 18
7 OPERATIONAL ENVIRONMENT ........................................................................... 19
7.1 MODES OF OPERATIONS............................................................................................19
8 CRYPTOGRAPHIC KEY MANAGEMENT................................................................. 20
8.1 KEY GENERATION.....................................................................................................21
8.2 KEY ESTABLISHMENT.................................................................................................21
8.3 KEY ENTRY AND OUTPUT...........................................................................................21
8.4 KEY STORAGE..........................................................................................................21
8.5 ZEROIZATION OF KEYS AND CSPS................................................................................21
9 SELF-TESTS......................................................................................................... 22
9.1 POWER-UP TESTS.....................................................................................................22
9.1.1 Tests upon Power-up..............................................................................22
9.1.2 On-Demand Self-Tests............................................................................23
9.2 CONDITIONAL TESTS.................................................................................................23
9.3 CRITICAL FUNCTION TESTS.........................................................................................23
9.4 FAILURE OF SELF-TESTS.............................................................................................23
10 DESIGN ASSURANCE........................................................................................... 24
10.1 CONFIGURATION MANAGEMENT ................................................................................24
10.2 DELIVERY AND OPERATION ........................................................................................24
10.3 DEVELOPMENT ........................................................................................................24
10.4 GUIDANCE DOCUMENTS............................................................................................24
11 MITIGATION OF OTHER ATTACKS........................................................................ 25
11.1 TIMING ATTACK ON RSA...........................................................................................25
4
12 ENTROPY SOURCE.............................................................................................. 26
A CRYPTO OFFICER AND USER GUIDE..................................................................... 27
A.1 INSTALLATION..........................................................................................................27
A.1.1 Installing.................................................................................................27
A.1.2 Uninstalling.............................................................................................27
A.2 COMMANDS ...........................................................................................................27
A.2.1 Load........................................................................................................27
A.2.2 Unload ....................................................................................................28
A.2.3 Self-Tests.................................................................................................28
A.2.4 Show Status/Mode.................................................................................28
A.3 WHEN MODULE IS DISABLED .....................................................................................28
A.4 OPERATION LIMITATION FOR FIPS APPROVED MODE ......................................................28
5
1 Introduction
1.1 Overview
This is a non-proprietary Federal Information Processing Standard (FIPS) 140-2 Security
Policy for Certicom’s Security Builder® FIPS Module Version 6.5.0 (SB FIPS
Module). SB FIPS Module is a cryptographic toolkit for C language users, providing
services of various cryptographic algorithms such as hash algorithms, encryption
schemes, message authentication, and public key cryptography. This Security Policy
specifies the rules under which SB FIPS Module must operate. These security rules are
derived from the requirements of FIPS 140-2 [1], and related documents [6, 7, 8].
1.2 Purpose
This Security Policy is created for the following purposes:
1. It is required for FIPS 140-2 validation.
2. To outline SB FIPS Module’s conformance to FIPS 140-2 Level 1 Security
Requirements.
3. To provide users with information on how to configure and operate the
cryptographic module in order to comply with FIPS 140-2.
1.3 References
References
[1] NIST Security Requirements for Cryptographic Modules, FIPS PUB 140-2,
December 3, 2002.
[2] NIST Security Requirements for Cryptographic Modules, Annex A: Approved
Security Functions for FIPS PUB 140-2, Draft, May 10, 2017.
[3] NIST Security Requirements for Cryptographic Modules, Annex B: Approved
Protection Profiles for FIPS PUB 140-2, Draft, December 21, 2016.
[4] NIST Security Requirements for Cryptographic Modules, Annex C: Approved
Random Number Generators for FIPS PUB 140-2, Draft, January 04, 2016.
[5] NIST Security Requirements for Cryptographic Modules, Annex D: Approved Key
Establishment Techniques for FIPS PUB 140-2, Draft, May 10, 2017.
[6] NIST Derived Test Requirements for FIPS 140-2, Draft, January 4, 2011.
[7] NIST Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module
Validation Program, May 10, 2017.
[8] NIST Frequently Asked Questions for the Cryptographic Module Validation
Program, October 28, 2016.
6
1.4 Change History
Change history is recorded in Table 1.
Table 1: Change History
Revision Date Author Description
0.1 2020/12/22 R.T. Initial revision.
Created based on the Security Policy for SB FIPS
Module 6.3.0.
0.2 2021/03/15 R.T. Updated platform list. Added hashes for entropy
libraries.
0.3 2021/04/16 R.T. Addressed comments from validation lab.
0.4 2021/05/17 R.T. Added CAVP certificate.
0.5 2021/07/15 R.T. Addressed additional comments from validation
lab.
0.6 2021/07/23 R.T. Added entropy estimates.
0.7 2021/10/28 R.T. Updated hash values for SB API library.
0.8 2022/04/01 R.T. Updated per comments from CMVP.
0.9 2022/05/25 R.T. Updated per comments from lab.
0.10 2022/06/15 R.T. Updated per second round comments from
CMVP.
0.11 2022/06/29 R.T. Updated per third round comments from CMVP.
0.12 2022/07/06 R.T. Addressed fourth round comments from CMVP.
0.13 2022/07/12 R.T. Addressed fifth round comments from CMVP.
7
2 Cryptographic Module Specification
SB FIPS Module is a multiple-chip standalone software cryptographic module in the
form of an object that operates with the following components:
• Commercially available general-purpose computer hardware.
• Commercially available Operating System (OS) that runs on the computer
hardware.
Table 2: level of validation
FIPS 140-2 Section Title Validation
Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles, Services, and Authentication 1
Finite State Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
Electromagnetic Interference / Electromagnetic
Compatibility
1
Self-Tests 1
Design Assurance 1
Mitigation of Other Attacks 1
2.1 Physical Specifications
The tested platforms consist of the following devices:
1. CPU (Microprocessor)
2. Memory
(a) Working memory is located on the RAM containing the following
spaces:
i. Input/output buffer
ii. Plaintext/ciphertext buffer
iii. Control buffer
Key storage is not deployed in this module.
(b) Program memory is also located on RAM.
3. Hard Disk (or disks)
4. Display Controller, including Touch Screen Controller
5. Keyboard Interface
6. Mouse Interface, including Trackball Interface
7. Audio Controller
8. Network Interface
9. Serial Interface
8
10. Parallel Interface
11. USB Interface
12. Power Supply
The configuration of this component is illustrated in Figure 1.
Figure 1: Cryptographic Module Hardware Block Diagram
: Physical Cryptographic Boundary
: Flow of data, control input, and status output
: Flow of control input : Flow of status output
Display
Terminal
USB
Interface
Keyboard
Mouse
External
Source of
Power
Hard Disk
Drive
Display
Controller
Keyboard
Interface
Mouse
Interface
Power
Supply
System Bus
CPU Memory
Network
Interface
Serial
Interface
USB Port
Network Serial
Port
Speaker/M
icrophone
Audio
Controller
Parallel
Interface
Parallel
Port
9
2.2 Computer Hardware and OS
The combinations of computer hardware and OS include the following representative
platforms.
1. Android 9 on Google Pixel 3 smart phone, Qualcomm Snapdragon 845 64-bit
ARMv8 processor
2. Android 9 on Google Pixel 3 smart phone, Qualcomm Snapdragon 845 64-bit
ARMv8 processor (32-bit ARMv7 instructions)
3. iOS 12.4.7 on Apple iPad mini 2, Apple A7 64-bit ARMv8 processor
4. Mac OS 10.15. on Apple Mac Book Pro late 2012 laptop computer, Intel Core i7
64-bit x86 processor
5. Windows 10 Pro on Lenovo P15 laptop computer, Intel Core i7 64-bit x86
processor
6. Windows Server 2019 on Lenovo SR630, Intel Xeon Silver 64-bit x86 processor
(virtual machine running on VMware ESX 6)
7. CentOS 7.0 on Lenovo SR630, Intel Xeon Silver 64-bit x86 processor (virtual
machine running on VMware ESX 6)
8. Ubuntu Linux 18.04 on Lenovo SR630, Intel Xeon Silver 64-bit x86 processor
(virtual machine running on VMware ESX 6)
9. QNX SDP 7.1 on NXP i.MX8 QuadXPlus Multisensory Enablement Kit ,
Cortex-A35 ARMv8 processor
10. QNX SDP 7.1 on Xilinx Zynq UltraScale+ MPSoC ZCU102 Eval. Kit, Cortex-
A53 64-bit ARMv8 processor
11. QNX SDP 7.1 on Supermicro A2SDi-4C-HLN4F-O server motherboard, Intel
Atom 64-bit x86 processor.
For the platforms listed above, SB FIPS Module is tested supporting NEON instructions
on ARMv7 and ARMv8 processor, supporting Crypto Extensions instructions on ARMv8
processor, and supporting AES-NI instructions on 64-bit x86 processor. It has also been
tested that when these instruction sets are missing or turned off, SB FIPS Module still
works.
SB FIPS Module is also suitable for any platforms of any manufactures with compatible
processors and equivalent system configurations, and compatible OS versions. For
example, an identical SB FIPS Module can be used on any compatible QNX for 64-bit
x86 processors, or Android for ARMv8 processors. SB FIPS Module will run on such
platforms and OS versions while maintaining its compliance to the FIPS 140-2 Level 1
requirements.
Additionally, the CMVP makes no statement as to the correct operation of the module or
the security strengths of the generated keys when ported to an operational environment
which is not listed on the validation certificate.
10
2.3 Software Specifications
SB FIPS Module is manufactured by BlackBerry Limited., providing services to the C
computer language users in object format.
The interface into SB FIPS Module is via Application Programmer’s Interface (SB API)
function calls. These function calls provide the interface to the cryptographic services, for
which the parameters and return codes provide the control input and status output (see
Figure 2).
Figure 2: Cryptographic Module Software Block Diagram
: Cryptographic Boundary
: Data flows
3 Cryptographic Module Ports and Interfaces
The physical and logical interfaces are summarized in Table 3.
Table 3: Logical and Physical Interfaces
I/O Logical Interface Physical Interface
Data Input API Keyboard, Mouse, USB ports,
Serial, and Ethernet port
Data Output API USB ports, Serial ports and
Ethernet port
Control Input API Keyboard and Mouse
Status Output API return code and
state returned by
Display
Operating System
Application Program
SB FIPS Module
Module Interface (API)
11
sbg_FIPS140GetState()
Power Input OS API to load the
module (library)
The Power Supply is the power interface.
Maintenance Not supported Not supported
The APIs logically separate data input from control input, and data output and status output.
12
4 Roles, Services, and Authentication
4.1 Roles and Services
SB FIPS Module supports Crypto Officer and User Roles (see Table 4). These roles are
enforced by this Security Policy.
Table 4: Roles and Services
Service Roles Key/CSP Permission
Installation, etc.
Installation Crypto
Officer/User
None execute
Self-tests Crypto
Officer/User
All Keys/CSPs listed in Table 6, with
the exception of ephemeral key pair
generation.
execute
Show status Crypto
Officer/User
None execute
Symmetric Ciphers (AES and Triple-DES)
Key generation User AES Key, Triple-DES key read/write/execute
Key input User AES Key, Triple-DES key read/write/execute
Encrypt User AES Key, Triple-DES key read/write/execute
Decrypt User AES Key, Triple-DES key read/write/execute
Key zeroization User AES Key, Triple-DES key read/write/execute
Hash Algorithms and Message Authentication (SHA, HMAC)
Hashing User None read/write/execute
Message Authentication User HMAC Key read/write/execute
Seed from system (ENT (NP))
Request User None read/write/execute
Random Number Generation (DRBG)
Instantiation User Entropy input, V, Key or C read/write/execute
Seeding User Entropy input, V, Key or C read/write/execute
Request User Entropy input, V, Key or C read/write/execute
CSP/Key zeroization User Entropy input, V, Key or C read/write/execute
Digital Signature (DSA, ECDSA, RSA)
Key pair generation User Key pair read/write/execute
Key pair input User Key pair read/write/execute
Sign User Private Key read/write/execute
Verify User Public Key
Key zeroization User Key pair read/write/execute
Key Establishment (KAS-FFC, KAS-ECC, RSA, AES-KW)
Key pair generation User Key pair read/write/execute
Key pair input User Key pair read/write/execute
Shared secret generation (KAS-
FFC-SSC and KAS-ECC-SSC)
User Public Key and Private Key, secret
read/write/execute
Wrap and Unwrap (RSADP) User RSA Public Key and RSA Private Key read/write/execute
Wrap and Unwrap (KTS-RSA) User RSA Public Key and RSA Private Key read/write/execute
Wrap and Unwrap (KTS-AES) User AES Key read/write/execute
Key zeroization User Key pair read/write/execute
SB FIPS Module does not support multiple concurrent operators.
SB FIPS Module supports many cryptographic algorithms. The set of cryptographic
algorithms supported by SB FIPS Module is given in Table 5. The algorithms test
certificate is A1303 (https://csrc.nist.gov/projects/cryptographic-algorithm-validation-
program/details?validation=33912).
13
Table 5: Supported Algorithms and Standards
FIPS Approved Algorithms
Algorithm CAVP Certificate
Block Ciphers 3-Key Triple-DES (ECB, CBC, CFB64, OFB64) [SP 800-67rev2] Cert# A1303
AES (ECB, CBC, CFB8, CFB128, OFB128, CTR) [FIPS 197] Cert# A1303
Block Cipher
Modes
CMAC [NIST SP 800-38B] Cert# A1303
CCM [NIST SP 800-38C] Cert# A1303
GCM [NIST SP 800-38D]1
Cert# A1303
XTS-AES [NIST SP 800-38E]23
Cert# A1303
KW [NIST SP 800-38F] Cert# A1303
Hash Functions SHA-1 [FIPS 180-4]456
Cert# A1303
SHA-224 [FIPS 180-4] Cert# A1303
SHA-256 [FIPS 180-4] Cert# A1303
SHA-384 [FIPS 180-4] Cert# A1303
SHA-512 [FIPS 180-4] Cert# A1303
SHA-512/224 [FIPS 180-4] Cert# A1303
SHA-512/256 [FIPS 180-4] Cert# A1303
SHA3-224 [FIPS 202] Cert# A1303
SHA3-256 [FIPS 202] Cert# A13027
, A1303
SHA3-384 [FIPS 202] Cert# A1303
SHA3-512 [FIPS 202] Cert# A1303
Extended-Output
Functions
SHAKE128 [FIPS 202] Cert# A1303
SHAKE256 [FIPS 202] Cert# A1303
Message HMAC-SHA-1 [FIPS 198-1]8
Cert# A1303
1
IV is generated according to scenario 2 in IG A.5, internally by DRBG with length >= 96 bits
2
XTS-AES uses two keys, and the module checks explicitly that Key_1  Key_2, regardless of how Key_1 and Key_2 are
obtained.
3
The XTS-AES mode was designed for the cryptographic protection of data on storage devices that use fixed length data units.
It was not designed for other purposes, such as the encryption of data in transit.
4
SHA-1 may only be used for digital signature generation where specifically allowed by NIST protocol-specific guidance. For all
other applications, SHA-1 is disallowed for digital signature generation.
5
When used for digital signature verification, SHA-1 is allowed for legacy use.
6
For non-digital-signature applications, the use of SHA-1 is acceptable for applications that do not require collision resistance.
7
Cert# A1302 is for the SHA-3 implementation used as the conditioning component of the Entropy Source
8 HMAC-SHA-1 shall have a key size of at least 112 bits.
14
Authentication HMAC-SHA-224 [FIPS 198-1] Cert# A1303
HMAC-SHA-256 [FIPS 198-1] Cert# A1303
HMAC-SHA-384 [FIPS 198-1] Cert# A1303
HMAC-SHA-512 [FIPS 198-1] Cert# A1303
HMAC-SHA-512/224 [FIPS 198-1] Cert# A1303
HMAC-SHA-512/256 [FIPS 198-1] Cert# A1303
HMAC-SHA3-224 [FIPS 198-1] Cert# A1303
HMAC-SHA3-256 [FIPS 198-1] Cert# A1303
HMAC-SHA3-384 [FIPS 198-1] Cert# A1303
HMAC-SHA3-512 [FIPS 198-1] Cert# A1303
Random Number
Generators
Hash_DRBG [NIST SP 800-90A] Cert# A1303
HMAC_DRBG [NIST SP 800-90A] Cert# A1303
CTR_DRBG [NIST SP 800-90A] Cert# A1303
Digital Signature9 DSA (KeyGen, PQGGen, SigGen, SigVer) [FIPS 186-4] Security strength 112-128
bits10 Cert# A1303
ECDSA (KeyGen, KeyVer, SigGen, SigVer) [FIPS 186-4, ANSI X9.62] Security
strength 112-256 bits
Cert# A1303
RSA PKCS1 v1.5 (KeyGen, SigGen, SigVer, DP) [FIPS 186-4, PKCS #1 v2.1]
Modulus size 1024, 2048 and 3072 bits only11 Cert# A1303
RSA PSS (SigGen, SigVer) [FIPS 186-4, PKCS #1 v2.1] Cert# A1303
Key Establishment KAS-FFC-SSC [NIST SP 800-56A] (Domain Parameter Generation Methods: FB,
FC) Security strength 112 bits
Cert# A1303
KAS-ECC-SSC [NIST SP 800-56A] (curves K-233, K-283, K-409, K-571, P-224,
P-256, P-384, P-521) Security strength 112-256 bits
Cert# A1303
KTS-RSA [NIST SP 800-56B]12
Security strength 112-150 bits (used in key
wrapping)
Cert# A1303
KTS (AES-KW) Security strength 128-256 bits (used in key wrapping) Cert# A1303
KDA-OneStep [NIST SP 800-56A] Cert# A1303
Cryptographic Key
Generation (CKG)
Cryptographic Key Generation, (SP 800-133) is using output from DRBG for
asymmetric and symmetric key generation, no post-processing. N/A
Components CVL-RSADP [NIST SP 800-56B] (used in key wrapping) Cert# A1303
CVL-ANSI X9.63-2001 KDF [NIST SP 800-135] (used in KAS-ECC key
agreement)
Cert# A1303
Entropy Source Entropy Source, Non-Physical (SP 800-90B) (ENT (NP)) N/A
FIPS Allowed Algorithms
Algorithm Status
Block Cipher 2-Key Triple-DES (ECB, CBC, CFB64, OFB64) decryption [SP800-67rev2] Allowed
FIPS Disallowed Algorithms
Algorithm Status
Block Ciphers 2-Key Triple-DES (ECB, CBC, CFB64, OFB64) encryption [SP800-67rev2] Disallowed
9
Digital signature generation using SHA-1 as its underlying hash function is disallowed.
10
For DSA signature generation, only the primes p and q pairs with bit lengths (2048, 224), (2048, 256) and (3072, 256) can be
used in the approved mode for signature generation.
11
Modulus 1024 in RSA signature verification (Legacy SigVer) only.
12 Only cryptographic keys may be wrapped using KTS-RSA.
15
DES (ECB, CBC, CFB64, OFB64) Disallowed
DESX (ECB, CBC, CFB64, OFB64) Disallowed
AES EAX [ANSI C12.22] Disallowed
ARC2 (ECB, CBC, CFB64, OFB64) [RFC 2268] Disallowed
Block Cipher
Mode
AES (CCM*) [ZigBee 1.0.x] Disallowed
Stream Cipher ARC4 Disallowed
Hash Functions MD5 [RFC 1321] Disallowed
MD4 [RFC 1320] Disallowed
MD2 [RFC 1115] Disallowed
AES MMO [ZigBee 1.0.x] Disallowed
Message
Authentication
HMAC-MD5 [RFC 2104] Disallowed
AES-XCBC-MAC [RFC 3566] Disallowed
Random Number
Generators
ANSI X9.62 RNG [ANSI X9.62] Disallowed
ANSI X9.31 RNG [ANSI X9.31] Disallowed
Digital Signature DSA [FIPS 186-4] Security strength 56-111 Disallowed
ECDSA [FIPS 186-4, ANSI X9.62] Security strength 80-111 Disallowed
RSA PKCS1 v1.5 Modulus sizes other than 1024, 2048 and 3072 Disallowed
RSA PKCS1 v1.5 [FIPS 186-4, PKCS #1 v2.1] Security strength 56-111 Disallowed
ECNR [IEEE 1363] Disallowed
ECQV Disallowed
Key Establishment KAS-FFC [NIST SP 800-56A] Security strength 56-111 bits Disallowed
KAS-ECC [NIST SP 800-56A] Security strength 80-111 Disallowed
ECPVS [ANSI X9.92] Disallowed
ECSPEKE [IEEE 1363.2] Disallowed
RSA KEM [ANSI X9.44] Disallowed
KTS-RSA [NIST SP 800-56B] Security strength 56-111 bits (used in key
wrapping)
Disallowed
Component ECIES [ANSI X9.63] Disallowed
Table 6 summarizes the keys and CSPs used in the FIPS mode.
Table 6: Key and CSP, Key Size, Security Strength, and Access
Algorithm Keys and CSPs Key Size Strength Access
AES key 128-256 bits 128-256 bits Create, Read, Use
AES-GCM IV >= 96 bits >=96 bits Create, Use
Triple-DES13
key 168 bits 112 bits Create, Read, Use
HMAC key 160-512 bits 128-256 bits Use
DRBG Seed seed 112-256 bits 112-256 bits Use
DRBG(CTR_AES)
V and AES Key, entropy
input
112-256 bits 112-256 bits Use
DRBG(HASH) V and C, entropy input 112-256 bits 112-256 bits Use
13 Triple-DES is disallowed after 2023.
16
DRBG(HMAC) V and Key, entropy input 112-256 bits 112-256 bits Use
DSA key pair
L=2048, 3072,
N=224, 256 bits
112-128 bits Create, Read, Use
ECDSA key pair f=224-521 bits 112-256 bits Create, Read, Use
RSA key pair k=2048-3072 bits 112-128 bits Create, Read, Use
RSADP key pair k=2048 bits 112 bits Create, Read, Use
KAS-FFC static/ephemeral key pair
L=2048,
N=224, 256 bits
112 bits Create, Read, Use
KAS-ECC static/ephemeral key pair f=224-521 bits 112-256 bits Create, Read, Use
RSA Key wrapping key pair
k=2048, 3072,
4096 bits
112-150 bits Create, Read, Use
The module does not enforce FIPS 140-2 compliance. It is up to the user to select the
algorithms and cryptographic strength that complies with this Security Policy.
4.2 Operator Authentication
SB FIPS Module does not deploy authentication mechanism. The roles of Crypto Officer
and User are implicitly selected by the operator.
17
5 Finite State Model
The Finite State model contains the following states:
• Power Off
• Power On
• Self-Test
• Idle
• Crypto Officer/User/Key Entry
• Error
The following is the important features of the state transition:
1. When the module is installed by the Crypto Officer, the module is in the Power Off
state.
2. When the module is loaded on the memory, turning to the Power On state. Then, it
transitions to the Self-Test state automatically, running the Power-up Tests. While in
the Self-Test state, all data output via the data output interface is prohibited. On
success, the module enters Idle state; on failure, the module enters the Error state and
the module is disabled. From the Error state the Crypto Officer may need to re-install
to attempt correction.
3. From the Idle state (which is only entered if self-tests have succeeded), the module can
transition to the Crypto Officer, User or Key/CSP Entry state when an API function is
called.
4. When the API function has completed successfully, the state transitions back to Idle.
5. If the Conditional Test (Continuous RNG Test or Pair-wise Consistency Test) fails, the
state transitions to Error and the module is disabled.
6. When On-demand Self-test is executed, the module enters the Self-Test state. On
success, the module enters Idle; on failure, the module enters Error and the module is
disabled.
18
6 Physical Security
Physical security is not applicable to this software module at Level 1 Security.
19
7 Operational Environment
This module is designed for commercially available general-purpose computer operating
systems such as Windows, Android or QNX. These operating systems provide modifiable
environment.
This module is to be run in single user operational environment, where each user
application runs in virtually separated independent space. Note that modern Operating
Systems such as Windows, Android or QNX provide such operational environment, that
no other process can access private and secret keys, intermediate key generation values,
and other CSPs, while the cryptographic process is in use.
7.1 Modes of Operations
This module supports two modes of operations: Approved and Non-Approved. The
module operates in Approved mode after the power-up self-tests have completed
successfully and whenever an approved or allowed algorithm is executed (see Table 5). It
will switch to Non-Approved mode upon execution of a disallowed algorithm, and back
to Approved mode when an approved or allowed algorithm is executed.
20
8 Cryptographic Key Management
SB FIPS Module provides the underlying functions to support FIPS 140-2 Level 1 key
management. The user will select FIPS Approved algorithms and will handle keys with
appropriate care to build up a system that complies with FIPS 140-2. It is the Crypto
Officer and User’s responsibility to select FIPS 140-2 validated algorithms (see Table 5).
Table 7 summarizes the management of the keys and CSPs used in the FIPS mode.
Table 7: Cryptographic Key Management
Algorithm Keys and CSPs Generation/Input Output Storage Zeroization
AES key
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
AES-GCM IV
IV is generated
according to scenario
2 in IG A.5
API parameter
Volatile
Memory
API call
Power cycle
Triple-DES key
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
HMAC key
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
DRBG seed Seed
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
DRBG(CTR)
V and Key, entropy
input
Entropy: generated
by ENT (NP). V and
Key: internally
generated.
API parameter
Volatile
Memory
API call
Power cycle
DRBG(HASH) V and C, entropy input
Entropy: generated
by ENT (NP). V and
C: internally
generated.
API parameter
Volatile
Memory
API call
Power cycle
DRBG(HMAC)
V and Key, entropy
input
Entropy: generated
by ENT (NP). V and
Key: generated.
API parameter
Volatile
Memory
API call
Power cycle
DSA key pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
ECDSA key pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
RSA key pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
RSADP key pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
KAS-FFC
static/ephemeral key
pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
KAS-ECC
static/ephemeral key
pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
KAS-FFC-SSC Shared secret Z Internally Generated API parameter
Volatile
Memory
API call
Power cycle
KAS-ECC-SSC Shared secret Z Internally Generated API parameter
Volatile
Memory
API call
Power cycle
RSA Key wrapping key pair
Internally Generated
or Input
API parameter
Volatile
Memory
API call
Power cycle
Note:
Keys must be imported or exported from the cryptographic boundary in encrypted form
using a FIPS Approved algorithm.
To comply with FIPS 140-2, AES-GCM must generate IV internally with Approved
DRBG. DRBG seed also must be generated internally. The minimum 96-bit IV length is
enforced by the module.
21
8.1 Key Generation
SB FIPS Module provides FIPS 140-2 compliant key generation (CKG). The underlying
random number generation uses a FIPS Approved method, a DRBG (Hash, HMAC or
Counter).
The module also supports ANSI X9.62 and ANSI X9.31 RNGs, however, the use of
ANSI X9.62/ANSI X9.31 RNG is non-approved for key generation. No keys generated
using ANSI X9.62/ANSI X9.31 RNG can be used to protect sensitive data in the
Approved mode.
8.2 Key Establishment
SB FIPS Module provides the following FIPS Approved or allowed key establishment
techniques [5]:
1. KAS-FFC (key agreement; key establishment methodology provides 112 bits of
encryption strength)
2. KAS-ECC (key agreement; key establishment methodology provides between
112 and 256 bits of encryption strength)
3. RSA (key wrapping; key establishment methodology provides between 112 and
150 bits of encryption strength)
4. KTS (key wrapping using AES-KW; key establishment methodology provides
between 128 and 256 bits of encryption strength)
It is the responsibility of the application to ensure that the appropriate key establishment
techniques are applied to the appropriate keys.
8.3 Key Entry and Output
Keys must be imported or exported from the cryptographic boundary in encrypted form
using a FIPS Approved algorithm.
8.4 Key Storage
SB FIPS Module is a low-level cryptographic toolkit, and as such does not provide key
storage.
8.5 Zeroization of Keys and CSPs
SB FIPS Module provides zeroizable interfaces which implement zeroization functions
(see Table 4). Zeroization of keys and CSPs must be performed by calling the
corresponding destroy functions of the objects when no longer needed.
Internally, SB FIPS Module zeroize all intermediate keys and CSPs upon each function
returns.
22
9 Self-Tests
9.1 Power-up Tests
9.1.1 Tests upon Power-up
Self-tests are initiated automatically by the module at start-up without any intervention
from an application. It does not involve any inputs by the operator. The following tests
are applied:
1. Software Integrity Test:
The software integrity test deploys HMAC SHA-256 to verify the integrity of
the module.
2. Known Answer Tests (KATs):
The following KATs are performed:
AES-ECB Encrypt KAT,
AES-ECB Decrypt KAT,
AES-GCM Encrypt KAT,
AES-GCM Decrypt KAT,
AES-KW Wrapping KAT,
AES-KW Unwrapping KAT,
DRBG-CTR KAT,
DRBG-HASH KAT,
DRBG-HMAC KAT,
DSA PCT,
ECDSA PCT,
KAS-FFC-SSC KAT,
KAS-ECC-SSC KAT,
KDA-onestep (KDA-56C) KAT,
HMAC SHA-1 KAT,
HMAC SHA-224 KAT,
HMAC SHA-256 KAT,
HMAC SHA-384 KAT,
HMAC SHA-512 KAT,
HMAC SHA-512/224 KAT,
HMAC SHA-512/256 KAT,
HMAC SHA3-224 KAT,
HMAC SHA3-256 KAT,
HMAC SHA3-384 KAT,
HMAC SHA3-512 KAT,
ANS X9.63-2001 KDF KAT,
RSA Signature Generation KAT,
RSA Signature Verification KAT,
RSADP Encrypt KAT,
RSADP Decrypt KAT,
Triple-DES-ECB Encrypt KAT, and
Triple-DES-ECB Decrypt KAT.
Pairwise-consistency test (PCT) is used for DSA, RSA and ECDSA. ECMQV
tests are covered by the underlying arithmetic tests via ECDSA PCT and ANSI
X9.63-2001 KDF KAT. Each SHA KAT is considered covered by the
corresponding HMAC SHA KAT. SP 800-56A Primitive “Z” Computation
23
KATs are covered by KAS-FFC KAT and KAS-ECC KAT. The SP 800-56B
Self-Tests per IG D.4 are covered by RSADP Encrypt KAT and RSADP
Decrypt KAT.
9.1.2 On-Demand Self-Tests
On-demand self tests may be invoked by the Cryptographic Officer or User by invoking a
function, which is described in the Crypto Officer And User Guide in Appendix A.
9.2 Conditional Tests
Continuous RNG Tests for ENT (NP),
Adaptive Proportion Tests for ENT (NP),
Continuous RNG Tests for DRBG-CTR,
Continuous RNG Tests for DRBG-HASH,
Continuous RNG Tests for DRBG-HMAC,
Pair-wise Consistency Tests for FFC key generation,
Pair-wise Consistency Tests for ECC key generation, and
Pair-wise Consistency Tests for RSA key generation.
9.3 Critical Function Tests
For DRBG (CTR, HASH, and HMAC), the module implements the following critical
function tests:
• SP 800-90A DRBG Instantiate Health Test
• SP 800-90A DRBG Generate Health Test
• SP 800-90A DRBG Reseed Health Test
• SP 800-90A DRBG Uninstantiate Health Test
9.4 Failure of Self-Tests
Failure of the Self-tests places the cryptographic module in the Error state, wherein no
cryptographic operations can be performed. If any Self-test fails, the cryptographic
module will output an error code, and goes into the Error state.
24
10 Design Assurance
10.1 Configuration Management
A configuration management system for the cryptographic module is employed and has
been described in a document to the testing laboratory. It uses Subversion (SVN) to track
the configurations.
10.2 Delivery and Operation
Please refer to Section A.1 of Crypto Officer And User Guide in Appendix A to review
the steps necessary for the secure installation and initialization of the cryptographic
module.
10.3 Development
Detailed design information and procedures have been described in documentation
submitted to the testing laboratory. The source code is fully annotated with comments,
and is also submitted to the testing laboratory.
10.4 Guidance Documents
Crypto Officer Guide And User Guide is provided in Appendix A. This appendix outlines
the operations for Crypto Officer and User to ensure the security of the module.
25
11 Mitigation of Other Attacks
SB FIPS Module implements mitigation of the following attacks:
1. Timing Attack on RSA
11.1 Timing Attack on RSA
When employing Montgomery computations, timing effects allow an attacker to tell
when the base of exponentiation is near the secret modulus. This leaks information
concerning the secret modulus.
In order to mitigate this attack, the following is executed: The bases of exponentiation are
randomized by a technique that requires no inversion to remove (unlike other blinding
methods e.g. BSAFE Crypto-C User Manual v 4.2).
Note that Remote Timing Attacks are practical:
http://crypto.stanford.edu/ dabo/papers/ssl-timing.pdf
26
12 Entropy Source
The entropy source accumulates 256 noise samples, each sample consisting of 64 bits,
into a 256 bit pool. Each noise sample is estimated to contain at least 1 bit of entropy, so
the pool contains 256 bits of entropy. The pool is used for at most 256 output bits before
another set of 256 noise samples are accumulated into the pool. Therefore, each output bit
of the entropy source contains 1 bit of entropy.
27
A Crypto Officer and User Guide
A.1 Installation
In order to carry out a secure installation of SB FIPS Module, the Crypto Officer must
follow the procedure described in this section.
A.1.1 Installing
The Crypto Officer is responsible for the installation of SB FIPS Module. Only the
Crypto Officer is allowed to install the product.
Place the object in an appropriate location on the computer hardware for your
development and runtime environments.
The entropy source tested is not part of the SB FIPS Module but included with the SB
API library. The SB API library must be linked with the application that uses the SB
FIPS Module. The Crypto Officer shall verify the SHA-256 digest of the static library
matches the values listed in Table 8.
Table 8: SHA-256 Digest of Library including Entropy Source
Platform
Library File
Name
SHA-256 Digest
Android 64-bit ARMv8 libhu.a
d6125b28ef3ead380141ab8f248a59f169de34313dfe9d440
532224b867ace8a
Android 32-bit ARMv7 libhu.a
d323f2710e961a5e42789930b39f16194f5b269a1c1e2985a
c743dd2b2caa114
iOS 64-bit x86 libhu.a
539d013368077338a53e910b26083ac8fcd4c1926d0529cdb
6bd3288f23e9d0e
MacOS 64-bit x86 libhu.a
7c2fcca6dd581cae7113a916894daa2bbc071718a5a1a59ae
e91899b77728589
Windows 64-bit x86 hu.lib
58a149c1f58cba66bd3f33ddda67472a728f9e329ee9a2969
9304e867d671047
Linux 64-bit x86 libhu.a
ed854bace6c704b69aab114da6d097d417defe3dee99f605b
e74ebb036ca2fa0
QNX SDP 7.1 64-bit ARMv8 libhu.a
727aaa6e6b58f34d2b3b6558ad0fb07185f49dd2264a812ed
ed278cbab89cc63
QNX SDP 7.1 64-bit x86 libhu.a
0481ee7a24a47bc5e0138bf8332271c99b941d110e29c5914
254abed27c7225f
A.1.2 Uninstalling
Remove the object from the computer hardware.
A.2 Commands
A.2.1 Load
SB FIPS Module typically is a shared library. Depending on the platform, the module can
be loaded on the memory automatically when an executable is run or calling a loader
system function by an executable. Once the module is loaded, a series of self-tests will be
automatically started without any intervention from an application. These tests examine
the integrity of the object, and the correct operation of the cryptographic algorithms. If
these tests are successful, a value of SB_SUCCESS will be returned and the module will
be enabled.
28
A.2.2 Unload
When the executable which loaded SB FIPS Module finishes running, the module will be
unloaded from the memory.
A.2.3 Self-Tests
sbg_FIPS140RunTest()
This user callable function runs a series of self-tests, and return SB_SUCCESS if the tests
are successful. These tests examine the integrity of the object, and the correct operation
of the cryptographic algorithms. If these tests fail, the module will be disabled. Section
A.3 of this document describes how to recover from the disabled state.
A.2.4 Show Status/Mode
sbg_FIPS140GetState()
This function will return the current state of the module.
A.3 When Module is Disabled
When SB FIPS Module becomes disabled, uninstall the module and re-install it. If the
module is loaded successfully by this re-installation, the recovery is successful. If this
recovery attempt fails, it indicates a fatal error. Please contact Certicom Support
immediately.
A.4 Operation Limitation for FIPS approved mode
For 3-key Triple-DES, NIST SP 800-67rev1 requires a limit that the same Triple-DES
key shall not be used for more than 228
encryptions.