La verificación de edad de la UE enfrenta críticas en Hacker News por la confianza en el hardware

El proyecto de verificación de edad de la UE ha atraído el escrutinio de Hacker News después de que su especificación incorporara el hardware criptográfico nativo al proceso de cumplimiento. El requisito protege las credenciales de edad frente a la extracción o duplicación. Pero también plantea una pregunta más compleja sobre quién controla el acceso cuando una wallet de código abierto depende de aplicaciones aprobadas, hardware de confianza y sistemas operativos reconocidos.

La controversia es más específica que las afirmaciones de que la Unión Europea ha prohibido Linux o impuesto Google Play Integrity en todas partes. Ninguna de esas conclusiones se desprende directamente de la especificación publicada. Los usuarios de escritorio pueden completar un flujo entre dispositivos con una wallet móvil, mientras que los implementadores nacionales conservan margen para elegir comprobaciones de integridad adicionales.

Aun así, la preocupación no es imaginaria. La arquitectura actual se centra en dispositivos móviles, y los proveedores de credenciales deben rechazar aplicaciones que no figuren en una lista de cumplimiento mantenida por la Comisión. Esa combinación convierte la disponibilidad del código fuente en solo una parte de la apertura práctica.

El resultado es una verdadera disyuntiva de política pública. La vinculación al hardware puede impedir que credenciales copiadas y clientes modificados debiliten un control de edad. El mismo modelo de confianza puede excluir compilaciones comunitarias, sistemas Android alternativos, dispositivos antiguos y a personas sin smartphones compatibles.

Lo que realmente exige la especificación de verificación de edad de la UE

La regla vinculante se refiere al hardware criptográfico, pero el acceso a producción también depende de la aprobación de la aplicación y de la política del proveedor de credenciales.

La Comisión Europea publicó la primera versión de su modelo de verificación de edad de marca blanca el 14 de julio de 2025. Fue diseñado como una base reutilizable que los Estados miembros podrían adaptar a aplicaciones nacionales.

El proyecto respalda el artículo 28 de la Ley de Servicios Digitales, que exige a las plataformas cubiertas proteger a los menores mediante medidas adecuadas y proporcionadas. La Comisión presenta el sistema como un puente temporal hacia las Carteras Europeas de Identidad Digital previstas para finales de 2026.

Su flujo de trabajo básico separa la prueba de edad de la divulgación de identidad. Un proveedor autorizado verifica la edad de una persona y emite una atestación digital. Posteriormente, un sitio web solicita una condición de edad, como si el visitante tiene más de 18 años.

El sitio web que confía en la prueba recibe el resultado de edad solicitado en lugar de un registro de identidad completo. Este diseño pretende evitar el envío repetido de pasaportes, datos de pago, imágenes faciales o fechas de nacimiento a servicios individuales.

Según la especificación técnica publicada, una aplicación de verificación de edad “DEBERÁ” usar hardware criptográfico nativo cuando esa capacidad esté disponible. Entre los ejemplos figuran Secure Enclave de Apple y Trusted Execution Environment o StrongBox de Android.

Estos componentes aíslan las operaciones criptográficas del sistema operativo principal. Una clave privada vinculada a la credencial puede permanecer inaccesible incluso cuando se copian o inspeccionan el almacenamiento ordinario de la aplicación.

El requisito no dice explícitamente que cada implementación deba usar Google Play Integrity o Apple App Attest. El almacenamiento de claves respaldado por hardware y la atestación remota de plataforma son controles relacionados, pero responden a preguntas diferentes.

El almacenamiento seguro pregunta si una clave está protegida por el dispositivo. La atestación remota puede preguntar si un servidor reconoce la aplicación, el sistema operativo, el estado de arranque, el hardware o el canal de distribución.

Esta distinción se volvió central después de que un informe original describiera las implicaciones para Linux y los sistemas móviles alternativos. El informe señaló que los servicios más estrictos no eran obligatorios de forma universal en la implementación de referencia.

No obstante, la especificación establece otros controles obligatorios. Cada prueba de edad es de un solo uso y se elimina de su lote emitido tras ser presentada. Los proveedores de atestaciones deben verificar la edad con un nivel de garantía “sustancial” o “alto” antes de emitir credenciales.

