Security Builder® FIPS Java Module
Version 2.9 and 2.9.2
FIPS 140-2 Non-Proprietary
Security Policy
Certicom Corp.
November 25th, 2022
2
Copyright © 2005-2018 Certicom Corp.
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 Certicom Corp. 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
Certicom Corp. Such consent must arise from a separate license agreement from
Certicom 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 Certicom Corp. 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 NOTES ........................................................................................................ 7
2 CRYPTOGRAPHIC MODULE SPECIFICATION ........................................................... 11
2.1 PHYSICAL SPECIFICATIONS ......................................................................................... 11
2.2 COMPUTER HARDWARE, OS AND JVM ....................................................................... 11
2.3 SOFTWARE SPECIFICATIONS ....................................................................................... 13
3 CRYPTOGRAPHIC MODULE PORTS AND INTERFACES ............................................. 15
4 ROLES, SERVICES, AND AUTHENTICATION ............................................................. 16
4.1 ROLES AND SERVICES ............................................................................................... 16
4.2 SECURITY FUNCTIONS ............................................................................................... 18
4.3 OPERATOR AUTHENTICATION .................................................................................... 21
5 FINITE STATE MODEL ............................................................................................ 21
6 PHYSICAL SECURITY .............................................................................................. 22
7 OPERATIONAL ENVIRONMENT ............................................................................. 23
8 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................... 24
8.1 KEY GENERATION .................................................................................................... 24
8.2 KEY ESTABLISHMENT ................................................................................................ 24
8.3 KEY ENTRY AND OUTPUT .......................................................................................... 24
8.4 KEY STORAGE ......................................................................................................... 24
8.5 ZEROIZATION OF KEYS .............................................................................................. 25
9 SELF-TESTS ............................................................................................................ 26
9.1 POWER-UP TESTS .................................................................................................... 26
9.1.1 Tests upon Power-up .............................................................................. 26
9.1.2 On-Demand Self-Tests ............................................................................ 26
9.2 CONDITIONAL TESTS ................................................................................................ 26
9.3 FAILURE OF SELF-TESTS ............................................................................................ 26
10 DESIGN ASSURANCE ............................................................................................. 27
10.1 CONFIGURATION MANAGEMENT ................................................................................ 27
10.2 DELIVERY AND OPERATION ........................................................................................ 27
10.3 DEVELOPMENT ....................................................................................................... 27
10.4 GUIDANCE DOCUMENTS ........................................................................................... 27
11 MITIGATION OF OTHER ATTACKS .......................................................................... 28
11.1 TIMING ATTACK ON RSA .......................................................................................... 28
11.2 ATTACK ON BIASED PRIVATE KEY OF DSA .................................................................... 28
4
A CRYPTO OFFICER AND USER GUIDE ....................................................................... 29
A.1 INSTALLATION ......................................................................................................... 29
A.1.1 Installing ................................................................................................ 29
A.1.2 Uninstalling ............................................................................................ 29
A.2 COMMANDS ........................................................................................................... 29
A.2.1 Initialization ........................................................................................... 29
A.2.2 De-Initialization ...................................................................................... 29
A.2.3 Self-Tests ................................................................................................ 29
A.2.4 Show Status ............................................................................................ 29
A.3 WHEN MODULE IS DISABLED ..................................................................................... 30
A.4 FIPS MODE ........................................................................................................... 30
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 Java Module Version 2.9 and 2.9.2 (SB
FIPS Java Module). SB FIPS Java Module is a cryptographic toolkit for Java 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 Java Module must operate. These security
rules are derived from the requirements of FIPS 140-2 [1], and related documents ([6],
[7], [8]).
The FIPS 140-2 requirements that the SB FIPS Java Module have been validated to are
summarized in Table 1.
Table 1: FIPS 140-2 Requirements
Requirement
Section
Section Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 1
4 Finite State Model 1
5 Physical Security N/A
6 Operational Environment 1
7 Cryptographic Key Management 1
8 EMI/EMC 1
9 Self-Tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks 1
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 Java Module’s conformance to FIPS 140-2 Level 1 Security
Requirements.
3. To provide users with how to configure and operate the cryptographic module in
order to comply with FIPS 140-2.
1.3 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, July 26, 2011.
[3] NIST Security Requirements For Cryptographic Modules, Annex B: Approved
Protection Profiles for FIPS PUB 140-2, Draft, August 12, 2012.
[4] NIST Security Requirements For Cryptographic Modules, Annex C: Approved
Random Number Generators for FIPS PUB 140-2, Draft, July 26, 2011.
6
[5] NIST Security Requirements For Cryptographic Modules, Annex D: Approved Key
Establishment Techniques for FIPS PUB 140-2, Draft, July 26, 2011.
[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, June 15, 2011.
[8] NIST Frequently Asked Questions for the Cryptographic Module Validation
Program, December 4, 2007.
7
1.4 Change Notes
Change history is recorded in Table 2.
Table 2: Change History
Date Author Description
2010/08/03 A.Y. Moved to Subversion
Algorithm certificate numbers are added.
2010/08/13 A.Y. Updated IP notices
2011/01/25 R.W. Editorial corrections
2011/01/25 R.W. Updated copyright year
2011/08/15 R.W. Editorial modifications
2011/09/07 A.Y. Response to 2nd round comments
2012/06/01 A.Y. Editorial fix for clarification based on the comments on
rebranded Security Policy
2012/06/14 A.Y. Added Version 2.8.7, which contains an improvement on
concurrent access to RNG context
2015/05/19 R.T. Modified for version 2.8.8.
2015/06/16 R.T. Modified Appendix A. Integrity and other tests are run
automatically.
2015/07/15 R.T. Added algorithm certificate numbers for version 2.8.8.
2015/07/29 R.T. Incorporated comments from EWA.
2015/11/10 R.T. Updated per comments from CMVP.
2015/11/11 R.T. Added guidance for GCM per comment from CMVP.
2015/11/12 R.T. Minor updates after internal review.
2015/11/25 R.T. Updated per second round of comments from CMVP.
2015/12/16 R.T. Updated per additional comments from CMVP.
2016/01/11 R.T. NIST SP 800-131A transitions.
2016/01/15 R.T. Updated per comments from lab.
2016/01/18 R.T. More comments from lab.
2016/06/02 R.T. Added version 2.9.
2016/06/13 R.T. Added CAVP certificate numbers for version 2.9.
2016/06/14 R.T. Updated per comments from lab.
2016/06/14 R.T. More comments from lab.
2016/08/31 R.T. Updated per comments from CMVP.
2016/09/21 R.T. Addressed further comments from CMVP.
2016/10/03 R.T. Addressed a third round of comments from CMVP.
2017/01/23 R.T. Added Android platforms.
2017/06/13 R.T. Removed other module versions.
2017/06/28 R.T. Addressed comment from CMVP.
2017/07/12 R.T. Addressed comments from CMVP.
2017/07/20 R.T. Addressed comments from CMVP.
2018/08/20 R.T. Added version 2.9.2.
2018/08/24 R.T. Addressed comments from EWA.
2018/11/30 R.T. Addressed comments from CMVP.
2019/02/20 R.T. Updated per comments from EWA.
2019/02/25 R.T. Updated per comments from CMVP.
The following were placed here by RCS upon check-in.
Revision 1.50 2010/04/21 13:10:23 ayamada
Editorial corrections.
Revision 1.49 2010/04/20 15:45:06 ayamada
Updated with the latest information.
8
Revision 1.48 2010/01/08 17:53:52 ayamada
Added key agreement algorithms for SB FIPS Module Version 2.8.
Revision 1.47 2010/01/07 20:04:25 rwilliam
Merged 2.2.1 details from development branch.
Revision 1.46 2008/09/15 14:00:42 ayamada
Revised based on the comments from CMVP.
Revision 1.45 2008/06/16 18:00:39 ayamada
1. Algorithm Certificate numbers are provided.
2. Updated references.
3. Editorial correction.
Revision 1.44 2008/05/09 19:45:52 rwilliam
Clarified runSelfTests
Revision 1.43 2008/05/09 15:29:34 ayamada
Correction on the date.
Revision 1.42 2008/05/09 15:29:05 ayamada
Fixed the description to correctly represent the behavior in Java.
Revision 1.41 2008/04/18 17:04:55 ayamada
Corrections on the supported algorithms.
Editorial corrections.
Revision 1.40 2008/04/18 13:28:40 ayamada
For SB FIPS Jave Module 2.2.
1. Updated the list of tested platforms.
2. The tested JRE version is now 1.6.
3. Added new algorithms: AES CMAC, AES GCM, DRBG.
4. Clarification on the operational environment.
Revision 1.39 2008/04/15 12:35:28 ayamada
Fixed a typo.
Revision 1.38 2008/04/11 22:09:50 ayamada
For Version 2.2.
New platform list and JRE list.
Includes new algorithms such as NIST SP 800-90 RNG.
Revision 1.37 2008/03/14 17:50:42 ayamada
The first draft for SB FIPS Java Module 2.2.
Revision 1.36 2008/01/24 15:25:36 ayamada
Updated from the 2.1 branch.
Revision 1.35.6.1 2007/08/29 19:04:22 ayamada
Updated to add Solaris 10 32-bit.
Revision 1.35 2006/12/08 14:17:26 ayamada
Date update.
Revision 1.34 2006/12/08 14:15:55 ayamada
Correction on the DSS certificate number.
Revision 1.33 2006/12/07 19:46:09 ayamada
Updated the date on the document.
Revision 1.32 2006/12/07 19:44:24 ayamada
Added FIPS Algorithm certificate numbers.
Revision 1.31 2006/11/03 17:45:58 ayamada
Added extra space on page 2.
Revision 1.30 2006/11/03 17:39:02 ayamada
Added patent statement.
Revision 1.29 2006/11/03 15:07:49 ayamada
Addition of some clarifications and reference update.
9
Revision 1.28 2006/11/02 19:58:52 ayamada
Simplified operational environment description.
Revision 1.27 2006/10/13 14:22:49 ayamada
Improved to have clearer statements.
Revision 1.26 2006/09/14 14:04:22 ayamada
Revised to add 2 platforms.
Windows OS is updated to XP.
Revision 1.25 2006/06/28 14:09:02 ayamada
A bit more editorial improvements.
Revision 1.24 2006/06/28 14:01:32 ayamada
Some editorial fixes.
Revision 1.23 2006/06/27 20:15:40 mmezheri
updated supported hardware, software diagram and algorithms table
Revision 1.22 2006/06/26 15:20:06 mmezheri
updated regarding gse-j 2.1
Revision 1.21 2006/06/05 21:52:41 mmezheri
new algorithms updating.Revision 1.20 2005/12/14 17:02:48 zlieber
Merged sbgsej_2_0 branch: -j root-of-sbgsej_2_0-branch -j sbgsej_2_0_9
Revision 1.11.2.2 2005/09/27 18:10:34 ayamada
Further revised the notes on the security of key establishment techniques.
Revision 1.19 2005/09/27 13:42:29 ayamada
Added notes on security levels of Diffie-Hellman, Elliptic Curve Diffie-Hellman, and ECMQV.
Revision 1.18 2005/09/21 20:01:27 ayamada
Added clarification on key size for the RSA key wrapping techniques.
Revision 1.17 2005/09/14 18:47:47 ayamada
Further clarified the status of DES in Table 3.
Revision 1.16 2005/09/14 17:20:11 ayamada
1. Fix on Table 3 to clarify the legacy status of DES.
2. FIPS Approved is corrected to FIPS allowed for key establishment techniques.
Revision 1.15 2005/04/22 13:19:47 ayamada
Further clarifications.
Revision 1.14 2005/03/31 17:46:50 ayamada
Editorial corrections.
Revision 1.13 2005/03/28 15:26:50 ayamada
Correction on the date.
Revision 1.12 2005/03/28 15:21:17 ayamada
The algorithm certificate numbers are obtained.
Some minor editorial corrections.
Revision 1.11 2005/02/18 18:53:36 ayamada
A few minor corrections.
Revision 1.10 2005/02/18 16:04:20 ayamada
More clarifications and editorial corrections.
Revision 1.9 2005/02/15 17:10:11 efung
Typo
Revision 1.8 2005/02/11 21:16:22 efung
Superscript the (R)
Revision 1.7 2005/02/10 23:00:19 efung
supertab isn’t actually being used (package seems to be superseded by
supertabular)
10
Revision 1.6 2005/02/10 19:08:35 ayamada
Further corrections.
Revision 1.5 2005/02/10 18:34:20 ayamada
Editorial corrections.
Revision 1.4 2005/02/04 18:35:07 ayamada
Completed the appendix.
Revision 1.3 2005/02/01 15:56:28 ayamada
Editorial corrections.
Revision 1.2 2005/01/28 14:54:00 ayamada
Revised for differences of Java from C.
Revision 1.1 2005/01/28 13:48:21 ayamada
Initial revision: copied from GSE-C 2.0.
11
2 Cryptographic Module Specification
SB FIPS Java Module is a multiple-chip standalone cryptographic module that operates
with the following components:
• A commercially available general-purpose computer hardware.
• A commercially available Operating System (OS) that runs on the computer
hardware.
• A commercially available Java Virtual Machine (JVM) that runs on the computer
hardware and OS.
2.1 Physical Specifications
The general-computer hardware component consists 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
5. Keyboard Interface
6. Mouse Interface
7. Network Interface
8. Serial Port
9. Parallel Port
10. Power Supply
The configuration of this component is illustrated in Figure 1.
2.2 Computer Hardware, OS and JVM
Versions 2.9 of SB FIPS Java Module has been tested on the following representative
combinations of computer hardware and OS:
1. CentOS Linux 7.0 64 bit x86 on a Dell PowerEdge 2950 running JRE 1.8.0 by Oracle
2. BlackBerry Priv with a Qualcomm 8992 Snapdragon processor, running Android OS
version 6.0.1
3. Ricoh MP C3004 with a NXP ARM Cortex-A9 processor, running Android OS API level
17
Versions 2.9.2 of SB FIPS Java Module has been tested on the following representative
combinations of computer hardware and OS:
1. Ubuntu Linux 16.04 on Dell PowerEdge R430 running JRE 1.8.0 by Oracle (virtual
12
machine running on VMware ESX 4.1.5)
2. Windows Server 2016 on Dell PowerEdge R430 running JRE 1.8.0 by Oracle (virtual
machine running on VMware ESX 6.5)
3. Red Hat Enterprise Linux 7 on Dell PowerEdge R430 running IBM Java 1.8
4. SUSE Linux Enterprise 11 on Dell PowerEdge R430 running JRE 1.8.0 by Oracle (virtual
machine running on VMware ESX 4.1.5)
5. BlackBerry Priv with a Qualcomm 8992 Snapdragon processor, running Android OS
version 6.0.1
6. Venturi K502 tablet with an ARMv8 processor running Android 8.1.2
The module will run on other Linux or Android Platforms while maintaining its compliance to the
FIPS 140-2 Level 1 requirements.
13
: Physical Cryptographic Boundary
: Flow of data, control input, and status output
: Flow of control input : Flow of status output
Figure 1: Cryptographic Module Hardware Block Diagram
2.3 Software Specifications
SB FIPS Java Module software is manufactured by Certicom Corp., providing services to
the Java computer language users in the form of a Java archive (JAR). The same binary is
Display
Terminal
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
Network Serial
Port
Parallel
Interface
Parallel
Port
14
used for all identified computer hardware and OS because the JVM underneath SB FIPS
Java Module will absorb the differences of the computer and hardware and OS.
The interface into SB FIPS Java Module is via Application Programmer’s Interface (API)
method calls. These method 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).
: Cryptographic Boundary
: Data flows
Figure 2: Cryptographic Module Software Block Diagram
Java Virtual Machine
Application Program
SB FIPS JavaModule
Module Interface (API)
15
3 CryptographicModule 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 Ethernet port
Data Output API Ethernet port
Control Input API Keyboard and Mouse
Status Output Return Code Display
Power Input Initialization Function The Power Supply is the power interface.
Maintenance Not supported Not supported
16
4 Roles, Services, and Authentication
4.1 Rolesand Services
SB FIPS Java Module supports Crypto Officer and User Roles (see Table4). These roles
are enforced by this Security Policy.
Table 4: Roles and Services
Service1 Crypto
Officer
User Description Input Output CSP Access
Initialization, etc.
Initialization × ×
Initialize module for use
in the Approved Mode
of Operation.
N/A N/A N/A N/A
Deinitialization × ×
Deinitialize module for
use in the Approved
Mode of Operation.
N/A N/A N/A N/A
Self-tests × × Performs self-tests N/A
Pass or fail
return code
N/A N/A
Show status × × Displays module status N/A
Module
status
N/A N/A
Symmetric Ciphers (AES and Triple DES)
Key generation
(Triple-DES only) × × Generate Triple-DES
Key
Key Size Key Triple-DES key Write
Encrypt × × Encrypts plaintext data
Plaintext data,
Initialization
vector, Key
Encrypted
data
AES Key, Triple-
DES Key
Read/
Execute
Decrypt × × Decrypts encrypted data
Encrypted
data,
Initialization
vector, Key
Plaintext
data
AES Key, Triple-
DES Key
Read/
Execute
Key zeroization × × Zeroize symmetric Keys N/A N/A
AES Key, Triple-
DES Key
Write
Hash Algorithms and Message Authentication (SHA, HMAC)
Hashing × ×
Calculates a hash using
SHA
Plaintext Data Hashed data N/A N/A
Message
Authentication × × Calculates a MAC using
HMAC-SHA
HMAC key
and Plaintext
data
Hashed data HMAC Key
Read/
Execute
Zeroize × × Zeroize HMAC key N/A N/A HMAC Key Write
Random Bit Generation
Instantiation × ×
Instantiation of the SP
800-90A DRBGs
Seed value N/A DRBG Seed Read
Request × × Generates random bits
Number of
bits
Random
bits
N/A
Read/
Execute
CSP/Key zeroization × × Zeroize CSPs N/A N/A DRBG Seed Write
Digital Signature (DSA, ECDSA, RSA)
Key pair generation × ×
Generates asymmetric
key pair
Key size
Asymmetric
key pair
DSA key pair,
ECDSA key pair
and RSA key pair
Write
Sign × × Generates a digital
signature
Signing key
and plaintext
Digital
signature
DSA private key,
ECDSA private
key and RSA
private key
Read/
Execute
1
These services are non-Approved when using one of the non-Approved algorithms as specified in Table 5.
17
Verify × × Verifies a digital
signature
Digital
signature and
Public Key
Result of
verification
DSA public key,
ECDSA public
key and RSA
public key
Read/
Execute
Key zeroization × × Zeroize CSPs N/A N/A
DSA key pair,
ECDSA key pair
and RSA key pair
Write
Key Agreement (Diffie-Hellman, Elliptic Curve Diffie-Hellman, ECMQV)
Key pair generation
Generates asymmetric
key pair
Key size
Asymmetric
key pair
DH key pair,
ECDH key pair
and ECMQV key
pair
Write
Shared secret
generation
Generates a shared
secret
N/A
Shared
secret
DH key pair,
ECDH key pair
and ECMQV key
pair
Read/
Execute
Key zeroization Zeroize CSPs N/A N/A
DH key pair,
ECDH key pair
and ECMQV key
pair
Write
Key Wrapping (RSA)
Key pair generation × × Generates asymmetric
key pair
Key size
Asymmetric
key pair
RSA key pair Write
Wrap × × Wrap a key value
Key value and
RSA Key
Wrapped
key value RSA public key
Read/
Execute
Unwrap × ×
Unwrap a wrapped key
value
Encrypted
Key value and
RSA Key
Unwrapped
key value
RSA private key
Read/
Execute
Key zeroization × × Zeroize CSPs N/A N/A RSA key pair Write
In order to operate the module securely, it is the Crypto Officer and User’s responsibility
to confine calls to those methods that have been FIPS 140-2 Approved. Thus, in the
approved mode of operation, all Roles shall confine themselves to calling FIPS Approved
algorithms, as marked in Table 5.
18
4.2 Security Functions
SB FIPS Java Module supports many cryptographic algorithms. The set of cryptographic
algorithms supported by SB FIPS Module is given in Table 5.
Table 5: Supported Algorithms and Standards
Algorithm
FIPS
Approved or
Allowed
Cert #
Version 2.9 Version 2.9.2
Block Ciphers DES (ECB, CBC, CFB64, OFB64)
Triple DES (ECB, CBC, CFB64,
OFB64 [SP 800-67] ×
#2188,
#2320,
#2321
#2788,
#2822,
#2823
DESX (ECB, CBC, CFB64, OFB64)
AES (ECB, CBC, CFB128, OFB128,
CTR, CCM, CMAC, GCM) [FIPS
197]
× #3988 #5539
AES (ECB, CBC, CFB128, OFB128,
CTR) [FIPS 197] × #4299,
#4300
AES (ECB, CBC, CFB128, OFB128,
CTR, GCM) [FIPS 197] × #5608,
#5609
ARC2 (ECB, CBC, CFB64, OFB64)
[RFC 2268]
Stream Cipher ARC4
Hash Functions
SHA-1 [FIPS 180-4] ×
#3292,
#3537,
#3538
#4445,
#4505,
#4506
SHA-224 [FIPS 180-4] ×
#3292,
#3537,
#3538
#4445,
#4505,
#4506
SHA-256 [FIPS 180-4] ×
#3292,
#3537,
#3538
#4445,
#4505,
#4506
SHA-384 [FIPS 180-4] ×
#3292,
#3537,
#3538
#4445,
#4505,
#4506
SHA-512 [FIPS 180-4] ×
#3292,
#3537,
#3538
#4445,
#4505,
#4506
MD5 [RFC 1321]
MD2 [RFC 1115]
RIPEMD
Message
Authentication HMAC-SHA-1 [FIPS 198-1] ×
#2603,
#2835,
#2836
#3690,
#3741,
#3742
HMAC-SHA-224 [FIPS 198-1] ×
#2603,
#2835,
#2836
#3690,
#3741,
#3742
HMAC-SHA-256 [FIPS 198-1] ×
#2603,
#2835,
#2836
#3690,
#3741,
#3742
HMAC-SHA-384 [FIPS 198-1] ×
#2603,
#2835,
#2836
#3690,
#3741,
#3742
HMAC-SHA-512 [FIPS 198-1] ×
#2603,
#2835,
#2836
#3690,
#3741,
#3742
HMAC-MD5 [RFC 2104]
Random Bit
Generation
ANSI X9.62 RNG [ANSI X9.62]
DRBG [NIST SP 800-90A Rev. 1] ×
#1180,
#1359,
#1360
#2194,
#2250,
#2251
19
NDRGB (GenerateSeed())2
×
Digital Signature
DSA [FIPS 186-4] ×
#1084,
#1142,
#1143
#1421,
#1443,
#1444
ECDSA [FIPS 186-4] ×
#884,
#1009,
#1010
#1490,
#1518,
#1519
RSA PKCS #1 v1.5 Signature [PKCS
#1 v2.1] ×
#2046,
#2320,
#2321
#2972,
#3016,
#3017
RSA PSS [PKCS #1 v2.1] ×
#2046,
#2320,
#2321
#2972,
#3016,
#3017
ECQV
Key Agreement
Diffie-Hellman [NIST SP 800-56A]
#83,
#98,
#99
#190,
#193,
#194
Elliptic Curve Diffie Hellman [NIST
SP 800-56A]
#83,
#98,
#99
#190,
#193,
#194
ECMQV [NIST SP 800-56A]
#83,
#98,
#99
#190,
#193,
#194
Key Wrapping RSA PKCS #1 v1.5 Encryption
[PKCS #1 v2.1] ×
RSA OAEP [KTS, vendor affirmed] ×
ECIES [ANSI X9.63]
The Triple-DES, AES (ECB, CBC, CFB128, OFB128, CTR, CCM, GCM, and CMAC
modes), SHS (SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512), HMAC-SHS
(HMACSHA-1, HMAC-SHA-224, HMAC-SHA256, HMAC-SHA-384, and HMAC-
SHA-512), random bit generation (NIST SP 800-90A), DSA, ECDSA, RSA PKCS #1
v1.5 Signature, and RSA PSS algorithms. SB FIPS Java Module also supports a NIST SP
800-56B Key Establishment technique (key wrapping), RSA OAEP. In order to operate
the module in a FIPS Approved mode of operation only these FIPS Approved or allowed
algorithms may be used. The operator shall use an Approved DRBG internal to the
module to generate an IV that shall consist of a minimum of 96-bits when using AES
GCM encryption.
DES, DESX, AES CCM* (CCM star) mode, random bit generation (ANSI X9.62),
ARC2, ARC4, MD5, MD2, RIPEMD and HMAC-MD5, ECQV, ECIES, RSA PKCS #1
v1.5 Encryption algorithm, and Diffie-Hellman, Elliptic Curve Diffie-Hellman, and
ECMQV are supported as non FIPS Approved algorithms. In order to operate the module
in a FIPS Approved mode of operation these algorithms must not be used.
Generated symmetric keys or seeds used in the creation of asymmetric key pairs are an
unmodified output from an Approved DRBG.
Please be advised, 2-Key Triple-DES decryption is permitted for legacy purposes. 2-Key
Triple-DES encryption is now considered a non-FIPS Approved algorithm as of January
1, 2016. Please see NIST SP 800-131A for more information.
In accordance to NIST guidance, operators are responsible for insuring that a single
Triple-DES key shall not be used to encrypt more than 216 64-bit data blocks.
There are some algorithm modes that were tested but not implemented by the module.
Only the algorithms, modes, and key sizes that are implemented by the module are shown
in this table.
2
The estimated amount of entropy provided by the NDRNG is 184.122 bits.
Table 6 summarizes the keys and CSPs used in the FIPS mode.
Table 6: Key and CSP, Key Size, Security Strength, and Access
Algorithm Key and SP Key Size Strength Access
AES key 128-256 bits 128-256 bits Use
Triple-DES key 192 bits 112 bits
Create, Read,
Use
HMAC key 160-512 bits 160-512 bits Use
DRBG seed 160-512 bits 160-512 bits Use
DSA key pair 2048-15360 bits 112-256 bits
Create, Read,
Use
ECDSA key pair 224-571 bits 112-256 bits
Create, Read,
Use
RSA Signature key pair 2048-15360 bits 112-256 bits
Create, Read,
Use
RSA Key wrapping key pair 2048-15360 bits 112-256 bits
Create, Read,
Use
Note:
In FIPS approved mode, only the elliptic curves P-224, P-256, P-384, P-521, K-233, K-
283, K-409, K-571, B-233, B-283, B-409 and B-571 can be used.
SB FIPS module supports the elliptic curves K-163, B-163, P-192, secp160r1, sect239k1
and wTLS5 that are not FIPS approved. They can be used with the ECDSA, ECDH,
ECMQV and ECIES algorithms, but not in FIPS approved mode.
RSA (key wrapping; key establishment methodology provides between 112 and 256 bits of
encryption strength; non-compliant less than 112-bits of encryption strength)
Digital signature generation that provides less than 112 bits of security (using RSA, DSA or
ECDSA) is disallowed beginning January 1st, 2014.
Digital signature generation using SHA-1 as its underlying hash function is disallowed
beginning January 1st, 2014.
HMAC-SHA-1 shall have a key size of at least 112 bits.
20
21
4.3 Operator Authentication
SB FIPS Java Module does not deploy authentication mechanism. The roles of Crypto
Officer and User are implicitly selected by the operator.
5 Finite State Model
The Finite State model contains the following states:
• Installed/Uninitialized
• Initialized
• Self-Test
• Idle
• Crypto Officer/User
• 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 In-
stalled/Uninitialized state.
2. When the initialization command is applied to the module, i.e., the module is loaded
on the memory, turning to the Initialization state. Then, it transits to the Self-Test
state automatically, running the Power-up Tests. While in the Self-Test state, the
module prohibits all data output via the data output interface. On success the module
enters Idle; on failure the module enters Error 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 transit to the Crypto Officer/User state when an API method is called.
4. When the API method has completed successfully, the state transits back to Idle.
5. If the Conditional Test (Continuous RNG Test or Pair-wise Consistency Test) fails,
the state transits 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.
7. When the de-initialization command is executed, the module goes back to the
Installed/Uninitialized state.
22
6 Physical Security
Physical security is not applicable to this software module at Level 1 Security.
23
7 Operational 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 Linux and Android provide such operational environment.
24
8 Cryptographic Key Management
SB FIPS Java Module provides the underlying methods 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).
8.1 Key Generation
SB FIPS Module provides FIPS 140-2 compliant key generation. The underlying random
number generation uses a FIPS Approved method, a DRBG (hash, HMAC or counter
based on block cipher).
The module also supports Dual_EC DRBG, however, the use of Dual_EC DRBG is non-
approved for key generation. No keys generated using this version of the DRBG can be
used to protect sensitive data in the Approved mode. Any random output in Approved
mode using the DUAL_EC DRBG is equivalent to plaintext.
8.2 Key Establishment
SB FIPS Java Module provides the following FIPS allowed key establishment techniques
[5]:
RSA OAEP
The RSA OAEP key wrapping implementation supports modulus sizes from 512 bits to
15360 bits that provides between 56 and 256 bits of security, where 2048 bits and above
must be used to provide minimum of 112 bits of security in the FIPS mode.
It is the user’s responsibility to ensure that the appropriate key establishment techniques
are applied to the appropriate keys.
8.3 Key Entryand Output
Secret (security sensitive) keys must be imported into or exported from the SB FIPS Java
Module in encrypted form using a FIPS Approved algorithm when crossing the module’s
physical boundary.
8.4 Key Storage
SB FIPS Java Module is a low-level cryptographic toolkit, and as such does not provide key
storage.
25
8.5 Zeroization of Keys
SB FIPS Java Module provides zeroizable interfaces which implement zeroization
methods. Zeroization of all keys and CSPs are performed in the finalizing methods of the
objects; JVM executes the finalizing methods every time it operates garbage collection.
26
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. The following tests are
applied:
1. Known Answer Tests (KATs):
KATs are performed on Triple-DES encrypt, Triple-DES decrypt, AES encrypt,
AES decrypt, SHS (via HMAC-SHS), HMAC-SHS,DRBG
hash/HMAC/counter health tests (instantiate, generate, reseed and un-
instantiate), RSA sign and RSA verify, Diffie-Hellman, Elliptic Curve Diffie-
Hellman, ECMQV and KDF (via key agreement). For DSA and ECDSA, Pair-
wise Consistency Test is used.
2. Software Integrity Test:
The software integrity test deploys ECDSA signature validation to verify the
integrity of the module.
9.1.2 On-Demand Self-Tests
On-demand self-tests may be invoked by the Cryptographic Officer or User by invoking
a method, which is described in the Crypto Officer And User Guide in Appendix A.
9.2 Conditional Tests
The Continuous RNG Test is executed on all data generated by the NIST SP 800-90A
DRBG, examining the first 160 bits of each requested random generation for repetition.
This ensures that the RNG is not stuck at any constant value.
Also, upon each generation of a RSA, DSA or ECDSA key pair, the generated key pair is
tested of their correctness by generating a signature and verifying the signature on a given
message as a Pair-wise Consistency Test.
9.3 Failure of Self-Tests
Failure of the Self-Tests places the cryptographic module in the Error state, wherein no
cryptographic operations can be performed. The module is disabled. Additionally, the
cryptographic module will throw a Java exception to the caller.
27
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 certifying lab. 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.
28
11 Mitigation of Other Attacks
SB FIPS Java Module implements mitigation of the following attacks:
1. Timing Attack on RSA
2. Attack on biased private key of DSA
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.
Note that Remote Timing Attacks are practical:
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
11.2 Attack on Biased Private Key of DSA
The standard for choosing ephemeral values in DSA signature introduce a slight bias.
Means to exploit these biases were presented to ANSI by D. Bleichenbacher.
In order to mitigate this attack, the following is executed: The bias in the RNG is reduced
to levels which are far below the Bleichenbacher attack threshold.
Change Notice 1 of FIPS 186-2 is published to mitigate this attack:
http://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2-
change1.pdf
29
A Crypto Officer And User Guide
A.1 Installation
In order to carry out a secure installation of SB FIPS Java 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 Java Module. Only the
Crypto Officer is allowed to install the product.
Place the cryptographic module, EccpressoFIPS.jar in CLASSPATH or as in installed
extension.
A.1.2 Uninstalling
Remove the jar file, EccpressoFIPS.jar, from the computer hardware.
A.2 Commands
A.2.1 Initialization
FIPSManage.getInstance().activateFIPSMode()
This method runs a series of Self-Tests on the module. These tests examine the integrity
of the shared object, and the correct operation of the cryptographic algorithms. If these
tests are successful, the module will be enabled.
The Self-Tests are automatically run whenever a CryptoTransform or DRBG object is
created. Therefore, there is no need to invoke this method to initialize the module
explicitly.
If the module has been de-initialized by a previous call to
FIPSManage.getInstance().deactivateFIPSMode(), it can be re-initialized by calling
this method.
A.2.2 De-Initialization
FIPSManage.getInstance().deactivateFIPSMode()
This method de-initializes the module.
A.2.3 Self-Tests
FIPSManage.getInstance().runSelfTests()
This method runs a series of Self-Tests, and returns if the tests are successful, otherwise,
an exception is thrown. These tests examine the integrity of the shared 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
Status can be found by calling FIPSManager.getInstance().isFIPSMode() and
FIPSManager.getInstance().requestCryptoOperation(). If both methods return true,
the module is in the Idle state (the module is operating in the Approved mode of
operation and is ready to perform cryptographic operations).
30
A.3 When Module is Disabled
When SB FIPS Java Module becomes disabled, attempt to bring the module back to the
Installed state by calling the de-initialization method , and then to initialize the module
using the initialization method. If the initialization is successful, the module is recovered.
If this attempt fails, uninstall the module and re-install it. If the module is initialized
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 FIPS Mode
In order to operate in FIPS 140-2 mode, it is the user’s responsibility to use FIPS Approved
algorithms, as marked in Table 5.