Security Policy

This is a draft document.

Security Policy

Authentication Policy

Strength of Authentication Mechanism

In FIPS mode, the NSS cryptographic module imposes the following requirements on the password.

• 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, ASCII uppercase letters, ASCII non-alphanumeric characters (such as space and punctuation marks), and non-ASCII characters. 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 probability that a random guess of the password will succeed, we assume that

• the characters of the password are independent with each other, and
• the probability of guessing an individual character of the password is < 1/10.

Since the password is >= 7 characters long, the probability that a random guess of the password will succeed is < (1/10)^7 = 1/10,000,000.

After each failed authentication attempt in FIPS mode, the NSS cryptographic 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 < 60 * 1/10,000,000 = 0.6 * (1/100,000).

Multiple Concurrent Operator Roles and Services

The NSS cryptographic module doesn't allow concurrent operators.

• For Security Level 1, the operating system has been restricted to a single operator mode of operation, so concurrent operators are explicitly excluded (FIPS 140-2 Sec. 4.6.1).
• On a multi-user operating system, this is enforced by making the NSS certificate and private key databases readable and writable by only the owner of the files.

FIPS 140-2 Implementation Guidance 6.1 clarifies the use of a cryptographic module on a server.

When a crypto 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.

Note: The NSS cryptographic module does allow concurrent processes with the same user identity to access the module, with the restriction that all the concurrent processes must open the NSS databases in read-only mode. Each process accessing the module needs to assume a role separately.

