The standard actually contains many more acronyms than my small list. Being a computer scientist I am used to dealing with acronyms, even like it. But enough is a enough! Being inundated with dozens of new three-letter acronyms all at once, while trying to come to grips with the protocol in sufficient detail that I might be able to unravel the mysterious traffic patterns we’d been seeing lately, was a bit much.
| Acronyms | |
| RSI | Request Service Initiation (optional) |
| RFS | Request For Service |
| RTR | Response to Request message |
| RSM | Response Service Message |
| KSM | Key Service Message (contains encrypted key) |
| MCL | Message Class (type code) |
| RCV | Intended Recipient (identifier) |
| ORG | Originator (identifier) |
| IDC | Server used (identifier) |
| SVR | Service Class (type code) |
| NOS | Notarization indicator (flag) |
| IDU | Ultimate Recipient of encrypted key (identifier) |
| KD | Encrypted key (ciphertext) |
| KDU | Encrypted and notarized key (ciphertext) |
| CTA | Request counter for A |
| CTB | Request counter for B |
| MAC | Message Authentication Code for all preceding fields |
I needed some notation for my notes. I chose A and B to represent arbitrary banks. Sd denoted a trusted key distribution server and St denoted a trusted key translation server.
What is the difference between the KD field and the KDU field, I wondered. Both hold a session key, encrypted with a key-encrypting key. Flipping back to the definitions section I learned that the computation for the KDU field includes a notarization step. OK, so how do they stipulate that notarization of keys be done? After another iced-tea, two trips to the restroom, and two or three separate moments staring out the window, I had successfully waded through the explanation of notarization contained on pages 28 through 30. It isn’t a lengthy explanation, but I had to be careful to understand it fully and not read anything more into it than was there.
I concluded that notarization is a method for sealing a key with the identities of the intended users of that key. A key is notarized by first blinding the key-encrypting key with a notary seal before using it to encrypt (notarize) the data-encrypting key. The notary seal is a function of the key-encrypting key and the two identities, and is designed such that it is difficult to compute a notary seal without prior knowledge of the key-encrypting key (i.e. it is a one-way function).
As I was writing down the basic protocol for the Key Translation Center environment, I was struck by how useful a key translation service might be to an outside attacker. The “translation” process involves accepting a key that has been encrypted by one key-encrypting key and returning the same key encrypted with the key-encrypting key of the requestor’s choice. How convenient! This is exactly the sort of thing that encrypting the key is supposed to protect against! If anybody can ask to have a key encrypted using any other key, then what protection does it afford? In affect, any member of the network can ask the key translation center to encrypt any key-sized collection of bits using the secret key known only to the translation center and some other member. The Key Translation Center is an encrypting service, using other people’s keys!