Reanudar en reinicio

En Android 11, se pueden aplicar actualizaciones inalámbricas con la actualización A/B. o de actualización A/B virtual, combinados con RecoverySystem: de clase 3D. Después de que un dispositivo se reinicia para aplicar una actualización OTA, La reanudación en el reinicio (RoR) desbloquea el almacenamiento de credenciales encriptadas (CE) del dispositivo.

Aunque los socios pueden vincular este proceso con una función del sistema inalámbrico que se aplique actualizaciones cuando se espera que el dispositivo esté inactivo en Android 11, en Los socios de Android 12 no necesitan un sistema inalámbrico adicional . El proceso de RoR brinda mayor seguridad y conveniencia a los usuarios, ya que las actualizaciones se pueden realizar durante los tiempos de inactividad del dispositivo, mientras que Android 12 de actualización de varios clientes y basadas en el servidor proporcionan a nivel de hardware.

Sin embargo, debes otorgar permiso de dispositivo para el android.hardware.reboot_escrow. para admitir RoR en Android 11, no necesitas hacerlo para habilitar RoR basado en servidor en Android 12 y versiones posteriores, porque no uses el HAL.

Información general

A partir de Android 7, Android admite el inicio directo, que permite que las apps de un dispositivo se inicien antes de que el almacenamiento CE se desbloquee del usuario. La implementación de la compatibilidad con el inicio directo les brindó a los usuarios una mejor experiencia antes de ingresar el Factor de conocimiento de la pantalla de bloqueo (LSKF) después de un inicio.

RoR permite desbloquear el almacenamiento CE de todas las apps de un dispositivo, lo que incluye aquellas que no admiten el inicio directo, cuando se inicia un reinicio después de una actualización OTA. Esta función permite que los usuarios reciban notificaciones de todos sus las apps instaladas, después del reinicio.

Modelo de amenazas

Una implementación de RoR debe garantizar que cuando un dispositivo entre en el las manos, es muy difícil para el atacante recuperar el CE- datos encriptados, incluso si el dispositivo está encendido, el almacenamiento CE está desbloqueado y El usuario desbloquea el dispositivo después de recibir una actualización inalámbrica. Usuario con información privilegiada la resistencia a los ataques debe ser eficaz aun si el atacante consigue acceso al transmitir claves criptográficas de firma.

Específicamente, no debe leer el almacenamiento CE si un atacante con el dispositivo y cuenta con las siguientes capacidades y limitaciones:

Funciones

  • Se puede usar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
  • Puede hacer que el dispositivo reciba una actualización inalámbrica.
  • Pueden modificar el funcionamiento de cualquier hardware (como un procesador de aplicaciones, o memoria flash), salvo que se indique en la sección Limitaciones más adelante. (Sin embargo, dicha modificación implica un retraso de, al menos, una hora y un que destruye el contenido de la RAM).

Limitaciones

  • No se puede modificar el funcionamiento del hardware resistente a alteraciones (por ejemplo, un Titan M).
  • No se puede leer la RAM del dispositivo activo.
  • No puede adivinar las credenciales del usuario (PIN, patrón, contraseña) ni generar ningún otro tipo de causa. que se deben ingresar.

Solución

El sistema de actualización RoR de Android 12 brinda seguridad contra atacantes muy sofisticados, y lo hace mientras las contraseñas del dispositivo y Los PIN permanecen en el dispositivo; nunca se envían a los servidores de Google ni se almacenan en ellos. Esta es una descripción general del proceso que garantiza que los niveles de seguridad proporcionados sean similar a un sistema RoR a nivel del dispositivo basado en hardware:

  • Android aplica protecciones criptográficas a los datos almacenados en un dispositivo.
  • Todos los datos están protegidos por claves almacenadas en el entorno de ejecución confiable. (TEE).
  • El TEE solo libera las claves si el sistema operativo en ejecución pasa autenticación criptográfica (inicio verificado)
  • El servicio de RoR que se ejecuta en los servidores de Google protege los datos de CE mediante el almacenamiento de un que se puede recuperar solo por tiempo limitado. Esto funciona en todo el ecosistema de Android.
  • Se usa una clave criptográfica, protegida por el PIN de un usuario, para desbloquear el dispositivo. y desencriptar el almacenamiento CE.
    • Cuando se programa un reinicio nocturno, Android le solicita al usuario que ingrese su PIN y, luego, calcula una contraseña sintética (SP).
    • Luego, encripta el PS dos veces: una con una clave K_s almacenada en la RAM y otra vez con una clave K_k almacenada en TEE.
    • El SP con doble encriptación se almacena en el disco, y el SP se limpia de la RAM. Ambas claves se generaron de nuevo y se usan solo un reinicio.
  • Cuando es el momento de reiniciar, Android confía K_s al servidor. El recibo con K_k se encripta antes de almacenarse en el disco.
  • Después del reinicio, Android usa K_k para desencriptar el recibo y lo envía a que el servidor recupere K_s.
    • K_k y K_s se usan para desencriptar el PS almacenado en el disco.
    • Android usa el SP para desbloquear el almacenamiento de CE y permitir el inicio normal de la app.
    • Se descartan K_k y K_s.

