Case Study: Preventing Substitution of Cryptographic Keys

One of our customers recently submitted a support ticket related to a question asked by their QSA Auditor.  Just a quick background on our customer - they have an all IBM i environment and are using AES/400, our NIST-certified AES encryption among other data privacy solutions we offer.  This customer needs to comply with PCI because they are accepting credit cards and store personally identifiable information (PII). The question was: How does your AES encryption software prevent unauthorized substitution of cryptographic keys?

At Townsend Security we stress the need for encryption any time you have sensitive data, but that is only half of the battle.  You also need to protect the encryption key with a key manager.  Did the question about substitution of cryptographic keys surprise us? No, it didn’t.  This is a great example of what is happening out in the business world.

If your encryption is weak (did you know there is weak encryption?), this is a legitimate concern. There is a “key store” on the IBM i that stores encryption keys, but it’s like putting your house key underneath the welcome mat to your front door.

If you are using our Alliance Key Manager (our encryption key management HSM), we use NIST FIPS 140-2 best practices for detecting key substitution or key corruption. This involves the use of an HMAC mechanism with each key stored in the key management appliance.

What kind of questions are your QSA Auditor’s asking?  We would love to hear from you, whether you are a current customer of ours or not.  If you are interested in hearing more download our podcast on compliance and encryption key management.