Mar 18, 2003 Mårten Trolin 1

AgendaAgenda

Parts that need to be securedCard authenticationKey management

Mar 18, 2003 Mårten Trolin 2

SecuritySecurity with with SSmart-cardsmart-cards

Avoid use of fake cards for off-line transactions

Detect use of skimmed cards in on-line transaction

Secure sensitive data sent to the card from the issuer

Mar 18, 2003 Mårten Trolin 3

Parts Parts TThat hat NNeed to eed to BBe e SSecuredecured

Card – terminal authenticationCard – issuer interactionScripts sent to card by issuer

Mar 18, 2003 Mårten Trolin 4

Card – Card – TTerminal erminal AuAuthenticationthentication

The issuer has a certificate signed by the payment net (VISA, Europay or MasterCard)– The payment net acts as CA (Certificate Authority)

The issuer signs its card with its private key and puts the signature on the card

The issuer’s public key certificate is placed on the card

The terminal knows the root (CA) certificate– Using the root certificate, the terminal can verify the

signature presented by the card is valid.

Mar 18, 2003 Mårten Trolin 5

Overview of Keys UsedOverview of Keys Used

Payment net

Issuer

Signed certificate

Root certificate

Card certificate

Certificate verified against root certified during transaction

Mar 18, 2003 Mårten Trolin 6

Static Data Authentication Static Data Authentication (SDA)(SDA)

Each card is equipped with a signature on important card data.– No secret key on card.

Data signed include card number, expiration data, verification methods etc.

The signed data is sent to the terminal when transaction is started.

Same data and signature used every time (therefore static).

S ign e d a pp lica tio n d a taIn d ivid ua l fo r e ach ca rd

Issu er ce rtif ica te

R o o t ce rtf ica te

On card

Mar 18, 2003 Mårten Trolin 7

Signed Static Application Signed Static Application DataData, Generation, Generation

PAN

Sequence number

Verification methods

Other parameters... Hashed valued

Header

Data Authenticaion Code (DAC)

Encrypt with issuer private key

Signed Static Application Data

Mar 18, 2003 Mårten Trolin 8

Signed Static Application Signed Static Application Data, VerificationData, Verification

PAN

Sequence number

Verification methods

Other parameters...Hashed valued

Header

Data Authenticaion Code (DAC)

Decrypt with issuer public key

Signed Static Application Data

Mar 18, 2003 Mårten Trolin 9

Dynamic Data AuthenticationDynamic Data Authentication (DDA)(DDA)

Each card is equipped with a private key and a public key.

The public key is in a public key certificate signed by the issuer.

At transaction time, the card signs random data with its private key.

The terminal checks the signature and verifies the certficate chain.

Different data used every time (therefore dynamic).

T ra nsac tion de p en d en t d a tas ig ne d b y th e ca rd

C a rd pu b lic ke y ce rtica te

Issu er ce rtif ica te

R o o t ce rtf ica te

On card

Mar 18, 2003 Mårten Trolin 10

Dynamic Data AuthenticationDynamic Data Authentication

Certificate Chain

Unpredictable Number

Digital Signature

Generation of signature with card private key

Mar 18, 2003 Mårten Trolin 11

Comparison – SDA vs. DDAComparison – SDA vs. DDA

Static Data Authentication Dynamic Data Authentication

Cheaper cards – no need for RSA functionality on card

Expensive cards – card needs to perform RSA encryption

Fast – no processing on card Slower – card needs to produce RSA signature

Seeing one transaction is enough to produce a card that will be approved off-line

Seeing one transaction gives nothing

Mar 18, 2003 Mårten Trolin 12

CardCard – – IIssuer ssuer AAuthenticationuthentication

Issuer needs a permanent proof that the transaction has taken place.

Protection against fraud that comes from the merchant.

Based on symmetric cryptography– Issuer places a key on the card at issuing.– Issuer keeps the same key for use in

authorization processing.

Mar 18, 2003 Mårten Trolin 13

Overview of Keys UsedOverview of Keys Used

Payment net

Issuer

Keys for card-issuerauthentication

Sent during transaction

Mar 18, 2003 Mårten Trolin 14

Application CryptogramsApplication Cryptograms

In every request to the issuer, the cards computes a MAC over certain parameters.

This MAC is called application cryptogram.

The exact algorithm is defined between the issuer and the card.

Mar 18, 2003 Mårten Trolin 15

Issuer Issuer Authentication and Authentication and Secure MessagingSecure Messaging

If the issuer sends a MAC in the response, the card can verify that the message originates at the issuer.

When secure messaging is used, data sent from the issuer to the card is authenticated and/or encrypted.

Necessary for script processing– Change of risk parameters requires the messages to be

secured with a MAC.– Change of PIN requires the new PIN to be enciphered.

Mar 18, 2003 Mårten Trolin 16

Computing Application Computing Application CryptogramsCryptograms

Amount

Currency

Transaction type

Date

Other transaction parameters...

MAC computation with card key

Application cryptogram (8

bytes)

Mar 18, 2003 Mårten Trolin 17

Computing Response Computing Response Cryptogram (ARPC)Cryptogram (ARPC)

Application cryptogram (8

bytes)

XOR last two bytes with the response from

issuer

Encrypt with card key

Application Response

Cryptogram (ARPC,8 bytes)

Mar 18, 2003 Mårten Trolin 18

Key DerivationKey Derivation

Each key to be put on the card is derived from an issuer master key.– An issuer has (at least) one

master key for each key type to be placed on the card.

The derivation process is performed by taking card data and encrypt it with the corresponding master key.– The card information used is

PAN (i.e., card number) and sequence number.

EncryptionIssuer

master key

Card information

Unique card key

Mar 18, 2003 Mårten Trolin 19

Session KeysSession Keys

For security reasons it is often a good idea to use different keys for each transaction.

Keys used only for one transaction are called session keys.

EncryptionUnique card

key

Session information

Session key

Mar 18, 2003 Mårten Trolin 20

Deriving Session KeysDeriving Session Keys

Session keys are derived from the card key and session information.

The session information can be the transaction counter, ATC, or some other information sent in the transaction.

The data used for session key generation must be available to the issuer to allow the issuer to create the same key.– Transaction counter is sent in clear.– Other data used for key generation must be available

through other means.

Mar 18, 2003 Mårten Trolin 21

SummarySummary

Smart-cards protects the merchant, issuer and card-holder against fraud from counterfeited cards and fake transactions.

For card – terminal authentication different levels of security is possible, e.g., SDA vs. DDA.

Card – issuer authentication gives an electronic seal on transaction data.