A Secure Boot az UEFI firmware egyik legfontosabb biztonsági funkciója. Az UEFI a klasszikus BIOS modern utódja, amely már nem egyszerű hardverinicializáló rétegként működik, hanem egy fejlettebb, moduláris firmware-környezetként. A Secure Boot célja, hogy megakadályozza olyan kártékony kódok betöltődését, amelyek még az operációs rendszer előtt próbálnának elindulni. Ezeket a támadásokat általában bootkitnek vagy rootkitnek nevezik, és különösen veszélyesek, mert a rendszer legalsó rétegeiben képesek elrejtőzni, gyakran még az antivírusok és a kernel szintű védelmek előtt. A modern operációs rendszerek – legyen szó Linuxról, BSD-ről vagy Windowsról – egyre szorosabban integrálják ezt a mechanizmust, mivel a bootfolyamat elleni támadások az egyik legveszélyesebb kompromittációs lehetőséget jelentik. Egy bootkit vagy rootkit képes lehet még az operációs rendszer előtt átvenni az irányítást a gép felett, ezért a Secure Boot gyakorlatilag a rendszer legelső védelmi vonala.

A Secure Boot működése digitális aláírásokra és tanúsítványokra épül. Az UEFI firmware csak olyan bootloadereket, kerneleket és drivereket hajlandó betölteni, amelyek megfelelő kriptográfiai aláírással rendelkeznek. Ezeket az aláírásokat tanúsítványok hitelesítik, amelyek meghatározott ideig érvényesek. Ez azt jelenti, hogy a Secure Boot infrastruktúra kulcsai és tenúsítványai idővel lejárhatnak, visszavonásra kerülhetnek vagy lecserélődhetnek. Amikor ez megtörténik, a rendszer akár teljesen működésképtelenné válhat: a firmware megtagadhatja a bootloader indítását, a kernel nem töltődik be, vagy bizonyos driverek és modulok egyszerűen elutasításra kerülnek.

A Secure Boot mögött egy összetett kulcskezelési lánc található. A Platform Key, vagyis a PK határozza meg a platform tulajdonosát, a KEK kulcsok a frissítések és kulcscserék kezelésére szolgálnak, a db adatbázis tartalmazza a megbízható aláírásokat, míg a dbx a visszavont vagy tiltott komponensek listáját. A rendszerindítás során a firmware nem egyszerűen betölti a bootloadert, hanem minden egyes komponens digitális aláírását ellenőrzi. Ha egy komponens olyan tanúsítvánnyal van aláírva, amelyet a firmware megbízhatónak tekint, akkor továbbengedi a rendszerindítási folyamatot. Ha nem, a boot folyamat megszakad. Ez a mechanizmus biztosítja, hogy csak hiteles és ellenőrzött kód fusson a Linux, a Windows, vagy a BSD indulása előtt.

A firmware ezen kívül két fontos adatbázist is tárol. Az egyik a DB, amely a megbízható aláírásokat tartalmazza, a másik pedig a DBX, amely a tiltott vagy visszavont aláírások listája. A DBX szerepe az elmúlt években különösen felértékelődött, mivel több súlyos Secure Boot megkerülési sérülékenységet is találtak. Ezek közül az egyik legismertebb a BlackLotus bootkit volt, amely képes volt megkerülni bizonyos régebbi Secure Boot implementációkat.

A tanúsítványok lejárata mögött többféle ok állhat. Egyes esetekben egyszerűen a kriptográfiai élettartam végéhez ér egy kulcs, máskor biztonsági incidensek miatt vonnak vissza bizonyos aláírásokat. Előfordulhat az is, hogy új hardveres vagy operációs rendszeres követelmények miatt új CA láncra kell áttérni. A Microsoft például rendszeresen frissíti a Secure Boot infrastruktúrát annak érdekében, hogy kiszűrje a sérülékeny bootloadereket és exploitokat.

