Innehåll i en LocalPolicy-fil för Mac-datorer med Apple Silicon

Överlämnande av ägarskap mellan operativsystem

Tillgång till OIK (Owner Identity Key) kallas för ”ägarskap”. Ägarskap krävs för att tillåta användare att omsignera LocalPolicy när policy- eller programvaruändringar har gjorts. OIK skyddas med samma nyckelhierarki som beskrivs i SKP (Sealed Key Protection), där OIK skyddas av samma KEK (Key Encryption Key) som VEK (Volume Encryption Key). Det innebär att det normalt skyddas av både användarlösenord och mätvärden från operativsystemet och policyn. Det finns endast en enda OIK för alla operativsystem på datorn. Vid installation av ett andra operativsystem krävs därför uttryckligt godkännande från användarna i det första operativsystemet för att överlämna ägarskapet till användarna i det andra operativsystemet. Det finns dock ännu inga användare i det andra operativsystemet när installeraren körs från det första operativsystemet. Användare genereras normalt inte i operativsystem förrän operativsystemet startas och inställningsassistenten körs. Därför krävs två nya åtgärder vid installation av ett andra operativsystem på Mac-datorer med Apple Silicon:

• Skapa en LocalPolicy för det andra operativsystemet.

• Förbereda en ”installationsanvändare” för överlämnande av ägarskapet.

När en inställningsassistent och en målinstallation för en sekundär tom volym körs får användaren frågan om en användare från den aktuella volymen ska kopieras och skapas som den första användaren på den andra volymen. Om användaren svarar ja blir den ”installationsanvändare” som skapas i praktiken en KEK som härleds från den valda användarens lösenord och maskinvarunycklar, och som sedan används till att kryptera OIK när den överlämnas till det andra operativsystemet. Inställningsassistenten för det andra operativsystemet ber sedan om den användarens lösenord för att tillåta användaren tillgång till OIK i Secure Enclave för det nya operativsystemet. Om användare väljer att inte kopiera en användare skapas installationsanvändaren på samma sätt, men ett tomt lösenord används istället för en användares lösenord. Det här andra flödet finns för användning vid vissa systemadministrationsscenarier. Användare som vill installera med flera volymer och som vill utföra överlämnade av ägarskap så säkert som möjligt bör dock alltid välja att kopiera en användare från det första operativsystemet till det andra operativsystemet.

LocalPolicy på Mac-datorer med Apple Silicon

För Mac-datorer med Apple Silicon har styrningen av lokala säkerhetspolicyer delegerats till en app som körs i Secure Enclave. Denna programvara kan utnyttja användarens behörighet och startläget för den primära processorn till att bestämma vem som kan ändra säkerhetspolicyn och från vilken startmiljö. Detta hjälper till att förhindra att sabotageprogram använder styrfunktionerna för säkerhetspolicyn mot användaren genom att nedgradera dem för att få fler behörigheter.

Manifestegenskaper för LocalPolicy

LocalPolicy-filen innehåller en del arkitektoniska 4CC:er som finns i nästan alla Image4-filer, som ett kort- eller modell-ID (BORD) som indikerar en viss Apple-krets (CHIP) eller ECID (Exclusive Chip Identification). 4CC:erna nedan fokuserar dock endast på de säkerhetspolicyer som användare kan konfigurera.

LocalPolicy Nonce Hash (lpnh)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: Detta lpnh-värde används för anti-replay av LocalPolicy. Detta är en SHA384-hash av LocalPolicy Nonce (LPN) som lagras i SSC och är åtkomlig med Secure Enclaves Boot ROM eller Secure Enclave. Det råa anti-replay-värdet är aldrig synligt för approcessorn, endast för sepOS. En angripare som vill övertyga LLB om att en föregående LocalPolicy de har fångat in är giltig skulle behöva placera ett värde i SSC som hashas till samma lpnh-värde som hittas i den LocalPolicy som de vill återanvända. Normalt finns det en enda giltig LPN i systemet. Undantaget är under pågående programuppdatering när två LPN är giltiga samtidigt, detta för att tillåta möjligheten att återgå till start av den gamla programvaran om ett uppdateringsfel inträffar. När en LocalPolicy för något operativsystem ändras blir alla policyer omsignerade med det nya lpnh-värde som motsvarar den nya LPN som finns i SSC. Ändringen görs när användaren ändrar säkerhetsinställningar eller skapar nya operativsystem med en ny LocalPolicy för vardera system.

