Chapter 17 Page 2 of 6

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.


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!