Drošas sāknēšanas atslēgu pārvaldība operētājsistēmās Windows un Linux

Ja izmantojat drošo sāknēšanu Windows un Linux datoros, atslēgu pārvaldība vairs nav izvēles iespēja : tā ietekmē, vai sistēma tiek startēta, vai varat atjaunināt programmaparatūru, izmantojot fwupd vai ražotāja rīkus, un turpmākajos gados pat to, vai jūsu datori turpinās pieņemt sāknēšanas ielādētājus, kas parakstīti ar veciem Microsoft sertifikātiem.

Šī raksta mērķis ir mierīgi, bet rūpīgi izskaidrot, kā visa drošās palaišanas atslēgu un sertifikātu ekosistēma darbojas mūsdienu UEFI platformās , kāda ir PK, KEK, db un dbx loma, kā tas iederas operētājsistēmā Windows, Linux distribūcijās, kas izmanto shim, un OEM aparatūrā, un kādi reāli risinājumi pastāv šo atslēgu ģenerēšanai, glabāšanai un atjaunošanai, neradot haosu rūpnīcā vai profesionālā vidē.

Kas ir drošā sāknēšana un kā tā iederas UEFI, Windows un Linux sistēmās?

Droša sāknēšana ir drošības līdzeklis, kas definēts UEFI standartā, nevis Microsoft ekskluzīvs izgudrojums . Tā radās kā vecās BIOS evolūcija, lai nodrošinātu standarta mehānismu, kas ļauj programmaparatūrai pārbaudīt sāknēšanas laikā ielādēto komponentu kriptogrāfiskos parakstus: opciju ROM, UEFI draiverus, UEFI lietojumprogrammas un, galvenokārt, operētājsistēmas ielādētājus.

Knifs ir tāds, ka programmaparatūra izpilda tikai tos bināros failus, kuru parakstu tā var pārbaudīt ar iekšēji saglabātām uzticamām atslēgām . Tas samazina uzbrukuma virsmu pret sāknēšanas ļaunprogrammatūru (sāknēšanas komplektiem, sakņkopām), kas tiek ievadīta pirms operētājsistēmas un pretvīrusu programmas pārņemšanas vadībā. Windows 8 ieviesa šo modeli kā daļu no drošās sāknēšanas arhitektūras, un kopš tā laika tas ir kļuvis par prasību mūsdienu Windows klientu datoros un Windows Server.

Linux pasaulē drošā sāknēšana (Secure Boot) izraisīja lielāku diskusiju, jo daudzas distributīvās versijas nebija gatavas pareizi parakstīt GRUB un kodolu, un lielākā daļa ekosistēmas balstās uz Microsoft galveno infrastruktūru, lai palaistu patērētāju aparatūru. Tas noveda pie shim izstrādes: neliela sāknēšanas ielādētāja, ko parakstījis Microsoft, kas savukārt pārbauda GRUB un kodolu ar pašas distributīvās versijas atslēgām un tiek pārvaldīts ar tādiem rīkiem kā MOK Manager.

Lai gan Microsoft darbojas kā viena no attiecīgajām sertifikācijas iestādēm drošās sāknēšanas (Secure Boot) jomā, standarts galu galā kontroli piešķir datora īpašniekam : gandrīz visās x86 mātesplatēs var pārvaldīt atslēgu datubāzi, pievienot savas atslēgas, dzēst Microsoft atslēgas vai pat startēt datoru ar pilnībā pielāgotu primāro atslēgu. Strīds vairāk izriet no noklusējuma konfigurācijas un Windows sertifikācijas prasībām, nevis no pašas tehnoloģijas.

Drošai sāknēšanai tiek izmantota publiskās atslēgas kriptogrāfija un PKI

Droša sāknēšana pilnībā balstās uz publiskās atslēgas infrastruktūru (PKI) . Tas ietver darbu ar asimetriskiem atslēgu pāriem (publiskiem un privātiem), X.509 sertifikātiem un sertifikātu ķēdēm, kas izveido uzticības sakni no sertifikātu iestādes (CA) līdz binārajiem failiem, kas darbojas sāknēšanas laikā.

