Dar a conocer sin perder la firma

Un pasaporte digital del producto no muestra lo mismo a todo el mundo. Una compradora ve los datos públicos. Un taller de reparación o una empresa de reacondicionamiento ve más. Una autoridad de vigilancia del mercado lo ve todo. Esto está claro, y las normas europeas ya lo establecen expresamente.

La pregunta interesante es más sutil: si a alguien se le revelan campos protegidos más allá de los datos públicos, ¿puede demostrar que precisamente esos campos son auténticos? ¿O debe confiar en que la plataforma los ha seleccionado correctamente y los ha transmitido sin modificaciones?

En la mayoría de las plataformas, la respuesta sincera es: confianza. Nosotros hemos diseñado la nuestra de tal forma que la respuesta sea «prueba», no solo para los campos públicos, sino para cada campo que se añada en el momento de la divulgación. Por qué esta diferencia es importante y por qué hemos optado por el camino más laborioso.

Todos cumplen la norma de acceso de la misma manera

Lanorma EN 18239, la norma europea sobre derechos de acceso, seguridad y confidencialidad en el DPP, exige un control de acceso por elemento de datos: para cada campo hay una regla que establece quién puede verlo. Ese es el requisito adecuado y no es difícil de cumplir. En normas armonizadas hemos desglosado qué estatus tienen realmente estas normas.

La forma habitual de lograrlo es mediante el filtrado en el servidor. El servidor sabe quién realiza la consulta, comprueba qué puede ver esa persona y devuelve exactamente ese fragmento. Control de acceso: resuelto. La norma no exige nada más.

Sin embargo, hay un inconveniente del que la norma no se ocupa: el fragmento llega sin firmar. El lector recibe una vista preparada a su medida y debe confiar en que el servidor ha seleccionado el contenido de buena fe y no ha modificado nada durante la transmisión. Para una ficha informativa pública, esto está bien. Pero para un valor en el que un reciclador basa directamente el precio de una batería usada, se trata de una gran muestra de confianza.

Donde una sola firma llega a sus límites

La solución más obvia es firmar los datos. Para los dos extremos de la escala, una firma convencional funciona bien: firmar la vista pública, firmar el conjunto de datos completo y verificar ambos con una clave pública, sin que intervenga ningún servidor. El funcionamiento detallado se explica en Firmas y certificados en el DPP.

El problema surge en el punto medio. Una firma sobre todo el documento cubre exactamente un conjunto de campos, concretamente los que estaban presentes en el momento de la firma. Si se revela además un campo protegido a un lector autorizado, dicho campo queda fuera del conjunto firmado y le llega sin estar cubierto. Si, en cambio, se firma desde el principio el conjunto completo de datos, la firma lo cubre todo, pero entonces habría que mostrárselo todo a todo el mundo.

Los niveles intermedios quedan así fuera del sistema: el taller de reparación, la aseguradora, la empresa de reciclaje. Si se quisiera firmar de antemano cada posible combinación de «quién ve qué», se necesitaría un documento firmado específico para cada combinación, y el número de combinaciones se dispara con cada nuevo grupo de acceso. Nadie hace eso. Se recurre al filtro de servidor sin firmar, y el nivel intermedio vuelve a basarse en la confianza.

Firmar cada campo por separado

Existe un diseño mejor, y sobre él construimos la plataforma. En lugar de firmar el documento final como un bloque único, el emisor especifica cada campo por separado en una única pasada de firma (para los expertos en normas: el certificado del W3C ecdsa-sd-2023 para la divulgación selectiva).

Cada vista comienza por el núcleo público

Cada vista comienza, por tanto, con los mismos campos públicos. Lo que el lector ve además se añade campo a campo, y cada uno de estos campos sigue remitiendo a la clave pública del emisor - sin conexión, sin necesidad de volver a firmar y sin confiar en la entidad que ha compilado la vista - . Los campos sin derecho de acceso simplemente no aparecen. No están tachados, sino que ni siquiera están ahí, y no se filtra nada sobre ellos.

Un ejemplo práctico: el taller de reparación

Un ejemplo práctico ilustra cómo funciona esto en la práctica. Un taller de reparación ha declarado un interés legítimo respecto a una batería, uno de los niveles de acceso que prevé expresamente el Reglamento sobre baterías. Su sistema de taller se conecta a nuestra interfaz con su clave API y recupera el pase.

La respuesta es el mismo certificado público que ve la compradora, pero con un campo más: las instrucciones de desmontaje, que solo se revelan a los lectores autorizados. No es un segundo documento, ni una versión especial, sino el mismo certificado con un campo más.

Antes de que la empresa confíe en este campo, su software compara el certificado adjunto con la clave pública del emisor. Si la verificación es correcta, incluso en lo que respecta al campo adicional, sabe con certeza que estas instrucciones proceden, carácter por carácter, del fabricante, y que ni nosotros ni nadie en el proceso las ha modificado. Si la verificación falla, lo sabe con la misma certeza y descarta la vista en su totalidad.

