1

EMV

2

EMV

• EMV = Europay-Mastercard-Visa • standard for replacing mag-stripe with chip • interesting standard, as it is all public

– www.emvco.com– 100s of pages

• originally for contact smartcard, but now also for RFIDs

3

EMV 2004 spec

• Book 1: ICC to Terminal Interface Requirements• Book 2: Security and Key Management• Book 3: Application Specification• Book 4: Cardholder, Attendant and Acquirer Interface Specifications

4

EMV roll-out

• first version of standard 1996• UK rollout Oct 2003-Feb 2006 (Chip and PIN)

– www.chipandpin.co.uk• continental Europe still migrating for credit cards

– eg see www.vanstripnaarchip.nl– but many national payment schemes use smartcards

• USA sticking to magstripe– and skipping contact cards to move to RFID

5

Why smartcards?

• preventing skimming/cloning

• also: shift in liability to customer– PIN replacing signatures for non-repudiation

• process of checking and contesting very different– some public debate on this

• eg see http://www.chipandspin.co.uk/spin.pdf

• and to non-complying merchants – eg since jan 2005, UK merchant that cannot conform to

EMV is liable

6

Does it work?

UK card fraud in millions of £ [Source: apacs.org.uk]

32313730211517141713card ID theft

438439504420425412317188135122Total

15407345372718151213mail intercept

6889115112108114102806666lost/stolen

10097130110149160107502720counterfeit

2131831511221109673291410card not present

2006200520042003200220012000199919981997

7

EMV security techniques

• card authentication to terminal– Static Data Authentication (SDA)– Dynamic Data Authentication (DDA)

• transaction confidentiality & integrity– encryption and MAC

• PIN encryption at point of entry (optional)

8

EMV security techniques

• Algorithms used: – 3 DES, RSA, SHA-1– possible new algorithm in future, eg ECDSA

• RSA digital signature and public key certificates• card unique 3-DES key, derived from Master

Derivation Keys (MKDs)• unique session keys for encryption & MAC

9

EMV Public Key Certificate

Public Key Certificate

EMV formatting

CertificateCore

General information about the user and the application

Public Key Remainder

Public KeyUser’s public key

Signature by a Trusted Third Party

Hash Result

Hash of data

10

Static Data Authentication (SDA)

• Static authentication data on card is signed with issuer's private key– Static authentication data includes

• Primary Account Number (PAN)• Expiry date

11

SDA

12

IC Terminal

IC Card

Card provides to terminal:

Signature OK

Terminal:

• Uses PKCA to retrieve the Issuer’s PKISS which is certified by the CA

• Uses PKISS to verify the digital signature of the card data

• Card data with Issuer’s digital signature

Card static

data

• PKISS certified by Certification Authority (CA)

CERTIFIED

SDA - Authorisation Phase

13

Weakness of SDA

• does not prevent replay attacks:– skimming still an option!

• UK banks issue SDA cards, which has caused criticisms– still, cloning SDA cards will be harder than magstripe

cards, esp. one that looks convincing

• DDA repairs this by having a terminal-generated nonce

14

DDA

15

DDA - Authorisation Phase

IC Terminal

IC Card

Card provides to terminal:

Signature OK

• Uses PKCA to retrieve the Issuer’s PKISS which is certified by the CA

• Uses PKIC to verify the digital signature on the card and terminal data

• PKISS certified by Certification Authority (CA)

CERTIFIED

• PKIC certified by Issuer

CERTIFIED

• Uses PKISS to retrieve the ICC PKIC which is certified by the Issuer

• Digital signature on the UN and the ICC Dynamic Data generated using SKIC

Terminal:

Terminal provides to card:

• Unpredictable Number (UN)

INTERNAL AUTHENTICATE

16

Dynamic Data Authentication (DDA)

• terminal-generated nonce prevents replays• downside: more expensive card required

17

PIN encryption

• encryption of PIN code in tamper-evident secure keypad

• card issuers don't want to trust the entire ATM, but only the Hardware Security Module (HSM) and this secure keypad

• PIN encrypted with – card's public key PKIC

– or card's PIN encipherment public key PKPE

18

Offline PIN Processing

Validate PKIC or PKPE

GET CHALLENGE

Unpredictable Number (UN)