A problémák különböző formában jelentkezhetnek. Linux rendszereken tipikus hiba a „Secure Boot Violation” vagy a „Verification failed” üzenet, illetve az, hogy bizonyos kernelmodulok – például az NVIDIA driver vagy a VirtualBox DKMS moduljai – nem töltődnek be. BSD rendszereken gyakran a loader.efi aláírásával vagy a saját EFI binárisok hitelesítésével adódik gond. Windows alatt pedig előfordulhat BitLocker recovery mód, boot failure vagy driver signing probléma is.

A Secure Boot mögött egy teljes kulcshierarchia dolgozik. Ennek legfelső szintjén található a Platform Key, vagyis a PK, amelyet jellemzően maga a hardvergyártó – például Dell, Lenovo, HP vagy ASUS – kezel. Ez határozza meg, ki módosíthatja a Secure Boot konfigurációját. A következő szinten a KEK, vagyis a Key Exchange Key helyezkedik el. Ez már arra szolgál, hogy új tanúsítványokat lehessen hozzáadni vagy régieket visszavonni. A Microsoft saját KEK tanúsítvánnyal rendelkezik, amelyet a Windows-alapú eszközök világszerte használnak.

Linux rendszereken az első és legfontosabb lépés a firmware frissítése. Szinte minden nagyobb gyártó – Dell, Lenovo, HP, ASUS és mások – firmware update-ekkel frissíti a Secure Boot adatbázisokat és a tiltólistákat. Modern Linux disztribúciókon erre kiváló megoldás az fwupd infrastruktúra, amely képes közvetlenül az operációs rendszerből kezelni az UEFI firmware frissítéseket. Egy elavult firmware könnyen inkompatibilissé válhat az újabb shim vagy GRUB verziókkal.

A Linux Secure Boot lánc egyik kulcseleme a shim. Ez egy Microsoft által aláírt kis bootloader, amely lehetővé teszi, hogy a Linux disztribúciók saját kulcskezelést használjanak anélkül, hogy közvetlenül a firmware-be kellene integrálniuk minden saját tanúsítványukat. Ha a shim tanúsítványa lejár vagy visszavonásra kerül, akkor a teljes Linux bootfolyamat megállhat. Emiatt kritikus a shim és a GRUB rendszeres frissítése.

Az elmúlt években különösen nagy figyelmet kaptak a Microsoft UEFI CA kulcsainak változásai, valamint a különböző Linux shim és GRUB aláírások frissítései. Sok rendszergazda csak akkor szembesült a problémával, amikor egy firmware update vagy egy dbx tiltólista-frissítés után a gépek nem bootoltak többé. A Secure Boot tanusítványok lejárata tehát nem elméleti kérdés, hanem nagyon is gyakorlati üzemeltetési probléma.

Különösen sok problémát okoznak a harmadik féltől származó kernelmodulok. Az NVIDIA driver, a VMware, a VirtualBox vagy bizonyos ZFS modulok gyakran saját DKMS buildet használnak. Secure Boot alatt ezek csak akkor tölthetők be, ha megfelelően alá vannak írva. Egy lejárt vagy visszavont tanúsítvány miatt a kernel egyszerűen megtagadhatja a modul betöltését. Ilyenkor gyakran új MOK kulcsot kell generálni és újra kell aláírni a modulokat.

A Machine Owner Key, vagyis a MOK infrastruktúra Linux alatt lehetővé teszi a felhasználó számára saját aláíró kulcsok használatát. Ez különösen hasznos egyedi kernelmodulok, saját kernelek vagy vállalati appliance rendszerek esetén. A probléma azonban az, hogy ezeknek a kulcsoknak is van lejárati idejük, így rendszeres kulcsrotációra van szükség. Egy rosszul menedzselt MOK infrastruktúra könnyen oda vezethet, hogy egy kernel update után a rendszer többé nem képes bootolni.

BSD rendszereknél a helyzet valamivel fragmentáltabb. A FreeBSD például viszonylag fejlett Secure Boot támogatással rendelkezik, és sok adminisztrátor saját PK/KEK/db struktúrát használ. Ilyenkor a loader.efi és más EFI binárisok újraaláírása rendszeres üzemeltetési feladattá válik. OpenBSD esetén sok környezetben egyszerűen kikapcsolják a Secure Bootot, mivel a projekt hagyományosan konzervatívabb az ilyen integrációk terén. NetBSD alatt szintén gyakori a custom EFI signing és a shim-alapú megoldások használata.

