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