PKIC or PKPE and UN

PIN Pad generates random padding

Create data block to include PIN, UN and random padding and encrypt with PKIC or PKPE

Cardholder enters PIN

Encrypted PIN Data

VERIFY (includes Encrypted PIN

Data)

Decrypt Encrypted PIN Data, using SKIC or SKPE and validate UN and

PIN

IC Terminal

Secure PIN Pad

IC Card

19

Transaction Security

• card's master key derived from issuer master key– by encrypting PAN and PAN sequence number– different issuers master keys for confidentiality

(encryption) and message/transaction integrity (MACs), resulting in corresponding card's master keys

• session key derived from card's master key – by encrypting card's ATC (Application Transaction

Counter) and terminal-supplied nonce (UN = Unpredictable Number)

20

ICC Master Key Derivation

Issuer Master Key

PAN + PAN Sequence Number

3-DES Encrypt(Encrypt/Decrypt/Encrypt)

ICC Master Key (left half)

Inverted PAN + PAN Sequence

Number

3-DES Encrypt(Encrypt/Decrypt/Encrypt)

ICC Master Key (right half)

Issuer Master Key

21

Session Key Derivation

ATC F0 00UN

3-DES Encrypt(Encrypt/Decrypt/Encrypt)

SKAC(left half)

IC Master Key

ATC 0F 00UN

3-DES Encrypt(Encrypt/Decrypt/Encrypt)

SKAC(right half)

IC Master Key

22

Secure Messaging

• Secure messaging is used between the Issuer’s host system and the smart card, – eg to update card parameters, application unblock, or

change/unblock PIN

• Secure messaging provides data integrity and origin authentication (with MAC) and confidentiality (encryption).– Encryption uses 3-DES Cipher Block Chaining (CBC).– MAC as on next slide

23

Message Authentication Code (MAC)

• MAC calculated with a 3-DES session key (derived from the ICC Master Key).

• Algorithm defined in ANSI X9.19 and ISO 9797-1

• SK(L) = Session Key (left half)• SK(R) = Session Key (right half)

Block 1

Encrypt

Block 2

Encrypt

Block 3

AC

Encrypt

⊕ ⊕

Decrypt

Encrypt

SK(L) SK(L) SK(L)

SK(L)

SK(R)

24

Cardholder Verification Methods (CVM)

• range of cardholder verification methods– depending on card and the application

• terminal and smartcard negotiate CVM– given their lists of allowed/supported method (in order of

preference) with conditions• potential for trouble: forcing terminal/card to fall

back to old CVM– problems with this reportedly fixed

25

CVM codes

26

CVM condition codes

27

Hardware Security Modules

• Bank's bank-end has to store issuer's master keys – eg in ATM

• Hardware Security Modules (HSMs)– store these keys – and perform required operations on them

• keys shouldn't leave HSM unencrypted– HSM are tamper-resistant/evident devices

• the complicated APIs of HSM may allow attacks– combination of API calls may produce spoofed encrypted

message or a reveal key

28

IBM 4758

29

Example HSM API weakness

• HSM allows external storage of key K in encrypted form{K}KM where KM is master key that never leaves HSM

• Secure_Messaging_for_Keys operation added in CCA (Common Cryptographic Architecture) to support EMV – input: {K1}KM, {K2}KM, template, offset

– output: {template with K1 inserted at offset}K2

• attack:– take template = m ++ '00000000' , offset = |m|– now output is {m ++ K1}K2 = {m}K2 ++ ...– we have an encryption oracle for K2– we can now spoof messages to the EMV smartcard..

30

Example HSM API weakness (cont)

• we can go to recover K1 • calculate {0000 0000 0000 00yy}K2for 00≤yy≤FF• call Secure_Messaging_for_Keys with template = '0000 0000 0000 0000' , offset = 7

• match result with one of the {0000 0000 0000 00yy}K2 revealing the first byte of K1

• repeat procedure to calculate other bytes

[A Note on EMV Secure Messaging in the IBM 4758 CCA, B. Adida et al., 2005]

31

EMV next steps?

• hand-held reader to cut card-not-present fraud– cf. online banking in the Netherlands– weakest link then: browser security

• integration in mobile phone– which has keyboard & display!