Slashdot Mirror

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/

Maybe. Maybe not.

Remember that these chips are extremely low power low speed.

They have to perform usually a cryptograhic hash of some input they are passed with their secret key. The algorithm used is not a fully secure algorithm like what would be used in https, it's not NIST approved etc. They are custom algorithms designed to be done by a very simple processor very quickly and are orders of magnitude easier than AES or SHA.

Incorrect. Card cryptograms are generated with either 3DES or AES. You can see full details here: https://www.emvco.com/specific.... Specifically, you want to look at Annex A of EMV 4.3, Book 2, "Security and Key Management".

Note that many of the card issuing networks define their own variations on the EMV specifications, but they all comply with the general framework, algorithms, etc.

As for the nature of the processors, most contactless smart card chips today are 32-bit CPUs running at around 40 Mhz, with several KiB of RAM and a few hundred KiB to a MiB of flash. They're low powered in comparison to the desktops and laptops we use today, but they're far more powerful than the high end computers I started with. They're even orders of magnitude more powerful than their predecessors which were in use when the EMV specifications were written, and those earlier generations could handle it. So today's are clearly perfectly capable of executing AES or 3DES operations in a short period of time... particularly since they all include dedicated coprocessors for that purpose. The coprocessors aren't necessary from a performance or power consumption perspective, they're used to defeat side channel attacks, but they do make the cryptographic operations faster and cheaper.

That involves RFID and/or NFC, right? How does "add wireless stuff to it" make any system at all more secure over an overt and obvious physical interaction?

Apple Pay and Android Pay both implement tokenization for their contactless systems, which is significantly more secure than non-tokenized transactions, physical interaction or not. The massive Target hack, for example? Wouldn't have worked on tokenized transactions.

Tokenization is part of the EMV Payment Specifications so it could be implemented in physical chip transactions as well. Might have been, I'm not sure off-hand. But Apple Pay in particular got a lot of press for being the first implementation of contactless EMV tokenization.

You mean the EMV chip and/or contactless standards?
https://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.

The EMV web site disagrees with you. Just because they used existing communication standards for their specification doesn't mean it's not contactless EMV.

EMV has nothing at all to do with RFID cards

Yes, it does. EMV specifies both a contactless and a direct chip contact method. It just so happens that contactless EMV matches the specifications of PayPass and PayWave. Which makes sense, considering they are the M and V of EMV.

Short answer - tokenization and eCommerce security.

Chip and Pin uses physical contact of the card to the payment terminal. The chip is very hard to duplicate so it essentially eliminates card cloning. The PIN provides a second factor to authenticate a trusted customer at the point of sale.

Apple Pay is a variant of NFC (near field communication) much like Google Wallet with PayPass. This is wireless (contactless).

The specifications for hardware (Level 1) and software (Level 2) for both contact and contact-less payment systems are managed by EMVCo; see http://www.emvco.com/. Apple has chosen wisely to work with existing industry standards with a couple of big improvements. These guys are smart and they got it right.

What is different about Apple Pay is that unlike PayPass and Chip&PIN which send the credit card account number through all links in the system (usually encrypted), a one time use token is created. If an Apple Pay transaction is exposed, only a useless one time token would be divulged. This is much like the DUKPT system used from other secure transactions. If you are curious about DUKPT see en.wikipedia.org/wiki/Derived_unique_key_per_transaction.

Aside from the technical superiority of tokenization for security over Chip&Pin for card present transactions, how Apple Pay is better is a matter of taste because both systems mitigate card present fraud. It will always be hard to argue that either will be faster than a swipe.

I'm sick of sitting on my fat wallet and if I could get rid of my cards that would be great. Unfortunately I'll still need my cards because most places wont take anything but mag stripe for years (its taken Canada 7 years to get to 90% Chip&PIN at the merchants). If I lose my wallet I have to call a bunch of companies, whereas if I lose my phone nobody is going to get my card numbers. Apps will proliferate that allow loyalty programs and discounts to be offered to me through mobile integration (e.g. Amex has already announced buying McDonalds food with points). Geofencing in conjunction with NFC will further promote targeted marketing and I like the idea of saving money in exchange for loyalty. NFC will also likely be used to do things like open doors, start cars so it will be very convenient.

