Billetera de identidad electrónica eIDAS de Alemania: estructura de verificación de seguridad del dispositivo basada en cuentas de Apple y Google

 (bmi.usercontent.opencode.de)
1 puntos por GN⁺ 24 일 전 | 1 comentarios | Compartir por WhatsApp
  • La National EUDI Wallet de Alemania mantiene la integridad de la autenticación de identidad electrónica mediante un esquema de gestión de vulnerabilidades de dispositivos móviles (MDVM)
  • MDVM detecta vulnerabilidades en el sistema operativo y el almacén de claves de hardware (HKS) y, si el riesgo es alto, bloquea el uso de claves de autenticación
  • En Android, verifica la integridad del dispositivo con Google Play Integrity API y KeyAttestation; en iOS, usa Apple DeviceCheck·AppAttest
  • Debido a esta estructura, al usar funciones de identidad electrónica se activa de forma obligatoria un procedimiento de verificación basado en cuentas de Apple o Google
  • Todo el sistema está diseñado con el objetivo de evitar la clonación y el uso indebido de claves por parte de atacantes y mantener la autenticación eID con un alto nivel de aseguramiento

Concepto de gestión de vulnerabilidades de dispositivos móviles (Mobile Device Vulnerability Management, MDVM)

  • MDVM es un esquema dentro de la arquitectura de la National EUDI Wallet de Alemania que supervisa continuamente las vulnerabilidades de seguridad del dispositivo del usuario y mantiene la integridad de los medios de autenticación
  • Detecta vulnerabilidades conocidas del HKS (almacén de claves de hardware) y del sistema operativo (OS) y, si el riesgo de ataque es alto, bloquea el uso de claves RWSCA/RWSCD
  • Con ello, mantiene un alto nivel de aseguramiento en el proceso de verificación de identidad electrónica (eID) y evita la clonación y el uso indebido de claves por parte de atacantes
  • MDVM se compone de cuatro funciones: verificación del estado de seguridad del dispositivo y de la app, identificación de la clase del dispositivo, verificación de vulnerabilidades y decisión de uso

Motivación

  • La Wallet Unit proporciona medios de autenticación vinculados a varios medios de identidad (como PID) mediante un par de claves pública/privada
  • Al emitir un PID, el WB (Wallet Backend) confirma frente al PP (Provider Party) mediante OpenID4VCI Key Attestation que esa clave está controlada por un medio de autenticación con cierto nivel de resistencia a ataques
  • Conforme a ISO/IEC 18045 y al Reglamento de la UE 2015/1502, la verificación de identidad electrónica con alto nivel de aseguramiento exige medios de autenticación sólidos
  • Los medios de autenticación ofrecen dos garantías
    1. Prevención de clonación y manipulación del almacén de claves
    2. Prevención de ataques contra el mecanismo de autenticación del usuario
  • La primera garantía puede implementarse con RWSCD basado en HSM, y lograrse independientemente del dispositivo del usuario
  • La segunda garantía depende de la seguridad del dispositivo del usuario y se compone de un factor de posesión (basado en HKS) y un factor de conocimiento (como contraseña)
  • En la práctica, no es posible realizar análisis previos de vulnerabilidades y certificación del HKS o del OS de los dispositivos móviles, y en el pasado se han reportado numerosas vulnerabilidades
  • Por ello, mediante un sistema de monitoreo de vulnerabilidades en operación (MDVM) se reduce la posibilidad de ataque y, en dispositivos con seguridad insuficiente, se bloquea el uso de claves RWSCA/RWSCD

Funciones principales de MDVM

Función Descripción
Verificación del estado de seguridad del dispositivo/app Verifica la integridad y autenticidad del dispositivo y de la app Wallet, aprovechando funciones de seguridad de la plataforma y RASP (Runtime Application Self-Protection)
Identificación de la clase del dispositivo Identifica de forma verificada el modelo del dispositivo, la versión y nivel de parche del OS, y la información del HKS
Verificación de vulnerabilidades por clase de dispositivo Comprueba la información más reciente sobre vulnerabilidades del OS y del HKS
Decisión de uso del dispositivo/app Con base en el estado de seguridad y la información de vulnerabilidades, en dispositivos con seguridad insuficiente bloquea la validación de OpenID4VCI Key Attestation y el uso de claves RWSCD

