Contenu d’un fichier LocalPolicy d’un Mac avec puce Apple

Transmission de la propriété entre systèmes d’exploitation

L’accès à l’OIK (Owner Identity Key, clé d’identité du propriétaire) est appelé « propriété ». La propriété est requise pour autoriser les utilisateurs à resigner le fichier LocalPolicy après la modification de règlements ou de logiciels. L’OIK est protégée par la même hiérarchie de clés que celle décrite dans la section Protection scellée des clés (SKP) : l’OIK est protégée par la même clé de chiffrement des clés (KEK) que la clé de chiffrement du volume (VEK). Cela signifie qu’elle est habituellement protégée autant par les mots de passe de l’utilisateur que par les mesures du système d’exploitation et du règlement. Il n’existe qu’une seule OIK pour tous les systèmes d’exploitation du Mac. Par conséquent, lors de l’installation d’un deuxième système d’exploitation, le consentement explicite des utilisateurs du premier système d’exploitation est requis pour transmettre la propriété aux utilisateurs du deuxième. Cependant, aucun utilisateur n’existe pour le deuxième système d’exploitation lors de l’exécution du programme d’installation à partir du premier système d’exploitation. Les utilisateurs des systèmes d’exploitation ne sont habituellement pas générés avant le démarrage du système d’exploitation et l’exécution d’Assistant réglages. Deux nouvelles actions sont donc requises lors de l’installation d’un deuxième système d’exploitation sur un Mac avec puce Apple :

• la création d’un fichier LocalPolicy pour le deuxième système d’exploitation;

• la préparation d’un « utilisateur d’installation » pour transmettre la propriété.

Lors de l’exécution de l’assistant d’installation pour effectuer une installation sur un volume secondaire vide, une invite demande à l’utilisateur s’il souhaite copier un utilisateur du volume actuel pour en faire le premier utilisateur du deuxième volume. Si l’utilisateur accepte, l’utilisateur d’installation créé est en réalité une KEK dérivée des clés de mot de passe et de matériel de l’utilisateur sélectionné, qui est ensuite utilisée pour chiffrer l’OIK lors de sa transmission au deuxième système d’exploitation. Ensuite, à partir de l’assistant d’installation du deuxième système d’exploitation, la saisie du mot de passe de cet utilisateur est requise pour permettre l’accès à l’OIK dans le Secure Enclave pour le nouveau système d’exploitation. Si les utilisateurs choisissent de ne pas copier un utilisateur, l’utilisateur d’installation est quand même créé de la même façon, mais un mot de passe vide est utilisé plutôt que celui d’un utilisateur. Ce deuxième processus existe pour certains scénarios d’administration du système. Toutefois, les utilisateurs qui veulent effectuer des installations sur plusieurs volumes et transmettre la propriété de la façon la plus sécurisée possible devraient toujours choisir de copier un utilisateur du premier au deuxième système d’exploitation.

LocalPolicy sur un Mac avec puce Apple

Pour un Mac avec puce Apple, le contrôle local du règlement de sécurité a été délégué à une application qui s’exécute dans le Secure Enclave. Ce logiciel peut utiliser les informations d’identification de l’utilisateur ainsi que le mode de démarrage du processeur principal pour déterminer qui peut modifier le règlement de sécurité et à partir de quel environnement de démarrage. Cela contribue à empêcher les logiciels malveillants d’utiliser les commandes du règlement de sécurité contre l’utilisateur en les rétrogradant pour obtenir plus de privilèges.

Propriétés du manifeste LocalPolicy

Le fichier LocalPolicy contient des codes architecturaux FourCC qui se trouvent dans presque tous les fichiers Image4, tels que BORD (qui désigne l’identifiant d’une carte ou d’un modèle), CHIP (qui désigne une puce Apple précise) ou l’identifiant unique de puce (ECID). Mais les codes FourCC présentés plus bas traitent uniquement des règlements de sécurité configurables par les utilisateurs.

