Token (informática)

La tokenización, cuando se aplica a la seguridad de los datos, es el proceso de sustitución de un elemento de datos sensible por un equivalente no sensible denominado token, que no tiene un significado o valor extrínseco o explotable. El token es una referencia (un identificador) que regresa a los datos sensibles a través de un sistema de tokenización. El mapeo de datos originales a un token, utiliza métodos que hacen que los tokens no sean factibles de revertir en ausencia del sistema de tokenización, por ejemplo, utilizando tokens creados a partir de números aleatorios. El sistema de tokenización debe ser asegurado y validado utilizando las mejores prácticas de seguridad aplicables a la protección de datos confidenciales, el almacenamiento seguro, la auditoría, la autenticación y la autorización. El sistema de tokenización proporciona a las aplicaciones de procesamiento de datos la autoridad y las interfaces para solicitar tokens o destokenizar datos sensibles.

Este es un ejemplo simplificado de cómo funciona comúnmente la tokenización de pago móvil a través de una aplicación de teléfono móvil con una tarjeta de crédito.^[1]​^[2]​ En un terminal de pago se pueden utilizar métodos distintos del escaneo de huellas dactilares o números de identificación personal (PIN).

Los beneficios de seguridad y reducción de riesgos de la tokenización requieren que el sistema de tokenización esté lógicamente aislado y segmentado de los sistemas y aplicaciones de procesamiento de datos que anteriormente procesaban o almacenaban datos confidenciales reemplazados por tokens. Solo el sistema de tokenización puede tokenizar datos para crear tokens, o destokenizar de nuevo para canjear datos confidenciales bajo estrictos controles de seguridad. Se debe demostrar que el método de generación de tokens tiene la propiedad de que no hay medios viables a través de ataques directos, criptoanálisis, análisis de canales laterales, exposición de tablas de mapeo de tokens o técnicas de fuerza bruta para revertir los tokens a datos en vivo.

Cuando los tokens sustituyen a los datos activos en los sistemas, el resultado es una exposición mínima de los datos confidenciales a esas aplicaciones, almacenes, personas y procesos, lo que reduce el riesgo de exposición accidental y de acceso no autorizado a los datos confidenciales. Las aplicaciones pueden funcionar utilizando tokens en lugar de datos en tiempo real, con la excepción de un pequeño número de aplicaciones de confianza explícitamente autorizadas a destokenizar cuando sea estrictamente necesario para un fin comercial aprobado. Los sistemas de Tokenización pueden ser operados internamente dentro de un segmento aislado y seguro del centro de datos, o como un servicio de un proveedor de servicios seguro.

La Tokenización puede ser utilizada para salvaguardar datos sensibles que involucren, por ejemplo, cuentas bancarias, estados financieros, registros médicos, antecedentes penales, licencias de conducir, solicitudes de préstamos, transacciones bursátiles, registros de votantes y otros tipos de información personal identificable (PII, por sus siglas en inglés). La Tokenización se utiliza a menudo en el procesamiento de tarjetas de crédito. El Consejo de la Industria de Tarjeta de Pago (PCI, por sus siglas en inglés) define el tokenización como "un proceso por el cual el número de cuenta primario (PAN) es reemplazado por un valor sustituto llamado token. La destoquización es el proceso inverso de canjear un token por su valor PAN asociado. La seguridad de una ficha individual se basa predominantemente en la imposibilidad de determinar el PAN original conociendo solo el valor sustitutivo". La elección de una ficha como alternativa a otras técnicas tales como el cifrado dependerá de los diversos requisitos reglamentarios, la interpretación y la aceptación por parte de las respectivas entidades de auditoría o evaluación. Esto se suma a cualquier restricción técnica, arquitectónica u operativa que la simbología imponga en la práctica.

Conceptos y orígenes

