Secure Boot -avainten hallinta Windowsissa ja Linuxissa

Jos käytät Secure Boot -toimintoa Windows- ja Linux-järjestelmissä, avaintenhallinta ei ole enää valinnaista.Tämä vaikuttaa siihen, käynnistyykö järjestelmä, voiko laiteohjelmiston päivittää fwupd:llä vai valmistajan työkaluilla, ja tulevina vuosina jopa siihen, hyväksyvätkö koneesi vanhoilla Microsoft-varmenteilla allekirjoitetut käynnistyslataimet.

Tämän artikkelin tarkoituksena on selittää rauhallisesti mutta perusteellisesti, miten Secure Boot -avainten ja -sertifikaattien koko ekosysteemi toimii nykyaikaisilla UEFI-alustoilla.Mitä rooleja PK:lla, KEK:lla, db:llä ja dbx:llä on? Miten tämä sopii yhteen Windowsin, shim-levyjä käyttävien Linux-jakelujen ja OEM-laitteiston kanssa? Ja mitä todellisia ratkaisuja on olemassa näiden avainten luomiseen, suojaamiseen ja uusimiseen aiheuttamatta kaaosta tehtaissa tai ammattiympäristöissä?

Mikä on Secure Boot ja miten se sopii UEFIin, Windowsiin ja Linuxiin?

Secure Boot on UEFI-standardin sisällä määritelty tietoturvaominaisuus, eikä se ole Microsoftin yksinomainen keksintö.Se syntyi vanhan BIOSin kehityksenä, jossa on standardoitu mekanismi, jonka avulla laiteohjelmisto voi tarkistaa käynnistyksen yhteydessä ladattavien komponenttien kryptografiset allekirjoitukset: lisä-ROMit, UEFI-ajurit, UEFI-sovellukset ja ennen kaikkea käyttöjärjestelmän latausohjelmat.

Temppu on siinä, että laiteohjelmisto suorittaa vain binääritiedostoja, joiden allekirjoituksen se voi varmistaa sisäisesti tallennetuilla luotettavilla avaimilla.Tämä pienentää hyökkäyspintaa käynnistyshaittaohjelmia (bootkit- ja rootkit-ohjelmia) vastaan, jotka ruiskutetaan ennen kuin käyttöjärjestelmä ja virustorjuntaohjelmisto ehtivät ottaa hallinnan. Windows 8 esitteli tämän mallin osana Secure Boot -arkkitehtuuriaan, ja siitä on sittemmin tullut vaatimus nykyaikaisille Windows-asiakastietokoneille ja Windows Serverille.

Linux-maailmassa Secure Bootilla oli kiistanalaisempi vastaanotto. Koska monet jakelut eivät olleet valmiita allekirjoittamaan GRUBia ja ydintä oikein, ja koska suurin osa ekosysteemistä on riippuvainen Microsoftin avaininfrastruktuurista käynnistyäkseen kuluttajalaitteistolla. Tästä syystä syntyi shim: pieni Microsoftin allekirjoittama käynnistyslataaja, joka puolestaan ​​​​varmentaa GRUBin ja ytimen jakelun itsensä avaimilla ja jota hallitaan työkaluilla, kuten MOK-päällikkö.

Vaikka Microsoft toimii yhtenä Secure Bootin asiaankuuluvista sertifiointiviranomaisista, standardi antaa lopullisen hallinnan koneen omistajalle.Lähes kaikissa x86-emolevyissä voit hallita avaintietokantaa, lisätä omia avaimiasi, poistaa Microsoftin avaimia tai jopa käynnistää täysin mukautetulla PK:lla. Kiista johtuu enemmän oletuskokoonpanosta ja Windowsin sertifiointivaatimuksista kuin itse teknologiasta.

Julkisen avaimen kryptografia ja PKI sovellettuna suojattuun käynnistykseen

Secure Boot perustuu kokonaan julkisen avaimen infrastruktuuriin (PKI)Tämä edellyttää työskentelyä epäsymmetristen avainparien (julkisten ja yksityisten), X.509-sertifikaattien ja sertifikaattiketjujen kanssa, jotka muodostavat luottamusjuuren sertifikaatin myöntäjältä (CA) käynnistyksen yhteydessä suoritettaville binääreille.

