Introductory Musings
This doesn’t have to do too much with enterprise security, but since I did the research I figured I might as well write it down. I haven’t worked as a PCI assessor for the past three-or-so years (and obviously never in Europe ;-)), but some questions about EMV cards of the more technical nature were floating around in my head. Mainly I was wondering how crypto is used to facilitate the functions introduced by the EMV specifications.
There are plenty resources available online, so this is more or less just a summary of what I was curious about. I will spare you the usual basics introduced by and discussed in all those plenty of news articles generated by the current push to introduce chip cards into the US market and the motivating breaches that generated attention beyond the security community.
The end goal of using EMV technology, as usual, is obviously to authorize transactions that are initiated by the cardholder at a point-of-sales terminal, i.e. during card-present transactions (online and offline). The technology in the embedded chip (ICC) is supposed to reduce the potential for fraud, in particular as a result of theft of cardholder data (such as the card number and verification data).
Chip cards do not offer benefits for e-commerce (card-not-present) transactions unless the cardholder is supplied with a physical card reader for their PC that is then used to access the chip during the Internet transaction, turning it into sort of a card-present transaction. Obviously, if the cardholder enters the PAN (card number) and verification data by hand into a web browser, it is subject to the usual threats of exposing those on their way from a local device to the acquirer through the interwebs.
From a historic point of view, a lot of the basic functionality in the EMV specifications emphasizes the increased security for offline transactions, i.e. card-present transactions where the card terminal at the merchant location doesn’t “dial up” to the acquirer for an online authorization, because that’s slow and costs money. Rather, card-present fraud is significantly reduced by a number of measures that allow the local terminal / point-of-sale system (POS) to establish trust into the card (and cardholder), and allow the POS (and the card!) to authorize transactions that meet certain criteria. These days, avoiding online authorizations isn’t quite as much of an issue in many of the interconnected places of the world anymore, but this explains why ― for example ― the basic card authentication mechanisms are all designed to work offline. (It used to be the norm that, in particular smaller, merchants would collect their transactions offline during the day and then forward them at some point in time to their acquirer in batches.)
So let’s look at the mechanisms introduced by EMV for card authentication, cardholder verification, and transaction authorization. And how they are implemented from a cryptographic (key management) point of view, which is what I was wondering about in the first place. (There are other aspects we won’t look at ― scripts for updating chips remotely, etc.)
Disclaimer: I synthesized most of this information from the EMV Specifications and other information publicly available on EMV’s website. I’m not privy to any card manufacturer’s, brand-, or issuer-specific information, and beyond the basic EMV specifications those institutions certainly have options available to them to implement alternative / additional mechanisms in the applications they put on the cards that might not completely match the picture I’m painting below. 😉
Card Authentication
Most of the card authentication means built into the EMV specs deal with authentication of the card in card-present, offline transactions. In other words, the (trusted, tested, certified, approved, etc. :-)) terminal (and not the issuer) authenticates the card. In online transactions, the authentication of the card is built directly into the messages exchanged by the card, terminal, and issuer (etc.) for authorization, and whether or not any of the offline card authentication mechanisms are executed in this case is sort of left to the particular environment. (I believe most networks in the US might require it regardless?)
Three authentication types are defined:
- Static Data Authentication (SDA)
- Dynamic Data Authentication (DDA)
- Combined DDA/Application Cryptogram Generation (CDA)
SDA authenticates static data put onto the card by the issuer, which is not unique to individual cards, but only to a specific issuer’s application on the card. DDA and CDA authenticate ICC-resident data, data provided by the terminal, and data generated by the card itself, therefore providing for authentication of the card in one unique situation.
Which of these authentication mechanisms is performed basically depends on the least common denominator between card and terminal. In order of priority, the preference (if supported by both) is specified as CDA – DDA – SDA.
Functionality on ICC cards is organized into applications. Typically, you will find one application on an EMV card ― the card-type-specific application for a particular brand. (For example, a VISA credit card application.) Theoretically, the EMV specs allow for multiple applications on a card. For example, both a VISA credit card and a MasterCard credit card application on the same card, with the cardholder being able to choose (through the terminal) which one they want to use in a particular situation. Or maybe a credit card application and an application that generates one-time passwords for general authentication use in computing environments ― wouldn’t that be handy? But I’m not sure that the personalization of cards with more than one application is practiced much these days. (Of course, this becomes more interesting once we start talking about mobile applications and NFC-enabled smartphones ― loading banking applications onto cards that are also used as SIM-type cards in smart phones, etc.)
Applications (particularly, some static application data) are signed with an issuer’s key, which a certification authority operated by the payment system has issued a certificate for. Card ICCs then provide to a terminal the certificate for that issuer’s key, as well as the signature for the static application data that was stored on the card with the application during personalization of the card. Terminals contain the public keys of CAs and are thus able to validate both the issuer’s certificate as well as the signed application data provided by a card. Which is referred to as SDA.
In DDA (and CDA), the ICC has its own keypair that allows it to sign dynamic requests from the terminal, rather than just presenting the signature for parts of the application data that were signed by the issuer. (Static application data, in this case, is included in the certificate for the ICC’s keypair.) Requests to be signed include a list of data elements selected by the terminal, as well as an “Unpredictable Number” generated by the terminal.
DDA is performed before any transactions are processed; CDA is executed as part of messages exchanged by the terminal and ICC to process transactions, thus assuring that the individual ICC responses have been generated by the ICC in question.
The algorithms specified for all of this (CA keys, certificates, signatures, and their validation) are RSA with a maximum length of 248 bytes (not bit!) keys and SHA-1.
Cardholder Verification Methods
OK, we have authenticated the card, but how do we establish that the human presenting the card to the terminal is in fact the authorized user of that card? Traditionally, in the US, this happens by signature (shudder) for credit transactions, and by PIN for debit/ATM transactions.
This is likely not going to change much as a result of the introduction of EMV cards into the US market. The card brands have no current requirements to move credit card transactions to PIN authentication, although some brands offer incentives for supporting PINs in addition to signatures. (Although this news article claims that PINs might actually be the future.) According to Computerworld, in about two dozen countries a PIN isn’t required.
The four cardholder verification methods (CVM) defined by the EMV specs are:
- Offline PIN (plaintext or encrypted)
- Online PIN – encrypted by PIN pad and sent to issuer for validation
- Signature
- No CVM
Combinations of these can also be used.
For (the encrypted version of) offline PIN verification, an ICC either owns a PIN Encipherment public key pair, or uses the key pair it owns for offline dynamic data authentication. The terminal obtains the PIN from the cardholder and, together with a random challenge provided by the ICC in order to prevent replay attacks, encrypts it with the ICC’s public key before passing it on for verification to the ICC.
For online PINs, the best I could deduce is that the messages formatted according to ISO 9564-1 are used for sending the PIN entered by the cardholder from the terminal to the issuer as part of authorization requests. For encryption of online messages, see below. The PCI’s PIN Security Requirements require the use of TDEA or an algorithm that’s at least comparable in strength for PIN encryption.
Transaction Authorization
For the authorization (or declination) of offline transactions, EMV specifies a sophisticated risk management program that both the ICC and the terminal are involved in. In particular, this includes:
| Terminal Risk Management / Terminal Action Analysis | Card Action Analysis |
|---|---|
| Based on parameters specified by the acquirer (and/or maybe the network?), the terminal performs: Floor limit checking: If a set amount is exceeded, go online for authorization. Random transaction selection: Select random transactions for online processing (can include a bias for higher amounts to go online more often). Velocity checking: Checks counters in the ICC for consecutive offline transactions to decide whether to go online. An action (offline approve/decline, or go online) is then determined based on other factors as well, such as whether CVM succeeded or not. | This is issuer-proprietary logic, and things like counters and limits for certain transaction types, issuer authentication results, etc. might be involved. The card’s analysis may actually result in responding to an offline authorization request from the terminal with a request to go online instead (or a declination of the transaction). In other words, it is not just the terminal that decides whether an offline transaction is authorized or declined. |
For online (and offline) transactions, and all other communication involved in transaction authorizations, the EMV specs define message formats. In the case of online processing, the most interesting ones are the ARQC (authorization request cryptogram) and ARPC (authorization response cryptogram). The former is generated by the ICC for inclusion into an authorization request that the terminal sends to the network. (The terminal also includes the PIN entered by the cardholder in case of online PIN verification.) The latter is the issuer’s response, which is processed by the terminal. The ARQC contains a card authentication method (CAM) allowing the issuer to validate the card’s authenticity. The issuer’s response, apart from an authorization decision, can include issuer authentication data that is passed on to the ICC by the terminal to allow the ICC to authenticate the issuer response.
When it comes to specifying key management and encryption methods for online processing, the EMV specs get a bit fuzzy. (Actually, they are probably perfectly clear if you have all the information necessary and the time to study it.) Basically, specifying this seems to be up to the payment system (i.e., the brand/network). What the specs suggest is that the ICC owns some sort of master key, which is shared with the issuer and used to derive session keys based on an application transaction counter. (The EMV Card Personalization Specification, then, specifies at least three 112-bit “master” keys for different purposes to be loaded onto the card, derived from a personalization master key.) Session keys can then be used to generate MACs over transaction request data, encrypt/decrypt data, etc. The generally recommended algorithm seems to be triple-DES for session data, with EMV allowing AES as an option.
Other Random Questions
Other questions I was wondering about…
So how is use of the chip enforced for cards that have both a chip and a magnetic stripe?
Cards have different service codes depending on whether they have a chip or not, defined by ISO/IEC 7813. If a card is swiped at a terminal, the terminal can recognize the service code encoded on the magnetic tracks and prompt the user/attendant to use the chip reader instead. Unless I am missing something, this also means that once I have obtained the cardholder data I could create a fake card with an altered service code that would not trigger the terminal’s attention? (But probably the issuer’s fraud system’s, in an online transaction?)
Edits:
2014-06-10: Editorial beautifications.
secuilibrium.com 