EFS Recovery – oder: Vorsorge ist allesTeil 2 - Einrichtung von Data Recovery Agents

Teil 1 - Technische Eckdaten des EFS

Autor: olc, MCSEboard.de

 

Um das Thema im Kern zu verstehen ist es wichtig, die Funktionsweise von EFS zumindest zu kennen. Seit Windows 2000 bringt Microsoft das verschlüsselnde Dateisystem EFS standardmäßig mit. Es ermöglicht – kurz gesagt – das Verschlüsseln von Dateien und Ordnern auf einem Windows System mit NTFS formatiertem Datenträger. In diesem HowTo wird nicht weiter auf Windows 2000 eingegangen, sondern Windows XP / Server 2003 vorausgesetzt. Es gibt einige Unterschiede, die in diesem HowTo nicht weiter beleuchtet werden sollen. Interessierte könne hierzu einige Informationen in den am Ende angegebenen Links erhalten.

Wird eine Datei verschlüsselt, errechnet das System einen zufälligen symmetrischen Schlüssel, der die Entschlüsselung der Datei ermöglicht. Dieser symmetrische Schlüssel ist für jede Datei unterschiedlich. Das hat den Vorteil, dass es nicht möglich ist alle Dateien zu knacken, sollte ein Angreifer den Zugriff auf einen der Schlüssel bekommen, so z.B. über einen Brute-Force Angriff auf eine einzelne Datei.

Dieser zufällig erzeugte Schlüssel nennt sich File Encryption Key (FEK). Der File Encryption Key wird mit dem öffentlichen Schlüssel des berechtigten Benutzers verschlüsselt und in diesem verschlüsselten Zustand im Header der verschlüsselten Datei abgelegt, im sogenannten Data Decryption Field (DDF). Gleiches gilt für jeden weiteren Benutzer, der Zugriff auf die Daten haben soll – mit dem öffentlichen Schlüsseln des jeweiligen Benutzers verschlüsselt wird der FEK im DDF abgelegt. Mehreren Benutzern den Zugriff auf eine verschlüsselte Datei zu gestatten ist jedoch erst ab Windows XP möglich. Es ist nicht möglich auf Ordnerebene festzulegen, dass mehrere Benutzer die Dateien dieses Ordners öffnen dürfen. Markiert man einen Ordner als „verschlüsselt“, vererbt er diese Eigenschaft an die Dateien innerhalb des Ordners – der Ordner selbst kann nicht verschlüsselt werden.

Wie der Name „öffentlicher Schlüssel“ schon zeigt, sind die Benutzerschlüssel nach dem asymmetrischen Verschlüsselungsprinzip erzeugt, dass heißt es existiert je ein privater Schlüssel und ein öffentlicher Schlüssel für einen Benutzer. Dazu später mehr – grundsätzliche Informationen gibt es an verschiedenen Stellen im Internet unter dem Stichwort „Public Key Infrastructure“ (PKI) bzw. „PKI Verschlüsselung“.

Alle Benutzer, für die der File Encryption Key verschlüsselt im Data Decryption Field der Datei aufgeführt ist, können die Datei entschlüsseln – solange sie den privaten Schlüssel besitzen, der Ihnen den Zugang zur Datei gewährt.

Hintergrund dieser Methode der Dateiverschlüsselung, also dem Verschlüsseln einer Datei mittels symmetrischer Verschlüsselung und das Ablegen des symmetrischen Schlüssels in den wiederum mittels asymmetrischer Verschlüsselung gesicherten Teil einer Datei ist recht schnell erklärt: Die symmetrische Verschlüsselung ist aufgrund der einfacheren Berechnung des Schlüssels und der Daten schlichtweg schneller – auf gängiger Hardware geschätzte 1.000x so schnell wie eine asymmetrische Verschlüsselung.

Um also keine ausufernde CPU Belastung auf einem System zu riskieren, auf dem mit verschlüsselten Dateien gearbeitet wird, macht diese Methode mehr Sinn. Da die asymmetrische Verschlüsselung aufgrund Ihrer Architektur in Netzwerken jedoch bei weitem sicherer ist als die symmetrische Verschlüsselung, wird sie ebenfalls herangezogen. Mit der Kombination beider Verschlüsselungsmethoden erreicht man ein hohes Maß an Performance und Sicherheit.

