MISFIT/PIN Cracking-comsec-09_pdf.md

# PIN Cracking-comsec-09


---

Weighing Down
⋆
“The Unbearable Lightness of PIN Cracking” (Extended Version)
Mohammad Mannan and P.C. van Oorschot
School of Computer Science
Carleton University,Ottawa, Canada
Abstract. Responding to the PIN cracking attacks from Berkman and Ostrovsky (FC 2007), we outline a
simplesolutioncalled salted-PIN.Arandomlygeneratedsaltvalueofadequatelength(e.g.128-bit)isstoredon
abankcardinplaintext,andinanencryptedformataverificationfacilityunderabank-chosensaltkey.Instead
of sending the regular user PIN, salted-PIN requires an ATM to generate a Transport Final PIN from a user
PIN, account number, and the salt value (stored on the bank card) through, e.g., a pseudo-random function.
Weexploredifferentattackson thissolution, and proposethreevariantsofsalted-PIN that can protectagainst
known attacks. Depending on the solution variation, attacks at a malicious intermediate switch now may only
revealtheTransportFinalPIN;boththeuserPINandsaltvalueremainbeyondthereachofanattacker’sswitch.
Salted-PIN requires modifications to service points (e.g. ATM, point-of-sale), issuer/verification facilities, and
bank cards; however,changes tointermediate switches are not required.
1 Introduction
Attacks on financial PIN processing APIs revealing customers’ PINs have been known to banks and security re-
searchers for years, e.g., [10], [6], [8], [9], [7] (failure modes of ATM PIN encryption were first discussed in An-
derson [2]). Apparently the most efficient of these ‘PIN cracking’ attacks are due to Berkman and Ostrovsky [4].1
However,proposalstocountersuchattacksarealmostnon-existentintheliterature,otherthanafewsuggestions;for
example,maintainingthesecrecy(andintegrity)ofsomedataelementsrelatedtoPINprocessing(thatareconsidered
security insensitive according to current banking standards)such as the ‘decimalization table’ and ‘PIN Verification
Values (PVVs)/Offsets’ has been emphasized [8], [4]. However, implementing these suggestions requires modifica-
tions to all involvedparties’ HardwareSecurity Modules (HSMs). Commercial solutions such as the PrivateServer
Switch-HSM[1]relymostlyon‘tightly’controllingthe keyuploadingprocesstoaswitchandremoving‘unnecessary’
APIs or weak PIN block formats. Even if the flawed APIs are fixed, or non-essential attack APIs are removed to
preventthese attacks,it may be difficult in practice to ensure that all intermediate (third-party controlled)switches
areupdated accordingly.Thus banks relymainly onprotectionmechanisms providedwithin banking standards,and
policy-based solutions, e.g., mutual banking agreements to protect customer PINs.
A solution such as Mobile Password Authentication (MP-Auth) [13] is apparently capable of preventing these
attacks in addition to saving PINs from false ATM keypads and card reader attacks. However, MP-Auth relies
on public key operations, and thus cannot be deployed without significant modifications to ATMs, switches and
verificationfacilities. Another obvioussolution(as suggestedin [8],[4]) is to update the PINprocessingAPIs,which
2
alsorequires modifications to all involvedparties’HardwareSecurity Modules (HSMs). Evenif the flawedAPIs are
fixed, or non-essentialattack APIs are removed(as in ARX PrivateServerHSM [1]) to preventthese attacks,it may
be difficult in practice to ensure that all intermediate (third-party controlled) switches are updated accordingly.
Designing solutions to mitigate PIN cracking attacks pose some interesting challenges. PIN transfers in banking
networks rely on symmetric key cryptography where the third-party controlled intermediate switches also possess
shared keys to decrypt encrypted PINs (although have no access to issuer/verification keys). Although decrypted
PINs (and the decryption key itself) are not (ideally) accessible from outside of an HSM, API flaws allow attackers
to realistically extract enough information from the HSM (through ‘legitimate’ API calls) that enable PIN cracking
attacks. Thus PIN cracking solutions must protect user PINs travel through third-party switches which may be less
security conscious or even actively malicious. Our solution attempts to address threats from such an adversary as
⋆ Version:April29,2008.Contactauthor:mmannan@scs.carleton.ca. A5-pageversionofthismanuscripthasbeenaccepted
as a short paper in Financial Cryptography and Data Security (FC) 2008.
1 We encourage readers unfamiliar with financial PIN processing APIs and PIN cracking attacks to consult Section 2 for
background,and Section 7 for a summary of attacks by Berkman and Ostrovsky[4].
2 For an overview of HSMsand related attacks, see Anderson et al. [3]