Windows rendszereken a legtöbb Secure Boot kulcsfrissítés a Windows Update mechanizmuson keresztül érkezik. A Microsoft rendszeresen frissíti a db és dbx adatbázisokat, illetve a boot managert is. Ezért kritikus, hogy a rendszerek naprakészek legyenek. Egy régi Windows telepítő vagy WinPE image könnyen használhatatlanná válhat egy újabb Secure Boot policy mellett.

Külön figyelmet igényel a BitLocker integráció. Mivel a TPM és a Secure Boot állapota szorosan összekapcsolódik, egy firmware vagy kulcsfrissítés könnyen recovery módot indíthat el. Sok rendszergazda csak ekkor szembesül azzal, hogy nincs meg a BitLocker recovery kulcs. Emiatt minden nagyobb firmware vagy Secure Boot módosítás előtt kötelező a recovery key archiválása.

A virtualizációs környezetekben további komplikációk jelennek meg. Hyper-V, VMware, KVM vagy Proxmox alatt a virtuális Secure Boot és a virtual TPM implementációk külön kezelést igényelnek. Egyes virtuális gépsablonok régi shim vagy EFI binárisokat tartalmazhatnak, amelyek új dbx policy mellett már nem indulnak el.

A régebbi hardverek különösen problémásak lehetnek. Számos korai UEFI implementáció hibásan kezeli a dbx frissítéseket vagy nem támogat bizonyos modernebb SHA-256 alapú policy-ket. Előfordulhat, hogy egy firmware update után a Secure Boot teljesen használhatatlanná válik, és csak firmware downgrade vagy a Secure Boot kikapcsolása segít.

Üzemeltetési szempontból a legfontosabb szabály, hogy minden Secure Boot változtatást kontrollált környezetben kell tesztelni. Egy hibás dbx update vagy lejárt shim tanúsítvány tömeges bootolási hibát okozhat vállalati környezetben. Emiatt ajánlott staging rendszereket használni, rendszeres firmware inventoryt készíteni és monitorozni a kulcsok lejárati idejét. A Secure Boot tanúsítványok lejárata tehát nem egyszerű technikai részlet, hanem a modern platformbiztonság egyik legkritikusabb üzemeltetési kérdése. Linux alatt a shim, a GRUB és a kernelmodulok megfelelő aláírása kulcsfontosságú. BSD rendszereken sokszor saját kulcsinfrastruktúra és EFI signing szükséges. Windows alatt a firmware update-ek, a BitLocker és a driver signing kompatibilitás jelenti a legnagyobb kihívást.

A most lejáró tanúsítványok többsége még 2011-ben készült, amikor a Windows 8 bevezette a Secure Boot támogatását. Ezek a kulcsok több mint egy évtizeden keresztül szolgálták a Windows és egyéb ökoszisztémát, azonban a kriptográfiai infrastruktúrák természetéből adódóan minden tanúsítványnak van lejárati ideje. Ez nem hiba vagy rendellenesség, hanem alapvető biztonsági követelmény. Minél tovább használatban marad egy kulcs, annál nagyobb az esélye annak, hogy idővel kompromittálódik, vagy egyszerűen technológiailag elavul.

A Microsoft ezért új, 2023-as tanúsítványokat vezet be. A „Microsoft Corporation KEK CA 2011” helyét például a „Microsoft Corporation KEK 2K CA 2023” veszi át. A Windows Boot Manager aláírására használt „Microsoft Windows Production PCA 2011” helyett pedig a „Windows UEFI CA 2023” kerül használatba. Érdekes változás az is, hogy a korábbi egységes Microsoft UEFI CA tanúsítványt kettéválasztják. Az egyik új tanúsítvány a külső bootloaderek és EFI alkalmazások hitelesítésére szolgál majd, míg a másik kizárólag az úgynevezett Option ROM-okhoz kapcsolódik.

