Bitlocker in combinatie met TMP vraag

[Aurelium]

Tweakers, ik heb een vraag over bitlocker in combinatie met TPM waar ik na veel googlen nog steeds niet achter ben gekomen. Zoals bekend stelt de combinatie van bitlocker en TPM de gebruiker in staat de laptop veilig op te starten zonder enige invoer van een password. Verwijderen van de schijf of aanpassingen in de bootvolgorde zorgen er direct voor dat enkel nog gestart kan worden met de 48 karakters lange recovery key. De opstartsequentie wordt namelijk gehashed en alleen met die valide hash en in combinatie met de juiste TMP chip kan de schijf ontgrendeld worden.

Nu mijn vraag: ik heb een pc waarbij de BIOS ingesteld staat om eerst van USB te starten en daarna pas van de interne schijf (bitlocker beveiligd). Als ik nu een externe schijf met windows to go eraan hang dan wordt netjes vanaf die externe schijf geboot. Zet ik de pc daarna uit en weer aan (zonder de externe harde schijf) dan wordt om de recovery key gevraagd. Waar treedt nu precies een verandering op dat de hash niet meer valide is? Mijn aanname was dat er juist niets wijzigt tijdens het starten vanaf de externe schijf. Een zoektocht op internet levert op dat de recovery key ook gevraagd wordt wanneer je eenmalig vanaf een liveCD boot (ook hier natuurlijk geldt dat die dan primair in de bootvolgorde ingesteld is), maar ook hiervan snap ik niet hoe dat werkt.

Hopelijk kunnen jullie me helpen!
(achtergrond van de vraag is het creëren van een dynamische dual boot setup dmv externe schijf waarbij de interne schijf beveiligd blijft)

[Verwijderd]

Volgens mij is dat nou juist waarom ze een TPM in het leven geroepen hebben. Je kunt eens beginnen met de TPM niet door Windows (welke Windows?) te laten beheren maar er zelf een sterk wachtwoord in te voeren.

[Aurelium]

Verwijderd schreef op donderdag 2 februari 2017 @ 17:29:
Volgens mij is dat nou juist waarom ze een TPM in het leven geroepen hebben. Je kunt eens beginnen met de TPM niet door Windows (welke Windows?) te laten beheren maar er zelf een sterk wachtwoord in te voeren.

Klopt, ik snap de meerwaarde van de TPM, maar ik zou verwachten dat je als je wil voorkomen dat er vanaf iets anders geboot wordt je de interne schijf als primaire boot medium zet en dan bitlocker activeert. Wil je dan van een alternatief medium booten dan wijzig je de bios en snap ik dat bitlocker ingrijpt.

[Verwijderd]

Dat is het Secure-Boot verhaal, dat sinds een jaar helemaal niet meer Secure is (gelekte sleutel). En een wachtwoord in het BIOS is door een simpele handeling als batterij even eruit halen ook omzeilt.

[Aurelium]

Secureboot staat trouwens niet aan. Windows 7 wordt via de interne schijf gestart en is geencrypt, op de externe schijf staat windows 10.

Maar ik heb het antwoord op mn vraag nog niet iemand die me kan toelichten hoe het technisch in elkaar steekt?

[PilatuS]

De TPM checkt ook of er in de BIOS iets veranderd, zoals de bootvolgorde. Dit kan namelijk betekenen dat iemand geprobeerd heeft de boel te kraken. Daarom triggert de TPM de invoer van de code. Een BIOS update bijvoorbeeld doet precies hetzelfde, ook dan moet de code ingevoerd worden. Zolang er niets veranderd word er nooit om de code gevraagt. Worden er dingen in de boot aangepast word die gezien als een mogelijke inbraakpoging.

Je kan trouwens ook prima Bitlocker gebruiken zonder TPM als je wil en dan heb je dit probleem niet. De TPM zorgt voor een stuk extra veiligheid, maar ik dit geval is het juist onhandig.

Dus zodra er bepaalde dingen veranderen, wat er best een hoop zijn, ziet de TPM dit en word er om de 48 karakters gevraagd. Ik had dit laatst zelf ook na een BIOS update.

[ Voor 12% gewijzigd door PilatuS op 04-02-2017 17:02 ]

[Aurelium]

Ik snap wat je zegt, maar mijn punt is juist dat ondanks dat ik niks aan de bootvolgorde verander (usb stond al als eerste bootkandidaat bij het activeren van bitlocker) de beveiliging toch getriggerd wordt als er een keer gestart wordt vanaf een USB device. Ik zie niet in hoe dit iets wijzigt in de BIOS of aan de niet versleutelde partitie van de interne schijf waarop de windows boot manager draait.

[Trommelrem]

Long shot, maar:

Heb je fast boot uitgeschakeld op beide Windows installaties?

[PilatuS]

Aurelium schreef op zaterdag 4 februari 2017 @ 17:08:
Ik snap wat je zegt, maar mijn punt is juist dat ondanks dat ik niks aan de bootvolgorde verander (usb stond al als eerste bootkandidaat bij het activeren van bitlocker) de beveiliging toch getriggerd wordt als er een keer gestart wordt vanaf een USB device. Ik zie niet in hoe dit iets wijzigt in de BIOS of aan de niet versleutelde partitie van de interne schijf waarop de windows boot manager draait.

