Vulnerability in IBM crypto card
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
9 Nov 2001 2:54PM ET
A rather interesting vulnerability was found recently in the IBM 4758 crypto coprocessor. This coprocessor implements FIPS 140-1 level 4, and is extremely tamper-proof. The vulnerability has to do largely with the CCA API, which is often used to implement financial transactions, like ATM machines.
This certainly affects anyone in the financial industry using this card and CCA and relies upon its key escrow features. The only way I can see this affecting FIX is if someone's engine uses the card and CCA for DES.
The idea is that two distinct security officers each enter a 3DES key into the card, and the two are XOR'd together. In theory, unless the officers collude or both parts of the key are intercepted, one would expect data sent between the cards to be secure. Only the cards on either end of the link know the two keys. Thanks to the FIPS 140-1 hardware protection, any attempt to tamper with the cards to extract the key would result in the destruction of the key before the intruder could get to it.
This specific attack allows one of the two security officers to extract the 3DES keys, and only involves 20 minuts alone with the crypto card, and about 2 days of offline compute time with commonly available FPGA hardware costing $1000.
This attack is possible due to two things:
1. Known plaintext attacks put the odds in the attacker's favor. With the $1000 FPGA board, you can find a single DES key by brute force in 70 years. (Now $250,000 can get you custom hardware that will find a DES key in days, but this attack is more interesting in that the average IT professional can afford it.) But if you can have the crypto card generate 16,000 random keys, and can encrypt the number 0 with all 16,000 keys, then the time to find just 1 of the 16,000 DES key drops to about a day.
2. CCA has what seems to be a rather nasty flaw. Keys can be exported in encrypted format. Now it allows DES keys to be exported encrypted with DES keys, but requires 3DES keys to be exported by encrypting with 3DES keys. This in itself is good. But the flaw is that you can have the system generate a 3DES key in DES compatibility mode (where the first 56 key bits = the last 56 key bits.) The system considers this type of 3DES key to be low security. But you, as a security officer, can then enter a 112 bit 3DES key (high security), XOR the two keys together, and use this to export 3DES keys. This lowers the system security for 3DES keys from 3DES level (likely not possible to attack) to DES level (trivially attackable.)
This type of attack is an "inside job." A random attacker can't do it. It requires that the attacker is (or has compromised passwords of) one of the two security officers. But it means that the escrow of keys between two people is invalid, as either person can access the keying information with a small amount of brute force computing power.