Tässä mallissa yksityistä avainta käytetään allekirjoittamiseen ja julkista avainta varmentamiseenJos joku vaarantaa yksityisen avaimen, kaikki sillä allekirjoitettu muuttuu epäluotettavaksi, ja siihen liittyvä varmenne on peruutettava (lisäämällä se dbx:ään), jotta laitteet eivät voi jatkaa mahdollisesti haitallisten binääritiedostojen lataamista.

Suositellut algoritmit Secure Bootille ovat vähintään 2048-bittinen RSA ja SHA-256-allekirjoitukset.UEFI-standardi määrittelee allekirjoitustyyppejä, kuten EFI_CERT_X509_GUID (täydelliset X.509-varmenteet) tai EFI_CERT_RSA2048_GUID (raaka julkinen avain tai avaimen tiiviste, laiteohjelmiston tilan säästämiseksi), ja Windows mukauttaa vaatimuksensa tähän suojaustasoon.

Tyypillinen digitaalinen varmenne sisältää yksilöivän nimen, julkisen avaimen ja myöntäjän allekirjoituksen.Juurivarmenteissa allekirjoitus on itse allekirjoitettu (varmentaja allekirjoittaa itsensä), kun taas välivaiheen tai lopullisissa varmenteissa allekirjoitus tulee korkeamman tason varmentajalta. Secure Boot hyödyntää näitä varmenneketjuja, jotta luotettu juurivarmentaja voi todentaa useita välivaiheen avaimia ilman, että laiteohjelmisto täyttyy varmenteilla.

Käytännössä useat asiaankuuluvat CA:t yhdistyvät turvallisessa käynnistyksessä.Toisaalta OEM (tai sen edustajat, kuten IBV tai ODM) ja toisaalta Microsoft, joilla on eri varmenteet KEK:lle, Windowsin käynnistyksen hallinnan allekirjoittavalle UEFI CA:lle ja UEFI CA:lle, jota se käyttää allekirjoittaakseen kolmannen osapuolen UEFI-ajureita ja muiden käyttöjärjestelmien, kuten Fedoran tai Ubuntun, latausohjelmia.

UEFI-luottamuksen juuri: PK, KEK, db ja dbx

UEFI:n luottamuksen Secure Boot -perustana on neljä keskeistä elementtiäAlustan avain (PK), avaimenvaihtoavain (KEK), sallittujen allekirjoitusten tietokanta (db) ja kiellettyjen tai peruutettujen allekirjoitusten tietokanta (dbx) tallennetaan kaikki todennetuiksi UEFI-muuttujiksi.

Alustan avain (PK) määrittää, kuka omistaa alustan turvallisen käynnistyksen tarkoituksiin.Se on varmenne, yleensä X.509 RSA-2048 SHA-256-allekirjoituksella, jonka julkinen osa (PKpub) kirjoitetaan laiteohjelmistoon valmistuksen aikana, jolloin järjestelmä siirtyy pois konfigurointitilasta käyttäjätilaan.

PK:n yksityisen osan (PKpriv) on aina pysyttävä laitteen ulkopuolella äärimmäisen suojattuna.Tätä käytetään allekirjoittamaan kaikki toiminnot, jotka muuttavat KEK:iä, db:tä tai dbx:ää käyttäjätilassa, ja myös korvaamaan itse PK:n. Microsoft tarjoaa laitevalmistajille mahdollisuuden käyttää heidän hallinnoimaansa ja HSM:ään tallennettua PK:ta, mikä yksinkertaistaa hallintaa valmistajille, jotka eivät halua ottaa käyttöön täyttä PKI:tä.

Key Exchange Key (KEK) toimii luotettavana linkkinä laiteohjelmiston ja käyttöjärjestelmien tai sovellusten välillä, jotka hallitsevat tietokantaa ja tietokantaa (dbx).Jokainen järjestelmä (Windows, Linux, OEM, kolmannen osapuolen järjestelmä) voi rekisteröidä KEKpub-julkisen avaimensa KEK-muuttujaan, jotta kaikki kyseisellä avaimella allekirjoitetut tietokanta- tai dbx-päivitykset hyväksytään laillisiksi.

