Cifrado que preserva el formato para garantizar la privacidad de datos financieros y personales

Gonzalo Álvarez Marañón    6 octubre, 2020
Cifrado que preserva el formato para garantizar la privacidad de datos financieros y personales

Tu información personal pulula por miles de bases de datos de organizaciones públicas y privadas. ¿Cómo proteger su confidencialidad para que no caiga en las manos equivocadas? A primera vista, la solución parece obvia: cífrala. Por desgracia, en criptografía las cosas nunca son sencillas, cifrar la información así sin más plantea numerosos inconvenientes. Veámoslo con un ejemplo.

Inconvenientes del cifrado de datos confidenciales

Imagina que un comercio online o tu entidad financiera quieren cifrar tu número de tarjeta de crédito que guardan en su base de datos. Podrían recurrir a la solución estándar de cifrado: usar AES, por ejemplo, en modo CTR con una clave de 128 bits y con un vector de inicialización aleatorio. Si tu número de tarjeta es 4444 5555 1111 0000, el resultado de cifrarlo con AES-128-CTR se muestra en la siguiente tabla, codificado de diferentes maneras habituales:

Texto claro4444 5555 1111 0000
Texto cifrado en Base64U2FsdGVkX1/Kgcb0V8G++1DWcwyu47pWXflP2CiVda51Ew==
Texto cifrado en hexadecimal53616c7465645f5f3601f1e979348111d342c038e9275492a1966fd8659f61a89869
Texto cifrado sin codificarSalted__ݺ▒Ii<½║'{☺Éqc»▬@Çþ¶ÔÈ×C♂♦

Como ves, el formato del texto cifrado nada tiene que ver con el formato del texto claro original:

  • Cambia la longitud: el texto cifrado es mucho más largo que el texto claro. Violaría los límites de longitud estándar para tarjetas de crédito impuestos por la base de datos.
  • Cambia el formato: nadie reconocería ese chorizo como un número de tarjeta de crédito. Si un ciberatacante roba la base de datos, no tiene que ser muy avispado para darse cuenta de que lo que está robando no es una tarjeta de crédito lista para usar.
  • Cambia el conjunto de caracteres: no pasaría ninguna validación para el contenido del registro porque contiene caracteres que no son números y no digamos ya en su forma sin codificar, que parece el WhatsApp de un adolescente. El texto cifrado causaría problemas en el esquema de datos.

Esta transformación del texto claro en una cadena monstruosa romperá muchos sistemas:

  • No podrás almacenarlo en bases de datos que no estén preparadas para aceptar ese nuevo formato.
  • No podrás transmitirlo por las pasarelas de pago al uso.
  • Tendrás que descifrarlo cada vez que lo usas.
  • No podrás buscar un número de tarjeta determinado en la base de datos para consultar sus operaciones.

¿Te parece poco? Pues no acaban ahí los problemas. Si durante una consulta a la base de datos el valor cifrado se descifra para leerlo y luego se vuelve a cifrar, AES en modo CTR utilizará un nuevo vector de inicialización aleatorio, por lo que el cifrado final no se parecerá en nada al valor cifrado anterior. Como prueba, en esta nueva tabla tienes el mismo valor de tarjeta cifrado con la misma clave, pero con otro vector de inicialización:

Texto claro4444 5555 1111 0000
Texto cifrado en Base64U2FsdGVkX18OyY1wEH1Co2mFw3nXazm9e6yCGqLLAyTbug==
Texto cifrado en hexadecimal53616c7465645f5f09c2cb2e14abda1d21bea9d22e3653e8310e6e8551a94bbf1467
Texto cifrado sin codificarSalted__Ñ╬T7¶Í«é¿r═§yG»¬³hºƒð7→{╩e

Nada que ver, ¿verdad? Como consecuencia, olvídate de utilizar los datos cifrados como una clave única para identificar una fila en una base de datos porque cambiarán de cifrado a cifrado.

En resumen: cifrar los datos que tienen formato muy estricto, como una tarjeta de crédito, plantea una serie de limitaciones prácticas aparentemente insalvables. Pero entonces, si el cambio de formato impide su cifrado, ¿cómo cumplir con las últimas regulaciones, como la GDPR, la PCI DSS o la PSD2? ¿Cómo conservar la confidencialidad de los datos sin perjudicar a la funcionalidad de las bases de datos?

¿Qué solución proporciona la criptografía?

La respuesta que han dado los criptógrafos a este dilema se conoce como cifrado de datos con preservación del formato (Format-Preserving Encryption, FPE). FPE extiende los algoritmos de cifrado clásicos, como AES, de manera que los textos cifrados conservan la longitud y el formato originales. Es más, en el caso particular de una tarjeta de crédito, incluso puede hacerse que el valor cifrado pase la comprobación de Luhn. Mira cómo quedaría cifrado el número de tarjeta de crédito anterior usando FPE:

Texto claro4444 5555 1111 0000
Texto cifrado con FPE1234 8765 0246 9753

Con FPE, una tarjeta de crédito se cifra en una cadena que sigue pareciendo una tarjeta de crédito y pasa todos los controles.

Format-Preserving Encryption (FPE)

Gracias a FPE, los datos ya no causan errores en las bases de datos, ni en los formatos de mensajes, ni en las aplicaciones legadas. ¿Y cuál es la gran ventaja de FPE? Puedes procesar y analizar los datos mientras están cifrados porque seguirán cumpliendo las reglas de validación.

Por supuesto, existen numerosos datos muy formateados más allá de los números de tarjeta de crédito que pueden protegerse con éxito mediante FPE:

  • Número IMEI
  • Número de cuenta bancaria
  • Número de teléfono
  • Número de la seguridad social
  • Código postal
  • DNI                                            
  • Dirección de correo electrónico
  • Etc.

Estos identificadores los usan rutinariamente todo tipo de industrias: comercio electrónico, financiera, salud, etc. La cuestión es: ¿hasta qué punto resultan seguros estos métodos de cifrado?

FPE en el mundo real

En 2013 el NIST adoptó en su recomendación SP 800-38G tres algoritmos para cifrar los datos preservando el formato, llamados, respectivamente, FF1, FF2 y FF3. Si tienes curiosidad por el nombre, deriva de usar un esquema de cifrado con mucha solera: el cifrado de Feistel; de ahí que los algoritmos basados en él se llamen Feistel-based Format-preserving encryption o FF. FF2 ni siquiera llegó a ver la luz, ya que fue roto durante el proceso de aprobación. En cuanto a FF3, en 2017 ya le encontraron debilidades, que han sido fortalecidas en su posterior versión FF3-1. De momento, FF1 y FF3-1 aguantan el tipo.

A pesar de todo, los algoritmos de FPE aún presentan limitaciones:

  • Los algoritmos de FPE son deterministas: textos claros idénticos darán como resultado textos cifrados idénticos cuando se cifran con la misma clave, a diferencia de lo que ocurre con el cifrado convencional, que suele estar aleatorizado. No obstante, para datos con formatos no tan exigentes, como una dirección de email, sí que puede añadirse fácilmente aleatoriedad, ya que una dirección de correo puede tener cualquier longitud, a diferencia de, por ejemplo, un número de teléfono que siempre tendrá 9 dígitos.
  • Los esquemas de FPE no proporcionan integridad de datos (no tienes garantía de si el dato cifrado ha sido alterado) ni autenticación del emisor (no tienes garantía de quién cifró el dato).

En definitiva, FPE continúa como un problema de investigación abierto, en el que veremos aún muchos avances tanto en criptoanálisis (romper algoritmos) como en la creación de otros nuevos más potentes.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *