Evaluating Tokenization Systems

Transcription

1 White Paper Security Evaluating Tokenization Systems

2 Table of Contents page Abstract: Evaluating Tokenization Systems... 1 The Tokenization Model... 1 Risks and Attacks... 2 Attack 1: Guess Secret Data... 3 Attack 2: Predict Random Mapping... 3 Attack 3: Subvert Access Control Rules... 4 Attack 4: Subvert Tokenization Isolation... 5 Conclusion... 5

3 Tokenization is an approach to securing structured data (usually PAN or other regulated payment data) by mapping sensitive data items to random values that share some characteristics with the original data. Abstract: Evaluating Tokenization Systems This white paper provides a general model for tokenization systems that encompasses database, table, and encryption-based models. This model is used to examine the potential attacks against tokenization systems and the effect of various design decisions on risk and compliance exposure. The design decisions used in the Micro Focus Voltage Secure Stateless Tokenization (SST) system are also evaluated in this model. The Tokenization Model Tokenization is an approach to securing structured data (usually PAN or other regulated payment data) by mapping sensitive data items to random values that share some characteristics with the original data. By doing this, many existing applications can use the random token value without risk of exposing the original values, often with accompanying reduction in regulatory costs. To accomplish either risk or regulatory/ audit reduction, the token values must not leak data to an attacker, even in situations where the attacker might have multiple token/pan pairs or other artifacts of a data breach. This is done by creating a random mapping from a PAN to a token, based on some secret data that is denied to the attacker. The abstract diagram shows the architecture of a credible tokenization system. Secret Data Random Mapper Access Control Rules PAN Data Token Applications Figure 1. Tokenization Model This model has a few important features: 1. The tokenization system is isolated from the application. This enables control over which applications can tokenize and detokenize data. Access to the tokenization system is controlled with a set of access control rules. 1

4 White Paper Evaluating Tokenization Systems 2. The tokenization system specifically isolates some secret data. This secret data is the basis for the token mapping. The secret data must be large enough to not be guessable by the attacker. 3. The tokenization system contains a procedure for using the secret data to create a random mapping from PAN to token values. This is critical both for security and for PCI compliance. In the case of a database tokenization system, the secret data is the database containing the PAN to token mapping, and the random mapper is the function that creates a random token and inserts the mapping. Encryption-based tokenization uses a cryptographic key as the secret data, and a format-preserving encryption function to generate tokens. Table-driven tokenization (such as Voltage SST) systems use a pregenerated table as the secret data and use some function over the table and PAN to generate the token. Note that in the case of table-driven and encryption-based tokenization systems, it is imperative that the random mapping function creates a mapping that is provably indistinguishable from the random map created by a database system. Failure to do this yields potentially predictable tokens, and exposes the user to regulatory risk, as X9 and PCI appear to be moving to adopt this requirement for all tokenization systems. The design criteria around mapping functions will be examined in Attack 2: Predict Random Mapping. Risks and Attacks Given this model, we can examine the universe of possible attacks available to someone looking to extract PAN data from a system using tokens, and why various design criteria are important: Encryption-based tokenization uses a cryptographic key as the secret data, and a formatpreserving encryption function to generate tokens. Table-driven tokenization (such as Voltage SST) systems use a pregenerated table as the secret data and use some function over the table and PAN to generate the token. By examining each attack in detail, we can assess the requirements that arise from that class of attack and measure the strength of various systems against those attacks. By examining each attack in detail, we can assess the requirements that arise from that class of attack and measure the strength of various systems against those attacks. Attack 2 Predict random mapping Secret Data Random Mapper Access Control Rules Attack 1 Guess secret data Attack 3 Subvert access rules Attack 4 Subvert isolation of tokenization system PAN Data Token Applications Figure 2. Risks and Attacks 2

