[English]Bitlocker, das "unbekannte Wesen" möchte ich mal den Blog-Beitrag umschreiben. Es geht um die Frage, wo die Windows-Funktion Bitlocker eigentlich den Recovery-Key, der immer mal wieder gebraucht wird, überhaupt speichert. Bevor jemand mit "in deinem Microsoft-Konto" um die Ecke kommt: So einfach ist es nicht immer. Blog-Leser Markus, der als Administrator unterwegs ist, hat mich auf eine Beobachtung der besonderen Art in diesem Zusammenhang hingewiesen. Zeit, mal wieder einen Blick auf Bitlocker zu werfen.
Anzeige
Meine Bitlocker-Hinweise
Bitlocker ist die von Microsoft in Windows mitgelieferte Funktion zur Verschlüsselung von Datenträgern. Die Verschlüsselungslösung ist sowohl in Windows 10 als auch in Windows 11 (wie auch in früheren Windows-Versionen) integriert – und wird u.U. auch auf Home-Systemen aktiviert. Zum Problem wird dies, wenn Windows 10 Home (und auch Windows 11) bei Konsumenten die Datenträger automatisch verschlüsseln und plötzlich nach einem BIOS- oder Windows-Update einen Wiederherstellungsschlüssel verlangen, weil sie mit Bitlocker verschlüsselt sind. Ich hatte das Thema im Blog-Beitrag Windows 10/11 Home-Edition und die OEM Bitlocker-Falle aufgegriffen.
Die betreffenden Bitlocker-Wiederherstellungsschlüssel lassen sich in Microsoft-Konten oder im TPM speichern. Die Funktion ist aber immer wieder für Ärger gut, wenn Windows einen Bitlocker-Wiederherstellungsschlüssel will, der Nutzer diesen aber nicht kennt. Oder die Maschine startet nicht mehr und die Leute kommen nicht mehr an die Daten der Festplatte heran, weil diese verschlüsselt sind.
Aber wo ist der Bitlocker Recovery-Key?
Blog-Leser Markus hat mich die Tage per E-Mail kontaktiert, weil er eine besondere Beobachtung im Zusammenhang mit Bitlocker und dem gespeicherten Recovery-Key gemacht hat. Markus ist bei seiner Arbeit etwas besonderes aufgefallen, als er das BIOS seines Rechners aktualisiert hat.
- Auf dem Rechner (war ein HP, ist aber völlig egal) wurde aus dem BIOS eine Aktualisierung gestartet
- Im Anschluss wollte Bitlocker beim Systemstart das Passwort
- Dann wollte Bitlocker auch noch den Recovery Key
Das ist soweit nicht nicht wirklich verwunderlich, so wird das System per Bitlocker abgesichert. Für Markus im ersten Augenblick auch kein Problem, denn der Bitlocker Recovery-Key ist ja im Microsoft Konto gespeichert, so die Annahme. Aber beim Nachschauen mit einem Notebook fand sich im betreffenden Microsoft Konto der betroffenen Maschine kein Bitlocker Recovery-Key. Das ist dann die Stelle, wo viele Nutzer die Nerven verlieren, weil die Daten bis in alle Unendlichkeit verschlüsselt bleiben.
Anzeige
Markus schrieb mir dazu: "Gut nachdem ich ja nicht ganz unwissend bin, habe ich mich für den schnellsten Weg des BIOS-Rollback entschieden. Das hat auch wunderbar funktioniert." Nach diesem Rollback kam er natürlich ohne Eingabe des Recovery Key in Windows. Im nächsten Schritt begann er dann mit der Feldforschung zur Frage, wo der Recovery Key durch Bitlocker denn nun gespeichert wurde.
Wenn die Feuerwehr deinen Bitlocker-Key hat
Dazu schrieb er mir: "Nach ca. 2 Stunden Recherche habe ich dann herausgefunden, dass der Bitlocker Recovery-Key nicht in meinem persönlichem Microsoft Konto befindet wo ich ihn eigentlich vermutet hätte, auch nicht im Microsoft Konto der Universität, wo er als Administrator aktiv ist. Den Bitlocker Recovery-Key fand er im Microsoft Konto seines Zugangs für die Feuerwehr.
Azure Entra ID gewinnt?
Markus hat das Ganze nicht weiter verfolgt, schrieb mir aber, dass eines sicher sei: Azure AD (mittlerweile Entra ID) gewinnt gegenüber dem Konto mit dem man sich am Rechner anmeldet (damit hatte Markus eigentlich nicht gerechnet). So ist zu erklären, dass der Recovery-Key im Microsoft Konto seines Zugangs für die Feuerwehr landete.
Was Markus jetzt allerdings brennend interessieren würde, ist die Antwort auf die Frage: "Welche Azure AD-Zugehörigkeit gewinnt, wenn ein Benutzer beispielsweise ein OneDrive mit einem Azure AD-Konto einer anderen Organisation verwendet?" Der Blog-Leser hat dann ein Szenario durchgesponnen: "Ich bin eine böse Organisation und möchte über obigen Ansatz den Recovery Key zu mir holen. Da hätte man dann ja glatt RaaS (Ransomware as a Service) wenn man Bitlocker dazu bringt den Key in der (böswilligen Azure AD (des Angreifers) zu speichern – in seinem Fall landete der Key ja im Konto der Feuerwehr). Was Markus noch nicht versucht hat, ist ein Test, was passiert, wenn man in einer On-Premises Active Directory-Umgebung (AD Umgebung) Onedrive von einer Organisation, die Azure AD hat (wie z.B. im obigem Fall die Feuerwehr), einrichtet.
Markus meint: "Wenn da der Recovery-Key auch abwandert, wäre das ein schon krass. Mangels Zeit kann und werde ich mich allerdings damit nicht weiter befassen. Gestaunt habe ich jedenfalls schon sehr. Keine Ahnung ob ich da etwas übersehen oder nicht bedacht habe, vielleicht habe ich sogar etwas nicht verstanden :). Für normale Benutzer mit Sicherheit nicht durchschaubar würde ich behaupten." An dieser Stelle die Frage an die Leserschaft: Hat jemand ähnliche Beobachtungen gemacht bzw. kann er die Beobachtung von Markus bestätigen?
Ergänzungen: Auf Facebook sind mir zwei Rückmeldungen untergekommen, die ich hier einstelle. Thomas schrieb zur Frage, wie man ein Konto zum Speichern des Schlüssels vorgeben kann "Das haben wir deshalb mit Sophos Central Device Encryption gelöst.". Und Andreas meinte "Das Konfiguriert man. AD, Entra ID oder beides. Gibt's ja ne dicke fette GPO / Intune-Profil dafür. Und wenn man sein Gerät ins Intune von jemandem enrollt dann tja…. ist der der Admin."
Ähnliche Artikel:
Windows 10/11 Home-Edition und die OEM Bitlocker-Falle
Bitlocker über TPM binnen 42 Sekunden mit Raspberry Pi Pico ermittelt
Windows 10/11: Microsoft veröffentlicht Fix für OOBE-Bitlocker-Ausfall-Bug
Anzeige
Vor einem UEFI-Update hält man Bitlocker an, oder besorgt sich vorher den Recovery-Key: https://learn.microsoft.com/en-us/troubleshoot/windows-client/windows-security/suspend-bitlocker-protection-non-microsoft-updates
Schlimmer als solche geplanten UEFI-Updates sind doch die UEFI-Updates, die über Windows-Updates automatisch aufgespielt werden und man davon nichts mitbekommt, sieht man meistens bei Laptops. Dann kann es passieren, dass die Pin nicht mehr funktioniert (TPM Reset) und falls Bitlocker aktiv war (viele wissen das ja nicht mal), man zur Eingabe des Recovery-Keys aufgefordert wird. Wehe dem, der nicht an seinen Recovery-Key kommt.
Der erste Absatz im "Klugscheiß-Modus" hilft bei obigem Thema genau was? … ;-)
Updates die via Windows|MS|Optional-Update daher kommen machen in der Regel kein Problem, da diese für die benötigte Anzahl an reboots Bitlocker aussetzen.
Mir geht es hier lediglich um die Frage wo der Rekovery-Key hinkommt, wie und wann!
Wäre ich ein Bösewicht und hätte die Möglichkeit das auszunutzen, dann kann das schon durchaus unlustig werden.
> … da diese für die benötigte Anzahl an reboots Bitlocker aussetzen. <
Ernstgemeint: Das würde ich auch gerne können. Wie geht das? Mit manage-bde.exe, PowerShell, WMI?
In der PS z.b.
Suspend-BitLocker -MountPoint C: -RebootCount 3
Ich klugscheiße noch einen oben drauf.
Wer kein Backup seiner Daten macht, und dazu zähle ich auch und vor allem die Bitlockerschlüssel, der sollte die Finger von der Tastatur lassen oder sich nicht beschweren. Ist es so mühsam, die Schlüssel zumindest auf einem keinen USB Stick zu lagern, der dann an einem sichern Ort liegt?
Das im Artikel genannte Problem der abwandernden Schlüssel in andere Azure Konten ist damit natürlich nicht gelöst. Aber wenn die Schlüssel lokal vorliegen, muss man sie ja nicht bei Microsoft lagern.
Warum ist es für manche so schwer. sich zivilisiert zu einem Thema austauschen? Warum muss man gleich Überlegenheit raus hängen lassen und andere abqualifizieren? So schwer?
Es geht im Artikel um die Rangfolge beim Speichern und dass der Speicherort sehr überraschend sein kann. Und um die Sicherheitsimplikationen. Also: Thema verfehlt.
> Markus meint: "Wenn da der Recovery-Key auch abwandert, … <
Schnellschuss, von (1): "During COVID we have seen a lot of customers who were suddenly working or attending school from home and may have been asked to sign into a work or school account from their personal computer. If that was your experience too, then it's possible your work or school has a copy of your BitLocker recovery key."
Das ist jedenfalls schon einmal ein Beleg, dass Microsoft das Abwandern eines BitLocker Recovery Keys in Kauf nimmt.
(1) support.microsoft.com/en-us/windows/finding-your-bitlocker-recovery-key-in-windows-6b71ad27-0b89-ea08-f143-056f5ab347d6
Das ist ja schön, nur stellt sich doch die Frage warum, kann MS beispielsweise bei der erstinstallation nicht auf bitlocker aufmerksam machen, und den Export oder das abschalten dieser Verschlüsselung gerade bei Home Versionen nicht in das oobe mit aufnehmen. Zumindest könne man die verschlossene Tür als normal Benutzer wieder öffnen, ohne gleich nach einem ungeplanten Windows Update basierenden UEFI Update da zu stehen wie ein depp.
Das hat was von ransomware by Design.
Und Backup ist jetzt nicht der Punkt!
Um das obige Problem des Admins mit Bezug zur Feuerwehr zu verstehen, müsste man wissen, welche M365 Accounts der Gute denn alle einsetzt.
Hat er sich zum Beispiel am OneDrive der Feuerwehr angemeldet und bei der Anmeldung versäumt ein Häkchen zu entfernen, das darauf hinweist, der Rechner können von der Organisation verwaltet werden, hat diese Organisation den Zugriff auf den Rechner über Entra ID und Intune.
Hat die Feuerwehr nun Richtlinien in Entra ID und Intune, die zum Beispiel die Bitlocker Verschlüsselung vorschreiben, damit das Gerät die Compliance Anforderungen der Organisation erfüllt, dann wird es über Intune verschlüsselt und der Key wird im Entra ID abgelegt.
Das ist für Organisationen mit M365 Einsatz eine ganz normale Sicherheitsmaßnahme, die auch dem Zero Trust Ansatz entspricht und unter anderem auch Conditional Access Anforderungen erfüllt, so sie denn aufgesetzt sind in der Organisation.
Hat sich dieser Admin nun mit einem privaten Rechner dort angemeldet, wurde dieser zumindest ein "Entra ID registered Device" wenn nicht gar ein "Entra ID joined Device". Blöd, wenn die Organisation darauf bei BYOD Geräten nicht vorab hinweist.
Das Verhalten ist aber nicht Entra ID schlägt privaten Account, sondern User hat sich bei der Organisation angemeldet, sein Device registriert und damit auch dessen Richtlinie akzeptiert.
Das ist kein Fehlverhalten des M365 System, sondern fehlende Kommunikation, da es ein absolut korrektes Verfahren ist. Nur der Nutzer hat der Verwaltung "seines" Devices eben nicht durch entfernen des Häkchens widersprochen.
Ich hatte eigentlich einen bösen Kommentar bringen wollen: aber wer die Lingo und """LOGIK""" von Microsoft schon so verinnerlicht hat – bei dem ist Hopfen und Malz eh verloren. Um ein tadelloses Mitglied einer Schafherde zu sein…
Nachsatz
Hab vor 2 Monaten den PC einer 75jährigen neu aufsetzen müssen – Win11 hatte nen Update gemacht und danach kam das Ding mit Bitlocker und Co. Kein Reinkommen mehr.
Wohlgemerkt: die gute Dame hatte noch nicht mal ein Login, geschweige denn ***irgendwas*** mit Bitlocker eingerichtet.
Ne wirklich doofe Nutzerin die bestimmt auch nur wo nen Haken übersehen hat.
Oh vielen Dank für diese Einschätzung meiner Person. Sie kennen sich ja aus.
Bestimmt sind Sie ebenso geschickt im Umgang mit der Einrichtung und Nutzung moderner Technik. Den Bitlocker Key konnten Sie ja schon mal nicht wieder herstellen. Na zumindest reichte es für eine Neueinrichtung. Hoffe alle wichtigen Haken wurden gesetzt, oder entfernt.
Oh, ich gebe gaaaanz offen zu, bei Microsoft raus zu sein. Linuxer.
Dann erleuchten Sie mich mal: was hätte ich bei der Dame machen sollen?
Sie hat keinerlei Logins von Microsoft – also nix Onedrive, Microsoft-Konto etc.
Da ist auch keine Organisation, der PC steht bei ihr unterm Dach. Nix Intune, Extra ID etc.
Sie hat bestimmt nicht Bitlocker aktiviert – konnte also auch nicht den Key händisch sichern. Backups…
So – was machen Sie als Profi dann?
Tja, vielleicht hätte man der Dame dann nicht eine Pro Version von Windows installieren sollen, denn dann wäre das Problem gar nicht erst aufgetaucht. Und dass diese Dame kein Windows Pro benötigt, liegt wohl auf der Hand.
Blöde Lösung. Damit die Dame nicht ins Messer rennt, soll sie nochmals Geld ausgeben für ein Lizenz-Upgrade?
Sie haben die Microsoft Logik wirklich völlig verinnerlicht. Für andere Menschen ist das keine akzeptable Logik. Die erwarten, dass Microsoft einfach funktionierende, sichere Software abliefert. Oder ist das zu viel verlangt?
Nochmal: die 75(+?) Dame hat gar nichts.
Sie hat einen All-in-One von HP gekauft/vom Sohn bekommen. Da war wohl Win11 Pro drauf.
Das war's! Mehr hat sie nicht gemacht.
Sie (als Profi) sagen jetzt also, dass die Dame proaktiv a) die Bitlocker Keys hätte sichern sollen b) da sie ja kein AD und Co. braucht auf Win11 Home wechseln sollen (Rückfrage: Version N oder normal?) und – aus dem allerersten Kommentar – c) vor dem Bios Update Bitlocker anhalten sollen.
Merken Sie es langsam oder …?
Die Dame hat wahrscheinlich GAR nichts gemacht. Nicht dem Windows Update zugestimmt, nicht irgendwas mit Bitlocker geklickt, kein M$ Konto – nichts!
Sie kennt das alles absolut gar nicht!
Das ist alles automatisch – bin in ihrem Fall – gesperrtem PC mit verlorenen Daten gegangen.
Also allen die BitLocker nicht trauen kann ich mein DiskCryptor von https://diskcryptor.org/ nur wärmstens ans Herz legen.
Einziger Nachteil, man muss bei jedem boot das Passwort eingeben, die Software benutzt kein TPM oder sonstigen murks, daher geht auch kein reboot in Abwesenheit außer man hat remote KVM Hardware um das Passwort beim booten einzugeben.
Und natürlich muss das Passwort dann auch kryptographisch stark sein, also schwer zu merken und lang. Aber dafür braucht man, um an die Daten zu kommen nur die SSD und das Passwort, alles andere am Rechner kann weg.
Ja, Ja ich weis Eigenlob stinkt aber DiskCryptor ist nun mal genial! ;p
Das ist ja SUPER!
Gleich mal Werbung für das eigene Produkt und dann ist das alles in neudeutsch dokumentiert. Das schreckt doch schon mal 50% ab. Und die, die dann auf GitHub sich das Teil "grabben" lesen den Bildschirm rauf und runter BETA – !!
KLASSE NUMMER!
Da wäre VeraCrypt deutlich empfehlenswerter und nein, habe ich keine Aktien drin!
Nein VeraCrypt taugt für windows 10 nichts die haben einen gravierenden bug seit 2019: https://sourceforge.net/p/veracrypt/discussion/general/thread/f6e7f623d0/?limit=25
den sie immer noch nicht beheben Konten.
tl;dr: Wenn man ein page file hat und verschlüsseltes OS friert das system zufällig ein.
Natürlich ist DC Beta, eine Software mit GAU potential werde ich doch nicht an DAU's verschenken, das mag gemein klingen ist aber IMHO nur vernünftig.
@ T Sommer – verstehe ich. Dauerhaft produktiver Einsatz wäre zu prüfen. Jedoch – vielleicht erwartest Du zu viel? Arbeite doch mit, Übersetzungen machen! Testen? Wann hast Du die letzte freie Software auf Github entwickelt?
@ David – lass Dich nicht demotivieren. Solche Ansätze braucht es. Natürlich bist Du noch nicht so groß wie Veracrypt.
Ein Traum wäre die externe Anbindung von Devices oder Hardwarekriterien, um die Keyphrase zB von anderen (externen) Devices zu holen oder abzuleiten und es von dessen Existenz als ganzer oder 2ter Faktor abhängig zu machen.
Beispiel: Die MAC von IP-Adresse auslesen und Passworteingabe ergänzen. Beispiel: Hole per SSH weiteres Kriterium wie File.txt und ergänze oder ersetze damit den Schlüssel.
Auch wenn es sehr interessant ist, wo der Bitlocker-Key landet (was bei jeder Erst- oder Neueinrichtung dem Nutzer deutlich von Windows mitgeteilt werden sollte):
Ich kann aus eigener leidvoller Erfahrung jedem für die Praxis raten, darauf zu achten, dass der Windows-Rechner automatisch regelmäßige "System-Wiederherstellungspunkte" abspeichert für alle lokalen Festplatten. Also quasi Backups nur vom Windows-System an sich, die bei Wiederherstellung nur das Windows-System überscheiben, nicht die gespeicherten User-Daten.
Mein Firmenrechner im Homeoffice startete nach einem Windows- oder Treiber-Update nicht mehr richtig, und es wurde auch mein Bitlockerkey abgefragt:
Unser IT-Support teilte mir den Key zwar mit, vermutlich aus Azure AD, aber konnte mir ansonsten nicht weiter helfen bei meinem Startproblem. Support-Besuche im Homeoffice gibts ja nicht… Also war Selbsthilfe angesagt.
(Denn der Support riet mir nur noch, den Rechner in der Firma komplett neu installieren zu lassen. Tolle Idee bei Zeitdruck !!)
Allein den Key dutzende Male manuell bei meinen Selbsthilfeversuchen eintippen zu müssen, ist schon Qual genug. Und war zudem gar nicht von Erfolg gekrönt.
Letztlich habe ich es geschafft, mir beim Bootvorgang von einem USB-Stick mit WindowsRE die Recovery options von Windows anzeigen/anbieten zu lassen, unter denen ich dann zum Glück jüngst gespeicherte Wiederherstellungspunkte angezeigt bekam, auf die ich den Rechner zurücksetzen lassen konnte.
Seitdem achte ich stärker darauf, wöchentlich gespeicherte Wiederherstellungspunkte zu haben (was automatischer Standard in unserer Firma ist) und vor kritischen Aktionen (Treiberupdates etc.) selbst so einen Punkt zu speichern.
…Ich weiß, das ist ewas offtopic und auch klugscheißerisch. ;-)
Aber vlt. hilfts dem einen oder anderen, letztlich seinen Rechner wieder schnell lauffähig zu bekommen.
Die Aussage "Die betreffenden Bitlocker-Wiederherstellungsschlüssel lassen sich in Microsoft-Konten oder im TPM speichern" ist falsch.
Der Key im TPM ist KEIN Recovery-Key.
Der Recovery-Key ist dafür da, wenn das TPM defekt ist, sich sperrt, gecleart ist, oder das Mainboard defekt.
Der KeyProtector im TPM kann auch nicht ausgelesen werden.
Der Recovery-Key ist ein zusätzlicher KeyProtector.
Windows Clients, die bestimmte Voraussetzungen (unter anderem TPM) erfüllen,
verschlüsseln die Festplatte automatisch via Bitlocker (und hinterlegt einen KeyProtector im TPM).
Jedoch wird die Verschlüsselung zunächst dauerhaft suspended. D.h. es ist noch kein TPM nötig. In dem Zustand kann man die FEstplatte auch ausbauen und auf die Daten zugreifen.
Erst wenn zum ersten mal ein Microsoft-Account (Consumer-Accounts) am PC Systemweit eingerichtet wird, oder ein Microsoft 365 work & school Account, dann wird automatisch ein Recovery-Key erstellt, dieser wird dann im Account hinterlegt, und dann wird die suspension aufgehoben. Denn es muss der Recovery-Key erst irgendwo extern hinterlegt werden, damit man im Falle des Falles noch Zugriff darauf hat.
Die beschriebenen Fälle im Blog-Post hatten also wohl einen lokalen User account (bitlocker suspended). Beim Einrichten von einem Microsoft 365 school account (z.B. in OneDrive), kommt eine Meldung, wo man auswählen kann, ob der Account nur für die App gespeichert werden soll, oder Systemweit. Die meisten Anwender drücken einfach fertig, womit der Account nicht nur für die App, sondern systemweit hinterlegt wird.
Damit startet dann das Hinterlegen des Recovery-Keys und das Scharfschalten von Bitlocker.
Das ist natürlich nicht suboptimal, dass das ungefragt passiert bei einem work&school account. Zumal die Geräte ja nicht EntraId-joined werden, sondern nur registered. (sofern der Admin ein join für beliebige Geräte unterbunden hat)
Angriffsszenarien die oben angedeutet wurden sind sehr weit hergeholt.
Der Anwender muss schließlich explizit einen 365 Account eines bösartigen TEnants auf seinem Gerät einrichten. Wenn man den Anwender dazu bringt, dann kann man ihn auch zu ganz anderen Sachen bewegen.
Versteht mich nicht falsch: Das Verhalten ist lästig, aber kein Cybersicherheitsrisiko.
Der Anwender hat hingegen ggf. ein Problem, wenn sein M365-account später mal gelöscht wird (Exmatrikulation, Arbeitgeberwechsel) und er später den Recovery-Key braucht.
Wer keine Arbeit hat, macht sich welche – zur Not verwende man einfach Microsoft, das macht immer Arbeit; allein bei den Recherchen, irgendwelche "Eigenarten" des Systems heraus zu bekommen, die in der langatmigen Dokumentation nicht oder nur in der "hintersten Ecke" beschrieben wird.
Gegen Diebstahl eines Notebooks setzen wir einfach auf das UEFI/BIOS-Passwort für selbiges und die Festplatte (Master + User). Das hindert schon die meisten, eine FP überhaupt auslesen geschweige denn wiederverwenden zu können.
Und wer so leichtsinnig ist, den Recovery Key nicht auf einen USB-Stick zu sichern, verdient die ganze unnötige Arbeit auch. (https://support.microsoft.com/en-us/windows/back-up-your-bitlocker-recovery-key-e63607b4-77fb-4ad3-8022-d6dc428fbd0d)
> Gegen Diebstahl eines Notebooks setzen wir einfach auf das UEFI/BIOS-Passwort für selbiges und die Festplatte (Master + User). <
Hat aber Grenzen. Ich erinnere mich schwach, vor Jahren auf Notebooks gestossen zu sein, bei denen die zweite (!) Festplatte nicht durch Firmware-Passwörter gesichert werden konnte und dieser Umstand nur aus dem Manual, nicht aber aus der Mimik der Firmware-Menüs hervorging.
S. z. B. auch (1): "… computers released in 2022 and later support NVMe BIOS passwords, however Dell does not support unlocking NVMe BIOS passwords."
D. h. vor 2022 waren bei DELL NVMe Festplatten nicht geschützt.
(1) dell.com/support/kbdoc/en-us/000132226/dell-system-prompts-for-a-hard-drive-hdd-or-bios-password
Zum Thema Bitlocker-Key und AD. Hier gibt es eine Richtlinie, wo das ganze gespeichert werden darf. Dann kann man u.a. Ziele verbieten oder überhaupt nur AD zulassen. Diese Geräte können dann nicht mehr Mitglied anderer "Stellen" werden. Wobei es auch da immer wieder (neue) Ausnahmen gibt… – die sich dann auch gerne als "Upps, war nicht so geplant" rausstellen.
Was mich bei der Geschichte aber irritiert. War das Gerät nun vollständig unabhängig? Mir erscheint, dies wurde bei der FW registriert und hat von dort Richtlinie gezogen und hat diese Vorgabe (jetzt verschlüsseln und Ziel für den Bitlocker-Key ist FW) übernommen. Aber das hat u.a. auch Mathias bei den Kommentaren nachgefragt.
Bei BYOD Szenarien gab es früher schon den Hinweis, dass es da passieren kann, private Rechner erhalten andere Einstellungen und übermitteln Telemetrie oder eben auch Bitlocker-Key…
Die Idee mit dem Angriff ist durchaus möglich. Aber doch auch aufwendig und wohl eher für gezielte Ziele. Egal wie oder was – ich frage mich, müsste der Key nicht nur einmalig übertragen werden und zwar nur zum Zeitpunkt der ersten Verschlüsselung? Ich kenne dies nämlich nur so.
SSD/HDD bekommt den Befehl verschlüsselt zu werden. Dabei muss immer angeführt werden wo und ob ein Key gespeichert wird. Dabei wird dies einmal übertragen und erst dann startet die Verschlüsselung (Anmerkung: sofern nicht eine Überprüfung angefordert wird).
Ist nun bereits die HDD/SSD verschlüsselt, dann ist nach meinem Wissenstand keine erneute Übertragung der Wiederherstellungsdaten möglich. Bislange Nutzung in der Vergangenheit zeigten bislang dieses Verhalten. Es geht wenn man manuell entschlüsselt und erst dann eine neue Vorgabe zur Verschlüsselung erhält. War bereits verschlüsselt, dann kann gar nicht entschlüsselt werden, solange egal von wo eine Anweisung zur Verschlüsselung daherkommt.
> Die Idee mit dem Angriff ist durchaus möglich. Aber doch auch aufwendig und wohl eher für gezielte Ziele. <
Nicht persönlich gemeint: Auch in einem anderen Kommentar und unter anderen Artikeln lassen sich Kommentatoren mit bagatellisierender Tendenz immer wieder über die Wahrscheinlichkeit und Machbarkeit von Angriffen aus. Ich halte das angesichts der Raffinesse und Komplexität beobachteter Angriffe, deren Funktionsweise selbst nationale Sicherheitsbehörden erst nach Monaten – und dann oft auch nur ansatzweise – erklären können, für nicht statthaft. Die allermeisten ITler – noch mehr natürlich Hobbyisten – sind Zauberlehrlinge, nicht Meister!
Ich speichere den Key immer lokal in KEEPASS , nach jeder Aktualisierung schick ich mir die neue KDBX Datei als Mail
Ich bin nicht mehr up-to-date. Vorsorglich Hinweis auf (1): "If an attacker finds such a database (.kdbx), he can transfer it to himself and use keepass2john (part of John the Ripper) to extract the hash of the master password, which can then be cracked with Hashcat or John the Ripper."
Dass es neben der produktiven Kopie der .kdbx-Datei eine Kopie der Datenbank in Form des Backups (bzw. mehrerer Backups) geben muss , ist wohl unvermeidlich. Alle weiteren Kopien machen die Lösung m. E. jedoch unnötig unsicherer.
(1) avantguard.io/en/blog/attacking-and-hardening-keepass
***************************
Das ist dann die Stelle, wo viele Nutzer die Nerven verlieren, weil die Daten bis in alle Unendlichkeit verschlüsselt bleiben.
***************************
Nö das ist dann der Zeitpunkt wo der mündige User einfach neu aufsetzt und sein Backup einspielt!
Wenn man die Geräte entsprechend einrichtet, landen die Keys automatisch im lokalen AD, denke das wird bei einer reinen Entra/Cloud Umgebung auch möglich sein.
Das abspeichern des Keys auf der verschlüsselten Festplatte ist hingegen sehr Sinnfrei wenn man ihn dann mal braucht und nicht dran kommt.
Wenn der Key nicht bekannt ist, Bitlocker aufheben und neu verschlüsseln. Den neuen Key dann irgendwo außerhalb der Festplatte sichern, ob auf einer eigenen NAS oder ggf. in einer Keypass Datei auf OneDrive muss jeder selber Wissen.
Wenn der Key nicht bekannt ist, kann man ihn jederzeit über die Bitlocker-Verwaltung extrahieren. Eine De- und Neuverschlüsselung ist dazu keinesfalls notwendig.
> Wenn der Key nicht bekannt ist, kann man ihn jederzeit über die Bitlocker-Verwaltung extrahieren. <
Ja aber doch nur solange wie das System startbar ist. Oder was habe ich nicht verstanden?
Microsoft Copilot in Edge erwähnt auf entsprechende Anfrage ("bde type of key protectors") u. a.: "PIN", "startup key", "Password", "Recovery key", "Recovery password".
Was davon kann man in Deinem Sinne "jederzeit" extrahieren?
Und man kann den Wiederherstellungsschlüsel auch ausdrucken und irgendwo sicher hinterlegen. Ängstliche Naturen schneiden das Ding durch und lagern einen Teil bei Muttern im Kleiderschrank oder so.
Man sollte das nur irgendwie tun!
Es gibt ja die Möglichkeit den Wiederherstellungsschlüssel in der onPrem AD zu speichern. Dann ist er im entsprechenden Computerobjekt sichtbar. Das der Schlüssel überhaupt an einem Benutzerobjekt dranhängt ist ja meiner Meinung nach völlig falsch, denn der Schlüssel ist ja für jeden Benutzer auf dem PC der gleiche.
Es wäre jedenfalls interessant wennso eingestellt, dass der Schlüssel im onPrem AD verspeichert wird ob dieser dann immer noch in Azure über einen Benutzer ab zu rufen ist. Das wäre dann schon eine riesen Sicherheitslücke die da absichtlich aufgerissen wird.
Kürzlich als wir unsere Zweigniederlassung vollständig in unsere Hybrid Domäne hinzugefügt haben. Hatte ein Gerät Probleme mit Hardware Kompnenten. Nach dem Austausch wurde der Recovery Key angefordert. Zu meinem Erstaunen, war dieser nirgends zu finden.
Zuerst schöpfte ich den Verdacht, dass bei der Migration etwas nicht richtig gelaufen ist. Doch bei 12 von 13 Geräte, war der Recovery Key auf Entra ID ersichtlich (Murphy hat also zugeschlagen).
Nun es blieb mir nichts anderes übrig als das OS neu zu installieren. Nun ist alles konform, Recovery Key liegt bei mir.
Nun – nach dem lesen des Beitrages hätte ich nun auch die Lösung gehabt. Womöglich lag der Recovery Key bei der Tochterfirma, da der User auch M365 dort hin verknüpft.
Nun, fürs nächste Mal, weiss ich wie ich da auch vorgehen kann. Allgemein hab ich mir angewohnt, vor der Reparatur den Recovery Key zu sichten, vorher melde ich keine Rep an.
Aus meiner pragmatischer Sicht müsste eigentlich der erste Domain Join den Recovery Key beim hinterlegten Entra ID hinterlegen und muss immutable sein bis das Gerät mit dem Wipe aus Entra ID geworfen wird.
Mal sehen, evtl. habe ich ab ca. 2027 Zeit für solche ausgiebige Tests wenn alle meine aktuellen internen Probleme gelöst sind :-)
Ich habe gerade geschaut, ich habe in zwei Vereinen bei den Vorständen, die das Microsoft 365 nutzen auch Bitocker Keys im Tenant gespeichert.
Ich habe eine Frage zum Bitlocker Wiederherstellungspasswort. Das Auslesen der Key Protektoren kann ich ja über eine Shell (cmd.exe oder Powershell) unter Windows mit dem Befehl
manage-bde -protectors -get c:
auslesen. Da werden mir dann alle eingesetzten Protektoren für Bitlocker angezeigt, unter anderem auch das Wiederherstellungspasswort.
Wo wird denn dieses Passwort genau auf der Festplatte gespeichert?