Šajā modelī privātā atslēga tiek izmantota parakstīšanai, bet publiskā atslēga — verifikācijai . Ja kāds apdraud privāto atslēgu, viss, kas ar to parakstīts, kļūst neuzticams, un ir obligāti jāatsauc saistītais sertifikāts (pievienojot to dbx), lai novērstu ierīču turpmāku potenciāli ļaunprātīgu bināro failu ielādi.

Ieteicamie drošās sāknēšanas algoritmi ir vismaz 2048 bitu RSA un paraksti ar SHA-256 . UEFI standarts definē parakstu veidus, piemēram, EFI_CERT_X509_GUID (pilni X.509 sertifikāti) vai EFI_CERT_RSA2048_GUID (neapstrādāta publiskā atslēga vai atslēgas jaucējkods, lai ietaupītu vietu programmaparatūrā), un Windows pielāgo savas prasības šim drošības līmenim.

Tipisks digitālais sertifikāts satur atšķirīgu nosaukumu, publisko atslēgu un izdevēja sertifikācijas iestādes (CA) parakstu. Saknes sertifikātos šis paraksts ir pašparakstīts (CA parakstās pati), savukārt starpposma vai gala entītijas sertifikātos paraksts nāk no augstāka līmeņa sertifikācijas iestādes. Droša sāknēšana izmanto šīs sertifikātu ķēdes, lai uzticama saknes sertifikācijas iestāde varētu autentificēt daudzas starpposma atslēgas, nepārslogojot programmaparatūru ar sertifikātiem.

Praksē drošā sāknēšanas procesā saplūst vairākas attiecīgas sertifikācijas iestādes : no vienas puses, OEM (vai tā delegāti, piemēram, IBV vai ODM), un, no otras puses, Microsoft ar dažādiem sertifikātiem KEK, UEFI sertifikācijas iestādei, kas paraksta Windows sāknēšanas pārvaldnieku, un UEFI sertifikācijas iestādei, ko tā izmanto, lai parakstītu trešo pušu UEFI draiverus un citu operētājsistēmu, piemēram, Fedora vai Ubuntu, ielādētājus.

UEFI uzticamības sakne: PK, KEK, db un dbx

UEFI uzticamības drošās sāknēšanas sakne ir ietverta četros galvenajos elementos : platformas atslēgā (PK), atslēgu apmaiņas atslēgā (KEK), atļauto parakstu datubāzē (db) un aizliegto vai atsaukto parakstu datubāzē (dbx). Visi šie elementi tiek glabāti kā autentificēti UEFI mainīgie.

Platformas atslēga (PK) nosaka, kam pieder platforma drošas sāknēšanas nolūkos . Tas ir sertifikāts, parasti X.509 RSA-2048 ar SHA-256 parakstu, kura publiskā daļa (PKpub) tiek ierakstīta programmaparatūrā ražošanas laikā, pārslēdzot sistēmu no konfigurācijas režīma uz lietotāja režīmu.

PK privātajai daļai (PKpriv) vienmēr jāpaliek ārpus ierīces, ievērojot stingrus drošības pasākumus : tā tiek izmantota, lai parakstītu jebkuru darbību, kas lietotāja režīmā modificē KEK, db vai dbx, kā arī lai aizstātu pašu PK. Microsoft piedāvā oriģinālo iekārtu ražotājiem (OEM) iespēju izmantot viņu pārvaldītu PK, kas tiek glabāts HSM, kas vienkāršo pārvaldību ražotājiem, kuri nevēlas ieviest pilnu PKI.

Atslēgu apmaiņas atslēga (KEK) darbojas kā uzticības saite starp programmaparatūru un operētājsistēmām vai lietojumprogrammām, kas pārvalda datubāzes un dbx failus . Katra sistēma (Windows, Linux, OEM, trešās puses) var reģistrēt savu publisko atslēgu KEKpub KEK mainīgajā, lai jebkura datubāzes vai dbx atjauninājums, kas parakstīts ar šo atslēgu, tiktu pieņemts kā likumīgs.

