5.2 Auditor: atestación local/remota y qué información aporta

En GrapheneOS, la atestación de claves criptográficas desempeña un papel fundamental para garantizar la integridad del dispositivo, la procedencia del sistema operativo y el cumplimiento de las políticas de seguridad. El auditor, ya sea local o remoto, valida de forma confiable que las claves generadas y almacenadas en el módulo de seguridad (TEE o Secure Element) obedecen a las propiedades esperadas y no han sido manipuladas. A continuación, describimos en detalle los dos modos de atestación disponibles y el conjunto de datos que proporcionan.

1. Introducción a la atestación de claves

La atestación es un mecanismo criptográfico que vincula una clave generada en hardware seguro con metadatos sobre el dispositivo y su estado. Utiliza firmas digitales emitidas por la autoridad de certificación del fabricante o proveedor del SoC, garantizando que:

• La clave es legítima y fue creada en un entorno aislado.
• El sistema operativo y el arranque seguro no han sido comprometidos.
• Se cumple la política de uso de la clave (por ejemplo, no exportable, solo uso de firma).

2. Atestación local

La atestación local se realiza íntegramente en el dispositivo, sin comunicarse con servidores externos. Emplea la clave de atestación primaria almacenada en el TEE y devuelve un certificado X.509 firmado internamente.

• Procedimiento:
  1. Generación de la clave con KeyGenParameterSpec indicando setAttestationChallenge().
  2. El TEE responde con un chain de certificados que incluye la atestación.
  3. El auditor local valida la firma y extrae los metadatos.
• Ventajas:
  • No requiere conexión de red.
  • Respuesta inmediata para comprobaciones offline.
• Limitaciones:
  • El certificado raíz de atestación debe estar preinstalado.
  • Menor flexibilidad para revocación o actualización de CA.

3. Atestación remota

La atestación remota involucra un servidor de confianza (puede ser Google, GrapheneOS o un servicio privado) que valida el certificado entregado por el dispositivo y genera un informe adicional firmado.

• Procedimiento:
  1. El dispositivo solicita la atestación local y recibe el certificado X.509.
  2. El certificado se envía al servidor remoto junto con un nonce para prevenir ataques de repetición.
  3. El servidor comprueba la cadena de confianza, el estado de revocación y devuelve un token JWT firmado con metadatos aprobados.
• Ventajas:
  • Control centralizado de revocaciones y actualizaciones de CA.
  • Historial y auditoría de solicitudes.
  • Validación cruzada de políticas organizativas.
• Limitaciones:
  • Necesita conectividad.
  • Introducción de latencia y posibles puntos de fallo externos.

4. Información aportada por la atestación

Tanto en el modo local como en el remoto, la atestación proporciona un conjunto detallado de atributos que permiten al auditor evaluar el nivel de confianza:

Con estos metadatos, el auditor puede concluir si el dispositivo cumple las políticas de seguridad definidas y si la clave es fiable para usos críticos (autenticación, firma de documentos, intercambio cifrado, etc.).

Casos de uso típicos

• Autenticación fuerte para acceso a sistemas corporativos.
• Firma de transacciones financieras con garantías hardware-backed.
• Validación de integridad en procesos de DevSecOps.

Consideraciones finales

La combinación de atestación local y remota en GrapheneOS proporciona flexibilidad y robustez. Un auditor avanzado debe conocer los detalles de cada modo, entender cómo interpretar los metadatos y configurar adecuadamente tanto el TEE como el servidor de atestación remota para adaptarse a requisitos de seguridad y privacidad.