Los proveedores también deben negarse a emitir atestaciones a aplicaciones que no figuren en la lista de aplicaciones conformes de la Comisión. Un proveedor de aplicaciones debe notificar a la Comisión antes de publicar una wallet conforme, y la Comisión mantiene la lista correspondiente.

Esta capa de gobernanza importa tanto como la cláusula sobre hardware. Cualquiera puede inspeccionar o bifurcar el código, pero una bifurcación no necesariamente puede obtener credenciales auténticas de emisores de producción.

El proyecto sigue siendo una implementación de referencia, no un servicio universal terminado. Su repositorio de Android indica que la demostración está en desarrollo activo y requiere trabajo adicional antes de su despliegue en producción.

Los Estados miembros u otros implementadores deben encargarse del endurecimiento de las aplicaciones, la configuración de emisores, el almacenamiento seguro, la gestión de claves, la seguridad del registro, la localización y el cumplimiento legal. Sus decisiones determinarán si los sistemas finales usan una vinculación básica al hardware o verificaciones de dispositivo mucho más estrictas.

Por qué Hacker News se centró en el código abierto sin acceso abierto

El debate en Hacker News trata, en última instancia, de si el código auditable es suficiente cuando las instituciones siguen controlando las credenciales y la lista de confianza.

El proyecto publica el código fuente bajo la Licencia Pública de la Unión Europea. Los desarrolladores pueden inspeccionar las aplicaciones de referencia, compilarlas localmente, informar de problemas y proponer cambios.

Eso aporta una transparencia significativa. Permite a los investigadores examinar los flujos de registro, el almacenamiento de credenciales, los protocolos de presentación y las dependencias antes de que los despliegues nacionales lleguen a millones de usuarios.

Sin embargo, las licencias de código abierto no obligan a un emisor a confiar en cada binario modificado. Eso entraría en conflicto con el objetivo de seguridad del sistema, ya que un cliente alterado podría eliminar comprobaciones de autenticación o automatizar la presentación de credenciales.

Por ello, la Comisión necesita una forma de distinguir las aplicaciones aceptadas del software arbitrario. Su especificación lo hace mediante la lista de aplicaciones conformes y las reglas impuestas a los proveedores de atestaciones.

Esto produce dos definiciones distintas de apertura.

La primera es la apertura del código. Un desarrollador puede estudiar, compilar y modificar la aplicación sin obtener permiso de un proveedor propietario.

La segunda es la apertura operativa. Una aplicación modificada puede participar en la red real de credenciales sin la aprobación de una autoridad central o de un guardián de plataforma.

El proyecto de la UE respalda claramente la primera definición. Su apoyo a la segunda es limitado por diseño, porque se instruye a los emisores a reconocer únicamente las aplicaciones incluidas en la lista.

Los participantes del hilo de discusión vinculado insistieron en esa brecha. Algunos consideraron los requisitos de hardware una defensa necesaria contra la copia de credenciales. Otros vieron la arquitectura como una vía para excluir el software controlado por los usuarios.

Ambos argumentos identifican propiedades reales del diseño. Un emisor no puede tratar a todos los clientes como fiables, pero un proceso de aprobación puede convertirse en una barrera si sus reglas son opacas o difíciles de cumplir para desarrolladores independientes.

La arquitectura también separa el acceso desde escritorio de la ejecución de la wallet. Su documentación describe flujos de presentación en el mismo dispositivo y entre dispositivos.

En un flujo en el mismo dispositivo, la wallet y el sitio web operan en un único dispositivo. En un flujo entre dispositivos, un sitio web en un ordenador de escritorio muestra una solicitud que completa una wallet móvil cercana, normalmente mediante un código QR.

Eso significa que Linux no está expresamente prohibido. Un usuario de Linux puede visitar un sitio web restringido y presentar una prueba mediante un teléfono compatible.

Sin embargo, esto no equivale a contar con soporte nativo para wallets en Linux. Las implementaciones de referencia actuales se centran en Android e iOS, mientras que la especificación denomina a la aplicación móvil de marca blanca el canal de entrega principal.

