Capture

Según el requerimiento 3.4 del estándar PCI DSS, una de las posibles opciones a implementar para la protección del PAN (Primary Account Number) de las tarjetas de pago almacenadas en un entorno PCI DSS es la tokenización.

Dicha técnica se basa en sustituir la información sensible (en este caso el PAN (Primary Account Number) de una tarjeta de pago) por información no confidencial, creando una relación entre estos dos tipos de dato, de manera que todas las operaciones funcionales donde no se requiera el uso del dato sensible, se realicen sobre dicho token. En el momento en que se requieran consultar los datos originales y confidenciales, se lanzará una petición al sistema, que devolverá el PAN asociado a un token concreto.

Con dicha técnica, se puede lograr – además de proteger la información confidencial de una plataforma – reducir el alcance de un entorno de cumplimiento PCI DSS, tal y como contamos en anteriores entradas en este portal.

Para que dicha técnica sea efectiva y válida para estos propósitos, su implementación debe realizarse de manera correcta, y para ello, el PCI SSC ha publicado una guía de seguridad para productos de tokenización  (Information Supplement -Tokenization Product Security Guidelines) en donde  se detallan todas las medidas a implementar para que dichas soluciones ofrezcan las garantías de protección adecuadas.

En este artículo procedemos a analizar de manera general los diferentes apartados que conforman esta guía, haciendo énfasis en aquellos puntos considerados como más relevantes, y dando una visión global sobre su contenido.

Clasificación de token

Existen diferentes tipos de token de remplazo de información sensible, que pueden clasificarse según se muestra en el siguiente diagrama:

token

Dentro de la categoría de token reversibles (se puede obtener el dato sensible original a partir del token), tenemos los siguientes tipos:

  • Criptográficos: Son generados a partir del PAN, utilizando algoritmos de cifrado robustos.
  • No-criptográficos: El token se obtiene de una tabla que relaciona el PAN original con un valor aleatorio específico. En dichos casos, es evidente que la información contenida en las tablas de relación token-PAN será vital para asegurar la confidencialidad de los datos de la plataforma.

Dentro de la categoría de tokens irreversibles (no se puede obtener el dato sensible original a partir del token), tenemos los siguientes tipos:

  • Autentificable: El token es creado a partir de la aplicación de una función matemática (hash) sobre el PAN. A pesar de que no es posible revertir el proceso, obteniendo el PAN original se puede validar cual es el token asociado a dicho dato, aplicando de nuevo la misma función matemática sobre el dato.
  • No-autentificable: En este caso, aunque el token se genera de la misma forma que en el caso anterior (aplicando una función matemática sobre el PAN), es imposible validar el token asociado a un PAN original, ya que cada token generado es diferente, a pesar de que el dato inicial sea el mismo.

Roles en servicios de tokenización

Los roles en el proceso de tokenización definidos por la guía son los siguientes:

  • Proveedor de la solución de tokenización: Entidad que provee a un comercio una solución de tokenización empaquetada, para que el usuario final la implemente en su propio entorno.
  • Proveedor de servicio de tokenización: Entidad que provee un servicio de tokenización a un comercio o usuario final, de manera que dicho proveedor se hace responsable no solo del desarrollo de la plataforma de tokenización, sino también de su mantenimiento y administración.

Guias, mejores prácticas y dominios de seguridad para la plataforma de tokenización

La guía nos proporciona una serie de prácticas de seguridad, segmentadas entre una sección de medidas generales y cuatro secciones de dominios de seguridad, que aplican en una plataforma de tokenización, según la clasificación de tokens que hemos comentado anteriormente.

La aplicabilidad de estas guías y recomendaciones de seguridad según el tipo de token generado se puede observar en la siguiente tabla:

tokenization_domain

Guias / Mejores prácticas generales

Como se puede observar en la tabla de anterior, estas guías aplican a todas las plataformas de tokenización, sea cual sea el tipo de token generado en ellas.

Estas guías se comprenden de trece requerimientos de seguridad, donde se tratan aspectos como son por ejemplo:

  • Niveles seguridad de los módulos de hardware y software necesarios en la plataforma según las normativas FIPS.
  • Independencia entre los procedimientos de generación de los diferentes tipos de token.
  • Imposibilidad computacional de deducir el PAN original obteniendo solo el token asociado al mismo.
  • Necesidad de la existencia de servicios de monitorización en la plataforma.
  • Implementación de mecanismos que aseguren la integridad del proceso de generación de token.
  • Restricción de acceso a la plataforma solo a usuarios con una necesidad operativa justificada para tal efecto, y siempre a través de mecanismos de identificación y autenticación fiables.
  • Existencia de registros de auditoría a nivel funcional en la plataforma, donde se registren las acciones llevadas a cabo en la misma (sin que en ellos se incluyan datos de PAN).
  • Cifrado robusto de accesos administrativos.
  • Implementación de metodologías de desarrollo seguro para los módulos de software de la plataforma.