El concepto de "tokenización", tal y como lo adopta hoy en día la industria, ha existido desde que surgieron los primeros sistemas monetarios hace siglos como medio para reducir el riesgo en el manejo de instrumentos financieros de alto valor, sustituyéndolos por equivalentes sustitutivos. En el mundo físico, las fichas de moneda tienen una larga historia de uso en sustitución del instrumento financiero de las monedas y billetes acuñados. En una historia más reciente, las fichas de metro y las fichas de casino fueron adoptadas por sus respectivos sistemas para reemplazar la moneda física y los riesgos de manejo de efectivo, como el robo. Exonumia y dinero de emergencia son términos sinónimos de tales fichas.

En el mundo digital, desde los años 70 se han utilizado técnicas de sustitución similares para aislar los elementos de datos reales de la exposición a otros sistemas de datos. En las bases de datos, por ejemplo, se han utilizado valores claves artificiales desde 1976 para aislar los datos asociados con los mecanismos internos de las bases de datos y sus equivalentes externos para una variedad de usos en el procesamiento de datos. Más recientemente, estos conceptos se han ampliado para considerar esta táctica de aislamiento con el fin de proporcionar un mecanismo de seguridad a los efectos de la protección de datos.

En la industria de las tarjetas de pago, la conversión a token es un medio de proteger los datos sensibles de los titulares de las tarjetas para cumplir con los estándares de la industria y las regulaciones gubernamentales.^[3]​

En 2001, TrustCommerce creó el concepto de Tokenización para proteger los datos de pago sensibles de un cliente, classmates.com.^[4]​ Contrataron a TrustCommerce porque el riesgo de almacenar los datos del titular de la tarjeta era demasiado grande si sus sistemas eran pirateados. TrustCommerce desarrolló TC Citadel®, donde los clientes podían referenciar un token en lugar de los datos del titular de la tarjeta y TrustCommerce procesaba un pago en nombre de los comerciantes.^[5]​ Esta aplicación de facturación segura permite a los clientes procesar pagos recurrentes de forma segura y sin necesidad de almacenar la información de pago del titular de la tarjeta. La tokenización reemplaza el número de tarjeta bancaria (siglas en inglés, PAN) con tokens seguros generados aleatoriamente. Si se interceptan, los datos no contienen información del titular de la tarjeta, lo que los hace inútiles para los hackers. El Número de Tarjeta Bancaria no puede ser recuperado incluso si el testigo y los sistemas en los que reside están comprometidos, ni tampoco puede el testigo ser sometido a ingeniería inversa para llegar al PAN.

Shift4 Corporation aplicó la tokenización a los datos de las tarjetas de pago y la dio a conocer al público durante una Cumbre de Seguridad de la industria celebrada en Las Vegas (Nevada) en 2005.^[6]​ ^[7]​ La tecnología está destinada a prevenir el robo de la información de la tarjeta de crédito almacenada. Shift4 define la tokenización como: "El concepto de usar un trozo de datos no desencriptados para representar, por referencia, datos sensibles o secretos. En el contexto de la industria de las tarjetas de pago (PCI), los tokens se utilizan para referirse a los datos del titular de la tarjeta que se gestionan en un sistema de tokenización, una aplicación o una instalación de seguridad externa".^[8]​

Para proteger los datos a lo largo de todo su ciclo de vida, la conversión mediante tokenización se combina a menudo con un cifrado de extremo a extremo para asegurar los datos en tránsito hacia el sistema o servicio de conversión de token, con un token que sustituye a los datos originales a su regreso. Por ejemplo, para evitar los riesgos de que el malware robe datos de sistemas de baja confianza, como los terminales de puntos de venta (TPV), como en el caso del incumplimiento del objetivo de 2013, la encriptación de los datos del titular de la tarjeta debe realizarse antes de que los datos de la tarjeta entren en el TPV y no después. La encriptación tiene lugar dentro de los límites de un dispositivo de lectura de tarjetas validado y reforzado en materia de seguridad y los datos permanecen encriptados hasta que son recibidos por el host de procesamiento, un enfoque en el que Heartland Payment Systems^[9]​ fue pionero como medio para asegurar los datos de pago frente a amenazas avanzadas, ahora ampliamente adoptado por las empresas de procesamiento de pagos y las empresas de tecnología de la industria.^[10]​ El Consejo PCI también ha especificado la encriptación de extremo a extremo (encriptación certificada de punto a punto-P2PE) para diversas implementaciones de servicios en varios documentos de encriptación de punto a punto del Consejo PCI.