Pašreizējās Windows 11 sistēmās KEK mainīgajā ir obligāti jāiekļauj vismaz sertifikāts “Microsoft Corporation KEK 2K 2023” . Šis sertifikāts ļauj Microsoft izplatīt dbx atjauninājumus (neaizsargātu bināro failu vai kompromitētu sertifikātu atsaukšanu) un, ja nepieciešams, pielāgot db saturu, lai atbalstītu jaunus parakstītājus.

Datubāzē db (_IMAGE_SECURITY_DATABASE) tiek glabāti paraksti, kas tiek uzskatīti par derīgiem palaišanai . Šeit tiek ievietoti saknes sertifikāti, piemēram, “Windows UEFI CA 2023”, “Microsoft UEFI CA 2023”, “Microsoft Corporation UEFI CA 2011” vai “Microsoft UEFI Option ROM CA 2023”, kā arī visi OEM CA vai konkrētu bināro failu heši.

dbx (EFI_IMAGE_SIGNATURE_DATABASE1) dara tieši pretējo: tas uzglabā skaidri atsauktus sertifikātus, atslēgas vai jaucējkodas . Jebkura atbilstība dbx bloķē binārā faila izpildi, pat ja tā paraksts atbilst kaut kam dbx. Windows pieprasa, lai dbx fails vienmēr pastāvētu, un regulāri izplata atjauninājumu pakotnes ar jaunām atsaukšanas tiesībām, īpaši, ja sāknēšanas ielādēs vai UEFI draiveros tiek atklātas ievainojamības.

Drošas sāknēšanas konfigurācijas prasības Windows 11 datoros un Linux sistēmās

Mūsdienu Windows 11 ierīcēm, īpaši versijai 25H2, Microsoft nosaka minimālo UEFI drošās sāknēšanas konfigurāciju . Oriģinālo iekārtu ražotājiem (OEM) ir iepriekš jāinstalē PK (paša vai Microsoft izstrādāta), "Microsoft Corporation KEK 2K 2023" KEK, "Windows UEFI CA 2023" db formātā un jaunākā dbx pakotne dbx formātā.

Sistēmās, kas paredzētas arī Linux vai citu trešo pušu UEFI lietojumprogrammu darbināšanai, datubāzes saturs ir paplašināts . Papildus Windows UEFI CA 2023 ieteicams iekļaut Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 un Microsoft UEFI Option ROM CA 2023, lai opciju ROM, ārējie UEFI draiveri un ielādētāji no citām platformām varētu startēties, nepieprasot lietotājam modificēt programmaparatūru.

OEM ražotāji var iekļaut datubāzē savu UEFI CA, ja nepieciešams , piemēram, lai parakstītu iekšējos UEFI draiverus vai specializētus ielādētājus. Līdzīgi mainīgie dbDefault, dbxDefault un KEKDefault ļauj definēt noklusējuma atslēgu un parakstu kopas, kuras programmaparatūra var atjaunot rūpnīcas iestatījumos.

Linux pasaulē spēlē lomu vēl viens faktors: Microsoft sertifikātu derīguma termiņa beigas . Veco atslēgu derīguma termiņš galu galā beigsies (īpaši svarīgs ir 2025. gada septembra termiņš), un tas nozīmē, ka ar šiem sertifikātiem parakstīti sāknēšanas ielādētāji var pārtraukt sāknēšanu vai arī programmaparatūras atjauninājumi, izmantojot fwupd, var neizdoties, ja nav instalētas jaunās Microsoft KEK un CA atslēgas.

Tādas distributīvās versijas kā Ubuntu, Fedora un openSUSE, kā arī to komerciālās versijas (RHEL, SLE), parasti ir labākas drošās sāknēšanas saderības ziņā . Tās labi integrē fwupd, GNOME programmatūru un Discover, lai lietotu galvenos atjauninājumus ar pāris klikšķiem un pārstartēšanu, savukārt citas distributīvās versijas joprojām iesaka pilnībā atspējot drošo sāknēšanu, jo tās nepareizi paraksta GRUB vai kodolu.

Tipiski lietošanas gadījumi un bieži sastopamas problēmas ar drošo sāknēšanu

