I don't know much about TR-31, other than the little I've read about it in the ICSF documentation. I do remember our Thales vendor trying to sell it to us some years ago, and I couldn't understand a word he was saying! Now that I understand it a bit more I find it interesting, but rather useless until our "partners" (Visa, MasterCard, our ATM vendor) support it. And I've heard no indication that any of them have it on their radar.
Frank >________________________________ > From: Todd Arnold <[email protected]> >To: [email protected] >Sent: Wednesday, March 20, 2013 6:41 AM >Subject: Re: IBM Mainframe (1980's) on You tube > >Two points... > >(1) Remember that when IBM invented CCA back in the late 1980s, there really >were no other HSMs - thus, there were no other crypto architectures in the >banking world to be "compatible" with. I suppose other vendors who came along >and developed HSMs could have adopted CCA, but they developed their own APIs >and architectures. IBM, of course, had no way to make our own CCA any kind of >"standard" for the industry. > >(2) Compatibility for interchange has always been a problem, and the solution >for key exchange has generally been to use a least common denominator >approach, simply wrapping keys with TDES in ECB mode with no associated >type/usage information or other metadata. Dissimilar systems generally strip >off their proprietary metadata when exporting the key, then the receiving >system binds its own proprietary metadata structures to the key when importing >it. This obviously is not the best approach in terms of security, but it's >what everyone has done all these years. Now, there is the TR-31 key block >format which has improved somewhat on that situation, but TR-31 also has >significant problems. It defines its own fixed set of key metadata, which of >course is not entirely compatible with anything the preceded it and does not >generally match up exactly with any vendor's HSM architecture, so translations >have to occur and in the process security information is lost or interpreted differently. Furthermore, different vendors have interpreted the meaning of the key type/usage in TR-31 in different ways, so the restrictions you think you defined for a key may not be enforced in quite the way you thought when the key reaches some other device. One example is that TR-31 has rather coarse key typing and usage, whereas CCA has much finer granularity and lets you control the key much more tightly. When translating a CCA key to TR-31 format, all that extra control has to be discarded so that you use only the attributes defined in TR-31. Conversely, when importing a TR-31 key into CCA, you have to somehow create all the extra, more detailed control attributes that are not present in TR-31, and the only way to do that is to let the application program tell CCA what to do. > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
