Cette page a été traduite par l'API Cloud Translation.

Reprise 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 la classe RecoverySystem . Après le redémarrage d'un appareil pour appliquer une mise à jour OTA, Resume-on-Reboot (RoR) déverrouille le stockage Credential Encrypted (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 dans Android 11, les partenaires Android 12 n'ont pas besoin d'une fonctionnalité système OTA supplémentaire. Le processus RoR offre une sécurité et une commodité supplémentaires 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 multi-client et serveur d'Android 12 fournissent ensemble une sécurité de type matériel au niveau de l'appareil.

Bien que vous deviez fournir l'autorisation de l'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 supérieur, car ils n'utilisent pas le HAL.

Arrière-plan

À partir d'Android 7, Android a pris en charge Direct Boot , qui permet aux applications d'un appareil de démarrer avant que le stockage CE ne soit déverrouillé par l'utilisateur. La mise en œuvre de la prise en charge du démarrage direct a fourni 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.

RoR permet de déverrouiller le stockage CE de toutes les applications sur un appareil, y compris celles qui ne prennent pas en charge 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 RoR doit garantir que lorsqu'un appareil tombe entre les mains d'un attaquant, il est extrêmement difficile pour l'attaquant de récupérer les données cryptées CE de l'utilisateur, même si l'appareil est sous tension, le stockage CE est déverrouillé et 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 l'attaquant parvient à accéder aux clés de signature cryptographique diffusées.

Plus précisément, le stockage CE ne doit pas être lu par un attaquant qui possède physiquement l'appareil et qui possède ces capacités et limitations :

Capacités

Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
Peut amener l'appareil à 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 les Limitations ci-dessous. (Cependant, une telle modification implique à la fois un retard d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.)

Limites

Impossible de modifier le fonctionnement du matériel inviolable (par exemple, un Titan M).
Impossible de lire la RAM de l'appareil en direct.
Impossible de deviner les informations d'identification de l'utilisateur (PIN, modèle, mot de passe) ou de les saisir autrement.

Solution

Le système de mise à jour Android 12 RoR offre une sécurité contre les attaquants très sophistiqués, et ce, tant que les mots de passe et les codes PIN sur l'appareil restent sur l'appareil - ils ne sont jamais envoyés ni stockés sur les serveurs Google. Il s'agit d'un aperçu du processus qui garantit que les niveaux de sécurité fournis sont similaires à un système RoR basé sur le matériel 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 de confiance (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 vérifié ).
Le service RoR fonctionnant sur les serveurs de Google sécurise les données CE en stockant un secret qui ne peut être récupéré que pendant un temps limité . Cela fonctionne dans tout l'écosystème Android.
Une clé cryptographique, protégée par le code PIN de l'utilisateur, est utilisée pour déverrouiller l'appareil et décrypter le stockage CE.
- Lorsqu'un redémarrage nocturne est programmé, Android invite l'utilisateur à entrer son code PIN, 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 le SP est effacé de la RAM. Les deux clés sont fraîchement générées et utilisées pour un seul redémarrage .
Au moment 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écrypter 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 ignorés.

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

Relecture SIM-PIN

Sous certaines conditions, le code PIN d'une carte SIM est vérifié à partir d'un cache, un processus appelé relecture SIM-PIN.