Mājas vai spēļu datorā drošā sāknēšanas funkcija aizsargā datoru no ļaunprātīgiem sāknēšanas ielādētājiem, taču tā var radīt konfliktus ar vecāku aparatūru vai programmatūru bez derīga paraksta . Ir samērā bieži, ka tā ir jāatspējo, lai startētu no rīku USB, dažiem eksotiskiem Linux izplatījumiem vai vecākām grafikas kartēm, kas neatklāj parakstītas UEFI ROM atmiņas.

Profesionālā vai korporatīvā vidē drošās sāknēšanas (Secure Boot) aktivizēšana un pareiza konfigurēšana ir gandrīz obligāta . Daudzas izvietošanas paļaujas uz šo slāni, lai samazinātu zema līmeņa kompromitēšanas risku un apvienotu tā izmantošanu ar TPM 2.0 un pilnīgu diska šifrēšanu (BitLocker operētājsistēmā Windows, LUKS operētājsistēmā Linux), aizzīmogojot atšifrēšanas atslēgas, lai nodrošinātu sāknēšanas procesa integritāti.

Operētājsistēma Windows 11 ir vēl vairāk pastiprinājusi noteikumus, vienlaikus pieprasot TPM 2.0 un drošo sāknēšanu kā oficiālas prasības . Lai gan pastāv modificēti instalētāji, kas apiet šīs pārbaudes, ikvienam, kurš vēlas izmantot "atbalstīto maršrutu", ir jānodrošina, ka programmaparatūra ir tīrā UEFI režīmā, ar pieejamu un, ja iespējams, iespējotu drošo sāknēšanu.

Arī videospēles ir ieviesušas Secure Boot kā netiešu prasību kombinācijā ar kodola līmeņa pretkrāpšanas aizsardzību. Tādām spēlēm kā Valorant, League of Legends, Battlefield 6 un Call of Duty: Black Ops 7 pat ir bijusi nepieciešama Windows ar Secure Boot, lai to pretkrāpšanas sistēmas darbotos, izņemot vecākas sistēmas bez UEFI vai TPM.

Linux vidē drošā sāknēšana ir kritiski svarīga šifrētās divkāršās sāknēšanas scenārijos . Ja Windows un Linux koplieto vienu datoru un jūsu Linux nodalījums ir šifrēts, daži faili (initramfs, bootloader, shim/GRUB) vienmēr paliek nešifrēti, padarot tos par pievilcīgiem mērķiem uzbrucējiem, kas apdraud Windows. Pareizi konfigurēta drošā sāknēšana neļauj šādam uzbrucējam aizstāt jūsu initramfs ar tādu, kas zog paroli, jo programmaparatūra noraidītu neparakstītu bināro failu ar uzticamu atslēgu.

Kā droši iespējot vai atspējot drošo sāknēšanu

Drošas sāknēšanas iespējošana vai atspējošana vienmēr tiek veikta no datora UEFI programmaparatūras, nevis no pašas operētājsistēmas , lai gan Windows piedāvā saīsnes, lai restartētu datoru tieši programmaparatūras izvēlnē.

Operētājsistēmā Windows 10 vai 11 vienkāršākais veids ir izmantot papildu atkopšanas izvēlni : dodieties uz Iestatījumi > Atjaunināšana un drošība > Atkopšana > Papildu startēšana, noklikšķiniet uz “Restartēt tūlīt” un pēc restartēšanas izvēlieties Problēmu novēršana > Papildu opcijas > UEFI programmaparatūras iestatījumi. Pēc tam dators tiks restartēts, bet tieši pāries uz BIOS/UEFI saskarni.

UEFI ietvaros katrs ražotājs drošās sāknēšanas opciju novieto nedaudz citā vietā , parasti cilnē “Sāknēšana” vai “Drošība”. Lai mainītu šo iestatījumu, iespējams, vispirms būs jāiestata administratora parole, un pēc tam varēsiet pārslēgties starp iespējotu/atspējotu vai notīrīt taustiņus, lai atgrieztos konfigurācijas režīmā.

Ir svarīgi atcerēties, ka drošās sāknēšanas atspējošana būtiski ietekmē uzbrukuma virsmu . Jūs pavērsiet durvis sāknēšanas ielādētāju, kodolu vai diagnostikas rīku izpildei bez verificētiem parakstiem, kas, ja sistēma ir pakļauta sarežģītai ļaunprogrammatūrai, palielina sāknēšanas komplektu risku, kurus ir ļoti grūti atklāt un noņemt.

Datoros, kas iegādāti ar iepriekšinstalētu Windows, daži ražotāji diezgan ierobežojoši konfigurē drošo sāknēšanu . Dažos "slēgtos" galddatoros un klēpjdatoros lietotājam nav citas izvēles kā to atspējot, ja viņš vēlas palaist daudzus Linux izplatījumus, kas vēl pilnībā neatbalsta Microsoft paraksta modeli vai nepiedāvā parakstītu starpliku.

Drošas sāknēšanas atslēgu pārvaldība ražošanas un OEM vidēs

Runājot par oriģinālā aprīkojuma ražotājiem (OEM), oriģinālā aprīkojuma ražotājiem (ODM) vai integratoriem, kas ražo iekārtas plašā mērogā, atslēgu pārvaldība no tehniskas detaļas pārvēršas par pilnīgu PKI projektu . Nepietiek tikai ar "sertifikāta ģenerēšanu": ir jādefinē, cik dažādu privāto atslēgu būs, kur katra privātā atslēga tiek glabāta un cik gadus var izsniegt programmaparatūras atjauninājumus vai mainīt KEK/db/dbx.

Tipiskas platformas atslēgu (PK) iespējas ir dažādas – no vienas katrai ierīcei līdz vienai katram oriģinālā aprīkojuma ražotājam (OEM) . Vienas PK izmantošana katrai ierīcei maksimāli palielina izolāciju (ja kāda tiek apdraudēta, tas ietekmē tikai šo ierīci), taču tas ir loģistikas un uzglabāšanas murgs. Viena PK katram modelim vai produktu līnijai parasti ir saprātīgs līdzsvars, īpaši patērētāju galddatoriem un klēpjdatoriem.

Papildus PK atslēgai oriģinālo iekārtu ražotājiem (OEM) ir nepieciešamas īpašas atslēgas, lai droši parakstītu programmaparatūras atjauninājumus . Tā sauktā "drošā programmaparatūras atjaunināšanas atslēga" parasti tiek glabāta kā publiska atslēga vai jaucējkoda (hash) ierīces aizsargātā apgabalā (aizsargātā zibatmiņā vai drošinātājos SoC mikroshēmās), un visas atjauninājumu kapsulas ir jāparaksta ar atbilstošo privāto atslēgu vai tai pievienoto atslēgu.

Tas viss ir atspoguļots Windows darbplūsmā programmaparatūras atjaunināšanai, izmantojot UEFI Capsule . Windows apkopo atjauninājumus no draiveru krātuves, pirms ExitBootServices() izsauc funkciju UpdateCapsule(), un programmaparatūra validē parakstu, salīdzina atslēgu ar saglabāto jaucējkodu un, ja viss sakrīt, atjaunina jauno programmaparatūru.

Aparātprogrammatūras atjaunināšanas atslēgai nekad nevajadzētu būt tādai pašai kā PK atslēgai . Ja PKpriv tiktu apdraudēta un tiktu izmantota aparātprogrammatūras parakstīšanai, uzbrucējs varētu atspējot drošo sāknēšanu un aizstāt likumīgo aparātprogrammatūru ar modificētu, pat bloķējot iespēju atjaunot platformu ar jaunu PK atslēgu.

Atslēgu pārvaldības risinājumi: HSM, TPM, programmatūra un citi

Lai efektīvi pārvaldītu drošās sāknēšanas atslēgas, parasti tiek izmantoti aparatūras drošības moduļi (HSM) . Tās ir sertificētas ierīces (daudzos gadījumos FIPS 140-2 2. vai 3. līmenis), kas paredzētas privāto atslēgu ģenerēšanai, glabāšanai un lietošanai, nekad neatklājot tās vienkāršā tekstā ārpus aparatūras.

Tīkla HSM ir visizturīgākā iespēja rūpnīcām vai datu centriem : tie nodrošina augstu pieejamību, drošas dublējumkopijas un kontrolētu piekļuvi no vairākiem serveriem, kā arī piedāvā kriptogrāfisku paātrinājumu, lai ģenerētu un parakstītu lielu sertifikātu apjomu, nepārslogojot ražošanas līniju.