2
wellashostilepartiesataverificationfacilitywithlimitedaccess(e.g.onewhocancallAPIfunctions fromanHSM,
but cannotaccessverificationkeys).However,we do not considerATM frauds suchas false keypadsandcardreader
attacks that are not scalable.
One primary reason that PIN cracking attacks are possible is that actual user PINs, although encrypted, travel
from ATMs to a verification facility through several (untrustworthy) intermediate switches. If, for example, hashed
PINsweresentinanencryptedform,attackersmaynotbeabletorevealuserPINseveninthepresenceofAPIflaws.
However, as PINs are generally short (4 digits), an offline dictionary attack may still easily allow recovery of actual
PINs. From reviewing the history of API attacks, we also note that even a complete overhauling of PIN processing
APIsmaybesubjecttopresently-unknownAPIflawsthatmightbeexploitedtorevealuserPINs.Thereforeweseek
a solution that precludes real user PINs being extracted at verification facilities, and especially at switches (which
are beyondthe controlof issuing banks),even in the presence of API flaws.One possible solutionin this directionis
not to send the actual user PIN itself through untrusted intermediate nodes. Our proposal follows such a direction.
While PIN cracking attacks get more expensive as the PIN length increases, it is unrealistic to consider larger
(e.g. 12-digit)user PINs,for usability reasons.3 As part of our proposal,we assume that a unique randomsalt value
ofsufficientlength(e.g.128bits)isstoredonauser’sbankcard,andusedalongwiththeuser’sregularfour-digitPIN
(‘FinalPIN’)togenerate4 alarger(e.g.12digits)Transport Final PIN (TFP).ThisTFPisthenencryptedandsent
throughthe intermediate switches.Thus we essentially expandthe 4-digitPINto 12digits. We build our salted-PIN
solution on this simple idea. Our proposal requires updating bank cards (magnetic-stripe/chip card), service-points
(e.g.ATMs),andissuer/verificationHSMs.However,ourdesigngoalisto avoidchanginganyintermediate switches,
or requiring intermediate switches be trusted or compliant to anything beyond existing banking standards.
Salted-PIN provides the following benefits.
1. Itdoesnotdependonpolicy-basedassumptions,andlimitsexistingPINcrackingattacksevenwhereintermediate
switches are malicious.
2. It significantly increases the cost of launching known PIN cracking attacks; for example, the setup cost for the
translate-onlyattackforbuildingacompleteEncryptedPINBlock(EPB)tablenowrequiresmorethanatrillion
API calls in contrast to 10,000 calls as in Berkman and Ostrovsky [4].
3. Incorporating service-point specific information such as ‘card acceptor identification code’ and ‘card acceptor
name/location’ (as in ISO 8583) into variants of salted-PIN, we further restrict attacks to be limited to a
particular location/ATM.
Organization.BackgroundonfinancialPINprocessingisprovidedinSection2.Weoutlinetheproposedsalted-PIN
solution in Section 3. Known attacks against the basic versionof salted-PIN are discussed in Section 4. In Section 5
we introduce three variants of salted-PIN to counter these attacks. Implementation challenges to salted-PIN are
briefly discussed in Section 6. In Section 7, we review several (representative) attacks as outlined by Berkman and
Ostrovsky [4]. Section 8 concludes.
2 Background
In this section, we provide a basic overviewof PIN processing and PIN block formats. More backgroundon banking
networks is discussed elsewhere (e.g. [10], [14]).
PINProcessingArchitecture.WhenauserinputsherPINatanATM,thePINisencryptedtoformanEncrypted
PIN Block (EPB) using a transport key shared between the ATM and the next switch connected to the ATM. A
switch can be a stand-alone facility for PIN transportation (and other related bank network activities), or part of a
bank’s verification facility. PIN blocks are processed inside Hardware Security Modules (HSMs). Each switch shares
a transport key with other switches that it is connected to. At a verification center, a switch may also have the
issuerkey(forPINverification).AstandardizedsetofPINprocessingAPIsisusedforPINcreation,transportation,
and verification.The intent is that this allows banks to protect user PINs from applicationprogrammers(or anyone
having access to PIN processing APIs) at verification facilities as well as in switches.
There are several standardized PIN block formats (see below). An EPB may travel across several HSMs on its
way to a verificationsite. When transmitted fromone HSM to another, re-formatting (i.e. translating from one PIN
3 A 12-digit PIN can be constructed bystoring eight digits on thebank card while a usermemorizes theotherfour digits as
usual. However, as thereal PIN is sent encryptedin thissolution, attackers at amalicious switch can recover thePIN and
createfakecards.(AnanonymousFC2008refereepointedthissolutionanditsrelativeadvantagesanddisadvantages to us.)
4 For example, through a pseudo-randomfunction (PRF).

3
block format to another) may be required. Thus all HSMs must implement translation APIs to allow reformatting
of an EPB. A switch decrypts an EPB, checks the PIN block format (e.g. validity of PIN digits, PIN length),
changes the format if required, and re-encrypts the PIN block with the destination switch’s transport key. As all
PIN operations are performed by HSMs, an application programmer (ideally) cannot learn anything about PINs
transported as EPBs.
PAN
PIN Key Encrypt PAN
(issuer)
Decimalization
Table Decimalize the encrypted PAN
Natural PIN (4 leftmost digits)
EPB
PIN block Decrypt EPB and extract
format Transport Final PIN
Key
Final PIN - Natural PIN
Offset
Fig.1. Offset calculation (adapted from [14])
PIN Block Formats. We outline four PIN block formats from ISO 9564-1 [12], three of which are approved by
VISA for online transactions (e.g. through ATMs). Assume that a PIN is four decimal digits long. A PIN block
is composed of 16 hex digits, i.e., 64-bits. Let ‘P’ be a PIN digit (0 to 9), PAN the least significant 12 digits of a
customer’sPrimaryAccountNumber (excluding the checkdigit), andlet‘A’be a PANdigit(0 to 9).AnISO-0PIN
block is calculated as follows.
ISO-0 PIN Block=Original PIN Block⊕Formatted PAN
Here, Original PIN Block=04 PPPP FFFF FFFF FF,
with ‘F’ denoting the hex digit F
Formatted PAN Block=00 00AA AAAA AAAA AA
The leftmost zero in the original PIN block stands for ISO-0, and the digit 4 is the PIN length (which could be
ashighas12).AnISO-0PINblock is the resultofXORing anoriginalPINblock withaformattedPAN.The ISO-1
PIN Block format is 14 PPPP RRRR RRRR RR, where ‘R’ is a random hex digit (0 to F). The ISO-2 PIN Block format
is 24 PPPP FFFF FFFF FF, which is used only when creating a card. An ISO-3 PIN block is calculated as follows.
ISO-3 PIN Block=Formatted PIN Block⊕Formatted PAN
Here, Formatted PIN Block=34 PPPP RRRR RRRR RR,
with ‘R’ a hex digit from A to F
Formatted PAN Block=00 00AA AAAA AAAA AA
Insummary,ISO-2is the weakestPINformat;it is not allowedfor online processing,and ithas not beenused in
the PIN cracking attacks. ISO-0 and ISO-3 PIN blocks depend on a user PIN and account number. ISO-1 format is
not bound to a user’s account number, and is recommended to be used in situations where the PAN is unavailable.
Attacks exploiting translate-only APIs (see Section 7.1) depend on the fact that any ISO-0 and ISO-3 PIN formats
canbetranslatedtothelesssecureISO-1format(astheISO-1formatdoesnotdependontheuserPAN).Translation
APIs are also generally implemented by all HSMs.

