3.6.1—Generation of strong cryptographic keys.

How SAKA meets this requirement: SAKA generates DEKs using content from FIPS-certified HSM or TPM, both of which provide a true Random Number Generator (RNG) as a product feature. SAKA only generates 128-, 192-, and 256-bit AES, and 256-bit EC keys.

3.5.1—Additional requirement for service providers only: Maintain a documented description of the cryptographic architecture that includes:

• Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date

• Description of the key usage for each key

• Inventory of any HSMs and other SCDs used for key management

HowSAKA meets this requirement: StrongKey is not a service provider. However, it does provide an appliance—SAKA—whose primary function is to protect cardholder data (CHD) using cryptography. As such, this response provides information about the SAKA and its elements related to cryptography.

SAKA uses a hardware-based cryptographic module to protect all cryptographic keys generated and used within the appliance. SAKA uses either a FIPS 140-2 Level 2 TPM or a FIPS 140-2 Level 3 certified HSM. While there are many differences between these two types of devices, they deliver similar benefits for some key management functions. SAKA leverages those specific functions, and can thus deliver identical cryptographic services regardless of the type of cryptographic hardware used in the appliance.

On machines using the TPM, the SAKA appliance generates a single 256-bit EC asymmetric key pair—known as the Storage Root Key (SRK) in TPM terminology—within the TPM during its initialization. The SRK is stored inside the TPM, never leaves the TPM, and is used to encrypt other objects—usually cryptographic keys. All such encrypted objects are stored on the hard disk and must be brought inside the TPM—with the proper authorization—to be decrypted. The software libraries interacting with the TPM handle this and shield applications from such details. Your applications only interact with the web services provided by SAKA and are further shielded from these mechanical details.

On machines using the HSM, the SAKA appliance generates a single 256-bit EC asymmetric key pair—the HSM Root Key (HRK)—within the HSM during its initialization. The HRK is stored inside the HSM, but unlike the TPM, can leave the HSM when encrypted. This feature is used to clone the key from the Primary SAKA server to other SAKA appliances at a site. The HRK is used to encrypt other objects—usually cryptographic keys. All such encrypted objects are stored on the hard disk and must be brought inside the HSM—with the proper authorization—to be decrypted. The software libraries interacting with the HSM handle such details.

SAKA supports the management of different encryption policies through the use of encryption domains. An encryption domain is a logical collection of keys, policies, users, and encrypted data, all of which are protected under a unique encryption domain key (EDK) to encrypt all symmetric keys. The EDK is a 256-bit EC key protected by the SRK/HRK.

SAKA appliances require three (3) KCs to be present to activate the TPM/HSM each time the appliance is restarted. This ensures that if the appliance is ever stolen, the attacker will never find anything on the appliance that can compromise the hardware module.

SAKA uses the following symmetric encryption keys:

• Data encryption keys—AES cryptographic keys with a default size of 256 bits. These are the keys that protect CHD. The default key usage period is one month; new keys are generated each month—on the first encryption request for the month—and used until midnight of the last day of the month. These keys are rotated once a year.

• Data HMAC keys—256-bit cryptographic keys used to generate hashed message authentication codes of unencrypted data. SAKA uses HMAC keys to determine the integrity of sensitive data before and after a cryptographic operation. Data HMAC keys are generated on the first encryption request for the year and used until midnight of the last day of the calendar year. These keys are rotated every year.

• Password HMAC keys—256-bit cryptographic keys used to generate HMACs of passwords for application service credentials calling cryptographic services in SAKA. These are never rotated, since passwords for service applications may be changed at will by SAKA Administrators.

All three symmetric key types defined above are encrypted under the EDK.

3.5.2—Restrict access to cryptographic keys to the fewest number of custodians necessary.

How SAKA meets this requirement: SAKA uses a sophisticated “Chain of Control” mechanism, allowing KCs to be divorced from the generation, transport, and access of the DEK. Domain Administrators establish policies that direct which users can request encryption, decryption, or both services—and can exclude Key Custodians from gaining access to DEKs.

Once a SAKA server is installed, all DEKs generated and accessed by applications are managed directly by SAKA and do not require the involvement of KCs. The custodians are required only to activate the cryptographic hardware module when the SAKA service must be started after a system reboot, or when a new encryption domain must be created.

3.5.3—Store secret and private keys used to encrypt/decrypt CHD in one (or more) of the following forms at all times:

• Encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, and is stored separately from the data-encrypting key

• Within a secure cryptographic device (such as a host HSM) or PTS-approved point-of-interaction device)

• As at least two full-length key components or key shares, in accordance with an industry-accepted method

How SAKA meets this requirement: SAKA generates and stores ALL DEKs centrally, and “escrows” them encrypted under the encryption domain's 256-bit EC key. The encryption domain's EC keys are ultimately encrypted by another 256-bit EC key pair generated and stored on a hardware cryptographic module to protect against tampering or unauthorized access. With the exception of the keys inside the hardware module, all keys are replicated to failover SAKA appliances securely.

3.5.4—Store cryptographic keys in the fewest possible locations.

How SAKA meets this requirement: SAKA only stores keys internally within itself and other SAKA nodes. No keys are ever transported to requesting applications. Thus, only SAKA appliances actually have the cryptographic keys that manage the encryption/decryption of PANs.