pin processing apis - information trust institute · ... pin veriﬁcation security ... otherwise...

Graham Steel 23 July 2013

PIN Processing APIsGraham Steel

Photo: redspotted/Flickr

Graham Steel - PIN Processing APIs 23 July 2013 - 2/ 62

Introduction

Processing of PINs in the international cash machine network isone of the oldest and most widespread uses of cryptographichardware

International standards (ISO 9564, ANSI X9.8) and de-factostandards (e.g. Visa’s requirements documents) regulate thenetwork

Secure hardware must be configured so that “The system shall notbe capable of being used or misused to determine a PIN byexhaustive trial and error”.

This lecture will investigate PIN Processing APIs


Verizon Breach Report 2008

Released April 2009“While statistically not a large percentage of our overall caseloadin 2008, attacks against PIN information represent individualdata-theft cases having the largest aggregate exposure in terms ofunique records,”“In other words, PIN-based attacks and many of the very largecompromises from the past year go hand in hand.”“We’re seeing entirely new attacks that a year ago were thought tobe only academically possible,”“What we see now is people going right to the source [..] andstealing the encrypted PIN blocks and using complex ways toun-encrypt the PIN blocks.”(Quotes from Wired Magazine interview with report author, BryanSartin)


Known Major Breaches

2008 Feb Citibank $3.6M

2008 Nov RBS worldpay $9.4M

2011 May FIS $13M

2012 December RAKBANK $11M

2013 February Bank of Muscat $45M

Symatec report: ”tens of millions” lost to ATM heists in 2012 justin Europe:http://www.bloomberg.com/news/2013-05-07/banks-say-fed-should-lead-in-cybersecurity-for-industry.html


Simplified Network Schematic

ATM

HSBC

Maestro UK

SocGen


More Detail


PIN Processing API

We can see that the PIN processing API of the HSM will have to(at least):

I Translate PINsI Verify PINs

We will examine both of these APIs in detail.There are also functions to

I GenerateI PrintI Change PINs

which we will look at briefly


Deriving a PIN: IBM 3624 Method

IPIN derived by:

Encode account number (PAN) as 0000AAAAAAAAAAAA3DES encrypt under a PDK (PIN Derivation Key)

Take 4 leftmost hexadecimal digits of resultDecimalise using a mapping table (’dectab’)

0123456789ABCDEF0123456789012345

PIN = IPIN + Offset (modulo 10 each digit)


PIN Verification

Verify PIN:

{PIN}K, vDATA,Dectab →Offset, Lenyes/no ←

K, PDK


PIN Verification Code

PIN V(EPB, vdata, len, dectab, offset) {x1 := {vdata}pdk ;x2 := left(len, x1 );x3 := decimalize(dectab, x2 );u pin := sum mod10(x3 , offset);

x4 := deck(EPB);t pin := fcheck(x4 );

if (t pin =⊥) then return(′′format wrong ′′);if (t pin = u pin) then return(′′PIN is correct ′′);

else return(′′PIN is wrong ′′)}


PIN verification Security

Assumption: magstripe cards can be easily cloned

I Security requirement: No PIN should ever be disclosed

Threat scenario worst case: the attacker works inside the bankI Can break into the system and obtain access to the HSMI Can perform any sequence of API callsI ... but no direct access to HSM keys, memory or resources


The Mastermind Game

I Invented by the Israeli postmaster and telecommunicationsexpert Mordecai Meirowitz in 1970;

I 4 pegs from 6 possible colors, duplicates are allowed.I The codemaker chooses a sequence of 4 pegs, the

codebreaker has to guess itI Goal: Minimize the number of guesses


The Mastermind ‘API’

I The codebreaker ‘calls’ MasterMind(guess)I The return value is a set of 4 markers:

I red marker: right color and position;I white marker: right color and wrong position.


Decimalisaton Table Attack (Clulow ’02, Bond & Zeilinski’03)

Suppose in a hacked switch, an attacker has a set{PIN}K,PAN,Dectab,Offset that verifies PIN is correct

Original Dectab0123456789ABCDEF0123456789012345

Dectab’0123456789ABCDEF1123456789112345

Repeat verification command with Dectab’Successful verification indicates no 0s in PIN


More dectab attack

To find the 0s, try changing the offset

Attacker set offset Result from HSM Knowledge of PIN0001 Incorrect PIN ????0010 Incorrect PIN ????0100 Incorrect PIN ????1000 Incorrect PIN ????0011 Incorrect PIN ????0101 Correct PIN ?0?0


What’s the Best Strategy for the Dectab Attack?

Allows us to assess the seriousness of the attack

