1. Audyt stanu systemu

1. System state audit

Uruchom poniższe polecenie w konsoli PowerShell (Uruchom jako Administrator). Kliknij przycisk, aby przenieść kod do schowka jako idealny, nienaruszony oneliner:

Run the following command in a PowerShell (Run as Administrator) console. Click the button to copy the code to your clipboard as a perfect, intact oneliner:

powershell -c {try{$sb=Confirm-SecureBootUEFI}catch{$sb=$false};try{$db=Get-SecureBootUEFI -Name db; $ca=([System.Text.Encoding]::ASCII.GetString($db.Bytes) -match "UEFI CA 2023")}catch{$ca=$false};try{$bl=(Get-BitLockerVolume -MountPoint C:).ProtectionStatus -eq 'On'}catch{$bl=$false};$q=(Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot" -Name "AvailableUpdates" -ErrorAction SilentlyContinue).AvailableUpdates;$qs=if($null -eq $q){"Brak_Danych"}elseif($q -eq 16384 -or $q -eq 0){"Sukces($q)"}elseif($q -eq 320){"Zaplanowano(320)"}elseif($q -eq 256){"W_Toku(256)"}else{"Inny($q)"};$r=if($sb -and $ca){"READY"}elseif($q -eq 320 -or $q -eq 256){"REBOOT_PENDING"}elseif(-not $sb){"BLOCKED"}else{"RISK"};Write-Output "SecureBoot=$sb | BitLocker=$bl | UEFI_CA_2023=$ca | UpdateQueue=$qs | RESULT=$r";exit([int](-not($sb -and $ca)))}

2. Rozpiska i interpretacja zwracanych statusów

2. Breakdown and interpretation of returned statuses

Skrypt ten został zaprojektowany, aby w jednym, szybkim wywołaniu zbadać 5 kluczowych obszarów bezpieczeństwa sprzętowego i systemowego, nie wymagając od administratora szukania informacji w wielu różnych miejscach. Zwraca on zawsze przejrzysty ciąg znaków przypominający logowanie. Przykład:

This script is designed to examine 5 key areas of hardware and system security in a single, fast call, without requiring the administrator to look for information in many different places. It always returns a clear logging-style string. Example:

SecureBoot=True | BitLocker=True | UEFI_CA_2023=False | UpdateQueue=Brak_Danych | RESULT=RISK

Oto co dokładnie oznacza każdy wyodrębniony parametr w wyjściu skryptu:

Here is exactly what each extracted parameter in the script's output means:

A. Podstawowe flagi diagnostyczne

A. Basic diagnostic flags

B. Status kolejki aktualizacji systemowej (UpdateQueue)

B. System update queue status (UpdateQueue)

C. Status końcowy operacji (RESULT)

C. Final operation status (RESULT)

3. Wymuszenie aktualizacji rejestru

3. Force registry update

Jeśli w Kroku 2 system zwrócił status RISK lub Brak_Danych, dodaj wymaganą flagę bitową aktualizacji bezpośrednio do rejestru za pomocą poniższego polecenia:

If in Step 2 the system returned RISK or Brak_Danych, add the required update bit flag directly to the registry using the following command:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot" -Name "AvailableUpdates" -Value 0x140 -Type DWord -Force

4. Wymuszenie wykonania zadania systemowego

4. Force execution of system task

Aby natychmiast wyzwolić natywne zadanie harmonogramu Windows odpowiedzialne za wdrożenie przygotowanych certyfikatów baz kluczy Secure Boot, użyj komendy:

To immediately trigger the native Windows Scheduled Task responsible for deploying the prepared Secure Boot key database certificates, use the command:

powershell -Command {Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"}

5. Różnice we wdrażaniu na różnych platformach (OEM, Serwery, Wirtualizacja)

5. Deployment differences across platforms (OEM, Servers, Virtualization)

Po wykonaniu wcześniejszych kroków odczekaj minimum 30 sekund, a następnie wykonaj pełny restart systemu operacyjnego. Często wymagane są dwa cykle restartu, by certyfikaty zaktualizowały się w całości.

After completing previous steps, wait at least 30 seconds, then perform a full restart of the operating system. Often two reboot cycles are required for the certificates to fully update.

Wgrywanie nowych certyfikatów z poziomu systemu operacyjnego Windows opiera się na tym, jak dany producent zaimplementował proces obsługi zmiennych UEFI i sprawdzania klucza KEK. Zobacz jak zarządzać różnymi typami środowisk sprzętowych:

Uploading new certificates from Windows relies heavily on how a given manufacturer implemented the handling of UEFI variables and KEK verification. See how to manage different types of hardware environments:

A. Sprzęt biznesowy (Dell, HP, Lenovo)

A. Enterprise client hardware (Dell, HP, Lenovo)

• Najwięksi gracze zazwyczaj radzą sobie z aktualizacjami bazy kluczy wzorowo i wspierają aktualizacje wymuszane z poziomu Windows Update (czyli przez skrypt opisany w krokach 1-4). The biggest players usually handle key database updates flawlessly and support updates forced via Windows Update (i.e. the script from steps 1-4).
• Dodatkowo nowsze paczki z BIOSem publikowane w HP Support Assistant, Lenovo Commercial Vantage czy Dell Command Update w większości przypadków zawierają zaszyty nowy zbiór certyfikatów db i dbx. Sama aktualizacja BIOS od producenta często wystarczy, by podmienić bazy w NVRAM, zanim Windows w ogóle tego zażąda. Additionally, newer BIOS packages published in HP Support Assistant, Lenovo Commercial Vantage, or Dell Command Update in most cases contain the embedded new set of db and dbx certificates. A simple manufacturer BIOS update is often enough to replace the databases in NVRAM before Windows even requests it.

B. Płyty konsumenckie i gamingowe (ASUS, Gigabyte, MSI, ASRock)

B. Consumer and gaming motherboards (ASUS, Gigabyte, MSI, ASRock)

• Często mają problemy z autoryzacją ładunków od Microsoftu przesyłanych przez OS (z powodu błędów implementacji lub przestarzałych kluczy KEK). Skutkuje to bezgłośnym ignorowaniem aktualizacji ze strony Windows (błąd "Invalid signature ──> Update rejected" po restarcie). They often struggle to authorize payloads from Microsoft sent via OS (due to implementation bugs or outdated KEK keys). This results in silently ignoring the Windows update (an "Invalid signature ──> Update rejected" error after reboot).
• Rozwiązaniem jest aktualizacja BIOSu do najnowszej wersji, wejście w jego ustawienia i przejście do sekcji Security -> Secure Boot -> Key Management. The solution is to update the BIOS to the latest version, enter its settings and navigate to Security -> Secure Boot -> Key Management.
• Należy użyć tam wbudowanych opcji np. Restore Factory Keys, Reset to Default lub Install Default Secure Boot Keys. Załaduje to poprawne klucze (w tym MS 2023) przypisane do nowej wersji BIOS przez producenta płyty. Use built-in options there, e.g. Restore Factory Keys, Reset to Default, or Install Default Secure Boot Keys. This will load the correct keys (including MS 2023) assigned to the new BIOS version by the motherboard manufacturer.

C. Platformy serwerowe (Supermicro, Dell EMC, HPE)

C. Server platforms (Supermicro, Dell EMC, HPE)

• Środowiska serwerowe mają rygorystyczne zasady bezpieczeństwa (lockdown) i często całkowicie blokują systemowi operacyjnemu (Windows Server / Linux) możliwość modyfikacji zmiennych BIOS z tzw. "poziomu in-band". Server environments have strict security policies (lockdown) and often completely block the operating system (Windows Server / Linux) from modifying BIOS variables from the so-called "in-band" level.
• Na sprzęcie np. Supermicro, certyfikaty zazwyczaj wgrywa się ręcznie przez wbudowany interfejs zarządzający IPMI / BMC, API Redfish lub fizycznie podczas POST wchodząc w ustawienia BIOS Setup i wgrywając certyfikaty jako pliki .auth / .cer (out-of-band management). On hardware like Supermicro, certificates are usually uploaded manually via the built-in IPMI / BMC management interface, Redfish API, or physically during POST by entering the BIOS Setup and uploading certificates as .auth / .cer files (out-of-band management).

D. Środowisko wirtualizacyjne (Proxmox VE)

D. Virtualization environment (Proxmox VE)

• Zanim użyjesz skryptu na maszynie wirtualnej z Windows, host Proxmox musi posiadać najnowszy pakiet firmware EDK2 wspierający klucze z 2023 r. Uruchom w konsoli hosta: Before using the script on a Windows VM, the Proxmox host must have the latest EDK2 firmware package supporting the 2023 keys. Run on the host console: apt update && apt install pve-edk2-firmware Upewnij się, że posiadasz co najmniej wersję 4.2025.05-2. Make sure you have at least version 4.2025.05-2.
• Krytyczny Alert w Proxmox: Critical Alert in Proxmox: Maszyny wirtualne ze starym dyskiem EFI będą logować w systemie Proxmox ostrzeżenie o braku flagi ms-cert=2023k. Zablokuje to też Windows Update wewnątrz VM. Virtual machines with old EFI disks will log a warning in the Proxmox system about a missing ms-cert=2023k flag. This will also block Windows Update inside the VM.
  WARN: EFI disk without 'ms-cert=2023k' option, suggesting that not all UEFI 2023 certificates from Microsoft are enrolled yet. The UEFI 2011 certificates expire in June 2026! The new certificates are required for secure boot update for Windows and common Linux distributions.
• Aby to naprawić (wgrać certyfikaty z poziomu hiperwizora do NVRAM wirtualki), przy wyłączonej maszynie wirtualnej wykonaj: To fix this (enroll certificates from the hypervisor level into the VM's NVRAM), with the virtual machine shut down, do:
  1. W GUI: Wybierz opcje sprzętowe VM (Hardware -> EFI Disk), kliknij Disk Action -> Enroll Updated Certificates. In GUI: Select VM hardware options (Hardware -> EFI Disk), click Disk Action -> Enroll Updated Certificates.
  2. Lub w CLI: qm enroll-efi-keys ID_MASZYNY (np. qm enroll-efi-keys 102). Or in CLI: qm enroll-efi-keys VM_ID (e.g. qm enroll-efi-keys 102).

6. Architektura i mechanizm działania Secure Boot (Wyjaśnienie szczegółowe)

6. Secure Boot Architecture and Mechanism (Detailed Explanation)

Poniżej znajduje się szczegółowy opis mechanizmu Secure Boot oraz procesu, w jaki Microsoft aktualizuje certyfikaty w pamięci UEFI, oparty na zmianach wprowadzonych w 2023 roku w związku z wygasaniem starych kluczy z 2011 r. (których ważność kończy się w 2026 r.).

Below is a detailed description of the Secure Boot mechanism and the process by which Microsoft updates certificates in UEFI memory, based on changes introduced in 2023 due to the expiration of old 2011 keys (which expire in 2026).

6.1. Architektura Certyfikatów (Co znajduje się w NVRAM UEFI?)

6.1. Certificate Architecture (What is in UEFI NVRAM?)

[ PAMIĘĆ BIOS / NVRAM ]
  ├── PK (Platform Key) ──> Zarządza KEK
  └── KEK (Key Exchange Key) ──> Zarządza db / dbx
        ├── db (Dozwolone):    MS UEFI CA 2023 / Windows Production PCA 2011
        └── dbx (Zablokowane): Lista skasowanych / dziurawych (np. BlackLotus)

[ BIOS / NVRAM MEMORY ]
  ├── PK (Platform Key) ──> Manages KEK
  └── KEK (Key Exchange Key) ──> Manages db / dbx
        ├── db (Authorized): MS UEFI CA 2023 / Windows Production PCA 2011
        └── dbx (Forbidden): List of revoked / vulnerable hashes (e.g. BlackLotus)

• PK (Platform Key): Korzeń zaufania należący do producenta sprzętu (OEM). Jego głównym zadaniem jest kontrolowanie dostępu do klucza wymiany (KEK).
• KEK (Key Exchange Key): Klucze wymiany. Zazwyczaj zawierają klucz producenta (OEM) oraz klucz Microsoftu. KEK służy do autoryzacji modyfikacji w bazach db i dbx.
• db (Signature Database): Baza dozwolonych sygnatur (biała lista). Zawiera certyfikaty i skróty (hashe) plików binarnych (np. .efi), które mają prawo się uruchomić. To tutaj trafia nowy certyfikat Microsoft Corporation UEFI CA 2023.
• dbx (Forbidden Signatures Database): Baza odrzuconych sygnatur (czarna lista). Zawiera skróty i certyfikaty zablokowanych, podatnych na ataki bootloaderów (np. związane z luką BlackLotus). Plik obecny w tej bazie zostaje natychmiast zablokowany.

• PK (Platform Key): The root of trust belonging to the hardware manufacturer (OEM). Its main purpose is to control access to the Key Exchange Key (KEK).
• KEK (Key Exchange Key): Usually contains the OEM key and the Microsoft key. The KEK is used to authorize modifications in the db and dbx databases.
• db (Signature Database): Authorized signatures database (whitelist). It contains certificates and hashes of binaries (e.g., .efi) that are allowed to run. The new Microsoft Corporation UEFI CA 2023 certificate is placed here.
• dbx (Forbidden Signatures Database): Forbidden signatures database (blacklist). It contains hashes and certificates of blocked, vulnerable bootloaders (e.g., related to the BlackLotus vulnerability). Files present in this database are immediately blocked from running.

6.2. Proces Bootowania i weryfikacja plików

6.2. Boot Process and file verification

[Boot] ──> UEFI ładuje Boot Manager (np. bootmgfw.efi)
             │
             ├── Krok 1: Czy plik ma prawidłowy podpis cyfrowy?
             │     ├── NIE ──> [HALT] Błąd Secure Boot
             │     └── TAK ──> Przejdź do Krok 2
             │
             ├── Krok 2: Czy certyfikat podpisu pochodzi z bazy "db" (np. nowy CA 2023)?
             │     ├── NIE ──> [HALT] Nieautoryzowany system
             │     └── TAK ──> Przejdź do Krok 3
             │
             └── Krok 3: Sprawdzenie czarnej listy "dbx"
                   ├── Czy hash pliku lub certyfikat jest w "dbx"?
                   │     ├── TAK ──> [HALT] Plik zablokowany (unieważniony)
                   │     └── NIE ──> [SUCCESS] Windows Boot Manager zostaje uruchomiony!

[Boot] ──> UEFI loads Boot Manager (e.g., bootmgfw.efi)
             │
             ├── Step 1: Does the file have a valid digital signature?
             │     ├── NO  ──> [HALT] Secure Boot Error
             │     └── YES ──> Proceed to Step 2
             │
             ├── Step 2: Is the signature certificate from "db" database (e.g. CA 2023)?
             │     ├── NO  ──> [HALT] Unauthorized system
             │     └── YES ──> Proceed to Step 3
             │
             └── Step 3: Check "dbx" blacklist
                   ├── Is the file hash or certificate in "dbx"?
                   │     ├── YES ──> [HALT] File blocked (revoked)
                   │     └── NO  ──> [SUCCESS] Windows Boot Manager is launched!

1. Inicjalizacja: UEFI odczytuje bazy db i dbx ze zmiennych środowiskowych.
2. Lokalizacja: UEFI szuka Menedżera Rozruchu (np. bootmgfw.efi na partycji systemowej).
3. Sprawdzenie dbx (Czarna lista): Obliczany jest hash pliku. Jeśli hash lub certyfikat podpisu znajduje się w bazie dbx, rozruch jest natychmiast przerywany.
4. Sprawdzenie db (Biała lista): UEFI sprawdza cyfrowy podpis pliku z wykorzystaniem bazy db. Jeśli plik podpisany jest poprawnym certyfikatem (np. nowym MS 2023), zostaje załadowany do pamięci.
5. Łańcuch zaufania (Chain of Trust): bootmgfw.efi następnie ładuje winload.efi, weryfikując jego podpis, a ten z kolei weryfikuje jądro systemu (ntoskrnl.exe) i kluczowe sterowniki systemowe.

1. Initialization: UEFI reads the db and dbx databases from environmental variables.
2. Location: UEFI searches for the Boot Manager (e.g., bootmgfw.efi on the system partition).
3. Check in dbx (Blacklist): The file's hash is calculated. If the hash or signature certificate is found in the dbx database, the boot process is immediately halted.
4. Check in db (Whitelist): UEFI verifies the file's digital signature against the db database. If signed by a valid certificate (e.g., new MS 2023), it is loaded into memory.
5. Chain of Trust: bootmgfw.efi then loads and verifies winload.efi, which in turn verifies the system kernel (ntoskrnl.exe) and critical system drivers.

6.3. Jak Windows aktualizuje bezpieczne bazy UEFI?

6.3. How Windows updates secure UEFI databases?

[ PROCES AKTUALIZACJI (Windows Update) ]
Dostarczenie łatki ──> Windows OS ──> Wywołanie API UEFI (SetVariable)
                                                │
                                    WERYFIKACJA SPRZĘTOWA (Klucz KEK)
                                    ├── Podpis niepoprawny 
                                    │     └──> [ODRZUCENIE] Autonomiczna decyzja BIOS
                                    │
                                    └── Podpis poprawny 
                                          └──> [ZAPIS] Dodanie certyfikatów do NVRAM

[ UPDATE PROCESS (Windows Update) ]
Update Delivery ──> Windows OS ──> UEFI API Call (SetVariable)
                                           │
                                 HARDWARE VERIFICATION (KEK Key)
                                 ├── Invalid signature 
                                 │     └──> [REJECTED] Autonomous BIOS decision
                                 │
                                 └── Valid signature 
                                       └──> [COMMIT] Certificates written to NVRAM

Bezpośredni zapis z działającego systemu operacyjnego (nawet z uprawnieniami administratora) do przestrzeni NVRAM BIOS/UEFI jest sprzętowo zablokowany. Microsoft aktualizuje bazy używając zaufanego, odroczonego procesu z wykorzystaniem mechanizmu UEFI Runtime Services:

Direct writing from a running OS (even with admin privileges) to the BIOS/UEFI NVRAM space is blocked on the hardware level. Microsoft updates the databases using a trusted, deferred process via the UEFI Runtime Services mechanism:

• Dostarczenie łatki (Windows Update): Windows Update pobiera pakiet z nowymi certyfikatami, zabezpieczony cyfrowym podpisem z użyciem klucza Microsoft KEK.
• Przygotowanie (SetVariable API): Windows wywołuje interfejs programistyczny API (SetFirmwareEnvironmentVariableEx) w celu umieszczenia ładunku aktualizacji w tzw. Zmiennych Uwierzytelnionych EFI (Authenticated Variables).
• Wymagany Restart: Ponieważ pełny, fizyczny dostęp do zapisu w pamięci NVRAM jest możliwy tylko na bardzo wczesnym etapie rozruchu, Windows wymaga zrestartowania komputera.
• Weryfikacja sprzętowa (KEK): Podczas ponownego uruchamiania, zanim system operacyjny zostanie załadowany, firmware UEFI wykrywa oczekującą aktualizację. UEFI sprawdza sygnaturę kryptograficzną dostarczonego ładunku za pomocą publicznego klucza KEK zapisanego uprzednio na płycie głównej. Odrzucenie w przypadku niepoprawnego podpisu to autonomiczna decyzja sprzętowego BIOSu/UEFI, całkowicie niezależna od woli użytkownika czy systemu operacyjnego (Windows).
• Zapis (NVRAM): Jeśli walidacja za pomocą KEK kończy się sukcesem, firmware UEFI fizycznie dopisuje nowy certyfikat (MS 2023) do bazy db (i odpowiednie skróty do dbx) w trwałej pamięci flash NVRAM. Zmienne tymczasowe są czyszczone, po czym kontynuowany jest normalny proces bootowania Windows.

• Delivery (Windows Update): Windows Update downloads an update package containing the new certificates, secured with a digital signature using the Microsoft KEK.
• Staging (SetVariable API): Windows calls an API (SetFirmwareEnvironmentVariableEx) to place the update payload into Authenticated EFI Variables.
• Reboot Required: Because full, physical write access to NVRAM is only available during the very early boot phase, Windows requires a system restart.
• Hardware Verification (KEK): During restart, before the operating system is loaded, the UEFI firmware detects the pending update. UEFI validates the payload's cryptographic signature using the public KEK stored previously on the motherboard. Rejection in case of an invalid signature is an autonomous decision of the hardware BIOS/UEFI, completely independent of the user's will or the operating system (Windows).
• Commit to NVRAM: If KEK validation is successful, the UEFI firmware physically writes the new certificate (MS 2023) to the db database (and appropriate hashes to dbx) in the persistent NVRAM flash memory. Temporary variables are cleared, and the normal Windows boot process continues.