Townsend Security Data Privacy Blog

The Uncomfortable Truth About Key Management on the IBM i

Posted by Patrick Townsend on Feb 15, 2011 10:21:00 AM

IBM i Key ManagementLast week we presented a webinar on PCI requirements for encryption key management.  Many of the people who attended were encrypting data on the System i and curious about how to manage their encryption keys according to new PCI requirements. 

The way organizations are managing encryption keys is falling under more scrutiny by QSA auditors.  Companies must demonstrate they are enforcing dual control and separation of duties.  

How is this achieved on the System i? Is it still effective to use an integrated key management solution that is store encryption keys in the same partition as the encrypted data?  The answer, quite simply,  is "no" PCI DSS requirement states the following requirements for key management:

 

  • Dual Control means that at least two people should be required toauthenticate before performing critical key management tasks.
  • Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

Now here is an uncomfortable truth.  On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the System i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Let us know about the key management strategy at your company. Is your organization encrypting data on the System i?  How are you managing the encryption keys? If you store them on a separate partition, have you had a recent PCI audit?  What did your auditor say?

Topics: Compliance, Encryption, Key Management, IBM i, encryption key