Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

• One way hashes based on strong cryptography,(hash must be of the entire PAN)

• Truncation (hashing cannot be used to replace the truncated segment of PAN)

• Index tokens and pads (pads must be securely stored)

• Strong cryptography with associated key management processes and procedures

The MINIMUM account information that must be rendered unreadable is the PAN.

How SAKA meets this requirement: SAKA does not generate message digests, but supports Hashed Message Authentication Codes (HMAC) to internally create unique identifiers. HMACs require symmetric cryptographic keys; these keys are generated and managed automatically by the appliance. SAKA generates HMACs based on the HmacSHA256, HmacSHA384, and HmacSHA512 algorithms.

Applications may choose to use the HMAC or a Psuedo-Number (PSN)—a substituted value which resembles a PAN—for the HMAC through Tokenization. Using the PSN as a token, applications can be effectively taken out of PCI DSS scope for encryption and key management controls, since all keys and PAN are stored only in SAKA; neither the keys nor the sensitive data are stored on the client application.

PCI DSS Requirement 3.4.1

If disk encryption is used (rather than file- or column-level database encryption), logical access must be managed separately and independently of native operating system authentication and access control mechanisms (for example, by not using local user account databases or general network login credentials). Decryption keys must not be associated with user accounts.

How SAKA meets this requirement: SAKA does not support disk-based, file-, and/or column-level database encryption. SAKA currently supports only application-level encryption through its exposed web services, thus minimizing the “attack surface” of the application.

Disk encryption (encryption performed at the disk drive layer either by an operating system driver supplied by the disk drive manufacturer, or by the firmware on the disk drive controller) can, potentially, mitigate risks associated with stolen or lost computing devices containing sensitive data. However, disk encryption cannot protect a company from online attacks on a system that is powered up and operational.

This is because, once a user has legitimately authenticated themselves to the machine's drive encryption software (even with a separate password or PIN), all data blocks are automatically decrypted by the cryptographic software—regardless which application, running under the authenticated user's ID, requests the data. Thus, if an attacker managed to execute malware on the machine, because the user is already authenticated to the drive, the malware will be able to read data much as the legitimate user would.

Additionally, encrypting in the disk drive—which is the lowest layer of an application's technology stack—leaves all layers above the disk drive vulnerable to snooping by attackers. Given the complexity of today's applications, there are potentially numerous opportunities for attackers to snoop unencrypted data on a compromised machine.

While disk drive encryption has some short term risk mitigation properties, StrongKey believes that the strongest long term data protection comes from encrypting and decrypting data within the application layer by the application itself. In this paradigm, data is protected no matter what the storage media, no matter which network the data traverses, and no matter how many software layers intervene between the application and storage media.