Hachage du nonce LocalPolicy (Ipnh)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le lpnh sert à protéger le fichier LocalPolicy contre les rejeux. Il s’agit d’un hachage SHA384 du LPN (LocalPolicy Nonce, nonce du fichier LocalPolicy), qui est stocké dans le composant de stockage sécurisé et qui est accessible au moyen de la mémoire morte d’amorçage du Secure Enclave ou du Secure Enclave lui-même. La valeur antirejeu brute n’est jamais lisible par le processeur d’application et n’est lisible que par sepOS. Un assaillant qui tenterait de convaincre le LLB de la validité du fichier LocalPolicy antérieur dont il se serait emparé serait contraint de placer dans le composant de stockage sécurisé une valeur dont le hachage correspondrait au même lpnh que celui trouvé dans le fichier LocalPolicy qu’il souhaiterait réexécuter. Normalement, il n’y a qu’un LPN valide dans le système, excepté lors des mises à jour logicielles pendant lesquelles deux LPN sont simultanément valides, et ce, pour permettre à l’utilisateur de lancer l’ancien logiciel en cas d’erreur de mise à jour. Toute modification d’un fichier LocalPolicy de n’importe quel système d’exploitation entraîne une nouvelle signature de tous les règlements avec la nouvelle valeur lpnh, qui correspond au nouveau LPN trouvé dans le composant de stockage sécurisé. Cette modification se produit lorsque l’utilisateur modifie les réglages de sécurité ou crée de nouveaux systèmes d’exploitation avec un nouveau fichier LocalPolicy pour chacun d’eux.

Hachage du nonce des règles distantes (rpnh)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le rpnh se comporte de façon identique au lpnh, mais il n’est mis à jour que lorsque les règles distantes sont mises à jour, par exemple lors de la modification de l’état d’inscription à Localiser. Cette modification se produit lorsque l’utilisateur modifie l’état de Localiser sur son Mac.

Hachage du nonce de recoveryOS (ronh)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le ronh se comporte de façon identique au lpnh, mais on le retrouve uniquement dans le fichier LocalPolicy pour le système recoveryOS. Il est mis à jour lorsque le système recoveryOS est mis à jour, comme lors de mises à jour logicielles. Une valeur antirejeu séparée du lpnh et du rpnh est utilisée de sorte que lorsqu’un appareil est désactivé au moyen de Localiser, les systèmes d’exploitation existants peuvent être désactivés (en supprimant leur LPN et leur RPN du composant de stockage sécurisé) sans empêcher le démarrage du système recoveryOS. Ainsi, les systèmes d’exploitation peuvent être réactivés lorsque le propriétaire prouve son contrôle sur le système en saisissant son mot de passe iCloud utilisé pour le compte Localiser. Cette modification se produit lorsqu’un utilisateur met à jour le système recoveryOS ou crée de nouveaux systèmes d’exploitation.

Hachage du manifeste Image4 de l’étape suivante (nsih)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le champ nsih représente un hachage SHA384 de la structure de données du manifeste Image4 qui décrit le système macOS démarré. Le manifeste Image4 de macOS contient des mesures pour tous les objets de démarrage, tels qu’iBoot, le cache statique de confiance, l’arborescence de l’appareil, la collection du noyau de démarrage et le hachage racine du volume système signé (VSS). Lorsque le LLB reçoit l’ordre de démarrer un système macOS donné, il est conçu pour vérifier que le hachage du manifeste Image4 de macOS joint à iBoot correspond à la valeur enregistrée dans le champ nsih du fichier LocalPolicy. De cette manière, le nsih capture l’intention de l’utilisateur quant au système d’exploitation pour lequel l’utilisateur a créé un fichier LocalPolicy. Les utilisateurs modifient la valeur nsih de façon implicite lorsqu’ils effectuent une mise à jour logicielle.

Hachage du manifeste Image4 de Cryptex1 (spih)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le champ spih représente un hachage SHA384 de la structure de données du manifeste Image4 de Cryptex1. Le manifeste Image4 de Cryptex1 contient les mesures de ses cryptex, leurs sceaux de système de fichiers et leur cache de confiance associé. Lorsque macOS démarre, le noyau XNU et la couche de protection de page s’assurent que le hachage du manifeste Image4 de Cryptex1 correspond à ce que l’iBoot a publié à partir du champ spih du fichier LocalPolicy. Les utilisateurs modifient la valeur spih de façon implicite lorsqu’ils installent les améliorations rapides à la sécurité ou qu’ils effectuent une mise à jour logicielle. Le hachage du manifeste Image4 de Cryptex1 peut être mis à jour indépendamment du hachage du manifeste Image4 de l’étape suivante.

