Post on 11-Mar-2018
Privacy Models in the Payments Industry*
Terence Spies Voltage Security
* plus some editorializing
Why “Real-‐World Crypto”?
Academic Crypto Enterprise Crypto
Security Methodology
Define a model, show security in that model.
Does this reduce risk, regulatory or audit cost?
Credibility Peer-‐reviewed publicaJon Standards (ie. NIST) acceptance
Success Criteria Novelty, PublicaJon Cost-‐effecJve implementaJon
If we define the “Real World” as enterprises….
Real-‐world security models typically involve cost, legacy, and business process concerns that can be more complex than the underlying
crypto model.
Why the disparity?
• Three factors: 1. Parsing crypto papers is extremely difficult 2. Crypto demos neglect the salient property 3. Cryptographers keep changing their minds
A distributed system is a system where I can’t get my work done because a computer has failed that I’ve never even heard of.
Leslie Lamport A real-‐world cryptographic system is a system where I can’t secure my data because a computer has succeeded that I’ve never even heard of.
Every security customer ever
A Real-‐World Example: Payments
• How payment systems work • Cryptographic soluJons in payments • Future problems / models
What happens when a credit card is swiped at a retail terminal….surely that’s encrypted, right?
DefiniJons
• PIN – Personal IdenJficaJon Number, used to authenJcate ATM and Debit transacJons
• PAN – Primary Account Number. The number printed on the front of a credit or debit card.
• Track Data – Data read from the two magneJc stripes on the back of a credit card.
• POS – Point-‐of-‐Sale. The terminal reading a payment card.
PIN Security
• PIN Entry Devices (PEDs) are provisioned with individual keys. – Session or transacJon keys are created (X9.24)
• The PIN is encrypted with the session key and PAN as randomizer – MulJple standards for DES and 3DES pinblock creaJon-‐ (ISO 9564)
• Key management standards require PINs do not appear outside HSMs.
Payment Standards • Payment standards evolve very slowly – 3DES is the default standard – Some PIN blocks are sJll DES encrypted – US and ISO AES pinblock standards in progress
• Why? – Cost of physical upgrade – No single party in charge
• Millions of retailers • Hundreds of intermediaries
– Extremely complex business processes • Recurrence, chargeback, preauth
Solving the PAN problem • Payment systems were built with the assumpJon that PINs are private.
• But no assumpJon of PAN privacy – Receipt prinJng uses last 4 PAN digits – Card rouJng uses first 2-‐6 digits – Fuel cards use arbitrary digits
• PANs have value to ahackers – Web transacJons – PrinJng fraudulent cards
• Merchant PAN databases == breach risk – Storage at processors, lodging, etc.
Ahempt #1: SET / STT
• The STT and SET protocols ahempted to solve PAN privacy via public key encrypJon & signature.
• SET was cryptographically feature rich • It was also extremely complex – Programmer’s Guide: 619 pages – Protocol SpecificaJon: 250+ pages
Why SET Failed the Real-‐World Test
• SET had lots of interesJng features (dual signature, etc.), but…..
Academic Crypto Enterprise Crypto
Security Methodology
Define a model, show security in that model.
Does this reduce risk, regulatory or audit cost?
Credibility Peer-‐reviewed publicaJon Standards (ie. NIST) acceptance
Success Criteria Novelty, PublicaJon Cost-‐effecJve implementaJon þ ý þ
?
PCI
• In 2004, the major card brands join to form the Payment Card Industry Data Security Standard (PCIDSS)
• Imposes a set of requirements, and sets up a Qualified Security Assessor (QSA) audit framework. – Requirement 3: Protect stored cardholder data – Requirement 4: Encrypt transmission of cardholder data
PAN EncrypJon
• Goal: Encrypt at POS • Does TLS or other protocols solve this problem? No. – ExisJng payment system intermediaries – Security for stored PANs
The Simple Case: Small Merchant
Card swipe
Processor / acquirer
13
Issuer Bank, Inc.
Card Brand
(C) Voltage Security, Inc. All Rights Reserved
Visa, MC, etc.
PIN Privacy Model
Card swipe
Processor / acquirer
14
Issuer
Card Brand
(C) Voltage Security, Inc. All Rights Reserved
PIN is private from entry unJl it is checked at the issuer. HSM based reencrypJon is done at the processor.
Simple PAN Privacy Model
Card swipe
Processor / acquirer
15
Issuer
Card Brand
(C) Voltage Security, Inc. All Rights Reserved
In this case, link encrypJon actually would seem to do the job.
More Complex Case Card swipe
Card Brand
POS terminal
Controller
Switch / Gateway
Processor / acquirer
16
Issuer
(C) Voltage Security, Inc. All Rights Reserved
e-CommerceCard Not PresentCard Present
Payments Industry
CountertopTerminals
Integrated Terminals
MobileTerminals
Mobile Wallets
Call CenterOrder Processing
Bill Pay Shopping Carts
Con
sum
ers
Car
dB
rand
sM
erch
ants
Version 1.1
Point-of-Sale SystemsPayment Applications
Paym
ents
Ser
vice
s
Payment Networks
Card Processors
Gateways
Hosted Pay Pages
Virtual Terminals
Store ControllersTransaction Switches
Self-Hosted Webstore
Authorization Transaction Flow
ERP SystemsRecurring Payments
MSRs
Deployable PAN EncrypJon
• A realisJc soluJon must: – Be secure – Not break every exisJng payment protocol
• Why not create a new protocol? – Every processor has it’s own message standard – ISO 8583 defines a framework, but all processors modify it
• Only baseline is the PAN and track data itself
Format Preserving EncrypJon
• Build a cipher so ciphertext looks like plain – Maintain length and alphabet
• Use a tweakable cipher to allow plain digits
4321 0001 0002 1234
FPE Cipher K
4321 0098 3409 1234
Tweak 4321 00 1234
History of FPE
• The first DES FIPS document (FIPS 74, in 1981) contains a secJon on character set preservaJon!
• An example of a user asking the crypto community for a primiJve. – Smith and Brightwell, “Using datatype-‐preserving encrypJon to enhance data warehouse security”, 1997 NIST conference
– Defined the pracJcal need and use, but proposed no secure soluJon
• Best alternaJve was storing plaintext in a database, returning a random index in the right format.
Format Preserving EncrypJon ` n ! ` ` n ! `
A0 B0
C0B0 A1 B1
n, T, 0
KF
KF
C2B2 A3 B3
KF
KF
C1B1 A2 B2
C3B3
`
n, T, 1�
A0 B0
C0 = B1 B0 = A1
B2 = C1
n, T, 1�
A2 = B1
n, T, 0
KF
KF
C2 = B3 B2 = A3
n, T, 3�
n, T, 2
KF
KF
B4 = C3A4 = B3
n, T, 2
n, T, 3�
Figure 1: Illustration of FFX encryption when method = 1 (left) and method = 2 (right). The first four rounds are shown. The divided boxes on the left are used to illustrate the re-partitioning of a string; for example, string B0C0 is exactly the string A1B1, where |C0| = |A1| = ! and |B0| = |B1| = n! !. No such re-partitioning occurs on the right, but strings get two names instead. All boxed strings are over Chars = {0, 1, . . . , radix ! 1}, while T is a byte string, n " 2 is a number, and 1 # ! # n! 1 is the imbalance.
that leading zeros are counted just like any other character. By Chars ! we mean the set of strings over Chars having any length. If X,Y $ Chars ! are strings we let XY or X % Y denote their concatenation. The i-th digit of a string X will be denoted X[i], for any i $ {1, . . . , |X |}. For 1 # i # j # |X | we let X[i .. j] = X[i] · · ·X[j].
The function ! takes a pair of equal-length strings and returns a string of the same length. Two possibilities are allowed: characterwise addition and blockwise addition. For characterwise addition, a1 · · · an ! b1 · · · bn = c1 · · · cn where ci = (ai + bi) mod radix. For blockwise addition, c1 · · · cn is ! "! !instead the unique string such that ciradix
n"i = airadixn"i + biradix
n"i# mod radixn. For
example, when radix = 10, characterwise addition would have 439 ! 724 = 153 while blockwise addition would result in 439 ! 724 = 163. The function " correspondingly takes a pair of equal-length strings and returns a string of the same length. It is determined by saying that X" Y is the
3
Cryptographic challenge is to build a small domain cipher. Rogaway and Black in 2002 show the first provably secure techniques, using a PRP model. Work by Bellare, Ristenpart, Rogaway, Stegers shows improved results for construcJng FPE ciphers using Feistel networks.
What about the intermediates?
Card swipe
Card Brand
POS terminal
Controller
Switch / Gateway
Processor / acquirer
22
Issuer TBTF Bank, Inc.
(C) Voltage Security, Inc. All Rights Reserved
Now just have random PAN encrypJons
TokenizaJon
• Generically, the replacement of a PAN with a random subsJtute.
• TokenizaJon creates a 1:1 replacement, enabling protecJon of permanently stored PAN data.
• Enables limited computaJon (idenJty)
Processor / acquirer
Encrypted PANs
Tokenized PANs
Tokenized PAN Privacy
Card swipe
Card Brand
POS terminal
Controller
Switch / Gateway
Processor / acquirer
24
Issuer
(C) Voltage Security, Inc. All Rights Reserved
Pass encrypted PAN. Use returned token equivalence and plain digits for computaJon
Future Work
• MulJple standardizaJon efforts (PCI and X9) are now working on security definiJons for tokenizaJon and encrypJon of card data.
• Database vs encrypJon vs hashing – Are there real differences? – How do we explain and build requirements?
• Next generaJon PIN block and key management standards – AES pinblock – AES DUKPT