Kürzliche Anforderung für einen Kunden war die Evaluierung einer sicheren VPN-Einwahl über einen zweiten Faktor ohne Einsatz von Drittsoftware oder Clients mit Windows-Boardmitteln.
Was haben wir in diesem Projekt gelernt?
Die Authentifizierung per EAP-TLS funktioniert, wenn die Zertifikate richtig generiert werden. SHA1-Zertifikate werden von den meisten VPN-Anbietern nicht mehr unterstützt (PFSENSE, bzw. strongswan seit 5.9.2¹)
TPM1.2-Module können kein SHA2 und sind auch beschränkt hinsichtlich der Schlüssellänge.
Unter Windows lässt sich zwar ein nicht unterstütztes Zertifikat in das TPM importieren oder in einen Yubikey oder Nitrokey, beim Verbindungsaufbau gibt es nur einen Mismatch.
VPN-GW logged nur spärlich
14[IKE] EAP method EAP_TLS failed for peer
Windows besitzt mehrere Crypto-Schnittstellen um Smartcards anzusprechen. Die alte Methode via CSP (crypto service provider) sowie die neuen Key Storage Provider².
Welche der eigene Rechner anbietet, zeigt:
certutil -csplist
Bei der Erzeugung von SSL-Zertifikate empfiehlt sich ein Containerformat PFX/PKCS12/P12, welches so direkt importiert werden kann.
openssl pkcs12 kennt den Schalter -CSP, um einem Zertifikat einen Provider aufzudrücken. Also den (angestaubten) CSP mit zu übergeben.
Bei den Smartcards ist Vorsicht geboten. Manche Hersteller kennzeichnen ihre Sticks als „CSP-tauglich“ und liefern eigene Smartcard-Treiber mit. Das ist der Idealfall und garantiert die beste Unterstützung.
Am Beispiel des Nitrokey ist zusätzliche Drittsoftware in Form OpenSC nötig um den Stick in die windows-nativen Anmeldevorgänge einzubinden wie z.B. für Windows Logon oder VPN. Der Nitrokey 2 Start hat keine CSP-Unterstützung und lässt sich somit nicht integrieren. Der PRO2 jedoch soll dies können. Ein Test steht noch aus.
Gut gefallen hat mir am Yubikey, dass sich mit der eigenen Anwendung mit wenigen Klicks ein Zertifikat importieren lässt. Das Windows certutil hat div. Beschränkungen hinsichtlich dem Import und der Darstellung von ECC-Keys.
Gut funktioniert haben generell die in der PFSense einfach zu generierenden Zertifikate. ECDSA 2048 mit prime256v1. So mags auch der Yubikey.
Es gibt hier sogar eine Default-Richtlinie unter Windows 10, die standardmäßig ECS-Schlüssel blockiert. Upload geht aber natürlich, was zu Verwirrung führt.
Ein vorhandener TPM-Chip kann als virtuelle Smartcard unter Windows verwenden werden. Setup mit
tpmvscmgr.exe create /name TestVSC /pin default /adminkey random /generate
Leider kann die virtuelle Smartcard nur SHA1 mit dem Base CSP. Andere CSP/KSP ich noch nicht probiert. Upload erfolgt mit
certutil -csp „Microsoft Base Smart Card Crypto Provider“ -importpfx F:\schluesselcontainer.p12
Löschen einer virtuellen Smartcard geht über device-manager oder manuell mit
tpmvscmgr.exe destroy /instance root\smartcardreader\0000
Hat man irgendwann den zweiten Faktor auf USB-Stick (Nitro/Yubi-key) oder im TPM, stellt man fest, dass Windows mit Boardmitteln (rechts unten klick, VPN – > Verbinden keine Smartcard-Unterstützung kennt, also den Dialog für die PIN nicht abfragen kann. Ist auch seit 2 Jahren als Bug³ bekannt.
Workaround ist das ganze über rasphone zu starten. Wenigstens kann der Windows-Anmeldeschirm die Pin-Abfrage.
¹ https://wiki.strongswan.org/projects/strongswan/wiki/592
² https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc730763(v=ws.10)?redirectedfrom=MSDN
³ https://answers.microsoft.com/en-us/windows/forum/all/virtual-smart-card-vpn-no-longer-working-after/46162f4c-0c95-4e5b-ba82-b064cd1d55a6