Nuestra participación en ello es deliberadamente mínima. Que reciba exactamente los campos que le corresponden sigue siendo tarea de nuestro control de acceso; eso lo hace cualquier filtro de servidor de la misma manera. Lo nuevo es el paso siguiente: él mismo comprueba si lo que recibe es auténtico, sin preguntarnos.

Por qué lo «intacto» es la clave

Imaginemos a un notario que no certifica la carta en su totalidad, sino cada párrafo por separado. Todo el mundo recibe la carta pública. Quien tenga derecho a más, recibirá los párrafos adicionales, y cada uno de ellos seguirá llevando el sello del mismo notario.

Merece la pena dedicar una frase más a explicar por qué es tan importante que el sello esté «intacto ». Un sello intacto no garantiza que el contenido sea verdadero. Lo que indica es: esto es exactamente lo que escribió el emisor y, desde entonces, nadie ha alterado ni un solo carácter. De este modo, queda fuera de la cuestión de la confianza cualquiera que simplemente haya transmitido el documento: el servidor de caché, la red, el archivo, nosotros. Ya no importa quién le haya entregado el pasaporte.

Y un sello es binario. O se mantiene o no se mantiene; no existe un sello «a medias». Si se rompe, no sabrás qué frase se ha modificado, sino solo que ya no puedes confiar en todo el documento. Por eso no es una diferencia gradual si los campos adicionales te llegan con su sello o sin él: Sin sello, no están verificados de forma algo menos rigurosa, sino que no están verificados en absoluto.

Ambos métodos de visualización

Cualquiera puede comprobarlo por sí mismo. La Transpareo Time Machine es nuestra aplicación de visualización de código abierto para pasaportes de productos: Esta aplicación recorre el historial de versiones de un pasaporte y, al hacerlo, verifica cada firma en el navegador del usuario sin consultar ninguno de nuestros servidores. En ella se pueden consultar públicamente dos pasaportes de ejemplo. El pasaporte de una camiseta lleva una firma que abarca todo el documento, mientras que el de una batería presenta la divulgación campo por campo.

Ambas son especificaciones abiertas del W3C: eddsa-jcs-2022 para la firma que abarca todo el documento, ecdsa-sd-2023 para la divulgación campo por campo. Cualquiera que lo desee puede implementarlas. El esfuerzo que supone es la razón por la que muchos no lo harán: la firma sobre todo el documento es mucho más barata de crear y mantener, y a quien solo facilite datos públicos le basta con eso.

El hecho de que Time Machine domine ambos procedimientos es intencionado y seguirá siendo así. No pertenece a ninguna plataforma. Un verificador que solo aceptara el método más caro sería una herramienta para nosotros y para nadie más.

A quién se le revelan los campos protegidos

Merece la pena preguntarse a quién se le revela realmente algo más allá de los datos públicos. No a la compradora ocasional, que recibe el certificado público. Son el preparador, que evalúa el valor de un paquete de baterías usado; la aseguradora, que calcula el precio de un riesgo; el reciclador, que clasifica los compuestos químicos; y la autoridad, que instruye un expediente. Estos son los destinatarios cuyas decisiones dependen del dinero o de la seguridad.

Y son precisamente esos campos los que, en el enfoque habitual, quedan al descubierto. Quien más motivos tendría para querer una certificación criptográfica, no la obtiene, precisamente, para los campos que sustentan su decisión.

Creemos que un sello de certificación debería significar lo mismo para todos. «Verificado por Transpareo» significa lo mismo en la vista ampliada de un taller de reparación que en el certificado público de una compradora: cada campo mostrado procede del emisor y no ha sido alterado desde entonces. Un sello que solo se aplica a los campos públicos es un sello a medias.

Más de lo que exige la norma

Lo decimos abiertamente: nada de esto es obligatorio. La norma EN 18239 exige que se controle el acceso, y un filtro del lado del servidor lo controla a la perfección. Hacer que los campos revelados sean verificables criptográficamente es algo que hacemos además, no un requisito que nos imponga la normativa.

Precisamente por eso merece la pena dejarlo por escrito. El sentido de un pase firmado es que nadie tenga que confiar en la plataforma. Eliminar el nivel intermedio como excepción recupera precisamente esa confianza que la firma debía eliminar.

El mismo principio permite que se pase por alto un campo

Fijarse en cada campo por separado conlleva una segunda característica, y esta sí que la exige la legislación europea. El Reglamento General de Protección de Datos otorga a las personas el derecho a que se supriman sus datos personales. Un conjunto de datos firmado como un bloque no puede cumplir con este requisito sin destruir su propia firma.

Dado que aquí cada campo es independiente, se puede eliminar un solo campo, mientras que el resto sigue siendo verificable. Si, por error, se incluyen datos personales en un pasaporte, estos se eliminan por completo y el pasaporte sigue siendo válido: no hay que volver a expedirlo ni se interrumpe su historial. Los campos reglamentarios que la ley exige conservar permanecen intactos; lo que se puede eliminar se puede borrar a petición, incluso años después.

A pesar de todo, un pasaporte totalmente normal