Nykyisissä Windows 11 -järjestelmissä on pakollista sisällyttää KEK-muuttujaan vähintään varmentaja ”Microsoft Corporation KEK 2K 2023”.Tämän varmenteen avulla Microsoft voi jakaa dbx-päivityksiä (haavoittuvien binääritiedostojen tai vaarantuneiden varmenteiden peruutuksia) ja tarvittaessa muokata tietokannan sisältöä uusien allekirjoittajien tukemiseksi.

Tietokanta (_IMAGE_SECURITY_DATABASE) kerää allekirjoitukset, joita pidetään kelvollisina aloittamiseen.Tähän lisätään juurivarmenteita, kuten ”Windows UEFI CA 2023”, ”Microsoft UEFI CA 2023”, ”Microsoft Corporation UEFI CA 2011” tai ”Microsoft UEFI Option ROM CA 2023”, sekä mahdollisia OEM-varmenteita tai tiettyjen binäärien tiivisteitä.

dbx (EFI_IMAGE_SIGNATURE_DATABASE1) toimii juuri päinvastoin: se tallentaa nimenomaisesti peruutetut varmenteet, avaimet tai tiivisteetMikä tahansa dbx-tiedostossa oleva osuma estää binääritiedoston suorittamisen, vaikka sen allekirjoitus vastaisi jotakin dbx-tiedostossa. Windows vaatii, että dbx-tiedosto on aina olemassa, ja jakaa säännöllisesti päivityspaketteja, joissa on uusia peruutuksia, erityisesti silloin, kun käynnistyslataimissa tai UEFI-ajureissa havaitaan haavoittuvuuksia.

Secure Boot -määritysvaatimukset Windows 11 -tietokoneissa ja Linux-järjestelmissä

Nykyaikaisille Windows 11 -laitteille, erityisesti versiolle 25H2, Microsoft määrittää UEFI Secure Boot -vähimmäiskokoonpanonLaitevalmistajien on esiasennettava PK (oma tai Microsoftin), "Microsoft Corporation KEK 2K 2023", "Windows UEFI CA 2023" dbx:ään ja uusin dbx-paketti dbx:ään.

Järjestelmissä, jotka on suunniteltu myös Linuxin tai muiden kolmannen osapuolen UEFI-sovellusten suorittamiseen, tietokannan sisältöä laajennetaanWindows UEFI CA 2023:n lisäksi on suositeltavaa sisällyttää Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 ja Microsoft UEFI Option ROM CA 2023, jotta muiden alustojen Option ROMit, ulkoiset UEFI-ajurit ja latausohjelmat käynnistyvät pakottamatta käyttäjää säätämään laiteohjelmistoa.

Laitevalmistajat voivat tarvittaessa sisällyttää oman UEFI CA:nsa dB-arvoina.Esimerkiksi sisäisten UEFI-ajurien tai erikoislataajien allekirjoittamiseen. Samoin dbDefault-, dbxDefault- ja KEKDefault-muuttujien avulla voit määrittää oletusarvoiset avain- ja allekirjoitusjoukot, jotka laiteohjelmisto voi palauttaa tehdasarvoihin.

Linux-maailmassa toinenkin tekijä tulee mukaan kuvioihin: Microsoft-sertifikaattien vanheneminen.Vanhat avaimet vanhenevat lopulta kokonaan (syyskuun 2025 määräaika on erityisen tärkeä), mikä tarkoittaa, että näillä varmenteilla allekirjoitetut käynnistyslataimet saattavat lopettaa käynnistymisen tai että fwupd:n kautta tehtävät laiteohjelmistopäivitykset voivat epäonnistua, jos uusia Microsoft KEK- ja CA-avaimia ei ole asennettu.

Jakelut, kuten Ubuntu, Fedora ja openSUSE, sekä niiden kaupalliset variantit (RHEL, SLE), ovat yleensä edellä Secure Boot -yhteensopivuudessa.Ne integroituvat hyvin fwupdin, GNOME-ohjelmiston tai Discoverin kanssa ja ottavat käyttöön tärkeät päivitykset muutamalla napsautuksella ja uudelleenkäynnistyksellä, kun taas muut jakelut suosittelevat edelleen Secure Bootin poistamista käytöstä suoraan, koska ne eivät allekirjoita GRUBia tai ydintä oikein.

Tyypillisiä käyttötapauksia ja yleisiä ongelmia Secure Bootin kanssa

