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

Reanudar al reiniciar

En Android 11, actualizaciones OTA se pueden aplicar utilizando el Una actualización / B o actualización virtuales A / B mecanismos, combinado con los RecoverySystem métodos de clase. Después de un dispositivo se reinicia para aplicar una actualización OTA, Resume-on-Reboot (RoR) desbloquea el dispositivo de credenciales cifrados (CE) de almacenamiento .

Aunque los socios pueden emparejar 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 adicional del sistema OTA. El proceso RoR proporciona 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 basadas en servidor y multicliente de Android 12 juntas brindan seguridad de tipo de hardware a nivel de dispositivo.

A pesar de que debe proporcionar el permiso para el dispositivo de android.hardware.reboot_escrow característica de apoyo RoR en Android 11, que no es necesario para esta opción para activar RoR basada en servidor en Android 12 y más alto, debido a que no utilizan la HAL.

proporcionar permisos del dispositivo para el android.hardware.reboot_escrow función. No necesita hacer nada para habilitar RoR basado en servidor en Android 12, porque Android 12 y versiones posteriores no usan HAL.

Fondo

Comenzando con Android 7, Android apoyado directa de arranque , lo que permite a las aplicaciones en un dispositivo para poner en marcha antes de su almacenamiento CE está desbloqueado por el usuario. La implementación del soporte de arranque directo brindó a los usuarios una mejor experiencia antes de que se necesitara 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 en un dispositivo, incluidas aquellas que no son compatibles con 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 asegurar que cuando un dispositivo cae en manos de un atacante, es extremadamente difícil para el atacante recuperar datos CE- cifrada del usuario, incluso si el dispositivo está encendido, el almacenamiento de la CE está desbloqueado, y el dispositivo se desbloquea el usuario después de recibir una actualización OTA. La resistencia a los ataques internos debe ser eficaz incluso si el atacante obtiene acceso a las claves de firma criptográficas de difusión.

En concreto, el almacenamiento de la CE no debe ser leído por un atacante que tiene físicamente el dispositivo, y tiene 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.
  • Se puede modificar el funcionamiento de cualquier hardware (tal como un procesador de aplicaciones, o memoria flash) - excepto como se detalla en Limitaciones de abajo. (Sin embargo, dicha modificación implica tanto un retraso de al menos una hora como un ciclo de energía que destruye el contenido de la RAM).

Limitaciones

  • No se puede modificar el funcionamiento de hardware a prueba de manipulaciones (por ejemplo, un Titan M).
  • No se puede leer la RAM del dispositivo en vivo.
  • No puedo adivinar las credenciales del usuario (PIN, patrón, contraseña) o hacer que se ingresen.

Solución

El sistema de actualización 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 de confianza (ETE).
  • La ETE sólo libera las teclas si el sistema operativo que se ejecuta pasa la autenticación criptográfica (arranque verificado).
  • El servicio RoR se ejecuta en los servidores de Google protege los datos de la CE mediante el almacenamiento de un secreto que puede ser recuperada por 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).
    • A continuación, cifra el SP dos veces: una vez con una clave K_s almacenan en la memoria RAM, y de nuevo 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 son recién generados y utilizados por un único reinicio.
  • Cuando llega el momento de iniciar el sistema, Android confía K_s al servidor. El recibo con K_k se cifran antes de que esté almacenada en el disco.
  • Después del reinicio, Android utiliza K_k para descifrar el recibo, a continuación, lo envía al servidor para recuperar K_s .
    • K_k y K_s se utilizan para descifrar el SP almacenada 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 su teléfono seguro pueden ocurrir en el momento que sea conveniente para usted: mientras duerme.

Reproducción de SIM-PIN

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

Una tarjeta SIM con un PIN habilitado también debe someterse a una verificación perfecta del código PIN (una repetición de SIM-PIN) después de un reinicio desatendido para restaurar la conectividad celular (requerido para llamadas telefónicas, mensajes SMS y servicios de datos). El PIN de la SIM y la información correspondiente de la tarjeta SIM (el ICCID y el número de ranura SIM) se almacenan juntos de forma segura. El PIN almacenado se puede recuperar y usar para verificación solo después de un reinicio desatendido exitoso. Si el dispositivo está protegido, el PIN de la SIM se almacena con claves protegidas por la LSKF. Si la tarjeta SIM tiene activado su PIN, la interacción con el servidor RoR requiere una conexión Wi-Fi para la actualización OTA y RoR basada en el servidor, lo que asegura la funcionalidad básica (con conectividad celular) al reiniciar el sistema.

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 deshabilita el PIN.
  • Se ha producido un reinicio no iniciado por RoR.

El PIN SIM almacenado sólo puede utilizarse una vez después del reinicio iniciado por RoR, y sólo durante un periodo de tiempo muy corto (20 segundos) - si los detalles del partido de la tarjeta SIM. El PIN de la SIM almacenado nunca sale de la aplicación TelephonyManager y no puede ser recuperado por módulos externos.

Pautas de implementación

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

Para asegurarse de que las actualizaciones de OTA durante esos períodos de tiempo no interrumpan a los usuarios, utilice el modo oscuro para mitigar las emisiones de luz. Para ello, tener la búsqueda del gestor de arranque dispositivo para la razón por la cadena unattended . Si unattended es true , poner 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 multi-cliente, isPreparedForUnattendedUpdate , 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 invoca la OTA TelephonyManager API del sistema cuando un reinicio es inminente en Android 12. Esta API se mueve todo en caché los códigos PIN de la AVAILABLE estado a la REBOOT_READY estado. El TelephonyManager API del sistema está protegido por el vigente REBOOT permiso 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 privilegiados utilizan la API del sistema TelephonyManager.

Pruebas

Para probar la nueva API, ejecute este comando:

    adb shell cmd phone unattended-reboot

Este comando sólo funciona cuando el proyectil se está ejecutando como root ( adb root ).

Solo Android 11

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

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

  1. Si la persistencia soportes de hardware SoC de RAM en los reinicios, los OEM pueden utilizar la aplicación por defecto en AOSP ( RAM por defecto fideicomiso ).
  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.
    • Tenga 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 RoR de manera que sea imposible para los internos o atacantes recuperarla.

Depósito de RAM predeterminado

AOSP tiene una implementación de RoR 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 siguiente sección.

Flujo de actualización de OTA usando RoR

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

  1. La aplicación cliente OTA descarga la actualización.
  2. Llamadas de la aplicación del cliente OTA 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. El usuario desbloquea el dispositivo en la pantalla de bloqueo y el dispositivo está listo para que se aplique la actualización.
  4. Llamadas de la aplicación del cliente OTA 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 encriptado con credenciales (CE). Para aplicaciones, esto aparece como un usuario normal de desbloqueo, por lo que reciben todas las señales, tales como ACTION_LOCKED_BOOT_COMPLETED y ACTION_BOOT_COMPLETED que lo hacen normalmente.

Modificar configuraciones de productos

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 de marcador de función. La implementación predeterminada funciona bien en dispositivos que usan reinicio en caliente (cuando la energía de la DRAM permanece encendida 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, debe reservar 65536 (0x10000) bytes. Nunca escriba estos bytes en un almacenamiento no volátil para asegurarse de que persistan 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. El siguiente ejemplo muestra 0x50000000 siendo reservados:

  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 , debe garantizar las siguientes nuevas entradas se agregan 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

Añadir estas nuevas entradas a del dispositivo file_contexts :

/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