De TPM ziet als er wat anders is dan normaal. Juist booten vanaf USB is een duidelijke trigger die aan kan geven dat iemand er in wil komen. De TPM doet wat ie moet doen.

[Trommelrem]

PilatuS schreef op zaterdag 4 februari 2017 @ 17:16:
[...]


De TPM ziet als er wat anders is dan normaal. Juist booten vanaf USB is een duidelijke trigger die aan kan geven dat iemand er in wil komen. De TPM doet wat ie moet doen.

Niet perse. Als je de situatie terugbrengt naar de oude situatie, dan moet de trigger in principe worden teruggenomen. Dat stond vroeger ook in de melding die je krijgt.

[Aurelium]

Trommelrem schreef op zaterdag 4 februari 2017 @ 17:17:
[...]

Niet perse. Als je de situatie terugbrengt naar de oude situatie, dan moet de trigger in principe worden teruggenomen. Dat stond vroeger ook in de melding die je krijgt.

Het ontkoppelen van de externe schijf brengt de situatie weer terug naar het oude. Echter niet volledig, want bij het herstarten van het systeem wordt gevraagd om de recovery key.

PilatuS schreef op zaterdag 4 februari 2017 @ 17:16:
[...]


De TPM ziet als er wat anders is dan normaal. Juist booten vanaf USB is een duidelijke trigger die aan kan geven dat iemand er in wil komen. De TPM doet wat ie moet doen.

Het gaat me er niet om of dat gewenst of ongewenst gedrag is van de TMP. Ik wil begrijpen hoe dit werkt

[ Voor 20% gewijzigd door Aurelium op 04-02-2017 17:20 ]

[PilatuS]

Trommelrem schreef op zaterdag 4 februari 2017 @ 17:17:
[...]

Niet perse. Als je de situatie terugbrengt naar de oude situatie, dan moet de trigger in principe worden teruggenomen. Dat stond vroeger ook in de melding die je krijgt.

Ik zou juist wel willen dat de TPM dit opmerkt, ook al gaat alles weer terug naar hoe het was. Het is de taak van de TPM om aan te geven dat er iets met het systeem gedaan is. Dus booten vanaf een stick, een virus wat de loopt te prutsen met de bootsector of wat dan ook.

Aurelium schreef op zaterdag 4 februari 2017 @ 17:20:
[...]
Het gaat me er niet om of dat gewenst of ongewenst gedrag is van de TMP. Ik wil begrijpen hoe dit werkt

De TPM kijkt naar alles wat met booten te maken heeft en triggert als er ergens iets veranderd is. Ook als er iets veranderd is wat weer terug gaat naar hoe het was is dat toch een verandering. Hoe dat precies werkt zal vast een heel uitgebreid technisch verhaal zijn. Mogelijk kan je meer info vinden over hoe een TPM precies werkt.

[ Voor 33% gewijzigd door PilatuS op 04-02-2017 17:29 ]

[Trommelrem]

Aurelium schreef op zaterdag 4 februari 2017 @ 17:20:
[...]


Het ontkoppelen van de externe schijf brengt de situatie weer terug naar het oude. Echter niet volledig, want bij het herstarten van het systeem wordt gevraagd om de recovery key. Het gaat me er niet om dat gewenst of ongewenst gedrag is van de TMP. Ik wil begrijpen hoe dit werkt

Kan een firmwarebug zijn. Zo heb ik een keer een moederbord gezien die bij elke reboot een ander (random) MAC adres gaf aan de onboard NIC. Logischerwijs was de TPM daardoor nutteloos. De fabrikant heeft op ons verzoek een firmware update uitgebracht waarmee het probleem werd "opgelost" door altijd MAC 00:00:00:00:00:00 toe te wijzen.

Wat is je TPM versie? Mijn ervaring is dat bij 1.2 je wel gewoon terug kunt naar de oude situatie. Met 2.0 nog niet geprobeerd.

[ Voor 8% gewijzigd door Trommelrem op 04-02-2017 17:23 ]

[Aurelium]

Trommelrem schreef op zaterdag 4 februari 2017 @ 17:22:
[...]

Kan een firmwarebug zijn. Zo heb ik een keer een moederbord gezien die bij elke reboot een ander (random) MAC adres gaf aan de onboard NIC. Logischerwijs was de TPM daardoor nutteloos. De fabrikant heeft op ons verzoek een firmware update uitgebracht waarmee het probleem werd "opgelost" door altijd MAC 00:00:00:00:00:00 toe te wijzen.

Wat is je TPM versie? Mijn ervaring is dat bij 1.2 je wel gewoon terug kunt naar de oude situatie. Met 2.0 nog niet geprobeerd.

TPM versie 1.2 wat ik zo snel kan vinden via google (Lenovo P50)

[Aurelium]

Ok, mijn excuses. Ik heb toch nog maar een keer de proef op de som genomen en de pc opgestart vanaf de externe schijf. Na afsluiten en uitnemen van de schijf wordt windows 7 nu wel normaal gestart.

Ik weet niet waarom het de eerste keer mis is gegaan (toen kreeg ik na installatie van windows 10 to go de recovery melding na uitname van de schijf), maar nu kan ik wel probleemloos starten vanaf de externe schijf zonder dat de bitlocker chain of trust wordt verbroken.