Une carte SIM avec un code PIN activé doit également subir une vérification transparente du code PIN (une relecture SIM-PIN) après un redémarrage sans surveillance pour restaurer la connectivité cellulaire (requise pour les appels téléphoniques, les messages 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 ensemble en toute sécurité. Le code PIN stocké peut être récupéré et utilisé à des fins de vérification uniquement 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 le LSKF. Si le code PIN de la carte SIM est activé, l'interaction avec le serveur RoR nécessite une connexion WiFi pour la mise à jour OTA et RoR basé sur le serveur, qui garantit les fonctionnalités de base (avec connectivité cellulaire) après le redémarrage.

Le code PIN SIM est recrypté et stocké chaque fois que l'utilisateur l'active, le vérifie ou le modifie avec succès. Le code PIN de la carte SIM est ignoré si l'un des événements suivants se produit :

La carte SIM est supprimée ou réinitialisée.
L'utilisateur désactive le code PIN.
Un redémarrage non initié par RoR s'est produit.

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

Directives de mise en œuvre

Dans Android 12, les fonctions RoR multi-clients et basées sur serveur offrent une charge plus légère aux partenaires lorsqu'ils poussent les mises à jour OTA. Les mises à jour nécessaires peuvent se produire pendant les temps d'arrêt de l'appareil, comme pendant les heures de sommeil 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 atténuer les émissions de lumière. Pour ce faire, demandez au chargeur de démarrage de l'appareil de rechercher la chaîne reason unattended . Si unattended est true , mettez l'appareil en mode sombre. Notez qu'il est de la responsabilité de chaque équipementier d'atténuer les émissions sonores et lumineuses.

Si vous effectuez une mise à niveau vers Android 12 ou lancez des appareils Android 12, vous n'avez rien à faire pour implémenter la nouvelle fonctionnalité RoR.

Il y a un nouvel appel dans le flux multi-client, isPreparedForUnattendedUpdate , illustré 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 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 du système TelephonyManager est protégée par l'autorisation REBOOT Manifest 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 du système TelephonyManager est utilisée par les APK privilégiés.

Essai

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

    adb shell cmd phone unattended-reboot

Cette commande ne fonctionne que lorsque le shell s'exécute en tant que 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 répartissent en deux catégories :

Si le matériel SoC prend en charge la persistance de la RAM lors des redémarrages, les OEM peuvent utiliser l'implémentation par défaut dans AOSP ( Default RAM Escrow ).
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é discret avec ses propres RAM et ROM), il doit en outre effectuer les opérations suivantes :
- Être capable de détecter un redémarrage du processeur principal.
- Avoir une source de minuterie matérielle qui persiste lors des redémarrages. C'est-à-dire que l'enclave doit pouvoir détecter le redémarrage et faire expirer un temporisateur défini avant le redémarrage.
- Prise en charge du stockage d'une clé séquestrée dans la RAM/ROM de l'enclave de sorte qu'elle ne puisse pas être récupérée avec des attaques hors ligne. Il doit stocker la clé RoR de manière à empêcher les initiés ou les attaquants de la récupérer.

Dépôt de RAM par défaut

AOSP a une implémentation du RoR HAL utilisant la persistance 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 sont pas en mesure de 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 cette HAL par défaut. La référence canonique pour cela dans la section suivante.

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

L'application client 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 de RoR. Avec cette condition préalable en place, le flux d'une mise à jour suit ces étapes :

L'application client OTA télécharge la mise à jour.
L'application cliente OTA appelle RecoverySystem#prepareForUnattendedUpdate , ce qui déclenche l'invite de l'utilisateur à saisir son code PIN, son schéma ou son mot de passe sur l'écran de verrouillage lors du prochain déverrouillage.
L'utilisateur déverrouille l'appareil sur l'écran de verrouillage et l'appareil est prêt à appliquer la mise à jour.
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é des informations d'identification (CE). Pour les applications, cela apparaît comme un déverrouillage utilisateur normal, de sorte qu'elles reçoivent tous les signaux, tels que ACTION_LOCKED_BOOT_COMPLETED et ACTION_BOOT_COMPLETED qu'elles font normalement.

Modification des configurations de produit

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

Redémarrer le marqueur de fonction d'entiercement

Le marqueur de fonctionnalité 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 du dépôt fiduciaire de redémarrage par défaut

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

Modifications de l'arborescence des 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 que 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 que vous avez un nouveau périphérique dans le répertoire de blocs avec un nom comme /dev/block/pmem0 (comme pmem1 ou pmem2 ).

Modifications de Device.mk

En supposant que votre nouveau périphérique de l'étape précédente s'appelle 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 aux 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

Arrière-plan

Modèle de menace

Plus précisément, le stockage CE ne doit pas être lu par un attaquant qui possède physiquement l'appareil et qui possède ces capacités et limitations :

