Virtuelle Smart Cards – geht das?

Smart Cards sind mit ihrer Hardware-basierten Sicherheit und den asymmetrischen kryptografischen Algorithmen die wohl sichersten 2FA-Möglichkeiten und mit Zertifikaten kann man noch digital signieren und hochsichere Verschlüsselungen realisieren. Hier sind Haben und Wissen so vereint, dass man keine Shared Secrets (Seeds oder Hashes) hinterlegen muss und den «Passcode» weder abfangen noch bewusst weitergeben kann. Die Identität wird auf Basis des Digital-Signing-Prinzips verifiziert. Das Verfahren ist schematisch (unter https://www.tec-bite.ch/smart-cards-what-happens-in-the-background) dargestellt. Auch die asymmetrische Verschlüsselung des Kerberos-Protokolls ist damit wesentlich sicherer.

Aktuelle Angriffe auf höhere Lehranstalten der Schweiz zeigen, dass auch interne Credentials sehr im Fokus der Hacker stehen und im Darknet gehandelt werden.

Warum sollte man nun auf den Gedanken kommen, diese Authentisierung zu virtualisieren?

• Organisatorischer Aufwand beim Versenden oder der Ausgabe der Credentials
• Smart Card Replacement on Demand
• Support auf Plattformen in denen, die Smart Card nicht nutzbar ist, etwa bei VDI-Umgebungen oder BYOD
• Post-Quantum Cryptography

Eigentlich ist das schon ein altes Thema.

Aladdin hatte schon vor über 15 Jahren mit dem eToken Virtual TMS 2.0 und dem eToken Rescue im TMS 5.0 eine Variante für zertifikatsbasierte Authentisierung, um den Verlust einer Smart Card oder des eToken temporär abzufedern.

Microsoft – Virtual Smart Card wurde dann zu «Windows Hello for Business» und die Keys liegen verbindlich im Trusted Plattform Module (TPM). Diebstahl der Keys wird so schon sehr schwierig.

Eine weitere Variante bietet Versasec mit ihrer Virtual Smart Card:

Und auch von Gemalto – heute Thales – kennen wir einen durchaus anspruchsvollen Ansatz. Hier liegen die privaten Schlüssel hochsicher in einer Datenbank, die mit einem Hardware Security Module (HSM) abgesichert ist und damit bleibt die Idee Hardware-basierten Sicherheit erhalten.  Aber dazu später mehr.

Um die Entwicklung darum wirklich zu verstehen, müssen wir vielleicht mal einen Schritt zurücktreten und uns die Anforderungen und Herausforderungen mit Smart Cards anschauen. Die Vorteile einer Smart Card als Zertifikatsträger sind oben genannt, aber es gibt dabei auch Herausforderungen und zusätzliche Anforderungen.

Wir brauchen eine PKI, die uns vertrauenswürdige Zertifikate erstellt und ab einer gewissen Grössenordnung auch eine Smart Card Management System – siehe «vSEC:CMS»-Artikel.

Die Logistik für das Verteilen, Erneuern – und bei Verlust das Ersetzen der Karten, inklusive der zuverlässigen Identifizierung der Besitzer – ist ein nicht zu unterschätzender Aufwand. Auch das Installieren und Aktualisieren der Middleware kann Zeit und Nerven kosten, wenn man an BYOD denkt.

Die operativen Aufgaben zum Entsperren oder Erneuern der Zertifikate sind dabei eher einfache und gut gelöste Aufgaben im Lifecycle einer Karte mit einem Smart Card Management.

Der Einsatz dieser Authentisierung ist auf den beliebten mobilen Geräten eine fast unmögliche Herausforderung. Nicht nur wegen des fehlenden Smart Card Slots. NFC gibt es auch für Smart Cards schon lange. Nur müsste der Zugang freigeschalten sein. Dieser ist auch bei iOS-Geräten noch immer eingeschränkt. Die Verwendung der Smart Cards über einen separaten Bluetooth Reader war nicht von Erfolg geprägt.

Zertifikate auf dem mobilen Gerät ablegen geht schon, aber der Schutz des Private Keys ist nicht mit einer Smart Card zu vergleichen. Leider. Dabei würde es doch zumindest auf einigen Geräten vergleichbare Chips für Hardware-basierte Sicherheit geben, wobei dann das Access Device und das Authentication Device nicht getrennt wären.

Ähnliche Herausforderungen stellen sich teilweise mit VDI-Lösungen. Und bei diesen verschiedenen Szenarien kann eine Virtualisierung der Smart Card ein Segen sein.

Es scheitert auch an einer generellen Schnittstelle, welche für Apps prädestiniert wäre, um die kryptografischen Prozesse sicher zu nutzen. Die Apps müssen auch entsprechend programmiert sein.

Hier verlässt man sich auf FIDO2 und die rein Key-basierte Authentication ohne Trust, Validity, Revocation, Subject … Womit man auf eine PKI verzichten kann. Hatte man das nicht als einen Mangel bei SSH-Key-based Authentication identifiziert?

Das ist nun einmal für den Consumer-Markt konzipiert und es muss beim Einsatz im Unternehmensumfeld optimiert werden.

Um einige dieser Challenges anzugehen und dennoch ein möglichst hohes Sicherheitsniveau zu gewährleisten, könnte man nun die virtuelle Karte via Netzwerk zur Verfügung stellen.

Also wir legen die Keys in einer DB ab, die mit einem HSM abgesichert ist und regeln den Zugriff für die Benutzer mit einem zentralen Identity Provider (IdP). Wenn der IdP nun die Authentisierung mit einem FIDO-Geräte unterstützt sind beide Steps (Authentisierung via IdP und die Smart-Card-Operation asymmetrisch). Bei einer Authentisierung mit OTP oder anderem fallen wir in diesem Punkt auf symmetrische Sicherheit zurück. Hier ist also eine Access Policy wichtig, die regelt, für welchen Verwendungszwecke welche Authentisierung gefordert wird, aber die Karte mit dem Zertifikat wäre im Falle eines Verlustes «on Demand» verfügbar. Wenn das Gerät – ein zertifikatsbasiertes Windows Logon – oder die VDI-Maschine keine Smart Cards unterstützt, wäre auch dafür eine Lösung gegeben.

Das HSM anzugreifen, ist wohl eher das Letzte, was man versuchen würde; alle anderen Steps muss man genauer betrachten, um die Sicherheit hochzuhalten: Ganz nach dem Motto: «Secure the Weakest Link».

Damit erweitern wir die Verfügbarkeit der Smart Cards und gerade für alle Digital Natives und bei den Firmen wäre eine grosse Herausforderung an die Logistik adressiert.

Vor allem die digitale Unterschrift (Digital Signing) von E-Mails oder Dokumenten lässt sich so auch ohne eine physische Karte abbilden und ist nicht mit OTP-Verfahren oder FIDO zu ersetzen. Und ja, es gibt auch die Möglichkeit, Zertifikate für E-Mail Signing und Encryption auf einem Gateway zu hosten, aber dann genau für diesen Verwendungszweck. Logon bei Windows für Unternehmen lässt sich hingegen noch nicht mit FIDO abbilden.

Mit den Steps als Beschreibung zum Ablauf:

1. Rot – Enrollment des FIDO Tokens – hier könnte auch das Card Management von Versasec und die Lösung SafeNet Trusted Access von Thales helfen.
2. Grün – Authentication mit dem FIDO Token am Identity Provider (IdP)
3. Blau – Access Virtual IDPrime Virtual Service (IDPV) – Smart Card verfügbar
4. Purple – Das Card Management kann auch zur Verwaltung und zum Enrollment des Zertifikats verwendet werden.

Für den Zugriff auf die Smart Card braucht man folgende Komponenten: Als Middleware wir der altbekannte SafeNet Authentication Client (SAC) verwendet. Als Quasi-Smart-Card-Reader «over the Net» wird der IDPV-Client verwendet, der also die Kommunikation zum IDPV-Service realisiert. Zur Authentisierung für diesen Zugriff wird jetzt der Identity Provider (IdP) via SAML bemüht. Wie die Authentisierung dort erfolgt, also mit welchem Authenticator und welche Access-Regeln dort definiert sind, ist die Aufgabe des IdPs. Im Falle von SafeNet Trusted Access sind verschiedenste Möglichkeiten bis zu FIDO2 mit entsprechenden Access-Regeln geboten.

Damit der User diese Möglichkeit nutzen kann, ist das Enrollment manuell oder automatisiert via Versasecs «vSEC:CMS» möglich. Nun brauchen wir natürlich noch ein Zertifikat auf unserer virtuellen Smart Card. Der SAC lässt sich hier wie gewohnt verwenden und auch hier ist ein manueller Import möglich, aber auch hier kann der «vSEC:CMS» für das Enrollment der Zertifikate von der definierten Zertifizierungsstelle der internen PKI oder auch von externen Trust Centern.

Für Offline-Verwendungen kann das Zertifikat im TPM des Clients abgelegt werden.

Das Zertifikat kann dann wie mit einer physischen Karte, wie gewohnt, verwendet werden.

So wird die Sache rund.

Es ist eine komplexe Struktur mit einigen Komponenten, aber eine sichere Basis für zertifikatsbasierte Anwendungsfälle, ohne Abstriche an der Sicherheit, on Demand verfügbar, wenn der User das benötigt, ohne Organisation des Shippings und der Verifizierung der User vor Ort.

Wer eine wirklich sichere Authentisierung benötigt, muss den Aufwand betreiben, eine Smart Card in Form einer ID-1 Card oder eines USB-Tokens als Zertifikatsträger zu betreiben. Die Kombination mit weiteren Einsatzzwecken, wie beim Sichtausweis, der Bezahlung in der Cafeteria, dem Gebäudezutritt, der Zeiterfassung, dem Secure Printing haben usw., haben wir schon öfters betrachtet … Und der ganze Aufwand ergibt Sinn.

Das Sicherheitsniveau und der zu betreibende Aufwand müssen aber festlegt werden und stehen immer im Kontext des zeitlichen und finanziellen Aufwands. Da kann es durchaus Sinn ergeben, wenigstens asymmetrische Verfahren wie FIDO2 im Kontext mit Cloud-Lösungen zu verwenden, weil diese nur dies unterstützen oder auch virtuelle Smart-Card-Systeme in Betracht zu ziehen, um die Verfügbarkeit asymmetrischer Verfahren zum Beispiel für das Signieren von Dokumenten, E-Mails oder auch zertifikatsbasierten Authentisierungen auf Plattformen ohne Smart Card Support zu bieten.

Im ersten Schritt erfolgt die Authentifizierung per Open ID Connect (OIDC) an einem entsprechenden Identity Provider (IDP) wie beispielsweise SafeNet Trusted Access (STA). Nach erfolgreicher Multi-Faktor-Authentisierung (MFA) entsprechend der dort hinterlegten Anmelderichtlinien erhält der User Zugriff auf den IDPV Server, der dessen virtuelle Smart Card bzw. die zugehörigen Keys auf dem HSM mit seinem Client verknüpft. Die virtuelle Smart Card wird transparent im Betriebssystem eingeblendet. Aus OS-Sicht ist dies identisch mit dem Einlegen einer physischen Smart Card in den Reader.

Nun kann der Anwender die auf der virtuellen Karte gespeicherten Zertifikate für nachfolgende Anmeldungen, digitale Signatur oder die Verschlüsselung seiner E-Mails verwenden. Sobald dafür der Zugriff auf die Private Keys erforderlich ist, muss der User sich durch Eingabe seiner PIN an der Karte nochmals authentifizieren. Die eigentliche Krypto-Operation wird dann über das Netzwerk an das HSM geschickt, mit dem dort liegenden Private Key des Anwenders ausgeführt und das Ergebnis zurück an den Client geschickt.

Die Sicherheit des Gesamtsystems hängt dabei von der Sicherheit der Authentifizierung am IDP sowie der PIN der virtuellen Karte ab. Wenn der User die Karte an einem anderen System benötigt, dann kann er diese mit dem neuen Client verbinden. Sie folgt also dem User entsprechend seiner Anmeldung an weiteren Systemen.

Weitere Flexibilität ermöglichen dabei Optionen wie ein IDPV Credential Provider, der die Verbindung zur Virtual Smart Card vor dem Windows Logon durchführen kann, um danach eine zertifikatsbasierte Anmeldung bei Windows durchführen zu können. Auch eine Offline-Nutzung ist möglich, indem die virtuelle Smart Card für eine limitierte Zeitspanne auf dem TPM des Windows Clients gespeichert werden kann.

www.avantec.ch/loesungen/thales

www.tec-bite.ch/passwordless-authentication-or-normal-it-madness

www.tec-bite.ch/kryptoanalyse-das-brechen-einer-verschluesselung

www.tec-bite.ch/smart-card-ein-kleines-kunstwerk

www.tec-bite.ch/cyber-security-ist-teuer-auch-gleich-besser

www.tec-bite.ch/quantensichere-kryptographie-von-mathematischer-theorie-zu-konkreten-standards

www.tec-bite.ch/key-length-versus-life-time