The next morning I slept late. After fixing myself a breakfast around noon, I settled in for a long bout with the X9.17 protocol. This is the ANSI standard I had gotten at the Chicago Public Library on the day of my arrest. I was hoping that I might be able to find a weakness in the protocol that would explain the money mill. Little had suggested that the mill was probably an attack on the protocol used to exchange encrypted messages rather than an attack on DES directly. This was a plausible explanation.
This left me with the question of how the millwright was getting the MAC keys. Was he a trusted insider? Or was he an outsider that had discovered a way to circumvent the security measures designed in the key-exchange protocol used by all banks worldwide? I was determined to find out.
I fixed myself a peanut butter and jelly sandwich, grabbed a can of iced-tea, and sat down at the kitchen table. I opened my copy of the X9.17 standard. On the blue and white cover, in the upper right corner, it was dated 1985 but it also indicated that the standard was reaffirmed without any modifications in 1991. The title of the standard is Financial Institution Key Management (Wholesale). I cracked the cover, sat back with my can of iced-tea (I’ve always found it more convenient to buy it by the can than to make my own) and, with great determination, set out to learn the protocol. As it turns out, determination was an important requirement; without it I would have tired quickly from all of the acronyms. As it was, they slowed me down but did not deter me.
X9.17 is intended for the exchange of cryptographic keys used in applications for wholesale financial institutions. In other words, for electronic funds transfer. This is the standard used for automatic deposits, automatic payments, wire transfers, and even the automated clearing of paper checks. To maintain the secrecy of keys, all exchanged keys are encrypted using key-encrypting keys. This encryption is done using DES. To provide integrity for exchanged keys, the protocol again uses DES, this time to compute message authentication codes (MAC’s).
X9.17 supports the exchange of two types of session keys: keys used to encrypt data for privacy; and keys used to compute MAC’s for integrity. The standard refers to both types as data-encrypting keys. The cryptographic keys used to encrypt data-encrypting keys during a key exchange are referred to as key-encrypting keys. So key-encrypting keys are only used to encrypt and authenticate other keys, which in turn are used for EFT’s and other inter-bank traffic. X9.17 only specifies key exchange, not key use (i.e. not EFT), but since all evidence indicated that the millwright had knowledge of keys, I wanted to study the X9.17 document to determine if there might be some way for an outsider to eavesdrop on MAC keys.
The standard includes two different architectures. The simpler architecture, called the two-layer version, uses manually distributed key-encrypting keys to exchange data-encrypting keys. The second architecture is a three-layer architecture that supports an additional layer of key-encrypting keys. The manually distributed key-encrypting keys are used to encrypt a layer of automatically distributed key-encrypting keys which are used in turn to encrypt data-encrypting keys. I noted that both architectures require that there be a secure mechanism external to the protocol for exchanging top-level key-encrypting keys.
The standard allows for three different “environments” (not to be confused with architectures). Because X9.17 has these three environments, it is really three separate protocols in one standard. The first, the point-to-point environment, is a protocol whereby two parties can agree upon a session key that is generated by one of the parties and is encrypted by that same party. The second environment, the key distribution center environment, is meant to be used when neither of the parties wishing to establish a session key is able to generate a good key or encrypt a key for use by the other party (i.e. the two parties share no prior secrets). In this environment, one of the two parties requests a key from a trusted distribution center and receives two ciphertexts, one of which can be decrypted by that party and the other of which is relayed on to the other party for decryption. The third environment, the key translation environment, makes it possible for one of the two communicating parties to generate the key. The trusted translation center is used to encrypt the key for transmission to the other party. This environment is appropriate when one of the pair is able to generate good keys but the pair does not share a prior secret.
OK, so far so good. I stood up and walked over to the refrigerator. Rummaging through the contents turned up very little in the way of snack foods and I didn’t want to prepare anything elaborate, so I settled for a second can of iced-tea.
I found the various message formats for each of the three environments on pages 47 through 50 of the document. Many of the fields are optional. Indeed, many of the messages are optional. I decided that the best way to tackle this was to filter out all of the optional features and concentrate first on the core of the standard. I got up from the table and went over to the telephone stand for a couple of clean pieces of paper. Sitting back down, I opened the iced-tea and took a long sip. Doing so, I noticed that the clock on the wall above the dishwasher read 3:05. Hmmmm, this might be a long afternoon. I used the first sheet of paper to jot down all the acronyms so that I would be able to refer to them easily. The standard already had a table of all the acronyms, listed on pages 4 through 7, but I wanted a list that only included those acronyms I expected to use. I left out all the acronyms for optional features, for example. The first part of my list consisted of the acronyms for the five message types that comprised the core of the protocol. The remainder of the list consisted of acronyms for required field types.