Alguien con un portátil Linux pero sin un smartphone compatible sigue enfrentándose a un problema de acceso. Lo mismo ocurre con un usuario cuyo teléfono carece del hardware seguro requerido o no puede satisfacer la política de integridad de un despliegue nacional.

La aplicación de referencia de Android requiere el nivel de API 29, que corresponde a Android 10. Esa base ya excluye dispositivos antiguos antes de que se aplique cualquier endurecimiento adicional para producción.

La accesibilidad también implica más que los sistemas operativos. El registro puede depender de la identificación electrónica nacional, documentos de identidad compatibles, proveedores de confianza u otras fuentes específicas de cada país.

Las personas sin documentos compatibles pueden encontrar una barrera antes de que la confianza en el hardware sea relevante. Los refugiados, migrantes, visitantes y residentes cuyos registros no se conecten claramente con un emisor necesitan alternativas viables.

Estos problemas no demuestran que el sistema esté concebido como un mecanismo de vigilancia. Sí muestran por qué el “código abierto” no puede resolver por sí solo el debate sobre el acceso.

Un repositorio abierto permite la revisión. No garantiza una participación equitativa entre dispositivos, sistemas operativos, situación documental o implementaciones nacionales.

La vinculación al hardware protege las credenciales, pero desplaza el control

La disyuntiva central es una mayor resistencia al robo de credenciales a cambio de una mayor dependencia de los proveedores de hardware, distribuidores de aplicaciones y decisiones institucionales de confianza.

Una prueba de edad reutilizable adquiere valor cuando los sitios web la aceptan. Los atacantes tienen entonces incentivos para copiar credenciales, generar atestaciones falsas, automatizar presentaciones o modificar una wallet para eludir la autenticación local.

Las claves respaldadas por hardware reducen esos riesgos. La wallet puede solicitar firmas sin exponer la clave privada a la memoria o al almacenamiento ordinarios de la aplicación.

Esto protege contra la extracción directa. Copiar los archivos de la wallet a otro dispositivo no debería copiar la autoridad criptográfica necesaria para presentar la credencial.

La especificación añade atestaciones de un solo uso para limitar la repetición y el seguimiento entre servicios. Los proveedores emiten credenciales en lotes y la wallet elimina cada atestación después de presentarla.

Un período máximo de validez recomendado de tres meses limita durante cuánto tiempo sigue siendo útil un lote emitido. El documento evita imponer una revocación obligatoria porque un servicio de revocación añadiría complejidad y podría aumentar la posibilidad de vinculación.

Estas decisiones ilustran la ingeniería de privacidad del proyecto. Un servicio central no necesita aprobar cada visita a un sitio web, mientras que las partes que confían en la prueba reciben un atributo de edad de alcance limitado.

El Comité Europeo de Protección de Datos también ha publicado diez principios de privacidad para la garantía de edad. Hacen hincapié en la necesidad, la proporcionalidad, la minimización de datos, la equidad, la exactitud, la seguridad y alternativas efectivas.

La protección por hardware respalda la seguridad, pero no satisface automáticamente los demás principios. Un sistema técnicamente seguro aún puede excluir a usuarios o revelar más información de la que necesita un servicio concreto.

La controversia crece cuando los implementadores añaden servicios de integridad remota. Google describe Play Integrity como una forma de evaluar si las solicitudes proceden de una aplicación reconocida que se ejecuta en un entorno Android genuino y certificado.

Sus niveles de integridad pueden incluir señales respaldadas por hardware, estado del bootloader, certificación del sistema operativo, actualizaciones de seguridad recientes, reconocimiento de la aplicación y origen de la instalación.

Estas capacidades ayudan a detectar clientes manipulados y dispositivos con acceso root. También pueden rechazar sistemas operativos alternativos que ofrecen una seguridad sólida, pero no son aceptados dentro del modelo de certificación de Google.

Google recomienda la aplicación escalonada porque menos dispositivos cumplen el veredicto más estricto. Ese consejo reconoce el problema de alcance: la respuesta de seguridad más estricta no está disponible para todos los usuarios legítimos.

App Attest de Apple sigue un modelo similar de verificación en servidor. Crea una clave basada en hardware y permite a Apple certificar que la clave pertenece a una instancia válida de la aplicación.