Las actualizaciones que protegen tu teléfono pueden realizarse en el momento que te resulte conveniente para ti: mientras duermes.

Reproducción del PIN de la SIM

Bajo ciertas condiciones, el código PIN de una tarjeta SIM se verifica desde una memoria caché. un proceso llamado reproducción del PIN de la SIM.

Una tarjeta SIM con un PIN habilitado también debe pasar por un código PIN sin inconvenientes. verificación (reproducción del PIN de la SIM) después de un reinicio sin supervisión para restablecer la red móvil conectividad (obligatoria para llamadas telefónicas, mensajes SMS y servicios de datos). El PIN de la SIM y la información de la tarjeta SIM correspondiente (el ICCID y la ranura de SIM número) se almacenan juntas de forma segura. El PIN almacenado se puede recuperar y usar. para la verificación, únicamente después de un reinicio sin supervisión exitoso. Si el dispositivo es seguro, el PIN de la SIM se almacena con claves protegidas por el LSKF. Si la SIM tiene su PIN habilitado, la interacción con el servidor RoR requiere una conexión Wi-Fi para la actualización OTA y el RoR basado en el servidor, lo que garantiza una funcionalidad básica (con conectividad móvil) después del reinicio.

El PIN de la SIM se vuelve a encriptar y se almacena cada vez que el usuario lo habilita correctamente. lo verifica o lo modifica. El PIN de la SIM se descarta si se cumple alguna de las siguientes condiciones: ocurre lo siguiente:

  • Se quitará o restablecerá la SIM.
  • El usuario inhabilita el PIN.
  • Se produjo un reinicio no iniciado por RoR.

El PIN de la SIM almacenado solo se puede usar una vez después del reinicio iniciado por RoR. solo por un período muy breve (20 segundos), si los detalles de la SIM coincidencia de cartas. El PIN de la SIM almacenado nunca sale de la app de TelephonyManager y y los módulos externos no pueden recuperarla.

Lineamientos de implementación

En Android 12, la RoR de varios clientes y basada en el servidor proporcionan una carga más ligera a los socios cuando envían actualizaciones OTA. Las actualizaciones necesarias pueden ocurrir durante los tiempos de inactividad convenientes del dispositivo, como durante horas de sueño designadas.

Para garantizar que las actualizaciones OTA durante esos períodos no interrumpan a los usuarios, y puedes usar el modo oscuro para mitigar las emisiones de luz. Para ello, haz que el dispositivo bootloader, busca el motivo de la cadena unattended. Si unattended es true, poner el dispositivo en modo oscuro. Ten en cuenta que es responsabilidad de cada OEM mitigar las emisiones de ruido y luz.

Si actualizas a Android 12 o lanzas Android 12, no necesitas hacer nada implementar la funcionalidad nueva de RoR.

Hay una llamada nueva en el flujo de varios clientes, isPreparedForUnattendedUpdate, como se muestra a continuación:

@RequiresPermission(anyOf = {android.Manifest.permission.RECOVERY,
            android.Manifest.permission.REBOOT})
public static boolean isPreparedForUnattendedUpdate(@NonNull Context context)

No es necesario que implementes esto, ya que la HAL dejó de estar disponible a partir de Android 12

TelephonyManager

El cliente inalámbrico invoca la API del sistema TelephonyManager cuando un reinicio es inminente. en Android 12. Esta API transfiere todos los códigos PIN almacenados en caché de el estado AVAILABLE al estado REBOOT_READY. El sistema de TelephonyManager La API está protegida por la REBOOT existente Permiso de manifiesto.

 /**
    * The unattended reboot was prepared successfully.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_SUCCESS = 0;

   /**
    * The unattended reboot was prepared, but the user will need to manually
    * enter the PIN code of at least one SIM card present in the device.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED = 1;

   /**
    * The unattended reboot was not prepared due to generic error.
    * @hide
    */
   @SystemApi
   public static final int PREPARE_UNATTENDED_REBOOT_ERROR = 2;

   /** @hide */
   @Retention(RetentionPolicy.SOURCE)
   @IntDef(prefix = {"PREPARE_UNATTENDED_REBOOT_"},
           value = {
                   PREPARE_UNATTENDED_REBOOT_SUCCESS,
                   PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED,
                   PREPARE_UNATTENDED_REBOOT_ERROR
           })
   public @interface PrepareUnattendedRebootResult {}

   /**
    * Prepare TelephonyManager for an unattended reboot. The reboot is
    * required to be done shortly after the API is invoked.
    *
    * Requires system privileges.
    *
    * <p>Requires Permission:
    *   {@link android.Manifest.permission#REBOOT}
    *
    * @return {@link #PREPARE_UNATTENDED_REBOOT_SUCCESS} in case of success.
    * {@link #PREPARE_UNATTENDED_REBOOT_PIN_REQUIRED} if the device contains
    * at least one SIM card for which the user needs to manually enter the PIN
    * code after the reboot. {@link #PREPARE_UNATTENDED_REBOOT_ERROR} in case
    * of error.
    * @hide
    */
   @SystemApi
   @RequiresPermission(android.Manifest.permission.REBOOT)
   @PrepareUnattendedRebootResult
   public int prepareForUnattendedReboot()

