Токенизация или просто токены относятся к многозначным терминам.  Однако чем же на самом деле является токен? Совет PCI SSC не дает никаких разъяснений на этот счет, только дает определение токена в Глоссарии:

Index Token: A cryptographic token that replaces the PAN, based on a given index for an unpredictable value. (В официальном переводе пока: «Индексный маркер — криптографический параметр, который заменяет номер PAN на основе заданного индекса для получения непредсказуемого значения.»)

Но и от этого определения мало толку.  Что еще хуже, термину token дается еще одно определение в этом же глоссарии, но уже у контексте описания устройств для двухфакторной аутентификации типа  SecurID. Сейчас я попробую раскрыть значение этого термина, предложить для обсуждения возможные варианты и рассказать об их сильных и слабых сторонах.

Основной смысл термина «токен» — значение, заменяющее какие-либо данные.  Это значит, что, например, вместо использования 4111 1111 1111 1111 для карты VISA, можно использовать какое-либо другое значение, которое будет являться представителем номера карты, и которое будет нужно для того, чтобы найти реальный номер карты.  Токены могут состоять, например, из букв и цифр, только из цифр,  только из букв, или вообще быть двоичным кодом.  Учитывая объем имеющихся данных и структуру приложений, использующих эти данные, большая часть токенов стремится к 16-разрядному цифровому значению.

Каким бы ни было представление токена, между ним и реальным значением не должно быть ни математической, ни какой-либо иной связи.  Именно поэтому в определении Совета PCI SSC присутствует слово index (указатель). Но вот незадача – в их определении еще есть слово  cryptographic (криптографический), которое может ввести аудиторов и других специалистов в заблуждение, что между токеном и реальным значением существует какая-то криптографическая связь.

Единственной взаимосвязью, которая должна существовать между токеном и реальным значением, является указатель. Структура такого указателя может быть, например, такой:

CREATE TABLE Tokens {
 original_value CHAR(16) PRIMARY KEY,
 token CHAR(16)
 };

В данном случае генерация токенов должна выноситься за пределы базы данных.  Если реальное значение будет первичным ключом, то мы исключим ситуации, при которых для одного реального значения будут генерироваться два токена.   Я давно занимаюсь проектированием БД, поэтому я бы не советовал реализовывать все это прямо в рабочей базе данных.  Этот пример приведен просто для иллюстрации.

Необходимо исключить возможность восстановления или вычисления реальных номеров PAN из значений токенов.  Если такая возможность существует, то придется менять механизмы защиты токенов и фактически это будет уже зашифрованный текст, а не токены.  Очевидно, что если между токенами и реальными значениями номеров карт будет существовать криптографическая связь, то возникает вероятность того, что можно провести анализ и восстановить криптооперации. Токенами часто называют хешированный шифротекст. Это довольно рискованно и, как минимум, некорректно, учитывая те определения, которые я привел.

Для стандарта PCI DSS я бы предложил следующее определение токена:

Токен — это  значение, заменяющее номер PAN (или иные критичные данные), которое не должно быть связано с PAN ни математически, ни каким-либо иным образом, позволяющим вычислять значение токена.

Таким образом, для того, чтобы значение можно было считать токеном, оно должно обладать двумя свойствами:

1. не иметь отношения к реальному значению (т.е. в его основе не должно быть никаких алгоритмов шифрования или шифротекстов);
2. он не должен использоваться в качестве замены PAN при авторизации (или иных процессах, выходящих за рамки системы токенов) транзакций, чтобы человек, имеющий доступ только к токенам, не представлял интереса для злоумышленников.

Не стоит рассматривать эту статью как рекламу или анти-рекламу чьей-либо продукции – эта статья ничто иное как просто разъяснение термина «токен».

Возникает вопрос: а можно ли по-прежнему пользоваться другими методами (которые тоже ошибочно называются  «токенами»)  для представления данных о держателе карты в нечитаемом виде согласно п. 3.4 (стандарта PCI DSS) при приведении в соответствие стандарту PCI DSS?

Конечно, можно, только по факту это уже не токены.