Az Option ROM olyan firmware-modul, amely valamely hardvereszközhöz tartozik, például RAID vezérlőhöz, hálózati bootkártyához vagy bizonyos PCIe eszközökhöz. Ezek a komponensek még az operációs rendszer előtt futnak, ezért különösen fontos a hitelességük ellenőrzése. A tanúsítványok szétválasztásával a Microsoft finomabb kontrollt biztosít a gyártóknak és a rendszergazdáknak. Egy szervezet például dönthet úgy, hogy engedélyezi az Option ROM-ok futását, miközben nem bízik meg minden külső bootloaderben.

Nagyon fontos hangsúlyozni, hogy a tanúsítványok lejárata nem jelenti azt, hogy a Windows 2026 után használhatatlanná válik. A Microsoft hivatalos dokumentációja alapján azok az eszközök, amelyek nem kapják meg az új 2023-as tanúsítványokat, továbbra is elindulnak és működnek. A Windows Update is működhet tovább normál módon. A probléma inkább hosszabb távon jelentkezik majd. Az ilyen rendszerek ugyanis nem kapnak új Secure Boot biztonsági frissítéseket, új visszavonási listákat, valamint problémák léphetnek fel a modern bootloaderekkel és firmware-komponensekkel.

Ez különösen érzékenyen érintheti a BitLockert, mivel annak megbízhatósági modellje részben a Secure Boot integritására épül. Ha a rendszerindítási lánc már nem tekinthető naprakésznek, előfordulhatnak helyreállítási kulcsot kérő események vagy kompatibilitási problémák. Hasonlóan érintheti a Linux dual-boot rendszereket is, mivel sok Linux disztribúció Microsoft által aláírt shim bootloadert használ a Secure Boot támogatásához.

A legtöbb modern Windows 10 és Windows 11 rendszer valószínűleg automatikusan megkapja a szükséges frissítéseket. Sok esetben a felhasználónak semmit sem kell tennie azon kívül, hogy telepíti a Windows és firmware frissítéseket. A helyzet inkább a régebbi hardvereknél lehet problémás, főleg a 2012 és 2015 közötti korai UEFI implementációknál. Egyes régi alaplapok vagy notebookok esetében elképzelhető, hogy a gyártó már nem biztosít firmware-frissítést, így ezek hosszú távon fokozatosan kieshetnek a modern Secure Boot ökoszisztémából.

Vállalati környezetben a helyzet ennél jóval összetettebb. A rendszergazdáknak auditálniuk kell a Secure Boot állapotát, tesztelniük kell a firmware-kompatibilitást, ellenőrizniük kell a BitLocker működését, valamint validálniuk kell a rendszerindítási láncot minden támogatott hardverplatformon. Nagy infrastruktúrák esetében a Secure Boot tanúsítványfrissítés valójában egy több éves migrációs projektnek tekinthető.

Az egész történet jól mutatja, hogy a modern operációs rendszerek biztonsága ma már messze nem csak az antivírusokról vagy a felhasználói jogosultságokról szól. A támadások egyre mélyebbre költöznek a rendszerarchitektúrában, ezért a firmware és a bootfolyamat védelme stratégiai jelentőségűvé vált. A Microsoft jelenlegi lépése tehát nem egy egyszerű tanúsítványcsere, hanem a Windows teljes bootbiztonsági infrastruktúrájának következő generációs átállása.

A legfontosabb tanulság, hogy a Secure Bootot nem elég egyszer bekapcsolni és elfelejteni. A kulcsok, tanúsítványok és tiltólisták folyamatos karbantartást igényelnek. Egyetlen lejárt vagy visszavont tanúsítvány is elegendő lehet ahhoz, hogy egy teljes rendszer indíthatatlanná váljon.

Mi az a Secure Boot?

A Secure Boot az UEFI firmware része. A rendszerindítás során ellenőrzi:

1. a bootloader aláírását,
2. az operációs rendszer kernelét,
3. opcionálisan a kernelmodulokat és drivereket.

A hitelesítés kulcsok és tanúsítványok láncolatával történik.