La diferencia con el cifrado

La tokenización y el cifrado "clásico" protegen eficazmente los datos si se aplican correctamente, y una solución de seguridad ideal utilizará ambas. Si bien son similares en ciertos aspectos, la tokenización y la encriptación clásica difieren en algunos aspectos clave. Ambos son métodos de seguridad de los datos criptográficos y tienen esencialmente la misma función, pero lo hacen con procesos diferentes y tienen efectos distintos en los datos que protegen.

La tokenización es un enfoque no matemático que sustituye los datos sensibles por sustitutos no sensibles sin alterar el tipo o la longitud de los datos. Se trata de una distinción importante con respecto al cifrado porque los cambios en la longitud y el tipo de los datos pueden hacer que la información sea ilegible en sistemas intermedios como las bases de datos. Los datos convertidos en tokens son seguros, pero aun así pueden ser procesados por sistemas heredados, lo que hace que la conversión en tokens sea más flexible que el cifrado clásico.

Otra diferencia es que los tokens requieren muchos menos recursos computacionales para su procesamiento. Con la conversión en tokens, los datos específicos se mantienen total o parcialmente visibles para su procesamiento y análisis, mientras que la información sensible se mantiene oculta. Esto permite que los datos con tokens se procesen con mayor rapidez y reduce la carga de los recursos del sistema. Esto puede ser una ventaja clave en los sistemas que dependen de un alto rendimiento.

Con la creciente adopción de la tokenización, han surgido nuevos enfoques de tecnología de tokenización para eliminar esos riesgos y complejidades operacionales y permitir una mayor escala adecuada a los casos de uso de los macrodatos que están surgiendo y al procesamiento de transacciones de alto rendimiento, especialmente en los servicios financieros y la banca.^[11]​ Entre los ejemplos recientes figuran la tokenización sin bóvedas de Protegrity, la tokenización de Privitar Publisher y la tecnología de tokenización segura sin estado de Voltage Security ^[12]​ y la solución patentada de tokenización sin estado SecurDPS de Comfort. La tokenización sin bóveda y la tokenización sin estado han sido validados independientemente ^[13]​ para proporcionar una limitación significativa de los controles aplicables del Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (PCI DSS) para reducir el alcance de las evaluaciones. La conversión de tokens sin estado permite el mapeo aleatorio de elementos de datos en directo para sustituir valores sin necesidad de una base de datos, conservando al mismo tiempo las propiedades de aislamiento de la conversión de tokens.

En noviembre de 2014, American Express lanzó su servicio de tokens que cumple con el estándar de tokens de EMV.^[14]​

Operaciones, limitaciones y evolución del sistema

Los sistemas de tokenización de primera generación utilizan una base de datos para trazar un mapa de los datos en directo para sustituir los tokens sustitutivos y volver. Esto requiere el almacenamiento, la gestión y el respaldo continuo de cada nueva transacción añadida a la base de datos de tokens para evitar la pérdida de datos. Otro problema es asegurar la consistencia entre los centros de datos, lo que requiere una sincronización continua de las bases de datos de los símbolos. La consistencia significativa, la disponibilidad y los intercambios de rendimiento, según la conjetura de Brewer, son inevitables con este enfoque. Esta sobrecarga añade complejidad al procesamiento de transacciones en tiempo real para evitar la pérdida de datos y asegurar la integridad de los datos en todos los centros de datos, y también limita la escala. El almacenamiento de todos los datos sensibles en un servicio crea un blanco atractivo para el ataque y el compromiso, e introduce la privacidad y el riesgo legal en la agregación de datos de la privacidad en Internet, particularmente en la U. E..