Koti- tai pelitietokoneella Secure Boot suojaa sinua haitallisilta käynnistyslataimilta, mutta se voi olla ristiriidassa vanhemman laitteiston tai allekirjoittamattoman ohjelmiston kanssa.On suhteellisen yleistä, että se on poistettava käytöstä käynnistääkseen työkaluja sisältävän live-USB:n, jonkin eksoottisen jakelun tai vanhat näytönohjaimet, jotka eivät paljasta allekirjoitettuja UEFI ROM -levyjä.

Ammatti- tai yritysympäristöissä Secure Bootin pitäminen aktiivisena ja oikein määritettynä on lähes pakollista.Monet käyttöönotot käyttävät tätä kerrosta pienentääkseen matalan tason tietomurtojen riskiä ja yhdistävät sen käytön TPM 2.0:n ja täydellisen levyn salauksen (BitLocker Windowsissa, LUKS Linuxissa) kanssa, sinetöiden salausavaimet käynnistyksen eheyden varmistamiseksi.

Windows 11 on kiristänyt tilannetta entisestään vaatimalla samanaikaisesti TPM 2.0:n ja Secure Bootin virallisiksi vaatimuksiksi.Vaikka on olemassa muokattuja asennusohjelmia, jotka ohittavat nämä tarkistukset, jokaisen, joka haluaa valita "tuetun reitin", on varmistettava, että laiteohjelmisto on puhtaassa UEFI-tilassa ja että Secure Boot on käytettävissä ja mahdollisuuksien mukaan käytössä.

Videopelit ovat myös hypänneet Secure Boot -kelkkaan epäsuorana vaatimuksena. yhdessä kernel-tason huijaukseneston kanssa. Pelit, kuten Valorant, League of Legends, Battlefield 6 ja Call of Duty: Black Ops 7, ovat jopa vaatineet Windowsin ja Secure Bootin toimiakseen huijauksenestojärjestelmänsä kanssa, pois lukien vanhemmat tietokoneet, joissa ei ole UEFIa tai TPM:ää.

Linux-ympäristössä Secure Boot on kriittinen salatuissa kaksoiskäynnistystilanteissa.Jos Windows ja Linux jakavat koneen ja Linux-osiosi on salattu, on aina joitakin salaamattomia tiedostoja (initramfs, bootloader, shim/GRUB), jotka houkuttelevat hyökkääjää, joka haluaa vaarantaa Windowsin. Oikein määritettynä Secure Boot estää hyökkääjää korvaamasta initramfs-tiedostoasi sellaisella, joka varastaa salasanan, koska laiteohjelmisto hylkäisi allekirjoittamattoman binääritiedoston, jossa on luotettava avain.

Suojatun käynnistyksen turvallinen ottaminen käyttöön tai poistaminen käytöstä

Suojatun käynnistyksen ottaminen käyttöön tai poistaminen käytöstä tehdään aina laitteen UEFI-laiteohjelmistosta, ei itse käyttöjärjestelmästä.Windows tarjoaa kuitenkin pikakuvakkeita, joilla voit käynnistää tietokoneen suoraan laiteohjelmistovalikkoon.

Windows 10:stä tai 11:stä eteenpäin helpoin tapa on käyttää edistynyttä palautusvalikkoaSiirry kohtaan Asetukset > Päivitys ja suojaus > Palautus > Käynnistyksen lisäasetukset, napauta "Käynnistä uudelleen nyt" ja valitse uudelleenkäynnistyksen jälkeen Vianmääritys > Lisäasetukset > UEFI-laiteohjelmiston asetukset. Sieltä tietokone käynnistyy uudelleen, mutta siirtyy suoraan BIOS/UEFI-käyttöliittymään.

UEFI:n sisällä jokainen valmistaja sijoittaa Secure Boot -vaihtoehdon hieman eri paikkaan.Tämä löytyy yleensä "Käynnistys"- tai "Suojaus"-välilehdeltä. Sinun on ehkä ensin asetettava järjestelmänvalvojan salasana muokataksesi tätä asetusta, ja sitten voit vaihtaa käytössä/pois käytöstä -tilan välillä tai poistaa näppäimiä palataksesi määritystilaan.

