Schlüsselverschlüssler Sicherheit des User Master Key unter Windows

Ordnungsmerkmale

erschienen in: <kes> 2004#1, Seite 17

Rubrik: Systeme und ihr Umfeld

Schlagwort: Schlüssel-Sicherheit

Autor: Von Uwe Wöhler, Hallbergmoos

Zusammenfassung: Der User Master Key ist in letzter Instanz – unter anderem – verantwortlich für die Sicherheit des Windows-Krypto-File-Systems EFS. Wie gut er gesichert ist und was man für seinen Schutz tun kann, beschreibt dieser Beitrag.

Windows liefert Anwendungen ab Version 2000/SP3 die Möglichkeit, kryptographische Verfahren zur Datenverschlüsselung, digitalen Signatur und zertifikatsbasierten Authentifizierung über die Crypto API (CAPI) des Betriebssystems anzusprechen. Die Gesamtsicherheit hängt in diesem System außer von der Güte der verwendeten Protokolle und Algorithmen auch von der Sicherheit der Schlüsselspeicherung ab. Die so genannten Cryptographic Service Provider (CSP) legen geheime Schlüssel häufig in chiffrierten Dateien ab (Cryptographic Store). Wie gut sind solche Informationen aber gesichert?

Eine (mitgelieferte) CAPI-Anwendung ist Microsofts Encrypting File System (EFS, vgl. Kasten) zur Dateiverschlüsselung. Die eigentlichen Daten werden dabei mittels symmetrischem Schlüssel (File Encryption Key, FEK) chiffriert. Diesen FEK verschlüsselt das EFS per RSA-Verfahren mit dem öffentlichen EFS-Schlüssel des Benutzers und legt das Chiffrat am Anfang der Datei (im Header) ab. Den zugehörigen geheimen Schlüssel des Benutzers speichert Windows im Ordner "RSA" des Benutzerprofils (unter XP typischerweise C:\Dokumente und Einstellungen\<User>\Anwendungsdaten\Microsoft\Crypto\RSA\) – wiederum in verschlüsselter Form, chiffriert mit dem User Master Key. Sichtbar wird dieser Speicher beispielsweise in der Management-Konsole "Zertifikate" im "My"-Store ("Eigene Zertifikate") des Benutzers. Letztlich hängt also die Sicherheit des EFS oder anderer CAPI-Anwendungen vom (Zugriffs-)Schutz des Master-Keys ab, der diesen "Store" sichert (bei XP sind das 64 zufällige Bytes, aus denen das System 3DES-Keys ableitet, unter Windows 2000 56 bzw. 128 Bit die per RC4 generiert werden).

Der Master-Key eines Benutzers wird vom System beim erstmaligen Logon erzeugt und später alle 60 Tage automatisch erneuert. Der Master-Key wird durch zwei verschiedene Schlüssel verschlüsselt im Benutzerprofil abgelegt:

----------Anfang Textkasten----------

Encrypting File System (EFS)

Wie der Name schon nahelegt, handelt es sich bei Microsofts Encrypting File System (EFS) um ein verschlüsselndes Dateisystem. EFS ist jedoch weder ein Krypto-Tool, das Dateien chiffriert und transportabel macht, noch eine komplette Festplattenverschlüsselung, sondern eine Erweiterung des NT File System (NTFS), die den transparenten Zugriff von Applikationen auf verschlüsselt abgelegte Ordner und Dateien ermöglicht.

Der Administrator oder Benutzer gibt per Encryption-Flag an, ob bestimmte Verzeichnisse Dateien verschlüsselt oder unverschlüsselt speichern. Beim Zugriff auf diese Dateien wird automatisch in den Hauptspeicher entschlüsselt – auf der Festplatte bleiben die Daten chiffriert. Auch beim Kopieren in unverschlüsselte Bereiche wird automatisch entschlüsselt. Applikationen "sehen" somit faktisch unverschlüsselte Daten, wodurch höchste Kompatibilität erreicht werden soll. Microsofts Backup-Utility und auch andere Hersteller bieten für EFS eine verschlüsselte Datensicherung an, bei der alle Dateien chiffriert bleiben.

Integriertes Data Recovery

EFS bindet zur Notfall-Entschlüsselung immer einen weiteren Header an die Dateien. Dieser zweite Header wird mit dem Data Recovery Agent (DRA) verschlüsselt. Falls eine Datei nicht mehr per User-Key zu entschlüsseln ist, kann sie mittels DRA entschlüsselt werden.

Damit EFS zentral verwaltbar bleibt, sollte man einige Punkte beachten: Der DRA ist normalerweise nur einmal vorhanden. Es handelt sich dabei um ein selbst-signiertes Zertifikat des ersten Domain-Administrators. Üblicherweise benötigt man aber mehrere Personen (Redundanz), um die Notfall-Entschlüsselung zu gewährleisten. Daher empfiehlt sich bei Windows 2000/2003 die Installation der Certificate Services (vgl. S. 10). Dort können dann alle Verschlüsselungszertifikate automatisch ausgestellt und auch weitere DRA erzeugt und im Active Directory veröffentlicht werden. Dann lassen sich auch kompromittierte DRA zurückziehen (Revocation) und in eine Sperrliste aufnehmen, damit keine weiteren Dateien mehr ver- oder entschlüsselt werden können.

