3.1.2— Roles and responsibilities for performing activities in Requirement 3 are documented, assigned, and understood.

How SAKA meets this requirement: With respect to StrongKey Tellaro appliance which holds CHD, StrongKey has defined roles explicitly to separate capabilities such as key custodians, domain admins, service credentials, etc. This allows for independent management by customers within their documentation.

3.2.1— Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following:

• Coverage for all locations of stored account data.

• Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization.

• Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements.

• Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification.

• Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy.

• A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable.

HowSAKA meets this requirement: The StrongKey Tellaro encrypts and stores whatever data is sent by the customer into the appliance. It is therefore the end user/customer’s responsibility to store only what is approved by PCI-DSS 4.0.1.

3.3.1— SAD is not stored after authorization, even if encrypted. All sensitive authentication data received is rendered unrecoverable upon completion of the authorization process.

How SAKA meets this requirement: The StrongKey Tellaro encrypts and stores whatever data is sent by the customer into the appliance. It is therefore the end user/customer’s responsibility to store only what is approved by PCI-DSS 4.0.1.

3.3.2— SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

How SAKA meets this requirement: The StrongKey Tellaro encrypts and stores whatever data is sent by the customer into the appliance. It is therefore the end user/customer’s responsibility to store only what is approved by PCI-DSS 4.0.1.

3.5.1 and 3.5.1.1— PAN is rendered unreadable anywhere it is stored by using any of the following approaches:

• One-way hashes based on strong cryptography of the entire PAN.

• Truncation (hashing cannot be used to replace the truncated segment of PAN). – If hashed and truncated versions of the same PAN, or different truncation formats of the same PAN, are present in an environment, additional controls are in place such that the different versions cannot be correlated to reconstruct the original PAN.

• Index tokens.

• Strong cryptography with associated key-management processes and procedures.

HowSAKA meets this requirement: When the PAN or any other sensitive data is stored in the StrongKey Tellaro appliance, two different cryptographic operations render it unreadable:

• Encryption with AES-256 symmetric encryption keys where the entire PAN (or sensitive data) is encrypted;
• Hashed message authentication code (HMAC) generation with a 256-bit HMAC key where the entire PAN (or sensitive data) is HMAC’d.

Both cryptographic keys are protected with strong key-management controls including FIPS 140-2 certified cryptographic hardware supported by FIPS 140-2 certified cryptographic software libraries.

3.5.1.2 and 3.5.1.3— If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:

• On removable electronic media

• If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.

HowSAKA meets this requirement: Tellaro does not support disk-based, file-, and/or column-level database encryption. Tellaro 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 of which application, running under the authenticated user's ID, requests the data. Thus, if an attacker managed to execute malware on the machine masquerading with an authorized user’s credentials, 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 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.

3.6.1— Procedures are defined and implemented to protect cryptographic keys used to protect stored account data against disclosure and misuse that include:

• Access to keys is restricted to the fewest number of custodians necessary.

• Key-encrypting keys are at least as strong as the data-encrypting keys they protect.

• Key-encrypting keys are stored separately from data-encrypting keys.

• Keys are stored securely in the fewest possible locations and forms.

HowSAKA meets this requirement: These are some of the protection mechanisms used by the Tellaro to protect cryptographic keys:

• Strong cryptographic algorithms: the Advanced Encryption System (AES)

• Large key sizes for Data Encryption Keys (DEK): 128‒256-bit AES, with the default being 256-bit keys

• Large key sizes for Key Encryption Keys (KEK) that encrypt DEKs, with the default being 256-bit EC keys

• Federal Information Processing Standard (FIPS) 140-2 Level 3 certified Hardware Security Modules (HSM)

• Federal Information Processing Standard (FIPS) 140-2 Level 2 certified Trusted Platform Modules (TPM) and Digitally signed and encrypted messages over the network for Key Custodians (KCs) and encryption Domain Administrators

While the security of any environment depends on more than just technology, Tellaro provides significant levels of integration in hardware, software, and cryptographic components towards protecting keys from disclosure and misuse.

Tellaro uses a sophisticated “Chain of Control” mechanism, allowing Key Custodians (KC) to be divorced from the generation, transport, and access of the DEK. Domain Administrators (DA) 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 Tellaro server is installed, all DEKs generated and accessed by applications are managed directly by Tellaro and do not require the involvement of KCs or the DA. The custodians are required only to activate the cryptographic hardware module when the Tellaro service must be started after a system reboot, or when a new encryption domain must be created.

