Privacy Models in the Payments Industry*

Transcription

1 Privacy Models in the Payments Industry* Terence Spies Voltage Security * plus some editorializing

2 Why Real- World Crypto? If we define the Real World as enterprises. 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 Real- world security models typically involve cost, legacy, and business process concerns that can be more complex than the underlying crypto model.

3 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

4 A Real- World Example: Payments What happens when a credit card is swiped at a retail terminal.surely that s encrypted, right? How payment systems work Cryptographic solujons in payments Future problems / models

5 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.

6 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.

7 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

8 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.

9 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

10 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 þ ý þ?

11 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

12 PAN EncrypJon Goal: Encrypt at POS Does TLS or other protocols solve this problem? No. ExisJng payment system intermediaries Security for stored PANs

13 The Simple Case: Small Merchant Card swipe Processor / acquirer Card Brand Visa, MC, etc. Issuer Bank, Inc. (C) Voltage Security, Inc. All Rights Reserved 13

14 PIN Privacy Model Card swipe Processor / acquirer Card Brand PIN is private from entry unjl it is checked at the issuer. HSM based reencrypjon is done at the processor. Issuer (C) Voltage Security, Inc. All Rights Reserved 14

15 Simple PAN Privacy Model Card swipe Processor / acquirer In this case, link encrypjon actually would seem to do the job. Card Brand Issuer (C) Voltage Security, Inc. All Rights Reserved 15

16 More Complex Case Card swipe Switch / Gateway POS terminal Processor / acquirer Controller Card Brand Issuer (C) Voltage Security, Inc. All Rights Reserved 16

17 Payments Industry Authorization Transaction Flow Card Present Card Not Present e-commerce Consumers Countertop Terminals Integrated Terminals Mobile Terminals Mobile Wallets Call Center Order Processing Bill Pay Shopping Carts Point-of-Sale Systems Payment Applications Merchants MSRs Store Controllers Transaction Switches ERP Systems Recurring Payments Self-Hosted Webstore Gateways Card Processors Virtual Terminals Hosted Pay Pages Payments Services Version 1.1 Payment Networks Card Brands

18 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

19 Format Preserving EncrypJon Build a cipher so ciphertext looks like plain Maintain length and alphabet Use a tweakable cipher to allow plain digits Tweak FPE Cipher K

20 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.

21 Format Preserving EncrypJon n ` ` n ` B 0 n, T, 0 B 1 n, T, 1 F K C 0 F K ` A 0 B 0 C 0 = B 1 B 0 = A 1 n, T, 1 F K F K n, T, 0 Cryptographic challenge is to build a small domain cipher. Rogaway and Black in 2002 show the first provably secure techniques, using a PRP model. B 2 n, T, 2 B 3 C 1 F K C 2 A 2 = B 1 F K B 2 = C 1 n, T, 2 C 2 = B 3 B 2 = A 3 Work by Bellare, Ristenpart, Rogaway, Stegers shows improved results for construcjng FPE ciphers using Feistel networks. n, T, 3 F K n, T, 3 F K C 3 A 4 = B 3 B 4 = C 3 ration of FFX encryption when method =1 (left) and method =2 (right). The are shown. The divided boxes on the left are used to illustrate the re-partitioning of a e, string B 0 C 0 is exactly the string A 1 B 1, where C 0 = A 1 = l and B 0 = B 1 = n l. ioning occurs on the right, but strings get two names instead. All boxed strings are over radix 1}, while T is a byte string, n 2isanumber, and 1 l n 1 is the imbalance.

22 What about the intermediates? Card swipe Switch / Gateway POS terminal Processor / acquirer Now just have random PAN encrypjons Controller Card Brand Issuer TBTF Bank, Inc. (C) Voltage Security, Inc. All Rights Reserved 22

23 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) Encrypted PANs Tokenized PANs Processor / acquirer

24 Tokenized PAN Privacy Card swipe Switch / Gateway POS terminal Controller Processor / acquirer Card Brand Pass encrypted PAN. Use returned token equivalence and plain digits for computajon Issuer (C) Voltage Security, Inc. All Rights Reserved 24

25 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