Well, no. The X9.17 designers apparently anticipated attacks on the Key Translation Center because the standard requires that the requester send a MAC with the Request For Service (RFS). An outsider cannot forge a legitimate RFS. And an eavesdropper of a legitimate RFS and Response To Request (RTR) pair learns nothing because the keys in the KD and KDU fields are encrypted.
This was getting way too confusing. I walked across the room and got a ruler and took out a fresh piece of paper. A glance at the clock told me it was well past time for dinner. My stomach confirmed this. Reluctant to stop now that I was fully focused, I pushed on. I then wrote down the minimal protocol, leaving out all the optional parts.
| Key Translation Center Environment | |||
| A ->St: RFS | St ->A: RTR | A ->B: KSM | B ->A: RSM |
| MCL | MCL | MCL | MCL |
| RCV | RCV | RCV | RCV |
| ORG | ORG | ORG | ORG |
| IDU | IDU | IDC | IDC |
| KD | KDU | KDU | MAC |
| CTA | CTB | CTB | |
| MAC | MAC | MAC | |
I used an arrow from X to Y to indicate that X sends a message to Y in that step of the protocol. In the Key Translation Center Environment, the protocol consists of four core messages. The first, the Request for Service (RFS) is from A to the center. This was the first column of my table. Then the center sends a reply (RTR) back to A. Then there is a message from A to B, and finally a message from B back to A.
Laid out in this way, the protocol began to make more sense. The first thing I noticed is that all of the messages contain the identifiers for the intended sender and recipient, as well as a MAC. In each message the MAC was written as the last field. The first three fields were always the same: the MCL holds the message class; the RCV holds the identifier of the intended recipient; and the ORG holds the identifier of the purported sender.
The fact that each message contained an explicit identifier for the recipient, as well as a MAC, would make it hard, if not impossible, to re-route messages. Because the messages contain MAC’s, they cannot be altered (unless the attacker knows the MAC key).
I wondered what would happen if an attacker tried to fool B into using the wrong data-encrypting key in the Key Translation Center Environment. The attacker might try intercepting the KSM message sent by A and intended for B. However, there is little that the attacker can do with the intercepted message. The key contained in the KDU field is encrypted and therefore inaccessible. The attacker might try to substitute a different key by replacing KDU with bits of his own choosing, but he will be foiled by the MAC that must be appended to the KSM message. Without knowing the key-encrypting key, there is no way for the attacker to recalculate the MAC for the new KDU field such that it will pass the verification check performed by B. This is the essential function of MAC’s — to make it infeasible to alter intercepted messages or to produce fake messages.
Next I turned to the Key Distribution Center Environment. According to the standard, at a minimum the protocol for a key distribution center environment consists of three basic messages. the first important message is the RTR message. Flipping back to page 7, I discovered that RTR stands for Response to Request, and the actual request (called and RSI or Request Service Initiation) is one of the optional messages I was ignoring for the time being. The table on page 47 indicates that RTR messages in this environment have nine fields. The first of these nine fields is the Message Class (MCL), which indicates the type of message. In this case the MCL field indicates that the message is a Response to Request (RTR). The next field, RCV, specifies the intended recipient. It is an identifier. This is followed by the identifier for the sender, or originator, of the message. The IDU field holds the identifier for the ultimate recipient of the (second) encrypted key. The entity that receives the RTR message is expected to relay a copy of the encrypted key on to the entity named in the IDU field. The next two fields hold encrypted copies of a key to be used in an EFT session. The KD field holds a encrypted copy for the recipient of the RTR message (i.e. entity A), while the KDU field holds an encrypted copy for the other entity (i.e. B). Thus, KD and KDU will be encrypted using different keys since they are intended for decryption by separate entities. The ciphertext fields are followed by two counters in plaintext. These counters are used to recognize replays of old messages. The first counter is a tally of the number of keys sent to entity B while the second counter is a tally of the number of keys sent to A. Finally, appended to the RTR message is a MAC. The MAC is computed over the entire message (i.e. eight fields, beginning with MCL and ending with CTA).