Création et gestion de la clé de signature du fichier LocalPolicy
Création
Lors de la première installation de macOS à l’usine, ou lors d’une installation connectée après formatage, le Mac exécute du code à partir du disque virtuel de restauration temporaire pour initialiser les réglages par défaut. Pendant ce processus, l’environnement de restauration crée une nouvelle paire de clés publique et privée qui est contenue dans le Secure Enclave. La clé privée est connue sous le nom de OIK (Owner Identity Key, clé d’identité du propriétaire). Si une OIK existe déjà, elle est détruite par ce processus. L’environnement de restauration initialise également la clé utilisée pour le verrouillage d’activation, connue sous le nom d’UIK (User Identity Key, clé d’identité de l’utilisateur). Une partie de ce processus est propre au Mac avec puce Apple : lorsque la certification de l’UIK est demandée pour le verrouillage d’activation, un ensemble de contraintes à appliquer au moment de la validation sur le fichier LocalPolicy est inclus. Si l’appareil n’arrive pas à faire certifier une UIK pour le verrouillage d’activation (par exemple parce que l’appareil est déjà associé à un compte Localiser mon Mac et signalé comme perdu), il ne peut pas procéder à la création d’un fichier LocalPolicy. Si un appareil reçoit un ucrt (User identity Certificate, certificat d’identité de l’utilisateur), celui-ci contient des contraintes de règlement imposées par le serveur et des contraintes de règlement demandées par l’utilisateur dans une extension X.509 v3.
Lorsque le verrouillage d’activation ou un ucrt est récupéré, il est stocké dans une base de données sur le serveur en plus d’être renvoyé à l’appareil. Une fois que l’appareil détient un ucrt, une demande de certification pour la clé publique qui correspond à l’OIK est envoyée au serveur BAA (Basic Attestation Authority, autorité d’attestation de base). Le serveur BAA vérifie la demande de certification de l’OIK à l’aide de la clé publique provenant du ucrt stocké dans la base de données à laquelle il a accès. S’il peut vérifier la certification, il certifie la clé publique, puis renvoie le certificat d’identité du propriétaire (OIC, Owner Identity Certificate) signé par lui-même, qui contient les contraintes stockées dans l’ucrt. L’OIC est renvoyé au Secure Enclave. Par la suite, dès que le Secure Enclave signe un nouveau fichier LocalPolicy, il attache l’OIC au manifeste Image4. Le LLB fait automatiquement confiance au certificat racine du serveur BAA. Pour cette raison, il fait confiance à l’OIC et donc aussi à la signature du fichier LocalPolicy en général.
Contraintes RemotePolicy
Tous les fichiers Image4 (pas seulement les fichiers LocalPolicy) contiennent des contraintes pour l’évaluation des manifestes Image4. Ces contraintes sont encodées au moyen d’identifiants d’objet (OID, Object Identifiers) spéciaux dans le certificat feuille. La bibliothèque de vérification Image4 recherche l’OID spécial d’un certificat pendant l’évaluation de la signature, puis elle évalue mécaniquement les contraintes qui y sont indiquées. Les contraintes adoptent les formes suivantes :
X must exist (X doit exister)
X must not exist (X ne doit pas exister)
X must have a specific value (X doit avoir une valeur précise)
Donc, par exemple, pour les signatures personnalisées, les contraintes de certificat comporteront « ECID must exist » (ECID doit exister), et pour les signatures « globales », elles comporteront « ECID must not exist » (ECID ne doit pas exister). Ces contraintes visent à garantir que tous les fichiers Image4 signés par une clé donnée doivent satisfaire à certaines exigences pour éviter la génération de manifestes Image4 signés erronés.
Dans le contexte de chaque fichier LocalPolicy, ces contraintes de certificat Image4 sont connues sous le nom de RemotePolicy. Un élément RemotePolicy différent peut exister pour les fichiers LocalPolicy de différents environnements de démarrage. L’élément RemotePolicy est utilisé pour restreindre le fichier LocalPolicy de recoveryOS de sorte que recoveryOS, lorsqu’il démarre, peut uniquement se comporter comme s’il appliquait le règlement Sécurité maximale. Cela augmente la confiance dans l’intégrité de l’environnement de démarrage de recoveryOS comme le lieu où le règlement de sécurité peut être modifié. L’élément RemotePolicy empêche le fichier LocalPolicy de contenir l’ECID du Mac qui l’a généré ainsi que le hachage du nonce des règles distantes (rpnh) précis qui est stocké dans le composant de stockage sécurisé de ce Mac. Le rpnh et par conséquent l’élément RemotePolicy ne changent que lorsque des opérations relatives à Localiser mon Mac et au verrouillage d’activation sont effectuées, par exemple des inscriptions, des désinscriptions, des verrouillages à distance et des effacements à distance. Les contraintes des règles distantes sont déterminées et précisées au moment de la certification de l’UIK, puis elles sont signées dans l’ucrt émis. Certaines contraintes des règles distantes, comme l’ECID, le ChipID et le BoardID, sont déterminées par le serveur pour empêcher un appareil de signer les fichiers LocalPolicy pour un autre appareil. D’autres contraintes des règles distantes peuvent être spécifiées par l’appareil pour contribuer à empêcher une rétrogradation de sécurité du fichier LocalPolicy sans la présentation de l’authentification locale requise pour accéder à l’OIK actuel et de l’authentification à distance du compte pour lequel le verrouillage d’activation de l’appareil est activé.