Um die bestmögliche Sicherheit für den DRA zu erreichen, sollte man den zugehörigen geheimen Schlüssel mit dem Zertifikatsmanager (certmgr.msc) aus dem System entfernen und auf Datenträger im Safe aufbewahren: Anders als den öffentlichen Schlüssel, den der Client bei Verschlüsselungsoperationen benötigt, wird ja der geheime Schlüssel nur im Notfall für das Recovery gebraucht. Im Falle eines Falles kann man dann (ebenfalls mit dem certmgr.msc) das Zertifikat mit dem geheimen Schlüssel auf die Recovery-Station re-installieren und die Entschlüsselung vornehmen.

----------Ende Textkasten----------

Hauptschlüssel-Hacks

Sollte ein Angreifer in den Besitz des (unverschlüsselten) Master-Key gelangen, so hätte er damit die Möglichkeit, alle im Dateisystem für diesen Benutzer gespeicherten CSP-Keys zu nutzen – beispielsweise also auch alle EFS-Dateien des Benutzers zu lesen. Windows birgt hier einige systemimmanente Schwachstellen beim Schutz des Master-Key:

Smartcard-Logon

Die beste Methode den geheimen Benutzerschlüssel besser zu schützen wäre es, ihn auf einem sicheren Speicher abzulegen, beispielsweise einer Smartcard oder einem Hardwaremodul. Falls man damit Tausende EFS-Dateien verschlüsselt, ergibt dies allerdings wegen der vergleichweise langsamen Chipkartenoperationen nur in einer zweistufigen Anordnung Sinn: Die erste Stufe verschlüsselt (rein in Software) die Datei-Schlüssel (FEK), die zweite Stufe verschlüsselt den Verschlüsselungsschlüssel per Smartcard (vgl. Abb. 1). Durch diese Vorgehensweise ist es zudem möglich, bei Verlust der Smartcard eine neue Karte auszustellen und auf die verschlüsselten Dateien zuzugreifen. Wäre der EFS-Schlüssel direkt auf der Smartcard, wäre kein Recovery der Dateien möglich.

Um die Smartcard beziehungsweise ihren Schlüssel freizuschalten, muss der Benutzer beim Login eine PIN eingeben. Während der Authentifizierung sendet der Client einen Zufallswert (Challenge) nebst öffentlichem Schlüssel im Benutzer-Zertifikat an den Domain-Controller (DC). Dieser antwortet – korrekte Anmeldungsdaten vorausgesetzt – mit der Authentifizierungsinformation für den lokalen Rechner und chiffriert diese mit dem öffentlichen Schlüssel des Benutzers. Im Falle einer Offline-Anmeldung werden zwischengespeicherte Authentifizierungsinformationen genutzt, die vorher mit dem öffentlichen Schlüssel des Benutzers (von der Smartcard) chiffriert worden sind. Ohne Smartcard ist es damit – abgesehen von Recovery-Maßnahmen – nicht möglich, an den Master-Key des Benutzers zu kommen.

[Ablaufdiagramm]
Abbildung 1: Schutz des User Master Key durch Smartcard-Einsatz

Syskey

Um alle Master-Keys sowie alle anderen wichtigen Geheimnisse, die im System gespeichert sind, zusätzlich zu schützen, kann ein Windows-Startpasswort (Syskey) dienen. Bei Systemstart benötigt das Betriebssystem den Syskey, um alle geheimen Schlüssel des Computers zu rekonstruieren, inklusive Master-Key und in der Folge den EFS-Schlüsseln. Das Startpasswort wird automatisch erzeugt und für alle Computer in einer Domain genutzt. Bei Computern außerhalb einer Domain muss man es hingegen manuell aktivieren. Die Sicherheit des Startpasswortes lässt sich erhöhen, indem man den Schlüssel auf Diskette speichert (Syskey Mode 3) oder die manuelle Passworteingabe beim Systemstart fordert (Syskey Mode 2). Allerdings muss man auch hier ein Recovery-Verfahren einführen, das bei Vergessen des Startpasswortes beziehungsweise beim Verlust der Syskey-Diskette den Zugriff auf die Computer ermöglicht.

[Ablaufschema]
Abbildung 2: Schutz des User Master Key durch Syskey-Einsatz

Um Syskey aktivieren zu können, muss man einen Account in der Gruppe der lokalen Administratoren benutzen. Auf der Kommandozeile gibt man "Syskey" ein, um das Tool auf den jeweiligen Computer zu starten und die jeweilige Betriebsart auszuwählen (vgl. Screenshot). Empfehlenswert ist die Schlüsselerzeugung von Windows durchführen zu lassen und den Schlüssel auf einer Diskette zu hinterlegen. Wer selbst ein Passwort auswählen möchte, muss auf hinreichende Komplexität achten, um Wörterbuch- und Brute-Force-Angriffe dagegen zu erschweren. Bei Verlust des Passworts lässt sich das Betriebssystem nicht mehr starten – auch Recovery-Tools können dann nicht mehr weiterhelfen.