Otra limitación de las tecnologías de conversión en tokens es la medición del nivel de seguridad de una solución determinada mediante una validación independiente. Ante la falta de normas, esta última es fundamental para establecer la solidez de la conversión en tokens ofrecida cuándo se utilizan tokens para el cumplimiento de la reglamentación. El Consejo de Normas de Seguridad de la Industria de las Tarjetas de Pago (PCI Council) recomienda la investigación y validación independientes de toda reclamación de seguridad y cumplimiento: "Los comerciantes que consideren la posibilidad de utilizar tokens deben realizar una evaluación exhaustiva y un análisis de riesgos para identificar y documentar las características únicas de su aplicación particular, incluidas todas las interacciones con los datos de las tarjetas de pago y los sistemas y procesos particulares de utilización de tokens".^[15]​

El método de generación de tokens también puede tener limitaciones desde el punto de vista de la seguridad. En lo que respecta a la seguridad y los ataques a los generadores de números aleatorios, que son una opción común para la generación de tokens y las tablas de asignación de tokens, debe aplicarse un escrutinio para garantizar que se utilicen métodos probados y validados frente a un diseño arbitrario.^[16]​ Los generadores de números aleatorios tienen limitaciones en cuanto a velocidad, entropía, sembrado y sesgo, y las propiedades de seguridad deben analizarse y medirse cuidadosamente para evitar la previsibilidad y el equilibrio.

Tipos de tokens

Hay muchas maneras de clasificar los tokens, pero actualmente no existe una clasificación unificada. Los tokens pueden ser: de uso único o múltiple, criptográfico o no criptográfico, reversibles o irreversibles, auténtico o no auténtico, y diversas combinaciones de las mismas.

Los tres tipos principales de tokens son:

• Token de seguridad (según las directrices de la Comisión de Bolsa y Valores de los Estados Unidos), o (SEC, por sus siglas en inglés) / Token de activos (FINMA)

• Token de utilidad (SEC) / Token de utilidad (FINMA) y

• criptomonedas (SEC) / Tokens de pago (FINMA).

En el contexto de los pagos, la diferencia entre los tokens de alto y bajo valor juega un papel importante.

Token de alto valor (TAVs)

Los TAVs sirven como sustitutos de los PAN reales en las transacciones de pago y se utilizan como instrumento para completar una transacción de pago. Para funcionar, deben parecerse a los PAN reales. Múltiples TAVs pueden ser asignados a un solo PAN y a una sola tarjeta de crédito física sin que el dueño lo sepa.

Además, los TAVs pueden limitarse a ciertas redes y/o comerciantes, mientras que los PAN no pueden.

Los TAVs también pueden estar vinculados a dispositivos específicos, de modo que las anomalías entre el uso de tokens, los dispositivos físicos y las ubicaciones geográficas puedan ser marcadas como potencialmente fraudulentas.

Token de bajo valor (TBV) o token de seguridad

Los TBVs también actúan como sustitutos de los PAN reales en las transacciones de pago, sin embargo sirven para un propósito diferente. Los TBVs no pueden ser utilizados por sí mismos para completar una transacción de pago. Para que un TBV funcione, debe ser posible compararlo con el PAN real que representa, aunque sólo de manera estrictamente controlada. El uso de tokens para proteger los PAN se vuelve ineficaz si se viola un sistema de tokens, por lo que asegurar el sistema de tokens en sí es extremadamente importante.

Aplicación a sistemas de pago alternativos

La creación de un sistema de pagos alternativo requiere que varias entidades trabajen juntas para prestar a los usuarios finales servicios de comunicación de campo cercano (NFC) u otros servicios de pago basados en la tecnología. Uno de los problemas es la interoperabilidad entre los actores y para resolver este problema se propone la función de gestor de servicios de confianza (TSM) para establecer un vínculo técnico entre los operadores de redes móviles (MNO) y los proveedores de servicios, de modo que estas entidades puedan trabajar conjuntamente. La tokenización puede desempeñar una función de mediación de esos servicios.