Autonomi HSM (USB, PCIe, PCMCIA) labi darbojas mazākos scenārijos vai laboratorijās . Tos var integrēt ar Microsoft kriptogrāfiskajām API (CAPI, CNG) vai citām, un daži modeļi piedāvā arī dublēšanas un replikācijas mehānismus, lai gan ne vienmēr tīkla HSM līmenī.

Visos šajos gadījumos stūrakmens ir spēcīga autentifikācija . Daudzi HSM (drošības pārvaldības rīki) atļauj "k no m" žetonu shēmas: piemēram, tiek ģenerētas piecas kriptogrāfiskās kartes, un, lai atbloķētu piekļuvi noteiktām atslēgām, ir nepieciešama trīs vienlaicīga klātbūtne. Tas sadala atbildību starp vairākām lomām (drošība, darbības, pārvaldība) un samazina individuālas ļaunprātīgas izmantošanas risku.

Ir mazāk jaudīgas alternatīvas, kas koncentrējas uz datora paša aparatūru, piemēram, TPM vai viedkartes . TPM var ģenerēt un aizsargāt atslēgas disku šifrēšanai un citām funkcijām, taču tam parasti trūkst apstrādes jaudas, krātuves ietilpības un sertifikāciju, kas nepieciešamas, lai rūpnīcā pārvaldītu tūkstošiem PK vai programmaparatūras atslēgu.

Viedkartēm un USB žetoniem ar EV sertifikātiem ir dažas kopīgas īpašības ar HSM (neeksportējamas atslēgas, pamata aizsardzība pret manipulācijām), taču tie ir neērti automatizētām ražošanas līnijas darbplūsmām un tiem trūkst mērogojamības un augstas pieejamības iespēju, kas nepieciešamas, ja programmaparatūras attēli ir jāparaksta nepārtraukti.

Visbeidzot, pastāv tīri uz programmatūru balstītas pieejas atslēgu ģenerēšanai un glabāšanai, kas nav ieteicamas oriģinālā aprīkojuma ražotāju (OEM) vidēm . Tādi rīki kā makecert vai standarta kriptogrāfiskās API ļauj izveidot sertifikātus un saglabāt tos šifrētos diskos vai izolētās iekārtās, taču uzbrukuma vektors ir daudz lielāks, un, ja vien tas netiek apvienots ar ārkārtīgi fiziskiem kontroles pasākumiem, atslēgu noplūdes risks kļūst nepieņemams.

Privāto atslēgu ģenerēšana, glabāšana un izguve

RSA-2048 atslēgas aizņemtā vieta absolūtā izteiksmē ir maza (2048 biti), taču atslēga slēpjas tās simboliskajā vērtībā un ilgtermiņa pārvaldībā . Primārajai atslēgai (PK) vai programmaparatūras atjaunināšanas atslēgai var būt nepieciešams drošs piekļuves punkts desmit gadus vai ilgāk, lai risinātu incidentus vai ģenerētu jaunas programmaparatūras versijas.

Vispārīgais ieteikums ir vienmēr glabāt privātās atslēgas uz īpašas aparatūras , neatkarīgi no tā, vai tas ir HSM datu centrā vai, daudz pieticīgākos gadījumos, glabāšanas kriptogrāfiskais marķieris, un glabāt dublējumkopijas atsevišķās fiziskās vietās, pat dažādos ģeogrāfiskos reģionos, lai mazinātu katastrofu ietekmi.

Atslēgu atkopšanas procesiem jābūt tikpat precīzi definētiem kā ģenerēšanas procesiem . Jums var nākties atkārtoti ģenerēt primāro atslēgu, ja augstas drošības klients vēlas reģistrēt savu atslēgu, ja tiek atklāta potenciāla noplūde vai vienkārši tāpēc, ka iekšējā politika nosaka periodisku rotāciju (piemēram, ik pēc X gadiem, ievērojot Federal Bridge CA vadlīnijas).