La guía de atestación de Apple también indica a los desarrolladores que comprueben la disponibilidad y gestionen adecuadamente los dispositivos no compatibles. No presupone que todos los dispositivos o tipos de aplicación puedan proporcionar el servicio.

La especificación de la UE no agrupa actualmente toda la protección de hardware en estos dos servicios comerciales. Menciona entornos criptográficos nativos y deja las decisiones adicionales de endurecimiento en manos de los implementadores.

Esa flexibilidad es importante, pero también pospone la cuestión decisiva de política. Los despliegues nacionales pueden elegir controles con consecuencias distintas para tiendas de aplicaciones alternativas, sistemas operativos posventa y monederos compilados de forma independiente.

Una implementación limitada podría vincular credenciales a una clave segura sin pedir a un operador de plataforma que apruebe todo el entorno de software. Una implementación más estricta podría exigir una firma de aplicación reconocida, un gestor de arranque bloqueado, un sistema operativo certificado y una vía de distribución oficial.

Ambas implementaciones podrían describirse como respaldadas por hardware. Sus efectos sobre la competencia y la libertad de los usuarios diferirían notablemente.

Por ello, los desarrolladores deben evitar tratar la «atestación de hardware» como una tecnología única e indivisible. La política de confianza real depende de qué afirmaciones exige un verificador y qué autoridades acepta.

Un dispositivo puede demostrar que una clave reside en hardware seguro sin demostrar que Google aprobó su sistema operativo. A la inversa, Play Integrity puede combinar evidencia de hardware con las clasificaciones de aplicaciones y dispositivos de Google.

La cuestión relevante no es si interviene hardware. Es quién define qué dispositivo es aceptable, qué evidencia se exige y si los usuarios rechazados reciben otra vía segura.

La promesa de privacidad sigue afrontando debilidades prácticas

La arquitectura puede minimizar la divulgación a los sitios web, pero no puede demostrar que la persona que posee una credencial de adulto sea quien está viendo el contenido.

El diseño de la UE aborda un importante fallo de privacidad de las comprobaciones de edad convencionales. Un sitio web restringido no necesita recopilar un documento de identidad ni mantener una base de datos que vincule identidades legales con la actividad de navegación.

El plan de referencia de marca blanca de la Comisión describe un método que preserva la privacidad y que los Estados miembros pueden personalizar. La credencial pretende revelar una condición de edad, en lugar de información personal no relacionada.

Esa separación tiene valor. Grandes colecciones de pasaportes, selfis, fechas de nacimiento y registros de pago crean objetivos atractivos para atacantes y aumentan las consecuencias de una filtración.

Sin embargo, preservar la privacidad no resuelve el problema del préstamo de credenciales. Un menor puede usar el teléfono de un adulto, mientras que un adulto puede aprobar una solicitud para otra persona.

La especificación reconoce que los dispositivos pueden compartirse entre usuarios. Exige autenticación local fiable, como un PIN, contraseña, patrón o comprobación biométrica, antes de presentar una atestación.

Eso verifica el acceso al monedero. No establece quién está mirando la pantalla de destino después de que se acepta la prueba.

Controles locales más estrictos pueden hacer menos cómodo el uso compartido casual, pero el sistema no puede vincular continuamente el consumo de contenido con la persona cuya edad se verificó. Hacerlo requeriría una supervisión más intrusiva.

Este es el límite fundamental de muchos sistemas de verificación de edad. Aumentar la garantía suele exigir evidencia de identidad adicional, comprobaciones biométricas, análisis del comportamiento o autenticación repetida.

Cada medida añadida puede reducir las oportunidades de elusión. Cada una también puede crear nuevos riesgos de recopilación de datos, exclusión, accesibilidad y seguridad.

La vinculación al hardware protege la credencial contra la extracción, pero no puede impedir la entrega voluntaria de un dispositivo desbloqueado. La atestación de aplicaciones puede detectar software modificado, pero no puede determinar quién está detrás de la pantalla.

El mecanismo de conocimiento cero del proyecto también merece un tratamiento preciso. El lenguaje normativo indica que las aplicaciones deberían implementar el mecanismo de prueba de conocimiento cero especificado, mientras que las partes confiantes deberían implementar su verificación.

