Reprendre au redémarrage

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 classe RecoverySystem. Après le redémarrage d'un appareil pour appliquer une mise à jour OTA, la fonctionnalité "Resume-on-Restart" (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 des mises à jour lorsque l'appareil est censé être inactif sous Android 11, dans Android 12, les partenaires n'ont pas besoin d'une fonctionnalité système OTA supplémentaire. Le processus RoR offre une sécurité et une commodité accrues aux utilisateurs, 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 multiclient et basées sur le serveur d'Android 12 assurent la sécurité du type au niveau matériel.

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 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'espace de stockage CE ne soit déverrouillé par l'utilisateur. 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 connaissances sur l'écran de verrouillage (LSKF) ne doive être saisi après le démarrage.

Le RoR 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 redémarrage.

Modèle de menace

Une mise en œuvre de la règle RoR doit garantir que lorsqu'un appareil tombe entre les mains d'un pirate informatique, il est extrêmement difficile pour le pirate informatique de récupérer les données de l'utilisateur chiffrées par CE, même si l'appareil est sous tension, que le stockage CE 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 parvient à accéder aux clés de signature cryptographique de diffusion.

Plus précisément, le stockage CE ne doit pas être lu par un pirate informatique qui possède physiquement l'appareil et présente les capacités et 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 détaillé dans la section Limites ci-dessous. Toutefois, cette modification implique à la fois un délai d'au moins une heure et un cycle d'arrêt qui détruit le contenu de la RAM.

Limites

  • Ne peut pas modifier le fonctionnement d'un matériel protégé contre les accès non autorisés (Titan M, par exemple).
  • Impossible de lire la RAM de l'appareil actif.
  • Ne peut pas deviner les identifiants de l'utilisateur (code, schéma, mot de passe) ni demander leur saisie.

Solution

Le système de mise à jour RoR d'Android 12 assure la sécurité contre les pirates informatiques très sophistiqués, tout en conservant les mots de passe et les codes 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 semblables à ceux d'un système RoR basé sur le matériel et 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 réussit 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 peut être récupéré pendant une durée limitée. Cela fonctionne dans tout l'écosystème Android.
  • Une clé cryptographique, protégée par le code d'un utilisateur, permet de déverrouiller l'appareil et de déchiffrer le stockage CE.
    • Lorsqu'un redémarrage nocturne est planifié, Android invite l'utilisateur à saisir son code, 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 TEE.
    • Le SP à double chiffrement est stocké sur le disque, et il est effacé de la RAM. Les deux clés sont fraîchement générées et ne sont utilisées que pour un seul redémarrage.
  • Au moment du redémarrage, 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 la confirmation, puis l'envoie au serveur pour récupérer K_s.
    • K_k et K_s permettent de déchiffrer le SP stocké sur le disque.
    • Android utilise le SP pour déverrouiller le stockage CE et permettre le démarrage normal de l'application.
    • K_k et K_s sont supprimés.

Les mises à jour qui protègent votre téléphone peuvent avoir lieu au moment qui vous convient: lorsque vous dormez.

Relecture via le code de la carte SIM

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

Une carte SIM avec un code PIN activé doit également être soumise à une validation simple du code PIN (une relecture du code PIN SIM) après un redémarrage non surveillé afin de rétablir la connectivité mobile (requise pour les appels téléphoniques, les SMS et les services de données). Le code PIN de la carte SIM et les informations correspondantes de la carte SIM (l'ICCID et le numéro d'emplacement SIM) sont stockés de manière sécurisée ensemble. Le code PIN 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 PIN de la carte SIM est stocké avec des clés protégées par la clé LSKF. Si le code PIN de la SIM est activé, l'interaction avec le serveur RoR requiert 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 connectivité mobile) après le redémarrage.

Le code PIN de la carte SIM est rechiffré et stocké chaque fois que l'utilisateur l'active, le valide ou le modifie. Le code PIN de la carte SIM est supprimé dans les cas suivants:

  • La SIM est retirée ou réinitialisée.
  • L'utilisateur désactive le code.
  • Un redémarrage non initié par la règle RoR a eu lieu.

