Reanudar al reiniciar

En Android 11, las actualizaciones OTA se pueden aplicar mediante la actualización A/B o los mecanismos de actualización A/B virtual , combinados con los métodos de la clase RecoverySystem . Después de que un dispositivo se reinicia para aplicar una actualización OTA, Resume-on-Reboot (RoR) desbloquea el almacenamiento cifrado con credenciales (CE) del dispositivo.

Aunque los socios pueden vincular este proceso con una función del sistema OTA que aplica actualizaciones cuando se espera que el dispositivo esté inactivo en Android 11, en Android 12 los socios no necesitan una función del sistema OTA adicional. El proceso RoR brinda mayor seguridad y conveniencia a los usuarios porque las actualizaciones se pueden realizar durante los tiempos de inactividad del dispositivo, mientras que las funcionalidades de actualización multicliente y basada en servidor de Android 12 brindan seguridad de tipo a nivel de hardware del dispositivo.

Aunque debe proporcionar permiso del dispositivo para que la función android.hardware.reboot_escrow admita RoR en Android 11, no necesita hacerlo para habilitar RoR basado en servidor en Android 12 y versiones posteriores, porque no usan HAL.

Fondo

A partir de Android 7, Android admitía el arranque directo , que permite que las aplicaciones de un dispositivo se inicien antes de que el usuario desbloquee el almacenamiento CE. La implementación de la compatibilidad con el arranque directo brindó a los usuarios una mejor experiencia antes de que fuera necesario ingresar el factor de conocimiento de la pantalla de bloqueo (LSKF) después de un arranque.

RoR permite desbloquear el almacenamiento CE de todas las aplicaciones de un dispositivo, incluidas aquellas que no admiten el arranque directo, cuando se inicia un reinicio después de una actualización 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 RoR debe garantizar que cuando un dispositivo cae en manos de un atacante, le resulte extremadamente difícil recuperar los datos cifrados CE del usuario, incluso si el dispositivo está encendido, el almacenamiento CE está desbloqueado y el dispositivo está desbloqueado por el usuario después de recibir una actualización OTA. La resistencia a los ataques internos debe ser efectiva incluso si el atacante obtiene acceso a las claves de firma criptográfica transmitidas.

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

Capacidades

  • Puede utilizar la clave de firma de cualquier proveedor o empresa para firmar mensajes arbitrarios.
  • Puede hacer que el dispositivo reciba una actualización OTA.
  • Puede modificar el funcionamiento de cualquier hardware (como un procesador de aplicaciones o una memoria flash), excepto lo que se detalla en Limitaciones a continuación. (Sin embargo, dicha modificación implica tanto un retraso de al menos una hora como un ciclo de encendido que destruye el contenido de la RAM).

Limitaciones

  • No se puede modificar el funcionamiento del hardware resistente a manipulaciones (por ejemplo, una Titan M).
  • No se puede leer la RAM del dispositivo en vivo.
  • No se pueden adivinar las credenciales del usuario (PIN, patrón, contraseña) ni hacer que se ingresen de otro modo.

Solución

El sistema de actualización de Android 12 RoR brinda seguridad contra atacantes muy sofisticados y lo hace mientras las contraseñas y los PIN del dispositivo permanecen en el dispositivo; nunca se envían ni se almacenan en los servidores de Google. Esta es una descripción general del proceso que garantiza que los niveles de seguridad proporcionados sean similares a los de un sistema RoR a nivel de 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 la autenticación criptográfica ( arranque verificado ).
  • El servicio RoR que se ejecuta en los servidores de Google protege los datos CE almacenando un secreto que puede recuperarse sólo durante un tiempo limitado . Esto funciona en todo el ecosistema de Android.
  • Se utiliza una clave criptográfica, protegida por el PIN de un usuario, para desbloquear el dispositivo y descifrar el almacenamiento CE.
    • Cuando se programa un reinicio nocturno, Android solicita al usuario que ingrese su PIN y luego calcula una contraseña sintética (SP).
    • Luego cifra el SP dos veces: una vez con una clave K_s almacenada en la RAM y otra vez con una clave K_k almacenada en TEE.
    • El SP con doble cifrado se almacena en el disco y el SP se borra de la RAM. Ambas claves se generan recientemente y se usan para un solo reinicio .
  • Cuando llega el momento de reiniciar, Android confía K_s al servidor. El recibo con K_k se cifra antes de almacenarse en el disco.
  • Después del reinicio, Android usa K_k para descifrar el recibo y luego lo envía al servidor para recuperar K_s .
    • K_k y K_s se utilizan para descifrar el SP almacenado en el disco.
    • Android usa el SP para desbloquear el almacenamiento CE y permitir el inicio normal de la aplicación.
    • K_k y K_s se descartan.

Las actualizaciones que mantienen tu teléfono seguro pueden realizarse en el momento que más te convenga: mientras duermes.

Repetición del PIN de SIM

