Recently, I read the VISA payment standards and found something interesting about how VISA generate cryptogram when making a payment. The specification is available online at http://www.scribd.com/doc/87334890/Visa-VIS-Specification-15-May-2009#scribd.
So when making a payment, the circuits need to generate a cryptogram to authorize the transaction. A transaction usually contains the information such as the authorized amount, currency type, et. al. More details are available in the VIS document. Then the card need to generate a cryptogram so the server can verify the transaction. Simply to put, the circuits calculate a MAC of the transaction data using the limited use key (LUK). A straight forward way to do this would be using HMAC, but VISA specified their own cryptogram algorithm which is a CBC-MAC based on DES (DEA in the graph). The Algorithm is shown below. So basically, the transaction data is first encrypted using DES-CBC. At the final stage, the output is then encrypted using a second key KB using the DES decryption mode, and then re-encrypted using KA and finally O7 as the cryptogram. This is looks like a CBC-MAC_ELB (encrypt last block). All looks fine. My questions is that since a single DES block cipher is only 56bits secure. Does that mean O_5 is only 56bits secure? Suppose that there are only two blocks of data (D1 and D2), the attack may be able to forge a second message by flipping one bit in D2, noted as D2' and exhaust all possible value of D1, noted as D1' such that DEA(D1) XOR D2 == DEA(D1') XOR D2', the attacker only need to try 2^64 times to forge this new message. I don't think this will pose any practical attack because a single LUK key probably will never be used that many times. But the algorithm is weak.
So when making a payment, the circuits need to generate a cryptogram to authorize the transaction. A transaction usually contains the information such as the authorized amount, currency type, et. al. More details are available in the VIS document. Then the card need to generate a cryptogram so the server can verify the transaction. Simply to put, the circuits calculate a MAC of the transaction data using the limited use key (LUK). A straight forward way to do this would be using HMAC, but VISA specified their own cryptogram algorithm which is a CBC-MAC based on DES (DEA in the graph). The Algorithm is shown below. So basically, the transaction data is first encrypted using DES-CBC. At the final stage, the output is then encrypted using a second key KB using the DES decryption mode, and then re-encrypted using KA and finally O7 as the cryptogram. This is looks like a CBC-MAC_ELB (encrypt last block). All looks fine. My questions is that since a single DES block cipher is only 56bits secure. Does that mean O_5 is only 56bits secure? Suppose that there are only two blocks of data (D1 and D2), the attack may be able to forge a second message by flipping one bit in D2, noted as D2' and exhaust all possible value of D1, noted as D1' such that DEA(D1) XOR D2 == DEA(D1') XOR D2', the attacker only need to try 2^64 times to forge this new message. I don't think this will pose any practical attack because a single LUK key probably will never be used that many times. But the algorithm is weak.
This also reminds me about the text book question about CBC-MAC, so basically, to generate a correct CBC-MAC, the following condition must be met:
- The initialization vector must be zero. This is counter intuitive since when encrypt using CBC mode requires the initialization vector to be random other wise the attacker may guess if the same initial block is transmitted twice. However, in CBC-MAC case, if the iv is random, then the attack can easily forge a new message such at (iv' XOR m1' == iv XOR m1) which break the existential unforgeable requirements.
- Only the last cipher block is used. Other wise, the attacker could inject another block of data.
- Handling variable length properly using one of the following technique: 1) prepend the length of the message. 2) encrypt the last block so the attacker can not chain new blocks of data. 3) input length separation.
- hm..., why not use HMAC?