La dificultad de integrar una licencia de conducir digital en un teléfono móvil (mDL) no reside en invocar una interfaz de programación para verificar la identidad, sino en comprender qué ocurre detrás de esa interfaz: dónde se almacenan las credenciales, quién protege las claves del dispositivo, cómo se gestionan los certificados de confianza y qué continúa funcionando cuando se interrumpe la red o falla el proveedor del servicio. El artículo publicado en InfoQ presenta una visión arquitectónica de los sistemas mDL construidos conforme a la norma ISO/IEC 18013-5, dirigida a las organizaciones que eligen un proveedor, un SDK, una plataforma de cartera o un servicio de verificación.
Separación entre la prueba de identidad y la emisión de la credencial
El marco propuesto comienza separando dos etapas distintas del ciclo de vida de la identidad. En la etapa de prueba de identidad, el usuario captura imágenes de su licencia física y un vídeo para la verificación de la vitalidad; después, las pruebas y los datos extraídos se envían al sistema de verificación. La autoridad competente, como el departamento de vehículos motorizados, revisa estas pruebas de forma automática o manual antes de emitir una decisión de aceptación o rechazo.
Tras la aprobación comienza la etapa de aprovisionamiento. El dispositivo genera claves asimétricas dentro de un Secure Enclave o un elemento seguro, y envía la clave pública, los certificados de atestación y la referencia de la operación de prueba a la entidad emisora. La entidad vincula los datos de la licencia con la clave dentro de un Mobile Security Object firmado; después cifra el paquete de credenciales y lo envía a la cartera para almacenarlo en un espacio respaldado por hardware.
La organización no tiene que ejecutar estos pasos por sí misma, pero debe determinar qué parte es responsable de cada paso y qué parte posee la decisión de confianza resultante.
¿Qué debe examinarse detrás de la interfaz del proveedor?
El artículo sostiene que el éxito de una prueba piloto que invoque funciones como verifyCredential() o requestPresentation() no basta para evaluar al proveedor. El examen debe abarcar seis ejes interrelacionados:
- Arquitectura criptográfica: generación y protección de claves, atestación del dispositivo, algoritmos y ciclo de vida de las claves.
- Confianza e infraestructura de clave pública: puntos de confianza, certificados de Document Signer, listas de confianza y de revocación.
- Privacidad y minimización de datos: divulgación selectiva, telemetría, conservación de los datos de presentación y riesgos de vinculación entre transacciones.
- Funcionamiento sin conexión: materiales almacenados en caché, estado obsoleto de la revocación y comportamiento del sistema durante una interrupción de la red.
- Interoperabilidad: cumplimiento de ISO/IEC 18013-5 y posibilidad de interactuar con carteras y verificadores independientes.
- Resiliencia operativa: impacto de la interrupción del proveedor, continuidad de la credencial y mecanismos de recuperación y gestión de fallos.
El cifrado y los certificados no son detalles de implementación
El artículo propone utilizar Hybrid Public Key Encryption conforme a RFC 9180 para proteger las operaciones de transporte en línea y los intercambios de las interfaces de programación, con parámetros que incluyen DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 y AES-128-GCM. Sin embargo, según el marco presentado, el cifrado no debe tratarse como una característica separada del modelo de confianza; es necesario saber dónde comienza y termina el cifrado, quién genera y protege las claves, cómo se rotan y qué componentes se encuentran dentro de los límites de confianza del proveedor.
Las comunicaciones entre los servidores de las carteras, las plataformas de emisión y los sistemas de verificación también requieren autenticación mutua mediante TLS y una arquitectura de certificados clara. El artículo presenta distintas funciones para los certificados, desde la raíz de confianza almacenada en un módulo de seguridad de hardware y fuera de línea, hasta certificados de Document Signer de corta duración, certificados mTLS y certificados de atestación de claves de dispositivos. La cuestión decisiva sigue siendo la distribución de responsabilidades: qué arquitectura gestiona el proveedor, cuál está bajo el control de la organización y qué relaciones de confianza permanecen en manos de la entidad emisora.
¿Qué cambia en la práctica cuando se interrumpe el servicio?
El diseño distingue entre las operaciones sincrónicas que ocurren durante la verificación, como el intercambio de datos mediante NFC o la verificación directa a través de una API, y las operaciones asincrónicas que pueden ejecutarse en segundo plano, como la revisión de la prueba de identidad, el aprovisionamiento de la credencial, la rotación de claves y la sincronización de listas de confianza.
Esta separación permite continuar presentando una credencial existente y verificarla sin conexión cuando las políticas lo permiten, mientras que la sincronización de las listas de confianza o las actualizaciones de revocación pueden aplazarse. El artículo propone probar la presentación y la verificación sin red, las credenciales caducadas, las listas de revocación obsoletas, la desviación del reloj del dispositivo, la recuperación de la conexión y el comportamiento del sistema durante una interrupción del proveedor. La dependencia de un proveedor altamente disponible puede seguir constituyendo un único punto de fallo si cada verificación requiere conectarse a sus servicios de backend.
Divulgación selectiva y prevención de la dependencia del proveedor
Los datos requeridos varían según el caso. Un punto de inspección en un aeropuerto puede necesitar el nombre, la fotografía, la fecha de nacimiento, el número del documento y la autoridad emisora, mientras que una tienda puede conformarse con una afirmación lógica que demuestre que la edad del usuario supera los 21 años, junto con una fotografía, sin el nombre, la dirección ni el número del documento. Por eso no basta con probar al proveedor mediante un único escenario; debe medirse frente a las políticas de la organización y a las categorías reales de transacciones.
El artículo propone mantener la lógica empresarial independiente de la arquitectura del proveedor, de modo que las aplicaciones expresen una política como solicitar una prueba de que la edad supera los 21 años, en lugar de publicar estructuras de datos específicas del proveedor por todo el sistema. Pueden ocultarse detalles como la secuencia de CBOR, la construcción de mensajes APDU y las llamadas a bibliotecas criptográficas, pero los puntos de confianza, la identidad de la entidad emisora, los atributos divulgados, el estado del certificado y de la revocación, la dependencia del proveedor y las capacidades de funcionamiento sin conexión deben seguir siendo visibles para la organización.
Lectura de certi.news
El cambio real en el que se centra el artículo consiste en trasladar la evaluación de mDL de la prueba de una función del SDK a la revisión de un sistema de confianza completo. Este enfoque resulta útil para los equipos de seguridad, identidad y adquisiciones porque determina qué puede comprarse y qué debe permanecer bajo la gobernanza de la organización: pueden comprarse la implementación de la cartera, los protocolos NFC y las bibliotecas criptográficas, mientras que las políticas de divulgación, autorización y auditoría, así como la gobernanza de la gestión de claves y certificados, la privacidad, la disponibilidad y la interoperabilidad, deberían construirse internamente.
Sin embargo, el marco no resuelve por sí solo cuestiones como los requisitos de cumplimiento locales o los modelos de gobernanza entre las entidades emisoras y los verificadores. Además, garantizar la validez de la firma no garantiza la privacidad si los sistemas conservan registros excesivos o vinculan las operaciones de presentación con los usuarios. Por ello, las cuestiones de trazabilidad, revocación que preserve la privacidad y responsabilidad ante el fallo del proveedor siguen requiriendo decisiones institucionales y regulatorias antes de pasar a producción.