Bajo ciertas condiciones, el código PIN de una tarjeta SIM se verifica desde un caché, un proceso llamado repetición SIM-PIN.

Una tarjeta SIM con un PIN habilitado también debe someterse a una verificación continua del código PIN (una repetición de SIM-PIN) después de un reinicio sin supervisión para restaurar la conectividad celular (requerida 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 el número de ranura SIM) se almacenan juntos de forma segura. El PIN almacenado se puede recuperar y utilizar para verificación solo después de un reinicio exitoso y desatendido. Si el dispositivo está protegido, el PIN de la SIM se almacena con claves protegidas por LSKF. Si la SIM tiene su PIN habilitado, la interacción con el servidor RoR requiere una conexión WiFi para la actualización OTA y RoR basado en servidor, lo que garantiza una funcionalidad básica (con conectividad celular) después del reinicio.

El PIN de la SIM se vuelve a cifrar y se almacena cada vez que el usuario lo habilita, verifica o modifica con éxito. El PIN de la SIM se descarta si ocurre cualquiera de las siguientes situaciones:

  • La SIM se quita o se reinicia.
  • El usuario desactiva el PIN.
  • Se ha producido 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, y solo por un período de tiempo muy corto (20 segundos), si los detalles de la tarjeta SIM coinciden. El PIN de la SIM almacenado nunca sale de la aplicación TelephonyManager y no puede ser recuperado mediante módulos externos.

Directrices de implementación

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

Para garantizar que las actualizaciones OTA durante esos períodos de tiempo no interrumpan a los usuarios, emplee el modo oscuro para mitigar las emisiones de luz. Para hacerlo, haga que el cargador de arranque del dispositivo busque la cadena motivo unattended . Si unattended es true , ponga el dispositivo en modo oscuro. Tenga en cuenta que es responsabilidad de cada OEM mitigar las emisiones de luz y sonido.

Si está actualizando a Android 12 o iniciando dispositivos con Android 12, no necesita hacer nada para implementar la nueva funcionalidad RoR.

Hay una nueva llamada en el flujo multicliente, isPreparedForUnattendedUpdate , que 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 implementar esto, porque HAL está obsoleto a partir de Android 12.

Administrador de telefonía

El cliente OTA invoca la API del sistema TelephonyManager cuando un reinicio es inminente en Android 12. Esta API mueve todos los códigos PIN almacenados en caché del estado AVAILABLE al estado REBOOT_READY . La API del sistema TelephonyManager está protegida por el permiso REBOOT Manifest existente.

 /**
    * 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 privilegiados utilizan la API del sistema TelephonyManager.

Pruebas

Para probar la nueva API, ejecute este comando:

    adb shell cmd phone unattended-reboot

Este comando solo funciona cuando el shell se ejecuta como root ( adb root ).

Solo Android 11

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

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

  1. Si el hardware SoC admite la persistencia de RAM durante los reinicios, los OEM pueden usar la implementación predeterminada en AOSP ( Default RAM Escrow ).
  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 hacer lo siguiente:
    • Ser capaz de detectar un 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 hacer expirar un temporizador configurado 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 RoR de una manera que haga imposible que personas internas o atacantes la recuperen.

Custodia de RAM predeterminada

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

Flujo de actualización OTA usando RoR

La aplicación cliente OTA en el teléfono debe tener los permisos Manifest.permission.REBOOT y Manifest.permission.RECOVERY para llamar a los métodos necesarios para implementar RoR. Con ese requisito previo implementado, el flujo de una actualización sigue estos pasos:

  1. La aplicación cliente OTA descarga la actualización.
  2. La aplicación cliente OTA llama a RecoverySystem#prepareForUnattendedUpdate , lo que hace que se le solicite al usuario su PIN, patrón o contraseña en la pantalla de bloqueo durante el siguiente 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 aplicación cliente OTA llama a RecoverySystem#rebootAndApply , lo que desencadena inmediatamente un reinicio.

Al final de este flujo, el dispositivo se reinicia y el mecanismo RoR 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 que normalmente reciben.

Modificar las configuraciones del producto

Un producto marcado como compatible con la función RoR en Android 11 debe incluir una implementación de RebootEscrow HAL e incluir el archivo XML del marcador de funciones. La implementación predeterminada funciona bien en dispositivos que usan reinicio en caliente (cuando la alimentación de la DRAM permanece encendida durante el reinicio).

Reiniciar el marcador de función de depósito en garantía

El marcador de característica 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 en garantía de reinicio

Para utilizar la implementación predeterminada, debe reservar 65536 (0x10000) bytes. Nunca escriba estos bytes en un almacenamiento no volátil para garantizar que las propiedades de seguridad persistan.

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 . El siguiente ejemplo muestra que 0x50000000 está reservado:

  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 el dispositivo.mk

Suponiendo que su nuevo dispositivo del paso anterior se llame pmem0 , debe asegurarse 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 SELinux

Agregue estas 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