Zusätzlich zum Data Decryption Field gibt es ein sogenanntes Data Recovery Field (DRF) im Header der verschlüsselten Datei. In diesem Teil des Headers wird ein sogenannter Data Recovery Agent (DRA) definiert, der z.B. beim Verlust der privaten Schlüssel durch den Benutzer die Dateien trotzdem noch öffnen kann. Auch hier wird der File Encryption Key der entsprechenden Datei, verschlüsselt mit dem öffentlichen Schlüssel des Data Recovery Agents, im Header gespeichert, nur in einem anderen Feld – dem Data Recovery Field. Unterschied zum Data Decryption Field ist im Grunde „nur“ der, dass der Data Recovery Agent zentral festgelegt wird, also in jede verschlüsselte Datei nach dem Konfigurieren des DRA mit aufgenommen wird, während dessen wie oben erwähnt zusätzlich berechtigte Benutzer für eine Datei einzeln pro Datei festgelegt werden müssen.

Verliert nun ein Benutzer seinen privaten Schlüssel, der verschlüsselt im Benutzerprofil unterhalb von „%APPDATA% \Microsoft\Crypto\RSA“ abgelegt ist, oder seinen Master Key, der wiederum den privaten Schlüssel schützt und verschlüsselt unterhalb von „%APPDATA%\Microsoft\Protect“ liegt, kommt niemand mehr an die Daten des Benutzers heran. Der Data Recovery Agent hingegen kann die Daten entschlüsseln, solange er wiederum im Besitz des eigenen privaten DRA Schlüssels ist. Der private Schlüssel des verschlüsselnden Benutzers wird in diesem Fall nicht benötigt.

Genau hier liegt das Problem beim Thema EFS: Wurde eine Datei von einem Benutzer verschlüsselt, ohne dass ein Data Recovery Agent definiert wurde, ist ausschließlich der Benutzer selbst in der Lage, die Datei zu entschlüsseln – es sei denn, es wurden vom Benutzer manuell weitere berechtigte Benutzer hinzugefügt, was jedoch in der Praxis der Erfahrung nach meist nicht der Fall ist.

Solange der Benutzer selbst auf die Datei zugreifen kann, also sein privater Schlüssel vorhanden und auch zugreifbar ist, kann der Recovery Agent auch nachträglich hinzugefügt werden. Die CryptoAPI des Windows Systems sorgt beim „anfassen“ der Datei durch den Benutzer selbständig dafür, dass der Datei der Recovery Agent transparent für den Benutzer hinzugefügt wird.

HINWEIS: Möchte man alle Dateien nach einer Änderung des DRA aktualisieren, ohne dass der berechtigte Benutzer jede Datei aufrufen muss (oder sich mindestens die Dateieigenschaften liest, so z.B. beim Öffnen eines Verzeichnisses), kann „efsinfo.exe /t“ ausgeführt werden.
Dies ist wichtig zu verstehen, will man nachträglich einen DRA definieren: Erst, wenn der Benutzer die verschlüsselten Dateien bzw. Verzeichnisse öffnet bzw. die Dateieigenschaften liest, wird der neue  DRA eingetragen. Tut der Benutzer dies nicht, wird der DRA auch nicht den Dateien hinzugefügt.


Ist jedoch der private Schlüssel des Benutzers nicht mehr vorhanden (z.B. durch das Löschen des Profils oder einer Neuinstallation des Rechners) oder schlichtweg nicht mehr zugreifbar (z.B. durch das Zurücksetzen des Kennworts des Benutzers durch einen Administrator außerhalb von Domänenumgebungen), kann auch der Data Recovery Agent nachträglich nicht mehr hinzugefügt werden. Die Daten sind nicht mehr auf normalem Wege zu entschlüsseln.

HINWEIS: Unter Windows 2000 war es möglich, als administrativer Benutzer das Kennwort eines Benutzers zurückzusetzen, ohne das der sogenannte „Master Key“ des Benutzer, dessen Kennwort geändert wurde, gesperrt wurde. Das ermöglichte die Entschlüsselung von Dateien durch einen anderen Benutzer, der die Möglichkeit hatte, das Kennwort des Benutzers zurückzusetzen, dessen Dateien verschlüsselt waren.
Dies stellte natürlich eine große Sicherheitslücke dar, die jedoch unter Windows XP geschlossen wurde. Setzt ein Administrator auf einem Workgroup Client (also einem Windows XP System, welches nicht Mitglied einer Domäne ist) das Kennwort eines Benutzers zurück, wird der Zugriff auf den Master Key des betroffenen Benutzers gesperrt. Somit kann auch nicht auf den privaten Schlüssel des Benutzers zugegriffen werden und keine Dateien entschlüsselt werden.

 

© MCSEboard.de, olc

EFS Recovery – oder: Vorsorge ist allesTeil 2 - Einrichtung von Data Recovery Agents