A legfontosabb elemek:

Elem	Szerep
PK (Platform Key)	A platform tulajdonosának főkulcsa
KEK (Key Exchange Key)	Kulcscsere és frissítés
db	Megbízható aláírások adatbázisa
dbx	Tiltott / visszavont aláírások

A firmware csak olyan komponenseket indít el, amelyek:

• szerepelnek a megbízható adatbázisban,
• és nincsenek tiltólistán.

Miért járnak le a Secure Boot tanúsítványok?

A digitális tanúsítványok lejárata normális biztonsági folyamat.

Ennek okai:

• kriptográfiai algoritmusok elavulása,
• kompromittált kulcsok visszavonása,
• új hardveres és firmware követelmények,
• CA (Certificate Authority) policy változások,
• Microsoft UEFI CA kulcsfrissítések.

Különösen fontosak:

• Microsoft Windows Production PCA kulcsok,
• Microsoft UEFI CA tanúsítványok,
• shim és GRUB aláíró kulcsok Linux alatt.

ilyen hibák jelentkezhetnek?

Tipikus tünetek

Linux

• „Secure Boot Violation”
• „Verification failed”
• kernel module rejected
• NVIDIA driver nem töltődik beA Linux Mint és az Ubuntu támogatják a Secure Boot-ot, de voltak kompatibilitási problémák az Ubuntu és a Linux Mint-ben is használt shim-signed csomaggal.
• DKMS modulok elutasítása
• shim vagy GRUB nem indul

BSD

• loader.efi betöltési hiba
• saját aláírású EFI binárisok elutasítása
• kernel integrity hibák

Windows

• BitLocker recovery kérés
• boot failure
• Secure Boot policy violation
• régi boot media nem indul
• aláíratlan driver blokkolása

Hogyan ellenőrizhető a Secure Boot állapota?

Linux

Secure Boot státusz

mokutil --sb-state

Válasz bekapcsolt Secure Boot esetében:

SecureBoot enabled

Válasz kikapcsolt Secure Boot esetében:

SecureBoot disabled

Vagy, ha a systemd-boot csomag telepítve van:

bootctl status

Telepített kulcsok listázása

efi-readvar

Ami kiírja az összes tanúsítvány (részlet)t:

Variable PK, length 886
PK: List 0, type X509
    Signature 0, size 858, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK MotherBoard PK Certificate
        Issuer:
            CN=ASUSTeK MotherBoard PK Certificate
Variable KEK, length 3573
KEK: List 0, type X509
    Signature 0, size 861, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK MotherBoard KEK Certificate
        Issuer:
            CN=ASUSTeK MotherBoard KEK Certificate
KEK: List 1, type X509
    Signature 0, size 1532, owner 77fa9abd-0359-4d32-bd60-28f4e78f784b
        Subject:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011
        Issuer:
            C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root
KEK: List 2, type X509
    Signature 0, size 1096, owner 6dc40ae4-2ee8-9c4c-a314-0fc7b2008710
        Subject:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
        Issuer:
            C=GB, ST=Isle of Man, L=Douglas, O=Canonical Ltd., CN=Canonical Ltd. Master Certificate Authority
Variable db, length 6322
db: List 0, type X509
    Signature 0, size 870, owner 3b053091-6c9f-04cc-b1ac-e2a51e3be5f5
        Subject:
            CN=ASUSTeK MotherBoard SW Key Certificate
        Issuer:
            CN=ASUSTeK MotherBoard SW Key Certificate
db: List 1, type X509

dbx visszavonási lista

efi-readvar -v dbx

BSD

FreeBSD alatt:

efivar -l

UEFI változók vizsgálata:

efivar -p -n db

OpenBSD és NetBSD rendszereken gyakran firmware-függő a támogatás.

Windows

PowerShell:

Confirm-SecureBootUEFI

Válasz bekapcsolt Secure Boot esetében:

True

Válasz kikapcsolt Secure Boot esetében:

False

Tanúsítványok:

Get-SecureBootUEFI db

Példa a válaszra:

Name Bytes                Attributes
---- -----                ----------
db   {161, 89, 192, 165…} NON VOLATILE…

UEFI események:

Get-WinEvent -LogName Microsoft-Windows-Kernel-Boot/Operational

Linux: mit kell tenni?

1. Firmware frissítése

Az első és legfontosabb lépés.

Sok gyártó firmware update-ben frissíti:

• a db adatbázist,
• a dbx tiltólistát,A Linux Mint és az Ubuntu támogatják a Secure Boot-ot, de voltak kompatibilitási problémák az Ubuntu és a Linux Mint-ben is használt shim-signed csomaggal.
• Microsoft UEFI CA kulcsokat.

fwupd használata

Modern disztribúciókon:

fwupdmgr refresh
fwupdmgr get-updates
fwupdmgr update

2. Shim és GRUB frissítése

A Linux Secure Boot lánc kulcseleme a shim. A Linux Mint és az Ubuntu támogatják a Secure Boot-ot, de voltak kompatibilitási problémák az Ubuntu és a Linux Mint-ben is használt shim-signed csomaggal.

A shim:

• Microsoft által aláírt,
• betölti a GRUB-ot,
• kezeli a Machine Owner Key (MOK) rendszert.

Frissítés

Debian/Ubuntu:

sudo apt update
sudo apt upgrade shim-signed grub-efi-amd64

RHEL / AlmaLinux / Rocky:

sudo dnf update shim grub2

Arch:

sudo pacman -Syu shim grub

3. DKMS és kernelmodulok újraaláírása

A lejáró tanúsítványok sokszor a harmadik féltől származó modulokat érintik:

• NVIDIA
• VirtualBox
• VMware
• ZFS
• WireGuard régebbi buildjei

Ellenőrzés:

modinfo -F signer nvidia

Újraaláírás:

/usr/src/linux-headers-$(uname -r)/scripts/sign-file \
sha256 \
MOK.priv \
MOK.der \
module.ko

4. MOK kulcsok újragenerálása

Ha saját Secure Boot infrastruktúrát használsz:

openssl req -new -x509 -newkey rsa:4096 \
-keyout MOK.priv \
-outform DER \
-out MOK.der \
-nodes -days 3650

Importálás:

sudo mokutil --import MOK.der

A következő boot során a MOK Manager felületen jóvá kell hagyni.

5. dbx frissítések kezelése

A dbx tiltólista frissítése kritikus.

Egy hibás dbx update:

• blokkolhat régi shim verziókat,
• bootloopot okozhat,
• recovery módot tehet szükségessé.

Ezért:

• mindig legyen recovery USB,
• tesztelj staging gépen,
• ellenőrizd a firmware release note-okat.

BSD rendszerek: sajátosságok

A BSD rendszerek Secure Boot támogatása eltérő.

FreeBSD

A FreeBSD támogatja:

• UEFI bootot,
• loader.efi aláírást,
• Secure Bootot,
• saját kulcskezelést.

Ajánlott lépések

1. Firmware frissítés
2. Mindig első lépés.
3. Saját kulcsok kezelése

Sok FreeBSD admin saját PK/KEK/db struktúrát használ.

Ellenőrizni kell:

• lejárati dátumokat,
• hash algoritmusokat,
• EFI executable aláírásokat.

loader.efi újraaláírása

sbsign --key db.key --cert db.crt loader.efi

OpenBSD

OpenBSD esetén gyakran:

• kikapcsolják a Secure Bootot,
• vagy saját aláírt bootloadert használnak.

A támogatás konzervatívabb.

Ha Secure Boot aktív:

• firmware kompatibilitást kell ellenőrizni,
• saját EFI binárisokat kell aláírni.

NetBSD

NetBSD alatt a Secure Boot támogatás kevésbé kiforrott.

Tipikus megoldások:

• shim használata,
• custom EFI signing,
• saját PK/KEK kezelés.

Windows: mit kell tenni?

1. Windows Update telepítése

A Microsoft rendszeresen frissíti:

• Secure Boot DB-t,
• dbx visszavonási listát,
• boot managert,
• CA láncokat.

