Attestering af administreret enhed for Apple-enheder
Attestering af administreret enhed i iOS 16, iPadOS 16.1, macOS 14, tvOS 16 og nyere versioner. Attestering af administreret enhed vidner om egenskaberne for en enhed, der kan bruges som led i evaluering af tillid. Den kryptografiske deklaration af enhedsegenskaber er baseret på sikkerheden i Secure Enclave og Apples attesteringsservere.
Attestering af administreret enhed hjælper med at beskytte mod følgende trusler:
En kompromitteret enhed, der lyver om sine egenskaber
En kompromitteret enhed, der angiver en forældet attestering
En kompromitteret enhed, der sender en anden enheds id'er
Privat nøgleuddragelse til brug på en uautoriseret enhed
En angriber, der kaprer en certifikatanmodning for at snyde CA til at udstede et certifikat til angriberne
Du kan få flere oplysninger i videoen fra WWDC22 What’s new in device management.
Understøttet hardware til Attestering af administreret enhed
Attesteringer udstedes kun til enheder, der opfylder følgende hardwarekrav:
iPhone-, iPad- og Apple TV-enheder: med A11 Bionic-chip eller nyere.
Mac-computere: med Apple Silicon.
Der er ingen ændringer til Attestering af administreret enhed for Apple Watch og Apple Vision Pro.
Attestering af administreret enhed med ACME-anmodninger om certifikattilmelding
En organisations udstedende Certification Authority (CA) ACME-tjeneste kan anmode om attestering af den tilmeldende enheds egenskaber. Denne attestering giver stærk forsikring for, at enhedens egenskaber (f.eks. serienummeret) er gyldige og ikke forfalskede. Den udstedende certifikatmyndigheds ACME-tjeneste kan validere integriteten af egenskaberne for den attesterede enhed kryptografisk og eventuelt krydsreferere dem mod organisationens oversigt over enheder og – hvis verificering lykkes – bekræfte, at enheden er organisationens enhed.
Hvis der bruges attestering, genereres der en hardwareforbundet privat nøgle i enhedens Secure Enclave som en del af CSR (Certificate Signing Request). Den ACME-udstedende certifikatmyndighed kan derefter udstede et klientcertifikar til denne anmodning. Denne nøgle er bundet til Secure Enclave og er derfor kun tilgængelig på en specifik enhed. Den kan bruges på iPhone, iPad, Apple TV og Apple Watch med konfigurationer, der understøtter specifikation af en certifikatidentitet. På en Mac kan hardwareforbundne nøgler bruges til godkendelse med MDM, Microsoft Exchange, Kerberos, 802.1X-netværk, den indbyggede VPN-klient samt indbygget netværkskanal.
Bemærk: Secure Enclave har meget stærk beskyttelse mod nøgleuddragelse, selv i tilfælde af en kompromitteret app-processor.
Disse hardwareforbundne nøgler fjernes automatisk, når en enhed slettes eller gendannes. Da nøglerne er fjernet, vil evt. konfigurationsprofiler, som er afhængige af disse nøgler, ikke fungere efter en gendannelse. Profilen skal anvendes igen, før nøglerne kan oprettes.
Ved hjælp af attestering af data i ACME kan MDM tilmelde en klientcertifikatidentitet vha. den ACME-protokol, der kryptografisk kan validere følgende:
Enheden er en original Apple-enhed
Enheden er en speciel enhed
Enheden administreres af organisationens MDM-server
Enheden har bestemte egenskaber (f.eks. serienummeret)
Den private nøgle er hardwareknyttet til enheden
Attestering af administreret enhed med MDM-anmodninger
Udover at bruge attestering af en administreret enhed under ACME-anmodninger om certifikattilmelding kan en MDM-løsning udstede en DeviceInformation-forespørgsel, der anmoder om en DevicePropertiesAttestation-egenskab. Hvis MDM-løsningen ønsker at sikre en ny attestering, kan den sende en valgfri DeviceAttestationNonce-nøgle, som gennemtvinger en ny attestering. Hvis denne nøgle udelades, returnerer enheden en attestering indlæst i bufferen. Enhedsattesteringens svar returnerer derefter et bladcertifikat med egenskaberne i specielle OID'er.
Bemærk: Serienummer og UDID udelades begge ved brug af brugertilmelding med henblik på at beskytte brugerens anonymitet. De andre værdier er anonyme og inkluderer egenskaber som f.eks. sepOS-versionen og freshness-koden.
MDM-løsningen kan derefter validere svaret ved at evaluere, om certifikatkæden er baseret på den forventede Apple-certifikatmyndighed (tilgængelig fra Apple Private PKI Repository), og om freshness-kodens hash-værdi er den samme som hash-værdien af freshness-koden i forespørgslen DeviceInformation.
Definition af en freshness-kode genererer en ny attestering, som bruger ressourcer på enheden og Apples servere. Derfor er brugen begrænset til en DeviceInformation-attestering pr. enhed hver 7. dag. En MDM-løsning bør ikke anmode om en ny attestering med det samme hver 7. dag. Det betragtes ikke som nødvendigt at anmode om en ny attestering, medmindre en enheds egenskaber har ændret sig. Det er f.eks. tilfældet ved opdatering eller opgradering af systemversionen. Hvis der af og til sendes en vilkårlig anmodning om en ny attestering, bliver det måske også muligt at opfange en kompromitteret enhed, der forsøger at lyve om disse egenskaber.
Håndtering af mislykkede attesteringer
Anmodninger om attestering kan mislykkes. Hvis det sker, svarer enheden stadig på DeviceInformation-forespørgslen eller ACME-serverens device-attest-01-udfordring, men nogle oplysninger udelades. Enten udelades et forventet OID eller dets værdi, eller også udelades attesteringen fuldstændigt. Der er mange mulige årsager til mislykkede attesteringer, f.eks.:
Et netværksproblem, der påvirker Apples attesteringsservere
Hvis enhedens hardware eller software er kompromitteret
Hvis enheden ikke er original Apple-hardware
I de to sidste tilfælde nægter Apples attesteringsservere at udstede en attestering for egenskaber, de ikke kan bekræfte. MDM-løsningen kan ikke finde den nøjagtige årsag til, at en attestering mislykkes, på nogen pålidelig måde. Det skyldes, at den eneste kilde til oplysninger om årsagen er enheden selv, som kan være en kompromitteret enhed, der lyver. Derfor angiver svar fra enheden ikke årsagen til, at attesteringen mislykkedes.
Når Attestering af administreret enhed anvendes som del af en arkitektur med nul tillid, kan organisationen dog beregne en tillidsscore for enheden. En attestering, der mislykkes eller er mere forældet end forventet, reducerer denne score. En reduceret tillidsscore udløser forskellige handlinger, f.eks. at der nægtes adgang til tjenester, at enheden markeres til manuel undersøgelse, eller at man optrapper overholdelse ved at slette enheden og tilbagekalde dens certifikater, når det er nødvendigt. Det sikrer, at en mislykket attestering fører til en passende reaktion.