La utilización de tokens como estrategia de seguridad radica en la capacidad de sustituir un número de tarjeta real por uno de sustitución (eliminación de objetivos) y las consiguientes limitaciones que se imponen al número de tarjeta de sustitución (reducción de riesgos). Si el valor sustitutivo puede utilizarse de manera ilimitada o incluso de forma generalizada, como en el caso de Apple Pay, el valor simbólico gana tanto valor como el número real de la tarjeta de crédito. En estos casos, el token puede estar asegurado por una segundo token dinámico único para cada transacción y también asociado a una tarjeta de pago específica. Entre los ejemplos de tokens dinámicos y específicos de una transacción figuran los criptogramas utilizados en la especificación EMV.

Aplicación de las normas del PCI DSS

El Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago (PCI DSS), es un conjunto de directrices para toda la industria que debe cumplir cualquier organización que almacene, procese o transmita datos de titulares de tarjetas, ordena que los datos de las tarjetas de crédito deben estar protegidos cuando se almacenen. La tokenización, aplicada a los datos de las tarjetas de pago, se suele implementar para cumplir este mandato, sustituyendo en algunos sistemas los números de las tarjetas de crédito y de la Cámara de Compensación Automatizada por un valor aleatorio o una cadena de caracteres. Los tokens se pueden formatear de diversas maneras. Algunos proveedores de servicios de tokens o productos de tokenización generan los valores sustitutivos de manera que coincidan con el formato de los datos sensibles originales. En el caso de los datos de las tarjetas de pago, un token puede tener la misma longitud que un número de cuenta principal (número de tarjeta bancaria) y contener elementos de los datos originales como los cuatro últimos dígitos del número de la tarjeta. Cuando se hace una solicitud de autorización de una tarjeta de pago para verificar la legitimidad de una transacción, se podría devolver al comerciante un token en lugar del número de la tarjeta, junto con el código de autorización de la transacción. El token se almacena en el sistema receptor mientras que los datos reales del titular de la tarjeta se asignan un token en un sistema seguro de tokens. El almacenamiento de los tokens y los datos de las tarjetas de pago debe cumplir las normas vigentes de la PCI, incluido el uso de criptografía fuerte.

Estándares (ANSI, el Consejo PCI, Visa, y EMV)

La tokenización se encuentra actualmente en la definición de normas en ANSI X9. X9 se encarga de las normas de la industria en materia de criptografía financiera y protección de datos, incluida la gestión del número de identificación personal (PIN) de las tarjetas de pago, la codificación de las tarjetas de crédito y de débito y las tecnologías y procesos conexos.

El Consejo de la PCI también ha declarado su apoyo a la utilización de tokens para reducir el riesgo de violación de datos, cuando se combina con otras tecnologías como el cifrado punto a punto (P2PE) y las evaluaciones del cumplimiento de las directrices del PCI DSS.^[17]​

Visa Inc. publicó las prácticas óptimas de tokenización de Visa para su uso en aplicaciones y servicios de gestión de tarjetas de crédito y débito.^[18]​

En marzo de 2014, EMVCo LLC publicó su primera especificación de tokenización de pago para EMV.^[19]​

El NIST estandarizó los algoritmos de encriptación de preservación de formato FF1 y FF3 en su publicación especial 800-38G.^[20]​

Reducción del riesgo

Cuando se valida adecuadamente y con una evaluación independiente apropiada, la tokenización puede hacer más difícil que los atacantes accedan a datos confidenciales fuera del sistema o servicio de tokenización. La aplicación de la tokenización puede simplificar los requisitos del PCI DSS, ya que los sistemas que ya no almacenan o procesan datos sensibles pueden tener una reducción de los controles aplicables exigidos por las directrices del PCI DSS.

