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.
6. 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.
5. Generate an EPB E which packs a known Final PIN PF . a a
6. For any customer PAN A , c pvv =CalculatePVV(E ,A ). a c
7. 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.
8. Choose any PAN A . x
9. Generate EPBs for all possible PINs; assume E packs PIN i, where i∈{0000...9999}. i
10. 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.
11. 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.