I Know your PIN

I Know your PINI Know your PIN

I Know Your PIN

Jolyon ClulowPrism

[email protected]

IntroductionIntroduction

What this talk is not about: The Internet, SSL, VPNs

What this talk is about: Bank, Credit and Debit cards Banks, Financial Networks and Switches PINs, PANs, ATMs, TRSMs, POS, Mobile

And……(some of the) ways that one can recover

PINs from such supposedly secure systems!

So why are we interested?So why are we interested?

Justification Driver for modern cryptography – the so called ‘killer

app’ of cryptography The concept of a ‘PIN’ is internationally understood

and accepted Scale of use

• Bank, Credit and Debit Cards• Card issuing banks• Card Associations (Visa, MasterCard,etc)

Amount of money protected by these operations Guaranteed that (almost) everyone who reads this,

relies on the security thereof to protect their own personal finances.

Talk OutlineTalk Outline

• Introduction• Background info: What is PIN security?• The attacks• Some remedies• Real world scenarios• The road ahead?• Conclusion

Background infoBackground info

Financial Security 101: An Introduction to PINS

TerminologyTerminology

PIN: Personal Identification Number PAN: Personal Account Number ATM: Automatic Teller Machine (cash

machine) API: Application Programming Interface

(the set of functions exposed/available) API attack: an attack which uses(or

abuses) the existing/available functions to compromise the security of the system

What is a TRSM?What is a TRSM?

Tamper Resistant/Responding Security Module (TRSM)

• Host Security Module (HSM)• Hardware Security Module (HSM)• Crypto Coprocessor

Provides a secure, trusted environment to perform sensitive operations

Detects and responds to physical, electronic (or other) attempts to recover key material or sensitive data. Typical measures include:

• physical tamper envelope/membrane• temperature, radiation sensors• power supply monitoring and filtering

Trigger causes erasure of protected data

Financial Network ArchitectureFinancial Network Architecture

ATM

BankSwitch

BankSwitch

Key ZonesKey Zones

Each connected pair of entities share a common key to form a key zone

ATM

Bank

BankSwitch

Switch

Basic OperationsBasic Operations

3 Basic PIN operations are required:1. Encryption2. Translation3. Verification

ATM

Bank

BankSwitch

Switch

21 3

PIN EncryptionPIN Encryption

e.g. PIN is 1234, Key is 0123456789ABCDEF1. Start with an empty PIN block2. Insert PIN

3. Pad

4. Encrypt the clear PIN block

It’s that simple!

1 2 3 4

1 2 3 4 F F F F F F F F F F F F

2 5 8 0 D 0 D 6 B 4 8 9 D D 1 B

PIN Formats (some examples)PIN Formats (some examples)

VISA Format 3 PIN Block = PPPPFXXXXXXXXXXX

IBM 3624 PIN Block = PPPPxxxxxxxxXXXX

ISO-1 PIN Block = CLPPPPrrrrrrrrRR

