Sécurité du processus d’attestation
Sécurité du processus d’attestation
Lorsque la configuration ACME précise une clé liée au matériel, ou que le service de gestion des appareils demande une attestation DeviceInformation, l’appareil utilise les étapes suivantes :
Le système d’exploitation demande au Secure Enclave une clé liée au matériel appelée clé attestée. Pour l’attestation ACME, cette clé fait partie de l’identité de certificat émise. Pour l’attestation
DeviceInformation, la clé est générée par le système d’exploitation et réutilisée pour toutes les attestationsDeviceInformationsubséquentes pour toute la durée de l’inscription.Le système d’exploitation demande une attestation matérielle au Secure Enclave. Il précise la clé attestée, le code de fabrication et les propriétés à attester.
Le Secure Enclave génère et renvoie une nouvelle attestation matérielle.
Le système d’exploitation envoie l’attestation matérielle aux serveurs d’attestation d’Apple.
Les serveurs d’attestation valident la demande, puis refusent d’émettre un certificat d’attestation ou génèrent une attestation qui ne contient que les propriétés et valeurs confirmées. La clé publique du certificat d’attestation correspond à la clé attestée.
Le système d’exploitation fournit le certificat d’attestation qui en résulte au service de gestion des appareils ou à la solution ACME.
Pour en savoir plus sur la validation du certificat d’attestation fourni, consultez la rubrique Validation d’une attestation d’appareil géré sur le site Web Apple Developer (en anglais).
À propos de l’attestation matérielle
Lorsque le Secure Enclave génère une attestation matérielle, celle-ci comprend notamment les éléments suivants :
les identifiants de la carte logique principale
la clé publique de la clé attestée
les hachages des éléments logiciels suivants qui sont calculés pendant le processus de démarrage et stockés dans les registres matériels (ce qui s’apparente à la protection scellée des clés) :
le programme interne du Secure Enclave (sepOS)
le manifeste Image4 joint au LLB qui contient également une mesure de tout autre programme interne couplé au système
le manifeste Image4 du système d’exploitation qui contient des mesures de tous les programmes internes couplés au système d’exploitation
d’autres valeurs propres à l’appareil comme l’ECID et le ChipID
les détails du fichier LocalPolicy (sur les ordinateurs Mac)
le code de fabrication
Si le Secure Enclave est incapable de développer la clé attestée, le Secure Enclave refuse de générer une attestation matérielle. Cela garantit que la clé attestée est liée à ce Secure Enclave spécifique et toutes les autres propriétés attestées sont associées à cette clé.
Tous ces éléments sont compilés dans une structure binaire personnalisée et signée avec l’UIK. L’attestation matérielle est ainsi liée à une identité spécifique que les attestations d’Apple peuvent vérifier, ce qui leur permet d’associer la demande à un dossier d’activation spécifique et par le fait même à un dossier de fabrication spécifique.
Génération du certificat d’attestation
Voici ce que les serveurs d’attestation d’Apple font lorsqu’ils reçoivent une demande d’attestation :
Ils valident la clé d’identité de l’utilisateur (UIK). Si la signature n’est pas valide, aucune attestation n’est générée.
Ils recherchent le composant
ucrtdans les dossiers d’activation d’Apple qui correspond à la clé publique de l’UIK. Si aucun composantucrtn’est trouvé, aucune attestation n’est générée.Ils recherchent le composant
scrtqui correspond au composantucrtde l’appareil. Le composantscrtest un certificat émis par les serveurs d’Apple pendant la fabrication en fonction de la clé d’identité de la puce (SIK). Le Secure Enclave génère la SIK, et sa clé publique est obtenue de l’appareil pendant la fabrication. La SIK est utilisée pendant l’activation pour vérifier que le Secure Enclave de l’appareil en cours d’activation possède la clé privée. La SIK est conservée pendant toute la durée de vie d’un appareil et sert d’identifiant unique. Le dossier de fabrication de l’appareil est récupéré au moyen du composantscrt. Si aucun dossier n’est trouvé, aucune attestation n’est générée.Ils vérifient que les identifiants des composants matériels correspondent aux dossiers de fabrication. Si les identifiants des composants ne correspondent pas aux dossiers de fabrication, aucune attestation n’est générée.
Ils copient le code de fabrication dans l’attestation, le cas échéant.
Si l’attestation l’exige :
Ils comparent les hachages calculés des composants logiciels aux hachages provenant des dossiers de création. En cas de correspondance, le numéro de version officiel est inséré dans l’attestation. Sinon, l’OID est omis ou sa valeur est vide.
Lorsque les images pour le LLB, le Secure Enclave ou le système d’exploitation principal sont créées, les hachages sont calculés et enregistrés dans une base de dossiers de création avec les numéros de version officiels de ces images.
Ils calculent l’UDID à partir de l’ECID et du ChipID.
Ils copient dans l’attestation les valeurs des OID demandés à partir du fichier LocalPolicy si l’appareil est un Mac.
Le résultat pratique de ces validations est qu’aucune attestation n’est générée si les serveurs d’attestation ne reconnaissent pas l’appareil comme un matériel Apple authentique. Les propriétés du certificat d’attestation sont incluses uniquement si les serveurs d’attestation sont en mesure de vérifier la valeur de la propriété, sauf pour le code de fabrication qui est inclus sans validation.