I think it's important to point out that ANSI X9.24 applies to financial (PIN) transactions/data. And there are federal regulations, at least in the U.S. that mandate meeting this requirement of providing tamper resistant/tamper responding technology as specified in a number of standards. The card associations and networks also mandate the use of tamper resistant technology.
Other standards do not mandate this technology, however, it is understood in cryptography that the key material is secure: The good guys have access to the appropriate keys and the bad guys do not. With PIN operations, the amount of data being protected is relatively small and the performance impact of secure key is acceptable. However, the performance impact may not be acceptable for other applications or processes (for example, if you are encrypting a large (multi-megabyte or gigabyte file). And if you plan on sharing data with a partner, under KeyA, does it really make sense to define KeyA as a secure key, if your partner doesn't have secure key technology? The security of the key is only as good as the weakest link. So, the use of protected keys or even clear keys for other work is certainly acceptable, especially when performance is a consideration, as long as you are using other techniques to keep that key material away from the bad guys. Secure key technology provides the most secure environment for your key material and makes key security easier on the key officers. However, you could implement procedures that would compromise that key material. Similarly, you can implement strong procedures that protect your key material even if it those keys are defined as clear keys. (Hint: secure key technology can help protect your data, but it's really your processes and procedures that make the difference.) Customers should use secure key technology when it is mandated or when the performance impact is acceptable as balanced against the security requirements of the data. I can imagine environments where the value of the data is significant and the performance impact is low, so secure key may be acceptable and appropriate. Protected key provides additional hardware protection for the key material, but does not satisfy the tamper-responding technology required for PIN data. Most applications should be using the protected key technology. For years customers have asked about the wisdom of having keys in the clear in the CKDS. Protected key means those keys will no longer be in the clear. Clear key is still supported and may be appropriate for work that requires the absolute fastest performance and throughput. Especially in environments where the data is low value and only exists briefly, clear key is the right solution. For example, System SSL where an attacker would have to capture multiple transactions and those transactions only exist briefly on the network, clear key is the right technology. You can compare the performance metrics of clear key, secure key and protected key in the performance whitepapers available at http://www-03.ibm.com/systems/z/advantages/security/zec12cryptography.html for the zEC12 and http://www-03.ibm.com/systems/z/advantages/security/z10cryptography.html for the z10 and z196 (look under 'Learn More' on each page). Greg Boyd IBM Advanced Technical Support Supporting Crypto on System z ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