Capacités

Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
Peut amener l'appareil à 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 les Limitations ci-dessous. (Cependant, une telle modification implique à la fois un retard d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.)

Limites

Impossible de modifier le fonctionnement du matériel inviolable (par exemple, un Titan M).
Impossible de lire la RAM de l'appareil en direct.
Impossible de deviner les informations d'identification de l'utilisateur (PIN, modèle, mot de passe) ou de les saisir autrement.

Solution

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 de confiance (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 vérifié ).
Le service RoR fonctionnant sur les serveurs de Google sécurise les données CE en stockant un secret qui ne peut être récupéré que pendant un temps limité . Cela fonctionne dans tout l'écosystème Android.
Une clé cryptographique, protégée par le code PIN de l'utilisateur, est utilisée pour déverrouiller l'appareil et décrypter le stockage CE.
- Lorsqu'un redémarrage nocturne est programmé, Android invite l'utilisateur à entrer son code PIN, 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 le SP est effacé de la RAM. Les deux clés sont fraîchement générées et utilisées pour un seul redémarrage .
Au moment 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écrypter 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 ignorés.

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

Relecture SIM-PIN

Sous certaines conditions, le code PIN d'une carte SIM est vérifié à partir d'un cache, un processus appelé relecture SIM-PIN.

La carte SIM est supprimée ou réinitialisée.
L'utilisateur désactive le code PIN.
Un redémarrage non initié par RoR s'est produit.

Directives de mise en œuvre

Si vous effectuez une mise à niveau vers Android 12 ou lancez des appareils Android 12, vous n'avez rien à faire pour implémenter la nouvelle fonctionnalité RoR.

Il y a un nouvel appel dans le flux multi-client, isPreparedForUnattendedUpdate , illustré 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 HAL est obsolète à partir d'Android 12.