I Bond’s original scheme (2003) : 16.5 guesses on average– Go through all the different dectabs, get a list of digits– For each digit, use the offset to find out where it is

I Steel (2006) : 16.145 guesses– Find a digit– Use the offset to find out where it is– Repeat


A Better Dectab Strategy

I Focardi + Luccio (2010) : 13.463 guesses

Found by exhaustive search of ‘size 2’ strategies

Focardi - Luccio strategy sometimes searches for 2 digits at thesame time, sometimes two positions at same time

(not known if this is optimal, but log2 10000=13.362 to 3dp)


PIN Block Formats

Padding formats to encode a PIN for encryptionMust be 64 bits long for 3DESMust allow PIN length to be determined (e.g. in Italy, 5 digits)

VISA format 3

PPPPFFFFFFFFFFFF

Same PIN block for different users with same PIN


ISO 9564 Formats

Diversify PIN blocks using PAN

ISO 9564 format 0

04PPPPFFFFFFFFFF0000AAAAAAAAAAAA

Two lines are XORed together before encryption


ISO 9564 Format 1

Diversify blocks using randomnessISO 9564 format 1

14PPPPRRRRRRRRRR

Requires source of randomness


The Translate API

Translate Encrypted PIN: (IBM CCA version)

Host → HSM : { PINBlock } p1, { p1 } km⊕ipinenc,{ p2 } km⊕ipinenc, Format1, Format2, [PAN]

HSM → Host : { PINBlock } p2

If the decrypted block is not in the correct format, an error isreturned


ISO-0 Reformatting attack

(Clulow, 2003)


Suppose attacker calls ‘Translate’ function with modified PAN:first A digit A’=A ⊕ 8Error check (0 ≤ P ≤ 9) leaks information


Example

Attacking digit 3 of the PIN by changing digit 1 of the PAN

Change to digit 1 Result from HSM Knowledge of PIN0 ok 0 ≤ P3 ≤ 9⊕8 Format error 0 ≤ P3 ≤ 7⊕12 ok 4 ≤ P3 ≤ 5

Limitations:Always get two possible values for the digitOnly works for digits 3 and 4


Extended Reformat Attack

Masquerade ISO-0 as VISA format 3


0604PPPPFFFFFFFF

Now two possible errors: non-decimal PIN digit,or padding digit 6= FCan now uniquely determine digits


Example

Change to digit 1 Result from HSM Knowledge of PIN0 ok 0 ≤ P3 ≤ 9⊕8 Format error 2 ≤ P3 ≤ 7⊕12 ok 4 ≤ P3 ≤ 5

Now masquerade the block as VISA⊕10 ok P3 = 5

Note reformatted block has digits shifted two places to the right- so attack can be repeated on PIN digits 1 and 2


Other Block Formats

ISO 9564 format 2

24PPPPFFFFFFFFFF

Should only be used locally inside e.g. POS equipmentHowever, is often supported by default by translation API


ISO Format 3

Diversify using PAN and randomnessISO 9564 format 3

34PPPPRRRRRRRRRR0000AAAAAAAAAAAA


Old Block Format

IBM 3624Still supported on some HSMs

PPPPxxxxxxxxxxxx

where x is a pad digit given by a parameterMakes sense to choose 0xA-0xF, otherwise PIN range restricted!


In The Next Half

I More AttacksI Automated analysis of attacks and fixesI Language-based approach to fixesI Cost-effective fixes


Codebook Attack

Assumer attacker can always translate a PIN block from format 0to format 1 and back again, using any PAN he likes.

Suppose we can inject 100 known encrypted ISO-0 PIN blocks into the system (from an ATM for example)

We will create a codebook for some fixed PAN

Choose PIN xy00 for 0 ≤ x ≤ 9, 0 ≤ y ≤ 9

Then create a full codebook by changing first two digits


Calculate Offset Attack

Calculate offset function:Host → HSM : { PIN } p1, h(p1), vDATA, h(PDK)HSM → Host : {vDATA}PDK - PIN

Given a known encrypted PIN in the system, can be used tocalculate the PIN inside any encrypted block.

Two methods: one if correct PDK is available, one if not.

Many similar attacks in [Berkman & Ostrovsky, 07]


Visa PIN Verification

Uses a different method from IBM

PVV calculated, not kept secret (like offset)

PVV = first4(decimalise({TSP}PDK ))

TSP = PAN||Index ||PIN

Decimalisation method different - no dectab


Attacks on PVV

Competing PIN Verification Algorithms(see Clulow ’03)- if the same key can be used for both IBM and Visa verification

