Payment cards are used for enabling and securing payment transactions. Payment cards based on Integrated Circuit Cards (ICCs) provide for comprehensive (and complex) use of authentication techniques. One of these techniques allows the authentication of the card to the merchant by the so-called offline Card Authentication Method (offline CAM). This technique is implemented by ICCs that are compliant with the EMV (Europay-MasterCard-Visa) standard (discussed more fully below).
Offline Card Authentication Mechanism
ICCs offer the possibility of using public key cryptography for card authentication. EMV defines mechanisms that enable the payment terminal to authenticate the payment card “offline,” that is, without requiring online communication to the card issuer during the transaction, and without requiring the card issuer and the terminal to share secret keys.
Such an offline card authentication is based on the ICC providing data that is signed, either statically or dynamically, by the private key of a party trusted by the terminal. This party is typically the card issuer or the card itself, and the trust relationship is established by having the terminal validate a certificate chain, up to a trusted root public key, which is owned by the payment system to which the issuer belongs.
The offline mechanism is either “static”, wherein the same authentication data is provided by the card to the terminal for every transaction, or “dynamic,” wherein the authentication data provided by the card will be different for each transaction. The EMV2000 specifications (discussed more fully below) define one static offline CAM, namely, Static Data Authentication (SDA), and two dynamic offline CAMs, namely, standard Dynamic Data Authentication (DDA), and Combined Data Authentication (CDA).
For SDA, the issuer pie-signs unique static card data using a private key to protect against alteration of the data after personalization. During a transaction, the terminal can retrieve this signed static data from the ICC and verify the correctness of the data. For both DDA and CDA the issuer personalizes the ICC with a private key unique to the ICC. During a transaction, the ICC produces a dynamic signature on a random challenge received from the terminal. By verifying this dynamic signature, the terminal can authenticate the ICC itself (under the assumption that the ICC private key is known only to the ICC), and confirm the legitimacy of static ICC data. Additionally, with CDA, the dynamic signature of the ICC covers all the transaction data necessary for the terminal to confirm the integrity of the ICC response for the current transaction. The underlying asymmetric signature algorithm is typically RSA (Rivest, Shamir and Adleman), but the same mechanism may be used with other asymmetric signature algorithms.
Card authentication is quite significant in payment transactions, as successful card authentication is typically a prerequisite to the conduct of an approved financial transaction and an enabler of other security techniques, such as offline Personal Identification Number (PIN) verification.
Payment System Keys
Payment system keys are a significant aspect of the EMV offline CAM Payment system public keys form the trusted root public key of an EMV certificate chain. Under the EMV specifications, each payment system generates several payment system key pairs, each including a payment system private key and the corresponding payment system public key. Each payment system generates its payment system key pairs in a secure system known as the payment system Certification Authority (CA).
Payment system private keys are used by the CA of each payment system to produce issuer public key certificates for the issuers. These certificates are stored by the issuers on the EMV ICCs that they issue. The payment system public keys are distributed by the relevant service of each payment system to all their acquires. The acquirers load them into their EMV terminals.
When an EMV offline transaction takes place at a terminal, the terminal identifies the payment system under which card issuance took place, then uses the relevant payment system public key to validate the issuer public key certificate read from the EMV ICCs. As described above, this validation step is a prerequisite to successful offline authentication of the card, and therefore to successful offline processing of the payment transaction.
Each payment system public key has an associated expiry date, which relates to the security properties of the key (that is, its resistance to attacks). Typically, the expiry date is determined by the key length. From time to time, existing payment system keys expire and are removed, while new payment system keys are introduced.
Payment System Keys and Interoperability
It is typically quite important that payment terminals are loaded with a correct set of payment system public keys. The unavailability of a valid payment system public key in a terminal adversely impacts the overall acceptance of cards. An EMV card featuring an issuer certificate generated using a given payment system private key can only be authenticated offline when the terminal is loaded with the corresponding payment system public key. If the relevant payment system public key is unavailable on the terminal, the transaction is either performed online (in the event that both (i) the terminal supports online authorization, and (ii) the card allows it) or declined.
The availability of an expired payment system public key in a terminal puts the payment scheme at risk. An EMV card featuring an issuer certificate generated using an expired payment system private key should normally not be accepted offline, as that private key is no longer secure.
In addition, the size of the keys (and of some related parameters, for instance with RSA keys, the size of the public modulus and the size and characteristics of the public exponent) impacts the terminal performance when performing offline CAM. Longer keys result in longer transaction times. When cards with long keys are used on slow terminals, performance may degrade down to a point where transaction time becomes unacceptably long, resulting in actual transaction failure.
Existing Terminal Testing Method
Testing of live terminals for the presence or absence of the payment system public keys and/or the correct operation of the offline CAM function is typically performed using live payment cards issued by a genuine issuer and loaded with valid certificate(s). Such an approach has several drawbacks. Payment systems have to pass agreements with some of their issuers that are keen issuing cards for test purposes. Some of these cards need to be personalized with the longest, most probably not yet deployed keys for the sole purpose of helping the payment system to conduct tests. Further, there is a financial risk associated with these cards as they could potentially be used frequently. Therefore, they are typically deployed under the control of accredited auditors, and can hardly be distributed to a wider panel. Yet further, the testers have to perform actual purchase transactions, hence generating costs to the payment system. Still further, tracing facilities need to be activated on the network conveying the financial transactions, and somewhat complex log analysis is required to check whether the transaction has been performed offline or online.
Accordingly, further improvements would be desirable.