Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.
Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Reanudar-Reinicio

Cuando se descarga una OTA y se prepara para su aplicación a través de una actualización A / B , A / B virtual u otro método disponible a través de la clase RecoverySystem , Resume-on-Reboot intentará desbloquear el almacenamiento Credential Encrypted (CE) después de que el dispositivo se reinicie para aplicar la OTA. Esto se puede combinar con un sistema OTA que aplica actualizaciones cuando es más conveniente para el usuario, como cuando se espera que el dispositivo esté inactivo.

Antecedentes

Para los desarrolladores de aplicaciones, Android es compatible con el arranque directo, que permite que las aplicaciones se inicien antes de que el usuario desbloquee el almacenamiento con credenciales cifradas (CE). A medida que más desarrolladores de aplicaciones implementan el soporte de arranque directo, el usuario tiene una mejor experiencia antes de ingresar su factor de conocimiento de pantalla de bloqueo (LSKF) después de un arranque.

Resume-on-Reboot permite desbloquear el almacenamiento CE de todas las aplicaciones, incluidas aquellas que aún no son compatibles con Direct Boot, después de un reinicio iniciado por una OTA. Esta función permite a los usuarios recibir notificaciones de todas sus aplicaciones instaladas después del reinicio.

Modelo de amenaza

Una implementación de Resume-on-Reboot debe preservar la propiedad de que cuando un dispositivo cae en manos de un atacante, es extremadamente difícil para ese atacante recuperar los datos cifrados con CE del usuario, incluso si el dispositivo está encendido, el almacenamiento CE está desbloqueado y el usuario ha desbloqueado el dispositivo después de recibir una OTA; para la resistencia a ataques internos, también asumimos que el atacante obtiene acceso para transmitir claves de firma criptográficas.

Específicamente, requerimos que el almacenamiento CE no pueda ser leído por un atacante que tenga físicamente el dispositivo y luego tenga estas capacidades y limitaciones:

  • Puede utilizar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
  • Puede hacer que el dispositivo reciba una OTA.
  • Puede modificar el funcionamiento de cualquier hardware (procesador de aplicaciones, flash, etc.) excepto como se detalla a continuación, pero dicha modificación implica un retraso de al menos una hora y un ciclo de energía que destruye el contenido de la RAM.
  • No se puede modificar el funcionamiento de hardware a prueba de manipulaciones (por ejemplo, Titan M).
  • No se puede leer la RAM del dispositivo en vivo.
  • No puede adivinar la credencial del usuario (PIN, patrón, contraseña) o hacer que se ingrese.

Directrices para el implementador

A partir de julio de 2020, las implementaciones de Resume-on-Reboot HAL se dividen en dos categorías:

  1. Si el hardware de SoC admite la persistencia de RAM en los reinicios, los OEM pueden utilizar la implementación predeterminada en AOSP (depósito de seguridad de RAM predeterminado).
  2. Si el hardware del dispositivo o SoC admite un enclave de hardware seguro (un coprocesador de seguridad discreto con su propia RAM y ROM), además debe:
    • Ser capaz de detectar el reinicio de la CPU principal.
    • Tener una fuente de temporizador de hardware que persista durante los reinicios; es decir, el enclave debe poder detectar el reinicio y caducar un temporizador establecido antes del reinicio.
    • Admite el almacenamiento de una clave en custodia en la RAM / ROM del enclave de modo que no se pueda recuperar con ataques fuera de línea. Debe almacenar la clave Resume-on-Reboot de manera que sea imposible para los internos o atacantes recuperarla.

Depósito de RAM predeterminado

AOSP tiene una implementación de Resume-on-Reboot HAL usando persistencia de RAM. Para que esto funcione, los OEM deben asegurarse de que sus SoC admitan la persistencia de RAM en los reinicios. Algunos SoC no pueden conservar el contenido de RAM durante un reinicio, por lo que se recomienda a los OEM que consulten a sus socios de SoC antes de habilitar esta HAL predeterminada. La referencia canónica para esto en la sección siguiente.

