GDPR vs Blockchain: tecnología vs la ley

Uno de los mayores impactos que el GDPR tendrá para los consumidores (al menos en el caso de los ciudadanos de los países que cumplen con el GDPR) es el derecho al olvido. Una persona puede solicitar que sus datos sean eliminados de cualquier registro. Pero ¿qué ocurre si este registro es parte de un blockchain? Esto plantea un desafío para las implementaciones blockchain. La tecnología blockchain está diseñada para durar para siempre. Cada bloque tiene un hash basado en su contenido y traslada el hash de su predecesor. Por lo tanto, cuando observas un bloque en blockchain puedes rastrear el bloque a través de sus predecesores llegando hasta el bloque fundador. Cambiar el contenido de un bloque varía el hash del mismo. Si el hash de un bloque cambia, los sucesores no lo referenciarán. A lo que apuntan es al bloque original y válido. Reconstruir la cadena con el bloque reemplazado significa que el hash para cada bloque tendrá que ser recalculado, lo cual supone una gran tarea de cálculo computacional. 

En la imagen de la Figura 1, observamos parte de un blockchain mostrando tres bloques. El bloque 36 contiene el hash para el bloque 35, algunos datos (DATA yyyyy) y su nuevo hash propio (HASH 36). Hay que tener en cuenta que algunos de los datos pueden incluir la identidad del creador de esos datos, el minero que calculó el hash. Si los datos cambian, el valor de HASH 36 también cambiará.

Los bloques posteriores no lo señalarán.

Para un blockchain distribuido, el problema de la modificación de la cadena se vuelve enormemente más complejo. No solo se deberá volver a calcular el hash del bloque modificado y de los sucesivos, sino que cada copia del blockchain tendrá que ser reemplazada en cada máquina en la que resida. Cualquiera que haya enviado en alguna ocasión un email erróneo a un grupo sabe lo complicado que es recuperar todas esas copias. Desde que los blockchains son eficazmente imborrables, cualquier registro que contenga información personal sobre un individuo no puede ser alterado.

Además, cualquier individuo que crea un bloque en un blockchain está afiliado a ese bloque por la duración del mismo. En sistemas como el bitcoin, los mineros usan un pseudónimo (normalmente generado mediante una criptografía de clave pública) para validar su autoría sin desvelar su identidad. Si la identidad de esa persona es revelada, esa relación queda expuesta a todas las transacciones en las que ha participado. En pocas palabras, tanto el contenido del bloque como la autoría de este son permanentes.

Bajo el GDPR, una organización que construye un blockchain puede tener que eliminar un bloque o modificar algunos datos para cumplir con la solicitud de derecho al olvido de alguien. ¿Cómo funcionaría eso? Para ilustrar este problema, considere esta parte de historia. La popular base de datos de mainframe DB2 respaldaba la seguridad en torno al uso de ‘vistas’, mapas de datos utilizados por las aplicaciones. Cada vista requiere un propietario, un usuario en el sistema. A menudo, este sería la identificación ID de un usuario de un individuo particular, con un permiso otorgado especial para permitirles crear o modificar una vista. Con el tiempo, el individuo puede cambiar a un trabajo diferente o abandonar la compañía. Si el ID de esa persona se eliminó del sistema, la vista ya no funcionaría. Las empresas tenían que preservar estos ‘‘ID huérfanos’’ siempre que la aplicación que utilizaba la vista permaneciera en producción. Esto planteó un problema para los auditores a la luz de Sarbanes Oxley: cada ID debe tener un usuario conocido y autenticado.

Cuando las organizaciones desplegaban sus herramientas de gestión de identidad (IdM), estos ID huérfanos se marcarían como "no válidos". La respuesta es usar identidades sintéticas. Es decir, en lugar de utilizar la identidad de un individuo, crea una identidad indirecta y mantiene la asociación entre ese pseudónimo ID y el sujeto de datos real por separado y de forma segura. La minería sería manejada por "Corp-ID Miner 031". Si ese individuo deseaba ser olvidado, la organización asignaría ese pseudo ID a otro técnico profesional para la minería.

Un registro médico se referiría a "Corp-ID Client 192734". Si esa persona deseaba ejercer su derecho al olvido, la organización volvería a reasignar ese pseudo-ID a una ID nula, erradicando así el enlace de la persona a los datos. Este ejemplo puede ayudar a aclarar esta propuesta. Durante la década de los 1980, trabajé como custodio de algunos documentos de planificación con el centro de desarrollo de software de IBM en Poughkeepsie, Nueva York. En ese trabajo, las personas, por lo general, permanecían uno o dos años. Muchos otros departamentos y laboratorios de IBM necesitaban información sobre los elementos del plan, pero actualizar constantemente cada potencial corresponsal con la dirección de correo electrónico del nuevo ocupante del puesto era tedioso y poco confiable. Por el contrario, teníamos una identificación de correo electrónico como "MVS Lab Plan" que era propiedad de quien tenía ese rol y su copia de seguridad. Cualquier consulta sobre el plan se dirigiría a ese ID, y quien respondiera proporcionaría la información solicitada (después de autenticar al solicitante). Tal y como sucede hoy, cuando se quiere hablar con la policía, no se busca el número del responsable, sino que marca directamente el 911 -en el caso de emergencias en Norteamérica- o el 112 -en España-, y el teléfono se gestiona desde un call center.   

GDPR no prohíbe blockchain, pero sí establece algunos requisitos de procedimiento alrededor del uso de blockchain en las empresas comerciales. Para las personas que optan por un blockchain, no hay autoridad para modificar o corregir un bloque una vez que se haya incorporado a la cadena. Para ellos, “caveat emptor”, es decir, “el comprador asume el riesgo”. En el caso de las organizaciones, estas deben asegurarse de que cuentan con un mecanismo que permita desasociar a un individuo con sus contribuciones de blockchain, ya sea como minero o como sujeto de datos.

José de la Cruz, director técnico de Trend Micro