The content of the fields in the remaining message types is similar to that of the RTR. The next message, the Response to Service Message (RSM) is an acknowledgment sent by A back to the key distribution center. At this point A has a copy of the key (after decrypting the contents of the KD field in the RTR). Next A sends a Key Service Message (KSM) to B. The KSM message contains the KDU field, which A cannot decrypt but B can. The KSM is the heart of the protocol in each of the three environments; it is the message that sends the encrypted key to the ultimate recipient. Each of the protocols ends with a Response to Service Message (RSM) which is an acknowledgment of the KSM.
| Key Distribution Center Environment | ||||
| A ->Sd: RSI | Sd ->A: RTR | A ->Sd: RSM | A ->B: KSM | B ->A: RSM |
| MCL | MCL | MCL | MCL | MCL |
| RCV | RCV | RCV | RCV | RCV |
| ORG | ORG | ORG | ORG | ORG |
| IDU | IDU | IDU | IDC | IDC |
| SVR | KD | MAC | KDU | MAC |
| KDU | CTB | |||
| CTB | MAC | |||
| CTA | ||||
| MAC | ||||
Ahh, but wait a minute! The key translation center environment allows a participant to generate a session key and submit it to the trusted third party for packaging. In other words, the party that generates the session key and sends it to the ultimate recipient does not need to share any prior secrets with the ultimate recipient. Might there be some way for one party to impersonate another party and request a key translation? Some sort of inside attack?
The party sending the RFS to the Key Translation Center still needs a legitimate key because, as I had noticed earlier, the RFS includes a MAC, which cannot be computed without the key. OK fine. Some other bank, separate from A and B partaking in the key exchange, would have a legitimate key. So that requirement can be met.
I hurriedly took notes on this train of thought, afraid that I might forget it. Damn — broke the pencil lead again. I renewed the pencil point and pressed on. So as not to add a new level of confusion and make it difficult to relate my notes to the X9.17 standard, I continued to use the notation of the standard, although I did yield to the temptation to deviate slightly.
OK, let’s see… The ciphertexts for encrypted session keys are not always notarized. Due to this lack of explicit type information in the ciphertext portion of some messages, it is possible for an attacker to use the ciphertext in a manner different from the intended use. Namely, the attacker can use un-notarized ciphertext to impersonate a party making a seemingly legitimate request for key translation. There is no MAC in the RSI message format used to request service from a key distribution center. Presumably the ciphertext in the response from the server is meant to guard against misuse.
Hmmm. I wonder if the lack of explicit information in keys might make them susceptible to replay attacks. The attacker would need to be able to predict the values of counters expected by recipients of forged messages (e.g. CTA and CTB), but this is easily handled by eavesdropping on a short history of messages. The counters are sequential and are sent in the clear.
I jumped out of my chair and ran over to the telephone stand, grabbed the entire stack of scrap paper, and hurried back to the table. I needed to get this down on paper before I forgot it. I hurriedly took notes, not bothering to write things down neatly; there would be plenty of time later to polish it up and fill in details.
I used YZ to denote entity Y attempting to impersonate entity Z in the protocol. The attacker, a legitimate member of the network, will be denoted by X. KDZ shall denote a key encrypted using a key-encrypting key known to Z. KDUYZ shall denote a key encrypted using a key-encrypting key known to Z and notarized with the identities of both Y and Z.