Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Reanudar al reiniciar

Cuando un OTA es descargado y preparado para ser aplicada a través de actualización A / B , virtual A / B , o cualquier otro método disponible a través de clase RecoverySystem , Resume-on-Reboot intentará desbloquear el almacenamiento de credenciales cifrados (CE) después de que se reinicie el dispositivo a 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.

Fondo

Para los desarrolladores de aplicaciones, Android apoya directa de arranque que permite a las aplicaciones para poner en marcha antes de la (CE) Almacenamiento de credenciales cifrados está desbloqueado por el usuario. A medida que más desarrolladores de aplicaciones implementan el soporte de arranque directo, el usuario tiene una mejor experiencia antes de que se ingrese su factor de conocimiento de la 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 físicamente tiene el dispositivo y luego tiene 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 usar 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 un OTA es descargado y preparado para ser aplicada por medio de una actualización / B , virtual A / B , o cualquier otro método disponible a través de clase RecoverySystem , Resume-on-Reboot intentará desbloquear el almacenamiento de credenciales cifrados (CE) después de que el 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 cliente OTA en el teléfono debe tener los Manifest.permission.REBOOT y Manifest.permisson.RECOVERY permisos para llamar a los métodos necesarios para aplicar reanudación tras reiniciar. 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. OTA de aplicaciones cliente de llamadas a RecoverySystem#prepareForUnattendedUpdate que provoca que el usuario se solicitara la PIN, el patrón o la 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. OTA de aplicaciones cliente de llamadas a RecoverySystem#rebootAndApply que provoca inmediatamente un reinicio

Al final de este flujo, el dispositivo se reinicia y el mecanismo de reanudación al reiniciar desbloquea el almacenamiento encriptado con credenciales (CE). Para aplicaciones, esto aparece como un desbloqueo de usuario normal, por lo que reciben todas las señales, tales 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 depósito en garantía

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 árbol de dispositivos del núcleo de Linux, debe reservar memoria para un pmem región. En el siguiente ejemplo 0x50000000 se ha reservado:

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

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

Compruebe que tiene un nuevo dispositivo en el directorio de módulos con un nombre como /dev/block/pmem0 (como pmem1 o pmem2 ).

Cambios en Device.mk

Suponiendo que el nuevo dispositivo de la etapa anterior se denomina pmem0 , las nuevas entradas siguientes 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

Las nuevas entradas a del dispositivo file_contexts hay que añadir:

/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