The NSS cryptographic module also allows a process to open multiple concurrent sessions (connections) with the module. When a session within a process assumes a role, all the concurrent sessions within the process assume that role (PKCS #11 v2.20, Sec. 11.4, C_Login).

Access Control Policy

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 to the CSPs.

Security-Relevant Information

The NSS cryptographic module employs the following cryptographic keys and CSPs in the FIPS Approved mode of operation.

• AES secret keys: The module supports 128-bit, 192-bit, and 256-bit AES keys. The keys may be stored in memory or in the private key database (key3.db).
• Triple DES secret keys: 168-bit. The keys may be stored in memory or in the private key database (key3.db).
• HMAC secret keys: HMAC key size must be greater than or equal to half the size of the hash function output. The keys may be stored in memory or in the private key database (key3.db).
• DSA public keys and private keys: The module supports DSA key sizes of 512-1024 bits. The keys may be stored in memory or in the private key database (key3.db).
• RSA public keys and private keys (used for digital signatures and key transport): The module supports RSA key sizes of 1024-8192 bits. The keys may be stored in memory or in the private key database (key3.db).
• EC public keys and private keys (used for ECDSA digital signatures and EC Diffie-Hellman key agreement): The module supports elliptic curve key sizes of 163-571 bits. (See the section "Non-NIST-Recommended Elliptic Curves" below.) The keys may be stored in memory or in the private key database (key3.db).
• Diffie-Hellman public keys and private keys (used for key agreement): The module supports Diffie-Hellman public key sizes of 1024-2236 bits. The keys may be stored in memory or in the private key database (key3.db).
• TLS premaster secret (used in deriving the TLS master secret): 48-byte. Stored in memory.
• TLS master secret (used in the generation of symmetric cipher keys, IVs, and MAC secrets for TLS): 48-byte. Stored in memory.
• seed key of the Approved random number generator: 256-bit. Stored in memory.
• authentication data (passwords): Stored in the private key database (key3.db).
• audited events and audit data (Security Level 2 only): Stored in the system audit logs.

Non-NIST-Recommended Elliptic Curves

The basic ECC version of the NSS cryptographic module only implements the NIST-Recommended elliptic curves P-256, P-384, and P-521 in FIPS 186-2.

The extended ECC version of the NSS cryptographic module implements all the NIST-Recommended elliptic curves and the following non-NIST-Recommended curves:

• ANSI X9.62 prime curves
  • prime192v2
  • prime192v3
  • prime239v1
  • prime239v2
  • prime239v3
• ANSI X9.62-1998 binary curves
  • c2pnb163v1
  • c2pnb163v2
  • c2pnb163v3
  • c2pnb176w1 (disallowed in ANSI X9.62-2005). Note: the NSS cryptographic module incorrectly named this curve c2pnb176v1.
  • c2tnb191v1
  • c2tnb191v2
  • c2tnb191v3
  • c2pnb208w1 (disallowed in ANSI X9.62-2005)
  • c2tnb239v1
  • c2tnb239v2
  • c2tnb239v3
  • c2pnb272w1 (disallowed in ANSI X9.62-2005)
  • c2pnb304w1 (disallowed in ANSI X9.62-2005)
  • c2tnb359v1
  • c2pnb368w1 (disallowed in ANSI X9.62-2005)
  • c2tnb431r1
• SEC 2 prime curves
  • secp112r1
  • secp112r2
  • secp128r1
  • secp128r2
  • secp160k1
  • secp160r1
  • secp160r2
  • secp192k1
  • secp224k1
  • secp256k1
• SEC 2 binary curves
  • sect113r1
  • sect113r2
  • sect131r1
  • sect131r2
  • sect163r1
  • sect193r1
  • sect193r2
  • sect239k1

Although FIPS 140-2 Implementation Guidance IG 1.6 allows the use of non-NIST-Recommended curves in the FIPS Approved mode of operation, we recommend that the non-NIST-Recommended curves not be used in the FIPS mode.

Specification of Services

The Crypto Officer role is assumed implicitly during installation or initialization of the module. The NSS User role is assumed explicitly by authenticating, or logging in, to the module. Some services require the user to assume the NSS User role. Other services do not impose any role requirement.

Each service is provided by a PKCS #11 function. The following table lists the defined services and correlates role, service type and type of access to security-relevant information. Access type is Read/Write/Zeroize.

Service Category	Role	Function Name	Description	CSPs Accessed	Access type, e.g. RWZ
FIPS 140-2 specific		FC_GetFunctionList	return the list of FIPS 140-2 functions	none	-
Module Initialization
	Crypto Officer	FC_InitToken	initializes or re-initializes a token	password and all keys	Z
	Crypto Officer	FC_InitPIN	initializes the normal user's password	password	W
General purpose		FC_Initialize	initializes the module library for the FIPS mode of operation. This function provides the power-up self-test service	none	-
		FC_Finalize	finalizes (shuts down) the module library	all keys	Z
		FC_GetInfo	obtains general information about the module library	none	-
Slot and token management		FC_GetSlotList	obtains a list of slots in the system	none	-
		FC_GetSlotInfo	obtains information about a particular slot	none	-
		FC_GetTokenInfo	obtains information about the token. This function provides the Show Status service.	none	-
		FC_GetMechansimList	obtains a list of mechanisms supported by a token	none	-
		FC_GetMechanismInfo	obtains information about a particular mechanism	none	-
	NSS User	FC_SetPIN	changes the password of the current user	password	RW
Session management		FC_OpenSession	opens a connection or "session" between an application and a particular token	none	-
		FC_CloseSession	closes a session	session's keys	Z
		FC_CloseAllSessions	closes all sessions with a token	all keys	Z
		FC_GetSessionInfo	obtains information about the session	none	-
		FC_GetOperationState	saves the state of the cryptographic operation in a session. This function is only implemented for message digest operations.	none	-
		FC_SetOperationState	restores the state of the cryptographic operation in a session. This function is only implemented for message digest operations.	none	-
	NSS User	FC_Login	logs into a token	password	R
	NSS User	FC_Logout	logs out from a token	none	-
Object management	NSS User	FC_CreateObject	creates an object	key	W
	NSS User	FC_CopyObject	creates a copy of an object	original key new key	R W
	NSS User	FC_DestroyObject	destroys an object	key	Z
	NSS User	FC_GetObjectSize	obtains the size of an object in bytes	key	R
	NSS User	FC_GetAttributeValue	obtains an attribute value of an object	key	R
	NSS User	FC_SetAttributeValue	modifies an attribute value of an object	key	W
	NSS User	FC_FindObjectsInit	initializes an object search operation	none	-
	NSS User	FC_FindObjects	continues an object search operation	keys matching the search criteria	R
	NSS User	FC_FindObjectsFinal	finishes an object search operation	none	-
Encryption and decryption	NSS User	FC_EncryptInit	initializes an encryption operation	encryption key	R
	NSS User	FC_Encrypt	encrypts single-part data	encryption key	R
	NSS User	FC_EncryptUpdate	continues a multiple-part encryption operation	encryption key	R
	NSS User	FC_EncryptFinal	finishes a multiple-part encryption operation	encryption key	R
	NSS User	FC_DecryptInit	initializes a decryption operation	decryption key	R
	NSS User	FC_Decrypt	decrypts single-part encrypted data	decryption key	R
	NSS User	FC_DecryptUpdate	continues a multiple-part decryption operation	decryption key	R
	NSS User	FC_DecryptFinal	finishes a multiple-part decryption operation	decryption key	R
Message digesting		FC_DigestInit	initializes a message-digesting operation	none	-
		FC_Digest	digests single-part data	none	-
		FC_DigestUpdate	continues a multiple-part digesting operation	none	-
	NSS User	FC_DigestKey	continues a multi-part message-digesting operation by digesting the value of a secret key as part of the data already digested	key	R
		FC_DigestFinal	finishes a multiple-part digesting operation	none	-
Signature and verification	NSS User	FC_SignInit	initializes a signature operation	signing/HMAC key	R
	NSS User	FC_Sign	signs single-part data	signing/HMAC key	R
	NSS User	FC_SignUpdate	continues a multiple-part signature operation	signing/HMAC key	R
	NSS User	FC_SignFinal	finishes a multiple-part signature operation	signing/HMAC key	R
	NSS User	FC_SignRecoverInit	initializes a signature operation, where the data can be recovered from the signature	RSA signing key	R
	NSS User	FC_SignRecover	signs single-part data, where the data can be recovered from the signature	RSA signing key	R
	NSS User	FC_VerifyInit	initializes a verification operation	verification/HMAC key	R
	NSS User	FC_Verify	verifies a signature on single-part data	verification/HMAC key	R
	NSS User	FC_VerifyUpdate	continues a multiple-part verification operation	verification/HMAC key	R
	NSS User	FC_VerifyFinal	finishes a multiple-part verification operation	verification/HMAC key	R
	NSS User	FC_VerifyRecoverInit	initializes a verification operation where the data is recovered from the signature	RSA verification key	R
	NSS User	FC_VerifyRecover	verifies a signature on single-part data, where the data is recovered from the signature	RSA verification key	R
Dual-function cryptographic operations	NSS User	FC_DigestEncryptUpdate	continues a multiple-part digesting and encryption operation	encryption key	R
	NSS User	FC_DecryptDigestUpdate	continues a multiple-part decryption and digesting operation	decryption key	R
	NSS User	FC_SignEncryptUpdate	continues a multiple-part signing and encryption operation	signing/HMAC key encryption key	R R
	NSS User	FC_DecryptVerifyUpdate	continues a multiple-part decryption and verify operation	decryption key verification/HMAC key	R R
Key management	NSS User	FC_GenerateKey	generates a secret key	key	W
	NSS User	FC_GenerateKeyPair	generates a public-key/private-key pair	key pair	W
	NSS User	FC_WrapKey	wraps (encrypts) a key	wrapping key key to be wrapped	R R
	NSS User	FC_UnwrapKey	unwraps (decrypts) a key	unwrapping key unwrapped key	R W
	NSS User	FC_DeriveKey	derives a key from a base key	base key derived key	R W
Random number generation		FC_SeedRandom	mixes in additional seed material to the random number generator	RNG seed key	RW
		FC_GenerateRandom	generates random data. Performs continuous random number generator test	RNG seed key	RW
Parallel function management		FC_GetFunctionStatus	a legacy function, which simply returns the value 0x00000051 (function not parallel)	none	-
		FC_CancelFunction	a legacy function, which simply returns the value 0x00000051 (function not parallel)	none	-

Mitigation of Other Attacks

The NSS cryptographic module is designed to mitigate the following attacks.

Other Attacks	Mitigation Mechanism	Specific Limitations
Timing attacks on RSA	RSA blinding Timing attack on RSA was first demonstrated by Paul Kocher in 1996[1], who contributed the mitigation code to our module. Most recently Boneh and Brumley[2] 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[3] 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.
Arithmetical errors in RSA signatures	Double-checking RSA signatures Arithmetical errors in RSA signatures might leak the private key. Ferguson and Schneier[4] recommend that every RSA signature generation should verify the signature just generated.	None.

Results of FIPS 140-2 Level 2 Validation of NSS Cryptographic Module 3.11.5

FIPS 140-2 Section	Description	Validation Level Obtained
1.0	Cryptographic Module Specification	2
2.0	Cryptographic Module Ports and Interfaces	2
3.0	Roles, Services, and Authentication	2
4.0	Finite State Model	2
5.0	Physical Security	2
6.0	Operational Enviroment	2
7.0	Cryptographic Key Management	2
8.0	EMI/EMC	2
9.0	Self-Tests	2
10.0	Design Assurance	2
11.0	Mitigation of Other Attacks	2
C	Cryptographic Module Security Policy	2

Platform List

• Level 1
  • Red Hat Enterprise Linux 4 x86
  • Windows XP Service Pack 2
  • 64-bit Solaris 10 AMD64
  • HP-UX B.11.11 PA-RISC
  • Mac OS X 10.4

• Level 2
  • Red Hat Enterprise Linux 4 x86_86
  • 64-bit Trusted Solaris 8 SPARC

References

[1] 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/)

[2] D. Boneh and D. Brumley, "Remote Timing Attacks are Practical," http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html.

[3] C. Percival, "Cache Missing for Fun and Profit," http://www.daemonology.net/papers/htt.pdf.

[4] N. Ferguson and B. Schneier, Practical Cryptography, Sec. 16.1.4 "Checking RSA Signatures", p. 286, Wiley Publishing, Inc., 2003.