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.6.2—Secure cryptographic key distribution.

How SAKA meets this requirement: SAKA does not hand out cryptographic keys to any requesting application. All keys are generated, stored, and used within the appliance and only replicated to another appliance over a trusted network. However, even if the encrypted keys fall into the wrong hands, without the cryptographic hardware module, it is computationally infeasible to decrypt them, since the Root 2048-bit key that can decrypt the chain is unavailable outside the cryptographic hardware module.

3.6.3—Secure cryptographic key storage.

How SAKA meets this requirement: SAKA's use of the “Chain of Control” concept allows DEKs to be treated like ordinary files on the operating system, or like records within a database. However, because DEKs are always encrypted under an encryption domain's key, and because the private key (which can decrypt the encrypted keys) of the Root key is stored inside cryptographic hardware modules (which in turn are protected by multiple KCs), access to the decrypted DEK is non-trivial to very difficult for unauthorized entities.

The standard use of approved cryptographic hardware modules in SAKA ensures that in the event the hardware module detects attacks, the modules can either lock up (requiring a Security Officer to reset the module), zero out (erase) key material inside the keystore, and/or introduce increasing delays in responses when subjected to dictionary and/or rainbow table attacks.

3.6.4—Cryptographic key changes for keys that have reached the end of their crypto-period (for example, after a defined period of time has passed, and/or after a certain amount of ciphertext has been produced by a given key), as defined by the associated application vendor or key owner, and based on industry best practices and guidelines (for example, NIST Special Publication 800-57).

How SAKA meets this requirement: SAKA includes the ability to automatically rotate DEKs without shutting down cryptographic services or applications that rely on them. Since keys never leave SAKA, and applications store a “token” to uniquely identify a PAN, SAKA can rotate keys at will or periodically without changing the token, thus isolating applications from this housekeeping duty.

3.6.5—Retirement or replacement (for example, archiving, destruction, and/or revocation) of keys as deemed necessary when the integrity of the key has been weakened (for example, departure of an employee with knowledge of a cleartext key component), or keys are suspected of being compromised.

How SAKA meets this requirement: Using the same methodology described in the earlier section (for key rollover), SAKA can be used to replace compromised DEKs. DEKs can also be rotated at will at any time without affecting the applications.

The SAKA also provides software “jobs” to delete encrypted PANs when they are past their data retention period (which is customizable). Once all encrypted PANs are deleted from the SAKA, site personnel have the ability to delete DEKs from the SAKA appliance.

3.6.6—If manual cleartext cryptographic key management operations are used, these operations must be managed using split knowledge and dual control.

How SAKA meets this requirement: SAKA meets this requirement through its “Chain of Control” concept. The SAKA installation requires a minimum of three KCs who are issued strong credentials (256-bit EC key pairs) used to digitally sign commands activating the cryptographic hardware module within SAKA. Until all KCs activate the cryptographic hardware module, the cryptographic services will not be enabled even if the database and application server are running.

3.6.7—prevention of unauthorized substitution of cryptographic keys.

How SAKA meets this requirement: SAKA automatically generates, encrypts, and manages all DEKs. To substitute DEKs inside the SAKA, attackers must not only compromise operating system and database security, but must also compromise the cryptographic hardware module to access its key pair, then encrypt the DEK and substitute it in the database. While there is no such things as perfect security, this degree of compromise requires a significant level of access to the SAKA appliance that is normally detected though other PCI DSS controls.

3.6.8—Requirement for cryptographic KCs to formally acknowledge that they understand and accept their responsibilities.

How SAKA meets this requirement: This is a procedural requirement addressed outside the realm of technology.