Blog de desarrolladores de Android: Actualización de la atestación de Android: implementación remota

Publicado por Max Bires, ingeniero de software

La autenticación como característica ha sido obligatoria desde Android 8.0. A medida que iban y venían los lanzamientos, se volvió cada vez más importante confiar en una variedad de funciones y servicios como SafetyNet, Identity Credential, Digital Car Key y una variedad de bibliotecas de terceros. Con esto en mente, es hora de repensar nuestra infraestructura de atestación para aumentar la seguridad de nuestra cadena de confianza y aumentar la capacidad de recuperación de la confianza del dispositivo en caso de vulnerabilidades conocidas.

A partir de Android 12.0, ofrecemos una opción para reemplazar las claves privadas proporcionadas de fábrica con una combinación de claves públicas proporcionadas de fábrica. extracción y entrega de certificados por aire con certificados de corta duración. Este esquema será obligatorio en Android 13.0. A este nuevo esquema lo llamamos aprovisionamiento remoto de claves.

¿A quién afecta esto?

OEM/ODM

Los fabricantes de dispositivos ya no proporcionan claves privadas de atestación directamente a los dispositivos en la fábrica, lo que elimina la carga de administrar los secretos en la fábrica para la atestación.

Partes que confían, potencialmente

Como se describe a continuación, el formato, los algoritmos y la longitud de la cadena de certificados cambian en una atestación. Si una parte de confianza tiene su código de validación de certificado configurado para que coincida con la estructura de la cadena de certificados anterior, ese código debe actualizarse.

¿Por qué cambiar?

Los dos impulsores clave para cambiar la forma en que proporcionamos certificados notariales para dispositivos son la capacidad de recuperar dispositivos después de una infracción y la optimización de la cadena de suministro de atestación. En el sistema de notarización actual, si se determina que un modelo de dispositivo está comprometido de una manera que compromete la señal de confianza de una certificación notarial, o si una clave está comprometida a través de algún mecanismo, la clave debe revocarse. Con el número cada vez mayor de servicios que dependen de la señal de la clave de autenticación, esto puede tener un gran impacto en el consumidor cuyo dispositivo se ve afectado.

Este cambio nos permite detener el aprovisionamiento de dispositivos con software comprometido conocido y eliminar la posibilidad de filtraciones accidentales de claves. Esto contribuye en gran medida a reducir el potencial de interrupciones del servicio para el usuario.

¿Como funciona esto?

Cada dispositivo genera un par de claves estáticas y únicas, y el OEM extrae la parte pública de este par de claves en su fábrica. Estas claves públicas luego se cargan en los servidores de Google, donde sirven como base de confianza para una implementación posterior. La clave privada nunca sale del entorno seguro en el que se genera.

Cuando un dispositivo se desempaqueta y se conecta a Internet, genera una solicitud de firma de certificado para las claves que generó y las firma con la clave privada que coincide con la clave pública recolectada en la fábrica. Los servidores back-end verifican la autenticidad de la solicitud y luego firman las claves públicas y devuelven las cadenas de certificados. Luego, Keystore almacena estas cadenas de certificados y las asigna a las aplicaciones cuando se solicita la certificación notarial.

Este flujo ocurre regularmente después de que los certificados caducan o se agota el conjunto de claves actual. El esquema preserva la privacidad ya que cada aplicación obtiene una clave de autenticación diferente y las claves rotan regularmente. Además, los servidores back-end de Google están segmentados de tal manera que el servidor que verifica la clave pública del dispositivo no ve las claves de autenticación adjuntas. Esto significa que Google no puede correlacionar las claves de autenticación con un dispositivo específico que las solicitó.

¿Qué está cambiando técnicamente?

Los usuarios finales no notarán ningún cambio. Los desarrolladores que utilizan la atestación deben tener en cuenta los siguientes cambios:

• Estructura de la cadena de certificados
  • Debido a la naturaleza de nuestra nueva infraestructura de entrega 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 finalmente se actualiza de la clave RSA actual a una clave ECDSA.
• Interrupción de la atestación RSA
  • Todas las claves generadas y verificadas por KeyMint están firmadas con una clave ECDSA y la cadena de certificados correspondiente. Anteriormente, las claves asimétricas estaban firmadas por su correspondiente algoritmo.
• Certificados de corta duración y claves de autenticación
  • Los certificados implementados en dispositivos generalmente son válidos hasta por dos meses antes de caducar y rotar.