Reprise au redémarrage

Lorsque l'OTA est téléchargée et prête à être appliquée par l' intermédiaire de A / B mise à jour , A / B virtuel , ou d'une autre méthode disponible via classe RecoverySystem , CV-on-redémarrage va tenter de débloquer le stockage crypté d' informations d' identification (CE) après le redémarrage du dispositif à appliquer l'OTA. Cela peut être associé à un système OTA qui applique les mises à jour lorsque cela est plus pratique pour l'utilisateur, par exemple lorsque l'appareil est censé être inactif.

Fond

Pour les développeurs d'applications, Android prend en charge Direct Boot qui permet aux applications de démarrer avant le stockage d' informations d' identification Encrypted (CE) est déverrouillé par l'utilisateur. À mesure que de plus en plus de développeurs d'applications implémentent la prise en charge du démarrage direct, l'utilisateur bénéficie d'une meilleure expérience avant que son facteur de connaissance de l'écran de verrouillage (LSKF) ne soit saisi après un démarrage.

Resume-on-Reboot permet de déverrouiller le stockage CE de toutes les applications, y compris celles qui ne prennent pas encore en charge le démarrage direct, après un redémarrage initié par une 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 Resume-on-Reboot doit préserver la propriété que lorsqu'un appareil tombe entre les mains d'un attaquant, il est extrêmement difficile pour cet 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'utilisateur a déverrouillé l'appareil après avoir reçu une OTA ; pour la résistance aux attaques internes, nous supposons également que l'attaquant a accès aux clés de signature cryptographiques diffusées.

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

  • Peut utiliser la clé de signature de n'importe quel fournisseur ou entreprise pour signer des messages arbitraires.
  • Peut entraîner la réception d'un OTA par l'appareil.
  • Peut modifier le fonctionnement de n'importe quel matériel (processeur d'application, flash, etc.) sauf comme détaillé ci-dessous, mais une telle modification implique un délai d'au moins une heure et un cycle d'alimentation qui détruit le contenu de la RAM.
  • Impossible de modifier le fonctionnement du matériel inviolable (par exemple, 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 d'une autre manière.

Lignes directrices à l'intention de l'exécutant

Depuis juillet 2020, les implémentations de Resume-on-Reboot HAL se répartissent généralement en deux catégories :

  1. 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).
  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é discret avec ses propres RAM et ROM), il doit en outre :
    • Être capable de détecter le redémarrage du processeur principal.
    • Avoir une source de minuterie matérielle qui persiste au cours des redémarrages ; c'est-à-dire que l'enclave doit être capable de détecter le redémarrage et d'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é Resume-on-Reboot de manière à ce qu'il soit impossible pour les initiés ou les attaquants de la récupérer.

Dépôt de RAM par défaut

AOSP a une implémentation de la HAL Resume-on-Reboot 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 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 cette HAL par défaut. La référence canonique pour cela dans la section ci-dessous.

Lorsque l'OTA est téléchargé et prêt à être appliqué au moyen de A / B mise à jour , A / B virtuel , ou d'une autre méthode disponible via classe RecoverySystem , CV-on-redémarrage va tenter de débloquer le stockage crypté d' informations d' identification (CE) après que le dispositif redémarre pour appliquer la mise à jour OTA. Cela peut être associé à un système OTA qui applique les mises à jour lorsque cela est plus pratique pour l'utilisateur, par exemple lorsque l'appareil est censé être inactif.

Flux de mise à jour OTA à l'aide de Resume-on-Reboot

L'application client OTA sur le téléphone doit avoir les Manifest.permission.REBOOT et Manifest.permisson.RECOVERY autorisations pour appeler les méthodes nécessaires pour la mise en œuvre de reprise après le redémarrage. Avec cette condition préalable en place, le flux d'une mise à jour est :

  1. Mise à jour des téléchargements de l'application cliente OTA
  2. OTA appels d'applications client à RecoverySystem#prepareForUnattendedUpdate qui déclenche l'utilisateur soient invités à entrer leur code PIN, schéma ou mot de passe sur l'écran de verrouillage lors du prochain déblocage
  3. Lorsque l'utilisateur déverrouille ensuite l'appareil sur l'écran de verrouillage, l'appareil est prêt à appliquer la mise à jour
  4. OTA appels d'applications client à RecoverySystem#rebootAndApply qui déclenche immédiatement un redémarrage

À la fin de ce flux, l'appareil redémarre et le mécanisme de reprise au redémarrage déverrouille le stockage chiffré des informations d'identification (CE). Pour les applications, cela apparaît comme un déverrouillage utilisateur normal, ils reçoivent tous les signaux, tels que ACTION_LOCKED_BOOT_COMPLETED et ACTION_BOOT_COMPLETED comme ils le feraient normalement.

Modification des configurations de produits

Pour qu'un produit soit marqué comme prenant en charge la fonctionnalité Resume-on-Reboot, il 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 un redémarrage à chaud (c'est-à-dire que l'alimentation n'est pas supprimée de la DRAM pendant le redémarrage).

Marqueur de fonction d'entiercement de redémarrage

Le marqueur de caractéristique 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 d'entiercement de redémarrage par défaut

Pour utiliser l'implémentation par défaut, 65536 (0x10000) octets doivent être réservés pour l'implémentation. Ces octets ne doivent pas être écrits dans une mémoire non volatile pour que les propriétés de sécurité soient conservées.

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 pmem région. Dans l'exemple suivant 0x50000000 a été 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 disposez d' un nouvel appareil dans le répertoire bloc avec un nom comme /dev/block/pmem0 (comme pmem1 ou pmem2 ).

Modifications de Device.mk

En supposant que votre nouvel appareil de l'étape précédente est nommé pmem0 , les nouvelles entrées suivantes doivent être ajoutées au 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

Les nouvelles entrées à l'appareil file_contexts doivent être ajoutés:

/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