El aprovisionamiento de clave remota de Google será obligatorio en Android 13, pero es un tema complicado. Esto es lo que eso significará para usted.
La certificación de claves de Android es la columna vertebral de muchos servicios confiables en nuestros teléfonos inteligentes, incluidos SafetyNet, Digital Car Key y la API de credenciales de identidad. Se requiere como parte de Android desde Android 8 Oreo y dependía de una clave raíz instalada en un dispositivo de fábrica. El suministro de estas claves requería el máximo secreto por parte del fabricante, y si se filtraba una clave, eso significaría que sería necesario revocarla. Esto daría como resultado que un consumidor no pudiera utilizar ninguno de estos servicios confiables, lo que sería desafortunado si alguna vez hubiera una vulnerabilidad que pudiera exponerlo. Aprovisionamiento remoto de claves, que será obligatorio en androide 13, pretende solucionar ese problema.
Los componentes que componen la actual cadena de confianza en Android
Antes de explicar cómo funciona el nuevo sistema, es importante brindar contexto sobre cómo funciona el nuevo sistema. viejo (y todavía está vigente para muchos dispositivos) el sistema funciona. Hoy en día, muchos teléfonos utilizan certificación de clave respaldada por hardware, que quizás le resulte familiar como el clavo en el ataúd para cualquier tipo de omisión de SafetyNet. Hay varios conceptos que es importante comprender para el estado actual de la atestación de claves.
Es una combinación de estos conceptos lo que garantiza que un desarrollador pueda confiar en que un dispositivo no ha sido manipulado y que pueda manejar información confidencial en el TEE.
Entorno de ejecución confiable
Un entorno de ejecución confiable (TEE) es una región segura en el SoC que se utiliza para manejar datos críticos. TEE es obligatorio en dispositivos lanzados con Android 8 Oreo y superior, lo que significa que cualquier smartphone reciente lo tiene. Todo lo que no esté dentro del TEE se considera "no confiable" y solo puede ver contenido cifrado. Por ejemplo, el contenido protegido por DRM se cifra con claves a las que solo se puede acceder mediante el software que se ejecuta en el TEE. El procesador principal solo puede ver un flujo de contenido cifrado, mientras que el TEE puede descifrar el contenido y luego mostrarlo al usuario.
Zona de confianza ARM
Trusty es un sistema operativo seguro que proporciona un TEE en Android y, en sistemas ARM, utiliza Trustzone de ARM. Trusty se ejecuta en el mismo procesador que el sistema operativo principal y tiene acceso a toda la potencia del dispositivo, pero está completamente aislado del resto del teléfono. Trusty consta de lo siguiente:
- Un pequeño núcleo del sistema operativo derivado de pequeño núcleo
- Un controlador del kernel de Linux para transferir datos entre el entorno seguro y Android
- Una biblioteca de espacio de usuario de Android para comunicarse con aplicaciones confiables (es decir, tareas/servicios seguros) a través del controlador del kernel.
La ventaja que tiene sobre los sistemas TEE propietarios es que esos sistemas TEE pueden ser costosos y también crear inestabilidad en el ecosistema de Android. Google proporciona Trusty a los OEM asociados de forma gratuita y es de código abierto. Android es compatible con otros sistemas TEE, pero Trusty es el que Google impulsa más.
Caja fuerte
Los dispositivos StrongBox son CPU seguras completamente independientes, diseñadas específicamente y certificadas. Estos pueden incluir elementos seguros integrados (eSE) o una unidad de procesamiento seguro (SPU) en SoC. Google dice que actualmente se "recomienda encarecidamente" que StrongBox venga con dispositivos que se inician con androide 12 (según el Documento de definición de compatibilidad), ya que es probable que se convierta en un requisito en una futura versión de Android. Es esencialmente una implementación más estricta de un almacén de claves respaldado por hardware y se puede implementar junto con TrustZone. Un ejemplo de implementación de StrongBox es el chip Titan M en los teléfonos inteligentes Pixel. No muchos teléfonos utilizan StrongBox y la mayoría utiliza Trustzone de ARM.
Maestro de llaves TA
Keymaster Trusted Application (TA) es el keymaster seguro que gestiona y realiza todas las operaciones del almacén de claves. Puede ejecutarse, por ejemplo, en TrustZone de ARM.
Cómo está cambiando Key Attestation con Android 12 y Android 13
Si una clave queda expuesta en un teléfono inteligente Android, Google debe revocarla. Esto plantea un problema para cualquier dispositivo que tenga una clave inyectada en fábrica: cualquier tipo de filtración que exponga la clave significaría que los usuarios no podrían acceder a cierto contenido protegido. Esto puede incluir incluso la revocación del acceso a servicios como Google Pay, algo en lo que muchas personas confían. Esto es desafortunado para los consumidores porque sin que un fabricante repare su teléfono, no habría forma de repararlo usted mismo.
Ingrese al aprovisionamiento de clave remota. A partir de Android 12, Google está reemplazando el aprovisionamiento de clave privada de fábrica con una combinación de Extracción de claves públicas en fábrica y aprovisionamiento de certificados inalámbricos con corta duración. certificados. Este esquema será necesario en Android 13 y tiene algunos beneficios. En primer lugar, evita que los OEM y ODM tengan que gestionar el secreto de claves en una fábrica. En segundo lugar, permite recuperar los dispositivos en caso de que sus claves se vean comprometidas, lo que significa que los consumidores no perderán el acceso a servicios protegidos para siempre. Ahora, en lugar de usar un certificado calculado usando una clave que está en el dispositivo y que podría filtrarse a través de un vulnerabilidad, se solicita un certificado temporal a Google cada vez que se activa un servicio que requiere certificación. usado.
En cuanto a cómo funciona, es bastante sencillo. Cada dispositivo genera un par de claves estático único, y el OEM extrae la parte pública de este par de claves en su fábrica y la envía a los servidores de Google. Allí servirán como base de confianza para el aprovisionamiento posterior. La clave privada nunca abandona el entorno seguro en el que se genera.
Cuando un dispositivo se utiliza por primera vez para conectarse a Internet, generará una solicitud de firma de certificado para claves que ha generado, firmándolo con la clave privada que corresponde a la clave pública recogida en el fábrica. Los servidores backend de Google verificarán la autenticidad de la solicitud y luego firmarán las claves públicas, devolviendo las cadenas de certificados. El almacén de claves del dispositivo almacenará estas cadenas de certificados y las asignará a las aplicaciones cada vez que se solicite una certificación. Puede ser cualquier cosa, desde Google Pay hasta Pokemon Go.
Esta cadena de solicitud de certificado exacta se producirá periódicamente tras la expiración de los certificados o el agotamiento del suministro de claves actual. Cada aplicación recibe una clave de certificación diferente y las claves se rotan periódicamente, lo que garantiza la privacidad. Además, los servidores backend de Google están segmentados de manera que el servidor que verifica la clave pública del dispositivo no ve las claves de certificación adjuntas. Esto significa que Google no puede correlacionar las claves de certificación con el dispositivo particular que las solicitó.
Los usuarios finales no notarán ningún cambio, aunque los desarrolladores deben estar atentos a lo siguiente, según Google.
- Estructura de la cadena de certificados
- Debido a la naturaleza de nuestra nueva infraestructura de aprovisionamiento en línea, la longitud de la cadena es más larga que antes y está sujeta a cambios.
- Raíz de confianza
- La raíz de confianza eventualmente se actualizará de la clave RSA actual a una clave ECDSA.
- Atestación RSA obsoleta
- Todas las claves generadas y certificadas por KeyMint se firmarán con una clave ECDSA y la cadena de certificado correspondiente. Anteriormente, las claves asimétricas estaban firmadas por su correspondiente algoritmo.
- Certificados de corta duración y claves de atestación
- Los certificados proporcionados a los dispositivos generalmente serán válidos por hasta dos meses antes de que caduquen y se roten.
Nos comunicamos con Google y le preguntamos si esto tiene alguna relevancia para Widevine DRM y cómo algunos usuarios de Pixel informaron que su nivel de DRM se había degradado con un gestor de arranque bloqueado. También preguntamos si esto se puede distribuir ahora como una actualización OTA a los usuarios a través de los servicios de Google Play. Nos aseguraremos de actualizar este artículo si recibimos una respuesta. No está claro qué componentes de la actual cadena de confianza se verán afectados ni de qué manera.
Fuente: Google