Calculate PVV attack(See B&0 07)- identify blocks containing the same PIN


Generate Encrypted PIN

Host → HSM : h(p1), vDATA, h(PDK), dectab, offsetHSM → Host : { PIN } p1


Statistical Attack

(see Bond & Clulow 2004)

First calculate a table of encrypted PINs for each offset 0000-9999Now for a fixed offset, generate EPB for random PDKs

Note that with a fixed standard dectab 0123456789012345,some digits are more likely than others.

After generating enough EPBs, we can ‘line up’ distribution anddecrypt all the PINs


AnaBlock (TCS 2006)

Take a customer configuration and an API spec. as input

Using Prolog, generate tree of all possible attacks

Constraint logic programming allows us to calculate transitionprobabilities

Apply PRISM (Kwiatkowska et. al, 2004)Get minimum expected number of steps to determine PIN

Generate tree for best attack


Attack Trees


Optimised Attack

(1,1,1,1,1,1,1,1,1,1,0,10) -> XOR in 8

(0,0,1,1,1,1,1,1,0,0,0,10) -> XOR in 10

0.6

(1,1,0,0,0,0,0,0,1,1,0,10) -> XOR in 10

0.4

(0,0,0,0,1,1,1,1,0,0,0,10) -> XOR in 12

0.66667

(0,0,1,1,0,0,0,0,0,0,0,10) -> XOR in 12 (VISA-3)

0.33333

(0,0,0,0,0,0,0,0,1,1,0,10) -> XOR in 6 (VISA-3)

0.5

(1,1,0,0,0,0,0,0,0,0,0,10) -> XOR in 14 (VISA-3)

0.5

(0,0,0,0,0,0,1,1,0,0,0,10) -> XOR in 8 (VISA-3)

0.5

(0,0,0,0,1,1,0,0,0,0,0,10) -> XOR in 10 (VISA-3)

0.5

PIN is 2

0.5

PIN is 3

0.5

PIN is 6

0.5

PIN is 7

0.5

PIN is 4

0.5

PIN is 5

0.5

PIN is 8

0.5

PIN is 9

0.5

PIN is 0

0.5

PIN is 1

0.5


AnaBlock Diagram

best−attackBest Attackscript

AnaBlock PRISM

Config File

API File

Customer

API Designer


Some Model Details

Typically large and flatI 1 process (or module)I 10 Booleans for each PIN digitI Integer variables to track Dectab operationsI P1 guessed etc.

Lots of symmetry


Dectab Attack Model

1. Start with Last Dectab=-1, Last Dectab Hit=11,Last Offset=0.

2. If all PIN digits determined, stop.3. If Last Dectab Hit > Last Dectab:

Increase Last Dectab by 1If the dectab hits, set Last Dectab Hit to Last Dectaband go to 4, else adjust digit constraints and go to 2.

4. Increase offset to next suitable value5. If offset hits: set Last Offset to 0, set the digits hit by the

offset to Last Dectab, set Last Dectab Hit to 11, goto2

6. Goto 4


Properties

Specified in PCTL

Rmin =? [F ( P1 guessed ∧ P2 guessed∧P3 guessed ∧ P4 guessed){”init”}{min} ]

Pmax =? [true U ( P1 guessed ∧ P2 guessed∧P3 guessed ∧ P4 guessed) ]


Results from AnaBlock

No. Attack E (Steps)(1) ISO-0 (extended) 13.6(2) Dectab 16.145(3) Dectab & ISO (restricted) 15.275

No. Attack Range: 400 36 24 14 1(4) ISO-0 (restricted) 1 0 0 0 0(5) Dectab no offset 1 1 0.568 0.064 0.001(6) Dectab no offset 1 1 1 1 0.001

& ISO-0 (restricted)


0

0.2

0.4

0.6

0.8

1

0 5 10 15 20 25 30 35

Pro

babili

ty

No. of Possible PINs

Performance of Dectab attack without offset

Dectab without ISO-0Dectab with ISO


Multilevel Security

One of the first semantic notions for security, based on a multilevelview of data:

Top Secret — Secret — Confidential — Unclassified

More generally we take a lattice of levelsCan split into confidentiality and integrity


Information Flow

Flow can be of two kinds: direct and indirectDirect flow:L := H;Indirect flow:if (H == 0) thenL := 1;

elseL := 0;


Non-inteference

Non-inteference is a security property meaning there is no flowfrom higher levels to lower levels

If a program is non-intefering, then no differences are visible in lowmemory for any pair of initial memories with identical lowmemories.This can be made fully formal (and has been the subject ofhundreds of papers)

Non-inteference can often be proved statically for a program usinga suitable type system


