Resume-on-Reboot

Dans Android 11, les mises à jour OTA peuvent être appliquées à l'aide des mécanismes de mise à jour A/B ou de mise à jour A/B virtuelle, combinés aux méthodes de la classe RecoverySystem. Une fois qu'un appareil redémarre pour appliquer une mise à jour OTA, la reprise au redémarrage (RoR) déverrouille l'espace de stockage chiffré par identifiants (CE) de l'appareil.

Bien que les partenaires puissent associer ce processus à une fonctionnalité système OTA qui applique les mises à jour lorsque l'appareil est censé être inactif sous Android 11, sous Android 12, les partenaires n'ont pas besoin d'une fonctionnalité système OTA supplémentaire. Le processus de RoR offre aux utilisateurs une sécurité et une commodité accrues, car les mises à jour peuvent être effectuées pendant les périodes d'inactivité de l'appareil, tandis que les fonctionnalités de mise à jour multi-client et basées sur un serveur d'Android 12 offrent une sécurité de type matériel pour l'appareil.

Bien que vous deviez fournir une autorisation d'appareil pour que la fonctionnalité android.hardware.reboot_escrow prenne en charge le RoR dans Android 11, vous n'avez pas besoin de le faire pour activer le RoR basé sur le serveur dans Android 12 et versions ultérieures, car ils n'utilisent pas le HAL.

Arrière-plan

À partir d'Android 7, Android est compatible avec le démarrage direct, qui permet aux applications d'un appareil de démarrer avant que l'utilisateur ne déverrouille l'espace de stockage CE. L'implémentation de la prise en charge du démarrage direct a sans frais aux utilisateurs une meilleure expérience avant que le facteur de connaissance de l'écran de verrouillage (LSKF) ne soit saisi après un démarrage.

Le rollback permet de déverrouiller le stockage CE de toutes les applications d'un appareil, y compris celles qui ne sont pas compatibles avec le démarrage direct, lorsqu'un redémarrage est lancé après une mise à jour OTA. Cette fonctionnalité permet aux utilisateurs de recevoir des notifications de toutes leurs applications installées après le redémarrage.

Modèle de menace

Une implémentation de la protection contre le vol d'appareil doit s'assurer que lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour ce dernier de récupérer les données chiffrées par le chiffrement côté client de l'utilisateur, même si l'appareil est allumé, que l'espace de stockage côté client est déverrouillé et que l'appareil est déverrouillé par l'utilisateur après avoir reçu une mise à jour OTA. La résistance aux attaques internes doit être efficace même si le pirate informatique accède aux clés de signature cryptographiques diffusées.

Plus précisément, le stockage CE ne doit pas être lu par un pirate informatique qui dispose physiquement de l'appareil, et qui dispose des fonctionnalités et des limites suivantes:

Fonctionnalités

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • L'appareil peut recevoir une mise à jour OTA.
  • Peut modifier le fonctionnement de n'importe quel matériel (tel qu'un processeur d'application ou une mémoire flash), sauf comme indiqué dans la section Limites ci-dessous. (Toutefois, une telle modification implique à la fois un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.)

Limites

  • Ne peut pas modifier le fonctionnement du matériel anti-piratage (par exemple, un Titan M).
  • Impossible de lire la RAM de l'appareil en direct.
  • Ne peut pas deviner les identifiants de l'utilisateur (code, schéma, mot de passe) ni les faire saisir d'une autre manière.

Solution

Le système de mise à jour de l'authentification par reconnaissance de l'utilisateur d'Android 12 offre une sécurité contre les pirates informatiques très sophistiqués, et ce même si les mots de passe et les codes de l'appareil restent sur l'appareil. Ils ne sont jamais envoyés ni stockés sur les serveurs Google. Voici un aperçu du processus qui garantit que les niveaux de sécurité fournis sont similaires à ceux d'un système de racine de confiance matérielle au niveau de l'appareil:

  • Android applique des protections cryptographiques aux données stockées sur un appareil.
  • Toutes les données sont protégées par des clés stockées dans l'environnement d'exécution sécurisé (TEE).
  • Le TEE ne libère les clés que si le système d'exploitation en cours d'exécution passe l'authentification cryptographique (démarrage validé).
  • Le service RoR exécuté sur les serveurs Google sécurise les données CE en stockant un secret qui ne peut être récupéré que pendant une durée limitée. Cette fonctionnalité est disponible dans l'ensemble de l'écosystème Android.
  • Une clé cryptographique, protégée par le code d'un utilisateur, est utilisée pour déverrouiller l'appareil et déchiffrer le stockage CE.
    • Lorsqu'un redémarrage pendant la nuit est planifié, Android invite l'utilisateur à saisir son code secret, puis calcule un mot de passe synthétique (SP).
    • Il chiffre ensuite le SP deux fois: une fois avec une clé K_s stockée dans la RAM, et une autre fois avec une clé K_k stockée dans le TEE.
    • Le SP doublement chiffré est stocké sur le disque, et le SP est effacé de la RAM. Les deux clés sont générées et utilisées pour un seul redémarrage.
  • Lorsque le moment est venu de redémarrer, Android confie K_s au serveur. Le reçu avec K_k est chiffré avant d'être stocké sur le disque.
  • Après le redémarrage, Android utilise K_k pour déchiffrer le reçu, puis l'envoie au serveur pour récupérer K_s.
    • K_k et K_s sont utilisés pour déchiffrer le SP stocké sur le disque.
    • Android utilise le SP pour déverrouiller le stockage CE et autoriser le démarrage normal de l'application.
    • K_k et K_s sont supprimés.

