Se mistä Bitlocker "pillastuu" ja mistä ei, riippuu siitä mitä TPM:n PCR-rekistereitä Bitlocker on määritelty käyttämään.
Saadaksesi sen selville, avaa Windowsin komentotulkki järjestelmänvalvojana, ja komenna:
Koodi:
manage-bde -protectors -get c:
Oletusarvona Bitlocker käyttää PCR-rekistereitä 0, 2, 4, 7 (vain jos kone tukee Secure Boottia) ja 11:
- PCR 0:n arvo muodostuu koneen firmiksen tarkisteista: jos koneeseen tehdään BIOS-päivitys laittamatta Bitlockeria ensin tauolle, pääset syöttämään palautusavainta.
- PCR 2:n arvo on summattu lisäkorttien kuten näytönohjaimen firmiksestä: jos näitä firmiksiä päivitetään tai esim. näytönohjain vaihdetaan erimalliseen laittamatta ensin Bitlockeria tauolle, joutuu seuraavassa bootissa syöttämään Bitlocker-palautusavaimen.
- PCR 4:n arvo muodostuu käytetyn bootloaderin/loaderien tarkisteista: jos aikaisemmin boottasit suoraan Windowsiin (bootmgfw.efi) ja siirryt tekemään sen GRUBin valikon kautta, tai päinvastoin, joudut seuraavassa bootissa syöttämään Bitlocker-palautusavaimen. ellet ennen muutoksen tekemistä laita Bitlockeria tauolle.
- PCR 7: Secure Boot-muuttujat (PK, KEK, DB, dbx, ja tieto onko Secure Boot ylipäätään päällä vai ei).
- PCR 11:n arvo muodostetaan Bitlockerin omista asetuksista, joten se ei yleensä pääse muuttumaan muuten kuin Bitlockerin hallintatyökalujen käytön kautta, ja ne pitävät automaattisesti huolen PCR 11:n uuden arvon rekisteröimisestä.
Jos Bitlocker on otettu käyttöön kustomoiduilla parametreilla (esim. koska AD:n kautta on pakotettu firman "kovennettu" tietoturvapolitiikka), Bitlocker voidaan määritellä käyttämään muitakin PCR-rekistereitä:
- PCR 1: UEFI-firmiksen data. Muutokset vaikeasti ennakoitavissa, joten tämän käyttöä Bitlockerin kanssa ei suositella.
- PCR 3: UEFI-muuttujat (paitsi Secure Boot), käytännössä BIOS-asetukset: tätä käytettäessä mikä tahansa BIOS-asetuksien muuttaminen aiheuttaa Bitlocker-palautusavaimen syöttötarpeen.
- PCR 5: GPT-osiotaulukko = osiointimuutokset aiheuttavat Bitlocker-palautusavaimen syöttötarpeen.
- PCR 6: laitevalmistajakohtainen, tämän käyttö Bitlockerin kanssa saattaa tuoda vaikeuksia suspend- ja hibernate-virransäästötilojen käytön kanssa (= Windows boottaa vain suoraan "kylmäkäynnistyksestä", ja jumittuu jos se suspendataan/hibernoidaan)
Ja Bitlockerin laittaminen tauolle tarkoittaa siis esim. järjestelmänvalvojan PowerShell-komentoa:
Koodi:
Suspend-BitLocker -MountPoint "C:" -RebootCount 1
Tauko kestää RebootCount:in määrittelemän määrän Windowsin boottikertoja. Jos RebootCountiksi laittaa nollan, tauko on päällä kunnes se nimenomaisesti poistetaan vastaavalla "Resume-BitLocker" komennolla.
Kun tauko päättyy, Windows tallettaa Bitlocker-salausavaimen TPM:ään uudestaan käyttäen sen hetkisiä PCR-rekisterien arvoja, eli tällä päästään yli näytönohjaimen (tai muun UEFI-firmiksiä sisältävän komponentin) vaihdosta tai muusta PCR-rekistereihin vaikuttavasta muutoksesta ilman Bitlocker-palautusavaimen syöttötarvetta.
Tämä ei siis varsinaisesti poista salausta, vaan varmistaa että Bitlockerin salausavain on Windowsin saatavissa ilman TPM-suojausta, joten TPM:n PCR-rekisterien muuttuminen ei estä koneen boottia. Tarkoittaa toki myös sitä, että salausavain on suojaamattomana saatavilla, jos joku pahantekijä saa koneen fyysisesti käsiinsä tauon aikana.
Boottijärjestyksen muutos tulee kysymykseen lähinnä silloin jos Windowsin versio päivittyy: esim. jos Windows 11 päivittyy 23H2-versiosta 24H2-versioon. Tällöin Windows yleensä boottaa useamman kerran, joten se "avuliaasti" varmistaa itselleen paikan boottijärjestyksen kärjessä jotta päivityksen vaatimat bootit saadaan läpi automaattisesti. Vastaavasti jos GRUB päivittyy uuteen versioon, sen päivitysprosessi saattaa kirjoittaa OpenSUSEn UEFI-boottimuuttujan uudestaan ja asettaa sen boottijärjestyksessä ensimmäiseksi. Jokin aika sitten tuli kasa GRUB-päivityksiä liittyen Black Lotus- ja BootHole-haavoittuvuuksien paikkaukseen; havainnot OpenSUSEn kiilaamisesta boottijärjestyksen kärkeen saattaisi johtua näistä.
Toinen mahdollinen tapaus on jos koneeseen lisätään/poistetaan levyjä niin että Windows-systeemilevyn järjestysnumero UEFI-firmistasolla muuttuu. Tätä numerointia ei oikein pääse näkemään kuin UEFI-shelliä käyttämällä, joten tämän ennakointi on vähän hankalaa.