El arranque verificado requiere la verificación criptográfica de todo el código ejecutable y los datos que forman parte de la versión de Android que se está arrancando antes de usarla. Esto incluye el núcleo (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 Flujo de arranque .
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 usan y Android ingresa en un estado de error. Para obtener más detalles, consulte Corrupción de dm-verity .
Los valores hash esperados generalmente se almacenan al final o al principio de cada partición verificada, en una partición dedicada o en ambos. Fundamentalmente, estos hashes están firmados (ya sea directa o indirectamente) por la raíz de la confianza. Como ejemplo, la implementación de AVB es compatible con ambos enfoques; consulte Arranque verificado de Android para obtener más detalles.
protección contra reversión
Incluso con un proceso de actualización completamente seguro, es posible que un kernel de Android no persistente instale manualmente una versión más antigua y 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 posee permanentemente el dispositivo y puede hacer cualquier cosa, incluso deshabilitar las actualizaciones.
La protección contra esta clase de ataques se llama Rollback Protection . La protección de reversión generalmente se implementa 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 anterior a la versión registrada. Las versiones normalmente 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 arranque, el dispositivo no puede arrancar 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 de restart . En el modo de restart , si se encuentra un error de verificación, el dispositivo se reinicia inmediatamente con un indicador específico establecido para indicar el motivo. El cargador de arranque debe 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 instale una nueva actualización.
Al arrancar en modo eio , el dispositivo muestra una pantalla de error que informa al usuario que se ha detectado corrupción 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; en su lugar, se devuelve un error EIO y la aplicación debe solucionar el error.
La intención es que se ejecute el actualizador del sistema (para que se pueda instalar un nuevo sistema operativo sin errores de corrupción) o que el usuario pueda obtener la mayor cantidad posible de datos 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 .