Secure Boot (från engelska - "secure boot") är ett protokoll som ingår i UEFI- specifikationen [1] . Den består i att verifiera den elektroniska digitala signaturen för körande EFI-applikationer med hjälp av asymmetrisk kryptografi med avseende på nycklar lagrade i systemets nyckellager.
Under 2011 inkluderade Microsoft i kraven för certifiering av datorer som kör Windows 8 leveransvillkoret för sådana system med säker start aktiverad med hjälp av en Microsoft-nyckel. Dessutom krävde ARM-system (smarttelefoner och vissa bärbara datorer) oförmågan att inaktivera Secure Boot. Detta orsakade ett stort offentligt ramaskri och kritik mot Microsoft, eftersom sådana krav gjorde det mycket svårare, och i fallet med ARM-system, att installera andra operativsystem än Microsoft Windows [2] [3] [4] .
Autentiserad variabel – Variabler som kräver autentisering för att ändras. Säker start innebär lagring av publika nycklar, signaturer och programhashar i autentiserade variabler som lagras i icke-flyktigt minne. Sådana variabler kan skrivas över på två sätt [5] [6] [7] :
Övergången till detta läge är möjlig från användarläget genom att rensa PK.
Det här läget kräver ingen autentisering för att skriva PK, KEK, db, dbx.
PK-posten sätter systemet i användarläge. Att skriva en enhet till den speciella variabeln AuditMode (skrivbar endast i konfigurationsläge och användarläge) försätter systemet i revisionsläge.
Revisionsläge (revisionsläge)Det är möjligt att byta till detta läge från inställningsläget eller användarläget genom att skriva en enhet till variabeln AuditMode. När du ändrar läget till granskningsläge rensas PK.
Det här läget kräver ingen autentisering för att skriva PK, KEK, db, dbx. I granskningsläge kan overifierade bilder startas, och information om alla stadier av bildvalidering kommer att registreras i en speciell tabell som är tillgänglig från operativsystemet, som låter dig testa kombinationer av sparade nycklar och signaturer utan rädsla för att förlora systemet [9 ] .
PK-posten sätter systemet i driftsatt läge.
Användarläge (användarläge)Att byta till detta läge är möjligt från inställningsläget genom PK-post, eller från det distribuerade läget med en plattformsberoende metod (ej specificerad i specifikationen).
Detta läge kräver autentisering för att ändra nyckellager och validerar startbilder.
Om du tar bort PK:n försätts systemet i inställningsläge. Att skriva 1 till variabeln AuditMode sätter systemet i revisionsläge. Att skriva en till variabeln DeployedMode (skrivbar endast i användarläge) sätter systemet i distribuerat läge.
Utplacerat lägeAtt byta till detta läge är möjligt från granskningsläge genom att skriva PK, eller från användarläge genom att skriva en till variabeln DeployedMode.
Det säkraste läget [9] . Skiljer sig från användarläge genom att ställa in alla lägesvariabler (AuditMode, DeployedMode, SetupMode) till skrivskyddat läge.
Att byta till andra lägen (anpassat eller konfigurationsläge) är endast möjligt genom plattformsspecifika metoder eller autentiserad PK-rensning [9] .
Innan en okänd UEFI-avbildning körs måste den gå igenom en auktoriseringsprocess.
Uppdatering av databasen med betrodda applikationer är också tillgänglig från operativsystemet [10] .
Användaren kan självständigt generera och installera sina egna nycklar. Skapa dem själv, signera dem och installera dem på din dator. Nyckelgenereringens "fulla cykel" implementeras för både Linux och Windows operativsystem.
Som regel används följande kedja av transformationer i processen för nyckelgenerering:
PEM => DER => ESL => AUTH
För Windows finns specialverktyg från Microsoft, och på Linux används OpenSSL och EfiTools uppsättning verktyg. Det finns ett problem relaterat till avsaknaden av ett gränssnitt för att ställa in anpassade nycklar i BIOS hos vissa tillverkare. Detta kräver ibland också ett separat verktyg.
Ytterligare komplexitet skapar behovet av att säkerställa kompatibilitet med utrustning från Microsoft i vissa fall. Kontrollen fungerar åt båda hållen och utan Microsoft-nycklar, deras mjukvara och hårdvara (till exempel GOP-drivrutiner för externa grafikkort och PXE-drivrutiner för externa nätverkskort, och därmed själva korten) kommer inte att fungera. Det vill säga, på en viss nivå måste du lita på MS i alla fall.
Användaren måste lägga till nyckeln från Microsoft till db eller KEK, vilket introducerar ytterligare säkerhetsrisker.
Det kan finnas flera KEK och db på en dator. På så sätt kan flera förtroendegrenar bildas. Eller vice versa, en db kan signeras av flera KEC (även om detta inte krävs)
HP Sure Start - en lösning från Hewlett-Packard, är faktiskt en inbyggd hård- och mjukvara SDZ. Implementerar funktionen Secure Boot-nyckelskydd. Secure Boot i sin nuvarande form erbjuds av Microsoft som en minimisäkerhetsstandard för att skydda mot rootkits. Samtidigt utvecklar vissa tillverkare sina egna lösningar som ger pålitlig start i samband med en lösning från Microsoft, ett exempel på en sådan lösning är HP Sure Start [11] .
När rootkits stör kritiska komponenter i operativsystemet blir signaturerna för motsvarande komponenter ogiltiga. Ett sådant operativsystem kommer helt enkelt inte att laddas [12] .
Om det behövs, begränsa listan över möjliga operativsystem som ska köras, detta kan göras genom att ange lämpliga signaturer i signaturdatabasen [12] .
Enhetsdrivrutiner som kräver support vid systemstartstadiet måste ha en signatur som korrekt klarar verifieringen på alla plattformar där sådana enheter kan användas. För att göra detta måste alla tillverkare av sådan utrustning komma överens med alla tillverkare av plattformar för att lägga till sina nycklar till systembutikerna. Eller så måste sådana drivrutiner signeras med en nyckel som redan ingår i de flesta plattformar, men då måste tillverkarna helt och hållet förlita sig på ägaren av en sådan nyckel (till exempel signerar Microsoft shim bootloader [13] [14] ) . Det är också möjligt att skapa signaturer i en kedja som slutar med en nyckel som finns i de flesta plattformar, men även detta tillvägagångssätt har en nackdel - när motsvarande nyckel tas bort från nyckellagret (till exempel för att förbjuda att ladda ett visst operativsystem) , förarens signaturer blir också ogiltiga [12] .
Systemleverantörer behöver inte implementera möjligheten att inaktivera Secure Boot. Proceduren för att lägga till tredjepartsnycklar till valvet måste vara otillgänglig för skadlig programvara, vilket gör denna procedur svårare för användarna. Dessa två faktorer tillsammans gör det mycket svårare att använda osignerade operativsystem, såväl som de som signeras med en nyckel som är okänd för plattformen [12] .
Specifika firmware-implementeringar av enheter från olika tillverkare kan innehålla sårbarheter, vars utnyttjande kan leda till förbikoppling av Secure Boot-mekanismen eller dess utjämning [15] [16] .
Secure Boot-mekanismen kan förhindra att betrodda startverktyg fungerar. Eftersom SDZ ersätter OS-starthanteraren med sin egen starthanterare, som vanligtvis inte har en signatur, kan Secure Boot blockera SDZ-starthanteraren och därför störa driften av SDZ som helhet.
Det finns två lösningar på detta problem.
Den första är att inaktivera Secure Boot på datorer med SDZ installerat. Ett exempel på ett sådant tillvägagångssätt är SDZ SafeNode System Loader [17] .
Den andra är leveransen av en uppsättning autentiserade variabler tillsammans med SDZ, som intygar giltigheten av laddarens signatur. Efter att ha ställt in variablerna kommer SDZ att fungera utan begränsningar från Secure Boot. Ett exempel på detta tillvägagångssätt är Dallas Lock SDZ. I det här fallet levereras även verktyget keytool.efi [18] med nycklarna .