On syytä muistaa, että Secure Bootin poistaminen käytöstä vaikuttaa merkittävästi hyökkäyspintaan.Avaat oven käynnistyslataajien, kernelien tai diagnostiikkatyökalujen suorittamiselle ilman vahvistettua allekirjoitusta, mikä lisää sellaisten käynnistyspakettien riskiä, ​​joita on erittäin vaikea havaita ja puhdistaa, jos tietokone altistuu kehittyneille haittaohjelmille.

Tietokoneissa, joihin Windows on esiasennettu, jotkut valmistajat määrittävät Secure Bootin melko rajoittavasti.Tietyissä "suljetuissa" pöytätietokoneissa ja kannettavissa tietokoneissa käyttäjän on poistettava se käytöstä, jos hän haluaa käynnistää useita Linux-jakeluja, jotka eivät vielä täysin tue Microsoftin allekirjoitusmallia tai eivät tarjoa allekirjoitettuja shim-levyjä.

Secure Boot -avainten hallinta valmistus- ja OEM-ympäristöissä

Kun puhumme OEM-valmistajista, ODM-valmistajista tai integraattoreista, jotka valmistavat laitteita laajamittaisesti, avaintenhallinnasta tulee tekninen yksityiskohta kokonaisvaltainen PKI-projekti.Pelkkä "sertifikaatin luominen" ei riitä: on määriteltävä, kuinka monta erilaista PK:ta on, missä kukin yksityinen avain tallennetaan ja kuinka monen vuoden ajan laiteohjelmistopäivityksiä voidaan myöntää tai KEK/db/dbx-tietoja voidaan muuttaa.

Tyypillisiä alusta-avainten (PK) vaihtoehtoja ovat yksi laitetta kohden ja yksi OEM-valmistajaa kohden.Yhden pakkauspaketin käyttäminen laitetta kohden maksimoi eristäytymisen (jos yksi pakkaus vaarantuu, se vaikuttaa vain yhteen koneeseen), mutta se on logistinen ja tallennuspainajainen. Yksi pakkaus mallia tai tuotelinjaa kohden on yleensä kohtuullinen tasapaino, erityisesti kuluttajakäyttöön tarkoitetuissa pöytätietokoneissa ja kannettavissa tietokoneissa.

PK:n lisäksi laitevalmistajat tarvitsevat erityisiä avaimia laiteohjelmistopäivitysten turvalliseen allekirjoittamiseen.Niin kutsuttu ”suojattu laiteohjelmistopäivitysavain” tallennetaan yleensä julkisena avaimena tai tiivisteenä laitteen suojatulle alueelle (suojattu flash-muisti tai sulakkeet SoC:ssä), ja kaikki päivityskapselit on allekirjoitettava vastaavalla yksityisellä avaimella tai siihen ketjutetulla avaimella.

Kaikki tämä toiminto heijastuu Windowsin työnkulussa laiteohjelmiston päivittämiseksi UEFI-kapselin kautta.Windows kerää päivitykset ohjainsäilöönsä, kutsuu UpdateCapsule()-funktiota ennen ExitBootServices():ia, ja laiteohjelmisto vahvistaa allekirjoituksen, tarkistaa avaimen tallennettua tiivistettä vasten ja jos kaikki täsmää, flash-asentaa uuden laiteohjelmiston.

Laiteohjelmiston päivitysavaimen ei tulisi koskaan olla sama kuin PK:nJos PKpriv vaarantuisi ja sitä käytettäisiin laiteohjelmiston allekirjoittamiseen, hyökkääjä voisi sekä poistaa Secure Bootin käytöstä että korvata laillisen laiteohjelmiston muokatulla, jopa estää alustan palauttamisen uudella PK:lla.

Avainhallintaratkaisut: HSM, TPM, ohjelmistot ja muut

Suojatun käynnistyksen avainten hallintaan käytetään yleensä laitteistopohjaisia ​​suojausmoduuleja (HSM).Nämä ovat sertifioituja laitteita (monissa tapauksissa FIPS 140-2 taso 2 tai 3), jotka on suunniteltu luomaan, tallentamaan ja käyttämään yksityisiä avaimia paljastamatta niitä koskaan selkokielisenä tekstinä laitteiston ulkopuolella.

