SUSE Linux Enterprise Server 12 SP2 - NSS
Cryptographic Module v2.0
FIPS 140-2 Non-Proprietary Security Policy
Version 1.1
Last Update: 04/17/18
Prepared by:
atsec information security corporation
9130 Jollyville Road, Suite 260
Austin, TX 78759
www.atsec.com
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Contents
1 Cryptographic Module Specification....................................................................................................................3
1.1 Description of the Module............................................................................................................................3
1.2 Description of Approved Modes...................................................................................................................4
1.3 Cryptographic Boundary..............................................................................................................................7
1.3.1 Hardware Block Diagram.....................................................................................................................7
1.3.2 Software Block Diagram......................................................................................................................8
2 Cryptographic Module Ports and Interfaces.......................................................................................................10
2.1 Inhibition of Data Output............................................................................................................................10
2.2 Disconnecting the Output Data Path from the Key Processes...................................................................10
3 Roles, Services, and Authentication...................................................................................................................11
3.1 Roles.......................................................................................................................................................... 11
3.2 Role Assumption........................................................................................................................................11
3.3 Strength of Authentication Mechanism.......................................................................................................11
3.4 Multiple Concurrent operators....................................................................................................................12
3.5 Services..................................................................................................................................................... 12
3.5.1 Calling Convention of API Functions..................................................................................................12
3.5.2 API Functions.....................................................................................................................................12
4 Physical Security...............................................................................................................................................19
5 Operational Environment...................................................................................................................................20
5.1 Policy......................................................................................................................................................... 20
6 Cryptographic Key Management.......................................................................................................................21
6.1 Random Number Generation.....................................................................................................................21
6.2 Key/CSP Storage.......................................................................................................................................22
6.3 Key/CSP Zeroization..................................................................................................................................22
7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)..........................................................24
8 Self-Tests........................................................................................................................................................... 25
8.1 Power-Up Tests.........................................................................................................................................25
8.2 Conditional Tests.......................................................................................................................................25
9 Guidance........................................................................................................................................................... 27
9.1 Crypto Officer Guidance............................................................................................................................27
9.1.1 Access to Audit Data..........................................................................................................................28
9.2 User Guidance........................................................................................................................................... 28
9.2.1 AES GCM Guidance..........................................................................................................................29
9.2.2 RSA and DSA Keys...........................................................................................................................29
9.2.3 Triple-DES Keys................................................................................................................................29
10 Mitigation of Other Attacks...............................................................................................................................30
11 Glossary and Abbreviations.............................................................................................................................31
12 References...................................................................................................................................................... 32
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
2 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
1 Cryptographic Module Specification
This document is the non-proprietary security policy for the SUSE Linux Enterprise Server 12 SP2 - NSS
Cryptographic Module, and was prepared as part of the requirements for conformance to Federal Information
Processing Standard (FIPS) 140-2, Security Level 1.
1.1 Description of the Module
The SUSE Linux Enterprise Server 12 SP2 - NSS Cryptographic Module (hereafter referred to as “the module”
or “module“) is a software library supporting FIPS 140-2 Approved cryptographic algorithms. The current version
of the Module is 2.0. The Module is an open-source, general-purpose cryptographic library, with an API based on
the industry standard PKCS #11 version 2.20. For the purposes of FIPS 140-2 validation, the Module is
classified as a software-only module. Its embodiment type is defined as multi-chip standalone.
The Module is FIPS140-2 validated at overall Security Level 1 with levels for individual sections shown in the
table below:
Security Component FIPS 140-2 Security Level
Cryptographic Module Specification 1
Cryptographic Module Ports and Interfaces 1
Roles, Services, and Authentication 2
Finite State Model 1
Physical Security N/A
Operational Environment 1
Cryptographic Key Management 1
EMI/EMC 1
Self Tests 1
Design Assurance 2
Mitigation of Other Attacks 1
Table 1: Security Level of the Module
The Module has been tested on the following platform:
Manufacturer Model O/S & Ver.
FUJITSU Server PRIMERGY CX2570
M2 inside a CX400 M1 enclosure
Intel Xeon E5 family SUSE Linux Enterprise Server 12 SP2
IBM z13 z13 SUSE Linux Enterprise Server 12 SP2
Table 2: Tested Platforms
On the FUJITSU Server, the Module has been tested in the following configuration:
• 64-bit x86_64 with AES-NI
• 64-bit x86_64 without AES-NI
Note: The z13 test platform supports CPACF instruction set, but the module does not utilize it. The Module
always uses C implementation of AES on the z13 platform.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
3 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Note: Per FIPS 140-2 IG G.5, the Cryptographic Module Validation Program (CMVP) makes no
statement as to the correct operation of the module or the security strengths of the generated keys when
this module is ported and executed in an operational environment not listed on the validation certificate.
1.2 Description of Approved Modes
The Module supports two modes of operation:
• FIPS mode (the Approved mode of operation): only approved or allowed security functions with sufficient
security strength can be used.
• Non-FIPS mode (the non-Approved mode of operation): only non-approved security functions can be
used.
The module enters FIPS mode after power-up tests succeed. Once the module is operational, the mode of
operation is implicitly assumed depending on the security function invoked and the security strength of the
cryptographic keys.
Critical security parameters used or stored in FIPS mode are not used in non-FIPS mode, and vice versa.
When the Module is powered on, the power-up self-tests are executed automatically without any operator
intervention.
Table 3 lists the services using Approved algorithms in FIPS mode.
Service Algorithm Keys/CSPs CAVS
Certificate
Encryption and
decryption
AES:
• ECB
• CBC
• CTR
• KW
128, 192 and 256-bit keys #5003, #5004,
#5005
Triple-DES:
• ECB
• CBC
• CTR
168-bit keys #2580, #2581,
#2582
Signature generation
and verification
DSA:
• PQG Generation
• Signature Generation
• Key Pair Generation
Key size:
• L = 2048, N = 224 bits
• L = 2048, N = 256 bits
• L = 3072, N = 256 bits
#1309, #1310,
#1311
DSA:
• PQG Verification
• Signature Verification
Key size:
• L = 1024, N = 160 bits
• L = 2048, N = 224 bits
• L = 2048, N = 256 bits
• L = 3072, N = 256 bits
ECDSA:
• Key Pair Generation
• PKV
• Signature Generation
• Signature Verification
Curves:
• P-256
• P-384
• P-521
#1272, #1273,
#1274
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
4 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Service Algorithm Keys/CSPs CAVS
Certificate
RSA:
• Key Pair Generation
Key size:
• 2048 bits
• 3072 bits
#2697, #2698,
#2699
RSA:
• Signature Generation
PKCS#1 v1.5
Key size:
• 2048 bits
• 3072 bits
• 4096 bits
RSA:
• Signature Verification
PKCS#1 v1.5
RSA:
• 1024 bits
• 2048 bits
• 3072 bits
Message digest Hash functions:
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512
N/A #4068, #4069,
#4070
Keyed message digest HMAC:
• SHA-1
• SHA-224
• SHA-256
• SHA-384
• SHA-512
Key size (at least 112 bits):
• > block size
• < block size
• = block size
#3325, #3326,
#3327
Random number
generation
SP800-90A Hash_DRBG
• SHA-256 (without prediction
resistance)
Entropy input string, seed, V
and C values
#1824, #1825,
#1826
Key Derivation
Function
KDF:
• SP 800-135 TLS KDF
Pre-master secret CVL:
#1552, #1554,
#1556
Table 3: Services using Approved Algorithms in FIPS mode
Table 4 lists the services using non-Approved but allowed algorithms in FIPS mode.
Service Algorithm Note Keys/CSPs
Key
Management
RSA key wrapping
(encrypt/decrypt)
The CAVS testing is not available. RSA keys with size equal to or
larger than 2048 bits
Diffie-Hellman key
agreement
CVL #1551, #1553, #1555 Diffie-Hellman with keys
between 2048 and 15360 bits
EC Diffie-Hellman key
agreement
CVL #1551, #1553, #1555 EC Diffie-Hellman private and
public components with curves
P-256, P-384 and P-521
Table 4: Services using non-Approved but Allowed Algorithms in FIPS mode
Notes:
1. AES (key wrapping; key establishment methodology provides between 128 and 256 bits of encryption
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
5 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
strength)
2. RSA (key wrapping; key establishment methodology provides at least 112 bits of encryption strength)
3. Diffie-Hellman (key agreement; key establishment methodology provides between 112 and 256 bits of
encryption strength)
4. EC Diffie-Hellman (key agreement; key establishment methodology provides between 128 and 256 bits
of encryption strength)
Caveat:
The module generates cryptographic keys whose strengths are modified by available entropy.
Table 5 lists the services using non-Approved algorithms, invocation of which will result in the Module operating
in a non-FIPS mode implicitly.
Service Algorithm
Encryption and decryption AES-GCM
Camellia
DES
RC2
RC4
RC5
SEED
AES CTS block chaining mode
Signature generation and
verification
DSA domain parameter generation, key pair generation and signature
generation with key size not equal to 2048 or 3072 bits
DSA domain parameter verification and signature verification with key size
not equal to 1024, 2048 or 3072 bits
RSA key generation and PKCS#1 v1.5 signature generation with key size
not equal to 2048 or 3072 bits
RSA PKCS#1 v1.5 signature verification with key size not equal to 1024,
2048 or 3072 bits
RSA PSS signature generation and verification
Message digest MD2
MD5
Key Management RSA key wrapping (encrypt/decrypt) with key size smaller than 2048 bits
AES/Triple-DES Key Wrapping using a non-SP 800-38F block chaining
mode
Diffie-Hellman key agreement with keys smaller than 2048 bits
JPAKE key agreement
Table 5: Services using non-Approved Algorithms in non-FIPS mode
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
6 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
1.3 Cryptographic Boundary
The Module's physical boundary is the surface of the case of the platform (depicted in the hardware block
diagram).
The Module's logical boundary consists of the shared library files and their integrity check signature files, which
are delivered with the RPM packages as listed below:
• The libsoftokn3-3.29.5-58.12.1, which contains the following shared libraries:
/usr/lib64/libnssdbm3.so
/usr/lib64/libsoftokn3.so
• The libsoftokn3-hmac-3.29.5-58.12.1, which contains the following integrity check signature files:
/usr/lib64/libnssdbm3.chk
/usr/lib64/libsoftokn3.chk
• The libfreebl3-3.29.5-58.12.1, which contains the following shared library:
• /lib64/libfreeblpriv3.so
• The libfreebl3-hmac-3.29.5-58.12.1, which contains the following integrity check signature file:
• /lib64/libfreeblpriv3.chk
The module shall be installed and instantiated by the dracut-fips package. The dracut-fips package is only used
for the configuration of the system and the module at boot time. This code is not active when the module is
operational and does not provide any services to users interacting with the module. The dracut-fips package is
outside the module's logical boundary.
1.3.1 Hardware Block Diagram
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
7 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Figure 1. Hardware Block Diagram
1.3.2 Software Block Diagram
The module implements the PKCS #11 (Cryptoki) API. The API itself defines the logical cryptographic boundary,
thus all implementation is inside the boundary. The diagram below shows the relationship of the layers.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
8 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Figure 2. Software Block Diagram
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
9 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
2 Cryptographic Module Ports and Interfaces
The physical ports of the module are the same as the General Purpose Computer (GPC) on which it is
executing. The logical interface is a C-language Application Program Interface (API) following the PKCS #11
specification.
The data input interface consists of the input parameters of the API functions. The data output interface consists
of the output parameters of the API functions. The control input interface consists of the actual API functions. The
status output interface includes the return values of the API functions. The ports and interfaces are shown in the
following table:
FIPS Interface Physical Port Module Interface
Data Input N/A API input parameters
Data Output N/A API output parameters
Control Input N/A API function calls, configuration file /proc/sys/crypto/fips_enabled
Status Output N/A API return codes and status parameters
Power Input PC Power Supply Port N/A
Table 6: Ports and Interfaces
The module uses different function arguments for input and output to distinguish among data input, control input,
data output, and status output; to disconnect the logical paths followed by data/control entering the module and
data/status exiting the module. The module doesn't use the same buffer for input and output. The module is
designed with an input buffer that may hold security-related information, it zeroizes the buffer so that if the
memory can be reused later as an output buffer. No sensitive information can be inadvertently leaked.
2.1 Inhibition of Data Output
All data output via the data output interface is inhibited when the module is performing power-up self-tests or in
error states:
• During power-up self-tests: The module performs power-up self-tests automatically without any operator
intervention. All data output via the data output interface is inhibited while self-tests are executed.
• In error states: If the power-up self-tests fail, the module will be aborted and no service can be invoked.
If the conditional self-tests fail during operation, the module will enter operational error state and only the
API functions that shut down and restart the Module, reinitialize the Module, or output status information
can be invoked. These functions are FC_GetFunctionList, FC_Initialize, FC_Finalize,
FC_GetInfo, FC_GetSlotList, FC_GetSlotInfo, FC_GetTokenInfo, FC_InitToken,
FC_CloseSession, FC_CloseAllSessions, and FC_WaitForSlotEvent.
2.2 Disconnecting the Output Data Path from the Key Processes
During key generation and key zeroization, the Module may perform audit logging, but the audit records do not
contain any sensitive information. The Module does not return any function output arguments until key
generation or key zeroization is finished. Therefore, the logical paths used by data output are logically
disconnected from the processes/threads performing key generation and key zeroization.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
10 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
3 Roles, Services, and Authentication
This section defines the roles, services and authentication mechanisms, and methods with respect to the
applicable FIPS 140-2 requirements.
3.1 Roles
The module implements two roles: User role and Crypto Officer (CO) role, their allowed services are listed in the
following table.
Role Descriptions
User Perform general security services which use the secret or private keys of the Module. It is also
responsible for the retrieval, updating, and deletion of keys from the private key database.
CO Perform module installation, configuration and initialization. The CO role can access other general-
purpose services (such as message digest and random number generation services) and status
services of the module. The CO does not have access to any service that utilizes the secret or
private keys of the module. The CO must control the access to the module before and after
installation, including management of physical access to the computer, execution of the module, as
well as management of the security facilities provided by the operating system.
Table 7: Roles
3.2 Role Assumption
The CO role is implicitly assumed by an operator while installing the module by following the instructions in
section 9.1 and while performing other services as listed in Table 7.
The module also implements a password-based authentication for the user role. To perform any security
services under the user role, an operator must log into the module and complete an authentication procedure
using the password information unique to the user role operator. The password is passed to the module via the
API function as one of its input arguments and will not be displayed. The return value of the function is the only
feedback mechanism, which does not provide any information that could be used to guess or determine the
password. The password is initialized by the CO role as part of module initialization and can be changed by the
user role operator.
If a user-role service is called before the operator is authenticated, it returns the
CKR_USER_NOT_LOGGED_IN error code. The operator must call the FC_Login function to perform the
required authentication.
Once a password has been established for the module, the user is allowed to use the security services if and
only if the user is successfully authenticated to the module. Password establishment and authentication are
required for the operation of the module.
3.3 Strength of Authentication Mechanism
In the FIPS mode of operation, the module imposes the following requirements on the password. These
requirements are enforced by the module on password initialization or change.
• The password must be at least seven characters long.
• The password must consist of characters from three or more character classes. We define five character
classes: digits (0-9), ASCII lowercase letters (a-z), ASCII uppercase letters (A-Z), ASCII non-
alphanumeric characters (space and other ASCII special characters such as '$', '!'), and non-ASCII
characters (Latin characters such as 'é', 'ß'; Greek characters such as 'Ω', 'θ'; other non-ASCII special
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
11 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
characters such as '¿'). If an ASCII uppercase letter is the first character of the password, the uppercase
letter is not counted toward its character class. Similarly, if a digit is the last character of the password,
the digit is not counted toward its character class.
To estimate the maximum probability of a successful random guess of the password, we assume that:
• The characters of the password are independent with each other.
• The password contains the smallest combination of the character classes, which is five digits, one ASCII
lowercase letter and one ASCII uppercase letter, and the probability to guess every character
successfully is (1/10)^5 * (1/26) * (1/26) = 1/67,600,000.
Since the password can contain seven characters from any three or more of the aforementioned five character
classes, the probability that a random guess of the password will succeed is less than or equal to 1/67,600,000,
which is smaller than the required threshold of 1/1,000,000.
After each failed authentication attempt in the FIPS mode, the module inserts a one-second delay before
returning to the caller, allowing at most 60 authentication attempts during a one-minute period. Therefore, the
probability of a successful random guess of the password during a one-minute period is less than or equal to 60
* (1/67,600,000) = 0.089 * (1/100,000), which is smaller than the required threshold of 1/100,000.
3.4 Multiple Concurrent operators
The module does not allow concurrent operators.
• On a multi-user operating system, this is enforced by making the NSS certificate and private key
databases readable and writable by the owner of the files only.
Note: FIPS 140-2 Implementation Guidance Section 6.1 clarifies the use of a cryptographic module on a server.
When a cryptographic module is implemented in a server environment, the server application is the user of the
cryptographic module. The server application makes the calls to the cryptographic module. Therefore, the server
application is the single user of the cryptographic module, even when the server application is serving multiple
clients.
3.5 Services
3.5.1 Calling Convention of API Functions
The Module has a set of API functions denoted by FC_*. All the API functions for the FIPS mode of operation
are listed in Table 8 of Section 3.5.2.
Among the module's API functions, only FC_GetFunctionList is exported and therefore callable by its name. All
the other API functions must be called via the function pointers returned by FC_GetFunctionList. It returns a
CK_FUNCTION_LIST structure containing function pointers named C_* such as C_Initialize and C_Finalize. The
C_* function pointers in the CK_FUNCTION_LIST structure returned by FC_GetFunctionList point to the FC_*
functions.
The following convention is used to describe API function calls. Here FC_Initialize is used as an example:
• When “call FC_Initialize” is mentioned, the technical equivalent of “call the FC_Initialize function via the
C_Initialize function pointer in the CK_FUNCTION_LIST structure returned by FC_GetFunctionList” is
implied.
3.5.2 API Functions
The module supports Crypto-Officer services which require no operator authentication, and user services which
require operator authentication. Crypto-Officer services do not require access to the secret and private keys and
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
12 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
other CSPs associated with the user. The message digesting services are available to Crypto-Officer only when
CSPs are not accessed. User services which access CSPs (e.g., FC_GenerateKey, FC_GenerateKeyPair)
require operator authentication.
Table 8 lists all the services available in FIPS mode. Access types R, W and Z stand for Read, Write and
Zeroize, respectively. Role types U and CO correspond to User role and Crypto Officer role, respectively. Please
refer to Table 3 and Table 4 for the Approved or allowed key size of each cryptographic algorithm supported by
the Module.
Note: The message digesting API functions (except FC_DigestKey) that do not use any keys of the module are
able to be accessed by the Crypto-Officer role and do not require user role authentication to the module. The
FC_DigestKey API function computes the message digest (hash) of the value of a secret key, so it is available
only to the User role.
Service Role API Function Description CSPs Access
Get the
function list
CO FC_GetFunctionList Return a pointer to the list of
function pointers for the
operational mode
none -
Module
initialization
CO FC_InitToken Initialize or re-initialize a token User password
and all keys
Z
CO FC_InitPIN Initialize the user's password,
i.e., set the user's initial
password
User password W
General
purpose
CO FC_Initialize Initialize the module library none -
CO FC_Finalize Finalize (shut down) the
module library
All keys Z
CO FC_GetInfo Obtain general information
about the module library
none -
Slot and
token
management
CO FC_GetSlotList Obtain a list of slots in the
system
none -
CO FC_GetSlotInfo Obtain information about a
particular slot
none -
CO FC_GetTokenInfo Obtain information about the
token. This function provides
the Show Status service.
none -
CO FC_GetMechanismList Obtain a list of mechanisms
(cryptographic algorithms)
supported by a token
none -
CO FC_GetMechanismInfo Obtain information about a
particular mechanism
none -
U FC_SetPIN Change the user's password User password RW
Session
management
CO FC_OpenSession Open a connection ("session")
between an application and a
particular token
none -
CO FC_CloseSession Close a session All keys for the
session
Z
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
13 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Service Role API Function Description CSPs Access
CO FC_CloseAllSessions Close all sessions with a token All keys Z
CO FC_GetSessionInfo Obtain information about the
session. This function provides
the Show Status service.
none -
CO FC_GetOperationState Save the state of the
cryptographic operation in a
session. This function is only
implemented for message
digest operations.
none -
CO FC_SetOperationState Restore the state of the
cryptographic operation in a
session. This function is only
implemented for message
digest operations.
none -
U FC_Login Log into a token User password R
U FC_Logout Log out from a token none -
Object
management
U FC_CreateObject Create a new object key W
U FC_CopyObject Create a copy of an object Original key R
New key W
U FC_DestroyObject Destroy an object key Z
U FC_GetObjectSize Obtain the size of an object in
bytes
key R
U FC_GetAttributeValue Obtain an attribute value of an
object
key R
U FC_SetAttributeValue Modify an attribute value of an
object
key W
U FC_FindObjectsInit Initialize an object search
operation
none -
U FC_FindObjects Continue an object search
operation
Keys matching
the search criteria
R
U FC_FindObjectsFinal Finish an object search
operation
none -
Encryption
and
decryption
U FC_EncryptInit Initialize an encryption
operation
AES/Triple-DES
secret key
R
U FC_Encrypt Encrypt single-part data AES/Triple-DES
secret key
R
U FC_EncryptUpdate Continue a multiple-part
encryption operation
AES/Triple-DES
secret key
R
U FC_EncryptFinal Finish a multiple-part
encryption operation
AES/Triple-DES
secret key
R
U FC_DecryptInit Initialize a decryption operation AES/Triple-DES R
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
14 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Service Role API Function Description CSPs Access
secret key
U FC_Decrypt Decrypt single-part encrypted
data
AES/Triple-DES
secret key
R
U FC_DecryptUpdate Continue a multiple-part
decryption operation
AES/Triple-DES
secret key
R
U FC_DecryptFinal Finish a multiple-part
decryption operation
AES/Triple-DES
secret key
R
Message
digest
CO FC_DigestInit Initialize a message-digesting
operation
none -
CO FC_Digest Digest single-part data none -
CO FC_DigestUpdate Continue a multiple-part
digesting operation
none -
U FC_DigestKey Continue a multi-part
message-digesting operation
by digesting the value of a
secret key as part of the data
already digested
HMAC key R
CO FC_DigestFinal Finish a multiple-part digesting
operation
none -
Signature
generation
and
verification
U FC_SignInit Initialize a signature operation DSA/ECDSA/
RSA private key,
HMAC key
R
U FC_Sign Sign single-part data DSA/ECDSA/
RSA private key,
HMAC key
R
U FC_SignUpdate Continue a multiple-part
signature operation
DSA/ECDSA/
RSA private key,
HMAC key
R
U FC_SignFinal Finish a multiple-part signature
operation
DSA/ECDSA/
RSA private key,
HMAC key
R
U FC_SignRecoverInit Initialize a signature operation,
where the data can be
recovered from the signature
DSA/ECDSA/
RSA private key
R
U FC_SignRecover Sign single-part data, where
the data can be recovered
from the signature
DSA/ECDSA/
RSA private key
R
U FC_VerifyInit Initialize a
verification operation
DSA/ECDSA/
RSA public key,
HMAC key
R
U FC_Verify Verify a signature on single-
part data
DSA/ECDSA/
RSA public key,
HMAC key
R
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
15 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Service Role API Function Description CSPs Access
U FC_VerifyUpdate Continue a multiple-part
verification operation
DSA/ECDSA/
RSA public key,
HMAC key
R
U FC_VerifyFinal Finish a multiple-part
verification operation
DSA/ECDSA/
RSA public key,
HMAC key
R
U FC_VerifyRecoverInit Initialize a verification
operation where the data is
recovered from the signature
DSA/ECDSA/
RSA public key
R
U FC_VerifyRecover Verify a signature on single-
part data, where the data is
recovered from the signature
DSA/ECDSA/
RSA public key
R
Dual-function
cryptographic
operations
U FC_DigestEncryptUpdate Continue a multiple-part
digesting and encryption
operation
AES/Triple-DES
secret key
R
U FC_DecryptDigestUpdate Continue a multiple-part
decryption and digesting
operation
AES/Triple-DES
secret key
R
U FC_SignEncryptUpdate Continue a multiple-part
signing and encryption
operation
DSA/ECDSA/
RSA private key,
HMAC key
R
AES/Triple-DES
secret key
R
U FC_DecryptVerifyUpdate Continue a multiple-part
decryption and verify operation
DSA/ECDSA/
RSA public key,
HMAC key
R
AES/Triple-DES
secret key
R
Key
management
U FC_GenerateKey Generate a secret key AES/Triple-DES
secret key
W
U FC_GenerateKeyPair Generate a public/private key
pair. This function performs the
pair-wise consistency tests.
DSA/ECDSA/
RSA key pair,
Diffie-Hellman/EC
Diffie-Hellman
public and private
components
W
U FC_WrapKey Wrap (encrypt) a key using
one of the following
mechanisms allowed in FIPS
mode per IG D.9:
1. RSA encryptionASP
800-38F Approved key
wrapping methodology
Wrapping key R
Key to be
wrapped
R
U FC_UnwrapKey Unwrap (decrypt) a key using Unwrapping key R
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
16 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Service Role API Function Description CSPs Access
one of the following
mechanisms allowed in FIPS
mode per IG D.9:
1. RSA decryption
2. SP 800-38F key
unwrapping
methodologyAny
Approved mode of
AES or two-key/three-
key Triple-DES
Unwrapped key W
U FC_DeriveKey Derive a key from a base key Base key R
Derived key W
Random
number
generation
CO FC_SeedRandom Mix in additional seed material
to the random number
generator
Entropy string,
seed, DRBG V
and C values
RW
CO FC_GenerateRandom Generate random data. This
function performs the
continuous random number
generator test
Random data,
DRBG V and C
values
RW
Parallel
function
management
CO FC_GetFunctionStatus A legacy function, which simply
returns the value 0x00000051
(function not parallel)
none -
CO FC_CancelFunction A legacy function, which simply
returns the value 0x00000051
(function not parallel)
none -
Self tests CO N/A The self tests are performed
automatically when loading the
module
DSA 2048-bit
public key
R
Zeroization U FC_DestroyObject All CSPs are automatically
zeroized when freeing the
cipher handle
All secret or
private keys and
password
Z
CO FC_InitToken
FC_Finalize
FC_CloseSession
FC_CloseAllSessions
Table 8: Service Details
NOTE:
1. 'Original key' and 'New key' are the secret keys or public private key pairs.
2. 'Wrapping key' corresponds to the secret key or public key used to wrap another key
3. 'Key to be wrapped' is the key that is wrapped by the 'wrapping key'
4. 'Unwrapping key' corresponds to the secret key or private key used to unwrap another key
5. 'Unwrapped key' is the plaintext key that has not been wrapped by a 'wrapping key'
6. 'Derived key' is the key obtained by a key derivation function which takes the 'base key' as input
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
17 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Please refer to Table 5 for the non-FIPS algorithms. Invocation of any of these services will put the module in
non-FIPS mode implicitly.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
18 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
4 Physical Security
The module is comprised of software only and thus does not claim any physical security.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
19 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
5 Operational Environment
This module operates in a modifiable operational environment per the FIPS 140-2 definition.
5.1 Policy
The operating system is restricted to a single operator mode of operation (i.e., concurrent operators are explicitly
excluded).
The application that makes calls to the module is the single user of the module, even when the application is
serving multiple clients.
In FIPS Approved mode, the ptrace system call, the debugger gdb, and strace shall not be used. In addition,
other tracing mechanisms offered by the Linux environment, such as ftrace or systemtap, shall not be used.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
20 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
6 Cryptographic Key Management
The management of all keys/CSPs used by the module is summarized in the table below.
Key/CSP Generation Storage Entry/Output Zeroization
AES or Triple-
DES key
FC_GenerateKey
() internally using
the SP 800-90A
DRBG
Application memory
or key database
Encrypted through key
wrapping using
FC_WrapKey
Automatically zeroized
when freeing the
cipher handle
RSA, DSA,
Diffie-Hellman,
EC Diffie-
Hellman/ECDSA
private key
FC_GenerateKey
Pair() (FIPS 186-
4 key generations
mechanisms)
internally using
the SP 800-90A
DRBG for the
seed
Application memory
or key database
Encrypted through key
wrapping using
FC_WrapKey
Automatically zeroized
when freeing the
cipher handle
HMAC keys SP 800-90A
DRBG
Application memory
or key database
Encrypted through key
wrapping using
FC_WrapKey
Automatically zeroized
when freeing the
cipher handle
SP 800-90A
DRBG seed and
entropy string
Obtained from
/dev/urandom
Application memory N/A Automatically zeroized
when seeding
operation completes
SP 800-90A
DRBG V and C
values
Derived from the
entropy string as
defined in SP
800-90A
Application memory N/A Automatically zeroized
when freeing DRBG
handle
User password Supplied by the
calling application
Key database in
salted form
N/A (input through API
parameter)
Automatically zeroized
when the module is re-
initialized or
overwritten when the
user changes its
password
Table 9: Key Management Details
6.1 Random Number Generation
The module implements a SP 800-90A Hash_DRBG using SHA-256 as a random number generator. The Linux
kernel provides /dev/urandom as a seed source for the DRBG. Reseeding is performed by pulling more data
from /dev/urandom. The module will periodically reseed its DRBG with unpredictable noise by calling
FC_SeedRandom: after 2 calls to the random number generator, the module reseeds
⁴⁸ the DRBG automatically.
The module performs a Continuous Random Number Generation Test (CRNGT) on the output of the SP800-90A
DRBG to ensure that consecutive random numbers do not repeat. In addition, the module also performs DRBG
health testing as defined in section 11.3 of SP 800-90A DRBG.
The Key Generation methods implemented in the module for Approved services in FIPS mode is compliant with
[SP800-133].
For generating RSA, DSA and ECDSA keys the module implements asymmetric key generation services
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
21 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
compliant with [FIPS186-4]. A seed (i.e. the random value) used in asymmetric key generation is directly
obtained from the [SP800-90A] DRBG.
The public and private key pairs used in the Diffie-Hellman and EC Diffie-Hellman KAS are generated internally
by the module using the same DSA and ECDSA key generation compliant with [FIPS186-4] which is compliant
with [SP800-56A].
The module generates symmetric key through the FC_GenerateKey() function using the random numbers from
the SP 800-90A DRBG.
6.2 Key/CSP Storage
This section identifies the cryptographic keys and CSPs that the user has access to while performing a service,
and the type of access the user has.
The module employs the following cryptographic keys and CSPs in the FIPS mode of operation. Note that the
private key database (key3.db/key4.db) mentioned below is within the module's physical boundary but outside of
its logical boundary.
• DSA integrity test public key: The module stores a public key for performing the power-up integrity test in
the libfreeblpriv3.chk, libnssdbm3.chk and libsoftokn3.chk files for the verification of libfreeblpriv3.so,
libnssdbm3.so and libsoftokn3.so, respectively.
• AES secret keys: The keys may be stored in memory or in the private key database (key3.db/key4.db).
• Hash_DRBG secret values: The entropy is stored in plaintext in volatile memory. Hash_DRBG V value
(internal Hash_DRBG state value) is stored in plaintext in volatile memory. Hash_DRBG C value
(internal Hash_DRBG state value) is stored in plaintext in volatile memory.
• Triple-DES secret keys: The keys may be stored in memory or in the private key database
(key3.db/key4.db).
• HMAC secret keys: HMAC key size must be greater than or equal to half the size of the hash function
output and greater than 112 bits. The keys may be stored in memory or in the private key database
(key3.db/key4.db).
• DSA/ECDSA public keys and private keys: The keys may be stored in memory or in the private key
database (key3.db/key4.db).
• RSA public keys and private keys (used for digital signatures and key transport): The keys may be
stored in memory or in the private key database (key3.db/key4.db).
• Diffie-Hellman/EC Diffie-Hellman public keys and private keys: The keys may be stored in memory or in
the private key database.
• Authentication data (NSS User role password): Stored in salted form in the private key database
(key3.db/key4.db).
Public and private keys are provided to the module by the calling process, and are destroyed when released by
the appropriate API function calls.
6.3 Key/CSP Zeroization
The module performs explicit zeroization steps to clear the memory region previously occupied by a plaintext
secret key, private key, or password. When the cipher handle is freed, the memset() function is used to zeroize
memory and free() function is used to free memory allocated from the heap. A plaintext secret or private key gets
zeroized when it is deleted (with a FC_DestroyObject call). All plaintext secret and private keys are zeroized
when the module is shut down (with a FC_Finalize call), or when the module is reinitialized (with a FC_InitToken
call), or when the session is closed (with a FC_CloseSession or FC_CloseAllSessions call). All zeroization is to
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
22 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
be performed by storing the value “zeros” into every byte of the memory that is occupied by a plaintext secret
key, private key or password.
Zeroization can be performed in a time that is not sufficient to compromise plaintext secret or private keys and
passwords.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
23 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
7 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC)
The test platforms that run the module meet the requirements of 47 CFR FCC PART 15, Subpart B, Class A
(Business use).
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
24 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
8 Self-Tests
FIPS 140-2 requires that the module performs self-tests to ensure the integrity of the module and the
correctness of the cryptographic functionality at start up. In addition, some functions require continuous self-
tests, such as the random number generator. All of these tests are listed and described in this section.
8.1 Power-Up Tests
All the power-up self-tests are performed automatically without requiring any operator intervention. During the
power-up self-tests no other services are available and all output is inhibited. Once the power-up self-tests are
completed successfully, the module enters operational mode and cryptographic operations are available. If any
of the power-up self-tests fail, the module enters power-up self-test error state. In error state, all output is
inhibited and no cryptographic operations are allowed. The module is aborted to indicate the error. It needs to be
reloaded in order to recover from the error state.
The module implements the following Known Answer Test (KAT) and Integrity Test during the power-up:
Algorithm Test
AES KAT: encryption and decryption are tested separately
Triple-DES KAT: encryption and decryption are tested separately
DSA KAT: signature generation and signature verification are tested
separately
RSA KAT: encryption and decryption are tested separately
KAT: signature generation and signature verification are tested
separately
ECDSA KAT: signature generation and signature verification are tested
separately
SP800-90A Hash-based DRBG KAT
SHA-1, SHA-224, SHA-256, SHA-384 and
SHA-512
KAT
HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-
256, HMAC-SHA-384 and HMAC-SHA-512
KAT
Module integrity DSA signature verification with 2048-bit key and SHA-256
Table 10: Module Self Tests
The power-up self tests can be performed on demand by reloading the Module.
8.2 Conditional Tests
The module implements the following Pair-wise Consistency Test (PCT) for public-private key pair generation
and Continuous Random Number Generator Test (CRNGT). If any of the conditional tests fail, the module enters
the operational error state. It returns the error code CKR_DEVICE_ERROR to the calling application to indicate
the error. The module needs to be reinitialized to resume normal operation. Reinitialization is accomplished by
calling FC_Finalize followed by FC_Initialize.
Algorithm Test
DSA PCT: signature generation and verification are tested
separately
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
25 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
Algorithm Test
RSA PCT: encryption and decryption are tested separately
PCT: signature generation and verification are tested
separately
ECDSA PCT: signature generation and verification are tested
separately
SP 800-90A DRBG CRNGT
Table 11: Module Conditional Tests
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
26 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
9 Guidance
9.1 Crypto Officer Guidance
The version of the RPMs containing the FIPS validated Module is listed in section 1.3. The integrity of the RPM
is automatically verified during the installation and the Crypto Officer shall not install the RPM file if the RPM tool
indicates an integrity error. The RPM package of the module can be installed by standard tools recommended for
the installation of RPM packages on a SUSE Linux system (zypper).
In addition, to support the module, the NSPR library (mozilla-nspr package) must be installed that is offered by
the underlying operating system.
Only the cipher types listed in Section 1.2 are allowed to be used.
To bring the module into FIPS Approved mode, perform the following:
1. Install the dracut-fips package:
# zypper install dracut-fips
2. Recreate the INITRAMFS image:
# dracut -f
After regenerating the initrd, the Crypto Officer has to append the following parameter in the /etc/default/grub
configuration file in the GRUB_CMDLINE_LINUX_DEFAULT line:
fips=1
After editing the configuration file, please run the following command to change the setting in the boot loader:
grub2-mkconfig -o /boot/grub2/grub.cfg
If /boot or /boot/efi resides on a separate partition, the kernel parameter boot=<partition of /boot or /boot/efi>
must be supplied. The partition can be identified with the command "df /boot" or "df /boot/efi" respectively. For
example:
$ df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 233191 30454 190296 14% /boot
The partition of /boot is located on /dev/sda1 in this example. Therefore, the following string needs to be
appended to the kernel command line:
"boot=/dev/sda1"
Reboot to apply these settings.
If an application that uses the module for its cryptography is put into a chroot environment, the Crypto Officer
must ensure one of the above methods is available to the module within the chroot environment to ensure entry
into the validated module. Failure to do so will not allow the application to properly enter the validated module.
Because FIPS 140-2 has certain restrictions on the use of cryptography which are not always wanted, the
module needs to be put into the FIPS Approved mode explicitly. If the file /proc/sys/crypto/fips_enabled exists
and contains a numeric value other than 0, the module is put into FIPS Approved mode at initialization time. This
is the mechanism recommended for ordinary use, activated by using the fips=1 option in the boot loader, as
described above.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
27 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
9.1.1 Access to Audit Data
The module may use the Unix syslog function and the audit mechanism provided by the operating system to
audit events. Auditing is turned off by default. Auditing capability must be turned on as part of the initialization
procedures by setting the environment variable NSS_ENABLE_AUDIT to 1. The Crypto Officer must also
configure the operating system's audit mechanism.
The module uses the syslog function to audit events, so the audit data are stored in the system log. Only the root
user can modify the system log. On some platforms, only the root user can read the system log; on other
platforms, all users can read the system log. The system log is usually under the /var/log directory. The exact
location of the system log is specified in the /etc/syslog.conf file. The module uses the default user facility and
the info, warning, and err severity levels for its log messages.
The module can also be configured to use the audit mechanism provided by the operating system to audit
events. The audit data would then be stored in the system audit log. Only the root user can read or modify the
system audit log. To turn on this capability it is necessary to create a symbolic link from the library file
/usr/lib64/libaudit.so.1 to /usr/lib64/libaudit.so.1.0.0.
9.2 User Guidance
The module must be operated in FIPS mode to ensure that FIPS 140-2 validated cryptographic algorithms and
security functions are used.
The following module initialization steps must be followed by the Crypto-Officer before starting to use the NSS
module:
• Set the environment variable NSS_ENABLE_AUDIT to 1 before using the NSS module with an
application.
• Use the application to get the function pointer list using the NSS API “FC_GetFunctionList”.
• Use the API FC_Initialize to initialize the module. Using the FC_GetFunctionList above ensured that we
selected FIPS mode, and the subsequent FC_Initialize call then initializes the module in FIPS-mode.
Ensure that this returns CKR_OK. A return code other than CKR_OK means that the FIPS-mode was
not enabled, and in that case, the Module must be reset and initialized again.
• For the first login, provide a NULL password and login using the function pointer C_Login, which will in-
turn call FC_Login API of the module. This is required to set the initial NSS User password.
• Now, set the initial NSS User role password using the function pointer C_InitPIN. This will call the
module's API FC_InitPIN API. Then, logout using the function pointer C_Logout, which will call the
module's API FC_Logout.
• The NSS User role can now be assumed on the module by logging in using the User password. And the
Crypto Officer role can be implicitly assumed by performing the Crypto-Officer services as listed in
Section 3.1.
The module can be configured to use different private key database formats: key3.db or key4.db. “key3.db”
format is based on the Berkeley DataBase engine and should not be used by more than one process
concurrently. “key4.db” format is based on SQL DataBase engine and can be used concurrently by multiple
processes. Both databases are considered outside the cryptographic boundary and all data stored in these
databases are considered stored in plaintext. The interface code of the NSS cryptographic module that accesses
data stored in the database is considered part of the cryptographic boundary.
Secret and private keys, plaintext passwords, and other security-relevant data items are maintained under the
control of the cryptographic module. Secret and private keys must be passed to the calling application only in
encrypted (wrapped) form with FC_WrapKey and entered from calling application only in decrypted (unwrapped)
form with FC_UnwrapKey. The cryptographic algorithms allowed for this purpose in FIPS-mode are AES, Triple-
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
28 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
DES or RSA using the corresponding Approved modes and key sizes.
Note: If the secret and private keys passed to higher-level callers are encrypted using a symmetric key
algorithm, the encryption key may be derived from a password. In such a case, they should be considered to be
in plaintext form in the FIPS Approved mode.
Automated key transport methods must use FC_WrapKey and FC_UnwrapKey to input or output secret and
private keys to or from the module.
All cryptographic keys used in the FIPS Approved mode of operation must be generated in the FIPS Approved
mode or imported while running in the FIPS Approved mode.
9.2.2 RSA and DSA Keys
The module allows the use of 1024 bit RSA and DSA keys for legacy purposes, including signature generation.
As per SP800-131A, RSA and DSA shall be used with either 2048-bit, 3072-bit or 4096-bit keys (RSA only).
9.2.1 9.2.3 Triple-DES Keys
According to IG A.13, Triple-DES key shall not be used to encrypt more than 228
64-bit blocks of data.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
29 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
10 Mitigation of Other Attacks
The Module is designed to mitigate the following attacks.
Attack Mitigation Mechanism Specific Limit
Timing attacks on RSA RSA blinding
Timing attack on RSA was first
demonstrated by Paul Kocher in 1996
[15], who contributed the mitigation
code to our module. Most recently
Boneh and Brumley [16] showed that
RSA blinding is an effective defense
against timing attacks on RSA.
None
Cache-timing attacks on the
modular exponentiation
operation used in RSA and
DSA
Cache invariant modular
exponentiation
This is a variant of a modular
exponentiation implementation that
Colin Percival [17] showed to defend
against cache-timing attacks.
This mechanism requires intimate
knowledge of the cache line sizes of
the processor. The mechanism may be
ineffective when the module is running
on a processor whose cache line sizes
are unknown.
Arithmetic errors in RSA
signatures
Double-checking RSA signatures
Arithmetic errors in RSA signatures
might leak the private key. Ferguson
and Schneier [18] recommend that
every RSA signature generation should
verify the signature just generated.
None
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
30 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
11 Glossary and Abbreviations
AES Advanced Encryption Specification
AES-NI Intel® Advanced Encryption Standard New Instructions
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CMVP Cryptographic Module Validation Program
CSP Critical Security Parameter
CTR Counter
DES Data Encryption Standard
DRBG Deterministic Random Bit Generator
DSA Digital Signature Algorithm
ECB Electronic Code Book
ECDSA Elliptic Curve Digital Signature Algorithm
FIPS Federal Information Processing Standard
GCM Galois/Counter Mode
GPC General Purpose Computer
HMAC Hash Message Authentication Code
MAC Message Authentication Code
NIST National Institute of Science and Technology
OS Operating System
PKCS Public-Key Cryptography Standards
RNG Random Number Generator
RSA Rivest, Shamir, Addleman
SHA Secure Hash Algorithm
TLS Transport Layer Security
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
31 of 32
SUSE Linux Enterprise Server 12 - NSS Module v2.0 FIPS 140-2 Non-Proprietary Security Policy
12 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] FIPS 186-4 Digital Signature Standard (DSS), http://csrc.nist.gov/publications/PubsFIPS.html
[8] NIST SP 800-67 Revision 1, Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher,
http://csrc.nist.gov/publications/PubsFIPS.html
[9] NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation: Methods and Techniques,
http://csrc.nist.gov/publications/PubsFIPS.html
[10] NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM)
and GMAC, http://csrc.nist.gov/publications/PubsFIPS.html
[11] NIST SP 800-38F, Recommendation for Block Cipher Modes of Operation: Methods for key Wrapping,
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
[12] NIST SP 800-56A, Recommendation for Pair-Wise Key Establishment Schemes using Discrete Logarithm
Cryptography (Revised), http://csrc.nist.gov/publications/PubsFIPS.html
[13] NIST SP 800-90A, Recommendation for Random Number Generation Using Deterministic Random Bit
Generators, http://csrc.nist.gov/publications/PubsFIPS.html
[14] RSA Laboratories, “PKCS #11 v2.20: Cryptographic Token Interface Standard”, 2004.
http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pdf
[15] P. Kocher, "Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems," CRYPTO
'96, Lecture Notes In Computer Science, Vol. 1109, pp. 104-113, Springer-Verlag, 1996.
http://www.cryptography.com/timingattack/
[16] D. Boneh and D. Brumley, "Remote Timing Attacks are Practical,"
http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html
[17] C. Percival, "Cache Missing for Fun and Profit," http://www.daemonology.net/papers/htt.pdf
[18] N. Ferguson and B. Schneier, Practical Cryptography, Sec. 16.1.4 "Checking RSA Signatures", p. 286, Wiley
Publishing, Inc., 2003.
© 2018 SUSE LLC / atsec information security corporation
This document can be reproduced and distributed only whole and intact, including this copyright notice.
32 of 32