Señales recopiladas

  • Las señales recopiladas se usan para respuesta ante amenazas, identificación de la clase del dispositivo y verificación de plausibilidad (plausibility check)

  • Principales fuentes de señal: KeyAttestation, PlayIntegrity, DeviceCheck, RASP, LPADB, DCVDB

  • Resumen

    Fuente de señal Amenazas abordadas Sinergia Nota
    KeyAttestation Root, desbloqueo del bootloader, ROM personalizada, manipulación de app, clonación, emulación, ataques de replay, etc. LPADB, RASP Se usa como entrada para DCVDB
    PlayIntegrity Manipulación de app, replay, root, ROM personalizada, evaluación MDVM basada en backend de Google, herramientas de robo de credenciales, ataques de overlay, etc. KeyAttestation, RASP Requiere verificar el estado del bootloader
    iOS DeviceCheck Replay, manipulación de certificados, ataques por proxy, manipulación de app RASP Garantía insuficiente de integridad del dispositivo
    LPADB Ocultamiento de root usando claves públicas de KeyAttestation KeyAttestation -
    DCVDB Detección de dispositivos inseguros basada en vulnerabilidades conocidas KeyAttestation, RASP Es importante la precisión en la identificación de la clase del dispositivo
    RASP Detección de hooking de app, depuración, root, emulación - Supervisión continua de integridad en tiempo de ejecución

Señales de Android KeyAttestation

  • Identifica el modelo del dispositivo, la versión del OS, el nivel de parche, el estado del bootloader y otros datos mediante información de verificación de hardware basada en HKS
  • Elementos principales de señal
    • SecurityLevel: identificación del tipo de HKS (TrustedEnvironment, StrongBox)
    • attestationIdModel/Product/Device: identificación del modelo del dispositivo
    • osVersion / osPatchLevel: versión del OS y nivel de parche de seguridad
    • RootOfTrust: estado del bootloader y de Verified Boot
    • AttestationApplicationId: nombre del paquete de la app, versión, hash del certificado de firma
  • La lista de revocación de certificados de Key Attestation de Google se actualiza lentamente, por lo que claves filtradas públicamente siguen pudiendo usarse
  • En algunos dispositivos pueden faltar ciertos campos de identificación, por lo que es necesario evaluar los tres campos

Señales de Android PlayIntegrity Verdict

  • Verifica la integridad de la app y del dispositivo mediante Google Play Integrity API
  • Elementos principales de señal
    • appRecognitionVerdict: si la app es original o no
    • deviceRecognitionVerdict: nivel de confianza del dispositivo (por ejemplo, MEETS_STRONG_INTEGRITY)
    • appLicensingVerdict: si fue instalada desde PlayStore
    • playProtectVerdict: evaluación de riesgo de Play Protect
  • MEETS_STRONG_INTEGRITY exige que se haya aplicado un parche de seguridad en los últimos 12 meses
  • Para asegurar la confiabilidad de la señal, se requiere verificación de firma y descifrado
  • El método interno de evaluación del backend de Google no es público

Android RASP

  • La solución concreta aún no está definida y se encuentra en etapa de definición de requisitos funcionales
  • Funciones de detección
    • App Hooking/Debugging: detección de manipulación dinámica (Frida, Xposed, etc.)
    • App Repackaging/Tampering: detección de modificación de la app y nueva firma
    • UD Rooting/Emulation: detección de root, virtualización y entornos automatizados
  • RASP proporciona supervisión de integridad en tiempo de ejecución y mantiene una lista de bloqueo separada de la lista de revocación de Google para prevenir ataques basados en claves filtradas

iOS DCDeviceCheck.AppAttest Attestation

  • Estructura de autenticación de apps mediante Secure Enclave y servidores de Apple
  • Señales principales
    • attestationObject: demuestra que la clave de App Attest fue generada en Secure Enclave
    • credentialId: identificador de la clave de App Attest
    • RP ID: prefijo App ID de la app + Bundle ID
  • El indicador de riesgo de Apple (receipt metric) puede usarse para detectar ataques por proxy, pero no existe un criterio claro y hay riesgo de exposición de datos personales por la comunicación con servidores de Apple
  • En iOS no es posible proporcionar información basada en hardware sobre el modelo del dispositivo ni la versión/nivel de parche del OS; solo puede comprobarse mediante consultas al OS

iOS DCDeviceCheck.AppAttest Assertions

  • Estructura de verificación basada en firmas generadas con la clave de App Attest
  • Señales principales
    • assertionObject: incluye la firma sobre el challenge
    • keyId: identificador de la clave de App Attest
    • counter: cantidad de firmas, debe aumentar de forma monótona
  • Un aumento brusco del valor del contador sugiere la posibilidad de un ataque por proxy, mientras que una disminución sugiere un posible ataque de replay

iOS RASP

  • Se requieren funciones de detección similares a Android
    • App Hooking/Debugging, App Repackaging, App Tampering, UD Rooting, UD Emulation
  • App Sandbox, Code Signing y System Integrity Protection de Apple solo ofrecen protección en el momento de la instalación y no incluyen funciones de detección de root, hooking ni manipulación en tiempo de ejecución
  • RASP complementa esto con supervisión de integridad en tiempo de ejecución
  • Según la documentación de Apple, App Attest indica que “una app manipulada que se ejecuta en un dispositivo legítimo no puede generar una assertion válida”