Los APK con privilegios usan la API del sistema TelephonyManager.

Prueba

Para probar la nueva API, ejecuta este comando:

    adb shell cmd phone unattended-reboot

Este comando solo funciona cuando la shell se ejecuta como raíz (adb root).

Solo para Android 11

El resto de esta página se aplica a Android 11.

A partir de julio de 2020, las implementaciones de la HAL de RoR se dividen en dos categorías:

  1. Si el hardware del SoC admite la persistencia de RAM en los reinicios, los OEM pueden usar el implementación predeterminada en AOSP (custodia predeterminada de RAM).
  2. Si el hardware del dispositivo o SoC admite un enclave de hardware seguro (un de seguridad de la nube con su propia RAM y ROM), lo siguiente:
    • Detecta el reinicio de la CPU principal.
    • Tener una fuente de temporizador de hardware que persista en los reinicios Es decir, enclave debe poder detectar el reinicio y vencer un temporizador establecido reiniciar.
    • Admitir el almacenamiento de una clave de custodia en la RAM/ROM del enclave, de modo que no pueda recuperarse con ataques sin conexión. Debe almacenar la clave RoR de forma que hace que sea imposible que los atacantes o los usuarios con información privilegiada

Custodia predeterminada de RAM

AOSP tiene una implementación de la HAL de RoR que usa persistencia de RAM. Para que esto funcione, los OEMs deben asegurarse de que sus SoC admitan persistencia RAM en los reinicios. Algunos SoC no pueden conservar el contenido de la RAM durante un reinicio. Se recomienda a los OEM que consulten a sus socios de SoC antes de habilitar esta HAL predeterminada. La referencia canónica de esto se encuentra en la siguiente sección.

Flujo de actualización OTA a través de RoR

La app cliente de OTA en el teléfono debe tener la Manifest.permission.REBOOT y Manifest.permission.RECOVERY para llamar a los métodos necesarios para implementar RoR. Con ese requisito previo establecido, el flujo de un sigue estos pasos:

  1. La app cliente OTA descarga la actualización.
  2. La app cliente OTA llama a RecoverySystem#prepareForUnattendedUpdate, que activa al usuario el mensaje de su PIN, patrón o contraseña en la la pantalla de bloqueo durante el próximo desbloqueo.
  3. El usuario desbloquea el dispositivo en la pantalla de bloqueo, y el dispositivo está listo. para que se aplique la actualización.
  4. La app cliente OTA llama a RecoverySystem#rebootAndApply, que inmediatamente activa un reinicio.

Al final de este flujo, el dispositivo se reinicia y la RoR desbloquea el almacenamiento encriptado a través de credenciales (CE). Para las apps, esto aparece como un desbloqueo normal del usuario, por lo que recibe todas las señales, ACTION_LOCKED_BOOT_COMPLETED y ACTION_BOOT_COMPLETED como lo hacen normalmente.

Modificar la configuración de los productos

Un producto marcado como compatible con la función RoR en Android 11 debe incluir un de la HAL de RestartEscrow y de incluir el archivo en formato XML del marcador de funciones. La implementación predeterminada funciona bien en dispositivos que usan reinicio semicaliente (cuando la alimentación a la DRAM permanecerá encendida durante el reinicio).

Reiniciar marcador de función de depósito

El marcador de componente 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 depósito de reinicio

Para usar la implementación predeterminada, debes reservar 65,536 (0x10,00) bytes. Nunca estos bytes en almacenamiento no volátil para garantizar que las propiedades de seguridad se mantienen.

Cambios en el árbol de dispositivos del kernel de Linux

En el árbol de dispositivos del kernel de Linux, debes reservar memoria para una región pmem. En el siguiente ejemplo, se muestra que se reserva 0x50000000:

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

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

Verifica que tengas un dispositivo nuevo en el directorio de bloques con un nombre como el siguiente: /dev/block/pmem0 (como pmem1 o pmem2)

Cambios en Device.mk

Si su nuevo dispositivo del paso anterior se llama pmem0, debes Asegúrate de que se agreguen las siguientes entradas nuevas 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

Agrega estas entradas nuevas al 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