«Debería» es significativo, pero menos firme que «deberá» en el lenguaje de los estándares. Por tanto, las implementaciones pueden diferir en cómo proporcionan la desvinculabilidad y la divulgación selectiva.

Una prueba de conocimiento cero permite a una parte establecer un hecho sin revelar el secreto subyacente. En este contexto, el objetivo es demostrar una condición de edad sin divulgar la identidad ni una fecha de nacimiento exacta.

Incluso un sistema de pruebas bien diseñado opera dentro de una red más amplia. Emisores, aplicaciones, listas de confianza, sitios web, dispositivos y servicios de plataforma siguen generando datos operativos.

La privacidad depende de si esos componentes pueden correlacionar los eventos de emisión y presentación. También depende de las políticas de registro, la precisión de las marcas de tiempo, los identificadores de red, la analítica y las decisiones nacionales de implementación.

La especificación intenta reducir la vinculación mediante atestaciones de un solo uso y limitando la precisión de las marcas de tiempo. Estas medidas merecen reconocimiento, pero las pruebas independientes deben confirmar cómo se comportan los despliegues completos.

La aplicación Android existente es explícitamente una demostración en desarrollo activo. Su repositorio advierte que los despliegues de producción requieren almacenamiento seguro, gestión de claves, endurecimiento de aplicaciones, validación de inscripción y trabajo de gobernanza.

Un fallo en una versión de demostración no invalidaría necesariamente el protocolo. Del mismo modo, un protocolo sólido no garantizaría que todas las aplicaciones nacionales lo implementen de forma segura.

Esta distinción debe guiar la cobertura de futuros informes de seguridad. Los investigadores deben identificar si una debilidad afecta a la demostración, a una decisión de despliegue, al protocolo de credenciales o a todo el modelo de garantía.

La reacción en Hacker News refleja desconfianza hacia sistemas que comienzan con un propósito limitado y más adelante adquieren usos más amplios. La especificación actual se centra en el acceso a servicios en línea y considera varios escenarios del mundo físico fuera de su ámbito prioritario.

Ese alcance puede cambiar mediante decisiones políticas posteriores. Los componentes técnicos creados para demostrar la edad podrían acabar admitiendo otros atributos dentro del marco más amplio de la Identidad Digital Europea.

Esa expansión no está establecida por el actual documento de verificación de edad. Aun así, la gobernanza debería abordar la limitación de finalidad antes del despliegue, porque la compatibilidad técnica facilita la reutilización posterior.

La promesa de privacidad es, por tanto, condicional y no vacía. El diseño puede divulgar menos que las comprobaciones directas de documentos, pero su éxito depende de la implementación, la supervisión, las alternativas y la resistencia a la ampliación de alcance.

Qué deberían vigilar los desarrolladores y los usuarios a continuación

La evidencia decisiva procederá de las políticas nacionales de confianza, las pruebas de seguridad independientes y el tratamiento de los dispositivos legítimos que no superan las comprobaciones de integridad preferidas.

La primera señal es la política de cumplimiento para aplicaciones en producción. La lista de monederos aceptados de la Comisión determinará si los proveedores independientes tienen una vía realista de entrada al ecosistema.

Los desarrolladores necesitan criterios publicados, plazos de revisión, procedimientos de apelación y normas para compilaciones reproducibles de código abierto. Sin ellos, la lista puede funcionar como una barrera opaca incluso cuando el código fuente siga siendo público.

Un proceso creíble debería explicar si las aplicaciones mantenidas por la comunidad pueden cumplir los requisitos. También debería identificar quién asume la responsabilidad de las actualizaciones de seguridad, la respuesta a incidentes y la revocación de credenciales después de que se acepte un monedero.

La segunda señal es cómo los Estados miembros implementan la confianza en el dispositivo. El almacenamiento de claves respaldado por hardware por sí solo crea consecuencias de acceso distintas de los veredictos obligatorios de Play Integrity o App Attest.

Las aplicaciones nacionales deberían documentar qué señales solicitan y cómo responden ante un fallo. Un resultado de integridad vacío no debería tratarse automáticamente como prueba de fraude cuando hardware no compatible o un sistema operativo alternativo pueden producir el mismo resultado.