Dominio 1: Generación del token

Este dominio incluye diferentes requerimientos de seguridad en la generación de token, según el tipo de token generado por la plataforma, como se puede observar a continuación:

  • Si se generan Token Irreversibles:
    • Se debe asegurar que el procedimiento de generación de los token dispone de unas funciones matemáticas (algoritmos hash) o los procesos aleatorios adecuados para tal efecto.
    • Los token generados no deben incluir en ningún caso la totalidad o parte de los dígitos del PAN original.
    • Las tablas “diccionario” de interrelación entre token aleatorios y datos PAN deben ser lo suficientemente complejas para que la probabilidad de deducir un PAN a partir del token sea menor que una opción entre un millón.
  • Si se generan Token Reversibles Criptográficos:
    • Se debe asegurar que las claves de cifrado utilizadas no puedan ser extraídas en claro de la plataforma.
    • Las claves de cifrado utilizadas en la generación de token no deben ser utilizadas para cualquier otra función dentro o fuera de la plataforma.
    • Los cambios de claves de tokenización deben suponer un cambio en el mapeo de token con los PAN originales relacionados.
    • No se deben almacenar en la plataforma la totalidad o parte de datos PAN en claro.
  • Si se generan Token Reversibles No-Criptográficos:
    • La generación del token debe ser independiente al PAN asociado a dicho token, de manera que sea imposible deducir el PAN desde dicho dato sin el acceso a la tabla de mapeo de ambos datos.
    • La probabilidad de deducir un PAN a partir de un token sin información adicional debe ser menor que una posibilidad entre un millón.

Dominio 2: Mapeo del token

Este dominio incluye diferentes requerimientos de seguridad en el mapeo de los token con los datos PAN originales, según el tipo de token generado por la plataforma, como se puede observar a continuación:

  • Si se generan Token Reversibles Criptográficos:
    • Las aplicaciones que realicen peticiones de tokenización o de de-tokenización a la plataforma deben ser previamente autenticadas en la misma.
    • Se deben establecer Controles de Acceso Basados en Roles en la plataforma (RBAC) en la plataforma, de manera que solo los usuarios con necesidades operativas justificadas para tal efecto puedan acceder a la misma.
  • Si se generan Token Reversibles No-Criptográficos:
    • El mapeo entre un token y el PAN original debe realizarse única y exclusivamente en el Repositorio de Datos de Tarjeta (Card Data Vault (CDV)) de la plataforma.
    • Se deben establecer Controles de Acceso Basados en Roles en la plataforma (RBAC), de manera que solo los usuarios con necesidades operativas justificadas para tal efecto puedan acceder a la misma.

Dominio 3: Repositorio de datos de tarjetas (Card Data Vault – CDV)

Este dominio aplica solo en el caso de que en la plataforma se generen Token Reversibles Criptográficos, y se ocupa de los siguientes requerimientos de seguridad en el CDV:

  • Las tablas y todas las localizaciones de la CDV donde se almacenen PAN (cintas de backup, etc) deben ser cifradas con claves de como mínimo 128 bits, con alguno de los algoritmos recomendados por la guía (ver sección “Algoritmos recomendados para claves criptográficas y hash” de este mismo artículo).
  • Se deben establecer Controles de Acceso Basados en Roles (RBAC) en el CDV, de manera que solo los usuarios con necesidades operativas justificadas para tal efecto puedan acceder a dicho elemento.

Dominio 4: Gestión de claves criptográficas