Le code PIN de la carte SIM stocké ne peut être utilisé qu'une seule fois après le redémarrage initié par le RoR, et seulement pendant une très courte durée (20 secondes), si les détails de la carte SIM correspondent. Le code PIN de la carte 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 basées sur le multicompte et le serveur offrent une charge plus légère aux partenaires lorsqu'ils envoient des mises à jour OTA. Les mises à jour nécessaires peuvent être effectuées lors de temps d'arrêt pratiques des appareils, par exemple pendant les heures de veille désignées.

Pour vous assurer que les mises à jour OTA pendant ces périodes n'interrompent pas les utilisateurs, utilisez le mode sombre pour limiter les émissions de lumière. Pour ce faire, demandez au bootloader de l'appareil de rechercher la raison de chaîne unattended. Si unattended est défini sur true, mettez l'appareil en mode sombre. Notez qu'il incombe à chaque OEM de réduire les émissions de sons et de lumières.

Si vous passez à Android 12 ou lancez des appareils Android 12, aucune action n'est requise de votre part pour implémenter la nouvelle fonctionnalité RoR.

Il existe un nouvel appel dans le parcours multicompte, 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 d'implémenter cela, car le HAL est obsolète depuis Android 12.

Gestionnaire de téléphonie

Le client OTA appelle l'API système TelephonyManager lorsqu'un redémarrage est imminent sous Android 12. Cette API fait passer 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 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 l'interface système s'exécute en mode root (adb root).

Android 11 uniquement

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

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

  1. Si le matériel 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 (mise en séquestre de la RAM par défaut).
  2. Si le matériel ou le SoC de l'appareil est compatible avec une enclave matérielle sécurisée (coprocesseur de sécurité discret avec sa propre RAM et ROM), il doit également procéder comme suit :
    • Être capable de détecter un redémarrage principal du processeur.
    • avoir une source de minuteur matériel qui persiste lors des redémarrages. Autrement dit, l'enclave doit pouvoir détecter le redémarrage et faire expirer un minuteur défini avant le redémarrage.
    • Possibilité de stocker une clé de séquestre dans la mémoire RAM/ROM de l'enclave, de sorte qu'elle ne puisse pas être récupérée avec des attaques hors connexion. Il doit stocker la clé RoR de manière à empêcher les initiés ou les pirates informatiques de la récupérer.

Séquestre de la RAM par défaut

AOSP dispose d'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 sont compatibles avec 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. Par conséquent, nous recommandons aux OEM de consulter leurs partenaires SoC avant d'activer cette HAL par défaut. La référence canonique à ce sujet 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 à la mise en œuvre du RoR. Une fois cette condition préalable en place, le flux d'une mise à jour suit les étapes suivantes:

  1. L'application cliente OTA télécharge la mise à jour.
  2. L'application cliente OTA appelle RecoverySystem#prepareForUnattendedUpdate, ce qui déclenche l'envoi d'une demande de code, de schéma ou de mot de passe sur l'écran de verrouillage lors du prochain déverrouillage.
  3. L'utilisateur déverrouille l'appareil à partir de l'écran de verrouillage, et l'appareil est prêt à appliquer 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 RoR déverrouille le stockage chiffré par identifiants (CE). Pour les applications, cela ressemble à un déverrouillage normal par l'utilisateur, c'est pourquoi elles reçoivent tous les signaux, tels que ACTION_LOCKED_BOOT_COMPLETED et ACTION_BOOT_COMPLETED.

Modifier les configurations de produit

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

Redémarrer le repère de l'élément géographique de séquestre

Le repère d'é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 HAL de séquestre par défaut pour le redémarrage

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

Modifications de l'arborescence des périphériques du noyau Linux

Dans l'arborescence des appareils du noyau Linux, vous devez réserver de la mémoire pour une région pmem. L'exemple suivant montre 0x50000000 en cours de réservation:

  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 se trouve dans le répertoire de blocs, avec un nom tel que /dev/block/pmem0 (tel que pmem1 ou pmem2).

Modifications apportées au fichier Device.mk

En supposant que le nouvel appareil de l'étape précédente s'appelle pmem0, vous devez vous assurer que les nouvelles entrées suivantes ont été 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 les nouvelles entrées suivantes au fichier 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