When you transact with an EMV payment card (a “Chip and PIN” card), typical UK operation is for the bank to exchange three authentication “cryptograms”. First comes the request from the card (the ARQC), then comes the response from the bank (the ARPC) and finally the transaction certificate (TC). The idea with the transaction certificate is that the card signs off on the correct completion of the protocol, having received the response from the bank and accepted it. The resulting TC is supposed to be a sort of “proof of transaction”, and because it certifies the completion of the entire transaction at a technical level, one can presume that both the money was deducted and the goods were handed over. In an offline transaction, one can ask the card to produce a TC straight away (no AQRC and ARPC), and depending on various risk management settings, it will normally do so. So, what can you do with a TC?
Well, the TC is sent off to the settlment and clearing system, along with millions of others, and there it sits in the transaction logs. These logs get validated as part of clearing and the MAC is checked (or it should be). In practice the checks may get deferred until there is a dispute over a transaction (i.e. a human complains). The downside is, if you don’t check all TCs, you can’t spot offline fraud in the chip and pin system. Should a concerned party dispute a transaction, the investigation team will pull the record, and use a special software tool to validate the TC – objective proof that the card was involved.
Another place the TC gets put is on your receipt. An unscientific poll of my wallet reveals 13 EMV receipts with TCs present (if you see a hex string like D3803D679B33F16E8 you’ve found it) and 7 without – 65% of my receipts have one. The idea is that the receipt can stand as a cryptographic record of the transaction, should the banks logs fail or somehow be munged.
But there is a bit of a problem: sometimes there isn’t enough space for all the data. It’s a common problem: Mr. Fermat had a truly marvellous proof of a proposition but it wouldn’t fit in the margin, and unfortunately while the cryptogram fits on the receipt, you can’t check a MAC without knowing the input data, and EMV terminal software developers have a pretty haphazard approach to including this on the receipts… after all, paper costs money!
Look at the following receipts. Cab-Inn Aarhus has the AID, the ATC and various other input goodies to the MAC (sorry if I’m losing you in EMV technicalities); Ted Baker has the TC, the CVMR, the TSI, TVR and IACs (but no ATC), and the Credit Agricole cash withdrawal has the TC and little else. One doesn’t want to be stuck like Andrew Wiles spending seven years guessing the input data! Only at one shop have I seen the entire data required on the receipt (including CID et al) and it was (bizarrely) from a receipt for a Big Mac at McDonalds!
Now in case of dispute one can brute force the missing data and guess up to missing 40 bits of data or so without undue difficulty. And there is much wrangling (indeed the subject of previous and current legal actions) about exactly what data should be provided, whether the card UDKs should be disclosed to both sides in a dispute, and generally what constitutes adequate proof.
A “fake” transaction certificate
But most worrying is something I observed last week, making a credit card purchase for internet access at an Airport: a fake transaction certificate. I can tell its a fake because it firstly its the wrong length, and secondly, it’s online — I only typed in my card number, and never plugged my card into a smartcard reader. Now I can only assume that some aesthetically minded developer decided that the online confirmation needed a transaction certificate so took any old hex field and just dumped it. It could be an innocent mistake. But whether or not the “margin was too small” to contain this TC, its a sad reflection on the state of proof in EMV when cryptographic data fields only appear for decorative purposes. Maybe some knowledgeable reader can shed some light on this?
I’m not convinced this is an EMV transaction certificate at all – I think it’s just something relating to the web payment handling system.
Here’s a video showing the merchant’s interface to the Atos SIPS system (the one you used in the airport). Looking at this still for a merchant-entered transaction It gives an authorisation number (6 digits) and a payment certificate (10 digits). Both look decimal, but that could just be chance. This is a Carte Bleue transaction.
Meanwhile here’s a still showing cancelling a transaction. This has a 12 hex digit transaction certificate. This can’t be anything to do with EMV, because the card typically isn’t involved in cancellations.
Not everything that says ‘Transaction certificate’ is necessary an EMV TC. It may just be the online certificate received back from Visa/Mastercard/etc when it said the transaction between the merchant system (Atos SIPS) and Visa is OK.
You have a point, though, that context-free strings of hex digits are opaque to anyone except the bank, which doesn’t help if you wish to dispute a transaction or even understand what’s going on.
True, EMV doesn’t have a monopoly on the words “Transaction Certificate”. There’s an argument which says clearly it must be there for a good reason, and its unlikely to be pure invention. But then this surely begs the question… what reason?
Even if we cynically assume that the bank is doing this entirely for their own benefit and they don’t give a damn about customer/merchant disputes, then what purpose does a hex string on its own provide? All I could think is that it helps match up disparate records. But such a field is normally called an ID or UID, not a “certificate”, which implies some crypto going on.
If there’s one thing I’ve learned from 3 years in industry its that the world of electronic payment cannot fit into any one persons head alone… there’s just too many regional variations, dirty hacks, smart ideas, etc etc.
Mike
Minor point, but at the end of the first paragraph you refer to AQRC – is that meant to be ARQC?
Great now I have to go looking through all my receipts, that’s cool 🙂
Honestly, I’m surprised more transactions aren’t securely hashed and stored semi-publicly like this. Any word on what the algorithm is — part of an MD5 maybe, or if it’s even a recognized secure algorithm?
Therefore a tc number authenticates approval of a transaction even if the transaction says declined.?
Does the presence of an ARQC categorically prove a Chip and PIN transaction or just that thegenuine card was present. Would there be an ARQC if the transaction was Chip and Signature.
@kendo
An ARQC shows that a chip card was probably used. It doesn’t prove that the genuine card was used (to do that, the ARQC needs to be verified, using the card’s unique derived key — UDK).
There will be an ARQC for a Chip & Signature card, but one of the fields — the issuer application data (IAD) — will state whether the PIN was successfully verified.
Could I ask you one question…
who is the responsible to fill field 44 in the response message; the issuer or the acquirer
look for this case;
Visa send us request message for online authentication contain field 44, but in the response there is a missing bits in field 44 which is 44.8
how does this bit filled in a correct value ??