Tokenization protects underlying sensitive values (USV) by substituting a pseudonym for storage or processing. However, static tokens increase risk to the USV as they tend to be long-term, stored in databases, reused by applications or detokenized by applications that need the original USV. This session will describe an alternative called derived unique token per transaction (DUTPT). Learning Objectives: 1: Understand basic tokenization methods. 2: Understand payment vs. nonpayment tokenization. 3: Understand DUTPT method. (Source: RSA Conference USA 2018)

1. SESSION ID:
#RSAC
Jeff Stapleton
DERIVED UNIQUE TOKEN PER
TRANSACTION
ASEC-W04
VP Security Architect
Wells Fargo
X9F4 workgroup chair

2. #RSAC
Application Security
2
Solution: tokenization technology
Substitute sensitive data for benign data
Control: benign data is safe
Data in storage
Data in transit
Data in process
Application interoperability
Token aware
Token unaware
Original
Data
Token
Data
App 1
App 2
aware
unaware

3. #RSAC
Token Problems
3
Tokens data elements not well understood
X9 sensitive payment card data tokens www.x9.org
EMV payment tokens www.emvco.com
— Apple Pay, Google pay, Samsung pay
PCI post-authorization tokens www.pcisecuritystandards.org
Tokenization process not well understood
Tokenization versus detokenization
Tokenization systems not well understood
Token vaults

4. #RSAC
WHAT IS TOKENIZATION?
Background Information

5. #RSAC
Tokenization Defined1
5
Tokenization2
Random Table
Encryption MAC3
USV Token
1 RSA 2017 Conference PDAC-R02 Cybersecurity vs. Tokenization
2 X9.119 Protection of Sensitive Payment Card Data – Part 2: Post-Authorization Tokenization Systems
3 ISO 16609 Banking – Requirements for Message Authentication Using Symmetric Techniques
Underlying Sensitive Value Pseudonym or alias

6. #RSAC
Detokenization: Encryption Method
6
Encryption
Decryption
USV Token
USV Token
Token
Key
Token Vault not needed
Need to manage keys

7. #RSAC
Detokenization: MAC1
7
MAC2USV Token
USV Token
Token
Key
Token Vault needed
Need to manage keys
1 Detokenization versus Verification
2 ISO 16609 Message Authentication Using Symmetric Techniques (includes MAC and HMAC)

8. #RSAC
Detokenization: Random
8
RandomUSV Token
USV Token
RNG
Token Vault needed
No correlation between
USV and tokens
RNG: Random Number Generator

9. #RSAC
Detokenization: Table
9
TableUSV Token
USV Token
RNG
Token Vault not needed
PRNG
Table
Static table
RNG: Random Number Generator
PRNG: Pseudo RNG

10. #RSAC
Comparison of Methods
10
Encryption Method
Vulnerable to key compromise
Key management
MAC Method
Vulnerable to key compromise
Key management
Vulnerable to vault attack
Table Method
Vulnerable to table compromise
Table management
Random Method
Vulnerable to RNG compromise
Entropy management
Vulnerable to vault attack
But what about EMV Tokenization?

11. #RSAC
PAN
EMV Tokenization
11
IssuerCardholder
NetworkMerchant Acquirer PAN
TSP
PAN
EMV
EMV
EMV
Visa
MasterCard
Amex
PAN
EMV Chip Card
PAN
EMV
EMV
Card Authorization
EMV token (Random)

12. #RSAC
PCI Tokenization
12
Bank
Identification
Number
Luhn
check
digit
ReceiptRouting BIN
Primary Account Number (PAN)
Token
Token
Major Industry Identifier
MII

13. #RSAC
Tokenization Issues
13
Token replaces USV to protect it from disclosure or misuse
Static tokens have value so might be misused
Static tokens might be detokenized
Token vaults are prime targets
Application access controls
Network segmentation controls
Tokenization services
Who can get a token, who cannot
Who can detokenize, who cannot
Tokenization
Service
TRI
API
APP
Tokenization
Environment
Vault

14. #RSAC
So What if?
14
Each token is used only once
No static tokens
No detokenization
No token vault
Capabilities
Unique token per transaction
No residual data
Ability to verify token
Cryptography based
DUTPT

15. #RSAC
DERIVED UNIQUE TOKEN PER
TRANSACTION (DUTPT)
Background Information

16. #RSAC
DUTPT Parameters
16
Two different one-way functions F(x)  G(x)
Transaction (c = 1, 2, 3, … max) counter
Value (V) to be tokenized
PKI with X.509 certificates
CMS-based digital signatures
CMS-based encrypted data
Client has unique identifier (ID)
Uses value (V) once then destroys
Client ServerV
T1
T2
Tc
…

