Uno de los controles clave del estándar PCI DSS v4.0 es el requerimiento 3.5. En él se enumeran una serie de técnicas para la protección del PAN (Primary Account Number) cuando este debe almacenarse, si existe alguna justificación de negocio.  Los métodos que pueden emplearse para dicha protección son el uso de valores hash de una sola vía, el truncamiento, la criptografía robusta o los índices de tokens. Este artículo se centrará en el último de ellos: la tokenización.

La tokenización es un concepto bastante sencillo pero efectivo. Consiste en el remplazo de un dato confidencial por otro que no lo es, pero que garantiza la misma operatividad.

Para explicar este concepto, se puede pensar en las fichas de un casino. Para jugar, se debe cambiar dinero real por fichas, las cuales son válidas únicamente en ese casino en particular. Si alguien las roba o intenta falsificarlas, su campo de acción estará limitado, ya que no las podrá utilizar en otros casinos, restringiendo al atacante y desmotivando su delito, ya que la ganancia será menos efectiva que si fuera dinero real.

Dada la efectividad en la aplicación en la vida real de este concepto, la tokenización también se ha aplicado al entorno digital, para remplazar información sensible, incluyendo información de identificación personal (Personally Identifiable Information – PII), datos protegidos por patentes o derechos de autor y datos financieros, como el número de cuenta primario (Primary Account Number – PAN). 

Figura 1. Esquema general del proceso de tokenización

De hecho, la tokenización va más allá, permitiendo la protección de la privacidad de los datos en investigaciones, análisis y correlación de fuentes de datos, entornos de data warehouse y/o big data, sin afectar las conclusiones generadas, siendo parte de las llamadas Privacy-Enhancing Technologies (o PET), dentro de las cuales se encuentran otras técnicas como datos sintéticos (synthetic data), privacidad diferencial (differential privacy), cifrado homomórfico (homomorphic encryption), Secure multiparty computation (SMC), entre otras, orientadas para pseudoanonimizar o de-identificar datos confidenciales. 

Dentro de su aplicabilidad en el entorno financiero, la tokenización se suele emplear como un control de seguridad para la protección del PAN. En ese caso en particular – y dependiendo de quién y cómo se genera el token y cómo será usado, los tokens se pueden organizar en tres categorías: tokens de adquiriencia, tokens de emisor y tokens de pago.

Token de adquiriencia (Acquiring token)

Un token de adquiriencia es un tipo de token generado por el adquiriente, el comerciante o un proveedor de servicios una vez el PAN ha sido capturado, ya sea a través de un canal presencial (TPV) o un canal no presencial (comercio electrónico). Este tipo de soluciones son propietarias; es decir: no suelen estar basadas en ningún estándar para su generación, formato, solicitud o aprovisionamiento.

Figura 2. Tipos de formatos de tokens para protección del PAN

En cuanto al formato del token, éste puede ser generado siguiendo diferentes patrones, dependiendo de las necesidades. A continuación se enumeran algunos de los más empleados:

  • Remplazo total del PAN usando una cadena de números y/o letras con longitud arbitraria o limitada: Bajo este escenario, el token puede tener un formato diferente al PAN relacionado. Suele ser el más complicado de gestionar, ya que es necesario modificar las aplicaciones y bases de datos asociadas para que soporten dicho cambio.
  • Remplazo total del PAN empleando un token con la misma longitud y formato del PAN asociado: Este modelo permite la generación de un token con la misma longitud y formato que el PAN al que representa, impactando mínimamente cualquier sistema asociado. Esto es posible a través de dos técnicas denominadas «Format Preserving Tokenization» (FPT) y «Format Preserving Encryption» (FPE). Debido a que el PAN y el token tienen el mismo formato, es necesario definir una serie de controles para poderlos diferenciar. Este proceso se denomina «distinguibilidad de tokens» («Token Distinguishability» en inglés). Una técnica que puede ser empleada es el uso del algoritmo de Luhn.
  • Remplazo parcial del PAN, manteniendo el BIN/IIN y las últimas 4 posiciones iguales: En aquellas entidades que requieren visualizar las primeras 6 u 8 y las 4 últimas posiciones del PAN (máximos permitidos por el control 3.4.1 de PCI DSS v4.0), se puede optar por tokenizar de forma parcial el PAN manteniendo dichas posiciones iguales y remplazando los datos intermedios con un token. En este modelo – al igual que en el modelo anterior – se requiere el uso de una técnica de diferenciación entre PAN y token para evitar contaminación de datos.

