
Processus de démarrage d’un Mac avec puce Apple
Le démarrage d’un Mac avec puce Apple suit un processus semblable à celui d’un iPhone ou d’un iPad.

Lors de la première étape de la chaîne de confiance, la puce exécute du code à partir de la mémoire morte d’amorçage. Le démarrage sécurisé de macOS sur un Mac avec puce Apple vérifie le code du système d’exploitation même ainsi que les règlements de sécurité et les extensions de noyau (ces dernières sont prises en charge, mais leur utilisation n’est pas recommandée) configurées par les utilisateurs autorisés.
Lorsque le LLB (Low level Bootloader, amorçage de niveau inférieur) est lancé, il vérifie les signatures et charge les programmes internes couplés au système qui se rapportent aux cœurs du système sur une puce, comme les contrôleurs de stockage, d’affichage, de gestion système et Thunderbolt. Le LLB est également responsable du chargement du fichier LocalPolicy, qui est signé par le processeur Secure Enclave. Le fichier LocalPolicy décrit la configuration choisie par l’utilisateur pour démarrer le système ainsi que les règlements de sécurité de l’exécution. Le fichier LocalPolicy adopte le même format de structure de données que les autres objets de démarrage, sauf qu’au lieu d’être signé par un serveur central d’Apple (comme les mises à jour logicielles), il est signé localement par une clé privée qui est uniquement disponible au sein du Secure Enclave d’un ordinateur donné.
Pour contribuer à prévenir le rejeu de tout fichier LocalPolicy antérieur, le LLB doit chercher une valeur antirejeu dans le composant de stockage sécurisé rattaché au Secure Enclave. Pour ce faire, il utilise la mémoire morte d’amorçage du Secure Enclave et vérifie que la valeur antirejeu du fichier LocalPolicy correspond à celle du composant de stockage sécurisé. Cela contribue à empêcher tout ancien fichier LocalPolicy, dont le niveau de sécurité pourrait être inférieur, d’être de nouveau appliqué au système après que la sécurité a été mise à niveau. Par conséquent, le démarrage sécurisé d’un Mac avec puce Apple protège l’appareil de la rétrogradation du système d’exploitation et du règlement de sécurité tout à la fois.
Le fichier LocalPolicy détermine si la configuration de sécurité du système d’exploitation est maximale, réduite ou permissive.
Sécurité maximale : Le système se comporte comme iOS et iPadOS, et permet uniquement le démarrage du logiciel déterminé comme étant le plus récent au moment de l’installation.
Sécurité réduite : Le LLB est autorisé à approuver les signatures « globales » fournies avec le système d’exploitation. Cela permet au système d’exécuter des versions antérieures de macOS. On parle de sécurité réduite, car les versions antérieures de macOS comportent inévitablement des vulnérabilités non corrigées. Il s’agit du niveau de sécurité requis pour lancer des extensions de noyau.
Sécurité permissive : Le système agit selon un niveau de sécurité semblable à la sécurité réduite, car il utilise une vérification des signatures globales pendant et après iBoot, mais il indique également à iBoot d’accepter que certains objets de démarrage soient signés par le Secure Enclave avec la clé qui sert aussi à signer le fichier LocalPolicy. Ce niveau de règlement sert aux utilisateurs qui conçoivent, signent et exécutent leurs propres noyaux XNU.
Si le fichier LocalPolicy indique au LLB que le système d’exploitation sélectionné s’exécute en mode Sécurité maximale, le LLB évalue la signature personnalisée d’iBoot. S’il s’exécute en mode Sécurité réduite ou en mode Sécurité permissive, le LLB évalue la signature globale. Toute erreur de validation de la signature forcera le démarrage de recoveryOS pour proposer des options de réparation à l’utilisateur.
Lorsque le LLB passe le relais à iBoot, ce dernier charge les programmes internes couplés à macOS, comme ceux notamment associés au Neural Engine sécurisé, au processeur toujours actif et à d’autres programmes internes. iBoot analyse également les informations relatives au fichier LocalPolicy transmis par le LLB. Si le fichier LocalPolicy indique qu’il doit y avoir une collection du noyau auxiliaire (AuxKC), iBoot la recherche dans le système de fichiers, vérifie qu’elle est signée par le Secure Enclave au moyen de la même clé que pour le fichier LocalPolicy et valide son hachage en le comparant à celui stocké dans le fichier LocalPolicy. Si l’AuxKC est valide, iBoot la place dans la mémoire avec la collection du noyau de démarrage avant de verrouiller au moyen de la protection de l’intégrité du coprocesseur système (SCIP, System Coprocessor Integrity Protection) toute la zone de mémoire qui couvre ces deux collections. Si la politique indique qu’une AuxKC doit être présente alors qu’elle est introuvable, le démarrage de macOS se poursuit tout en ignorant la collection en question. iBoot est également chargé de vérifier le hachage racine du volume système signé (VSS) pour confirmer la vérification complète de l’intégrité du système de fichiers que le noyau va monter.