Apple Pay also supports tokenization for eCommerce. This is huge because card not present is the area where credit card fraud is most persistent. Apple Pay and the variations that are sure to follow will knock the online card fraud guys out of the game.

Full specifications are available. There is no security through obscurity here.

Actually, it is obscurity. The specification you linked to was NOT followed by the device manufacturer, they just assumed since they didn't tell anyone they violated a proper practice that no one would notice. The specifications listed by you requires devices to adhere to the random number generating requirements outlined in ISO 18031, which the machines did not. This standard mandates a unpredictable entropy source be used as the seed for any random number generating function. The devices were implementing the use of date and time as a seed. This is what a lot of kids are taught in school for computer class, but any cryptographer is supposed to avoid.

Full specifications are available. There is no security through obscurity here.

Doh, managed to delete the rest of my post before submitting. I guess I should actually look at the preview.

Anyway, the problem here isn't obscurity, it's just implementation errors. Granted that the systems should have been audited.

Full specifications are available. There is no security through obscurity here.

The "new" system is the EMVCo Smart Card (CHIP and PIN), and most of the western world already has this in place since 1999.

For some reason, the US believes that check (cheque) and credit card fraud is still manageable.

See EMVCo FAQ and Wikipedia CHIP and PIN

You're right if you look at most of the contactless payment mechanisms that have been deployed in the US. They are what I would call RFID, not contactless smart cards, and they're dumb, and replayable.

You're wrong if you look at what has been deployed in other places, and if you look at the standards that have been defined for contactless payment. Contactless smart cards are full-blown microprocessor cards, with secure storage, key management capabilities and support for strong encryption, both symmetric and asymmetric. One of those cards plus secure EMV transactions (I say "secure" because EMV defines several levels of security, and the lowest aren't very good) and a card-verified PIN is very secure indeed. Vastly better than magstripe. And, believe it or not, it is completely possible to perform a strong mutual authentication and a secured transaction in < 200 ms, which is as long as it takes to tap the card on the reader.

With respect to contact vs. contactless, the difference is irrelevant from a security point of view. The key to making either secure is (a) using an adequately "smart" and tamper-resistant chip, and (b) using well-designed transaction protocols that make appropriate use of cryptographic operations.

The current trend in the US financial industry is, unfortunately, focused on low cost of chips and maximum convenience. Note, however, that the low level of security doesn't affect the cardholder that much, because as it is now the cardholder is not liable for fraudulent transactions. It's the banks and merchants that absorb those costs, and if they'd rather save money up front on secure hardware and pay for it later in fraud, that's their business.

What may reverse that trend, even here, is the possible upcoming shift to NFC devices for payment, rather than contactless smart card or RFID. NFC is basically the idea of putting a smart card RF transceiver in your cellphone, plus one or more secure processing units (which look a lot like smart card chips). Given the fact that the difference between using a powerful, high-security secure processor and a cheap, low-security one is a couple of dollars, it makes a lot less sense to go the cheap route when you're embedding it in a $100 phone. When you're looking at a plastic card, a price increase of $2 means tripling the price of the card.

Time will tell if we actually do go that way, but consumers, banks, merchants and mobile phone service operators all like it, so the odds are good.

Sorry for the pompous post heading, but the first part is true, I wrote a large part of Tesco's system including about half of the EMV processing component. It's a customised version of what was the world's first integrated EMV system (ie card reader + PC + store level auth servers + central connection to VISAnet, LINK etc).

Whether you should listen to me or not is another matter.

