Existe-t-il une documentation sur le fonctionnement exact de la protection contre la réinitialisation d'usine (FRP) ?

Je pense qu'une grande partie de ces informations est volontairement tenue secrète... en faisant moi-même des recherches sur ce sujet il y a quelque temps, c'est le maximum que j'ai pu trouver "en détail".

https://github.com/intel/kernelflinger/blob/master/doc/FRP.md

Règles relatives au chargeur de démarrage et protection contre la réinitialisation d'usine Les spécifications GVB (Google's verified boot) et FRP (Google Factory Reset Protection) pour AndroidTM définissent un ensemble de protocoles de sécurité visant à garantir l'intégrité du système et à décourager le vol de l'appareil, respectivement.

Il existe des raisons légitimes de déverrouiller le bootloader sans connaître le code PIN de déverrouillage de l'écran, notamment les RMA. Un centre de traitement RMA devrait être en mesure de déverrouiller les restrictions de flashage de l'appareil dans Fastboot et de remettre l'appareil dans son état d'origine sans demander à l'utilisateur de divulguer son code PIN de déverrouillage de l'écran et sans risquer de compromettre ses données.

Cette documentation décrit la solution permettant de définir un appareil de classe A et un mécanisme permettant de déverrouiller un appareil pour le RMA, indépendamment du FRP ou du statut de classe A. Cette solution répond aux exigences de sécurité du FRP de Google en garantissant qu'il n'y a pas de clé unique pour déverrouiller les appareils si toutes les considérations de sécurité sont mises en œuvre. Il permet également de provisionner les appareils de manière à ce que l'entité disposant de l'autorité de déverrouillage puisse être le vendeur, l'OEM, l'ODM, un opérateur ou une organisation d'entreprise.

Expérience de l'utilisateur de l'appareil L'utilisateur démarre l'appareil avec Fastboot L'utilisateur obtient un défi d'action fastboot oem get-action-nonce force-unlock L'utilisateur transmet le défi à l'agent d'autorisation d'action et reçoit un fichier de jeton d'autorisation d'action (voir détails plus loin). L'utilisateur montre le jeton d'autorisation d'action fastboot flash action-authorization token_file Fastboot effectue l'action autorisée Mise en œuvre Le protocole d'autorisation d'action OEM est une simple réponse à un défi où le Fastboot de l'appareil génère un one-time-nonce, l'agent d'autorisation d'action OEM signe le nonce et l'action approuvée en utilisant sa clé d'autorisation privée (OAK) pour générer un jeton d'autorisation, puis le Fastboot de l'appareil valide le jeton d'autorisation d'action et exécute l'action.

Remplacer la clé d'autorisation La clé d'autorisation prioritaire (OAK) est une clé publique qui est définie dans le dispositif lors de la fabrication et qui est utilisée pour valider les jetons d'autorisation d'action. Si une OAK n'est pas définie, toutes les fonctions d'autorisation d'action sont désactivées et le comportement par défaut du chargeur de démarrage et de Fastboot spécifié dans GVB et FRP est en vigueur. Étant donné que l'OAK est capable d'outrepasser les politiques de classe A et FRP, il est important de s'assurer qu'il ne peut pas être modifié par un code non autorisé, ce qui changerait l'identité de ceux qui peuvent outrepasser la politique.

L'OAK peut agir en tant que certificat racine de validation si l'attribut d'autorité de certification du certificat est "true" -- traitement standard des certificats X.509v3. Cela signifie que l'OAK peut être utilisé pour émettre des certificats qui sont également capables de signer des jetons d'autorisation d'action. C'est la méthode préférée pour définir l'OAK dans les cas où plusieurs entités ont besoin de pouvoir émettre des jetons d'autorisation d'action sans avoir accès à une seule clé.

L'OAK est stocké en tant que variable EFI authentifiée en fonction du temps sous le GUID Fastboot 1ac80a82-4f0c-456b-9a99-debeb431fcc1. Le contenu de cette variable est la somme SHA256 du certificat OAK.

Masque de politique du chargeur de démarrage Le masque de politique du chargeur de démarrage (BPM) est un ensemble de 64 drapeaux de politique booléens. Si un BPM n'est pas défini, Fastboot utilise par défaut une politique correspondant à une valeur BPM de zéro. Si une valeur BPM est définie, un bit 1 indique que la politique correspondante est active.

Le BPM est défini dans l'appareil lors de sa fabrication.

Nom de la politique Bit(s) Description CLASS_A_DEVICE 0 S'il est activé, le chargeur de démarrage applique le comportement défini par GVB pour les périphériques de classe A. MIN_BOOT_STATE 1-2 État de démarrage minimal requis pour démarrer le dispositif (0 pour le rouge, 1 pour l'orange, 2 pour le jaune et 3 pour le vert). BPM est stocké en tant que variable EFI authentifiée basée sur le temps BPM sous le GUID Fastboot de 1ac80a82-4f0c-456b-9a99-debeb431fcc1.

Générer une seule fois de l'argent Le nonce d'autorisation d'action unique a la forme "::<identifiant d'action de 8 bits>:<16 octets aléatoires du client>", tous les champs étant codés en hexadécimal. Il est généré lorsque la commande fastboot oem get-action-nonce est utilisée. Fastboot enregistre la valeur pour une durée limitée avant qu'elle n'expire. Chaque fois que la commande est exécutée, une nouvelle valeur est générée et la valeur précédente est écrasée. La valeur n'est pas stockée de manière persistante. Si Fastboot est redémarré, l'ancien nonce n'est plus valide.

Les actions suivantes sont définies.

Nom Action ID Description Force unlock 0x00 Oblige Kernelfliner à exécuter la commande Fastboot flashing unlock comme si l'option développeur "enable oem unlock" était activée. Toutes les propriétés GVB standard s'appliquent, y compris l'effacement sécurisé de la partition des données utilisateur. Le champ de la version est une valeur d'un octet. Il doit être égal à zéro pour la version actuelle.

Création d'un jeton d'autorisation d'action Un jeton d'autorisation d'action est généré en signant le nonce d'autorisation d'action avec l'OAK. Le jeton est un document signé PKCS #7, dont le corps prend la forme "::<identifiant d'action 8 bits>:<16 octets aléatoires du client>:<16 octets aléatoires de l'agent d'authentification>", tous les champs étant codés en hexadécimal. Les octets aléatoires de l'agent d'authentification ajoutés lors de la création de l'autorisation ont pour but d'empêcher un attaquant de monter une attaque en fournissant des valeurs connues en texte clair.

Le jeton doit contenir tous les certificats nécessaires pour valider la chaîne de signature du jeton.

L'agent d'autorisation de l'action doit vérifier que le nonce est exactement dans le format prescrit.

L'agent d'autorisation des actions doit vérifier que l'identifiant de l'action dans le nonce est une valeur reconnue.

Si possible, l'agent d'autorisation des actions doit vérifier que le numéro de série est valide.

Flashing du jeton d'autorisation d'action Le jeton d'autorisation est envoyé à Fastboot en utilisant la cible flash spéciale "action-authorization". Fastboot vérifie que le jeton est valide, invalide le one-time-nonce actuel et exécute l'action autorisée.

Fastboot doit valider qu'il n'y a pas de données supplémentaires après avoir analysé le jeton.

Fastboot doit vérifier que le certificat de la signature est lié à l'OAK défini lors de la fabrication.

Fastboot doit vérifier que toutes les valeurs dans le corps du jeton ont les valeurs prescrites.

Fastboot doit vérifier que la valeur renvoyée par la commande "oem get-action-nonce" correspond à la valeur du corps du jeton et que le nonce n'a pas expiré.