En abril de 2015, el PCI SSC publicó el documento «Tokenization Product Security Guidelines» en donde se estipulaban (sin ser obligatorias) una serie de mejores prácticas para la evaluación de productos de tokenización. En ese documento se categorizan los tokens de adquiriencia en dos grandes grupos: reversibles y no reversibles:

Figura 3. Categorías de tokens de adquiriencia

  • Tokens reversibles: Son aquellos que permiten obtener el PAN original desde su token a través de un proceso de destokenización. Esto se puede lograr mediante dos técnicas:
    • Tokens criptográficos: En este caso, los tokens son generados a partir del PAN empleando criptografía robusta y la entidad solamente almacena la clave criptográfica asociada con el proceso. Técnicamente, el token generado es un criptograma. Cuando se necesita destokenizar, simplemente el criptograma se envía al entorno seguro de la entidad, en donde se realiza un descifrado con la clave criptográfica asociada.
    • Tokens no criptográficos: En esta categoría, la entidad almacena una base de datos centralizada denominada Card Data Vault, en donde reposan el par PAN y token. Para obtener un PAN desde su token, simplemente se realiza una búsqueda en dicha base de datos. Es de anotar que en esta categoría, el PAN se almacena de forma cifrada, pero nunca se comparte con el exterior.

Figura 3. Tokenización con Card Data Vault (CDV)

  • Tokens irreversibles: Son aquellos que no permiten obtener el PAN desde su token relacionado. Existen dos clases de tokens irreversibles:
    • Tokens irreversibles autenticables: En este caso, el token es generado a partir del uso de una función criptográfica de una sola vía (hash). Este tipo de tokens es usado para verificar si un PAN ha sido usado en una transacción a partir de su hash, pero no hay forma de reversar o destokenizar el PAN.
    • Tokens irreversibles no autenticables:  En este último caso, el token no está vinculado con un PAN en particular sino con otros datos de la transacción, como el nombre del titular o una cuenta en el comercio, de tal forma que no hay una relación uno-a-uno con un PAN en particular.

Este tipo de tokenización puede ser implementado por la entidad internamente o puede ser delegado a un tercero especializado, con el fin de minimizar el alcance de cumplimiento de PCI DSS y ofrecer protección a los datos del PAN.

Token de emisor (Issuer token)

Un token de emisor (también conocido como Virtual Card Numbers – VNC o Virtual Credit Cards – VCC ) son un tipo de tarjeta creado por un emisor (una institución financiera que emite una tarjeta de pago a un cliente) y que está orientada a la minimización del riesgo en determinados casos de uso (sector de viajes, hotelero y restauración). Este tipo de tokens tiene el mismo formato que un PAN tradicional y su única diferencia está en las restricciones de transaccionalidad que tiene asociadas (solo pagos en comercio electrónico, restricción geográfica, limitación de fondos, etc.).

Token de pago (Payment token)