The chip controls the transaction. That's how it goes. The chip decides if it can trust the terminal or the bank based on cryptographic signing operations. The terminal is verified by a process in which it concatenates various pieces of data, performs a crypto op on them and presents the result to the card. The card compares this to its own result (depending on the card it either has one precalculated and uses the same one each time (low security) or does the same calculation itself on a set of data including some session data (better security)).
PIN is encrypted as soon as it is entered and should never leave the device it's entered on in plaintext form, it is presented to the card as a cryptogram for validation.
When a transactioon is presented to the bank for authorisation it is presented with yet another cryptogram so that the bank can validate the card. The response also comes in the form of a cryptogram so that the card can validate the bank.

However, I'll agree, all this is pretty useless if someone can get inside the terminal and intercept the PIN at hardware level. Other than that and the looking-over-shoulder social security hole problem, EMV's pretty bullet proof. Your PIN doesn't ever even get to the PC that's running the transaction.

If you want to know more then the actual standards are available at EMVco, but they're the nearest thing to legalese I've ever encountered as a software Dev. I'm out of the payments game now, but my knowledge should still be pretty relevant, I hope.

and they have to transfer the PIN from the keypad to the card via the terminal that has the mag stripe data.

No, the PIN will never leaves the PINpad. The PINpads must be type approved by EMVco http://www.emvco.com/ A hash of the PIN is passes from the terminal to the PINpad which validates the PIN supplied by the customer. A signal is passed back to the till which confirms the PIN was valid.

There are strict restrictions placed on the retailer as to how much of the card data can be saved or logged.

Two Factor Authenticationis not the only part of the problem. It does helps a lot for strong authentication of the client. Some other important parts of the problem are:

1. Mutual Authentication. Short term, need to have the FI display something unique which helps the user tell for sure they are connected to who they think they are connected to. Longer term, need changes to Firefox and IE6 (which for me means 95% of my customers) so that the PKI credentials for the FI are displayed.
2. Need to be able to ask the client if I can query their computers status, and make sure that they have a current patch level and decent AV and Spyware protection. So, need to ask Linux and Windows (or other products installed on Windows and Linux) to provide capabilities, because I do not want to download code. After all, not my business. Could request this function with a special HTTP header.
3. Mid term to long term, I love the idea of a second factor (USB attachment) which supports PKCS#11 / PKCS#15. This, along with #1, prevents MITM attack.
4. Everywhere in the world, except maybe theU.S., we are rapidly rolling out EMV and VIS. So, we are going to have Smartcards in everyone's wallet, that will be a key part of the 2FA problem. Just need a small portable USB device to support a USB interface to the card. So far, I am having trouble with this, need something small enough to hang on your keychain. Wait a year or so, someone will build it.

On the server side, need to make some changes as well.

1. Proper support for tiered authentication. So, you can access less dangerous functionality with less authentication
2. Base the entire thing on a decent RBAC approach, so I can administer and keep track of what is going on. Note, DSD gives me a decent way to model tiered authentication.
3. Need to build a proper authorization framework so that the requirements for both a proper authentication tier and even a signature (OTP, Digitial Signature) on specific transactions can be enforced.

The bottom line:

1. The stronger the authentication of the client, the better. As we move towards 2FA, lets be careful to not make any stupid biometric decisions. Biometrics should only be used to gain access to the hardware second factor, for instance via a thumbprint. Then, it the second factor gets stolen, we just revoke the token; we do not need to cut off your thumb!
2. Mutual authentication. Not only does the client need to prove who they are, the FI needs to prove who it is. Some cool stop-gate things with GIFs and stuff are possible, but in the middle and longer term, changes to the browsers (the two that dominate my customer base are Firefox and IE)
3. Assurance the PC is protected. If you will excuse me the vanity, I will riff on "Clarke&'s Third Law", name it "Cameron's Law&", and state that "Any sufficiently infested PC cannot be protected from allowing the customer to be scammed". Frankly, I was really hoping that the Fed would step up to that in its

Along with PKCS#11 and Javacard, you should be looking at all the ISO 7816 specifications for technical information.

The ISO 7816 specs are generally not free. You buy them from your national standards body, which in the US is ANSI. It'll cost around $150-$200 to buy the whole set from ANSI.

