MiReal.me MiReal.me – Tu blog tecnológico con la más actualizada información
Publicado por Max Bires, ingeniero de software
La atestación como característica es obligatoria desde Android 8.0. A medida que los lanzamientos han ido y venido, se ha vuelto cada vez más crítico confiar en una variedad de funciones y servicios como SafetyNet, Identity Credential, Digital Car Key y una variedad de bibliotecas de terceros. A la luz de esto, ha llegado el momento de revisar nuestra infraestructura de atestación para fortalecer la seguridad de nuestra cadena de confianza y aumentar la capacidad de recuperación de la confiabilidad del dispositivo en caso de vulnerabilidades conocidas.
A partir de Android 12.0, brindaremos una opción para reemplazar el aprovisionamiento de clave privada de fábrica con una combinación de clave pública de fábrica. extracción y suministro de certificados por aire con certificados a corto plazo. Este esquema será obligatorio en Android 13.0. A este nuevo esquema lo llamamos aprovisionamiento remoto de claves.
¿A quién impacta esto?
OEM/ODM
Los fabricantes de dispositivos ya no proporcionarán claves de atestación privadas directamente a los dispositivos en la fábrica, eliminando la carga de tener que administrar los secretos de fábrica para la atestación.
Confianza, potencialmente
Como se describe a continuación, el formato, los algoritmos y la longitud de la cadena de certificados en un certificado cambiarán. Si una parte de confianza ha configurado su código de validación de certificado para que se ajuste muy estrictamente a su estructura de cadena de certificados heredada, será necesario actualizar este código.
¿Por qué cambiar?
Los dos principales motivadores para cambiar la forma en que entregamos certificados de atestación a los dispositivos son permitir que los dispositivos se recuperen después de un compromiso y fortalecer la cadena de suministro de atestación. En el esquema de atestación actual, si se descubre que un modelo de dispositivo está comprometido de una manera que afecta la señal de confianza de una atestación o si una clave se filtra a través de un mecanismo, la clave debe revocarse. Debido al creciente número de servicios que dependen de la señal de clave de atestación, esto puede tener un gran impacto en el consumidor cuyo dispositivo se ve afectado.
Este cambio nos permite detener el aprovisionamiento en dispositivos que usan software comprometido conocido y eliminar el riesgo de pérdida de clave no intencional. Esto ayudará en gran medida a reducir la posibilidad de interrupción del servicio para el usuario.
¿Como funciona?
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 el aprovisionamiento posterior. La clave privada nunca sale del entorno seguro en el que se genera.
Cuando se desempaqueta un dispositivo y se conecta a Internet, generará una solicitud de firma de certificado para las claves que ha generado, firmándolo con la clave privada que coincide con la clave pública recopilada de fábrica. Los servidores backend verificarán la autenticidad de la solicitud y luego firmarán las claves públicas, devolviendo las cadenas de certificados. Luego, Keystore almacenará estas cadenas de certificados y las asignará a las aplicaciones cada vez que se solicite un reclamo.
Este flujo se producirá periódicamente cuando caduquen los certificados o cuando se agote el suministro actual de claves. El esquema preserva la privacidad ya que cada aplicación recibe una clave de atestación diferente y las claves mismas se 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 atestación adjuntas. Esto significa que no es posible que Google relacione las claves de atestación con un dispositivo en particular que las solicitó.
¿Qué está cambiando desde un punto de vista técnico?
Los usuarios finales no notarán ningún cambio. Los desarrolladores que aprovechen el reclamo querrán prestar atención a los siguientes cambios:
- 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.
- Revocación del certificado RSA
- Todas las claves generadas y certificadas por KeyMint estarán firmadas con una clave ECDSA y la cadena de certificados correspondiente. Anteriormente, las claves asimétricas estaban firmadas por su correspondiente algoritmo.
- Certificados a corto plazo y claves de atestación
- Los certificados proporcionados a los dispositivos generalmente tendrán una validez de hasta dos meses antes del vencimiento y la rotación.
