The article summary is dreadfully inaccurate and most of the comments are likewise inaccurate.

EMV does not support end-to-end card to issuer, or issuer to card encryption. The PCI data security standards (separate to EMV) do provide for point to point encryption, but that's not end to end encryption. EMV does nothing to ensure that "card data cannot be captured" (actually, it's quite easy to capture it; even the PIN can be transmitted in the clear in certain card simple card configurations; more complex card configs use enciphered PIN's). EMV does support three security levels (SDA, DDA, CDA) and only with SDA is it possible to clone publicly-accessible card data onto another card. Cards supporting DDA and CDA (SDA is deprecated in many countries outside the US) require more terminal processing and the data on the card cannot be cloned to another card.

EMV does provide what's effectively a DES-based transaction hash using a card-unique key which the card generates (to hash the transaction details) and which the terminal then sends to the cardholder bank which first tries to authenticate the hash, before checking if the rest of the transaction is good to go. And if all's good, the cardholder bank then generates a response hash which authenticates the transaction response back to the card. That stops man-in-the-middle attacks. Cards also use a sequential transaction serial number (ATC) to stop replay attacks. The card's unique key used to hash request and response data cannot be accessed and is one of three different keys used to hash different classes of request and response data.

There's a lot more there and most of it is publicly available from books one to four of the EMV standards, freely available from http://www.emvco.com/

Jerry Irvine is wrong on most of the points he makes. Just to correct some of them:

1. The PAN (the primary account number) is not enciphered on a chip card.

2. If you have a chip reader and easily-found software, you can recover the card PAN easily and quickly.

3. Cards do not provide support for "unlimited number of transactions" - as almost all cards have amount and velocity limits.

4. Most transactions will go online to the card issuing bank for authorization - allowing for lost and stolen cards to be blocked.

5. Each purchase with a chip card does not "create a separate token". He appears to be confusing tokenization with cryptography, though it's hard to know exactly what he means.

6. Issuing banks do not create tokens. Instead, they are created by a Token Service Provider, usually an independent third-party.

7. A partial EMV implementation would have mitigated against certain segments of the Target fraud. A full implementation, with PCI, industry-wide, would have mitigated against much more.

8. Mobile payment systems, in general, today, do not provide higher levels of security than chip cards.

Documentation on most of the above is freely available from EMVCo's website at http://www.emvco.com/

Mr Irvine's four minutes are, as a whole, inaccurate and unhelpful.

Tovarishch, that is why is called interNYET,

Yep, still using VC6 ten years and half a million lines of C++ later. Don't want to, but heavens above, it's a productive, fast and rock-solid environment. I've installed the later compilers and got my gear up and running. Kind of. But the later compilers feel flaky, jerky and brittle. And none of them have ClassWizard, which which you can drive with the keyboard. Fast.

I'll install VC2010 and who knows, perhaps I'll switch. I'd like to, but MS, please make it easy!