Génération Cryptex1 (stng)

• Type : Entier non signé de 64 bits

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le champ stng est un compteur qui indique la date de la dernière mise à jour du hachage du manifeste Image4 de Cryptex1 dans un fichier LocalPolicy. Il fournit une valeur antirejeu à la place de lpnh pendant l’évaluation de la couche de protection de page de la politique locale d’application du Cryptex entrant. Les utilisateurs augmentent la valeur stng de façon implicite lorsqu’ils installent les améliorations rapides à la sécurité ou qu’ils effectuent une mise à jour logicielle.

Hachage du règlement de l’AuxKC (auxp)

• Type : OctetString (48)

• Environnements mutables : macOS

• Description : L’auxp est un hachage SHA384 du règlement UAKL (User-Authorized Kext List, liste d’extensions de noyau autorisées par l’utilisateur). Il est utilisé au moment de la génération d’une AuxKC pour veiller à ce que seules les extensions de noyau autorisées par l’utilisateur soient incluses dans l’AuxKC. smb2 est une condition préalable pour configurer ce champ. Les utilisateurs modifient implicitement la valeur auxp lorsqu’ils modifient l’UAKL en approuvant une extension de noyau dans Réglages système > Confidentialité et sécurité (macOS 13 ou une version ultérieure) ou dans Préférences Système > Sécurité et confidentialité (macOS 12 ou une version antérieure).

Hachage du manifeste Image4 de l’AuxKC (auxi)

• Type : OctetString (48)

• Environnements mutables : macOS

• Description : Après que le système a vérifié que le hachage de l’UAKL correspond à la valeur du champ auxp du fichier LocalPolicy, il demande à l’application du processeur Secure Enclave chargée des signatures du fichier LocalPolicy de signer l’AuxKC. Ensuite, un hachage SHA384 de la signature du manifeste Image4 de l’AuxKC est stocké dans le fichier LocalPolicy pour éviter le risque de mélanger les AuxKC signées antérieurement et de les faire correspondre à un système d’exploitation au moment du démarrage. Si iBoot trouve le champ auxi dans le fichier LocalPolicy, il essaie de charger l’AuxKC à partir du stockage et valide sa signature. Il vérifie aussi que le hachage du manifeste Image4 joint à l’AuxKC correspond à la valeur du champ auxi. Si pour une raison quelconque le chargement de l’AuxKC échoue, le système poursuit son démarrage sans cet objet de démarrage et sans qu’aucune extension de noyau tierce ne soit chargée. Le champ auxp est une condition préalable à la configuration du champ auxi du fichier LocalPolicy. Les utilisateurs modifient implicitement la valeur auxi lorsqu’ils modifient l’UAKL en approuvant une extension de noyau dans Réglages système > Confidentialité et sécurité (macOS 13 ou une version ultérieure) ou dans Préférences Système > Sécurité et confidentialité (macOS 12 ou une version antérieure).

Hachage du reçu de l’AuxKC (auxr)

• Type : OctetString (48)

• Environnements mutables : macOS

• Description : L’auxr est un hachage SHA384 du reçu de l’AuxKC qui indique l’ensemble exact d’extensions de noyau comprises dans l’AuxKC. Le reçu de l’AuxKC est un sous-ensemble de l’UAKL, car les extensions de noyau peuvent être exclues de l’AuxKC même si elles sont autorisées par l’utilisateur lorsqu’elles sont réputées être le vecteur d’attaques. Par ailleurs, certaines extensions de noyau susceptibles d’être utilisées pour outrepasser la limite utilisateur-noyau peuvent occasionner une perte de fonctionnalité, telle que l’incapacité d’utiliser Apple Pay ou de visionner du contenu 4K et HDR. Les utilisateurs qui souhaitent utiliser ces fonctionnalités doivent opter pour une inclusion de l’AuxKC plus restrictive. Le champ auxp est une condition préalable à la configuration du champ auxr du fichier LocalPolicy. Les utilisateurs modifient implicitement la valeur auxr lorsqu’ils conçoivent une nouvelle AuxKC dans Réglages système > Confidentialité et sécurité (macOS 13 ou une version ultérieure) ou dans Préférences Système > Sécurité et confidentialité (macOS 12 ou une version antérieure).

