System z customers run some of the most secure workloads in the world. To architect these secure workloads, they must have the building blocks necessary to integrate their business requirements into an end-to-end secure solution. This requires hardware and software to interact flawlessly to make use of the latest technologies available to System z.
Such solutions may cross from an application server in one Logical Partition (LPAR) to a data server in a separate LPAR. They may run locally, crossing multiple security zones—as seen in a classic Demilitarized Zone (DMZ)—or span the globe, moving millions of dollars in currency from one international bank to another. One thing is common in all these cases: A security policy is an integral part of the solution and is an extension or expression of the intellectual property that separates one solution from another implemented and deployed at a different customer site. Both applications may ultimately provide the same general functionality, but the security path is likely different.
A good security policy includes many disciplines and elements that must come together to provide a secure solution:
- Networking requirements
- Deployment of firewalls and intrusion detection or prevention systems
- Monitoring and auditing
- Authentication requirements
- Authorization rules for access control.
Various regulations, such as the Payment Card Industry Data Security Standard (PCI DSS) and Health Information Portability and Accountability Act (HIPPA), will also play important roles in guiding the security policy.
Data is often thought of as a client’s most important asset, and it must be protected while at rest (e.g., stored on a hard drive or backup media), in transit (e.g., while in-flight over the Internet or intranet), and in use (e.g., while processing a credit card transaction). Cryptography, another critical element of the security policy, often provides this protection. The business and security requirements of each application should influence where and when to apply cryptography and which algorithms to use.
Effective use of cryptography on System z exploits hardware cryptographic accelerators. In some cases, secure functions require data to be protected at the application level, meaning the data must not be stored in memory in an unencrypted state. In other cases, cryptographic algorithms can’t be performed in software due to use of secure cryptographic keys. By definition, secure keys must not be stored in memory unencrypted. Doing so weakens the security of the end-to-end cryptography and the integrity of the solution. Advances in cryptographic hardware are one of the compelling factors that make moving to newer System z hardware releases more attractive.
New Frontiers for Secure Key
The IBM CEX3C Common Cryptographic Architecture (CCA) Support Program for Linux on System z 4.0.0 (the CCA host library) works with a CryptoExpress2 (CEX2C) or CryptoExpress3 (CEX3C) PCI card configured as a co-processor to provide applications with the secure cryptographic algorithms needed to meet the most rigorous end-to-end enterprise solutions. Together, the CCA host library and crypto card provide robust functionality that can be integrated into custom applications to meet the cryptographic needs of traditional industries such as banking and finance, insurance, and government. Any industry or solution with security needs that requires a Hardware Security Module (HSM) can now turn to Linux on System z with the CCA host library and a CEX2C or CEX3C to meet their needs.
This new version of the CCA host library has been greatly enhanced and provides access to new functions, new hardware, and a new programming language. The new library can recognize a CEX2C or CEX3C card assigned to a Linux image or guest and provide applications running in that image access to all the functions available from that hardware generation.
Support for new algorithms and expanded features and functions was a priority with the new CCA host library. The addition of Advanced Encryption Standard (AES) support provides applications with the next generation of symmetric cryptographic algorithm needed to meet challenging solution requirements. Functional improvements include new verbs, such as control vector translate, cryptographic variable encipher, random number generate long, symmetric algorithm decipher and more, which have been added to extend the capability and utility of secure key applications deployed on Linux on System z. In addition, existing verbs now have extended parameter lists to more closely align with CEX3C capabilities and z/OS functionality, using more keywords and parameter choices than previously available to Linux on System z.