Verkko-HSM:t ovat vankin vaihtoehto tehtaille tai datakeskuksilleNe mahdollistavat korkean käytettävyyden, turvalliset varmuuskopiot ja hallitun käytön useilta palvelimilta sekä tarjoavat kryptografisen kiihdytyksen suurten varmennemäärien luomiseen ja allekirjoittamiseen ilman tuotantolinjan kuristamista.

Erilliset HSM-piirit (USB, PCIe, PCMCIA) toimivat hyvin pienemmissä tilanteissa tai laboratorioissaNe voidaan integroida Microsoftin kryptografisiin API-rajapintoihin (CAPI, CNG) tai muihin, ja jotkut mallit tarjoavat myös varmuuskopiointi- ja replikointimekanismeja, vaikkakaan eivät aina verkon HSM-tasolla.

Kaikissa näissä tapauksissa vahva todennus on kulmakiviMonet HSM-järjestelmät sallivat "k/m"-tokenijärjestelmiä: esimerkiksi luodaan viisi kryptografista korttia, ja tiettyjen avainten avaamiseen vaaditaan kolmen samanaikainen läsnäolo. Tämä jakaa vastuun useiden roolien (turvallisuus, operatiivinen toiminta, hallinta) kesken ja vähentää yksittäisten väärinkäytösten riskiä.

Tietokoneen omaan laitteistoon, kuten TPM:ään tai älykortteihin, keskittyviä vähemmän tehokkaita vaihtoehtoja on.TPM voi luoda ja suojata avaimia levyjen salausta ja muita toimintoja varten, mutta siltä yleensä puuttuu prosessointiteho, tallennuskapasiteetti ja sertifioinnit, joita tarvitaan tuhansien PK- tai laiteohjelmistoavainten hallintaan tehtaalla.

Älykortit ja EV-varmenteilla varustetut USB-tokenit jakavat joitakin ominaisuuksia HSM-palveluiden kanssa. (ei-vietävät avaimet, perussuojaus peukalointia vastaan), mutta ne ovat hankalia automatisoiduille tuotantolinjojen työnkuluille, eivätkä niistä puutu skaalautuvuutta ja korkeaa käytettävyyttä, joita tarvitaan, kun laiteohjelmistokuvia on allekirjoitettava jatkuvasti.

Lopuksi on olemassa puhtaasti ohjelmistopohjaisia ​​​​lähestymistapoja avainten luomiseen ja tallentamiseen, joita ei suositella OEM-ympäristöihin.Työkalut, kuten makecert tai tavalliset kryptografiset API:t, mahdollistavat varmenteiden luomisen ja tallentamisen salatuille levyille tai erillisille koneille, mutta hyökkäysvektori on paljon suurempi ja ellei sitä yhdistetä äärimmäisiin fyysisiin suojatoimiin, avainvuodon riski kasvaa kohtuuttomasti.

Yksityisten avainten luominen, tallentaminen ja hakeminen

RSA-2048-avaimen käyttämä tila on absoluuttisesti pieni (2048 bittiä), mutta avain piilee symbolisessa arvossa ja pitkän aikavälin hallinnassa.PK- tai laiteohjelmistopäivitysavaimen on ehkä oltava turvallisesti saatavilla kymmenen vuoden ajan tai kauemmin, jotta ongelmia voidaan ratkaista tai luoda uusia laiteohjelmistoversioita.

Yleinen suositus on aina tallentaa yksityiset avaimet erilliselle laitteistolle.Olipa kyseessä sitten datakeskuksen HSM tai paljon vaatimattomammissa tilanteissa säilytyssalaustunniste, varmuuskopiot tulisi säilyttää erillisissä fyysisissä paikoissa, jopa eri maantieteellisillä alueilla, katastrofien vaikutusten minimoimiseksi.

Avainten palautusprosessien on oltava yhtä hyvin määriteltyjä kuin avainten luontiprosessienkin.Saatat joutua luomaan PK:n uudelleen, koska korkean tietoturvatason asiakas haluaa rekisteröidä oman, koska mahdollinen vuoto havaitaan tai yksinkertaisesti siksi, että sisäinen käytäntö sanelee säännöllisiä rotaatioita (esimerkiksi joka X. vuosi Federal Bridge CA:n ohjeiden mukaisesti).