Hachage du manifeste Image4 de CustomOS (coih)

• Type : OctetString (48)

• Environnements mutables : 1TR

• Description : Le coih est un hachage SHA384 du manifeste Image4 de CustomOS. L’entité de ce manifeste est utilisée par iBoot (à la place du noyau XNU) pour transférer le contrôle. Les utilisateurs modifient la valeur coih de façon implicite lorsqu’ils utilisent l’outil de ligne de commande kmutil configure-boot dans 1TR.

IDUU du groupe de volumes APFS (vuid)

• Type : OctetString (16)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le vuid indique le groupe de volumes que le noyau doit utiliser comme racine. Ce champ est principalement informatif et n’est pas utilisé pour appliquer des contraintes de sécurité. Ce champ vuid est configuré implicitement par l’utilisateur lors de la création de l’installation d’un système d’exploitation.

IDUU du groupe de la clé de chiffrement de clés (kuid)

• Type : OctetString (16)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le kuid indique le volume démarré. La clé de chiffrement des clés a généralement été utilisée à des fins de protection des données. Pour chaque fichier LocalPolicy, le kuid est utilisé pour protéger la clé de signature du fichier LocalPolicy. Le champ kuid est configuré implicitement par l’utilisateur lors de la création de l’installation d’un système d’exploitation.

Mesure de la règle de démarrage de confiance de couplage de recoveryOS (prot)

• Type : OctetString (48)

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Une mesure de la règle de démarrage de confiance (TBPM, Trusted Boot Policy Measurement) de couplage de recoveryOS est un calcul spécial, par itération, de hachage SHA384 appliqué au manifeste Image4 du fichier LocalPolicy, à l’exception des valeurs antirejeu, afin de fournir une valeur cohérente dans le temps (car les valeurs antirejeu telles que le lpnh sont actualisées fréquemment). Le champ prot se trouve uniquement dans le fichier LocalPolicy de chaque instance de macOS et fournit une valeur de couplage qui indique quel fichier LocalPolicy de recoveryOS correspond au fichier LocalPolicy de macOS.

Présence d’un fichier LocalPolicy de recoveryOS signé par le Secure Enclave (hrlp)

• Type : Booléenne

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : Le champ hrlp indique si la valeur prot ci-dessus est la mesure d’un fichier LocalPolicy de recoveryOS signé par le Secure Enclave. Si ce n’est pas le cas, le fichier LocalPolicy de recoveryOS est signé par le serveur de signature en ligne d’Apple, qui signe des éléments comme les fichiers Image4 de macOS.

Version du système d’exploitation local (love, Local Operating System Version)

• Type : Booléenne

• Environnements mutables : 1TR, recoveryOS, macOS

• Description : La valeur love indique la version du système d’exploitation pour lequel le fichier LocalPolicy est créé. La version est obtenue à partir du manifeste de l’état suivant lors de la création du fichier LocalPolicy et est utilisée pour appliquer les restrictions de couplage du recoveryOS.

Multidémarrage sécurisé (smb0)

• Type : Booléenne

• Environnements mutables : 1TR, recoveryOS

• Description : Si la valeur smb0 est présente et vérifiée, le LLB autorise la signature globale du manifeste Image4 de l’étape suivante au lieu d’exiger une signature personnalisée. Les utilisateurs peuvent modifier ce champ au moyen de l’utilitaire Sécurité au démarrage ou de bputil pour rétrograder le règlement de sécurité à Sécurité réduite.

Multidémarrage sécurisé (smb1)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur smb1 est présente et vérifiée, iBoot autorise les objets tels que la collection du noyau personnalisé à être signés par le Secure Enclave avec la clé qui a signé le fichier LocalPolicy. La présence de la valeur smb0 est une condition préalable de la présence de la valeur smb1. Ce champ peut être modifié par les utilisateurs au moyen d’outils de ligne de commande tels que csrutil ou bputil pour rétrograder le règlement de sécurité à Sécurité permissive.

