Security Policy
This is a draft document.
Module Information
- Module name: NSS cryptographic module
- Module version: 3.11.5
- Vendor name: Red Hat and Sun Microsystems
- Document version: 1.1
- Document revision date: 2006-08-11
Specification of Security Policy
The NSS cryptographic module is a general-purpose cryptographic library. Its API is based on the industry standard PKCS #11 version 2.20. The following table specifies the security rules that each product using the NSS cryptographic module shall adhere to:
|
Rule |
Specification of the NSS Cryptographic Module Security Rules |
|---|---|
| 1 | The NSS cryptographic module shall consist of software libraries compiled for each supported platform. |
| 2 | The cryptographic module shall rely on the underlying operating system to ensure the integrity of the cryptographic module loaded into memory. |
| 3 | The cryptographic module shall support the NSS User Role and the Crypto Officer Role. |
| 4 | A cryptographic module user shall have access to ALL the services supplied by the cryptographic module. |
| 5 | Cryptographic module services shall consist of public services, which require no authentication, and private services, which require authentication. Public services (e.g., random number generation) do not require access to the secret and private keys and other CSPs associated with the user. |
| 6 | Public key certificates shall be stored in plaintext form because of their public nature and internal CA-signing integrity features. |
| 7 | (This rule is intentionally left blank.) |
| 8 | TLS master secrets (48-byte secrets shared between the peers in TLS connections) shall be extracted from the cryptographic module in encrypted form (the TLS session ID cache, which stores the encrypted TLS master secrets, shall be considered outside the boundary of the cryptographic module). |
| 9 | For the FIPS PUB 140-2 mode of operation, the cryptographic module shall enforce rules specific to FIPS PUB 140-2 requirements. |
| 10 | The FIPS PUB 140-2 cryptographic module shall not allow critical errors to compromise security. Whenever a critical error (e.g., a self-test failure) is encountered, the cryptographic module shall enter an error state and the library shall need to be reinitialized to resume normal operation. |
| 11 | Upon initialization of the FIPS PUB 140-2 cryptographic module library, the following power-up self-tests shall be performed:
|
| 12 | Shutting down and restarting the FIPS PUB 140-2 cryptographic module with the FC_Finalize and FC_Initialize functions shall execute the same power-up self-tests detailed above when initializing the module library for the FIPS PUB 140-2 mode. This allows a user to execute these power-up self-tests on demand as defined in Section 4.9.1 of FIPS PUB 140-2.
|
| 13 | The FIPS PUB 140-2 cryptographic module shall require the user to establish a password (for the NSS user role) in order for subsequent authentications to be enforced. |
| 14 | A known password check string, encrypted with a Triple-DES key derived from the password, shall be stored in the private key database (key3.db) in secondary storage. |
| 15 | Once a password has been established for the FIPS PUB 140-2 cryptographic module, it shall only allow the user to use the private services if and only if the user successfully authenticates to the FIPS PUB 140-2 cryptographic module. |
| 16 | In order to authenticate to the cryptographic module, the user shall enter the password, and the cryptographic module shall verify that the password is correct by
|
| 17 | The user's password shall act as the key material to encrypt/decrypt private key material. Note: password-encrypted secret and private keys should be considered in plaintext form in FIPS mode. |
| 18 | Secret and private keys, plaintext passwords, and other security-relevant data items shall be maintained under the control of the cryptographic module. Secret and private keys shall only be passed to higher level callers in encrypted (wrapped) form with FC_WrapKey. Note: if secret and private keys are passed to higher level callers in password-encrypted form, they should be considered in plaintext form in FIPS mode.
|
| 19 | All secret and private keys shall be stored in encrypted form (using a Triple-DES key derived from the password) in the private key database (key3.db) in secondary storage. Note: password-encrypted secret and private keys should be considered in plaintext form in FIPS mode. |
| 20 | (This rule is intentionally left blank.) |
| 21 | Once the FIPS PUB 140-2 mode of operation has been selected, the cryptographic module user shall only use the FIPS PUB 140-2 cipher suite. |
| 22 | The FIPS PUB 140-2 cipher suite shall consist solely of
Caveats:
|
| 23 | Once the FIPS PUB 140-2 mode of operation has been selected, Triple-DES/AES shall be limited in its use to perform encryption/decryption using either CBC or ECB mode. |
| 24 | Once the FIPS PUB 140-2 mode of operation has been selected, SHA-1, SHA-256, SHA-386, and SHA-512 shall be the only algorithms used to perform one-way hashes of data. |
| 25 | Once the FIPS PUB 140-2 mode of operation has been selected, RSA shall be limited in its use to generating and verifying PKCS #1 signatures, and to encrypting and decrypting key material for key exchange. |
| 26 | Once the FIPS PUB 140-2 mode of operation has been selected, DSA and ECDSA shall be used in addition to RSA to generate and verify signatures. |
| 27 | In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a pair-wise consistency test upon each invocation of RSA, DSA, and ECDSA key pair generation as defined in section 4.9.2 of FIPS PUB 140-2. |
| 28 | The cryptographic module shall perform its prime number generation and primality test via the mechanisms described in Appendix 2 of FIPS PUB 186-2. |
| 29 | The cryptographic module shall perform pseudorandom number generation via the mechanisms described in FIPS PUB 186-2 Change Notice 1. |
| 30 | The cryptographic module shall seed its pseudorandom number generation via invoking a noise generator specific to the platform on which it was implemented (e.g., Macintosh, UNIX, or Windows). Pseudorandom number generator shall be seeded with noise derived from the execution environment such that the noise is not predictable. |
| 31 | A product using the cryptographic module shall periodically reseed the module's pseudorandom number generator with unpredictable noise. |
| 32 | In the FIPS PUB 140-2 mode of operation, the cryptographic module shall perform a continuous random number generator test upon each invocation of the pseudorandom number generator as defined in section 4.9.2 of FIPS PUB 140-2. |
| 33 | The cryptographic module takes a number of explicit zeroization steps to clear the memory region previously occupied by a plaintext secret key, private key, or password. Any plaintext secret and private keys and passwords are zeroized once the use is complete. Upon exit from the FIPS PUB 140-2 mode of operation, all plaintext secret and private keys within the cryptographic module are zeroized by having their memory contents rewritten with zeroes. |
| 34 | The TLS pseudorandom function (PRF) is contained within the cryptographic module. |
| 35 | For operation in FIPS PUB 140-2 Security Level 2 mode, the machine shall be labeled in a tamper-evident manner. Labels are to be supplied by the vendor and placed by the user on the bottom right and left edges midway between the front and the back of the case. Before placing labels, clean the portion of the case where the labels will adhere with rubbing alcohol, and allow the case to dry. Apply the labels to the indicated locations, and allow labels to set for 24 hours. |
| 36 | The NSS cryptographic module consists of the following shared libraries/DLLs and the associated .chk files:
The NSS cryptographic module requires the Netscape Portable Runtime (NSPR), which consists of the following shared libraries/DLLs:
Step 1: Install the shared libraries/DLLs and the associated
Step 2: Use the $ chmod 0755 libsoftokn3.so libfreebl*3.so libplc4.so libplds4.so libnspr4.so The discretionary access control protects the binaries stored on disk from being tampered with. Step 3: Use the $ chmod 0644 libsoftokn3.chk libfreebl*3.chk Step 4: By default the NSS cryptographic module operates in the non-FIPS Approved mode, meaning that if an application calls the standard PKCS #11 function #include "prlink.h"
#include "cryptoki.h"
#include <assert.h>
#include <stdio.h>
/*
* An extension of the CK_C_INITIALIZE_ARGS structure for the
* NSS cryptographic module. The 'LibraryParameters' field is
* used to pass instance-specific information to the library
* (like where to find its config files, etc).
*/
typedef struct CK_C_INITIALIZE_ARGS_NSS {
CK_CREATEMUTEX CreateMutex;
CK_DESTROYMUTEX DestroyMutex;
CK_LOCKMUTEX LockMutex;
CK_UNLOCKMUTEX UnlockMutex;
CK_FLAGS flags;
CK_CHAR_PTR *LibraryParameters;
CK_VOID_PTR pReserved;
} CK_C_INITIALIZE_ARGS_NSS;
int main()
{
char *libname;
PRLibrary *lib;
CK_C_GetFunctionList pC_GetFunctionList;
CK_FUNCTION_LIST_PTR pFunctionList;
CK_RV rv;
CK_C_INITIALIZE_ARGS_NSS initArgs;
PRStatus status;
/* Get the platform-dependent library name of the NSS cryptographic module */
libname = PR_GetLibraryName(NULL, "softokn3");
assert(libname != NULL);
lib = PR_LoadLibrary(libname);
assert(lib != NULL);
PR_FreeLibraryName(libname);
pC_GetFunctionList = (CK_C_GetFunctionList) PR_FindFunctionSymbol(lib,
"FC_GetFunctionList");
assert(pC_GetFunctionList != NULL);
rv = (*pC_GetFunctionList)(&pFunctionList);
assert(rv == CKR_OK);
/* Call FC_Foo as pFunctionList->C_Foo */
initArgs.CreateMutex = NULL;
initArgs.DestroyMutex = NULL;
initArgs.LockMutex = NULL;
initArgs.UnlockMutex = NULL;
initArgs.flags = CKF_OS_LOCKING_OK;
initArgs.LibraryParameters = (CK_CHAR_PTR *)
"configdir='.' certPrefix='' keyPrefix='' secmod='secmod.db' flags= ";
initArgs.pReserved = NULL;
rv = pFunctionList->C_Initialize(&initArgs);
assert(rv == CKR_OK);
/* ... */
rv = pFunctionList->C_Finalize(NULL);
assert(rv == CKR_OK);
status = PR_UnloadLibrary(lib);
assert(status == PR_SUCCESS);
return 0;
}
To reiterate, the mode of operation of the NSS cryptographic module is determined by the second argument passed to the
|
Authentication Policy
Specification of Roles
The NSS cryptographic module supports two roles.
The NSS User Role provides access to all cryptographic and general purpose services (except those that perform an initialization function) and all keys stored in the database.
The Crypto Officer Role is supported for installation and initialization of the module. It is assumed implicitly by performing installation or by requesting initialization of the module.
The NSS cryptographic module does not have a Maintenance Role.
Role-based Authentication
The NSS cryptographic module uses role-based authentication to control access to the module. To perform sensitive services using the cryptographic module, an operator must explicitly request to assume the NSS User role by logging into the module, and perform an authentication procedure using information unique to that operator (individual password). The password is initialized by the crypto officer as part of module initialization. Role-based authentication is used to safeguard a user's private key information. However, Discretionary Access Control (DAC) is used to safeguard all other NSS User information (e.g., the public key certificate database).
Authentication shall always be required upon initializing the NSS cryptographic module in the FIPS mode. If a function that requires authentication is called before the NSS User is authenticated, it returns the CKR_USER_NOT_LOGGED_IN error code. Call the FC_Login function to provide the required authentication.
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 by invoking any installation or initialization service. For all other services the NSS User role needs to be explicitly assumed.
Routines have been specified for each service and denoted whether or not they are public, meaning that the user doesn't need to authenticate to the module to use the routine, or NSS User, meaning that the user needs to login to the module to use the routine. The following table lists the defined services and correlates role, service type and access to security-relavant information.
|
Service Category |
Role |
Function Name |
Description |
CSPs |
Access
type, |
|
FIPS 140-2 specific |
User |
FC_GetFunctionList |
return the list of FIPS 140-2 functions |
- |
|
|
Installation and |
Crypto officer |
FC_Initialize |
initializes Cryptoki. This function provides the Power Up self-test service |
R |
|
|
FC_InitToken |
initializes a token |
R |
|||
|
FC_InitPIN |
initializes the normal user's PIN |
W |
|||
|
General |
User |
FC_Initialize |
initializes Cryptoki. This function provides the Power Up self-test service |
R |
|
|
FC_Finalize |
finalizes Cryptoki |
- |
|||
|
FC_GetInfo |
obtains general information about Cryptoki |
- |
|||
|
Slot
and |
User |
FC_GetSlotList |
obtains a list of slots in the system- |
- |
|
|
FC_GetSlotInfo |
obtains information about a particular slot |
- |
|||
|
FC_GetTokenInfo |
obtains information about the token. This function provides the Show Status service |
- |
|||
|
FC_GetMechansimList |
obtains a list of mechanisms supported by a token |
- |
|||
|
FC_GetMechanismInfo |
obtains information about a particular mechanism |
- |
|||
|
FC_InitToken |
initializes a token |
R |
|||
|
FC_SetPIN |
modifies the PIN of the current user |
RW |
|||
|
Session management |
User |
FC_OpenSession |
opens a connection or "session" between an application and a particular token |
- |
|
|
FC_CloseSession |
closes a session |
- |
|||
|
FC_CloseAllSessions |
closes all sessions with a token |
- |
|||
|
FC_GetSessionInfo |
obtains information about the session |
- |
|||
|
FC_GetOperationState |
saves the state of the cryptographic operation in a session |
- |
|||
|
FC_SetOperationState |
restores the state of the cryptographic operation in a session |
- |
|||
|
FC_Login |
logs into a token |
R |
|||
|
FC_Logout |
logs out from a token |
- |
|||
|
Object |
User |
FC_CreateObject |
creates an object |
- |
|
|
FC_CopyObject |
creates a copy of an object |
- |
|||
|
FC_DestroyObject |
destroys an object |
- |
|||
|
FC_GetObjectSize |
obtains the size of an object in bytes |
- |
|||
|
FC_GetAttributeValue |
obtains an attribute value of an object |
- |
|||
|
FC_SetAttributeValue |
modifies an attribute value of an object |
- |
|||
|
FC_FindObjectsInit |
initializes an object search operation |
- |
|||
|
FC_FindObjects |
continues an object search operation |
- |
|||
|
FC_FindObjectsFinal |
finishes an object search operation |
- |
|||
|
Encryption
and |
FC_EncryptInit |
initializes an encryption operation |
R |
||
|
FC_Encrypt |
encrypts single-part data |
R |
|||
|
FC_EncryptUpdate |
continues a multiple-part encryption operation |
R |
|||
|
FC_EncryptFinal |
finishes a multiple-part encryption operation |
R |
|||
|
FC_DecryptInit |
initializes a decryption operation |
R |
|||
|
FC_Decrypt |
decrypts single-part encrypted data |
R |
|||
|
FC_DecryptUpdate |
continues a multiple-part decryption operation |
R |
|||
|
FC_DecryptFinal |
finishes a multiple-part decryption operation |
R |
|||
|
Message |
User |
FC_DigestInit |
initializes a message-digesting operation |
R |
|
|
FC_Digest |
digests single-part data |
R |
|||
|
FC_DigestUpdate |
continues a multiple-part digesting operation |
R |
|||
|
FC_DigestKey |
continues a multi-part message-digesting operation by digesting the value of a secret key as part of the data already digested |
R |
|||
|
FC_DigestFinal |
finishes a multiple-part digesting operation |
R |
|||
|
Signature
and |
User |
FC_SignInit |
initializes a signature operation |
R |
|
|
FC_Sign |
signs single-part data |
R |
|||
|
FC_SignUpdate |
continues a multiple-part signature operation |
R |
|||
|
FC_SignFinal |
finishes a multiple-part signature operation |
R |
|||
|
FC_SignRecoverInit |
initializes a signature operation, where the data can be recovered from the signature |
R |
|||
|
FC_SignRecover |
signs single-part data, where the data can be recovered from the signature |
R |
|||
|
FC_VerifyInit |
initializes a verification operation |
R |
|||
|
FC_Verify |
verifies a signature on single-part data |
R |
|||
|
FC_VerifyUpdate |
continues a multiple-part verification operation |
R |
|||
|
FC_VerifyFinal |
finishes a multiple-part verification operation |
R |
|||
|
FC_VerifyRecoverInit |
initializes a verification operation where the data is recovered from the signature |
R |
|||
|
FC_VerifyRecover |
verifies a signature on single-part data, where the data is recovered from the signature |
R |
|||
|
Dual-function |
User |
FC_DigestEncryptUpdate |
continues a multiple-part digesting and encryption operation |
R |
|
|
FC_DecryptDigestUpdate |
continues a multiple-part decryption and digesting operation |
R |
|||
|
FC_SignEncryptUpdate |
continues a multiple-part signing and encryption operation |
R |
|||
|
FC_DecryptVerifyUpdate |
continues a multiple-part decryption and verify operation |
R |
|||
|
Key |
User |
FC_GenerateKey |
generates a secret key |
W |
|
|
FC_GenerateKeyPair |
generates a public-key/private-key pair |
W |
|||
|
FC_WrapKey |
wraps (encrypts) a key |
R |
|||
|
FC_UnwrapKey |
unwraps (decrypts) a key |
W |
|||
|
FC_DeriveKey |
derives a key from a base key |
RW |
|||
|
Random
number |
User |
FC_SeedRandom |
mixes in additional seed material to the random number generator |
W |
|
|
FC_GenerateRandom |
generates random data. Performs continuous random number generator test |
R |
|||
|
Function management |
User |
FC_GetFunctionStatus |
obtains updated status of a function running in parallel with the application |
- |
|
|
FC_CancelFunction |
cancels a function running in parallel with the application |
- |
|||
|
Callbacks |
User |
Notify |
processes notifications from Cryptoki |
- |
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.