17. #RSAC
Cryptographic Message Syntax1 (CMS)
17
Signed Data
Certificates, Signer Info
Enveloped or Encrypted Data
Recipient Info, Encrypted Content Info
Encrypted Content Info
SignCrypted Data
Certificates, Signcrypters
Client Server
Client
Exchange
Certificates
Encrypt
Decrypt
Sign
Verify
CEK
1 X9.73 Cryptographic Message Syntax – ASN.1 and XML

18. #RSAC
DUTPT Process: x = 1
18
V
F V1 G T1 E C1
V
F1V1GT1?D T1
IDClient Server
Out of network exchange
c = 1KESign KE Verify
• Inject V using an USV Loading Facility
• Inject V remotely using another protocol
• Inject V1 initially and avoid V altogether
• F(x)  G(x)
• Example: F = SHA2 and G = SHA3
• F(x) or G(x) might use cryptographic keys
• Example: MAC or HMAC
• F(x)  G(x) or KF  KG
• But need to manage keys in Client & Server

19. #RSAC
DUTPT Process: x = 2
19
V
F V1 G T1 E C1
V
F1V1GT1?D T1
ID
F V2 G T2 E C2 F2V2GT2?D T2
Client Server
Out of network exchange
c = 1
c = 2
KESign KE Verify
KESign KE Verify

20. #RSAC
DUTPT Process: x = 3
20
V
F V1 G T1 E C1
V
F1V1GT1?D T1
ID
F V2 G T2 E C2 F2V2GT2?D T2
F V3 G T3 E C3 F3V3GT3?D T3
Client Server
Out of network exchange
c = 1
c = 2
c = 3
KESign KE Verify
KESign KE Verify
KESign KE Verify

21. #RSAC
DUTPT Benefits
21
Unique token per transaction
Each token (Tc) used only once
Next token (Tc+1) not derivable from current token (Tc)
Derived token using cryptographically sound functions
Hash (SHA2, SHA3), MAC or HMAC but F(x)  G(x)
Client does not retain value (V) only next value (Vc)
Value (V) not recoverable from intermittent values (Vc)
Suitable for mobile, IoT or other remote devices

22. #RSAC
Conclusions
22
Derived Unique Token Per Transaction
Conceptual design schema
— No standards or specification at this time
Thinking about application opportunities
— No software implementations at this time
Solution looking for a problem
Audience questions or comments?
Any thoughts, ideas, or interest?

23. #RSAC
Appendix: References
23
International Standards Organization www.iso.org
American National Standards Institute www.ansi.org
Accredited Standards Committee X9 www.x9.org
National Institute of Standards and Technology www.nist.gov
Cryptographic Algorithm Validation Program (CAVP)
Cryptographic Module Validation Program (CMVP)
National Information Assurance Partnership www.niap-ccevs.org
Common Criteria Evaluation and Validation Scheme (CCEVS)

24. #RSAC
Appendix: Standards
24
Accredited Standards Committee X9 www.x9.org
ANSI X9.73 Cryptographic Message Syntax (CMS) – ASN.1 and XML
ANSI X9.82 Random Number Generation (RNG) – multiple parts
ANSI X9.119 Requirements for Protection of Sensitive Payment Card Data – Part 2:
Post-Authorization Tokenization Systems
International Standards Organization www.iso.org
ISO/IEC 7812 Identification cards -- Identification of issuers -- Part 1: Numbering
system
ISO 16609 Message Authentication Using Symmetric Techniques
Europay-MasterCard-Visa Company (EMVCo) www.emvco.com
EMVCo Payment Tokenisation Specification Technical Framework v1.0 March 2014

25. #RSAC
Appendix: Reading
25
Code Breakers: Story of Secret Writing by David Kahn (1967)
Code Book: Science of Secrecy by Simon Singh (2000)
Handbook of Applied Cryptography (HAC) by Menezes, van Oorshot,
and Vanstone (1997)
Security without Obscurity by Jeff Stapleton
A Guide to Confidentiality, Authentication, and Integrity (2014)
A Guide to Public Key Infrastructure (PKI) Operation (2016)
A Guide to Cryptographic Architectures (June 2018)

26. #RSAC
How to apply this session
26
One week
Determine if your organization uses, or plans to use, tokenization
Three months
Determine your tokenization regime (e.g. EMV, PCI, X9, other)
Determine the tokenization method (Encryption, MAC, Random, or Table)
Determine if static tokens or dynamic tokens are useful
Six months
Determine if derived unique token per transaction (DUTPT) makes sense