Conclusión

  • MDVM evalúa en tiempo real el estado de seguridad del dispositivo y bloquea el uso de claves de autenticación en entornos con alta probabilidad de ataque, con lo que mantiene la confiabilidad del sistema de autenticación de identidad electrónica
  • Tanto Android como iOS combinan funciones de seguridad de la plataforma y protección dinámica basada en RASP para conformar un esquema de verificación de integridad del dispositivo
  • Existe dependencia de los esquemas de verificación backend de Google y Apple, y los métodos internos de evaluación no públicos siguen siendo un factor potencial de incertidumbre

Lecturas relacionadas

1 comentarios

 
GN⁺ 24 일 전
Opiniones de Hacker News

  • La especificación de eIDAS 2.0 no exige hardware específico
    Solo es una estructura para almacenar credenciales verificables y certificados firmados criptográficamente
    Parece más bien pereza del equipo de implementación alemán al intentar esquivar la cláusula de “debe implementarse un mecanismo para que el usuario pueda verificar la autenticidad de la Wallet Unit”
    La documentación relacionada puede verse en EUDI Architecture and Reference Framework

    • Al revisar la implementación de referencia, parece que los mantenedores no quieren eliminar la dependencia de Google
      No está claro por qué, pero si algo continúa sin motivo aparente, al final suele haber una razón
      Ver el repositorio de GitHub
    • En la sección 5.4, en las partes de Attestation Rulebooks y Attestation Schemes, están especificadas las reglas relevantes

  • Como implementador alemán, según el reglamento de ejecución de eIDAS, hay que usar un mecanismo de attestation
    Esto no funciona sin soporte del sistema operativo
    Sabemos que estar limitados hoy a Google/Android no es lo ideal, y también está previsto soporte para otros sistemas como GrapheneOS
    Por ahora es solo una cuestión de prioridades, no que no reconozcamos el problema

    • Depender de productos de dos empresas estadounidenses no es solo algo “no ideal”, sino un problema grave
      Hay muchos casos de bloqueo de cuentas, y esa dependencia sería mejor evitarla por completo
    • También hay un elemento ilegal desde la perspectiva de accesibilidad y del espíritu de eIDAS
      Al final, todos los ciudadanos quedan sujetos a los términos de Google y Apple, y si les suspenden la cuenta pierden acceso al servicio eID
      Como técnicamente existen alternativas, es tu responsabilidad encontrar una solución así
    • Como ciudadano alemán, quiero preguntar: ¿por qué seguir adelante sabiendo que no funcionará para todos los ciudadanos?
      Yo pasé de Android basado en AOSP sin Google Play a Ubuntu Touch, y en el futuro planeo cambiar a postmarketOS
    • Es demasiado fácil perder acceso a una cuenta de Google. Recuperarla también puede ser imposible
      Considerando estas situaciones y el riesgo geopolítico, no se puede justificar depender de una empresa específica
      También está la lección de experiencia de desarrollador: “no hay nada más permanente que una solución temporal”
    • Ya era un problema resuelto con el Mobile-ID (basado en SIM) o Smart-ID (gestión de claves del lado del servidor) de eIDAS 1
      Así que no se entiende por qué forzarlo al modelo Wallet
      No hay razón para depender del backend de dos empresas estadounidenses

  • Hay que abolir por completo el attestation
    La app no debería saber en qué dispositivo se está ejecutando
    El usuario puede proteger su dispositivo por sí mismo, y al desarrollador le basta con dar recomendaciones
    Debería poder ejecutarse en cualquier entorno: GrapheneOS, root, emuladores, capas de compatibilidad de Linux, etc.

    • Exacto, es mi dispositivo, así que debería poder usarlo como yo quiera
      No hace falta que la app revise automáticamente si tiene la “certificación” de las big tech de Estados Unidos
    • La idea misma de confianza en el dispositivo es una ilusión
      Si se mira la historia de consolas y teléfonos rooteados, ninguna seguridad es perfecta
      Lo deseable sería dejar que, si el usuario quiere, vincule su identidad al dispositivo como una opción voluntaria
    • Claro que uno es libre de rootear o modificar, pero también tiene que asumir las consecuencias
      Si una app no puede verificar su propia integridad, algunas funciones son imposibles desde el punto de vista de seguridad
      Igual que una identificación física tiene restricciones de forma o tamaño, hacen falta ciertos límites
    • El pecado original de la computación moderna es que los ‘elementos de seguridad’ fueron diseñados para los fabricantes, no para los usuarios
      El problema empezó cuando en la época de NGSCB no se prohibieron legalmente esos componentes

  • ¿Y si pierdes tu cuenta de Google o Apple?
    Si terminas sancionado, como un juez de la Corte Penal Internacional, te quedas sin acceso a eIDAS
    Que la sociedad europea siga manteniendo una estructura de dependencia de empresas estadounidenses es una realidad contradictoria

    • Incluso sin ser una figura pública, una suspensión automatizada de cuenta puede dejarte socialmente excluido
      Es peligroso que dos empresas extranjeras tengan poder de vigilancia y control
    • “Si la capital de Europa estuviera en Washington”, entonces tal vez esto sería lo normal
    • Entonces tampoco podrías usar Waymo

  • Es impactante que haya tan poca oposición pública a este tipo de políticas
    Como padre, entiendo la necesidad de controlar el uso de internet por parte de los hijos,
    pero al final el Estado está haciendo el trabajo que deberían hacer los padres, y estamos perdiendo libertad y privacidad

    • La mayoría de la gente solo entiende de forma abstracta cómo esto afecta su vida
      Si no es una amenaza concreta como “el gobierno lee mis mensajes de WhatsApp”, no reaccionan
    • En Alemania la atención se dispersa con temas desgastantes como el debate sobre el límite de velocidad
      La clase política aprovecha esa confusión para ocultar los problemas de fondo
    • De hecho, muchos padres sí apoyan limitar el acceso en línea
      Quieren proteger a sus hijos de la explotación de la atención por parte de las grandes empresas
      Así como hay restricciones de edad en el mundo real, internet no tendría por qué ser la excepción
    • La gente está atrapada en su propia burbuja de filtros y ni siquiera oye hablar de estos temas
      Pensando en el futuro de la democracia, es muy preocupante
    • La UE funciona en la práctica como una plataforma de lobby
      El lobby ciudadano es posible, pero requiere costos y coordinación, así que las grandes empresas terminan dominando
      También hubo recientemente un caso en que infraestructura digital de la UE fue comprometida por un grupo de hackers
      Artículo relacionado

  • Exigir hardware o software específico es irracional
    Todos los ciudadanos deberían poder usar la computadora que quieran
    La autenticación basta con contraseña o par de claves, y si uno quiere puede agregar TOTP o una llave de seguridad
    Parece que se olvidaron de que también existen computadoras además del smartphone

    • La UE dice que va a crear un sistema de pagos independiente de VISA y MasterCard, pero al final sigue habiendo dependencia de las app stores
      Sin una cuenta de Apple o Google, ni siquiera se podrá pagar con el euro digital
      Sorprende que políticos y bancos no sean capaces de mirar dos o tres pasos hacia adelante
    • La política de la UE no va hacia una “evaluación autónoma del riesgo por parte del usuario”,
      sino hacia que el proveedor del servicio debe proteger al usuario
      Como resultado, la limitación de plataformas compatibles se vuelve inevitable
    • Decir que “debe funcionar en cualquier computadora” tampoco es realista
      Legalmente no significa que tenga que correr en una Apple II

  • Las personas sancionadas o ciertos grupos no pueden acceder a Play Store,
    por lo que quizá ni siquiera podrían instalar la app de eIDAS

    • Si hace falta una cuenta, entonces sí.
      Viendo los recientes casos de eliminación de cuentas de opositores políticos, para algunas autoridades incluso podría ser conveniente
    • Pero la protección de la clave privada es lo central
      Hace falta un dispositivo seguro como una smart card, así que un entorno completamente abierto es riesgoso
      Entiendo querer usar un “Android alternativo”, pero hay que saber que es un entorno no seguro

  • Me pregunto cuánto presupuesto desperdiciará la UE en este sistema
    No tengo claro quién necesita realmente algo así

  • Solo la Self Sovereign Identity (SSI) es la verdadera solución
    La identidad de una persona no debería quedar subordinada a una institución o empresa
    La identidad debería ser simplemente ‘yo mismo’
    No Google ID ni Apple ID, sino una identidad autosoberana

    • Pero “yo solo soy yo” no es una verificación de identidad realista
      No puedes decir eso en un bar en lugar de mostrar una identificación
      Dentro del contrato social, hace falta una verificación funcional de identidad
    • La UE ya creó en 2019 el ESSIF (European Self-Sovereign Identity Framework)
      La infraestructura existe desde hace 7 años, así que no se puede decir únicamente que el gobierno sea incompetente

  • Parece que ya va siendo hora de un “incendio digital del Reichstag”
    Dan ganas de preguntar cuándo dejará Alemania de repetir la historia