Now that the new version of the PCI Data Security Standard (PCI DSS version 2.0) is in effect, many IBM i (AS/400, iSeries) customers are getting dinged on their PCI compliance in the area of encryption key management. The renewed focus on "Dual Control" and "Separation of Duties" by QSA auditors is forcing many IBM i customers to move from homegrown key management to a better method of securing keys. This is even happening for IBM i customers who use IBM’s Master Key and key database facility. Why is this? There is just no way to properly implement effective security controls for the QSECOFR user, or for any user with All Object (*ALLOBJ) authority. Thus no "Dual Control" and no "Separation of Duties." And QSA auditors have figured this out.Moving to good key management does not mean you have to completely change how you encrypt the data. And it doesn’t have to be a time consuming, laborious process. Many IBM i customers use the native IBM i encryption APIs to protect data. Let us show you how easy it is to implement our Alliance Key Manager solution in RPG code while maintaining your encryption approach.
When you use the native IBM i APIs you first create an encryption algorithm context, then a key context, and they you use these contexts on the call to the encryption or decryption API. If you are using the IBM Master Key facility and special key database, you pass additional parameters to the key context API. Before migrating to our Alliance Key Manager solution your RPG code might look something like this:
* Create a key context
C eval myKey = 'some binary value'
C eval keySize = 32
C eval keyFormat = '0'
C eval keyType = 22
C eval keyForm = '0'
C callp CrtKeyCtx( myKey :keySize :'0'
C :keyType :keyForm :*OMIT
C :*OMIT :KEYctx :QUSEC)
*
* Now we call Qc3EncryptData or QC3ENCDT to encrypt some data
* and pass it the key context field <KEYctx>
After you implement the Alliance Key Manager solution and the IBM i API to retrieve the key, your application code would look like this:
* Get the key from Alliance Key Manager
C eval AKMName = 'SomeKeyName'
C eval AKMInstance = ' '
C eval AKMSize = 256
C eval AKMFormat = 1
C callp GetKey( AKMName :AKMInstance
C :AKMSize :AKMFormat
C :AKMKey :AKMUsed
C :Expires :LastChange
C :Reply)
*
* Now we can use the field <AKMKey> on the create of the key context
*
* Create a key context
C eval keySize = 32
C eval keyFormat = '0'
C eval keyType = 22
C eval keyForm = '0'
C callp CrtKeyCtx( AKMKey :keySize :'0'
C :keyType :keyForm :*OMIT
C :*OMIT :KEYctx :QUSEC)
*
* Now we call Qc3EncryptData or QC3ENCDT to encrypt some data
* and pass it the key context field <KEYctx>. That code is unchanged.
Notice that you’ve added a few lines of code to retrieve the key from the key server, and then used the retrieved key to create the key context. For most IBM i customers this will be a very quick change involving just a few lines of code. If you’ve taken a common module approach to isolate the encryption code, this might mean changing just one or two applications on your system. If you are using the IBM i Master Key and key database facility, you will have one more step to re-encrypt the data using keys from the Alliance Key Manager server.
Pretty simple process. Not bad for a day’s work.
Of course, there are proper ways to manage and protect an encryption key that has been retrieved from a key server, but we won’t go into that here. I want to save that topic for another day as it applies to many different application environments.
I hope you’ve gotten the idea that good key management doesn’t have to be a difficult, scary process. We are helping customers get this done today, and you can get there, too.
Click here to learn more about Alliance Key Manager and request an evaluation today.
Patrick