4
IBM Calculate-Offset API. IBM’scalculate-offsetAPIoutputs anoffsetusinga PANandEPB.If the calculated
offset value correspondsto the stored value for that PAN, then the PIN inside the EPB is verified. Offset values are
assumed by the banking standards to be security insensitive, and are generally stored in plaintext. Fig. 1 illustrates
how anoffsetvalue is calculatedforPINverification.Here,a Natural PIN is calculatedfromacustomer’s PAN,and
the Final PIN is a customer-chosen PIN. Subtraction is digit by digit modulo 10. An issuer key (residing inside an
HSM) is used to encrypt a user’s PAN. The encrypted PAN may contain hex digits (A to F), and it is decimalized
using a decimalization table (mapping hex digits to decimal digits). The four left-most digits of the decimalized
encryptedPANconstitutetheuser’sNaturalPIN.TheFinalPINisextractedfromtheuser’sPAN,EPB(containing
the user’s encrypted Final PIN), the PIN block format, and the transport key (residing inside the HSM). The offset
is calculated by subtracting the Natural PIN from the Final PIN.
VISA PIN Verification Value (PVV). Fig. 2 depicts how a VISA PIN Verification Value (PVV) is calculated.
PVVs are used in a similar fashion as IBM offset values, and also (generally) stored in a plaintext database. A
customer’s PVV may be written on her bank card as well (for offline PIN verification).
EPB
Transport
PIN block Key Decrypt EPB and extract
format Final PIN (4 digits)
PAN
PIN Key Transformed Security Parameter (TSP) =
Index 11 PAN digits || PIN Key Index || Final PIN
PVV Key Encrypt TSP
(issuer)
Decimalization
Table Extract 4 decimal digits
PVV
Fig.2. PVV calculation (adapted from [14], || denotes concatenation)
3 Salted PIN
Here we present the salted-PIN proposal in its simplest form.
Threat model and notation. Our threat model assumes attackers have access to PIN processing APIs and
transaction data (e.g. Encrypted PIN Blocks, account number) at switches or verification centers, but do not have
directaccesstokeysinsideanHSM,ormodifyHSMsinanyway.Attackerscanalsocreatefakecardsfrominformation
extractedatswitchesorverificationcentersandusethosecards(perhapsthroughoutsideraccomplices).Weprimarily
considerlargescaleattackssuchasthose thatcanextractmillions ofPINs inanhour[4].We donotaddressattacks
that arenot scalable,suchas card skimming, attacksonEMV5 PINentry devices [11],or cases where anaccomplice
steals acardandcallsaninsider ata switchorverificationcenterfor anappropriatePIN.PINcrackingattacksthat
we considerare successful only when online PINverificationis applied (i.e. encrypted PINs are sent to a verification
centerforapproval).Inadditiontomagnetic-stripecards,theseattacksarealsovalidforchip/EMVcardsexceptwhen
offline/on-chip PIN verification is used (assuming card issuers allow EMV cards to fallback to magstripe processing
for backward compatibility or chip failure). The following notation is used:
5 EMV is a growing standard for chip-based bank cards, initially developed by Europay, MasterCard, and VISA; see
http://www.emvco.com.