Este dominio incluye diferentes requerimientos de seguridad para la gestión de las claves criptográficas de la plataforma, según el tipo de token generado por la misma, como se puede observar a continuación:

  • Si se generan Token Irreversibles:
    • Se deben establecer unos adecuados procedimientos de seguridad en el ciclo de vida de las claves criptográficas utilizadas en la plataforma.
    • Se deben establecer criptoperíodos para las claves de cifrado, bien a nivel temporal o en base a un número máximo de usos.
    • Se deben incluir procedimientos de destrucción segura de las claves de cifrado una vez han finalizado su criptoperíodo, de manera que dichas claves no puedan ser nunca recuperadas una vez hayan sido destruidas.
  • Si se generan Token Reversibles Criptográficos:
    • Las claves criptográficas utilizadas en la plataforma deben ser generadas a través de un Dispositivo Criptográfico Seguro (Secure Cryptographic Device (SCD)). Además, la generación del token debe realizarse directamente en este mismo dispositivo.
    • La gestión del ciclo de vida de las claves de cifrado (claves de generación de los token) debe ser correcta (generación de las claves, definición de criptoperíodo, destrucción, etc).
  • Si se generan Token Reversibles No-Criptográficos:
    • Todas las operaciones relacionadas con la gestión de las claves de cifrado de tokens deben ser realizadas en un dispositivo SCD (como por ejemplo HSMs, etc).

Guias / Mejores prácticas para productos de tokenización que utilicen un SCD

Si una solución de tokenización utiliza Secure Cryptographic Devices (SCD), debe cumplir con los siguientes requerimientos de seguridad:

  • Se deben generar y mantener inventarios para todos los dispositivos SCD de la plataforma.
  • Los SCD deben ser protegidos físicamente y a nivel de roles (RBAC), con las medidas de seguridad que se requieran en la guía de instalación (obligatoria) del producto.
  • Se deben implementar mecanismos para la detección de manipulación o remplazo de los dispositivos SCD de la plataforma.
  • Se deben configurar los SCD para que se habilite el modo fail closed en caso de fallos o incidentes, de manera que estos no pueden ser utilizados en dichos casos para evitar (bypass) sus medidas de seguridad. También se debe asegurar que el tratamiento de los PAN contenidos en dichos dispositivo es el adecuado en estos escenarios.
  • Se deben implementar procedimientos para mantener los dispositivos SCD actualizados según los últimos parches de seguridad existentes en el entorno.

Algoritmos recomendados para claves criptográficas y hash

En dicho apartado, se proporcionan los algoritmos y complejidades recomendadas para la gestión de claves criptográficas y hash en las soluciones de tokenización.

En la siguiente tabla, se pueden consultar los algoritmos de cifrado permitidos en estas plataformas, con la longitud de las claves mínima recomendada para cada uno de ellos.

algorithms

Para las claves de cifrado de otras claves (Key Encryption Key (KEK)), se deben utilizar algoritmos como mínimo igual de robustos que las claves cifradas en cada caso, estando disponible la siguiente tabla como referencia, para la relación entre la robustez de los diferentes algoritmos de cifrado de datos permitidos.

security

En la siguiente tabla, se muestran los modos de operación permitidos para cada uno de los algoritmos criptográficos utilizados.

modes

Por último – y en relación con los algoritmos hash – en la siguiente tabla podemos consultar los algoritmos y longitudes mínimas permitidas en este tipo de plataformas:

length

Casos de uso

En dicho apartado, se proporcionan algunos casos de uso en la implementación de una solución o producto de tokenización, para cada uno de los tipos de token existentes en este tipo de plataformas.

  • Token Irreversibles Autentificables: Estas soluciones son utilizadas en el caso de que se necesite garantía sobre una transacción, para comprobar que un PAN determinado haya sido el que se utilizó en dicha operación. Para realizar esta comprobación, se generaría un token con el nuevo PAN, y se comprobaría que el valor de dicho token es igual al valor del token generado en el momento de la transacción. En este tipo de escenarios, el PAN original no podrá ser obtenido a partir de los datos token almacenados.
  • Token Irreversibles No-Autentificables: Dichas soluciones se pueden utilizar en el caso de que se desee utilizar una aplicación obsoleta, que requiera la generación de un valor aleatorio para cada uno de los PAN contenidos en sus bases de datos, de manera que los PAN originales se eliminen de la plataforma y no puedan ser recuperados a partir de los token generados.
  • Token Reversibles (Criptográficos y No-Criptográficos): Dichas soluciones pueden ser utilizadas para reducir el número de puntos donde el PAN original es tratado, pero pudiendo obtener el PAN original cuando sea necesario. De esta manera, la mayoría de operaciones funcionales a realizar sobre las transacciones monetarias se harán en los datos token, no sobre los datos PAN originales. En el momento en el que se desee realizar una operación sobre el dato original, la plataforma permitirá lanzar una consulta sobre un token específico, de manera que obtengamos el PAN relacionado con el mismo.

Como siempre, les invitamos a participar en el foro o dejar un comentario en este artículo si se tiene alguna duda, comentario o sugerencia.