5 Attack 1: Guess Secret Data Description Given a set of token and PAN values, an attacker might choose to try to guess the secret data used to generate the mapping and then use this data to detokenize other tokens that had been extracted in a data breach. Requirements In general, this is the least likely route of attack against a realistic token system. Credible encryption-based systems utilize at least 128 bits of entropy in the key, which is regarded as essentially impossible to bruteforce guess. For table-based systems, they must use at least 128 bits of entropy in table creation. Voltage SST The SST system uses megabits of entropy to create the initial mapping table, and also utilizes a 128-bit AES operation, making a guessing attack extremely infeasible. Attack 2: Predict Random Mapping Description The attacker might use characteristics of the mapping function to distinguish it from a random function and use these characteristics to reverse token mappings or reduce the number of digits that they need to guess. This attack also has regulatory consequences, in that the discovery of regularities in the mapping might cause the application system to be regarded as being within PCI scope. To quote the PCI Tokenization Guidelines: Whichever generation method is used, the recovery of the original PAN must not be computationally feasible knowing only the token or a number of tokens. This is true for both single-use and multi-use tokens. Additionally, access to multiple token-to-pan pairs should not allow the ability to predict or determine other PAN values from knowledge of only tokens. Tokens should have no value if compromised or stolen, and should be unusable to an attacker if a system storing only tokens is compromised. Setting the bar at creating mapping procedures that are indistinguishable from perfectly random mappings allows use of these procedures without fear that some future attack will enable reversing the mapping process, and also that the mapping procedure does not allow amplifying attacks where the knowledge of a few token-pan pairs enables discovery of PAN information from other tokens. Insisting on provable security also ensures that as standards evolve, there is a clear justification for use of that function. 3

6 White Paper Evaluating Tokenization Systems Requirements This is a realistic attack, both technically (in that algorithmic failures are fairly common in the security world) and from an audit perspective (in that the customer must be able to demonstrate the lack of this weakness to standards set by X9.119 and future PCI standards).one of the main difficulties with this attack is that it is impossible to simply test a bad mapping function might appear random to the naked eye, but actually have important weaknesses. To meet the tokenization guideline above, a table or encryption-based system must be provably secure, meaning that there is some demonstration that an attacker with PAN-token pairs cannot distinguish any regularity in the mapping function. Simple examination or review is insufficient. The Voltage design was a collaboration between Voltage, Phil Rogaway from UC Davis, and Seth Terashima from Portland State University, and is backed by a full proof that it is indistinguishable from a random permutation. Voltage Secure Stateless Tokenization The Voltage SST system uses two established techniques for building conventional block ciphers (Feistel networks and Liskov-Rivest-Wagner tweaking), repurposing them as methods of using a fixed random table to construct a provably secure random mapping based on a fixed-size table. The Voltage design was a collaboration between Voltage, Phil Rogaway from UC Davis, and Seth Terashima from Portland State University, and is backed by a full proof that it is indistinguishable from a random permutation. Attack 3: Subvert Access Control Rules Description An attacker might attempt to reverse token mappings by acting as the application or by finding a misconfiguration that allows unauthorized processes to call the detokenization function. Requirements This attack is independent of any specific tokenization method. The system must support strong authentication of the application and also logging and monitoring, to allow behavioral detection of this type of attack. Voltage SST The Voltage SST system allows strong shared secret or PKI-based authentication for application authentication, in addition to IP restrictions. The tokenization processes are separated (which also has a bearing on Attack 4 below) and all tokenization/detokenization operations generate system log events, which can be consumed by existing SEIM systems. 4

7 Attack 4: Subvert Tokenization Isolation Description An attacker might break into the system that is using tokens and attempt to sidestep the isolation used to protect the secret data. If the secret data used to perform tokenization is breached, this leads directly to the attacker either having live PAN-to-token mappings (in the database case) or the data that allows them to construct those mappings (in the encryption or table case). In the table and database case, we consider the case where the secret data is partially breached. Requirements The application and tokenization system MUST NOT share memory space. The point of a tokenization system is to prevent attackers that gain access to applications from getting access to sensitive data. If the tokenization system shares the core secret data in the same memory space as the application, there is no way to establish that a successfully exploited application didn t leak that secret, and hence the data needed to reverse token mappings. Voltage SST The Voltage SST system is designed so that the tokenization table is kept either in a physically separated box (in the case where the application is using the SOA API server) or in a hardware-isolated process, as in the case of Voltage SecureData z/protect where the application calls a separate process to perform tokenization operations. Conclusion Given the rapid pace of innovation in this area, it is critical that evaluators insist to see true mathematical security proofs and do not settle for qualitative statements made by vendors or third parties. 5

8 Additional contact information and office locations: a H 06/ Micro Focus or one of its affiliates. Micro Focus and the Micro Focus logo, among others, are trademarks or registered trademarks of Micro Focus or its subsidiaries or affiliated companies in the United Kingdom, United States and other countries. All other marks are the property of their respective owners.