KEK- ja laiteohjelmistopäivitysavainten tapauksessa palautus on vieläkin tärkeämpää.KEKpriv-avainta käytetään db- ja dbx-versioiden uusien versioiden allekirjoittamiseen, ja laiteohjelmiston "priv"-avain allekirjoittaa miljoonille laitteille toimitetut päivitykset. Yhden näistä avaimista menettäminen ilman varmuuskopiota voi estää vaarantuneiden varmenteiden peruuttamisen tai tietoturvapäivitysten jakelun.

Korkean tason todennus (FIPS 140-2 taso 3) lisää tähän prosessiin ylimääräisen suojauskerroksen.Se edellyttää jokaisen moduulia käyttävän käyttäjän yksilöllistä tunnistamista, heidän toimiensa tallentamista ja fyysisten valvontamenetelmien (sinetit, peukalointitunnistimet, turvallinen pyyhkiminen tunkeutumisyrityksiä vastaan) soveltamista, jotka vähentävät merkittävästi hiljaisen avainvarkauden riskiä.

Secure Boot, kolmannen osapuolen allekirjoittaminen ja Linux-yhteensopivuus

Secure Boot ei itsessään ole DRM-mekanismi tai suojaus, joka estäisi Linuxin asentamisen.Se rajoittaa käynnistyksen yhteydessä suoritettavien binäärien määrää, ja näitä tiedostoja voidaan käyttää laillisesti turvallisuussyistä tai kömpelösti, jos ne on määritetty liian rajoittavasti.

Tyypilliset kritiikit, jotka kuvaavat sitä Microsoftin työkaluna vaihtoehtoisten järjestelmien estämiseen, eivät pidä paikkaansa, kun UEFI-spesifikaatiota tarkastellaan.Käyttäjä tai ylläpitäjä voi rekisteröidä omat avaimensa, poistaa Microsoftin avaimet, muuttaa PK:ta tai valita luottavansa vain organisaationsa allekirjoittamiin binääreihin, minkä Debian ja muut jakelut dokumentoivat selvästi omissa dokumenteissaan.

Varmaa on, että käytännössä monet Linux-jakelut ovat päättäneet luottaa Microsoftin keskeiseen infrastruktuuriin helpottaakseen vähemmän teknisten käyttäjien elämää.Kun käytetään Microsoft UEFI CA 2011- tai 2023-allekirjoitettuja shim-levyjä, laiteohjelmisto tunnistaa välittömästi jakelun latausohjelman ilman, että käyttäjän tarvitsee koskea manuaalisesti PK:hon, KEK:iin tai db:hen.

Microsoft tarjoaa myös erityisen varmennesertifikaatin kolmannen osapuolen UEFI-ajureiden ja -sovellusten allekirjoittamiseen.Mikä tahansa laitevalmistaja tai kehittäjä, joka tarvitsee ROM-muistia tai UEFI-ajuria käynnistyäkseen Secure Boot -laitteistolla, voi lähettää binääritiedostonsa allekirjoitusprosessiin ja jakaa niitä tietäen, että ne toimivat tietokoneilla, joiden tietokannassa on Microsoftin varmennesertifikaatti.

Tämän järjestelmän vähiten houkutteleva puoli on, että avaimet vanhenevat ja peruutetaan.Kun vanhan juurivarmenteen voimassaoloaika on päättymässä, se on korvattava uudella ja varmistettava, että kaikki laitteet ovat vastaanottaneet vastaavat päivitykset KEK/db/dbx:n kautta. Muuten on olemassa riski, että esimerkiksi fwupd, tietyt käynnistyslataimet tai UEFI ROM -levyt lakkauttavat laiteohjelmiston tuen.

Jos käytät kaksoiskäynnistystä Windowsin ja Linuxin kanssa tai Linux-käyttöönotoissasi on käytössä Secure Boot, sinun kannattaa säännöllisesti tarkistaa Microsoftin ja jakelusi julkaisemat tärkeät päivitykset.Monissa jakeluissa riittää, että hyväksyt laiteohjelmistopäivityspaketit ohjelmistokaupasta tai pakettienhallinnasta, käynnistät tietokoneen uudelleen ja annat laiteohjelmiston ottaa muutokset käyttöön. Toisissa jakeluissa on käytettävä komentoriviä ja tiettyjä apuohjelmia.

Windows-Linux-kaksoiskäynnistys, EFI-osiot ja käynnistysjärjestys