Remote Policy Nonce Hash (rpnh)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: Detta rpnh-värde beter sig på samma sätt som lpnh men uppdateras endast när Remote Policy uppdateras, exempelvis när status ändras för Hitta-registreringen. Ändringen görs när användaren ändrar status för Hitta på datorn.

recoveryOS Nonce Hash (ronh)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: Detta ronh-värde beter sig på samma sätt som lpnh men finns endast i LocalPolicy för systemets recoveryOS. Det uppdateras när systemets recoveryOS uppdateras, exempelvis vid programuppdateringar. Ett separat anti-replay-värde från lpnh och rpnh används så att befintliga operativsystem avaktiveras (genom att ta bort deras LPN och RPN från SSC) när en enhet avaktiveras via Hitta, samtidigt som systemets recoveryOS fortfarande går att starta. På så vis kan operativsystemet återaktiveras när systemägaren bevisar att han eller hon har kontroll över systemet genom att ange sitt iCloud-lösenord för Hitta-kontot. Ändringen görs när en användare uppdaterar systemets recoveryOS eller skapar nya operativsystem.

Next Stage Image4 Manifest Hash (nsih)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: Detta nsih-fält representerar en SHA384-hash av Image4-manifestdatastrukturen som beskriver det startade macOS-systemet. macOS Image4-manifestet innehåller åtgärder för alla startobjekt som iBoot, den statiska tillförlitlighetscachen, enhetsträd, startkärnsamling och rothash för den signerade systemvolymen (SSV). När LLB instrueras att starta ett givet macOS är det meningen att det ska säkerställa att hashen för macOS Image4-manifestet som är bifogat till iBoot matchar informationen i fältet nsih i LocalPolicy. På så vis bekräftar nsih användarens avsikt gällande vilket operativsystem användaren har skapat en LocalPolicy för. Användarna ändrar implicit nsih-värdet när de utför en programuppdatering.

Hash för Cryptex1 Image4-manifest (spih)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: spih-fältet representerar en SHA384-hash av Cryptex1 Image4-manifestdatastrukturen. Cryptex1 Image4-manifestet innehåller värden i dess cryptexar, deras filsystemssigill och deras associerade tillförlitlighetscache. När macOS startar säkerställer XNU-kärnan och Page Protection Layer att hashen av Cryptex1 Image4-manifestet matchar det som iBoot publicerade från spih-fältet i LocalPolicy. Användarna ändrar implicit spih-värdet när de installerar ett snabbt säkerhetssvar eller utför en programuppdatering. Hashen för Cryptex1 Image4-manifestet kan uppdateras oberoende av Next Stage Image4-manifesthashen.

Cryptex1 Generation (stng)

• Typ: 64-bitars osignerat heltal

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: stng-fältet är ett räknarvärde som representerar när Cryptex1 Image4-manifesthashen senast uppdaterades i en LocalPolicy. Det tillhandahåller ett anti-replay-värde som ersätter lpnh under Page Protection Layers utvärdering av den lokala policyn för användning av Incoming Cryptex. Användarna ökar stng-värdet implicit när de installerar ett snabbt säkerhetssvar eller en programuppdatering.

Auxiliary Kernel Collection (AuxKC) Policy Hash (auxp)

• Typ: OctetString (48)

• Muterbara miljöer: macOS

• Beskrivning: Detta auxp är en SHA384-hash för den användarauktoriserade policyn för kärntillägg (user-authorized kext list, UAKL). Den används vid tidpunkten för AuxKC-generering för att säkerställa att endast användarauktoriserade kärntillägg inkluderas i AuxKC. smb2 är ett krav för att ställa in detta fält. Användarna ändrar implicit auxp-värdet när de ändrar UAKL genom att godkänna ett kärntillägg från Integritet och säkerhet i Systeminställningar (macOS 13 eller senare) eller inställningspanelen Säkerhet och integritet i Systeminställningar (macOS 12 eller tidigare).

Auxiliary Kernel Collection (AuxKC) Image4 Manifest Hash (auxi)

• Typ: OctetString (48)

• Muterbara miljöer: macOS

