Tokenization in an Enterprise
The most effective token servers combine tokenization with encryption, hashing and masking to deliver an intelligent and flexible data security strategy. Under the tokenization model, data that needs to be encrypted is passed to the token server where it is encrypted and stored in the central data vault. The token server then issues a token, which is placed into applications or databases where required. When an application or database needs access to the encrypted value, it makes a call to the token server using the token to request the full value.
Referential integrity can introduce problems where various applications (e.g., data warehouses) and databases use the sensitive data values as primary or foreign keys to run queries and to perform data analysis. When the sensitive fields are encrypted, they often impede these operations since, by definition, encryption algorithms generate random encrypted values - this is to say that the same encrypted value (a credit card, for instance) does not always generate the same encrypted value. While there are methods to make it consistent, there are risks associated with removing the �randomization' from encryption. A consistent, format-sensitive token eliminates this issue.
With format preserving tokenization, the relationship between data and token is preserved - even when encryption keys are rotated. The central data vault contains a single encrypted version of each original plain text field. This is true even when encryption keys change over time, because there is only one instance of the encrypted value in the data silo. This means the returned tokens are always consistent whenever the same data value is encrypted throughout the enterprise. Since the token server maintains a strict one-to-one relationship between the token and data value, tokens can be used as primary and foreign keys and referential integrity can be assured whenever the encrypted field is present across multiple data sets. And since records are only created once for each given data value (and token) within the data vault, storage space requirements are minimized.
Maintaining referential integrity is also useful for complying with European privacy laws that regulate the electronic transfer of social insurance numbers across international borders. Using tokens in place of encrypted values meet the requirement of the law, yet allow for data analysis across borders.
Tokenization in Practice
There are two scenarios where implementing a token strategy can be beneficial: to reduce the number of places sensitive encrypted data resides; and to reduce the scope of a PCI DSS audit. The hub and spoke model is the same for both. The hub contains three components: a centralized encryption key manager to manage the lifecycle of keys; a token server to encrypt data and generate tokens; and a central data vault to hold the encrypted values, or cipher text. The spokes are the endpoints where sensitive data originates such as point-of-sale terminals in retail stores or the servers in a department, call center or website.
Fortunately, incorporating tokenization requires little more than adding a token server and a central data vault. For companies that need to comply with PCI DSS, tokenization has the added advantage of taking applications, databases and systems out of scope, reducing the complexity and cost of initial compliance and annual audits.