Nada de esto convierte al pasaporte en un objeto especial que solo nuestras herramientas puedan abrir. Sigue siendo una credencial verificable en JSON-LD, el formato hacia el que converge el mundo de los estándares web, y el mismo formato que utilizan el Protocolo de Transparencia de la ONU y el resto del entorno del W3C.

El carné que una compradora escanea en el navegador es, por tanto, el mismo objeto que puede leer un socio de la sala de datos, y cualquier verificador que cumpla con las normas puede comprobarlo, no solo los nuestros. La seguridad adicional no le cuesta nada al lector y no vincula a nadie con nosotros.

Por qué es técnicamente complicado

Antes de nada, para que no se cree una impresión errónea: nosotros no hemos inventado el procedimiento. ecdsa-sd-2023 es una especificación pública del W3C; la criptografía que hay detrás no es obra nuestra, y quien quiera implementarla puede consultar la documentación. Lo difícil no es tener la idea. Lo difícil es diseñarla de tal forma que una contraseña siga siendo válida dentro de diez años. Ahí radica el trabajo, y sobre ello se puede decir algo útil.

La diferencia parece pequeña, pero cambia los fundamentos: una firma habitual realiza sus cálculos sobre los bytes de un documento. La divulgación selectiva realiza el cálculo a partir de sus afirmaciones. Antes de firmar, el pasaporte se adapta a un formato normalizado, en el que cada dato aparece como una frase independiente. Solo así es posible omitir una frase sin que ello afecte al resto.

Esto conlleva un problema que una firma de bytes no tiene: esa misma forma normalizada debe reproducirse exactamente igual dentro de diez años. No de forma aproximada, sino carácter por carácter; de lo contrario, la prueba ya no será válida. Hay tres cosas que lo impiden, y las tres son insignificantes.

Los números pierden su tipo. Si se escribe un número como simple JSON, por el camino se pierde qué tipo de número era. Un valor como 2,0 vuelve como 2 tras pasar por JSON. Para una persona es lo mismo, pero para la forma normalizada es otra frase, y la verificación falla.

Las denominaciones no son sinónimo de significado. Para que se genere la forma normalizada, cada nombre de campo debe resolverse en un significado único. Si falta uno, el campo desaparece silenciosamente durante la conversión. Entonces aparece en el carné, pero la justificación no lo cubre, y nadie se da cuenta.

Los significados suelen encontrarse en la red. Esta asignación figura en un vocabulario que la mayoría de las herramientas descargan de la red durante la comprobación. Quien lo haga, hace que la verificabilidad de su pasaporte dependa de que una dirección ajena siga respondiendo dentro de diez años, y además sin cambios.

Cómo lo hemos resuelto

Hemos resuelto los tres puntos de raíz, en lugar de detectarlos más tarde.

Tipos. Cada valor se escribe con su tipo, y la publicación se interrumpe en cuanto aparece, aunque sea uno solo, un número sin tipo en la forma normalizada. De este modo, el error se detecta allí donde cuesta una línea, en lugar de años más tarde como una inexplicable violación de la verificación.

Vocabularios. Cada vocabulario al que hace referencia un pase está disponible localmente en nuestro sistema y nunca se recupera a través de la red. Una dirección desconocida provoca una interrupción inmediata durante la firma, en lugar de una recaída silenciosa en un resultado vacío.

Identificadores. Cada nodo del documento lleva un identificador estable, para que la forma normalizada siga siendo reproducible, en lugar de asignar nuevos nombres auxiliares en cada pasada.

La parte más delicada reside en «Bring Your Own Key» (Trae tu propia clave). Para cada emisión se necesita una clave adicional de corta duración, con la que se firman individualmente los campos que pueden divulgarse. El propio emisor genera y desecha esta clave. Si estuviera en nuestro poder, podríamos inventar campos individuales a posteriori, y la independencia de la firma del emisor quedaría reducida a una mera afirmación. Comprobamos la prueba recibida cotejándola con la clave pública almacenada antes de darla por válida.

Cada pasaporte contiene dos de estos certificados: uno del emisor y otro de Transpareo, y cada uno de ellos se deriva de forma independiente para que un lector pueda consultarlo. Dos firmas, dos autoridades independientes entre sí, incluso para un campo divulgado de forma individual.

Para nosotros, este esfuerzo está bien invertido. No hemos añadido la verificabilidad a posteriori; la plataforma se ha desarrollado en torno a ella desde la primera versión. Cada pasaporte se firma al publicarse y se encadena a la versión anterior. El archivo inalterable de diez años se crea y entra en vigor tan pronto como los pasaportes se registran en el Registro DPP de la UE. Firmar cada campo en lugar de todo el bloque es una ampliación de este núcleo, no un añadido a algo que nunca se concibió para ello.

En qué punto nos encontramos

Hemos optado por la prueba, para todos los lectores, porque un sello debe significar lo mismo independientemente de quién lo mire. Para quienes quieran ver cómo funciona: las dos demostraciones enlazadas más arriba se verifican directamente en el navegador, sin necesidad de consultar un servidor.