Ezért kritikus:

Settings → Windows Update → Check for updates

Szervereken:

Install-WindowsUpdate

2. OEM firmware frissítések

Dell, HP, Lenovo, ASUS és más gyártók:

• BIOS/UEFI update-ben frissítik a Secure Boot kulcsokat.

Különösen fontos:

• régebbi TPM implementációk,
• Windows 11 kompatibilitás,
• BitLocker integráció.

3. Régi boot média cseréje

Régi:

• Windows installerek,
• WinPE image-ek,
• recovery ISO-k,
• PXE image-ek

nem biztos, hogy működni fognak új dbx policy mellett. Frissített telepítőket kell használni.

4. BitLocker recovery kezelése

Firmware vagy Secure Boot kulcsváltozás után:

• a TPM állapot változhat,
• BitLocker recovery key kérhető.

Mindenképpen legyen:

• exportált recovery key,
• AD/Azure backup,
• offline mentés.

Recovery key export:

manage-bde -protectors -get C:

5. Illesztőprogram signing problémák

Régebbi illesztőprogamoknál:

• SHA-1 aláírás,
• lejárt cross-signing cert,
• inkompatibilis kernel driver

miatt blokkolódhatnak.

Megoldás:

• új driver,
• WHQL verzió,
• gyártói update.

Saját Secure Boot infrastruktúra

Haladó környezetekben:

• saját PK/KEK/db kulcsokat használnak,
• Linux appliance-ek,
• ipari rendszerek,
• virtualizációs hostok,
• embedded rendszerek.

Ilyenkor fontos:

• rendszeres kulcsrotáció,
• lejárati monitoring,
• HSM használat,
• offline root key tárolás,
• recovery folyamat dokumentálása.

Mire kell különösen figyelni?

Kettős boot rendszerek

Windows + Linux dual boot esetén:

• firmware update megváltoztathatja a boot sorrendet,
• dbx frissítés blokkolhat régi Linux shim-et,
• BitLocker recovery indulhat.

Virtualizáció

VMware, Hyper-V, KVM és Proxmox alatt:

• virtuális TPM,
• virtual Secure Boot,
• EFI template-ek

külön frissítést igényelhetnek.

Régi hardverek

Egyes régi UEFI implementációk:

• hibás dbx kezelést végeznek,
• nem támogatnak új SHA-256 policy-t,
• Secure Boot brick állapotot okozhatnak.

Ilyenkor:

• firmware downgrade,
• Secure Boot disable,
• vagy hardvercsere szükséges.

Ajánlott üzemeltetési gyakorlat

Otthoni felhasználóknak

• rendszeres firmware update,
• naprakész operációs rendszer,
• recovery USB készítése,
• BitLocker kulcs mentése.

Rendszergazdáknak

• staging környezet,
• dbx tesztelés,
• automatizált firmware inventory,
• Secure Boot audit,
• kulcslejárati monitoring.

Vállalati környezetben

• központi firmware management,
• PKI dokumentáció,
• HSM integráció,
• TPM policy kezelés,
• disaster recovery terv.

Összegzés

A biztonsági fenyegetések növekedése miatt az utóbbi években a számítógép gyártói egyre több biztonsági funkciót vezettek be, amelyek megakadályozzák a rosszindulatú programok és a számítógépes támadások által okozott károkat. Az egyik ilyen funkció a Secure Boot, vagyis a biztonságos rendszerindítás. A Secure Boot olyan biztonsági funkció, amely megakadályozza a nem engedélyezett operációs rendszerek és illesztőprogramok futtatását a számítógépen. A Secure Boot rendszere a számítógép BIOS-ában vagy UEFI-jében található, és egy digitális aláírást használ a rendszerindítási folyamat ellenőrzésére. A digitális aláírás a számítógép gyártójától származó tanúsítvány, amely megerősíti, hogy az operációs rendszer és az illesztőprogramok biztonságosak és engedélyezettek. Ha az operációs rendszer vagy illesztőprogram digitális aláírása nem megfelelő, akkor a Secure Boot rendszere figyelmeztetést ad, és megakadályozza a rendszerindítást.

