TPM protected Certificates, Virtual Smart Cards und Key Attestation
Von der Sicherheit privater Schlüssel – oder verstecken Sie den Haustürschlüssel immer noch unter der Türmatte?
TPM protected Certificates, Virtual Smart Cards und Key Attestation
Bereits im Jahr 2000 wurden die "10 immutible laws of security" definiert (https://technet.microsoft.com/library/cc722487.aspx). Eines eben jener Gesetzte besagt, dass verschlüsselte Daten nur so sicher sind wie der zugehörige Entschlüsselungsschlüsse aufbewahrt wird. Was als sicherer Aufbewahrungsort für Schlüssel gelten kann, hat sich im Laufe der Jahre stark verändert. Wie sollte man also heute einen Schlüssel sicher aufbewahren?
Im Falle von asymmetrischer Kryptographie, die meinem Lieblingsthema "Public Key Infrastructure" zugrunde liegt, hat man der Schlüssel sogar zwei: Den sogenannten "Public Key", der wie der Name schon vermuten lässt kein Geheimnis darstellt und den zugehörigen "Private Key" um dessen Schutz es in diesem Artikel gehen soll.
Grundsätzlich haben alle Arten von privaten Schlüsseln einen hohen Schutzbedarf und einige der vorstellten Konzepte und Überlegungen können daher auf jeden beliebigen privaten Schlüssel angewendet werden; egal ob es um die privaten Schlüssel einer Zertifizierungsstelle, eines Web Servers, eines Benutzers oder Netzwerkgeräts geht. Vorwiegend aber beschäftigt sich dieser Artikel mit der Sicherheit privater Schlüssel von Benutzern und Computern.
Was tut Windows um private Schlüssel zu schützen?
Wird ein Zertifikat in einem der Windows Certifiate Stores aufbewahrt, ist für den Schutz des zugehörigen privaten Schlüssels die DPAPI (Data Protection API) zuständig. Die DPAPI verschlüsselt private Schlüssel auf der Festplatte eines Computers (https://blogs.msdn.com/b/shawnfa/archive/2004/05/05/126825.aspx). DPAPI kennt genau zwei Funktionen: CryptProtectData und CryptUnprotectData. Die DPAPI erzeugt hierfür einen sog. „Master Key“. Dieser wird wiederum mit einem aus den Credentials des Benutzers oder Computers abgeleiteten Master Key verschlüsselt. Weiters wird ein „Session Key“ für jeden Aufruf von CryptProtectData erzeugt (abgleitet aus dem Master Key und Zufassdaten). Die Daten (in diesem Fall die privaten Schlüssel) werden schließlich mit dem „Session Key“ verschlüsselt. Eine detaillierte Beschreibung dieser Vorgänge finden Sie auf https://msdn.microsoft.com/en-us/library/ms995355.aspx
Die DPAPI macht einen großartigen Job und die Brute-force Entschlüsselung der von ihr geschützten Informationen ist bei aktuellen Windows Versionen extrem schwierig geworden (ab Windows 7 wird AES als Verschlüsselungsalgorithmus von der DPAPI genutzt). Ist das Betriebssystem aber einmal gestartet und hat sich ein berechtigter Benutzer angemeldet, muss die DPAPI das private Schlüsselmaterial des Benutzers freigeben damit es in den Arbeitsspeicher geladen werden kann. Damit ist das Schlüsselmaterial für jede Anwendung, die ebenfalls im Security-Kontext des angemeldeten Benutzers oder Computers läuft, verfügbar. Dies beinhaltet auch Schadsoftware.
Von Schlüsseln zu PKI
Ein PKI-Grundgedanke ist, dass ein Benutzer über sein Schlüsselmaterial frei verfügen, d.h. auch Kopien und Backups davon anfertigen kann. Genau das wollen wir jedoch mit dem heutigen Einsatz von PKI in vielen Fällen verhindern, z.B. wird zertifikatsbasierte Authentifizierung im WLAN gerade deshalb implementiert weil Benutzer eben nicht ihre privaten Geräte mit dem Unternehmensnetzwerk verbinden sollen. Ein wichtiger Faktor beim Schutz privater Schlüssel ist Nicht-Exportierbarkeit (“non exportability”) .
In diesem Zusammenhang ist manchen Lesern vermutlich das "allow private Key to be exportable" Kontrollkästchen in den Einstellungen einer Zertifikatsvorlage bekannt:
 |
Wir empfehlen diese Einstellung so zu wählen, dass der Export privater Schlüssel möglichst erschwert wird. Es ist aber auch kein Geheimnis, dass ein derart als nicht exportierbar markierter Schlüssel nur begrenzten Schutz bietet. Ist ein privater Schlüssel einmal in Verwendung, befindet er sich im Arbeitsspeicher des Rechners und von dort kann er - entsprechende Berechtigungen am Betriebssystem (lokale Administratoren oder “Debug” Berechtigungen) sowie entsprechende Software vorausgesetzt - auch wieder ausgelesen werden. Im Fokus stehen, neben Mitarbeitern auch Angriffe von außen. |
Zertifikate nebst privater Schlüssel können, abhängig von ihrer Konfiguration (typischerweise geht es um die Parameter „Subject“, „Key Usage“ und “Enhanced Key Usage”), sehr mächtige Instrumente darstellen: Ein Zertifikat kann z.B. zur Authentifizierung verwendet werden, jedoch sind aus der jüngeren Vergangenheit auch einige Fälle bekannt im Zuge derer gestohlene Code Signing Zertifikate zur Signatur von Malware verwendet wurden.
Neue Features in Windows 8 bzw. Server 2012 und höher
Trotz aller Verbesserungen im Betriebssystem wird ein in Software erzeugter und gespeicherter privater Schlüssel, mit den heute verfügbaren Methoden, nicht die Sicherheit eines in Hardware gespeicherten privaten Schlüssels erreichen. Bisher zählten lediglich HSMs und physische Smart Cards zu der Kategorie "Hardware". Neu ist ab Windows 8 bzw. Server 2012 die Möglichkeit sowohl Computer- wie auch Benutzerzertifikate ("Virtual Smart Card") mit Hilfe eines TPM Chips abzusichern. Ab Windows 8.1 bzw. Server 2012 R2 kommt noch ein weiteres auf dem TPM Chip basierendes Feature hinzu: Key Attestation.
Wie läuft das Ausrollen eines Zertifikates eigentlich ab?
Da der Enrollment Prozess bereits in einem vorangegangenen Blogeintrag (https://blogs.technet.com/b/austria/archive/2015/04/28/windows-certificate-enrollment.aspx) genau beschrieben wurde, beinhaltet die folgende Beschreibung lediglich die zusätzlichen Aspekte von virtual Smart Cards bzw. Key Attestation.
1. Wird der Prozess des Ausrollens angestoßen, lädt ein Windows Domain-joined Client unter anderem die Zertifikatsvorlagen von einem DC und erstellt gemäß dieser Vorgaben ein Schlüsselpaar unter Zuhilfenahme des im Template angegebenen CSP bzw. KSP; hierbei kann es sich um ein "in Software" oder ein "in Hardware" erzeugtes Schlüsselpaar handeln. Daraus wiederum wird eine Certificate Request erstellt und an die CA geschickt. Der private Schlüssel verlässt das antragstellende Device nicht, im Falle eines HSMs oder einer physischen bzw. virtuellen Smart Card wäre dies in den meisten Fällen auch gar nicht möglich.
2. Die CA verifiziert die Certificate Request, stellt bei positivem Ausgang ein Zertifikat aus und schickt dieses an den Antragsteller. Im Zuge dieser Prüfung vergleicht die CA unter anderem das in der Request angegebene Subject gegen den Benutzer- bzw. Computernamen im AD oder auch die Schlüssellänge oder Gültigkeitsdauer des Antrags. Einen wesentlichen Parameter kann die CA allerdings bei dieser Methode nicht verifizieren: welcher CSP bzw. KSP verwendet wurde um das Schlüsselpaar zu erstellen. Vom CSP bzw. KSP hängt jedoch ab ob das Schlüsselpaar in Soft- oder in Hardware erzeugt wurde. Dieses Problem wird nun in Windows 8.1 bzw. Server 2012 R2 durch das neue Feature "Key Attestation" gelöst, Näheres dazu ein paar Absätze weiter unten.
TPM Protected Certificates
Windows unterscheidet ob ein Zertifikat im Security Context eines Benutzers oder eines Computerkontos (oder eines Dienstes) ausgerollt wird. Die Funktionalitäten einer virtual Smart Card wären im Context eines Computerkontos sinnlos bzw. unmöglich, wer sollte denn den PIN eingeben? Dennoch können derartige Zertifikate mit Hilfe des TPM Chips ausgerollt werden. Die Kernfunktionen des TPM Chips (Isolated Cryptography, non-Exportability und Tamper Protection) stehen in jedem der beschriebenen Szenarien zur Verfügung und tragen wesentlich zum Schutz des privaten Schlüssels bei. Konkret wird das Schlüsselpaar „im“ TPM Chip erzeugt und kann aus diesem nicht exportiert werden. (Ganz konkret wird der private Schlüssel auf der Festplatte des Computer gespeichert, liegt dort aber nur in durch den TPM Chip verschlüsselter Form vor und kann auch nur von diesem wieder entschlüsselt werden.)
Einen Nachteil von TPM Protected Certificates, physischen und virtuellen Smart Cards möchte ich hier nicht unerwähnt lassen: Bei "Non-Exportability" handelt es sich um ein Sicherheitsmerkmal, d.h. der private Schlüssel kann auch von Berechtigten nicht exportiert werden da diese Funktion schlicht und einfach fehlt. Was für Authentifizierungszertifikate kein Problem darstellt kann im Falle von Verschlüsselungszertifikaten zur Herausforderung werden, da mit einem öffentlichen Schlüssel verschlüsselte Daten ausschließlich mit dem zugehörigen privaten Schlüssel wieder entschlüsselt werden können und weder ein TPM Chip noch eine physische Smart Card ein Backup zulässt. (Virtual) Smart Card Management Software nimmt sich dieses Problems an und bietet einen Workaround an.
Virtual Smart Cards
Eine Virtual Smart Card unterscheid sich von einem "TPM Protected Certificate" durch das „Look & Feel“ einer physischen Smart Card inkl. PIN Eingabe. Das Ausrollen eines Zertifikats auf eine Virtual Smart Card setzt jedoch voraus, dass diese angelegt wurde. Die Windows Boardmittel stellen hierfür lediglich ein Kommandozeilenutility zur Verfügung. Das Anlegen einzelner VSCs ist somit kein Problem, für ein größer angelegtes Rollout empfiehlt sich jedoch auf diese Aufgabe spezialisierte Software wie z.B. MIM (Microsoft Identity Manager, vormals bekannt als Forefront Identity Manager).
Neue Features in Windows 8.1 bzw. Server 2012 R2 und höher - Key Attestation
Wie bereits erwähnt, kann eine Zertifizierungsstelle im Rahmen eines „normalen“ Ausrollprozesses nicht verifizieren ob das Schlüsselpaar tatsächlich mit Hilfe eines TPM Chips erstellt wurde, d.h. es wäre theoretisch möglich, dass ein Benutzer bewusst oder unbewusst den Ausrollprozess derart manipuliert, dass das Schlüsselpaar, entgegen der Einstellungen im Template, in Software erstellt wird. Eine ab Windows 8.1 bzw. Server 2012 R2 verfügbare Funktion kann dies verhindern.
„Key Attestion“ eröffnet der Zertifizierungsstelle die Möglichkeit zu verifizieren wie das Schlüsselpaar erzeugt wurde indem sie eine Bestätigung des TPM Chips einfordert. Dieser kann den Beweis durch eine Gegensignatur mit Hilfe seines Endorsement Key bzw. Endorsement Certificates (siehe auch https://technet.microsoft.com/de-de/library/cc770443.aspx) erbringen.
Fazit
Ein in Software erzeugtes und gehaltenes Schlüsselpaar gilt heute nur noch als begrenzt sicher (solange der entsprechende Rechner bzw. die Festplatte offline und sich im beaufsichtigten Besitzt befindet). Smart Cards würden dieses Problem zwar grundsätzlich lösen, gelten aber als etwas umständlich und sind auch im Vergleich langsamer. Windows 8 bzw. Server 2012 und höher ermöglichen sichere Erzeugung und Aufbewahrung von privaten Schlüsseln mit Hilfe des – auf aktuellen Rechnern vorhandenen – TPM Chips.