KEK un programmaparatūras atjauninājumu atslēgu gadījumā atkopšana ir vēl svarīgāka . KEKpriv tiek izmantota jaunu db un dbx versiju parakstīšanai, un programmaparatūras atslēga "priv" paraksta atjauninājumus, kas tiek piegādāti miljoniem ierīču. Zaudējot vienu no šīm atslēgām bez dublējuma, jūs, iespējams, nevarēsiet atsaukt kompromitētus sertifikātus vai izplatīt drošības ielāpus.

Augsta līmeņa autentifikācija (FIPS 140-2 3. līmenis) piešķir papildu aizsardzības slāni visam šim procesam . Tā prasa katra operatora, kas piekļūst modulim, individuālu identifikāciju, viņu darbību reģistrēšanu un fizisku kontroles mehānismu (zīmogu, viltošanas sensoru, drošas dzēšanas ielaušanās mēģinājumu gadījumā) piemērošanu, kas ievērojami samazina klusas atslēgas zādzības risku.

Droša sāknēšana, trešās puses parakstīšana un Linux saderība

Droša sāknēšana pati par sevi nav DRM mehānisms vai veids, kā neļaut instalēt Linux . Tā ierobežo, kuri binārie faili var darboties sāknēšanas laikā, un to var izmantot likumīgi drošības nolūkos vai neveikli, ja tas ir konfigurēts pārāk ierobežojoši.

Tipiskā kritika, kas to attēlo kā Microsoft rīku alternatīvu sistēmu bloķēšanai, vairs neapstiprinās, ja pārskatāt UEFI specifikāciju . Lietotājs vai administrators var reģistrēt savas atslēgas, dzēst Microsoft atslēgas, mainīt primāro atslēgu vai izvēlēties uzticēties tikai savas organizācijas parakstītiem binārajiem failiem — tas ir skaidri dokumentēts Debian un citu distribūciju dokumentācijā.

Skaidrs ir tas, ka praktiski daudzi Linux distributīvi ir izvēlējušies paļauties uz Microsoft galveno infrastruktūru, lai atvieglotu dzīvi mazāk tehniski prasīgiem lietotājiem . Izmantojot Microsoft UEFI CA 2011 vai 2023 parakstītus starplikas (shīmus), programmaparatūra nekavējoties atpazīst distributīvā sāknēšanas programmu, lietotājam manuāli nerediģējot PK, KEK vai db.

Microsoft piedāvā arī īpašu sertifikācijas aģentūru (CA) trešo pušu UEFI draiveru un lietojumprogrammu parakstīšanai . Jebkurš aparatūras ražotājs vai izstrādātājs, kuram ir nepieciešama papildu ROM vai UEFI draiveris, lai startētu drošās sāknēšanas aparatūrā, var iesniegt savus bināros failus šim parakstīšanas procesam un izplatīt tos, zinot, ka tie darbosies sistēmās, kuru datubāzē ir Microsoft sertifikācijas aģents (CA).

Šīs sistēmas mazāk pievilcīgais aspekts ir tas, ka atslēgas beidzas un tiek atsauktas . Kad vecs saknes sertifikāts tuvojas derīguma termiņa beigām, tas ir jāaizstāj ar jaunu, un jums jāpārliecinās, ka visas ierīces ir saņēmušas atbilstošos atjauninājumus, izmantojot KEK/db/dbx. Pretējā gadījumā jūs riskējat, ka tādas lietas kā fwupd, noteikti sāknēšanas ielādētāji vai UEFI ROM vairs netiks atbalstītas programmaparatūrā.

Ja izmantojat divkāršu palaišanu gan operētājsistēmās Windows, gan Linux vai arī Linux izvietojumos ir iespējota drošā palaišana, periodiski jāpārbauda, ​​vai nav pieejami galvenie atjauninājumi, ko izlaidusi Microsoft un jūsu izplatītā versija . Daudzās izplatībās vienkārši pieņemiet parakstu atjauninājumu pakotnes no programmatūras veikala vai pakotņu pārvaldnieka, pārstartējiet datoru un ļaujiet programmaparatūrai lietot izmaiņas; citās versijās jums būs jāizmanto komandrinda un īpašas utilītas.

Windows-Linux divkāršā sāknēšana, EFI nodalījumi un sāknēšanas secība