Windows XP benötigt im Prinzip kein Startpasswort, da die geheimen Schlüssel des Benutzers ohnehin zusätzlich über den Hashwert seines Passworts verschlüsselt werden. Das Revovery von Passwörtern bei Stand-alone-XP-Computern funktioniert dann mittels Password Reset Disk (PRD). Windows XP Professional eröffnet zudem verschiedene weitere Möglichkeiten für höhere Systemsicherheit: Beispielsweise kann man 3DES oder eine starke Passwort-Policy domänenweit vorschreiben (mehr dazu unter [5]).

Der XP-Nachfolger Longhorn wird darüber hinaus das System in einen "unsicheren" und einen "sicheren" Bereich aufteilen. "Sichere" Anteile sollen dann komplett per Cryptochip verschlüsselt und nur über zertifiziert sichere Hardware und Software benutzbar sein; dort werden dann in Zukunft auch die Krypto-Schlüssel abgelegt. Bis es soweit ist, müssen allerdings noch einige Vorsichtsmaßnahmen eingehalten werden.

[Screenshot]
Abbildung 3:Aktivierung und Konfiguration von Syskey unter Windows XP

Parameter-Plus

Falls man dem System oder dem Administrator nicht vertraut, sieht Windows einige Optionen für den Secure Storage vor: CRYPT_EXPORTABLE erwirkt auf FALSE gesetzt ein Sperren der Exportfunktion. Damit weigert sich Windows grundsätzlich, die Schlüssel in eine Datei zu speichern. Diese Option muss man entweder beim Importieren einer PFX-Datei mit der Microsoft Management Console (MMC) oder beim Enrollment-Prozess setzen (z. B. beim Beantragen des Zertifikates bei einer Zertifizierungsstelle); CRYPT_EXPORTABLE kann nachträglich nicht mehr geändert werden. Falls der Computer nun "offen" ohne Logon-Bildschirm einem Angreifer zur Verfügung steht, kann dieser trotzdem keine geheimen Schlüssel stehlen.

Eine weitere Option, die ebenfalls nur beim Importieren einer PFX-Datei ("Erhöhter Schutz des privaten Schlüssels") oder beim Zertifikatsantrag definiert werden kann, ist CRYPT_USERPROTECTED. Vor dem Verwenden des geheimen Schlüssels muss der Benutzer dann ein zusätzliches Passwort manuell eingeben, um ihn zu aktivieren.

Da beide Optionen die Handhabbarkeit verschlechtern, bieten diese Verfahren nur punktuellen Schutz für kritische Bereiche – beispielsweise zum Schutz für VIPs gegen die eigenen Administratoren. Wirklich gute Sicherheit kann hier jedoch nur durch Einsatz externer Schlüsselspeicher (Smartcards) gewährleisten.

Fazit

Die Cryptographic Services liefern, richtig eingesetzt, eine adäquate Möglichkeit zum Verschlüsseln lokaler Dateien – beispielsweise per EFS. Da die Sicherheit letztlich vor allem von der Schlüsselspeicherung durch Windows abhängt, sollte man die Clients konsequent absichern. Unter Windows 2000 ist es ratsam Stand-alone-Computer durch Syskey zu schützen; bei Windows XP ist dies nicht mehr notwendig. In jedem Fall bleibt empfehlenswert, alle Computerkonten (mobil oder nicht) und alle Benutzerkonten komplett per Active Directory zu administrieren, was die Sicherheit aller Schlüssel erhöht (Passwörter können nur auf dem Domain Controller zurückgesetzt werden) und das System-Management vereinfacht. Wer bereits Active Directory Services (ADS) betreibt, kann mit geringem Aufwand kritische Systeme, etwa VIP-Notebooks, per Smartcard-Logon schützen.

Uwe Wöhler ist Security Consultant bei der »|secaron AG.

Literatur

[1]
Crypto, Key Protection, and Mobility in Windows, [externer Link] http://csrc.nist.gov/pki/twg/y2000/presentations/twg-00-35.pdf
[2]
Implementation Issues for Cryptography, NIST-Empfehlung zur Speicherung geheimer Schlüssel, [externer Link] http://csrc.nist.gov/publications/nistbul/csl96-08.txt
[3]
NIST, Secure password recommendation, [externer Link] http://csrc.nist.gov/publications/fips/fips112/fip112-2.wp
[4]
Microsoft White Paper, Smart Card Logon, [externer Link] www.microsoft.com/windows2000/techinfo/howitworks/security/sclogonwp.asp
[5]
Microsoft, Strengthening Key and File Security, [externer Link] www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/winxppro/reskit/prnb_efs_zbxr.asp
[6]
BSI-Grundschutzhandbuch, Sichere Nutzung von EFS unter Windows 2000, [externer Link] www.bsi.de/gshb/deutsch/m/m04147.html