In a previous article we looked at methods of archiving TDES keys to prevent them from being used to encrypt new data, while keeping them available to decrypt existing data. While this diminishes the risk of new data being encrypted using an insecure algorithm, it does nothing to address the vulnerability of the existing encrypted data. 

Once the TDES keys on the system have been identified and archived, the next step is to strengthen the security of the data encrypted under them. In this article we will look at the services offered by ICSF that can be used to re-encrypt existing data under a different key. These services will allow us to choose a more secure encryption algorithm such as 256-bit AES, which is not susceptible to the same cryptanalytic attacks as TDES, and even provides resistance against quantum cryptanalysis. 

As with many functions, ICSF provides separate callable services to accomplish data re-encryption for the PKCS #11 and CCA cryptographic architectures. These callable services will perform the decryption and encryption of the data in the secure environment of their respective cryptographic coprocessor. This means that the data is never in the clear outside of the coprocessor, and is not even made available to the calling application, which provides an advantage over manually calling the decryption and encryption services to perform the re-encryption.

PKCS #11

PKCS #11 Secret Key Reencrypt (CSFPSKR & CSFPSKR6) is the callable service to re-encrypt data using an EP11 coprocessor. Secret Key Reencrypt accepts the handles of two PKCS #11 secure secret key objects, one for decryption and the other for encryption. The services determine the desired algorithm to be translated to and from based upon the algorithm of the corresponding key. The service supports AES and TDES for keys and CBC, CBC-PAD, and ECB as encryption modes.

Examples for how to invoke the Secret Key Reencrypt service using a REXX exec are available here.

CCA

Cipher Text Translate2 (CSNBCTT2 & CSNECTT2) is the callable service re-encrypt data using a CCA coprocessor. The service accepts the identifiers for an “input” key to be used for decryption, and an “output” key to be used for encryption. The algorithms to be translated to and from are specified via a rule array. The service supports CBC and ECB encryption modes for AES and CBC, CUSP, and IPS modes for TDES.

Examples for how to invoke the Cipher Text Translate 2 service using a REXX exec are available here.

Conclusion

In this series of articles we have discussed the reasons for utilizing the AES encryption algorithm over TDES for securing data, the controls available to limit the use of existing TDES keys, and the mechanisms for transitioning existing encrypted data from TDES to AES. We hope these articles have provided insight into z/OS security best practices, and we look forward to continuing our work with other security and cryptography related topics in the future.