However, much of the content of the 7816 documents is replicated in the EMV specifications. EMV stands for Europay Mastercard Visa and is a consortium for establishing smart card banking standards, so if you're interested in looking at your bank card chip, that's the more relevant set of documents anyway. You can find all of the EMV documents on-line, free, at the EMVCo web site. You may still have to acquire some of the 7816 specs (parts 3 and 4 are probably the most important), but the EMV docs contain most of what you need. Word of warning: be prepared to plow through a lot of material. Smart card technology has acquired a lot of complexity through 30 years of incremental enhancements.

wouldn't it be interesting if this were to cause a groundswell of support for the recently proposed RFID credit cards?

First, they're not RFID cards, they're contactless smart cards, which are a very different. Different frequency, different range, different capabilities, different protocols, and very different security.

Second, smart card credit cards are a good thing, and you as a credit card user should want them because they'll reduce fraud. Granted, the banks and merchants mostly bear the brunt of the fraud, not the cardholder, but since all of the money ultimately comes from our pockets that's a distinction without a difference.

Finally, your implied notion ("ack") that contactless smart cards are a bad thing for cardholders shows that you don't know anything about them. A fully-implemented EMV card:

1. Won't divulge any data other than a public key until after your PIN has been presented to it in a secure (mutually-authenticated and encrypted) session.
2. Allows transactions to be conducted off-line, making your checkout quicker for low-value transactions.
3. Can make decisions about whether or not transactions should require a real-time connection back to your bank to verify the account status. This counters the increased fraud opportunity provided by the greater convenience of fast transactions.
4. Provides very strong authentication to the transaction, making it nearly impossible for a thief to perform a "card-present" transaction without actually obtaining your card (and PIN). "Skimming" is the #1 type of credit card fraud, and these cards eliminate it.
5. With card readers built into PCs, offers a mechanism for doing "card present" on-line transactions. This will reduce the card fees paid by on-line merchants, which will (after a delay, probably) reduce your costs as well. Oh, and you can also use an EMV card to make logging into your bank's web site easier and more secure.
6. With an additional calculator-like device (or a PC and reader), offers a mechanism for doing secure over-the-phone transactions as well. Maybe in the future the cards will have a display and PIN pad integrated right into the card, eliminating the need for the extra device.
7. Offers credit card issuers to provide "value added" services on the chip. It's not clear how valuable this is; at present they're talking about things like storing your bookmarks on the card, so that you can carry them with you. It's possible that other, more useful, ideas will arise.

The security in these cards is very well thought-out and banks have zero interest in intruding on your privacy, because it would piss you off. If you don't believe they're careful with your privacy, consider the fact that they already know about every purchase you make with any credit card -- how often do you get marketers calling you because they got information from your bank about a recent purchase you made on your credit card?

If you don't care to believe me about how the security is designed, please review it for yourself. Complete EMV specifications are published on the EMV web site at http://www.emvco.com.

I'm a security expert of sorts -- and fairly paranoid by nature -- and the main concerns I have with this technology will arise if the US banks decide not to fully implement the technology.

1. They may decide that cardholders like signature authorization and don't want PINs. That would mean the card would have to be willing to communicate with anyone and it would become possible for handheld readers to collect card numbers in a crowd. Personally, I would love to use a PIN rather than signing. Signing is slow, and inherently must be done at the end of the process, meaning it can't be parallelized. With chip and PIN, I can insert my card and enter my PIN while the cashier is still scanning my items. As soon as (s)he's done, the transaction can be executed, which takes <2 seconds, including printing th

One of the biggest values of such a solution has to do with Micro-Payment. How many times have you turned away from a drive-through because the lineup is too long. This class of business needs to be able to process an order (including settlement) quickly. The more orders they can put through in an hour, the more revenue the business generates.

Typically, this sort of transaction will also be done offline. This will allow the business to batch process their transactions at the end of the day, saving on transaction fees.

Don't get me wrong, Visa isn't being altruistic in this. The more they can encourage people to move away from debit or cash, the more credit transactions they process and the bigger the interest earning bills.