A Secure Boot használata fontos a számítógépek biztonsága szempontjából, mivel megakadályozza a kártékony programok futtatását, amelyek lehetővé tennék a támadók számára a személyes adatok és a rendszerirányítás megszerzését.

A Secure Boot tanúsítványok lejárata nem hiba, hanem a modern platformbiztonság természetes része. A probléma akkor jelentkezik, ha:

• a firmware elavult,
• a bootloader régi,
• a kernelmodulok nincsenek újraaláírva,
• vagy a rendszer nem kezeli megfelelően a kulcsváltásokat.

Linux alatt a shim, a GRUB és a DKMS modulok frissítése a legfontosabb. BSD rendszereknél gyakran saját kulcskezelés és EFI signing szükséges. Windows alatt a firmware és a Windows Update kritikus szerepet játszik.

A legfontosabb tanács:

• mindig legyen recovery lehetőség,
• firmware backup,
• és dokumentált kulcskezelési folyamat.

A Secure Boot megfelelő karbantartása nélkül egy egyszerű firmware frissítés is teljes bootolási problémához vezethet.

Secure Boot használata a Linux Mint és Ubuntu alatt

A Linux Mint és az Ubuntu is támogatja a Secure Boot-ot, és beépített mechanizmusokat biztosít a digitális aláírások ellenőrzéséhez. Azonban az Ubuntu shim-signed csomagjának frissítése egy ideig eltörölte a Linux Mint korábbi verzióinak Secure Boot kompatibilitását, és a telepítés sikertelenné vált.

Az Ubuntu és a Linux Mint operációs rendszerei a Secure Boot használatához szükséges kulcsokat és tanúsítványokat tartalmazzák a UEFI-ben. Ez azt jelenti, hogy amikor a számítógép elindul, a BIOS vagy az UEFI ellenőrzi, hogy az operációs rendszer és az illesztőprogramok digitális aláírása megfelelő-e, mielőtt engedélyezi a rendszer betöltését. A Shim az első szintű bootloader, amit a Secure Boot támogatására fejlesztettek ki. Shim-nak hívjuk, mert olyan objektumként szolgál, ami betölti az űrt a Microsoft és saját megbízhatósági rendszer között. A tervezés során eredetileg csak a megfelelően aláírt binárisok betöltését és ellenőrzését végzi, de azóta valamivel bonyolultabb lett. Azonban alapvetően funkcionálisan kész - nem várható jelentős további bővítése.

Ha Secure Boot beállítása mellett nem sikerül telepíteni a Linux Mint-et, a fejlesztők egyelőre a Secure Boot letiltását javasolják.

Hogyan kell beállítani a Secure Boot-ot?

A Secure Boot beállítása a Linux Mint és az Ubuntu alatt egyszerű. Először is, ellenőrizni kell, hogy az operációs rendszer támogatja-e a Secure Bootot. Ez általában a legújabb verziókban érhető el. Ha az operációs rendszer támogatja a Secure Boot-ot, akkor meg kell győződni arról, hogy a számítógép támogatja-e ezt a funkciót. A Secure Bootot a számítógép BIOS vagy UEFI beállításaiban lehet engedélyezni vagy letiltani.

A Secure Boot engedélyezéséhez kövesse az alábbi lépéseket:

1. Indítsa el a számítógépet és nyomja meg az adott billentyűt (általában a Del, F2 vagy F10 gombot), hogy beléphessen a BIOS vagy az UEFI beállításaiba.
2. Keresse meg a „Boot” vagy „Security” menüt a beállítások között.
3. Keressen egy „Secure Boot” lehetőséget, és állítsa be az értékét „Enabled”-re.
4. Ha szükséges, hozzáadhatja az engedélyezett kulcsokat és tanúsítványokat is.
5. Mentse el a beállításokat és indítsa újra a számítógépet.

A Secure Boot beállítása után a rendszer csak az engedélyezett digitális aláírásokkal rendelkező operációs rendszereket és illesztőprogramokat indítja el és használja.