Les mises à jour qui sécurisent votre téléphone peuvent être effectuées à un moment qui vous convient: pendant que vous dormez.

Relecture du code PIN de la carte SIM

Dans certaines conditions, le code PIN d'une carte SIM est validé à partir d'un cache, un processus appelé "SIM-PIN replay".

Une carte SIM avec un code PIN activé doit également faire l'objet d'une vérification fluide du code PIN (une relecture du code SIM-PIN) après un redémarrage sans surveillance pour restaurer la connectivité mobile (nécessaire pour les appels téléphoniques, les SMS et les services de données). Le code SIM et les informations de la carte SIM correspondantes (l'ICCID et le numéro de l'emplacement de la carte SIM) sont stockés ensemble de manière sécurisée. Le code secret stocké ne peut être récupéré et utilisé pour la validation qu'après un redémarrage sans surveillance réussi. Si l'appareil est sécurisé, le code SIM est stocké avec des clés protégées par la LSKF. Si le code PIN de la carte SIM est activé, l'interaction avec le serveur RoR nécessite une connexion Wi-Fi pour la mise à jour OTA et le RoR basé sur le serveur, ce qui garantit les fonctionnalités de base (avec la connectivité mobile) après le redémarrage.

Le code PIN de la carte SIM est ré-chiffré et stocké chaque fois que l'utilisateur l'active, le vérifie ou le modifie. Le code SIM est supprimé si l'un des événements suivants se produit:

  • La carte SIM est retirée ou réinitialisée.
  • L'utilisateur désactive le code.
  • Un redémarrage non déclenché par le rollback a eu lieu.

Le code SIM stocké ne peut être utilisé qu'une seule fois après le redémarrage déclenché par le RO, et uniquement pendant une très courte durée (20 secondes) si les informations de la carte SIM correspondent. Le code SIM stocké ne quitte jamais l'application TelephonyManager et ne peut pas être récupéré par des modules externes.

Consignes d'implémentation

Dans Android 12, les fonctions RoR multi-client et basées sur un serveur allègent la charge des partenaires lorsqu'ils transfèrent des mises à jour OTA. Les mises à jour nécessaires peuvent avoir lieu pendant les temps d'arrêt de l'appareil, par exemple pendant les heures de veille.

Pour vous assurer que les mises à jour OTA ne perturbent pas les utilisateurs pendant ces périodes, utilisez le mode sombre pour réduire les émissions lumineuses. Pour ce faire, demandez au bootloader de l'appareil de rechercher la raison de la chaîne unattended. Si unattended est true, mettez l'appareil en mode sombre. Notez que chaque OEM est tenu de réduire les émissions sonores et lumineuses.

Si vous passez à Android 12 ou lancez des appareils Android 12, vous n'avez rien à faire pour implémenter la nouvelle fonctionnalité de récupération des autorisations.

Un nouvel appel est ajouté au flux multi-client, isPreparedForUnattendedUpdate, comme indiqué ci-dessous:

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

Vous n'avez pas besoin de l'implémenter, car le HAL est obsolète à partir d'Android 12.

TelephonyManager

