Should we worry?
In order for this attack to actually be possible, the actual configuration of the protocol must be an unusual one. X9.17 has two “architectures” and three “environments”.
The architecture is not really relevant since the attack is possible in either architecture. If the two-layer architecture is used, then data-encrypting keys can be compromised. If the three-layer architecture is used then key-encrypting keys can be compromised.
It is the “environments” that must be used in an unusual manner before this flaw becomes a concern. The flaw involves a weakness introduced by the interaction between the Key Distribution Environment and the Key Translation Environment. The flaw requires that parties participate in both environments and that they use the same key-encrypting keys to communicate with both. Is this typical? It seems unlikely. More likely, each bank opts for one of the three environments. If any banks actually do use more than one environment, they probably use different keys to communicate with the different types of key centers.
Nonetheless, with the right configuration, the flaw is real. Nowhere in the standard is there any indication that using multiple environments is discouraged. Furthermore, FIPS-171, which contains numerous recommendations for the use of X9.17 does not discourage configurations where this flaw occurs. FIPS-171 actually encourages the use of X9.17 in a broad set of applications involving various trust models. Even if the wholesale banking networks do not use multiple key centers in the way described in the book (and permitted by X9.17), surely it is unreasonable to think that no application will… unless there is some advisory against doing so….
So be advised: if you plan to develop or use a product based on X9.17, read Chapter 17 of The Electronic Money Mill and be sure not to allow an impersonation or eavesdropping attack based upon the interplay of Key Translation and Key Distribtion centers.