Puhtaan kaksoiskäynnistyksen määrittäminen Windowsin ja Linuxin välille edellyttää hieman ymmärrystä siitä, miten UEFI, EFI-osio ja GRUB-käynnistyksen hallintaohjelma ovat vuorovaikutuksessa.Kun Secure Boot on käytössä, on entistä tärkeämpää olla improvisoimatta, ja on suositeltavaa tarkistaa käynnistysprosessi UEFI-järjestelmissä.

Jos sinulla on jo Windows asennettuna UEFI-tilassa GPT-osiolla, ensimmäinen tehtävä on pienentää Windows-osiota ja varata Linuxille varaamatonta tilaa.Ennen koon muuttamista poista käytöstä ominaisuudet, kuten nopea käynnistys ja BitLocker, yllätysten välttämiseksi. On erittäin tärkeää varmistaa, että järjestelmät jakavat EFI-osion (FAT32, muutama sata Mt).

Linuxia asennettaessa on suositeltavaa käyttää manuaalista osiointia ja kunnioittaa olemassa olevaa EFI-osiota.Asenna se nimellä /boot/efi uuden luomisen sijaan. Tästä eteenpäin luodaan tarvittaessa osiot /-, /home- ja swap-kansioille, ja GRUB asennetaan UEFI-käynnistyksen hallintaohjelmaksi, joka myös osoittaa EFI-osioon.

Jos jakelu tukee Secure Boot -ohjelmaa, asennetaan allekirjoitettu shim ja GRUB, jotka laiteohjelmisto hyväksyy ilman sen kummempia puheita.Muussa tapauksessa sinun on ehkä poistettava Secure Boot käytöstä väliaikaisesti asennuksen loppuun saattamiseksi tai rekisteröitävä manuaalisesti lisäsertifikaatteja tietokantaan, jotta laiteohjelmisto luottaa Linuxin käynnistyslataajaan, ja yhteensopivuusongelmien sattuessa tämä on yleistä. Lisää käynnistysparametrit GRUBiin.

Asennuksen jälkeen järjestelmä saattaa käynnistyä suoraan Windowsiin, koska GRUB-käynnistysmerkintää ei ole priorisoitu.Siinä tapauksessa sinun on käytettävä UEFIa ja muutettava käynnistysjärjestystä tai Linuxissa käytettävä efibootmgr-komentoa merkintöjen järjestämiseen uudelleen. Tätä voi kokeilla myös Windowsissa. bcdedit, bootrec ja reagentcMutta on siistimpää antaa UEFI:n hallita prioriteetteja.

Kun kaikki on määritetty ja avaimet hallittu oikein, voidaan ylläpitää vankkaa kaksoiskäynnistystä, jossa levyt ovat salattuja ja suojattu käynnistys on aktiivinen., ilman että sinun tarvitsee ottaa asetuksia käyttöön ja poistaa käytöstä joka kerta järjestelmää vaihdettaessa tai luopua modernin UEFI-Secure Boot-TPM -arkkitehtuurin tarjoamista tietoturvaeduista.

Viime kädessä Secure Boot -avaintenhallinnan ymmärtäminen Windowsissa ja Linuxissa – PK:sta ja KEK:stä db/dbx:ään, HSM:ään, TPM:ään ja kaksoiskäynnistykseen – on se, mikä tekee eron omien koneiden hallintaan kykenemättömän, käynnistyksen pysäyttävän ja vankan alustan välillä. Alusta on valmis laiteohjelmistopäivityksiin, uusiin jakeluihin ja yhä vaativampiin tietoturvavaatimuksiin menettämättä kuitenkaan omien koneiden hallintaa.

Aiheeseen liittyvä artikkeli:

Käynnistysjäljitys Windows 11:ssä: Täydellinen opas käynnistysprosessien analysointiin

Isaac

Intohimoinen kirjoittaja tavujen maailmasta ja tekniikasta yleensä. Rakastan jakaa tietämykseni kirjoittamalla, ja sen aion tehdä tässä blogissa, näyttää sinulle kaikki mielenkiintoisimmat asiat vempaimista, ohjelmistoista, laitteistoista, teknologisista trendeistä ja muusta. Tavoitteeni on auttaa sinua navigoimaan digitaalisessa maailmassa yksinkertaisella ja viihdyttävällä tavalla.