How to Implement COBOL AES Encryption
Although we usually provide at least one case study for Redvers software products, when it comes to cyber security, it's usually neither wise nor corporate policy to make public any details of how our software is used at client sites. We have therefore adapted this page to provide some helpful advice on implementing AES in COBOL applications. Remember, you can always use our offer of a free 30 day trial to prove our software will run reliably at your site.
Most of the links on this page point to our COBOL AES Encryption White Paper - see download below. It isn't a short paper, so it might be preferable to use the points made on this page to select only the sections of the document most relevant to your project.
| Download a PDF white paper on COBOL AES Encryption: |
AES Properties
The AES algorithm/cipher has the following main properties:
- Block cipher - working on blocks of 128 bits (16 characters) at a time
- Symmetric-key algorithm - the same key is used to encrypt and decrypt
- Encryption key can be 128, 192 or 256 bits in length
- Algorithm is a publicly known, logical procedure - only the encryption key needs to be kept secret
The final point in the above list is of particular relevance to COBOL applications management. It means that although the key needs to be kept secure, the program source code can be kept in standard libraries, accessed by development and production teams - a common scenario for COBOL applications.
AES Options
AES encryption isn't a one-size-fits-all solution. It has several modes of operation and other features to help it fit seamlessly into a wide range of computer applications. The choice of mode, key length and other parameters will depend on the application involved, so the following points need to be considered when embarking on an AES project.
Should my ciphertext be the same or different for a given plaintext?
When encrypting unique key fields, the same ciphertext for a given plaintext will be required to maintain the integrity of the application. For example, a credit card number would need to produce a consistent ciphertext if card transactions for the card are to be linked to the correct card owner details - see Consistent Ciphertexts in COBOL AES Encryption White Paper.
For non-key data, applications will be more secure with a different ciphertext for a given plaintext. For example, if expiry dates within a credit card application were to be encrypted using consistent ciphertexts, knowledge of the true expiry date of one credit card would reveal the expiry date of all cards expiring on the same date - see Inconsistent Ciphertexts in COBOL AES Encryption White Paper.
What if I don't need to decrypt the ciphertext after encryption?
Verification of user id's, passwords or PIN numbers are the most common conditions where decryption isn't required. Indeed, it may even be possible to use a standard hashing routine instead of encryption. If the input, after encryption or hashing, matches the previously encrypted/hashed id, password or PIN on file, then the input is verified. It's not necessary for the application to derive the actual id, password or PIN in use - see Encryption without Decryption in COBOL AES Encryption White Paper.
Which key length should I use?
The choice of 128, 192 or 256 bit key lengths will depend on the security level required for the data involved. 128 bits is usually regarded as sufficient for most commercial applications.
Processor requirements for a 192 bit key will be approximately 20% greater than a 128 bit key and a 256 bit key will require about 40% more CPU than a 128 bit key.
Can I generate ciphertext for decryption by an external AES encryption routine (or visa-versa)?
Yes. AES encryption is a global industry standard regardless of platform or programming language. However, the encryption key, confidentiality mode (see Appendix A: Confidentiality Modes in COBOL AES Encryption White Paper) and, if required, Initialization Vector (see Appendix B: Initialization Vectors in COBOL AES Encryption White Paper) all need to be the same for encryption and decryption; so these will need to be agreed with the external party beforehand.
Can I transmit ciphertext in an XML document?
No - not even within a CDATA section. Ciphertext consists of pseudorandom bit patterns that could, by chance, represent any character or string of characters. For example, the "<" character could be created once in every 256 characters of ciphertext and the characters "]]>" are likely to appear once in every 17MB of ciphertext. Also, XML has a restricted character set, so invalid characters appearing in ciphertext will mean the XML isn't "well-formed".
The most common solution is to convert the ciphertext to Base64 format (characters in the range A-Z, a-z, 0-9, "+", "/" and "="). This can either be done within the AES encryption subroutine or by using a separate software tool to convert ciphertext to Base64. E.g.: The Redvers RCBINB64 tool.
Conversion to Base64 will cause an unavoidable expansion in the ciphertext length of about 33%.
An alternative to Base64 would be to produce a format-preserved ciphertext using an alphanumeric alphabet, see Format Preserved Ciphertexts in COBOL AES Encryption White Paper.
Can I compress ciphertext?
You could try but the random bit patterns in ciphertext will probably produce a compressed length, longer than the uncompressed length. However, you can encrypt compressed plaintext. Therefore, the sequence of events should be: compress, encrypt ... decrypt, decompress.
What if I need the ciphertext in a specific format and length?
Ciphertext can usually be stored in alphanumeric COBOL fields (PIC X) without a problem. However, if a field to be loaded with ciphertext is defined as
numeric or if it must conform to a specific format, then there will be formatting issues (ciphertext is a random array of bits). For the storage of ciphertexts in
fields with restricted formats or values, see Format Preserved Ciphertexts in COBOL AES Encryption White Paper.
How can I encrypt and decrypt large data volumes very quickly?
Applications that need to process high transaction volumes, very fast, may encounter performance problems when running the AES algorithm at peak processing times. To avoid this problem, a secured reserve of pseudorandom binary strings can be built during off-peak hours. This reserve can then be used at busy times, to encrypt/decrypt confidential data, just by using Exclusive Or (XOR) logic - see Binary Banks in COBOL AES Encryption White Paper.
Is there anything else I need to know?
The safe governance of encryption keys should be regarded as the top priority for applications management. As the circumstances within every installation will be different and the details of how keys are managed must be kept secret, a publicly available web page isn't the best place to detail how encryption keys should be handled.
Having said that, encryption keys are more likely to survive a Brute-force attack if they consist of an unpredictable bit pattern rather than printable characters. One way to do this might be to start with an alphanumeric string and then pass this through AES encryption, using the output as the actual key.
As part of a best practice policy, we also suggest initializing any application fields containing encryption keys or plaintext immediately after the encryption/decryption activity has completed. The Redvers Encryption Module has a "clean storage" function to perform this task for its own storage areas.
In the event an encryption key is compromised, a new key will need to be created and all encrypted data re-encrypted as soon as possible. In non-urgent circumstances it may be possible to adopt a phased migration to a new key, using the date-time of the last encryption to identify whether the old or new key is to be used for decryption, then, if necessary, re-encrypt using the new key.
Conclusion
We hope this web page and white paper have shown how the Redvers Encryption Module can be used to bring AES encryption to COBOL applications and that it isn't quite so complicated after all. If you still have questions, please use our Contact page and we will endeavour to provide an answer as quickly as possible.