Secure Boot (fra engelsk - "secure boot") er en protokol, der er en del af UEFI -specifikationen [1] . Den består i at verificere den elektroniske digitale signatur af kørende EFI-applikationer ved hjælp af asymmetrisk kryptografi med hensyn til nøgler gemt i systemets nøglelager.
I 2011 inkluderede Microsoft i kravene til certificering af computere, der kører Windows 8 , leveringsbetingelserne for sådanne systemer med Secure Boot aktiveret ved hjælp af en Microsoft-nøgle. Desuden krævede ARM-systemer (smartphones og nogle bærbare computere) manglende evne til at deaktivere Secure Boot. Dette forårsagede et stort offentligt ramaskrig og kritik over for Microsoft, da sådanne krav gjorde det meget vanskeligere, og i tilfælde af ARM-systemer, at installere andre operativsystemer end Microsoft Windows [2] [3] [4] .
Autentificeret variabel - Variabler, der kræver godkendelse for at ændre sig. Sikker opstart involverer lagring af offentlige nøgler, signaturer og applikations-hash i autentificerede variabler gemt i ikke-flygtig hukommelse. Sådanne variabler kan overskrives på to måder [5] [6] [7] :
Overgangen til denne tilstand er mulig fra brugertilstanden ved at rydde PK.
Denne tilstand kræver ikke godkendelse for at skrive PK, KEK, db, dbx.
PK-indgangen sætter systemet i brugertilstand. Ved at skrive en enhed til den specielle variabel AuditMode (kun skrivbar i konfigurationstilstand og brugertilstand) sættes systemet i revisionstilstand.
Revisionstilstand (revisionstilstand)Skift til denne tilstand er muligt fra opsætningstilstand eller brugertilstand ved at skrive en enhed til AuditMode-variablen. Når du ændrer tilstanden til revisionstilstand, ryddes PK.
Denne tilstand kræver ikke godkendelse for at skrive PK, KEK, db, dbx. I revisionstilstand kan uverificerede billeder startes, og information om alle stadier af billedvalidering vil blive optaget i en speciel tabel tilgængelig fra operativsystemet, som giver dig mulighed for at teste kombinationer af gemte nøgler og signaturer uden frygt for at miste systemet [9 ] .
PK-indgangen sætter systemet i udrullet tilstand.
Brugertilstand (brugertilstand)Det er muligt at skifte til denne tilstand fra opsætningstilstanden ved PK-indtastning eller fra den implementerede tilstand ved hjælp af en platformafhængig metode (ikke specificeret i specifikationen).
Denne tilstand kræver godkendelse for at ændre nøglelagre og validerer startbilleder.
Fjernelse af PK'en sætter systemet i opsætningstilstand. Hvis du skriver 1 til AuditMode-variablen, sættes systemet i revisionstilstand. Hvis du skriver en til DeployedMode-variablen (kan kun skrives i brugertilstand), sættes systemet i udrullet tilstand.
Deployeret tilstandDet er muligt at skifte til denne tilstand fra revisionstilstand ved at skrive PK, eller fra brugertilstand ved at skrive en til variablen DeployedMode.
Den sikreste tilstand [9] . Adskiller sig fra brugertilstand ved at indstille alle tilstandsvariabler (AuditMode, DeployedMode, SetupMode) til skrivebeskyttet tilstand.
Skift til andre tilstande (brugerdefineret eller konfigurationstilstand) er kun muligt gennem platformsspecifikke metoder eller godkendt PK-rydning [9] .
Før du kører et ukendt UEFI-image, skal det gennemgå en godkendelsesproces.
Opdatering af databasen over betroede applikationer er også tilgængelig fra operativsystemet [10] .
Brugeren kan selvstændigt generere og installere deres egne nøgler. Generer dem selv, underskriv dem og installer dem på din computer. Den "fulde cyklus" af nøglegenerering er implementeret til både Linux- og Windows-operativsystemer.
Som regel bruges følgende kæde af transformationer i processen med nøglegenerering:
PEM => DER => ESL => AUTH
Til Windows er der specielle værktøjer fra Microsoft, og på Linux bruges OpenSSL og EfiTools-sættet af hjælpeprogrammer. Der er et problem relateret til manglen på en grænseflade til indstilling af brugerdefinerede nøgler i BIOS hos nogle producenter. Dette kræver også nogle gange et separat hjælpeprogram.
Yderligere kompleksitet skaber behov for at sikre kompatibilitet med udstyr fra Microsoft i nogle tilfælde. Kontrollen fungerer begge veje og uden Microsoft-nøgler, deres software og hardware (f.eks. GOP-drivere til eksterne videokort og PXE-drivere til eksterne netværkskort, og dermed selve kortene) vil ikke fungere. Det vil sige, at du på et vist niveau skal have tillid til MS under alle omstændigheder.
Brugeren bliver nødt til at tilføje nøglen fra Microsoft til db eller KEK, hvilket introducerer yderligere sikkerhedsrisici.
Der kan være flere KEK og db på én computer. På den måde kan der dannes flere tillidsgrene. Eller omvendt, en db kan underskrives af flere KEC'er (selvom dette ikke er påkrævet)
HP Sure Start - en løsning fra Hewlett-Packard, er faktisk en indbygget hardware og software SDZ. Implementerer funktionen Secure Boot-nøglebeskyttelse. Secure Boot i sin nuværende form tilbydes af Microsoft som en minimumssikkerhedsstandard til beskyttelse mod rootkits. Samtidig udvikler nogle producenter deres egne løsninger, der giver betroet boot i forbindelse med en løsning fra Microsoft, et eksempel på en sådan løsning er HP Sure Start [11] .
Når rootkits forstyrrer kritiske komponenter i operativsystemet, bliver signaturerne for de tilsvarende komponenter ugyldige. Et sådant operativsystem vil simpelthen ikke blive indlæst [12] .
Begræns eventuelt listen over mulige operativsystemer til at køre, dette kan gøres ved at indtaste de relevante signaturer i signaturdatabasen [12] .
Enhedsdrivere, der kræver support ved systemstartstadiet, skal have en signatur, der passerer korrekt verifikation på alle platforme, hvor sådanne enheder kan bruges. For at gøre dette skal alle producenter af sådant udstyr være enige med alle producenter af platforme om at tilføje deres nøgler til systembutikkerne. Eller sådanne drivere skal signeres med en nøgle, der allerede er inkluderet i de fleste platforme, men så bliver producenterne nødt til at stole helt på ejeren af en sådan nøgle (f.eks. underskriver Microsoft shim-bootloaderen [13] [14] ) . Det er også muligt at oprette signaturer i en kæde, der ender med en nøgle indeholdt i de fleste platforme, men selv denne tilgang har en ulempe - når den tilsvarende nøgle fjernes fra nøglelageret (for eksempel for at forbyde indlæsning af et bestemt operativsystem) , bliver driversignaturer også ugyldige [12] .
Systemleverandører er ikke forpligtet til at implementere muligheden for at deaktivere Secure Boot. Proceduren for tilføjelse af tredjepartsnøgler til boksen skal være utilgængelig for ondsindet software, hvilket gør denne procedure vanskeligere for brugerne. Disse to faktorer tilsammen gør det meget vanskeligere at bruge usignerede operativsystemer, såvel som dem, der er signeret med en nøgle, der er ukendt for platformen [12] .
Specifikke firmwareimplementeringer af enheder fra forskellige producenter kan indeholde sårbarheder, hvis udnyttelse kan føre til omgåelse af Secure Boot-mekanismen eller dens udjævning [15] [16] .
Secure Boot-mekanismen kan forhindre pålidelige opstartsværktøjer i at fungere. Da SDZ erstatter OS bootloader med sin egen bootloader, som generelt ikke har en signatur, kan Secure Boot blokere SDZ bootloader og derfor forstyrre driften af SDZ som helhed.
Der er to løsninger på dette problem.
Den første er at deaktivere Secure Boot på computere med SDZ installeret. Et eksempel på en sådan fremgangsmåde er SDZ SafeNode System Loader [17] .
Den anden er leveringen af et sæt af autentificerede variabler sammen med SDZ, der bekræfter gyldigheden af loaderens signatur. Efter indstilling af variablerne vil SDZ fungere uden begrænsninger fra Secure Boot. Et eksempel på denne tilgang er Dallas Lock SDZ. I dette tilfælde leveres værktøjet keytool.efi [18] også med tasterne .