5
PAN User’s Primary Account Number(generally 14 or 16-digit).
PIN User’s Final PIN (e.g. 4-digit, issued bythe bank or chosen by theuser).
PINt User’s Transport Final PIN (TFP).
Salt Long-term secret valueshared between the usercard and issuing bank.
fK(·) A cryptographically secure Pseudo-Random Function (PRF).6 HereK is the PRFkey.
3.1 Generating Salted-PINs
A randomly generated salt value of adequate length (e.g. 128 bits, to make dictionary attacks infeasible) is selected
by a bank for each customer. The salt is stored on a bank card (chip-card or magstripe) in plaintext, and in an
encrypted form at a verification facility under a bank-chosen salt key. API programmers (i.e. those who use HSM
API)haveaccesstothis encryptedsalt(butdonotknowthe saltkeyorplaintextsaltvalues).Encryptedsaltvalues
alsocannotbeoverwrittenbyAPIprogrammers.AuserinputsherPINatanATM,andtheATMreadstheplaintext
salt value from the user’s bank card and generates a Transport Final PIN (TFP) as follows.
PIN =f (PAN,PIN) (3.1)
t Salt
ThePRFoutputisinterpretedasanumberanddividedby1012;the12-digitremainder(i.e.PRFoutputmodulo
1012) is chosenas PIN andtreatedas the Final PINfromthe user.Note that the maximumallowedPIN lengthby
t
ISOstandardsis12.The ATMencryptsPIN withthe transportkeysharedwiththe adjacentswitch,andformsan
t
Encrypted PIN Block (EPB). An intermediate switch decrypts an EPB, (optionally) reformats the PIN block, and
re-encrypts using the next switch’s transport key. Additional functionalities are not required from these switches.
To set the initial offset or PIN verification value (PVV), an issuer generates a random PIN (e.g. 4 digits long)
and salt for a user, and then uses equation (3.1) to generate PIN . The transport key of the verification HSM is
t
used to encrypt PIN and form an EPB. This EPB is used to call a calculate offset/PVV function with the user’s
t
PAN and encrypted salt to generate the initial offset/PVV (note that each of these values is now 12 digits long).
PAN
PIN Key
Encrypt PAN
(issuer)
Decimalization
Table Decimalize the encrypted PAN
Natural PIN (4 leftmost digits)
Encrypted
Salt
Salt Key Decrypt Salt
(issuer)
PAN Transport Natural PIN =
Decimalize(PRF(PAN, Natural PIN, Salt))
EPB Decrypt EPB and extract
PIN block format Transport Final PIN
Transport
Key
Transport Final PIN - Transport Natural PIN
Offset
Fig.3. Salted-PIN verification for the IBM offset method
6 For example, as used in PwdHash [15].

6
3.2 Offset/PVV Verification with Salted-PIN
The salted-PIN verification for the IBM offset method (recall Section 2) is shown in Fig. 3. The Natural PIN is
calculated from a PAN using an issuer’s PIN key. The encrypted salt value corresponding to the PAN is decrypted
usingasaltkey(likethePINkeyandtransportkey,thesaltkeyalsoresidesinsideanHSM).TheTransportNatural
PIN is generated from the Natural PIN using equation (3.1). The Transport Final PIN is extracted from an EPB,
and the Transport Natural PIN is subtracted from it (digit by digit modulo 10 subtraction) to get the offset. This
calculatedoffsetvalueiscomparedwiththecorrespondingPAN’sstored(e.g.inadatabase)offsetvalue.The salted-
PINverificationforVISAPVVisshowninFig.4.ThesaltvalueisappendedattheendoftheTransformedSecurity
Parameter (TSP), which is encrypted and decimalized to calculate the PVV. Note that we design the offset/PVV
verification functions to keep them similar to the existing functions although these can be further simplified; for
example, instead of storing offset/PVV values, EPBs directly may be stored and compared with incoming EPBs.
Encrypted Salt
Salt Key
Decrypt Salt
(issuer)
EPB
Transport
Key Decrypt EPB and extract
PIN block format
Transport Final PIN
PAN
PIN Key Transformed Security Parameter (TSP) =
Index PAN || PIN Key Index || Transport Final PIN || Salt
PVV Key
Encrypt TSP
(issuer)
Decimalization
Table Extract 12 decimal digits
PVV
Fig.4. Salted-PINverification for VISAPVV
3.3 Salted-PIN Protection against PIN Cracking Attacks
We discuss attacks (e.g. translate-only [4]) that reveal a user’s TFP in Section 4. An attacker with write-access to
the PVV database at a verification facility can choose any PIN for a specific account (see Section 7.3). With the
salted-PIN solution, an attacker can still choose any PIN to pack in an EPB and write the resulting PVV to a
database. However, without knowing the salt value, overwriting a user’s PVV does not help in an attack for the
following reason. The salted-PIN verification function for PVV (Fig. 4) ensures use of the encrypted salt value as
indexed by a user’s PAN; thus for a successful PVV verification, a user’s salt must be known or the encrypted salt
value must be replaced.
4 Attacks on Salted-PIN
We now discuss attacks against the basic version of salted-PIN.
4.1 Enumerating EPBs through Translate-only Attacks
HerethegoalofanattackeristocreateatableofEPBs,andthencrackallorasubsetofuseraccounts.Thefollowing
attacks in part follows an efficient variant of the translate attack as outlined by Berkman and Ostrovsky [4]. For
theseattacks,weassumeanattackerM isaninsider(e.g.applicationprogrammer)ataswitchorverificationcenter,
i
and an outsider accomplice M who helps M in carrying out user input at an ATM. These attacks are possible for
a i
the following reason. Although a TFP is calculated from a long (e.g. 128 bits, sufficient to deter dictionary attacks)