Las alternativas importan. Una persona que no dispone de un teléfono compatible necesita otra forma proporcionada de demostrar su edad, especialmente cuando el acceso implica información lícita en lugar de una función comercial opcional.

Esas alternativas podrían incluir credenciales entre dispositivos procedentes de otro monedero de confianza, inscripción asistida, canales físicos compatibles o hardware seguro independiente de la plataforma. Cada opción requiere su propio análisis de amenazas.

La tercera señal es la evaluación independiente del sistema completo. Los repositorios de referencia mencionan actualizaciones continuas, endurecimiento para producción y pruebas de la comunidad, pero la revisión pública del código no sustituye una evaluación estructurada.

Los investigadores deberían probar la extracción de credenciales, la resistencia a la repetición, la clonación de monederos, el abuso por parte de emisores, la connivencia de verificadores, los escenarios de dispositivos compartidos, la correlación de metadatos, la denegación de servicio y los fallos de accesibilidad.

También deberían publicar si un hallazgo se dirige al protocolo o a una implementación. Esa claridad evita que un error de aplicación corregible se presente como un fallo criptográfico total.

A la inversa, una demostración segura no debería utilizarse para afirmar que el modelo de política ha resuelto la garantía de edad. El préstamo de credenciales, el acceso a documentos, la exclusión digital y la ampliación de finalidad no son defectos ordinarios de software.

Las plataformas también afrontan decisiones operativas. Un sitio web debe validar que una atestación procede de un proveedor autorizado y contiene el atributo solicitado.

Debería solicitar únicamente la condición mínima de edad exigida por la ley o la política. Recopilar atributos adicionales socavaría la ventaja declarada del sistema frente a los proveedores de verificación que dependen intensamente de la identidad.

Los desarrolladores que integren el protocolo tendrán que supervisar las especificaciones cambiantes porque el proyecto está alineado con la evolución del Marco de Arquitectura y Referencia de la Identidad Digital Europea. Las afirmaciones de interoperabilidad dependen de esos estándares en movimiento.

También deben evitar asumir que la implementación de un país predice la de otro. El plan de referencia permite adaptación nacional en torno a la inscripción, los umbrales de edad, los controles de seguridad, la retención y la configuración de proveedores.

Para los usuarios, las preguntas más claras son prácticas. ¿Puede el monedero nacional funcionar en su dispositivo, pueden obtener una credencial y pueden apelar un rechazo incorrecto?

También se debería informar a los usuarios sobre qué recibe el sitio web que confía en la credencial, durante cuánto tiempo el monedero almacena las atestaciones y si la emisión puede vincularse a presentaciones posteriores. Esas explicaciones deben poder entenderse sin leer una especificación de protocolo.

El argumento más sólido a favor del enfoque de la UE es que puede sustituir la divulgación repetida de identidad por pruebas de edad de un solo uso y alcance limitado. Las claves vinculadas al hardware hacen que esas pruebas sean más difíciles de copiar o fabricar.

La objeción más sólida es que la seguridad puede convertirse en permiso. Si las credenciales de producción solo funcionan mediante software aprobado en dispositivos reconocidos por proveedores, los usuarios pierden un control significativo pese a recibir el código fuente.

Por eso la controversia en Hacker News no puede resolverse etiquetando el proyecto como preservador de la privacidad o excluyente. La arquitectura contiene mecanismos que respaldan ambos resultados.

Primero observe la lista de cumplimiento, después los requisitos nacionales de integridad y, por último, los resultados independientes de los flujos completos de producción. En conjunto, esas señales mostrarán si la confianza en el hardware protege una credencial privada o se convierte en una barrera para el acceso lícito a internet.

Los desarrolladores, los responsables de políticas públicas y los usuarios deberían exigir una respuesta concreta antes de aceptar un despliegue nacional: ¿qué vía segura queda cuando una persona legítima no puede superar la comprobación de dispositivo preferida? La respuesta revelará si este sistema trata los fallos de compatibilidad como excepciones manejables o como motivos de exclusión. Esa decisión, más que la existencia de un Secure Enclave o StrongBox, determinará si el proyecto de verificación de edad de la UE se gana la confianza más allá de las noticias para hackers.