Multidémarrage sécurisé (smb2)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur smb2 est présente et vérifiée, iBoot autorise la collection du noyau auxiliaire à être signée par le Secure Enclave avec la clé qui a signé le fichier LocalPolicy. La présence de la valeur smb0 est une condition préalable de la présence de la valeur smb2. Ce champ peut être modifié par les utilisateurs au moyen de l’utilitaire Sécurité au démarrage ou de bputil pour rétrograder le règlement de sécurité à Sécurité réduite et activer les extensions de noyau tierces.

Multidémarrage sécurisé (smb3)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur smb3 est présente et vérifiée, cela signifie qu’un utilisateur de l’appareil a confié le contrôle de son système à une solution de gestion des appareils mobiles (GAM). La présence de ce champ fait en sorte que l’application du processeur Secure Enclave qui contrôle le fichier LocalPolicy accepte les authentifications de la solution de GAM au lieu d’exiger l’authentification locale de l’utilisateur. Ce champ peut être modifié par les utilisateurs au moyen de l’utilitaire Sécurité au démarrage ou de bputil pour permettre le contrôle géré des extensions de noyau tierces et des mises à jour logicielles. (Sous macOS 11.2 et les versions ultérieures, la GAM peut également lancer une mise à jour vers la version de macOS la plus récente si le mode de sécurité est réglé à Sécurité maximale.)

Multidémarrage sécurisé (smb4)

• Type : Booléenne

• Environnements mutables : macOS

• Description : Si la valeur smb4 est présente et vérifiée, cela signifie que l’appareil a confié le contrôle du système d’exploitation à la solution de GAM au moyen d’Apple School Manager, d’Apple Business Manager ou d’Apple Business Essentials. La présence de ce champ fait en sorte que l’application du processeur Secure Enclave qui contrôle le fichier LocalPolicy accepte les authentifications de la solution de GAM au lieu d’exiger l’authentification locale de l’utilisateur. Ce champ est modifié par la solution de GAM lorsque le numéro de série d’un appareil apparaît dans l’un de ces trois services.

Protection de l’intégrité du système (sip0)

• Type : Entier non signé de 64 bits

• Environnements mutables : 1TR

• Description : La valeur sip0 comporte les bits du règlement de protection de l’intégrité du système qui étaient précédemment stockés dans la NVRAM. Les nouveaux bits du règlement de protection de l’intégrité du système sont ajoutés ici (plutôt que d’utiliser les champs du fichier LocalPolicy comme les champs suivants) s’ils sont utilisés uniquement dans macOS, et non par le LLB. Ce champ peut être modifié par les utilisateurs au moyen de csrutil à partir de 1TR pour désactiver la protection de l’intégrité du système et rétrograder le règlement de sécurité à Sécurité permissive.

Protection de l’intégrité du système (sip1)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur sip1 est présente et vérifiée, iBoot autorise les échecs de validation du hachage racine du VSS. Ce champ peut être modifié par les utilisateurs avec csrutil ou bputil à partir de 1TR.

Protection de l’intégrité du système (sip2)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur sip2 est présente et vérifiée, iBoot ne verrouillera pas le registre interne CTRR (Configurable Text Read-only Region, région configurable de lecture seule du texte) qui marque la mémoire du noyau comme n’étant pas inscriptible. Ce champ peut être modifié par les utilisateurs avec csrutil ou bputil à partir de 1TR.

Protection de l’intégrité du système (sip3)

• Type : Booléenne

• Environnements mutables : 1TR

• Description : Si la valeur sip3 est présente et vérifiée, iBoot n’appliquera pas sa liste d’autorisation intégrée pour la variable des arguments de démarrage de la mémoire vive non volatile, ce qui aurait pour effet de filtrer les options transmises au noyau. Ce champ peut être modifié par les utilisateurs avec csrutil ou bputil à partir de 1TR.

Certificats et élément RemotePolicy

Conformément à la description donnée dans la section Création et gestion de la clé de signature du fichier LocalPolicy, le manifeste Image4 du fichier LocalPolicy contient également l’OIC (Owner Identity Certificate, certificat d’identité du propriétaire) et l’élément RemotePolicy intégré.