7
salt value, only 12 digits of the PRF output are used. Thus an attacker only requires any pair of salt and PIN
combination that can generate a targeted account’s TFP instead of finding the actual salt/PIN values.
Targeting all accounts. Assume that M extracts the salt value (Salt ) and PAN from a card he possesses, and
i a
uses equation (3.1) to generate the 12-digit TFP PIN (through software or a hardware device, using any PIN
at
PIN
a
). Let PIN
at
consist of p1p2p3...p12 where each p
i
(i = 1 to 12) is a valid PIN digit. Then M
a
inserts this
card to an ATM, and enters PIN . Assume that the generated PIN is encrypted by the ATM to form an EPB,
a at
E1.M
i
captures E1 at a switch. If E1 is notin the ISO-1 format,M
i
translates it into ISO-1 (to disconnectE1 from
the associatedPAN). Let the translated (if needed) E1 in the ISO-1 format be E
1
′ . E
1
′ is then translatedfrom ISO-1
to ISO-0 using p3p4...p1200 as the input PAN. This special PAN is chosen so that the XOR of PIN positions 3 to
12 with PAN positions 1 to 10 removes p3...p12 when the translation API is called; i.e.,
PIN block inside E1 ′ =0Cp1 p2 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 FF
InputPAN =0 0 0 0 p3 p4 p5 p6 p7 p8 p9 p10 p11 p12 0 0
Resulting ISO-0PIN block =0Cp1 p2 0 0 0 0 0 0 0 0 0 0 FF
Assume the resulting EPB is E
p1p2
which is the same as the one containing a TFP p1p20000000000with PAN 0.
Now we can create all EPBs containing every 12 digit TFPs starting with p1p2 from E
p1p2
. For example, an EPB
with p1p2q3q4...q12 as the TFP can be generated through transforming E
p1p2
using PAN q3q4...q1200 (in ISO-0).
Thus we can create all 1010 EPBs with TFPs from p1p20...0 to p1p29...9.
Starting from a different p1p2, all 1012 EPBs containing every 12 digit TFP can be generated as follows. M
a
uses the previous bank card (i.e. the same salt and PAN) with different PINs (obviously, including wrong PINs)
to calculate TFPs using software or a special device. When a TFP is found with the first two digits different than
p1p2, the corresponding PIN is entered at an ATM. The attacker M
i
at the switch then generates another set of
1010 EPBs containing TFPs starting with this different p1p2. The attack continues with different PINs until all
100 possible values of the initial two TFP digits are covered. Thus using these 100 EPBs containing TFPs starting
with the different first two digits (i.e. from 00 to 99), M can create a table of EPBs for all possible TFPs (with
i
corresponding PINs). The cost of building this table is slightly over 1012 API calls (for each 100 E , at most two
p1p2
API calls are required). The cost of selecting the initial EPBs (i.e. that contain TFPs with two different starting
digits) is insignificant as M can calculate TFPs offline, i.e., without involving any API calls to HSMs.
a
To launch an attack,a valid EPB of a target customer is collected. The EPB is translated to ISO-1 (to decouple
it from the target account, if not already in ISO-1), then to ISO-0 with PAN 0. The resulting EPB is then located
onthe EPB table (as createdin the setup phase).The correspondingPINfromthe table cannow be used to exploit
a card generated with the target’s PAN, and the attacker’s salt value (i.e. Salt ). The cost of this attack is at most
a
two API calls and a search of O(1012), i.e., O(240).
In summary, the setup cost of this attack is about 1012 API calls with a per account cost of two API calls plus
a search of O(1012). The same translate-only attack by Berkman and Ostrovsky [4] on the current implementation
of PIN processing requires only about 10,000 API calls as setup cost, and a per account cost of two API calls plus a
search of O(103).
Algorithm 1 Steps in the partial table attack
1: for i=0 to106−1 do
2: Ec0 =Translate ISO−0(Ec,i×100)
3: if Ec0 is in the table then
4: TFP in Ec =106 × (six digit TFP from thetable) + i
5: Salt and PIN values corresponding to Ec is used to generate a fake card
6: exit
7: end if
8: endfor
Trade-off between table size and per EPB attack cost. The per account cost of the above attack is not high
enough to deter an attack. However, the setup cost of building the table with all one trillion EPBs is apparently
significant (although this is a one-time cost). By reducing the table size, the attack can be launched with fewer API
calls although the per EPB attack cost increases accordingly.
6
Assume that the attacker builds a table of 10 EPBs (i.e. one half of the original table size) containing TFPs
endingwithsixzeros(000000),i.e.,storingonlythefirstsixdigitsofaTFP.Withthistable,anattackercancalculate
TFP of any target EPB E in 106 steps (assuming the EPB arrives in ISO-1 format, or the attacker translates it
c
into ISO-1); each step then requires one API call. The attack is described in Algorithm 1.

