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, la fonctionnalité Resume-on-Reboot (RoR) déverrouille le stockage chiffré par identifiants (CE) de l'appareil.
Bien que les partenaires puissent associer ce processus à une fonctionnalité du système OTA qui applique les mises à jour lorsque l'appareil est censé être inactif dans Android 11, dans Android 12, les partenaires n'ont pas besoin d'une fonctionnalité supplémentaire du système OTA. 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. Les fonctionnalités de mise à jour multiclients et basées sur le serveur d'Android 12 offrent ensemble une sécurité de type matériel pour l'appareil.
Bien que vous deviez fournir l'autorisation de l'appareil pour que la fonctionnalité android.hardware.reboot_escrow soit compatible avec la reconnaissance de l'identité sur Android 11, vous n'avez pas besoin de le faire pour activer la reconnaissance de l'identité basée sur le serveur dans Android 12 et versions ultérieures, car elles n'utilisent pas la HAL.
Arrière-plan
Depuis Android 7, Android prend en charge le démarrage direct, qui permet aux applications d'un appareil de démarrer avant que l'utilisateur ne déverrouille le stockage CE. L'implémentation de la prise en charge du démarrage direct a permis aux utilisateurs de bénéficier d'une meilleure expérience avant que le facteur de connaissance de l'écran de verrouillage (LSKF) ne doive être saisi après un démarrage.
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 les 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 pirate informatique, il est extrêmement difficile pour ce dernier de récupérer les données chiffrées par identifiants de l'utilisateur, même si l'appareil est allumé, 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 l'attaquant obtient l'accès aux clés de signature cryptographiques de diffusion.
Plus précisément, le stockage CE ne doit pas être lu par un pirate informatique qui a physiquement l'appareil et qui présente les capacités et les limites suivantes :
Fonctionnalités
- 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'une mise à jour OTA par l'appareil.
- Peut modifier le fonctionnement de tout matériel (tel qu'un processeur d'application ou une mémoire flash), sauf dans les cas détaillés dans la section Limites ci-dessous. (Toutefois, une telle modification implique un délai d'au moins une heure et un redémarrage qui détruit le contenu de la RAM.)
Limites
- Vous ne pouvez pas modifier le fonctionnement du matériel inviolable (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 saisir d'une autre manière.
Solution
Le système de mise à jour RoR d'Android 12 offre une sécurité contre les pirates informatiques très sophistiqués, tout en conservant les mots de passe et les codes PIN sur l'appareil. Ils ne sont jamais envoyés aux serveurs Google ni stockés sur ceux-ci. Voici un aperçu du processus qui garantit que les niveaux de sécurité fournis sont semblables à ceux d'un système RoR 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 sécurisé (TEE).
- L'environnement d'exécution sécurisé 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 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 de l'utilisateur, est utilisée pour déverrouiller l'appareil et déchiffrer le stockage CE.
- Lorsqu'un redémarrage de nuit est programmé, 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_sstockée dans la RAM et une fois avec une cléK_kstocké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 récemment et ne sont utilisées que pour un seul redémarrage.
- Lorsqu'il est temps de redémarrer, Android confie
K_sau serveur. Le reçu avecK_kest chiffré avant d'être stocké sur le disque. - Après le redémarrage, Android utilise
K_kpour décrypter le reçu, puis l'envoie au serveur pour récupérerK_s.K_ketK_ssont utilisées pour 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_ketK_ssont supprimés.
Les mises à jour qui protègent votre téléphone peuvent avoir lieu à un moment qui vous convient : pendant votre sommeil.
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é relecture du code PIN de la carte SIM.
Une carte SIM avec un code PIN activé doit également faire l'objet d'une vérification du code PIN (relecture du code PIN de la carte SIM) 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 (ICCID et numéro de l'emplacement de la carte SIM) sont stockés ensemble de manière sécurisée. Le code secret stocké peut être récupéré et utilisé pour la validation uniquement après un redémarrage sans intervention 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 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 à nouveau chiffré et stocké chaque fois que l'utilisateur l'active, le valide ou le modifie. Le code PIN de la carte 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 initié par RoR s'est produit.
Le code PIN de la carte 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 informations 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 multiclients et basées sur un serveur permettent de réduire la charge pour les partenaires lorsqu'ils envoient des mises à jour OTA. Les mises à jour nécessaires peuvent avoir lieu pendant les périodes d'indisponibilité de l'appareil, par exemple 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 bootloader de l'appareil de rechercher la chaîne de raison unattended. Si unattended est true, mettez l'appareil en mode sombre. Notez qu'il incombe à chaque OEM d'atténuer les émissions sonores et lumineuses.
Si vous passez à Android 12 ou si vous lancez des appareils Android 12, vous n'avez rien à faire pour implémenter la nouvelle fonctionnalité RoR.
Un nouvel appel est disponible dans le flux 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 cette interface, car la HAL est obsolète depuis 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 secrets mis en cache de l'état AVAILABLE vers 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-rebootCette commande ne fonctionne que lorsque le shell est exécuté en tant que racine (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 ou le SoC de l'appareil sont compatibles avec un enclave matérielle sécurisée (un coprocesseur de sécurité distinct avec sa propre RAM et ROM), ils doivent également effectuer les opérations suivantes :
- être capable de détecter un redémarrage du processeur principal ;
- Disposer d'une source de minuteur matériel qui persiste lors des redémarrages. En d'autres termes, l'enclave doit être capable de détecter le redémarrage et d'annuler un minuteur défini avant le redémarrage.
- Prend en charge le stockage d'une clé séquestrée dans la RAM/ROM de l'enclave afin qu'elle ne puisse pas être récupérée avec des attaques hors connexion. Elle doit stocker la clé RoR de manière à ce qu'il soit impossible pour les personnes internes ou les pirates informatiques de la récupérer.
Escrow de RAM par défaut
AOSP dispose d'une implémentation de la couche HAL RoR utilisant la persistance 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 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 est indiquée 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 flux d'une mise à jour se déroule comme suit :
- L'application cliente OTA télécharge la mise à jour.
- L'application cliente OTA appelle
RecoverySystem#prepareForUnattendedUpdate, ce qui invite l'utilisateur à saisir son code, 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 processus, l'appareil redémarre et le mécanisme RoR déverrouille le stockage chiffré par identifiants (CE). Pour les applications, cela apparaît comme un déverrouillage normal par l'utilisateur. Elles reçoivent donc tous les signaux, tels que ACTION_LOCKED_BOOT_COMPLETED et ACTION_BOOT_COMPLETED, qu'elles reçoivent normalement.
Modifier les configurations de produit
Un produit marqué comme compatible avec la fonctionnalité RoR dans Android 11 doit inclure une implémentation de la HAL RebootEscrow et inclure le fichier XML du 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 activée pendant le redémarrage).
Marqueur de fonctionnalité de séquestre de redémarrage
Le repère 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 de l'escrow de redémarrage par défaut
Pour utiliser l'implémentation par défaut, vous devez réserver 65 536 (0x10000) octets. 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 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 comment réserver 0x50000000 :
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 portant un nom tel que /dev/block/pmem0 (par exemple, pmem1 ou pmem2) figure dans le répertoire des blocs.
Modifications apportées à Device.mk
En supposant que votre nouvel appareil 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 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