Today's stringent security requirements have led organizations to adopt mainframe cryptography to protect sensitive data, but not all mainframe systems programmers have extensive knowledge on the issue. In this tip, mainframe expert Robert Crawford explains the basics of cryptography on the mainframe.
Corporations frequently ask systems programmers to blaze new trails. It's not that the technical staff are experts in the new area; instead, the new function seems to involve system-level code and management assumes the systems programmers are smart enough to figure it out in a short timespan. Herein lies the premise of this article.
There are many reasons why cryptography may sneak up on a technician. Today's privacy laws, especially around health information, are getting tough. Many credit card companies enforce Payment Card Industry (PCI) security standards on customers who touch account data. Then, of course, there is the movement away from old security schemes that involve flinging clear-text user IDs and passwords through the network to more robust concepts, such as Secure Sockets Layer (SSL) or Kerberos. The good news is that the mainframe is well equipped to hit the ground running.
Cryptography hardware
There is a menagerie of cryptographic hardware available for the mainframe that seems to come in two forms. First, there is CP Assist for Cryptographic Function (CPACF), which helps the general cryptographic processors (CPs) perform encoding and decoding processes using standard OS/390 instructions. As IBM points out, the amount of crypto work that can be done on a box increases with every available CP. The bad news is that the general processors do the heavy lifting. The other disadvantage is that the CP must use the cryptographic key in the clear as it manipulates the data.
Besides CPACF, there are what IBM calls crypto adjunct processors. These processors are outboard of the CPs and process asynchronously from them. Since they do the c...
To continue reading for free, register below or login
To read more you must become a member of SearchDataCenter.com
ryptographic processing, the keys are never in the clear outside of the crypto engine. A couple of the later crypto engines, which are Federal Information Processing Standard (FIPS) 140-2 certified, will destroy (or, as the IBM doc says, "zeroize") saved keys if it senses it's being tampered wtih or removed from the processor. One drawback is the cryptograhic offloading is limited by the adjunct processors' capacity. Any excess demand falls back on the general processors. Installations need to be careful in ordering crypto engines, as the type and capabilities vary by processor model.
Integrated Cryptographic Service Facility (ICSF)
Integrated Cryptographic Service Facility (ICSF) is the no-cost software interface for cryptography on the mainframe. ICSF manages and schedules the crypto engines and maintains the keys within them. It also provides application programing interfaces (APIs) that may be called from your favoirte mainframe language.
ICSF maintains key stores in two linear VSAM datasets: the cryptographic key dataset (CKDS) and the public key dataset (PKDS). Keys in the key stores may be clear or encrypted, depending on how they will be used. Either way, the key data stores should be carefully protected through Resource Access Control Facility.
One reason why mainframe cryptography may be considered highly secure is because of its key handling strategies. Primarily there's the master key, generated through an elaborate procedure that typically includes hoods, candles and sacrifical goats, which is entered once by a number of security officers and stored in a special register inside the crypto engines. From this master key several more may be generated, which are likewise stored and managed by ICSF. Other keys generated for individual applications may be encrypted with the master key and kept in ICSF's key store.
The beauty of this setup is that with the crypto engines and special registers, ICSF can manage the encryption and decryption of sensitive material without exposing the keys in clear text to the computer. Instead, the keys and the processes stay in the crypto engine and never see the light of day. This also applies to encrypted keys stored in ICSF's datasets. Before they can be used, the keys must be loaded into the crypto engines and decrypted with the master key.
I should note at this point that cryptography has disaster recovery (DR) implications as well. If you have encrypted operational data you will need to include a DR procedure to set the master key in the recovery machines as well as a way to recover ICSF's key set. Loss of either of these will leave the enterprise with gibberish on mirrored volumes, or, in the very worst case, useless backups.
ICSF's API makes cryptography available to everyone. However, if an enterprise doesn't want to write its own code, it may purchase IBM's Encryption Facility for z/OS. The Encryption Facility provides utilities to secure "data at rest," especially when the data is physically transmitted between locations. It includes utilities that interface with data moving and archiving software, such as DFSMSdss. In addition, there are a couple of Java clients available to help secure data shared between z/OS and non-mainframe platforms.
Soon I hope to delve more into the ICSF APIs and practical steps for encrypting data. It depends on how well I can hack the code.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
What did you think of this feature? Write to SearchDataCenter.com's Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