Hey, Visa, if you think your RFID system is so secure, publish all the nice technical details on how it works, so we can be confident of its security.

They're all published and available.

The basic chip and communications specifications are contained in ISO 14443. It will cost you a few dollars to buy a copy. You purchase your copy from your national standards organization; if you live in the USA, that's ANSI and they charge $18 for each of the four parts. The fee isn't to keep this stuff out of your hands, by the way, *all* ISO standards are copyrighted and cost money to obtain. That's how they fund the standardization and publication processes.

Above that basic level, most of these cards will be Java Cards. You can get the specifications for Java Card from Sun. They're free.

Moving up, most of these cards are also Global Platform cards. GP defines an extra set of features above Java Card, mostly to specify security-related characteristics. The specifications are found at the Global Platform web site.

In Visa's case, their recommended smart card platform is the IBM JCOP. You can find the details of IBM's implementation of Java Card and Global Platform here.

Note that not all issuing banks will use Java Card, or even a programmable card. Visa's recommended non-Java platform is the IBM MFC card operating system. I don't think the MFC team has a web site.

Finally, the actual payment application, and the component that matters most from a security perspective, is EMV. You can find complete EMV specifications at the EMVCO web site. The specs are mostly written towards contact smart cards, not contactless, but good smart card protocol designers *always* assume an attacker can get between card and reader, whether it's directly connected via a contact plate, or whether it's over RF, so the contact-oriented security does just as good a job in contactless mode.

Regarding signatures or no, it's not clear yet how that is going to be handled. EMV provides for several modes of operation, the best being "chip and PIN", which is what's being deployed in the UK right now (with contact cards, not RF). In that mode, you provide your PIN to the card reader through a PIN pad, and that unlocks your card to perform the transaction.

EMV also allows chip and signature and chip-only (as well as providing for fall-back modes that don't use the chip and rely on the magnetic stripe or even on getting a carbon copy of the embossed card number). The decisions about which mode to require will be made by individual banks issuing cards.

There is a lot to EMV... so you've got a few weeks worth of serious work cut out for you if you really want to understand it all, but the information is public and peer-reviewed. The countries that have deployed EMV have seen card skimming fraud drop to zero. That's right, so far, there has been no known case of an EMV card being faked or duplicated, and as far as I know, no one has deployed cards with DDA (dynamic data authentication) enabled. They're all SDA (static data authentication), which carry digitially-signed but static data on the chip which is read out every time. The US banks are talking about doing DDA, which involves a cryptographic challenge-response protocol and is vastly harder to duplicate.

At, say, $24 each, in a large crowd, you could amass quite a bit of money, and many people would never know it happened.

LOL. Dude, think about what you're saying. Credit card transactions are completely auditable. When dozens of people complain that they didn't authorize those $24 transactions, the issuing banks are going to go back to the merchant who performed them, and his acquirer is going to notice the extraordinarily high level of complaints, *and* that they're all for sub-$25 transactions. The theif will be in prison very shortl

The technology to do this already exists. The EMV specifications already allow for multi-application cards. This could already be done for payments but is not.

Visa and Mastercard don't make use of it for the simple reason of branding - you can't promote your brand with a generic looking card. In this day and age, company branding is more important than user convenience.

Smartcards will be mandatory in a few years time. See EMV.

To everyone spouting nonsense like "smart cards are insecure - I used to hack my phone card", "why we should jump at -every- new technology", "smart cards never amounted to everything" etc, etc. Read the documents at EMVCo website and see for yourself which technology is used in such cards. Also, the point of EMV smart cards is not storing some amount of digital cash on it. The main point is avoiding fraudulent transaction repudiation (as each transaction carries digital signature called transaction certificate you can't claim that you didn't make a transaction when in fact you did) and the ability to make transactions offline (using offline PIN code). So at least in Europe both VISA and Mastercard are phasing out the magnetic stripe cards.

As others have said no system is totally secure, but this ups the bar from needing a few household items to clone a mag stripe card to needing millions worth of electron microscopy to clone a smart card.