Lai iestatītu tīru divkāršu sāknēšanu starp Windows un Linux, ir nedaudz jāsaprot, kā mijiedarbojas UEFI, EFI nodalījums un GRUB sāknēšanas pārvaldnieks , iesaistot drošo sāknēšanu. Vēl svarīgāk ir neimprovizēt, un ieteicams pārskatīt sāknēšanas procesu UEFI sistēmās.

Ja jums jau ir instalēta Windows UEFI režīmā ar GPT nodalījumu, pirmais solis ir samazināt Windows nodalījumu un rezervēt nepiešķirtu vietu Linux . Pirms tam atspējojiet tādas funkcijas kā ātrā palaišana un BitLocker, lai izvairītos no pārsteigumiem, mainot izmēru. Ir svarīgi pārliecināties, vai ir EFI nodalījums (FAT32, daži simti MB), ko koplietos abas sistēmas.

Instalējot Linux, ieteicams izmantot manuālu nodalījumu veidošanu un respektēt esošo EFI nodalījumu , pievienojot to kā /boot/efi, nevis veidojot jaunu. Pēc tam izveidojiet nodalījumus /, /home un veiciet maiņu pēc nepieciešamības, kā arī instalējiet GRUB kā UEFI sāknēšanas pārvaldnieku, norādot arī uz EFI nodalījumu.

Ja izplatījums atbalsta drošo sāknēšanu (Secure Boot), tiks instalēts parakstīts starpniekserveris un GRUB, ko programmaparatūra pieņems bez liekas kavēšanās . Pretējā gadījumā, lai pabeigtu instalēšanu, iespējams, būs īslaicīgi jāatspējo drošā sāknēšana vai manuāli jāreģistrē papildu sertifikāti datubāzē, lai programmaparatūra uzticētos Linux sāknēšanas ielādētājam. Saderības problēmu gadījumā ir ierasta prakse pievienot GRUB sāknēšanas parametrus.

Pēc instalēšanas sistēma var tieši startēties operētājsistēmā Windows, jo GRUB sāknēšanas ierakstam nav piešķirta prioritāte . Šādā gadījumā jums būs jāpiekļūst UEFI un jāmaina sāknēšanas secība vai, Linux vidē, jāizmanto efibootmgr, lai mainītu ierakstu secību. Operētājsistēmā Windows varat arī eksperimentēt ar bcdedit, bootrec un reagentc , taču ir ērtāk ļaut UEFI pārvaldīt prioritātes.

Kad viss ir konfigurēts un atslēgas ir pareizi pārvaldītas, varat uzturēt stabilu divkāršu sāknēšanu ar šifrētiem diskiem un aktīvu drošo sāknēšanu , bez nepieciešamības iespējot un atspējot opcijas katru reizi, mainot sistēmas, vai atteikties no drošības priekšrocībām, ko nodrošina modernā UEFI-Secure Boot-TPM arhitektūra.

Galu galā, izpratne par drošās sāknēšanas atslēgu pārvaldību operētājsistēmās Windows un Linux — sākot no PK un KEK līdz db/dbx, HSM, TPM un divkāršai sāknēšanai — ir tas, kas rada atšķirību starp kaprīzu sistēmu, kas pārtrauc sāknēšanu, kad beidzas sertifikāta derīguma termiņš, un stabilu platformu, kas ir gatava programmaparatūras atjauninājumiem, jaunām izplatīšanām un arvien prasīgākām drošības prasībām, nezaudējot kontroli pār savām iekārtām.

Saistītais raksts:

Sāknēšanas izsekošana operētājsistēmā Windows 11: pilnīgs ceļvedis sāknēšanas procesu analīzei

Isaac

Kaislīgs rakstnieks par baitu pasauli un tehnoloģiju kopumā. Man patīk dalīties savās zināšanās rakstot, un tieši to es darīšu šajā emuārā, parādot visu interesantāko informāciju par sīkrīkiem, programmatūru, aparatūru, tehnoloģiju tendencēm un daudz ko citu. Mans mērķis ir palīdzēt jums vienkāršā un izklaidējošā veidā orientēties digitālajā pasaulē.