Como práctica óptima en materia de seguridad, es preciso que se efectúe una evaluación y validación independientes de toda tecnología utilizada para la protección de datos, incluida la utilización de tokens, a fin de establecer la seguridad y la solidez del método y la aplicación antes de que se pueda hacer cualquier reclamación de cumplimiento de la privacidad, el cumplimiento de las normas y la seguridad de los datos. Esta validación es particularmente importante en la conversión en tokens, ya que los tokens se comparten externamente en el uso general y, por lo tanto, están expuestos en entornos de alto riesgo y baja confianza. La inviabilidad de convertir un token o un conjunto de tokens en un dato sensible vivo debe establecerse utilizando mediciones y pruebas aceptadas por la industria por parte de expertos apropiados, independientes del proveedor de servicios o soluciones.^[21]​

Ejemplo

Supongamos la siguiente línea de un programa:

 SI Nuevo > MaxNúm ENTONCES 

Los tókenes son:

 * "SI" * "Nuevo" * ">" * "MaxNúm" * "ENTONCES" 

Y se describen por lo general en dos partes, un tipo o clase y un valor, así: Token=(Tipo,Valor)

Para la secuencia anterior, los tókenes pueden describirse

 * [Palabra Reservada, "SI"] * [Identificador, "Nuevo"] * [Operador, ">"] * [Identificador, "MáxNúm"] * [Palabra Reservada, "ENTONCES"] 

Véase también

• Token de seguridad.
• Token Ring.

Referencias

1. . IDEMIA. 19 de septiembre de 2017. Archivado desde el original el 26 de enero de 2018. Consultado el 30 de mayo de 2020. 
2. . Square (en inglés estadounidense). Archivado desde el original el 2 de enero de 2018. Consultado el 26 de enero de 2018. 
3. . Archivado desde el original el 3 de noviembre de 2012. Consultado el 28 de marzo de 2013.  Parámetro desconocido |url-status= ignorado (ayuda)
4. «Where Did Tokenization Come From?». TrustCommerce (en inglés estadounidense). Consultado el 23 de febrero de 2017. 
5. . 5 de abril de 2001. Archivado desde el original el 5 de abril de 2001. Consultado el 23 de febrero de 2017.  Parámetro desconocido |url-status= ignorado (ayuda)
6. . Archivado desde el original el 13 de marzo de 2014. Consultado el 2 de julio de 2017.  Parámetro desconocido |url-status= ignorado (ayuda)
7. «Shift4 Launches Security Tool That Lets Merchants Re-Use Credit Card Data». Internet Retailer. Archivado desde el original el 5 de septiembre de 2012. Consultado el 1 de abril de 2020. Plantilla:Dl
8. . Archivado desde el original el 16 de julio de 2011. Consultado el 1 de abril de 2020.  Parámetro desconocido |url-status= ignorado (ayuda)
9. Lessons Learned from a Data Breach
10. Voltage, Ingencio Partner on Data Encryption Platform
11. Banks push for tokenization standard to secure credit card payments
12. Secure Stateless Tokenization Technology
13. «Voltage Secure Stateless Tokenization Advances Data Security for Enterprises, Merchants and Payment Processors». reuters.com. December 2012. 
14. . AmericanExpress.com. 3 de noviembre de 2014. Archivado desde el original el 4 de noviembre de 2014. Consultado el 15 de mayo de 2020.  Parámetro desconocido |url-status= ignorado (ayuda)
15. PCI Council Tokenization Guidelines
16. How do you know if an RNG is working?
17. Protecting Consumer Information: Can Data Breaches Be Prevented?
18. Visa Tokenization Best Practices
19. «EMV Payment Tokenisation Specification – Technical Framework». March 2014. 
20. Dworkin, Morris. . Archivado desde el original el 22 de agosto de 2017. Consultado el 27 de mayo de 2020.  Parámetro desconocido |url-status= ignorado (ayuda)
21. . Archivado desde el original el 7 de abril de 2014. Consultado el 1 de abril de 2014.  Parámetro desconocido |url-status= ignorado (ayuda)

•   Datos: Q6148067