How Does Tokenization Protect Sensitive Data?

TL;DR

Tokenization protects sensitive data by replacing an underlying sensitive value with a surrogate token for use in defined situations. Tokens can be generated through encryption, message authentication codes, random values, or static tables, and each method differs in reversibility, storage requirements, format preservation, and compatibility with existing applications.

Transcript

Good morning, everyone. We're here to speak about cybersecurity and tokenization this morning. And so to begin, just give you a quick agenda of our morning. We'll be talking about some fundamentals just to make sure we're on the same level set when we begin, and then talk about four controversial implementation issues, uh, as you can read them righ... Read More

Key Insights

• Tokenization is the process of mapping an underlying sensitive value to a surrogate token that can be used instead of the original value in specific, well-defined situations. The underlying value may be a payment card number, Social Security number, personal name, or other sensitive information.
• Tokenization definitions vary by organization and implementation context. PCI focuses narrowly on replacing a primary account number, while the ANSI X9 definition applies more broadly to plain-text underlying sensitive values. EMV implementations add further variation because participating payment organizations maintain their own implementation definitions.
• Format-preserving tokenization is useful for backward compatibility with legacy applications. A payment card token can remain numeric, retain the original length, preserve routing digits and the last four digits, and use a recalculated check digit so existing applications continue to accept and process it.
• Payment card tokenization has no single universal rule for determining which digits should be replaced. An implementer may tokenize the middle digits or the entire number, depending on the industry, customers, processing requirements, desired token format, required length, and application syntax constraints.
• Encryption-based tokenization creates a token by encrypting the underlying sensitive value with a cryptographic key. The token functions as ciphertext, and detokenization decrypts it with that key. Because the original value is recoverable from the token, a separate mapping database is not required.
• MAC-based tokenization applies a cryptographic key to an underlying sensitive value but does not place enough information in the resulting token to recover the original value directly. Detokenization therefore requires a database mapping each token to its underlying value, although some implementations support verification without detokenization.
• Random tokenization replaces an underlying sensitive value with a randomly generated value that has no derived correlation with the original. A database must preserve the relationship between each sensitive value and token whenever the system needs to provide a detokenization service.
• Static table tokenization uses a random source and a pseudo-random sequence to generate a reusable transformation table. The table supports tokenization and reversal without necessarily requiring a mapping database, but it must remain unchanged because replacing it could produce different results and break the system.

Questions & Answers

Q: What is tokenization in data security?

Tokenization is the process of replacing an underlying sensitive value with a surrogate value called a token. The protected value may be a primary account number, Social Security number, personal name, or another sensitive item. The token is used in certain well-defined situations, but it does not necessarily replace the original value in every operation the original supports.

Q: Why do tokenization definitions differ among PCI, ANSI X9, and EMV?

The definitions differ because each organization approaches tokenization from its own implementation context. PCI concentrates on payment cards and defines tokenization around replacing the primary account number. ANSI X9 uses a broader definition covering the mapping of any plain-text underlying sensitive value. EMV is more complicated because its participating payment organizations have their own implementation definitions.

Q: How can tokenization preserve compatibility with legacy payment applications?

Tokenization can preserve the numeric format, length, routing information, last four digits, and check-digit behavior expected by existing applications. One example replaces only the middle six digits of a 16-digit payment card number. The implementer can then calculate a valid check digit, allowing legacy systems to process a card-like token without receiving the original account number.

Q: When should an entire payment card number be tokenized?

An implementer may choose to tokenize the entire card number instead of replacing only its middle digits. In that design, applications generally need separate communication or processing channels for tokens and real card numbers. Mixing the two can create serious problems. The choice depends on the industry, customers, format, length, syntax, and processing requirements rather than one universal rule.

Q: How does encryption-based tokenization support detokenization?

Encryption-based tokenization applies a cryptographic key to the underlying sensitive value and uses the resulting ciphertext as the token. Detokenization applies decryption with the cryptographic key to recover the original value. Since recovery is possible directly from the token, the system does not have to store a separate database containing a mapping between every token and sensitive value.

Q: Why does MAC-based tokenization require a mapping database?

A message authentication code uses a cryptographic key to transform the underlying sensitive value into a token, but the token does not contain enough information to reconstruct that value. If detokenization is required, the system must maintain a database mapping each token to its original value. Some MAC-based systems instead provide verification and do not support detokenization at all.

Q: How does random tokenization differ from encryption?

Random tokenization substitutes a randomly generated value for the underlying sensitive value, and the two values have no derived correlation. Consequently, the original cannot be recovered by reversing a cryptographic operation on the token. A mapping database is required when detokenization must be available. Encryption instead creates recoverable ciphertext and can reverse the token with a cryptographic key.

Q: What is the static table method of tokenization?

The static table method uses a random number source and a pseudo-random sequence to generate transformation tables. The system passes an underlying sensitive value through the table to create a token and can apply the table in reverse to reconstruct the original. The table is generated once and retained because changing it could generate different answers and break dependent systems.

Summary & Key Takeaways

• Tokenization maps sensitive information, such as a primary account number, Social Security number, or personal name, to a surrogate value. Definitions differ among PCI, ANSI X9, and EMV implementations. The ANSI definition emphasizes that a token replaces the original value only in certain well-defined situations, not in every possible use.

• Payment card tokens may preserve selected structural features for compatibility with legacy applications. An implementation can retain the bank identifier number, last four digits, numeric format, length, and a valid check digit while replacing the sensitive middle digits. Alternatively, the entire card number can be tokenized and processed through a separate channel.

• Four tokenization methods are described: encryption, message authentication codes, random values, and static tables. Encryption and static tables can support direct reversal without maintaining a token mapping database. MAC and random methods require stored mappings when detokenization is needed, although some MAC-based systems perform verification without offering detokenization.