8
Now the cost of attacking N accounts is 106+N ×106 API calls. The attacker can also vary the table size and
the numberof steps foreachtargetaccount.For anytable size 10n forn∈{2,3,...,12},the requirednumber ofper
account translate steps is 1012−n. Thus in general the cost of attacking N account is 10n+N ×1012−n.
4.2 Replay Attack
In this attack, an adversary M at a switch or verification center collects a valid EPB E for a target PAN A , and
i c c
then creates a fake card with the account number A (and any salt value). Note that M here does not know the
c i
actual salt value or PIN for the target account. An accomplice M uses the fake card with any PIN at an ATM,
a
andthe ATMgeneratesafalse EPBE .At the switch/verificationcenterM locatesE intransfer,andreplacesE
a i a a
with the previously collected correct EPB E . Thus the fake card will be verified by the target bank, and M can
c a
access the victim’s account.
Notethatthisattackworksagainstthebasicvariantofsalted-PINaswellascurrentPINimplementationswithout
requiring any API calls. Although quite intuitive, this attack has not been discussed elsewhere to our knowledge.
5 Variants of Salted-PIN
As we discussed in Section 4, the basic version of salted-PIN is vulnerable to several attacks. Other than the replay
attack, the setup cost of launching these attacks is not trivial as previous PIN cracking attacks (cf. [4]) although
the per account attack cost is apparently manageable. In this section, we outline three variants of salted-PIN to
practically restrict these attacks by increasing the per account attack cost.
Service-point specific salted-PIN. If a fake bank card is created for a target account (e.g. through the attacks
in Section 4), the card can be used from anywhere as long as it remains valid (i.e. the issuing bank does not cancel
it). To restrict such attacks, we modify equation (3.1) as follows.
PIN =f (PAN,PIN,spsi) (5.1)
t Salt
Herespsistandsforservice-point specific information suchasa‘cardacceptoridentificationcode’and‘cardacceptor
name/location’ as in ISO 8583 (Data Elements fields). The verification center must receive spsi as used in equation
(5.1). Although any PINcrackingattack (Section 4.1)can be used to learna TFP orbuild a full/partialEPB table,
the table is valid only for the particular values of spsi. Also, the replay attack (Section 4.2) may succeed only when
the accomplice exploits a compromised card from a particular ATM. Thus this construct generates a localized TFP
for each PIN verification, and thereby restricts the fake card to be used only from a particular location/ATM. Note
that for this variant, the verification facility cannot use PVV or Offset values, because they would be different for
each ATM. Another verification value would need to be designed.
Salted-PIN with double EPBs. ISO PIN block formats restrict PIN length to 12 digits in an EPB. This length
limit enables a search of O(240) in a pre-built table (see in Section 4.1). As a variant, instead of choosing 12 digits
from the result of equation (3.1), we can take 24 digits (i.e. PRF output modulo 1024) and create two PIN blocks,
t
each12digitslong.Asaresult,twoEPBsmustbe sentfromanATM,andaverificationfacilityneedsbothEPBsto
verifyauser’sPIN.However,intermediateswitchesmaynotneedtobeawareofthis.AnattacksimilartoSection4.1
can be launched on each EPB separately, and two tables can be built for both parts of a 24-digit TFP; the cost
of building the table simply doubles (two TFP tables, each has 1012 entries). Using the tables, a 24-digit TFP can
be extracted from the two EPBs of any target account. However, determining a valid pair of salt value and PIN is
not straightforward as the attack in Section 4.1. To generate a fake card (i.e. to find an appropriate salt value and
PIN for the intended TFP) for this variant of salted-PIN, attackers must apparently carry out a computation of
1024 (i.e. O(280)) steps. However, this variant is vulnerable to the replay attack (Section 4.2) when equation (3.1)
is used. Again, service-point specific information as used in equation (5.1) for generating TFP can practically limit
such attacks.
End-to-end PIN encryption/MAC. Using the stored salt as an encryption key, end-to-end PIN encryption can
be achieved between an ATM and verification center. The salt value can also be used for calculating a message
authentication code (MAC) for a user’s Final PIN. This variant can secure PIN transportation to the extent of the
algorithmusedforencryptionorMAC.Thusitcaneffectivelyeliminate PINenumerationby anattackerataswitch
or verification center. However, to restrict the replay attack (Section 4.2), one or more service-point specific items
must be used with a PIN for encryption or MAC.

