Attestation d’appareil géré pour les appareils Apple
L’attestation d’appareil géré est une fonctionnalité d’iOS 16, iPadOS 16.1, macOS 14 et tvOS 16, ou ultérieur. L’attestation d’appareil géré offre de solides preuves concernant les propriétés d’un appareil qui peuvent servir dans le cadre d’une évaluation de confiance. Cette déclaration cryptographique des propriétés d’un appareil fondée sur la sécurité du coprocesseur Secure Enclave et des serveurs d’attestation d’Apple.
L’attestation d’appareil géré offre une protection contre les menaces suivantes :
Un appareil compromis mentant sur ses propriétés
Un appareil compromis fournissant une attestation obsolète
Un appareil compromis envoyant les identifiants d’un autre appareil
L’extraction d’une clé privée pour l’utiliser sur un appareil frauduleux
Un pirate détournant une demande de certificat pour tromper et inciter l’AC à lui délivrer un certificat
Pour en savoir plus, consultez la vidéo de l’édition 2024 de la WWDC What’s new in device management (en anglais).
Attestation dʼappareil géré avec requêtes dʼinscription de certificats ACME
Le service ACME de l’autorité de certification (AC) émettrice d’une organisation peut demander une attestation des propriétés de l’appareil à inscrire. Cette attestation garantit que les propriétés de l’appareil (son numéro de série, par exemple) sont légitimes et n’ont pas fait l’objet d’une opération de spoofing (usurpation d’identité). Le service ACME de l’AC émettrice peut valider de façon cryptographique l’intégrité des propriétés de l’appareil attesté et vérifier, s’il le souhaite, qu’elles concordent avec l’inventaire des appareils de l’organisation. Auquel cas, le service pourra confirmer que l’appareil appartient bien à l’organisation.
Si une attestation est utilisée, une clé privée liée à l’appareil par le matériel est générée au sein du coprocesseur Secure Enclave de l’appareil dans le cadre de la demande de signature de certificat. Pour cette demande, l’AC émettrice du service ACME peut alors délivrer un certificat client. Cette clé est liée au coprocesseur Secure Enclave et est par conséquent disponible uniquement sur un appareil spécifique. Elle peut être utilisée sur iPhone, iPad, Apple TV et Apple Watch avec des configurations prenant en charge la spécification d’une identité de certificat. Sur un Mac, les clés liées par le matériel peuvent être utilisées pour l’authentification auprès d’une solution MDM, de Microsoft Exchange, de Kerberos, de réseaux 802.1X, du client VPN intégré et du relais réseau intégré.
Remarque : le coprocesseur Secure Enclave intègre des mécanismes de protection extrêmement robustes contre l’extraction de clés, même lorsqu’un processeur d’applications est compromis.
Ces clés liées par le matériel sont supprimées automatiquement lors de l’effacement ou de la restauration d’un appareil. Étant donné que les clés sont supprimées, tous les profils de configuration reposant sur celles-ci ne fonctionneront plus après la restauration. Le profil doit être appliqué de nouveau pour que les clés soient recréées.
Fort de l’attestation des données utiles du ACME, la solution MDM peut inscrire l’identité du certificat d’un client à l’aide du protocole ACME, qui est capable de valider de façon cryptographique que :
L’appareil est un appareil Apple authentique
L’appareil est un appareil distinct
L’appareil est géré par le serveur MDM de l’organisation
L’appareil possède certaines propriétés (le numéro de série, par exemple)
La clé privée est liée à l’appareil par le matériel
Attestation d’appareil géré avec requêtes MDM
En plus de lʼutilisation de l’attestation d’appareil géré pendant des requêtes dʼinscription avec certificat ACME, une solution MDM peut émettre une requête DeviceInformation
afin d’obtenir une propriété DevicePropertiesAttestation
. Si la solution MDM souhaite s’assurer qu’elle possède l’attestation la plus récente, elle peut envoyer une clé DeviceAttestationNonce
facultative qui force l’émission d’une attestation actualisée. En cas de non-envoi de cette clé, l’appareil renvoie une attestation mise en cache. Dans sa réponse, l’attestation d’appareil inclut ensuite un certificat nœud terminal avec ses propriétés dans des OID personnalisés.
Remarque : Le numéro de série et l’UDID sont tous deux omis en cas d’utilisation de l’inscription d’utilisateurs pour protéger la vie privée de lʼutilisateur. Les autres valeurs sont anonymes ; elles comprennent des propriétés telles que la version sepOS et le code de fraîcheur.
La solution MDM peut ensuite valider la réponse après s’être assurée que l’autorité de certification Apple attendue se trouve à la base de la chaîne de certification (information accessible dans le référentiel PKI privé d’Apple). Elle vérifie également que le hachage du code de fraîcheur est le même que celui fourni dans la requête DeviceInformation
.
À l’heure actuelle, étant donné que la définition d’un code de fraîcheur génère une nouvelle attestation qui consomme des ressources sur l’appareil ainsi que sur les serveurs d’Apple, une seule attestation DeviceInformation
par appareil peut être générée tous les sept jours. Une solution MDM ne doit pas immédiatement demander une attestation à jour tous les 7 jours. À moins que les propriétés d’un appareil aient changé (mise à jour ou mise à niveau du système d’exploitation, par exemple), il n’est pas nécessaire de demander l’émission d’une attestation à jour. De plus, une demande aléatoire occasionnelle d’une attestation à jour peut permettre de repérer un appareil compromis qui tente de mentir à propos de ces propriétés.
Traitement des attestations échouées
Une demande d’attestation peut échouer. Lorsque cela se produit, l’appareil répond tout de même à la requête DeviceInformation
ou au défi device-attest-01
du serveur ACME, mais certaines informations sont omises. Soit l’OID attendu ou sa valeur sont omis, soit l’attestation est entièrement omise. De nombreuses raisons peuvent être à l’origine d’un échec, notamment :
un problème de réseau pour atteindre les serveurs d’attestation d’Apple ;
le matériel ou les logiciels de l’appareil peuvent être compromis ;
l’appareil n’est pas un matériel Apple authentique.
Dans ces deux derniers cas, les serveurs d’attestation d’Apple refusent d’émettre une attestation pour des propriétés qu’ils ne peuvent pas vérifier. La solution MDM ne dispose d’aucune manière fiable de connaître la cause exacte d’une attestation échouée. En effet, la seule source d’informations concernant l’échec est l’appareil lui-même, qui peut être un appareil compromis qui ment. C’est pourquoi les réponses de l’appareil n’indiquent pas la raison de l’échec.
Cependant, lorsque l’attestation d’appareil géré est utilisée dans le cadre d’une architecture sans confiance, l’établissement peut calculer un score de confiance pour l’appareil, une attestation échouée ou inopinément obsolète diminuant ce score. Un score de confiance inférieur déclenche différentes actions, telles que le refus d’accès aux services, le signalement de l’appareil en vue d’une investigation manuelle ou des mesures de mise en conformité en l’effaçant et en révoquant ses certificats si nécessaire. Cela garantit une réponse appropriée à une attestation échouée.