Cuando se descarga una OTA y se prepara para su aplicación mediante una actualización A / B , A / B virtual u otro método disponible a través de la clase RecoverySystem , Resume-on-Reboot intentará desbloquear el almacenamiento Credential Encrypted (CE) después del dispositivo. se reinicia para aplicar la actualización OTA. Esto se puede combinar con un sistema OTA que aplica actualizaciones cuando es más conveniente para el usuario, como cuando se espera que el dispositivo esté inactivo.

Flujo de actualización de OTA usando Resume-on-Reboot

La aplicación del cliente OTA en el teléfono debe tener los permisos Manifest.permission.REBOOT y Manifest.permisson.RECOVERY para llamar a los métodos necesarios para implementar Resume-on-Reboot. Con ese requisito previo en su lugar, el flujo de una actualización es:

  1. Actualización de descargas de la aplicación cliente OTA
  2. La aplicación cliente OTA llama a RecoverySystem#prepareForUnattendedUpdate que RecoverySystem#prepareForUnattendedUpdate que se le solicite al usuario su PIN, patrón o contraseña en la pantalla de bloqueo durante el próximo desbloqueo
  3. La próxima vez que el usuario desbloquee el dispositivo en la pantalla de bloqueo, el dispositivo estará listo para que se aplique la actualización.
  4. La aplicación cliente OTA llama a RecoverySystem#rebootAndApply que activa inmediatamente un reinicio

Al final de este flujo, el dispositivo se reinicia y el mecanismo de reanudación al reiniciar desbloquea el almacenamiento de credenciales cifradas (CE). Para las aplicaciones, esto aparece como un desbloqueo de usuario normal, por lo que reciben todas las señales, como ACTION_LOCKED_BOOT_COMPLETED y ACTION_BOOT_COMPLETED como lo harían normalmente.

Modificar configuraciones de productos

Para que un producto se marque como compatible con la función Reanudar al reiniciar, debe incluir una implementación de RebootEscrow HAL e incluir el archivo XML de marcador de función. La implementación predeterminada funciona bien en dispositivos que usan reinicio en caliente (es decir, no se quita energía de la DRAM durante el reinicio).

Reiniciar marcador de función de custodia

El marcador de características también debe estar presente:

PRODUCT_COPY_FILES += \
    frameworks/native/data/etc/android.hardware.reboot_escrow.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.reboot_escrow.xml

Implementación predeterminada de HAL de custodia de reinicio

Para utilizar la implementación predeterminada, se deben reservar 65536 (0x10000) bytes para la implementación. Estos bytes no deben escribirse en un almacenamiento no volátil para que se mantengan las propiedades de seguridad.

Cambios en el árbol de dispositivos del kernel de Linux

En el árbol de dispositivos del kernel de Linux, debe reservar memoria para una región pmem . En el siguiente ejemplo se ha reservado 0x50000000 :

  reserved-memory {
    my_reservation@0x50000000 {
      no-map;
      reg = <0x50000000 0x10000>;
    }
  }

  reboot_escrow@0 {
    compatible = "pmem-region";
    reg = <0x50000000 0x10000>;
  };

Verifique que tenga un nuevo dispositivo en el directorio de bloques con un nombre como /dev/block/pmem0 (como pmem1 o pmem2 ).

Cambios en Device.mk

Suponiendo que su nuevo dispositivo del paso anterior se llame pmem0 , las siguientes nuevas entradas deben agregarse a vendor/<oem>/<product>/device.mk :

# Resume on Reboot support
PRODUCT_PROPERTY_OVERRIDES += \
    ro.rebootescrow.device=/dev/block/pmem0
PRODUCT_PACKAGES += \
    android.hardware.rebootescrow-service.default

Reglas de SELinux

file_contexts deben agregar nuevas entradas a los file_contexts del dispositivo:

/dev/block/pmem0  u:object_r:rebootescrow_device:s0
/vendor/bin/hw/android\.hardware\.rebootescrow-service\.default  u:object_r:hal_rebootescrow_default_exec:s0