9
6 Implementation Challenges
One implementation challenge for salted-PIN could be the storagerequirement for the salt (39 decimal digits or 128
bits) that must be stored on a bank card. There are four possible scenarios: (1) magnetic-stripe (magstripe) cards;
(2) chip-card with a magnetic stripe at a magstripe reader terminal; (3) chip-card with online PIN verification; and
(4) chip-card with offline PIN verification. For the last case, as a PIN does not leave the card, PIN cracking attacks
areimmaterial.For the firsttwo cases,the amountofdata thatcanbe storedona magnetic stripe is limited by ISO
standards; for example, according to ISO-7811,track one in a magstripe bank card holds 79 six-bit characters (plus
a parity check), and track two holds 40 four-bit (plus a parity) characters.These two tracks are generally present in
most magstripe bank cards (there is also a third track on some cards). A salt may be stored on a magstripe card
by overloadingnon-essentialdata fields in track one (e.g. discretionary data, name, expirationdate), and redundant
fields in track two (e.g. PAN). Chip-cards offer significantly more storage capability, and thus for the third case,
accommodating the salt may not be an issue.
Salted-PIN requires that service points (e.g. ATMs, point-of-sale terminals) are capable of computing PRF as in
equation (3.1). Thus another implementation challenge is posed by the limited computing ability of old magstripe
readerterminals withlimited CPUcapabilitiesandcryptographicsupportofonly a DESchip; recentterminals (e.g.
Motorola’s PD4750) generally operate on a 32-bit processor,and computing a PRF is not a computational issue.
7 Review of Earlier PIN Cracking Attacks
For convenience to the reader and for reference within, here we summarize several representative attacks from
BerkmanandOstrovsky[4].Forreasonsofbrevity,weomithowsomespecific assumptionsrequiredbytheseattacks
are met, as well as any efficiency analysis of these attacks (e.g. how many API calls are required for a given attack
to succeed).
7.1 Translate PIN Block Attacks
We now review the translate-only API attack which requires an attacker to generate/collect Encrypted PIN Blocks
(EPBs) of all possible PINs, and access to the translate API function. This attack reveals plaintext PINs, and can
be applied at a switch or verification facility. The steps in the attack are as follows.
1. Let A be any attacker chosen PAN.
x
2. Attackers collect/generate 10,000 EPBs which pack all possible PINs in any ISO format (i.e. the format and
PAN of those EPBs are immaterial). Suppose i is any 4-digit PIN, and E′ packs i in any ISO format.
i
3. Translate all 10,000 EPBs to ISO-0 EPBs using A as the PAN. Assume E is the resulting EPB from the
x i
translation API.
E
i
=Translate ISO−0(E
i
′ ,A
x
),where i∈{0000...9999}.
Now E packs PIN i in the ISO-0 format (with respect to A ). Make a table with the resulting EPBs and PINs,
i x
i.e., (E , i).
i
4. For any customer EPB, E , calculate
c
E
t
=Translate ISO−0(Translate ISO−1(E
c
),A
x
).
Here,anattackerfirstconvertsthecustomerEPBtoISO-1(whichunlinksaPINwiththecorrespondingcustomer
PAN), and then uses this result with the attacker’s chosen PAN to generate an EPB in ISO-0 format.
5. Locate E in the table generated at step 3. The corresponding PIN is the PIN packed inside E .
t c
7.2 Attacks Exploiting the IBM Calculate-Offset API
The steps in the IBM Calculate-Offset attack at a verification facility and intermediate switch are now outlined.
Calculate-Offset Attacks at a Verification Facility. Here the attackeris someone at a verificationfacility, e.g.,
an application developer. The steps in the attack are as follows.
1. Generate an EPB E that packs a known Final PIN PF .
a a

10
2. For any customer account, A , calculate:
c
offset =CalculateOffset(E ,A ).
a c
Ifthecustomer’sNaturalPINisPN ,thenoffset =PF −PN .Here‘−’isdigitbydigitmodulo10subtraction;
c a c
offset and PF are known to the attacker. Thus the attacker learns the customer’s Natural PIN. If the attacker
a
can read the plaintext offset value of the customer, then the customer’s Final PIN is revealed.
Calculate-Offset Attack at a Switch. The steps of a calculate-offset attack at a switch are as follows.
1. Generate an EPB E that packs a known Final PIN PF .
a a
2. Select any (random) PAN A .
x
3. Assumethatattackersdonothaveaccesstotherealissuerkeyataswitch.However,theycancalculateadummy
offset using a dummy issuer key (i.e. whatever issuer key is available in the switch’s HSM):
offset =CalculateOffset(E ,A )
d1 a x
i.e., offset = PF −PN . Here PN is the dummy Natural PIN with respect to the account A . So now
d1 a xd xd x
PN can be calculated as both PF and offset are known.
xd a d1
4. For any customer EPB E which packs the customer’s Final PIN PF , calculate:
c c
offset =CalculateOffset(E ,A )
d2 c x
i.e., offset =PF −PN . The value of PN is known from the previous step, thus revealing the customer’s
d2 c xd xd
Final PIN.
7.3 Attacks Exploiting the VISA PIN Verification Value (PVV)
The steps in the VISA PVV attack at a verification facility and intermediate switch are outlined below.
PVV Attacks at a Verification Facility. Attackers need an EPB with a known PIN, and may need write access
to the issuer’s PVV database. Again, like offset values, PVVs are considered security insensitive. The attack is as
follows.
1. Generate an EPB E which packs a known Final PIN PF .
a a
2. For any customer PAN A ,
c
pvv =CalculatePVV(E ,A ).
a c
3. Use the calculated PVV with known PIN to create new bank cards (this may also require updating the PVV
database at the verification facility).
PVV Attacks at a Switch. Using 10,000EPBswhichpack allpossible PINs,attackerscan revealcandidate PINs
(less than two, on average)for any customer as follows. Note that the attack HSM here does not have access to the
real issuer PVV key; the attack succeeds if any PVV key is available.
1. Choose any PAN A .
x
2. Generate EPBs for all possible PINs; assume E packs PIN i, where i∈{0000...9999}.
i
3. For all EPBs generated in step 2, calculate PVVs with respect to A :
x
pvv =CalculatePVV(E ,A ).
i i x
Now sortthe values of pvv and build a table of entries (pvv ,i). More than one (on averageless than two) PINs
i i
may be indexed by a given PVV.
4. For any customer EPB E , compute
c
pvv =CalculatePVV(E ,A ).
c x
Use the resulting PVV as an index to the table built in step 3. The corresponding PIN is the customer’s Final
PIN PF ; in case of multiple PIN values indexed by pvv, PF is one of those values; building the table using a
c c
different A may resolve collisions.
x