Le client OTA appelle l'API système TelephonyManager lorsqu'un redémarrage est imminent dans Android 12. Cette API déplace tous les codes PIN mis en cache de l'état AVAILABLE à l'état REBOOT_READY. L'API système TelephonyManager est protégée par l'autorisation de fichier manifeste REBOOT existante.

 /**
    * 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()

L'API système TelephonyManager est utilisée par les APK privilégiés.

Tests

Pour tester la nouvelle API, exécutez la commande suivante:

    adb shell cmd phone unattended-reboot

Cette commande ne fonctionne que lorsque le shell s'exécute en tant qu'utilisateur racine (adb root).

Android 11 uniquement

Le reste de cette page s'applique à Android 11.

Depuis juillet 2020, les implémentations de HAL RoR se divisent en deux catégories:

  1. Si le matériel du SoC est compatible avec la persistance de la RAM lors des redémarrages, les OEM peuvent utiliser l'implémentation par défaut dans AOSP (Default RAM Escrow).
  2. Si le matériel de l'appareil ou le SoC prend en charge une enclave matérielle sécurisée (un coprocesseur de sécurité distinct avec sa propre RAM et sa propre ROM), il doit également effectuer les opérations suivantes :
    • être en mesure de détecter un redémarrage du processeur principal ;
    • disposer d'une source de minuteur matériel qui persiste lors des redémarrages ; Autrement dit, l'enclave doit pouvoir détecter le redémarrage et expirer un minuteur défini avant le redémarrage.
    • Prise en charge du stockage d'une clé escrowée dans la RAM/ROM de l'enclave afin qu'elle ne puisse pas être récupérée par des attaques hors connexion. Il doit stocker la clé de retour d'appel de manière à empêcher les personnes internes ou les pirates informatiques de la récupérer.

Dépôt de mémoire vive par défaut

AOSP propose une implémentation du HAL RoR à l'aide de la persistance de la RAM. Pour que cela fonctionne, les OEM doivent s'assurer que leurs SoC prennent en charge la persistance de la RAM lors des redémarrages. Certains SoC ne peuvent pas conserver le contenu de la RAM lors d'un redémarrage. Il est donc conseillé aux OEM de consulter leurs partenaires SoC avant d'activer ce HAL par défaut. La référence canonique pour ce cas se trouve dans la section suivante.

Flux de mise à jour OTA à l'aide de RoR

L'application cliente OTA sur le téléphone doit disposer des autorisations Manifest.permission.REBOOT et Manifest.permission.RECOVERY pour appeler les méthodes nécessaires à l'implémentation de RoR. Une fois cette condition préalable remplie, le processus de mise à jour se déroule comme suit:

  1. L'application cliente OTA télécharge la mise à jour.
  2. L'application cliente OTA appelle RecoverySystem#prepareForUnattendedUpdate, ce qui déclenche l'invite de saisie du code, du schéma ou du mot de passe de l'utilisateur sur l'écran de verrouillage lors du prochain déverrouillage.
  3. L'utilisateur déverrouille l'appareil sur l'écran de verrouillage, et l'appareil est prêt à recevoir la mise à jour.
  4. L'application cliente OTA appelle RecoverySystem#rebootAndApply, ce qui déclenche immédiatement un redémarrage.

À la fin de ce flux, l'appareil redémarre et le mécanisme de récupération des droits d'accès déverrouille l'espace de stockage chiffré par identifiant (CE). Pour les applications, cela apparaît comme un déverrouillage utilisateur normal. Elles reçoivent donc tous les signaux, tels que ACTION_LOCKED_BOOT_COMPLETED et ACTION_BOOT_COMPLETED, comme elles le font normalement.

Modifier les configurations produit

Un produit marqué comme compatible avec la fonctionnalité RoR dans Android 11 doit inclure une implémentation du HAL RebootEscrow et le fichier XML du repère de fonctionnalité. L'implémentation par défaut fonctionne bien sur les appareils qui utilisent un redémarrage à chaud (lorsque l'alimentation de la DRAM reste allumée pendant le redémarrage).

Repère de la fonctionnalité de séquestre de redémarrage

Le repère de l'élément géographique doit également être présent:

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

Implémentation par défaut du HAL de dépôt de redémarrage

Pour utiliser l'implémentation par défaut, vous devez réserver 65 536 octets (0x10 000). N'écrivez jamais ces octets dans un espace de stockage non volatile pour vous assurer que les propriétés de sécurité persistent.

Modifications apportées à l'arborescence de périphériques du noyau Linux

Dans l'arborescence des périphériques du noyau Linux, vous devez réserver de la mémoire pour une région pmem. L'exemple suivant montre comment 0x50000000 est réservé:

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

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

Vérifiez qu'un nouvel appareil est présent dans le répertoire de blocage avec un nom comme /dev/block/pmem0 (par exemple, pmem1 ou pmem2).

Modifications apportées à Device.mk

En supposant que le nouvel appareil de l'étape précédente soit nommé pmem0, vous devez vous assurer que les nouvelles entrées suivantes sont ajoutées à 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
Règles SELinux

Ajoutez ces nouvelles entrées au file_contexts de l'appareil:

/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