• Beskrivning: När systemet har verifierat att UAKL-hashen matchar med informationen i fältet auxp i LocalPolicy begär det att AuxKC ska signeras av den Secure Enclave-processorapp som ansvarar för LocalPolicy-signering. Därefter placeras en SHA384-hash för AuxKC Image4-manifestsignaturen i LocalPolicy för att undvika risken att tidigare signerade AuxKC:er mixas och matchas till ett operativsystem vid start. Om iBoot hittar fältet auxi i LocalPolicy försöker det läsa in AuxKC från lagringsutrymmet och validera dess signatur. Det verifierar även att hashen för det Image4-manifest som är bifogat till AuxKC matchar det värde som finns i fältet auxi. Om AuxKC av någon anledning inte läses in korrekt fortsätter systemet att starta utan det här startobjektet, och därför utan att några kärntillägg från tredje part blir inlästa. Fältet auxp är en förutsättning för att ställa in fältet auxi i LocalPolicy. Användarna ändrar implicit auxi-värdet när de ändrar UAKL genom att godkänna ett kärntillägg från Integritet och säkerhet i Systeminställningar (macOS 13 eller senare) eller inställningspanelen Säkerhet och integritet i Systeminställningar (macOS 12 eller tidigare).

Auxiliary Kernel Collection (AuxKC) Receipt Hash (auxr)

• Typ: OctetString (48)

• Muterbara miljöer: macOS

• Beskrivning: auxr är en SHA384-hash för AuxKC-kvittot som indikerar den exakta uppsättning kärntillägg som ingår i AuxKC. AuxKC-kvittot kan vara en delmängd av UAKL eftersom kärntillägg kan exkluderas från AuxKC, även om de auktoriserats av användaren, om de är kända för att användas för angrepp. Dessutom kan vissa kärntillägg som kan användas till att bryta gränsen mellan användare och kärna leda till minskad funktionalitet, exempelvis att det inte går att använda Apple Pay eller spela upp 4K- och HDR-innehåll. Användare som vill ha de här funktionerna väljer en mer restriktiv AuxKC-inkludering. Fältet auxp är en förutsättning för att ställa in fältet auxr i LocalPolicy. Användarna ändrar implicit auxr-värdet när de bygger en ny AuxKC från Integritet och säkerhet i Systeminställningar (macOS 13 eller senare) eller inställningspanelen Säkerhet och integritet i Systeminställningar (macOS 12 eller tidigare).

Hash för CustomOS Image4-manifestet (coih)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR

• Beskrivning: coih är en SHA384-hash i CustomOS Image4-manifestet. Nyttolasten för det manifestet används av iBoot (i stället för XNU-kärnan) till att överföra styrning. Användare ändrar implicit coih-värdet när de använder kommandoradsverktyget kmutil configure-boot i 1TR.

APFS volume group UUID (vuid)

• Typ: OctetString (16)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: vuid indikerar den volymgrupp kärnan ska använda som rot. Det här fältet är primärt upplysande och används inte för säkerhetsbegränsningar. Detta vuid ställs in implicit av användaren när en ny operativsystemsinstallation skapas.

Key encryption key (KEK) Group UUID (kuid)

• Typ: OctetString (16)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: kuid indikerar den volym som startas. KEK har typiskt använts för dataskydd. För varje LocalPolicy används den till att skydda LocalPolicy-signeringsnyckeln. kuid ställs in implicit av användaren när en ny operativsystemsinstallation skapas.

Paired recoveryOS Trusted Boot Policy Measurement (prot)

• Typ: OctetString (48)

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: Ett parkopplat recoveryOS-TBPM (Trusted Boot Policy Measurement) är en särskild iterativ SHA384-hashberäkning över Image4-manifestet för en LocalPolicy-fil, exklusive anti-replay-värden, för att ge ett konsekvent värde över tid (eftersom anti-replay-värden som lpnh uppdateras ofta). Fältet prot, som bara finns i vardera LocalPolicy-fil för macOS, tillhandahåller en parkoppling för att indikera den LocalPolicy för recoveryOS som motsvarar LocalPolicy för macOS.

Has Secure Enclave Signed recoveryOS LocalPolicy (hrlp)

• Typ: Booleskt

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: hrlp-värdet indikerar om prot-värdet ovan är mätvärdet för en Secure Enclave-signerad LocalPolicy för recoveryOS eller inte. Om inte signeras LocalPolicy för recoveryOS av Apples onlinesigneringsserver som signerar sådant som exempelvis macOS Image4-filer.

Local Operating System Version (love)

• Typ: Booleskt

• Muterbara miljöer: 1TR, recoveryOS, macOS