3.6.1.1— Additional requirement for service providers only: A documented description of the cryptographic architecture is maintained that includes:

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

• Preventing the use of the same cryptographic keys in production and test environments.

• Description of the key usage for each key.

• Inventory of any hardware security modules (HSMs), key management systems (KMS), and other secure cryptographic devices (SCDs) used for key management, including type and location of devices, to support meeting Requirement 12.3.4

HowSAKA meets this requirement: Although StrongKey does not qualify as a Service Provider based on the PCI DSS definition, the below information might be helpful to auditors:

Tellaro uses a hardware-based cryptographic module to protect all cryptographic keys generated and used within the appliance. Tellaro 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. Tellaro 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 Tellaro 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 Tellaro and are further shielded from these mechanical details.

On machines using the HSM, the Tellaro 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 Tellaro server to other Tellaro 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.

Tellaro 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.

Tellaro 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. Tellaro uses the following symmetric encryption keys:

• Data HMAC 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.

• Password HMAC keys — 256-bit cryptographic keys used to generate hashed message authentication codes of unencrypted data. Tellaro 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.

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

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

3.6.1.2— Secret and private keys used to protect stored account data are stored in one (or more) of the following forms at all times:

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

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

• Within a secure cryptographic device (SCD), such as a hardware security module (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.

HowSAKA meets this requirement: Tellaro generates and stores ALL Data Encryption Keys (DEK) internally, and “escrows” them encrypted under the encryption domain's 256-bit EC key. The encryption domain's EC keys are, further, encrypted by a second 256-bit EC key-pair, generated and stored on a FIPS 140-2 certified cryptographic hardware module to protect against tampering or unauthorized access.

3.6.1.3— Access to cleartext cryptographic key components is restricted to the fewest number of custodians necessary.

How SAKA meets this requirement: The Tellaro does NOT expose cleartext cryptographic keys to anybody. Key Custodians (KC) are only responsible for activating the cryptographic hardware module, which when activated, can decrypt all other cryptographic keys used within the encryption domain. As such, while KC and the DA have administrtive control over the appliance, the Tellaro does not enable cleartext access to any cryptographic key.

3.6.1.4— Cryptographic keys are stored in the fewest possible locations.

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

3.7.1— Key-management policies and procedures are implemented to include generation of strong cryptographic keys used to protect stored account data

How SAKA meets this requirement: Tellaro generates DEKs using content from FIPS-certified HSM or TPM, both of which provide a true Random Number Generator (TRNG) as a product feature. While it is possible for the Tellaro to be configured to use a Pseudo Random Number Generator (PRNG), Tellaro seeds the PRNG with random data generated by the TRNG. Tellaro only generates 128-, 192-, and 256-bit AES, and 256-bit EC keys.

3.7.2— Key-management policies and procedures are implemented to include secure distribution of cryptographic keys used to protect stored account data.

How SAKA meets this requirement: Tellaro 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 using an encrypted channel. 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 256-bit EC key that can decrypt the chain is unavailable outside the cryptographic hardware module.

3.7.3— Key-management policies and procedures are implemented to include secure storage of cryptographic keys used to protect stored account data

How SAKA meets this requirement: Tellaro'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 Tellaro 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.7.4 and 3.7.5— Key management policies and procedures are implemented for cryptographic key changes for keys that have reached the end of their cryptoperiod, as defined by the associated application vendor or key owner, and based on industry best practices and guidelines, including the following:

• A defined cryptoperiod for each key type in use.

• A process for key changes at the end of the defined cryptoperiod.

Key management policies procedures are implemented to include the retirement, replacement, or destruction of keys used to protect stored account data, as deemed necessary when:

• The key has reached the end of its defined cryptoperiod.

• The integrity of the key has been weakened, including when personnel with knowledge of a cleartext key component leaves the company, or the role for which the key component was known.

• The key is suspected of or known to be compromised. Retired or replaced keys are not used for encryption operations.

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

Cryptographic domain key-pairs and the root cryptographic key-pair of the appliance within the FIPS certified cryptographic hardware module are rotated, on average, once every five (5) years. When extended warranty is in place, these keys are available only for an additional two (2) years.

3.7.6— Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented, including managing these operations using split knowledge and dual control.

How SAKA meets this requirement: Tellaro meets this requirement through its “Chain of Control” concept. The Tellaro installation requires a minimum of three (3) KCs who are issued strong credentials (256-bit EC key pairs) used to digitally sign commands activating the cryptographic hardware module within the Tellaro. 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.7.7— Key management policies and procedures are implemented to include the prevention of unauthorized substitution of cryptographic keys.

How SAKA meets this requirement: The Tellaro appliance automatically generates, encrypts, and manages all DEKs; the installation procedure - in the presence of KCs - generates the root key-pair in the FIPS certified cryptographic hardware module. Encryption domain keys (EDK) are generated by KCs when a new cryptographic domain is created for a business purpose. None of these keys are visible as cleartext to anyone, at any time.

To substitute DEKs inside the Tellaro, 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 Tellaro appliance that is normally detected though other PCI DSS controls.

3.7.8— Key management policies and procedures are implemented to include that cryptographic key custodians formally acknowledge (in writing or electronically) that they understand and accept their key-custodian responsibilities.

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

3.7.9— Additional requirement for service providers only: Where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage and updating of such keys is documented and distributed to the service provider’s customers.

How SAKA meets this requirement: StrongKey is not a service provider, and cryptographic keys are not transmitted outside of the Tellaro appliance

Injection flaws, particularly SQL injection; also consider Lightweight Directory Access Protocol (LDAP) and Xpath injection flaws as well as other injection flaws

The SAKA servlet does not use Structured Query Language (SQL) to communicate with its internal database (IDB)—it uses Enterprise Java Beans (EJB), which in turn use Java Persistence API (JPA) to interact with the IDB. As a result, SQL injection attacks do not work on the SAKA messaging protocol.

Buffer overflows

Buffer overflows are a characteristic of programming languages that do not automatically check the size of data being written to the address of a variable. SAKA is written in 100% Java, which was designed with strong typing and protection from buffer overflows in the Java Virtual Machine (JVM). As a result, SAKA does not succumb to buffer overflow attacks; any attempt to write data larger than the size of the type allocated for a variable results in an Exception from the JVM, thus protecting the application.

Insecure cryptographic storage

The SAKA appliance uses either a FIPS 140-2 Level 3 certified, or a CC EAL4+ certified cryptographic hardware module to store the root key of the SAKA key hierarchy. All keys under the root key are encrypted when stored on the hard disk of the appliance.

Insecure communications

The SAKA appliances generates its own Transport Layer Security (TLS) certificates for secure communication with clients. Not only does this provide message confidentiality and integrity on the network, but it has the added benefit that computers that do not know of the SAKA's TLS certificate will receive error messages when communicating with the appliance.

Furthermore, the SAKA can be equipped to use TLS client authentication so that client systems must also possess an X509 digital certificate when communicating with SAKA. However, the client and appliance's TLS certificates must come from a Public Key Infrastructure (PKI) to enable this level of security.

Improper Error Handling

The SAKA appliance logs all application level errors with a unique Error ID (EID) and message. Additionally, errors received at the operating system, database, and/or application server are logged by each component individually, thus allowing customer sites to tailor their Security Incident Event Management (SIEM) tools to handle errors appropriately.

All “high risk” vulnerabilities identified in the vulnerability identification process (as defined in PCI DSS Requirement 6.1, above)

SAKA protects from such vulnerabilities by updating components used in the appliance software when vulnerabilities are discovered and/or made public by their manufacturers. It is noteworthy to mention that SAKA has strong controls by default. The built-in SAKA firewall restricts access to the web service port only for internal IP addresses on which authorized applications call for cryptographic services. The SAKA servers neither require, nor are enabled by StrongKey customers to have internet access.

Cross-site scripting (XSS)

SAKA does not use Representational State Transfer (REST)-based messages or HTML (typically used to carry out cross-site scripting attacks) between client applications and the appliance; it only uses Simple Object Access Protocol (SOAP)-based messages, and accepts and returns only XML. As such, the SAKA appliance is, in theory, immune to XSS attacks.

Improper access control (such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions)

The SAKA appliance does not return any internal object references. The design of the appliance's key management software forces a separation of the web tier (servicing web service requests) from the EJB tier which processes the request. All objects passed/returned between the web and EJB tiers are passed by value—not as references.

SAKA uses a single URL to provide all services from the appliance. The URL only accepts SOAP messages and neither redirects the calling application to any other URL nor displays any HTML. As such, the use of any other URL on the SAKA appliance results in an error message to the caller.

Cross-site request forgery (CSRF)

Just as SAKA avoids falling prey to XSS attacks through the use of SOAP-based calls and XML objects (as opposed to REST-based calls and HTML), it similarly avoids falling prey to CSRF attacks.

Broken authentication and session management

The SAKA appliance does not maintain sessions. All requests to the appliance must specify authentication credentials, and each request is authenticated independent of another.