TelephonyManager

 /**
    * 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 du système TelephonyManager est utilisée par les APK privilégiés.

Essai

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

    adb shell cmd phone unattended-reboot

Cette commande ne fonctionne que lorsque le shell s'exécute en tant que 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 répartissent en deux catégories :

Si le matériel SoC prend en charge la persistance de la RAM lors des redémarrages, les OEM peuvent utiliser l'implémentation par défaut dans AOSP ( Default RAM Escrow ).
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é discret avec ses propres RAM et ROM), il doit en outre effectuer les opérations suivantes :
- Être capable de détecter un redémarrage du processeur principal.
- Avoir une source de minuterie matérielle qui persiste lors des redémarrages. C'est-à-dire que l'enclave doit pouvoir détecter le redémarrage et faire expirer un temporisateur défini avant le redémarrage.
- Prise en charge du stockage d'une clé séquestrée dans la RAM/ROM de l'enclave de sorte qu'elle ne puisse pas être récupérée avec des attaques hors ligne. Il doit stocker la clé RoR de manière à empêcher les initiés ou les attaquants de la récupérer.

Dépôt de RAM par défaut

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

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

Modification des configurations de produit

Redémarrer le marqueur de fonction d'entiercement

Le marqueur de fonctionnalité 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 du dépôt fiduciaire de redémarrage par défaut

Modifications de l'arborescence des 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 que 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 que vous avez un nouveau périphérique dans le répertoire de blocs avec un nom comme /dev/block/pmem0 (comme pmem1 ou pmem2 ).

Modifications de 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 aux 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

Arrière-plan

Modèle de menace

Plus précisément, le stockage CE ne doit pas être lu par un attaquant qui possède physiquement l'appareil et qui possède ces capacités et limitations :

Capacités

Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
Peut amener l'appareil à 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 les Limitations ci-dessous. (Cependant, une telle modification implique à la fois un retard d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.)

Limites

Impossible de modifier le fonctionnement du matériel inviolable (par exemple, un Titan M).
Impossible de lire la RAM de l'appareil en direct.
Impossible de deviner les informations d'identification de l'utilisateur (PIN, modèle, mot de passe) ou de les saisir autrement.

Solution

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 de confiance (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 vérifié ).
Le service RoR fonctionnant sur les serveurs de Google sécurise les données CE en stockant un secret qui ne peut être récupéré que pendant un temps limité . Cela fonctionne dans tout l'écosystème Android.
Une clé cryptographique, protégée par le code PIN de l'utilisateur, est utilisée pour déverrouiller l'appareil et décrypter le stockage CE.
- Lorsqu'un redémarrage nocturne est programmé, Android invite l'utilisateur à entrer son code PIN, 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 le SP est effacé de la RAM. Les deux clés sont fraîchement générées et utilisées pour un seul redémarrage .
Au moment 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écrypter 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 ignorés.

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

Relecture SIM-PIN

Sous certaines conditions, le code PIN d'une carte SIM est vérifié à partir d'un cache, un processus appelé relecture SIM-PIN.

La carte SIM est supprimée ou réinitialisée.
L'utilisateur désactive le code PIN.
Un redémarrage non initié par RoR s'est produit.

Directives de mise en œuvre

Si vous effectuez une mise à niveau vers Android 12 ou lancez des appareils Android 12, vous n'avez rien à faire pour implémenter la nouvelle fonctionnalité RoR.

Il y a un nouvel appel dans le flux multi-client, isPreparedForUnattendedUpdate , illustré 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 HAL est obsolète à partir d'Android 12.

TelephonyManager

 /**
    * 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 du système TelephonyManager est utilisée par les APK privilégiés.

Essai

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

    adb shell cmd phone unattended-reboot

Cette commande ne fonctionne que lorsque le shell s'exécute en tant que 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 répartissent en deux catégories :

Si le matériel SoC prend en charge la persistance de la RAM lors des redémarrages, les OEM peuvent utiliser l'implémentation par défaut dans AOSP ( Default RAM Escrow ).
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é discret avec ses propres RAM et ROM), il doit en outre effectuer les opérations suivantes :
- Être capable de détecter un redémarrage du processeur principal.
- Avoir une source de minuterie matérielle qui persiste lors des redémarrages. C'est-à-dire que l'enclave doit pouvoir détecter le redémarrage et faire expirer un temporisateur défini avant le redémarrage.
- Prise en charge du stockage d'une clé séquestrée dans la RAM/ROM de l'enclave de sorte qu'elle ne puisse pas être récupérée avec des attaques hors ligne. Il doit stocker la clé RoR de manière à empêcher les initiés ou les attaquants de la récupérer.

Dépôt de RAM par défaut

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

L'application client OTA télécharge la mise à jour.
OTA client app calls to RecoverySystem#prepareForUnattendedUpdate which triggers the user to be prompted for their PIN, pattern, or password on the lock screen during the next unlock.
The user unlocks the device at the lockscreen, and the device is ready to have the update applied.
OTA client app calls to RecoverySystem#rebootAndApply , which immediately triggers a reboot.

At the end of this flow, the device reboots and the RoR mechanism unlocks the credential encrypted (CE) storage. To apps, this appears as a normal user unlock, so they receive all the signals, such as ACTION_LOCKED_BOOT_COMPLETED and ACTION_BOOT_COMPLETED that they normally do.

Modifying product configurations

A product marked as supporting the RoR feature in Android 11 must include an implementation of the RebootEscrow HAL and include the feature marker XML file. The default implementation works well on devices that use warm reboot (when the power to DRAM remains on during reboot).

Reboot escrow feature marker

The feature marker must also be present:

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

Default reboot escrow HAL implementation

To use the default implementation, you must reserve 65536 (0x10000) bytes. Never write these bytes to non-volatile storage to ensure that the security properties persist.

Linux kernel device tree changes

In the Linux kernel's device tree, you must reserve memory for a pmem region. The following example shows 0x50000000 being reserved:

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

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

Verify that you have a new device in the block directory with a name like /dev/block/pmem0 (such as pmem1 or pmem2 ).

Device.mk changes

Assuming that your new device from the previous step is named pmem0 , you must ensure the following new entries get added to 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

SELinux rules

Add these new entries to the device's 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