Fixing PIN Verification

I Label PIN as H, vDATA, PAN, Offset as LI Non-interference too strong: always reveal if encrypted PIN is

correct or notI So we need declassification. But this allows the attacks!I Robustness declassification may not be affected by low

integrity data– defined by Myers, Sabelfeld, Zdancewic, 04

I Endorsement - allows integrity to be raised

Fix PIN verify using Cryptographically assured endorsement usingMAC (Centenaro, Focardi, Luccio & Steel 2009)


Fixed version

PINVM(PAN,EPB, len, offset, vdata, dectab,MAC){if (macak(PAN,EPB, len, offset, vdata, dectab)==MAC)then EPB′ :=EPB;len′ := len;offset ′ := offset;

vdata′ := vdata;dectab′ := dectab;PINV(PAN,EPB′, len′, offset′, vdata′, dectab′);

else ret := ”integrity violation”;⊥MAC}


Existing MAC

CVV/CVC - Card Verification Value(/Code)

Effectively a MAC of PAN, expiry date, some other data

Made with secret key

5 decimal digits

Written to magstripe, does not appear e.g. on POS receipts

Designed to make construction of fake cards more difficult


CVV Format

PAN Exp date Service code 0 pad16 digits max 4 digits 3 digits 9 digits max

Block B1 Block B2

2-part DES key K1, K2.

CVVhex := enc(K1, dec(K2, enc(K1, (enc(K1,B1)⊕ B2))))


CVV’

Dectab Offset/PVV original CVV 0 pad16 digits 4 digits 5 digits 7 digits

Block B1’ Block B2’


Operation of Scheme

CVV’ is written onto card at issue time

CVV’ is sent along with trial PIN from each ATM transaction

Intermediate switches simply pass along the CVV’

At the verification facility, the supplied CVV’ is checked againstthe true derived value instead of full MAC


Evaluation - Advantages

I CVV’ can be calculated in advance- can be written to magstripe track 2, just like CVV

I Existing infrastructure already passes track 2 through network- no need for costly changes to infrastructure

I Institutions can choose to upgrade individually- no need to await standardization


Evaluation - Disadvantages

I Low entropy of MAC allows brute force attack- though overhead for PIN cracking attacks considerablyincreased

I Does not address translation command attacks- that would require point to point MACs, bigger overhead

I Change needed to HSM software- maybe not a big deal

Circulated in ANSI X.7


Fixing Translation Attacks

In practice most successful attacks seem to be made at switches.

Mannan (FC ’08) proposed a fix whereby PINs transported in thenetwork are ‘salted’, i.e. not the real PIN.

Salt value (e.g. 128 bits) is not secret and can be written tomagstripe

Disadvantage: all PIN pads must have same pseudorandomfunction (PRF) in them

PRF and Salt also used at verification facility, but not needed inswitches


Salted PINs

When PIN is typed, tPIN is calculated as:

I Generate PRF (PIN,Salt)I DecimaliseI Take first 12 digits as tPIN


Using the Salted PIN

tPIN is sent just like the real PIN through switches

At the verification facility, tPIN calculation is repeated using Saltfrom database

If they are equal then the PIN is correct

Attacks at the translation facility may still work, but the attacksonly learns the salted value


How much work to break the salted PIN?

Attacker knows the PAN

I Set up phase: create look up table of 1012 tPINsI For a target EPB fix one guess at the salt (from 128 bits)I Try every PIN 0000-9999I If they match, this is the correct PINI Otherwise, change the salt and repeat

Search requires O(240) steps


Summary

I PIN Processing a major application of HSMsI A poorly designed PIN processing API may be easy to attackI Automated methods for analysing attacksI Language-based methods for fixing the APIs


Further Reading

Wired Magazine, PIN Crackers Nab Holy Grail of Bank CardSecurityhttp://www.wired.com/threatlevel/2009/04/pins/

G. Steel. Formal analysis of PIN block attacks. TheoreticalComputer Science 367(1-2), 2006.R. Focardi, F. L. Luccio and G. Steel. Blunting Differential Attackson PIN Processing APIs. In NordSec’09, LNCS 5838.M. Centenaro, R. Focardi, F. L. Luccio and G. Steel. Type-basedAnalysis of PIN Processing APIs. In ESORICS’09, LNCS 5789Mohammad Mannan, P.C. van Oorschot. Reducing threats fromflawed security APIs: The banking PIN case, Computers &Security 28 (6), 2009.


http://www.wired.com/threatlevel/2009/04/pins/

pin processing apis - information trust institute · ... pin veriﬁcation security ... otherwise...

Documents