where C = X‘1`,

L = X‘4` to X’C`

r is either P or R

VISA Format 2 PIN Block = LPPPPzzDDDDDDDDD

PIN Formats (List).PIN Formats (List).

ISO-0 (ANSI X9.8, VISA-1, ECI1) ISO-1 ISO-2 VISA-2, VISA-3, VISA-4 IBM 3624, IBM 3621, IBM 4700 ECI-2, ECI-3 Docutel Others…

ANSI X9.8 Format (ISO-0)ANSI X9.8 Format (ISO-0)

E.g. For a 4 digit PINP1 = 04PPPPFF FFFFFFFFP2 = 0000AAAA AAAAAAAAWhere AAAAAAAAAAAA represents 12 digits of the PAN

PB = P1 P2EPB = ek(PB) Binds the account number to the PIN Diversifies the encrypted PIN block



ATM

Bank

BankSwitch

Switch

21 3

PIN TranslatePIN Translate

Translate between different zone keysQuestion:

What if different actors/entities use different formats?

Additional operation required PIN Reformat Supports change in PIN formats and PANs



ATM

Bank

BankSwitch

Switch

21 3

PIN VerificationPIN Verification

Exist multiple different approaches Simple Offsets PIN Verification Values(PVV)

Simple Compare the customer supplied PIN with a

reference PIN

PIN Verification (Offsets)PIN Verification (Offsets)

1. Validation data is encrypted under PIN generation (verification) key.

2. Ciphertext is ‘decimalised’ to form IPIN by means of a table.

3. Calculate the offset as OFFSET = PIN-IPIN (where ‘-’ is subtraction modulo 10)

Validation Data

Ciphertext

Digit Replacement

EDE Multiple Encryption

Decimalization Table

PIN GenerationKey

Intermediate PIN (IPIN)

Customer Selected PIN

Digit Subtraction modulo10

Offset

PIN Verification (Offsets)PIN Verification (Offsets)

IBM PIN Offset Algorithm Allows user to choose own PIN (also to

change it easily) Validation data is typically customer

and financial institution specific (e.g. PAN)

‘Decimalization’ by means of a table.0 1 2 3 4 5 6 7 8 9 A B C D E F

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

The AttacksThe Attacks

Attack #1a: ANSI X9.8 Attack• Attacks the PIN translate function.

Attack #1b: Extended ANSI X9.8 Attack• Attacks the PIN translate and reformat functions.

Attack #2: The Decimalization Attack• Attack against PIN verification algorithm using

offsets.

The AttacksThe Attacks

Attack #3: Key Separation #1• Attack against PIN verification functions based on

failure to enforce key separation between verification and translation(encryption).

Attack #4: Key Separation #2• Attack against PIN verification functions based on

failure to enforce key separation for different verification algorithms.

Attack #5: Check Value Attack• Attack against PIN verification algorithm using the

check value of a key

Attack #1Attack #1

ANSI X9.8 (ISO-0) Attack

Attacks the PIN translate/reformat function

ANSI X9.8 (ISO-0) AttackANSI X9.8 (ISO-0) Attack

Input Parameters• Encrypted PIN Block (EPB)• PAN• Encrypted ‘In’ Key• Encrypted ‘Out’ Key

Attack Strategy: In an iterative manner, we make a

modification to the PAN and observe the effects


Under normal operation:Inputs (EPB, P2)PB = dk(EPB)

P1 = PB P2= 04PPPPFFFFFFFFFF

Extract PIN as PPPP

Test that PPPP is valid PIN (i.e. each P is a valid decimal digit)


Instead of supplying the correct PAN (P2) to a call, use a modified PAN (P2’ = P2 )

Inputs (EPB, P2’)PB = dk(EPB)

P1’ = PB P2’= (P1 P2) (P2 )= P1

Say = 0000x000000000P1’ = 04PPPPFFFFFFFFFF 0000x000000000

ANSI X9.8 AttackANSI X9.8 Attack

Q: What happens if (P x) is a decimal digit?

A: The call passes.

Q: What happens if (P x) is not a decimal digit?

A: Typically, the call FAILS!

We have a test for (P x) < 10.

ANSI X9.8 AttackANSI X9.8 Attack

Building a simple algorithm to identify P

1. Try all possible values of x, yielding a unique* pattern of ‘passes’ and ‘fails’ allowing you to identify P.

2. A decision tree

Attack #2Attack #2

The Decimalization Attack

Attacks the PIN Verification using offsets function

Decimalization AttackDecimalization Attack

Input Parameters• Encrypted PIN Block (EPB)• Validation Data• Decimalization Table• Offset• Encrypted Key

Attack Strategy: In an iterative manner, we make a single

change to an entry in the decimalization table and observe the effects


PIN = 6598

PIN Ver Key = 05050505 05050505

Val. Data = 11223344 55667788

Ciphertext= E481FC56 58391418

Dec. Table= 01234567 89012345

IPIN = 4481

Offset = 2117


Dec. Table (0)= 11234567 89012345IPIN = 4481Offset = 2117 (will pass)

Dec. Table (1)= 02234567 89012345IPIN = 4482Offset = 2117 (will fail)

= 2116 (will pass)

Thus far we have identified that the 4th digit in the original IPIN is a 1 and hence that the 4th PIN digit is 1+7 = 8 (IPIN + Offset).


Work factor Initial search for (an unknown) offset

requires at most 104 + (n-4)•10 queries Each change in the dec. table requires at

most 24 + (n-4) queries At most need to try 15 of the 16 entries in

the table for a total of 15(24 + n-4) queries. Attack time dependant on TRSM speed Typical values (dependent on speed of

TRSM):• Known initial offset: 1 – 20 seconds• Unknown initial offset: 10 - 1000 seconds

PropertiesProperties

How efficient are these attacks? Computationally trivial Extremely fast

• Requires just a few seconds on a Pentium I• Typically limited by performance of TRSM

What are the requirements? Requires query access to the device, implying either:

• Physical access to the device/switch/trust center– Special case: Stolen device

• Access to the network transporting transaction traffic and the ability to inject messages

What about in the ‘Real World’?What about in the ‘Real World’?

Real world systems should be following standard industry best practices that if implemented correctly and enforced should limit a potential hacker’s ability to perform such attacks.

Physical access control to restricted area.

Some thoughts and counter arguments. Attacker can attack at weakest point. One institution’s

account holder can be compromised on another institution’s network. Hence must guarantee that all potential networks through which the PIN may travel to be secure.

So why did you buy an expensive TRSM in the first place if your defense rests on physical access control?

Multi-lane Retail Stores

So what went wrong?So what went wrong?

Some functions are just badly thought out and insecure.

Individually secure functions were added to the API in a manner to make entire system insecure. Insufficient attention was given to the possible interplay between functions.

Absence of a single standard to which everyone completely adheres to (many different formats and algorithms exist due to historical reasons).

Different customers want different functionality from the same product.

Solutions - CryptographicSolutions - Cryptographic

Remove ‘weaker’ algorithms/functions (leave only the strongest)

Parameter(data) Integrity MAC the PIN block and data

• PAN, PIN block format, etc MAC any verification/generation data

• Decimalization table, Validation data, TSP, etc A better PIN Block Format?

Key Separation Format (PIN Block Variance) Algorithms Other data (e.g. PAN)

Solutions – Access ControlSolutions – Access Control

Electronic access control Fine grained, allowing the individual

enablement/disablement of• Formats• Algorithms• Functions

Limit functionality. Only enable what is required. Disable everything else.

Useful to allow a function to be disabled should it later be shown insecure.

True split control

Hackers and Threats?Hackers and Threats?

Real world scenarios: Risk, Reward and Liability

DisclaimerDisclaimer

This material is made available as a courtesy, purely for educational and informative purposes only for an intended audience of responsible individuals with a genuine interest in improving the security of financial networks.

Prism makes no claim as to the accuracy or completeness of this information.

Prism accepts no responsibility or liability arising from the use of this material.

Insider attackInsider attack

1. Extract the PIN number for a given account (or accounts)

2. Create a duplicate ‘white card’ (or multiple duplicate cards)

3. Distribute to accomplices to perform a random tour of ATMs

Insider Attack - RewardInsider Attack - Reward

Let N be the number of compromised accounts, P the average period before unnatural transaction behavior is noticed and L the daily withdrawal limit.

Total Fraud Value = NPL

Example: N = 5000 P = 2 L = $1000Total Fraud = $ 10 M

Account Holder AttackAccount Holder Attack

1. Produce a number of duplicate ‘white cards’ of your own card

2. Distribute to multiple accomplices, preferably in different geographical locations to perform a random tour of ATMs.

3. Report the ‘unauthorized’ activity on your account and dispute the transactions.

Account Holder Attack (cont.)Account Holder Attack (cont.)

It may be advisable to perform a valid transaction “simultaneously” with a fraudulent one since this ‘proves’ you are in possession of your card and preferably in a different location.

Best done by multiple card holders from a given institution since:

Not an isolated incident Questions the security of the institution Gives the impression of a possible insider attack

Account Holder Attack - RewardAccount Holder Attack - Reward

Let N be the number of conspiring account holders, P the average period before unnatural transaction behavior is noticed and L the daily withdrawal limit.

Total Fraud Value = NPLAverage return = PL Example:

N = 100 P = 10 L = $1000Total Fraud = $ 1 MAverage return per account holder = $ 10 K

The Repudiation AttackThe Repudiation Attack

Just deny a transaction Dispute procedure leading to possible litigation Argue the insecurity of the system Best if security of institution already questioned

Scenario:Following a successful account holder/insider attack

being made public – other account holders (acting individually) may dispute valid transactions that occurred during the attack period (or after)

Financial risk is great due to the possible scale (e.g. 0.1 % of an institution’s 1,000,000 customers each disputing a $1000 transaction = $1 M)

Loss of confidence in the given institution could well be more damaging

Other IdeasOther Ideas

The Competitor Attack Use own network to compromise a competitor

institution (could even choose to use administrator privileges to effect this)

Reward not the stolen money but the ‘after effects’ Less of a connection between accomplices and

institution (no cash trail leading back) The Stock Market Attack

‘Short’ the stock prior to any attack (no cash trail) The Terrorist Attack

All/any combinations of all the previous attacks

What now?What now?

Q: What should you do now if you are a bank? Contact your vendor, request any best practices

information and implement it. Be vigilant. Increase your auditing. Reassure your clients. Wait. Positive pressure on the role players.

Q:Is that all?The nature of the problem is such that it is not yours

alone (unless you disconnect from the network). The entire network must be secured and until that happens you and your account holders are potentially vulnerable.

The road ahead?The road ahead?

Process driven by Card Associations? Due to role and influence over the infrastructure

Revise the standards New design/security requirements. Prescriptive requirements limiting what

functionality is allowed. Vendors will then update products based on

revised standards Expecting (and hoping) for more uniformity and

collaboration between different vendor product offerings. (Makes business sense for institutions)

Card associations will mandate new requirements to institutions.

The unanswered question?The unanswered question?

Who is liable in the event of such an attack leading to fraud?

SummarySummary

A set of API attacks which allow PIN recovery

Design criteria/suggestions to combat the attacks

Some potential attack scenarios

The final comment…The final comment…

The most concerning aspect of these attacks, is that you can be attacked on

someone else’s network – a network over which you have little or no control.

Documents

I Know your PIN