• Beskrivning: love indikerar den OS-version som LocalPolicy är skapad för. Versionen hämtas från manifestet för nästa steg under skapandet av LocalPolicy och används till att genomdriva begränsningar av recoveryOS-parkoppling.

Secure Multi-Boot (smb0)

• Typ: Booleskt

• Muterbara miljöer: 1TR, recoveryOS

• Beskrivning: Om smb0 är befintlig och sann tillåter LLB global signering av Image4-manifestet för nästa steg istället för att kräva en personligt anpassad signatur. Användarna kan ändra detta fält med Startsäkerhetsverktyg eller bputil för att nedgradera till Minskad säkerhet.

Secure Multi-Boot (smb1)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om smb1 är befintlig och sann tillåter iBoot att objekt som en anpassad startkärnsamling Secure Enclave-signeras med samma nyckel som LocalPolicy. Närvaron av smb0 är ett krav för närvaron av smb1. Användarna kan ändra detta fält med kommandoradsverktyg som csrutil eller bputil för att nedgradera till Tillåtande säkerhet.

Secure Multi-Boot (smb2)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om smb2 är befintlig och sann tillåter iBoot att AuxKC Secure Enclave-signeras med samma nyckel som LocalPolicy. Närvaron av smb0 är ett krav för närvaron av smb2. Användarna kan ändra detta fält med Startsäkerhetsverktyg eller bputil för att nedgradera till Minskad säkerhet och göra det möjligt att använda kärntillägg från tredje part.

Secure Multi-Boot (smb3)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om smb3 är befintlig och sann har en användare vid enheten valt att låta MDM (Mobile Device Management) styra systemet. Närvaron av det här fältet får den Secure Enclave-processorapp som styr LocalPolicy att acceptera MDM-autentisering istället för att kräva autentisering av en lokal användare. Användarna kan ändra det här fältet med Startsäkerhetsverktyg eller bputil för att möjliggöra hanterad styrning av kärntillägg från tredje part och programuppdateringar. (I macOS 11.2 och senare kan MDM också starta en uppdatering till den senaste macOS-versionen om säkerhetsläget är Full säkerhet.)

Secure Multi-Boot (smb4)

• Typ: Booleskt

• Muterbara miljöer: macOS

• Beskrivning: Om smb4 är befintlig och sann har enheten anslutit till MDM-styrning av operativsystemet via Apple School Manager, Apple Business Manager eller Apple Business Essentials. Närvaron av det här fältet får den Secure Enclave-app som styr LocalPolicy att acceptera MDM-autentisering istället för att kräva autentisering av en lokal användare. Detta fält ändras av MDM-lösningen när den upptäcker att enhetens serienummer finns i någon av de tre tjänsterna.

Systemintegritetsskydd (sip0)

• Typ: 64-bitars osignerat heltal

• Muterbara miljöer: 1TR

• Beskrivning: sip0 innehåller de befintliga SIP-policybitar (systemintegritetsskydd) som tidigare lagrats i NVRAM. Nya SIP-policybitar läggs till här (istället för att använda LocalPolicy-fält som nedan) om de endast används i macOS och inte används av LLB. Användarna kan ändra detta fält genom användning av csrutil från 1TR till att avaktivera SIP och nedgradera till tillåtande säkerhet.

Systemintegritetsskydd (sip1)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om sip1 är befintlig och sann tillåter iBoot fel vid verifiering av volymrothashen för SSV-volymen. Användarna kan ändra detta fält med csrutil eller bputil från 1TR.

Systemintegritetsskydd (sip2)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om sip2 är befintlig och sann låser inte iBoot maskinvaruregistret CTRR (Configurable Text Read-only Region) som markerar kärnminnet som skrivskyddat. Användarna kan ändra detta fält med csrutil eller bputil från 1TR.

Systemintegritetsskydd (sip3)

• Typ: Booleskt

• Muterbara miljöer: 1TR

• Beskrivning: Om sip3 är befintlig och sann tvingar iBoot inte igenom användningen av dess inbyggda tillståndslista för NVRAM-variabeln i boot-args som annars skulle filtrera de alternativ som skickas till kärnan. Användarna kan ändra detta fält med csrutil eller bputil från 1TR.

Certifikat och RemotePolicy

Enligt vad som beskrivs i Skapa och hantera signeringsnyckeln för LocalPolicy innehåller LocalPolicy Image4-filen också ett OIC (Owner Identity Certificate) och en inbäddad RemotePolicy.