Finalmente, tenemos los tokens de pago (payment tokens, network tokens o EMVCo tokens). Para que un token pueda ser catalogado como token de pago, debe cumplir con los siguientes puntos:

  • Cumplir con las especificaciones descritas en el documento EMV® Payment Tokenisation Specification – Technical Framework, publicado por EMVCo. Esta especificación define las funciones clave y los campos de datos asociados con las solicitudes, la emisión, el aprovisionamiento, el procesamiento de transacciones y las interfaces de programación de aplicaciones (API) de los tokens de pago.
  • Estar en el listado en el programa de registro de proveedores de tokens de EMV (Token Service Provider Registration Programme).
  • El entorno en el cual se gestionan las siguientes tareas debe estar alineado y evaluado de acuerdo con los requerimientos descritos en el estándar Payment Card Industry (PCI) Token Service Providers (TSP), de acuerdo con la FAQ #1383 «To whom do the PCI Token Service Provider Security Requirements apply?«:
    • Procesos de generación, emisión y asignación de tokens.
    • Asignación de parámetros de uso de tokens.
    • Gestión del ciclo de vida de los tokens.
    • Procesos para asignar o reasignar tokens, o realizar la des-tokenización.
    • Procesos criptográficos para respaldar las funciones de tokenización.
    • Mantenimiento de la seguridad subyacente de los tokens y controles de procesamiento relacionados, como las restricciones de dominio durante el procesamiento de transacciones.

Este tipo de tokens tienen las siguientes particularidades:

  • Cuentan con un BIN/IIN dedicado, por lo cual su numeración no se solapa con la de las tarjetas normales.
  • La numeración de estos tokens cumple con el algoritmo de Luhn.
  • En cuanto a longitud, estos tokens cuentan con la misma cantidad de números que una tarjeta normal.
  • Estos tokens son usados principalmente en tarjetas EMV-compliant o en teléfonos móviles en digital wallets, pero pueden ser usados también en servicios de card-on-file.
  • Generalmente, esto servicios de tokenización suelen ser ofrecidos por las propias marcas: Visa Token Service, MasterCard Network Tokenization, American Express Token Service, etc., así como por proveedores tecnológicos como Apple (Apple Pay), Google (Google Pay) y Samsung (Samsung Pay).

Diferencias entre los tipos de tokens

Como resúmen, a continuación se presenta una tabla con las diferencias entre los tres tipos de tokens:

Figura 4. Diferencias entre los tipos de tokens

Impacto de la tokenización en el alcance de PCI DSS

El principal valor agregado del uso de la tokenización en un entorno PCI DSS radica en que un token no es considerado como un elemento sensible y, como tal, no debe ser protegido con los controles de PCI DSS. Esto quiere decir, sencillamente, que un token se considera fuera del alcance.

No obstante, y como se explica en el artículo «Datos dentro y fuera del alcance de PCI DSS«, los tokens de PANs estarán en el alcance si estos son almacenados en el mismo sistema que ejecuta la tokenización, así como cualquier sistema que ejecute rutinas de tokenización de datos, que desempeñen tareas de gestión de claves (si aplican) y cualquier sistema o red conectada a estos activos.

Solo se considerarán los tokens fuera de alcance cuando dichos datos son transferidos y almacenados en un entorno separado (segmentado adecuadamente del CDE), no se tiene acceso al PAN original en claro o a las claves criptográficas asociadas y no se procesan, almacenan y/o transmiten datos de titulares de tarjetas (CHD) o datos sensibles de autenticación (SAD) de ninguna otra manera.

Referencias

PCI SSC FAQ #1326 : «How does PCI DSS apply to EMVCo Payment Tokens?»

PCI SSC FAQ #1383 «To whom do the PCI Token Service Provider Security Requirements apply?»

PCI SSC FAQ #1384: «What is the difference between ‘acquiring tokens’, ‘issuer tokens’, and ‘Payment Tokens’?»

PCI SSC FAQ #: «Which types of tokens are addressed by the PCI SSC tokenization documents?»

PCI SSC Tokenization Product Security Guidelines (2015)

PCI SSC PCI DSS Information Supplement: PCI DSS Tokenization Guidelines (2011)

PCI SSC Token Service Provider (PCI TSP) estándar – Additional Security Requirements and Assessment Procedures for Token Service Providers (EMV Payment Tokens)

Posted by David Acosta

Qualified Security Assessor (QSA) para PCI DSS, PCI PIN, PCI 3DS, P2PE y PCI TSP. CISSP, CISA, CISM, CRISC, C|EH, C|HFI.

Deja un comentario