Secure Boot (din engleză - „secure boot”) este un protocol care face parte din specificația UEFI [1] . Constă în verificarea semnăturii digitale electronice a aplicațiilor EFI care rulează folosind criptografia asimetrică în raport cu cheile stocate în depozitul de chei al sistemului.
În 2011, Microsoft a inclus în cerințele de certificare a computerelor care rulează Windows 8 condiția de livrare a unor astfel de sisteme cu Secure Boot activat folosind o cheie Microsoft. Mai mult, sistemele ARM (smartphone-uri și unele laptopuri) au necesitat imposibilitatea de a dezactiva Secure Boot. Acest lucru a provocat o mare protestă publică și critici la adresa Microsoft, deoarece astfel de cerințe au făcut mult mai dificilă, și în cazul sistemelor ARM, instalarea altor sisteme de operare decât Microsoft Windows [2] [3] [4] .
Variabilă autentificată - Variabile care necesită autentificare pentru a se modifica. Secure Boot implică stocarea cheilor publice, semnăturilor și hash-urilor aplicației în variabile autentificate stocate în memoria nevolatilă. Astfel de variabile pot fi suprascrise în două moduri [5] [6] [7] :
Trecerea la acest mod este posibilă din modul utilizator prin ștergerea PK.
Acest mod nu necesită autentificare pentru a scrie PK, KEK, db, dbx.
Intrarea PK pune sistemul în modul utilizator. Scrierea unei unități la variabila specială AuditMode (scris numai în modul configurație și modul utilizator) pune sistemul în modul audit.
Audit Mode (mod audit)Trecerea la acest mod este posibilă din modul de configurare sau modul utilizator prin scrierea unei unități în variabila AuditMode. Când schimbați modul în modul audit, PK este șters.
Acest mod nu necesită autentificare pentru a scrie PK, KEK, db, dbx. În modul de audit, imaginile neverificate pot fi lansate, iar informațiile despre toate etapele validării imaginii vor fi înregistrate într-un tabel special accesibil din sistemul de operare, care vă permite să testați combinații de chei și semnături salvate fără teama de a pierde sistemul [9] ] .
Intrarea PK pune sistemul în modul implementat.
Modul utilizator (modul utilizator)Trecerea la acest mod este posibilă din modul de configurare prin introducerea PK sau din modul implementat folosind o metodă dependentă de platformă (nespecificată în specificație).
Acest mod necesită autentificare pentru a schimba depozitele de chei și pentru a valida imaginile de pornire.
Eliminarea PK-ului pune sistemul în modul de configurare. Scrierea 1 la variabila AuditMode pune sistemul în modul de audit. Scrierea unuia în variabila DeployedMode (inscriptibil numai în modul utilizator) pune sistemul în modul implementat.
Modul implementatTrecerea la acest mod este posibilă din modul de audit prin scrierea PK sau din modul utilizator prin scrierea unuia în variabila DeployedMode.
Cel mai sigur mod [9] . Diferă de modul utilizator prin setarea tuturor variabilelor de mod (AuditMode, DeployedMode, SetupMode) în modul numai citire.
Trecerea la alte moduri (mod personalizat sau de configurare) este posibilă numai prin metode specifice platformei sau prin ștergere PK autentificată [9] .
Înainte de a rula o imagine UEFI necunoscută, aceasta trebuie să treacă printr-un proces de autorizare.
Actualizarea bazei de date a aplicațiilor de încredere este disponibilă și din sistemul de operare [10] .
Utilizatorul poate genera și instala în mod independent propriile chei. Generați-le singur, semnați-le și instalați-le pe computer. „Ciclul complet” de generare a cheilor este implementat atât pentru sistemele de operare Linux, cât și pentru Windows.
De regulă, următorul lanț de transformări este utilizat în procesul de generare a cheilor:
PEM => DER => ESL => AUTH
Pentru Windows, există instrumente speciale de la Microsoft, iar pe Linux sunt folosite OpenSSL și setul de utilitare EfiTools. Există o problemă legată de lipsa unei interfețe pentru setarea cheilor personalizate în BIOS-ul unor producători. Acest lucru necesită uneori și o utilitate separată.
Complexitatea suplimentară creează necesitatea de a asigura compatibilitatea cu echipamentele de la Microsoft în unele cazuri. Verificarea funcționează în ambele sensuri și fără cheile Microsoft, software-ul și hardware-ul lor (de exemplu, driverele GOP pentru plăcile video externe și driverele PXE pentru plăcile de rețea externe și, prin urmare, plăcile în sine) nu vor funcționa. Adică, la un anumit nivel, va trebui să ai încredere în SM în orice caz.
Utilizatorul va trebui să adauge cheia de la Microsoft la db sau KEK, ceea ce introduce riscuri suplimentare de securitate.
Pot exista mai multe KEK și db pe un computer. În acest fel, se pot forma mai multe ramuri de încredere. Sau invers, un db poate fi semnat de mai multe KEC (deși acest lucru nu este necesar)
HP Sure Start - o soluție de la Hewlett-Packard, este de fapt un SDZ hardware și software încorporat. Implementează caracteristica de protecție a cheii Secure Boot. Secure Boot în forma sa actuală este oferit de Microsoft ca standard minim de securitate pentru protejarea împotriva rootkit-urilor. În același timp, unii producători își dezvoltă propriile soluții care oferă boot de încredere împreună cu o soluție de la Microsoft, un exemplu de astfel de soluție este HP Sure Start [11] .
Când rootkit-urile interferează cu componentele critice ale sistemului de operare, semnăturile componentelor corespunzătoare devin invalide. Un astfel de sistem de operare pur și simplu nu va fi încărcat [12] .
Dacă este necesar, limitați lista de sisteme de operare posibile de rulat, acest lucru se poate face prin introducerea semnăturilor corespunzătoare în baza de date de semnături [12] .
Driverele de dispozitiv care necesită asistență în faza de pornire a sistemului trebuie să aibă o semnătură care să treacă corect verificarea pe toate platformele pe care pot fi utilizate astfel de dispozitive. Pentru a face acest lucru, toți producătorii de astfel de echipamente vor trebui să fie de acord cu toți producătorii de platforme pentru a-și adăuga cheile în magazinele de sistem. Sau astfel de drivere vor trebui să fie semnate cu o cheie care este deja inclusă în majoritatea platformelor, dar apoi producătorii vor trebui să se bazeze în întregime pe proprietarul unei astfel de chei (de exemplu, Microsoft semnează bootloader-ul shim [13] [14] ) . De asemenea, este posibil să se creeze semnături într-un lanț care se termină cu o cheie conținută în majoritatea platformelor, dar chiar și această abordare are un dezavantaj - atunci când cheia corespunzătoare este eliminată din depozitul de chei (de exemplu, pentru a interzice încărcarea unui anumit sistem de operare) , semnăturile șoferului devin și ele invalide [12] .
Furnizorii de sisteme nu sunt obligați să implementeze capacitatea de a dezactiva Secure Boot. Procedura de adăugare a cheilor de la terți în seif trebuie să fie inaccesibilă pentru software-ul rău intenționat, ceea ce face această procedură mai dificilă pentru utilizatori. Acești doi factori împreună fac mult mai dificilă utilizarea sistemelor de operare nesemnate, precum și a celor semnate cu o cheie necunoscută platformei [12] .
Implementările specifice de firmware ale dispozitivelor de la diferiți producători pot conține vulnerabilități, a căror exploatare poate duce la ocolirea mecanismului de pornire Secure sau la nivelarea acestuia [15] [16] .
Mecanismul de pornire sigură poate împiedica funcționarea instrumentelor de pornire de încredere. Deoarece SDZ înlocuiește bootloader-ul OS cu propriul său bootloader, care în general nu are o semnătură, Secure Boot poate bloca bootloader-ul SDZ și, prin urmare, interferează cu funcționarea SDZ în ansamblu.
Există două soluții la această problemă.
Prima este dezactivarea Secure Boot pe computerele cu SDZ instalat. Un exemplu de astfel de abordare este SDZ SafeNode System Loader [17] .
Al doilea este livrarea unui set de variabile autentificate împreună cu SDZ, care atestă valabilitatea semnăturii încărctorului. După setarea variabilelor, SDZ va funcționa fără restricții de la Secure Boot. Un exemplu al acestei abordări este Dallas Lock SDZ. În acest caz, utilitarul keytool.efi [18] este de asemenea furnizat împreună cu cheile .