CredentialProvider zum Windows Login mit Personalausweis
Zusammenfassung
Im Rahmen des Seminars "IT Security Workshop" haben wir uns mit dem Thema "CredentialProvider zum Windows Login mit Personalausweis" befasst. Hierbei war unser Ziel die eID Funktion des neuen Personalausweises in Form der Selbstauskunft zu nutzen, um sich sicher bei einem Windows 10 System anzumelden. Wir haben einen Credential Provider 2 implementiert, der mittels der Selbstauskunft einige auf dem Personalausweis gespeicherte Daten (wie Namen, Adresse, Geburtsdatum etc.) abgreift. Die Ausweisdaten, die wir durch die Selbstauskunft erhalten waren uns nicht geheim genug, weshalb wir uns dazu entschlossen haben, optional ein Second-Factor-Password hinzuzunehmen. Dieses wird zusammen mit den Personalausweisdaten benutzt, um das eigentliche Account Passwort verschlüsselt in der Registry abzuspeichern. Bei der Anmeldung kann sich ein registrierter Nutzer dann mit Hilfe seines hinterlegten Personalausweises, dem Personalausweis PIN und ggf. dem gewählten Second-Factor-Password anmelden. Leider ist für die Selbstauskunft eine Internetverbindung nötig, da die verschlüsselten Daten auf dem Personalausweis über SSL an einen bestimmten Webserver übertragen werden und von diesem dann entschlüsselt (aber weiterhin über SSL) an den Client ausgeliefert werden. Es gibt eine Open Source Anwendung (AusweisApp2), die eine solche Selbstauskunft ermöglicht. Allerdings ist diese Anwendung bisher nur per GUI bedienbar und benötigt eine Bestätigung per Klick sowie ggf. den Personalausweis PIN, weshalb dies im Secure Desktop von Windows bei der Anmeldung recht schwierig geworden wäre. Aus diesem Grund haben wir uns entschlossen ein anderes Open Source Projekt zu verwenden, um die Selbstauskunft zu realisieren. Dieses Projekt nennt sich eIDClientCore und wurde ebenfalls an der Humboldt Universität zu Berlin entwickelt. Später stellte sich heraus, dass dieses Projekt in einem nicht funktionsfähigen Zustand war, da wir erst zahlreiche Abhängigkeiten zu alten und z.T. auch geänderten Bibliotheken herstellen mussten. Außerdem scheint das Projekt nicht ganz fertiggestellt worden zu sein, da z.T. einige Funktionalitäten nur teilweise implementiert waren und auch Implementierungsfehler beinhalten. Es ist uns dennoch gelungen die Abhängigkeiten und fehlende Funktionalität umzusetzen, so dass wir eine DLL bauen konnten, die den Zweck der Selbstauskunft genügt. Aufgrund der eher schlechten Codequalität und der mit hoher Wahrscheinlichkeit enthaltenen Fehler im eIDClientCore raten wir davon ab, diesen und somit auch unsere Anwendung in Produktivumgebungen einzusetzen. Wir halten es jedoch für gar nicht so schwierig den eIDClientCore mit modernem C++ und aktuellen Bibliotheken (wie OpenPACE) neu (und sicherer) zu implementieren. Dies haben wir im Rahmen dieses Seminars aus Zeitgründen nicht mehr verwirklichen können, könnte allerdings für Studenten in einem weiteren Seminar ein mögliches Thema sein.
Ein paar Details zu unseren Sicherheitsmechanismen
Wir speichern zu jedem registriertem Nutzer (anhand der SID) folgende Daten in der Windows-Registry:
- Ein 126 Bit Initialisierungsvektor für die Ver- und Entschlüsselung mittels AES-256-CBC. Dieser wird bei der Registrierung eines Nutzers zufällig gewählt.
- Ein 256 Bit Salt, welches zum Hashen und Verschlüsseln benutzt wird und bei jeder Registrierung eines Nutzers zufällig gewählt wird.
- Ein Hash aus dem Second-Factor-Password und dem Salt. (Dieser wird zusätzlich mit den von Windows zur Verfügung gestellten Sicherheitsmechanismen verschlüsselt.) [Dies war ursprünglich dazu gedacht, das Second-Factor-Password unabhängig von den Personalausweisdaten validieren zu können. Da wir aus Zeitgründen dies nicht mehr umsetzen konnten, haben wir diesen wieder auskommentiert.]
- Ein Secret, welches das verschlüsselte Account Passwort darstellt. Als Schlüssel werden hierfür der Hash aus den Personalausweisdaten und den Second-Factor-Password genommen. Dabei fließt beim Hashen das Salt mit ein. Verschlüsselt wird mit AES-256-CBC und dem in der Registry hinterlegten Initialisierungsvektor. (Auch das Secret wird zusätzlich mit den von Windows zur Verfügung gestellten Sicherheitsmechanismen verschlüsselt.)
Sollte der verwendete Rechner ein TPM (Trusted Platform Module) besitzen, wird der Schlüssel für die Windows Verschlüsselung in diesem hinterlegt, wodurch es erheblich schwieriger wird an diesen Schlüssel zu kommen. Außerdem wird um Bruteforce Angriffe zu erschweren, bei jeglichen Hashenfunktionen eine Schlüssel Ableitungsfunktion mit 128.000 Durchläufen verwendet.