Continuing our series on PCI Encryption basics, we delve into the supporting systems that make encryption work. Key management and access controls are important building blocks, and subject to audit to ensure compliance with the Data Security Standard.

Key Management

Key management considerations for PCI are pretty much the same as for any secure deployment: you need to protect encryption keys from unauthorized physical and logical access. And to the extent it’s possible, prevent misuse. Those are the basics things you really need to get right so they are our focus here. As per our introduction, we will avoid talking about ISO specifications, key bit lengths, key generation, and distribution requirements, because quite frankly you should not care. More precisely you should not need to care because you pay commercial vendors to get these details right. Since PCI is what drives their sales most of their products have evolved to meet PCI requirements.

What you want to consider is how the key management system fits within your organization and works with your systems. There are three basic deployment models for key management services; external software, external hardware or HSM, and embedded within the application or database.

• External Hardware: Commonly called Hardware Security Modules, or HSMs, these devices provide extraordinary physical security, and most are custom-designed to provide strong logical security as well. Most have undergone rigorous certifications, the details of which the vendors are happy to share with you because they take a lot of time and money to pass. HSMs offer very good performance and take care of key synchronization and distribution automatically. The downside is cost – this is by far the most expensive key management option. And for disaster recovery planning and failover, you’re not just buying one of these devices, but several. They don’t work as well with virtual environments as software. We have received a handful of customer complaints that the APIs were difficult to use when integrating with custom applications, but this concern is mitigated by the fact that many off-the-shelf applications and database vendors provide the integration glue.
• External Software: The most common option is software-based key management. These products are typically bundled with encryption software but there are some standalone products as well. The advantages are reduced cost, compatibility with most commercial operating systems, and good performance in virtual environments. Most offer the same functions as their HSM counterparts, and will perform and scale provided you provide the platform resources they depend on. The downside is that these services are easier to compromise, both physically and logically. They benefit from being deployed on dedicated systems, and you must ensure that their platforms are fully secured.
• Embedded: Some key management offerings are embedded within application platforms – try to avoid these. For years database vendors offer database encryption but left the keys in the database. That means not only the DBAs had access to the keys, so did any attacker who successfuly executed an injection attack, buffer overflow, or password guess. Some legacy applications still rely on internal keys and they may be expensive to change, but you must in order to achieve compliance. If you are using database encryption or any kind of transparent encryption, make sure the keys are externally managed. This way it is possible to enforce separation of duties, provide adequate logical security, and make it easier to detect misuse.

By design all external key management servers have the capacity to provide central key services, meaning all applications go to the same place to get keys. The PCI specification calls for limiting the number of places keys are stored to reduce exposure. You will need to find a comfortable middle ground that works for you. Too few key servers cause performance bottlenecks and poor failover response. Too many cause key synchronization issues, increased cost, and increased potential for exposure.

Over and above that, the key management service you select needs must provide several other features to comply with PCI:

• Dual Control: To provide administrative separation of duties, master keys are not known by any one person; instead two or three people each possess a fragment of the key. No single administrator has the key, so some key operations require multiple administrators to participate. This deters fraud and reduces the chance of accidental disclosure. Your vendor should offer this feature.
• Re-Keying: Sometimes called key substitution, this is a method for swapping keys in case a key might be compromised. In case a key is no longer trusted, all associated data should be re-encrypted, and the key management system should have this facility built in to discover, decrypt, and re-encrypt. The PCI specification recommends key rotation once a year.
• Key Identification: There are two considerations here. If keys are rotated, the key management system must have some method to identify which key was used. Many systems – both PCI-specific and general-purpose – employ key rotation on a regular basis, so they provide a means to identify which keys were used. Further, PCI requires that key management systems detect key substitutions.

Each of these features needs to be present, and you will need to verify that they perform to your expectations during an evaluation, but these criteria are secondary.

Access Control

Key management protects keys, but access control determines who gets to use them. The focus here is how best to deploy access control to support key management. There are a couple points of guidance in the PCI specification concerning the use of decryption keys and access control settings that frame the relevant discussion points:

First, the specification advises against using local OS user accounts for determining who can have logical access to encrypted data when using disk encryption. This recommendation is in contrast to using “file – or column-level database encryption”, meaning it’s not a requirement for those encrypting database contents. This is nonsense. In reality you should eschew local operating system access controls for both database and disk encryption. Both suffer from the same security issues including potential discrepancies in configuration, so local administrative roles should not be considered equivalent to domain administrative roles. Use domain access controls for both.

Section 3.4.1 of the specification is where most people get confused. The assertion that “Decryption keys must not be tied to user accounts” leaves a lot of room for interpretation, but if you carefully consider this statement it actually cuts to the heart of the matter. Some interpret this as meaning keys should not be tied to a single user account, but rather a service account specifically configured for sensitive data access. Most merchants regard this statement as nothing more than a redundant way of saying you need to set domain level access controls, placing the assertion in context with the rest of Section 3.4. Still others feel this demands a separation of identity management and authorization, meaning the right to decrypt data is not equivalent to possessing account credentials.

We recommend you comply with all three interpretations:

• Service Account: Use a service account that requires additional credentials over and above what normal users provide. Using a service account is much easier for account management, and has the added benefit that auditing chores are easier when you can focus on a single account.
• Domain-Level Identity Management: You need to use domain level credentials to avoid attacks predicated on misconfigured servers or inappropriate rights bestowed on a local administrator.
• Verify Authorization: Above what’s provided by access control, verify authorization rights that take into account proper use policies. For example, while domain access controls like Active Directory and LDAP services may be used, applications and databases typically maintain authorization rights internally. They do not inherit rights from the domain – only identity. Databases provide extensive facilities to map authorization rights. Similarly, implementing encryption at the application layer has the inherent benefit of gating access based upon business context: data is decrypted only when it makes sense in the context of the function being performed. This is a great way to detect misuse!

Auditing and Verification

Any system you choose should provide audit logs of all administrative activity, failed logins, and system failure. If you are a Tier One merchant you are required to provide your auditor with not only these logs, but with specific reports on system setup as well. Your vendor should be able to provide the necessary reports for checking configuration, reviewing administrative access history, listing approved administrators, detailing system failures, and any other pertinent security information. They should provide documentation that discusses key management processes, as well as reports from third party analysis or security certifications. These reports, and the means to collect the audit data to populate them, should be built into the product.