11
8 Conclusion
Inthe30-yearhistoryoffinancialPINprocessingAPIs,severalflawshavebeenuncovered.Inthispaper,wesummarize
some API attacks from Berkman and Ostrovsky [4] for context, and introduce a salted-PIN proposal and three of
its variants to counter these attacks. Our preliminary analysis in this paper indicates that salted-PIN can provide
a higher barrier to these attacks in practice by making them considerably more expensive (computationally). We
have discussed some deployment issues, but acknowledge that this discussion is not exhaustive; deployment barriers
may arise from unseen aspects. Salted-PIN is motivated primarily by the realistic scenario in which an adversary
may control switches, and use any standard API functions to reveal a user’s PIN; i.e., an attacker has the ability to
perform malicious API calls to HSMs, but cannot otherwise modify an HSM.
Our proposal of salted-PIN is intended to stimulate further research and solicit feedback from the banking
community regarding: (1) whether salted-PIN may improve PIN security in real terms; (2) practical barriers of
deployingsalted-PIN;and(3)anysignificantweaknessesofsalted-PIN.Wefocusonprovidingatechnicalsolutionto
update PIN processing APIs, some of which are well-known to be flawed. Instead of relying, perhaps unrealistically,
on honest intermediate parties (who diligently comply with mutual banking agreements),we strongly encourage the
banking community to invest effort in designing protocols that do not rely on such assumptions which end-users
(amongothers)havenowayofverifying.Ithasbeenspeculated[4]thatPINcrackingattacksmayexplainnumerous
unexplained ‘phantom’ withdrawals [5] as reported by many ATM fraud victims.
Acknowledgements
Thisworkbenefitedsubstantiallyfromdiscussionand/orfeedbackfromanumberofindividuals,including:Bernhard
Esslinger of University of Siegen, Joerg-CorneliusSchneider and Henrik Koy of Deutsche Bank, especially regarding
attacksonthe simple versionofsalted-PIN;a reviewerfroma largeCanadianbank;Glenn Wurster;andanonymous
reviewers.The firstauthoris supportedinpartby anNSERC CGS.The secondauthoris CanadaResearchChairin
Network and Software Security, and is supported in part by an NSERC Discovery Grant, and the Canada Research
Chairs Program.
References
1. Algorithmic Research (ARX). PrivateServer Switch-HSM. White paper. http://www.arx.com/documents/Switch-HSM.
pdf.
2. R.Anderson. Why cryptosystemsfail. Communications of the ACM,37(11), Nov.1994.
3. R. Anderson, M. Bond, J. Clulow, and S. Skorobogatov. Cryptographic processors – a survey. Proceedings of the IEEE,
94(2), Feb. 2006. Invitedpaper.
4. O.BerkmanandO.M.Ostrovsky.TheunbearablelightnessofPINcracking. InFinancialCryptographyandDataSecurity
(FC), Scarborough, Trinidad and Tobago, Feb. 2007.
5. M. Bond. Phantom withdrawals: On-lineresources for victims of ATMfraud. http://www.phantomwithdrawals.com.
6. M. Bond. Understandingsecurity APIs. Ph.D. Thesis, Computer Laboratory, University of Cambridge, 2004.
7. M. Bond. Attacks on cryptoprocessor transaction sets. In Workshop on Cryptographic Hardware and Embedded Systems
(CHES), Paris, France, May 2001.
8. M.BondandP.Zielinski.DecimalisationtableattacksforPINcracking.Technicalreport(UCAM-CL-TR-560),Computer
Laboratory, University of Cambridge, 2003.
9. M.BondandP.Zielinski. Encrypted?Randomised?Compromised?(Whencryptographically secureddataisnotsecure).
In Workshop on Cryptographic Algorithms and their Uses, Gold Coast, Australia, July 2004.
10. J. Clulow. The design and analysis of cryptographic APIs for security devices. Masters Thesis, University of Natal,
Durban,South Africa, 2003.
11. S. Drimer, S. J. Murdoch, and R. Anderson. Thinking inside the box:System-level failures of tamper proofing. In IEEE
Symposium on Security and Privacy (to appear), May 2008. Also avialable as a technical report (UCAM-CL-TR-711) at
http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.html.
12. International Organization for Standardization (ISO). Banking – Personal Identification Number (PIN) management
and security – Part 1: Basic principles and requirements for online PIN handling in ATM and POS systems, Apr. 2002.
International Standard,ISO 9564-1.
13. M. Mannan and P. C. van Oorschot. Using a personal device to strengthen password authentication from an untrusted
computer. In Financial Cryptography and Data Security (FC), Scarborough, Trinidad and Tobago, Feb. 2007.
14. O.M. Ostrovsky. Vulnerabilities in thefinancial PIN processing API. Masters Thesis, Tel AvivUniversity,2006.
15. B.Ross,C.Jackson,N.Miyake,D.Boneh,andJ.C.Mitchell. Strongerpasswordauthenticationusingbrowserextensions.
In USENIX Security, 2005.