Google is committed to advancing racial equity for Black communities. See how.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Verificación de arranque

El arranque verificado requiere que se verifique criptográficamente todo el código ejecutable y los datos que forman parte de la versión de Android que se arranca antes de su uso. Esto incluye el kernel (cargado desde la partición de boot ), el árbol de dispositivos (cargado desde la partición dtbo ), la partición del system , la partición del vendor , etc.

Las particiones pequeñas, como boot y dtbo , que se leen solo una vez, generalmente se verifican cargando todo el contenido en la memoria y luego calculando su hash. Este valor hash calculado se compara luego con el valor hash esperado . Si el valor no coincide, Android no se cargará. Para obtener más detalles, consulte Boot Flow .

Las particiones más grandes que no caben en la memoria (como los sistemas de archivos) pueden usar un árbol hash donde la verificación es un proceso continuo que ocurre a medida que los datos se cargan en la memoria. En este caso, el hash raíz del árbol hash se calcula durante el tiempo de ejecución y se compara con el valor de hash raíz esperado . Android incluye el controlador dm-verity para verificar particiones más grandes. Si en algún momento el hash de raíz calculado no coincide con el valor de hash de raíz esperado , los datos no se utilizan y Android entra en un estado de error. Para obtener más detalles, consulte corrupción de dm-verity .

Los hash esperados generalmente se almacenan al final o al comienzo de cada partición verificada, en una partición dedicada o en ambos. Fundamentalmente, estos hashes están firmados (directa o indirectamente) por la raíz de la confianza. Como ejemplo, la implementación de AVB admite ambos enfoques; consulte Arranque verificado de Android para obtener más detalles.

Protección contra retroceso

Incluso con un proceso de actualización completamente seguro, es posible que un exploit del kernel de Android no persistente instale manualmente una versión anterior y más vulnerable de Android, reinicie en la versión vulnerable y luego use esa versión de Android para instalar un exploit persistente. A partir de ahí, el atacante es el propietario permanente del dispositivo y puede hacer cualquier cosa, incluida la desactivación de actualizaciones.

La protección contra esta clase de ataques se llama Rollback Protection . La protección contra la reversión se implementa normalmente mediante el uso de almacenamiento a prueba de manipulaciones para registrar la versión más reciente de Android y negarse a iniciar Android si es inferior a la versión registrada. Normalmente, las versiones se rastrean por partición.

Para obtener más detalles sobre cómo AVB maneja las protecciones de reversión, consulte AVB README .

Manejo de errores de verificación

La verificación puede fallar en el momento del arranque (por ejemplo, si el hash calculado en la partición de boot no coincide con el hash esperado) o en el tiempo de ejecución (por ejemplo, si dm-verity encuentra un error de verificación en la partición del system ). Si la verificación falla en el momento del inicio, el dispositivo no puede iniciarse y el usuario final debe seguir los pasos para recuperar el dispositivo.

Si la verificación falla en tiempo de ejecución, el flujo es un poco más complicado. Si el dispositivo usa dm-verity, debe configurarse en modo restart . En el modo de restart , si se encuentra un error de verificación, el dispositivo se reinicia inmediatamente con un indicador específico configurado para indicar el motivo. El cargador de arranque debería notar este indicador y cambiar dm-verity para usar el modo de error de E / S ( eio ) y permanecer en este modo hasta que se haya instalado una nueva actualización.

Al arrancar en modo eio , el dispositivo muestra una pantalla de error que informa al usuario que se han detectado daños y que es posible que el dispositivo no funcione correctamente. La pantalla se muestra hasta que el usuario la descarta. En el modo eio , el controlador dm-verity no reiniciará el dispositivo si se encuentra un error de verificación, sino que se devuelve un error EIO y la aplicación debe solucionarlo.

La intención es que se ejecute el actualizador del sistema (de modo que se pueda instalar un nuevo sistema operativo sin errores de corrupción) o que el usuario pueda obtener la mayor cantidad de datos posible del dispositivo. Una vez que se ha instalado el nuevo sistema operativo, el cargador de arranque detecta el sistema operativo recién instalado y vuelve al modo de restart .