Kryptographische Härtung der SCEP-Transaktionen für den Registrierungsdienst für Netzwerkgeräte (Network Device Enrollment Service, NDES)

Das Simple Certificate Enrollment Protocol (SCEP) ist ein uraltes Protokoll aus den frühen 2000ern. Es kommt ohne Transport Layer Security (TLS) aus. Daher werden die Protokollnachrichten auf Transportebene verschlüsselt.

Beim Senden der Zertifikatanforderung an den NDES-Server wird der Client den Zertifikatantrag mit dem CEP-Encryption Zertifikat des NDES-Servers (wurde ihm über die GetCACert Nachricht zuvor kommuniziert) vornehmen.

Beim Empfangen des ausgestellten Zertifikats wird der NDES-Server die Antwort mit einem temporär vom SCEP-Client erstellten selbstsignierten Zertifikat verschlüsseln.

In beiden Fällen kommt ein symmetrischer Verschlüsselungsalgorithmus zum Einsatz.

Die möglichen Capabilities sind in RFC 8894 für SCEP definiert und werden dem SCEP-Client über die "GetCACaps" Operation mitgeteilt.

Capability	Beschreibung
AES	Unterstützung von Advanced Encryption Standard (AES128-CBC).
DES3	Unterstützung von Triple Data Encryption Standard (3DES-CBC).
GetNextCACert	Für Rollover von Zertifizierungsstellen-Zertifikaten. Nicht von NDES unterstützt.
POSTPKIOperation	Durchführen der Operationen via HTTP POST anstelle GET.
Renewal	Erneuern eines Zertifikats unter Verwendung eines bereits vorhandenen.
SHA-1	Unterstützung des SHA-1 Hashalgorithmus.
SHA-256	Unterstützung des SHA-256 Hashalgorithmus.
SHA-512	Unterstützung des SHA-512 Hashalgorithmus.
SCEPStandard	Indiziert, dass der Server alle verpflichtend zu implementierenden SCEP-Standard-Operationen gemäß RFC unterstützt. Hierzu zählen unter anderem "AES", "POSTPKIOperation", und "SHA-256".

Standardeinstellung von NDES

NDES kommuniziert im Auslieferungszustand folgende Capabilities an SCEP-Clients:

POSTPKIOperation
Renewal
SHA-512
SHA-256
SHA-1
DES3

Die Capabilities kann man per Browser oder PowerShell vom NDES-Server abfragen.

Invoke-WebRequest -Uri "http://localhost/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACaps"

Wie man sieht, fehlt hier der modernere AES Algorithmus. Wir wollen im Folgenden NDES dazu bringen, diesen mit anzubieten.

Im SCEP-Standard ist nur der AES-CBC Algorithmus mit 128 Bit spezifiziert. Theoretisch könnten SCEP-Clients auch andere Algorithmen verwenden. Es gibt aber keine entsprechend standardisierten Capabilities.

Ändern der Standardeinstellungen

Wichtig zu verstehen ist, dass wir mit den Capabilities lediglich kommunizieren, welche Algorithmen der NDES-Server auf alle Fälle versteht. Clients müssen sich nicht an die propagierten Capabilities halten. NDES wird bereits im Auslieferungszustand alle Algorithmen von RC2 bis AES akzeptieren. Angenommen, dass die Clients die propagierten Capabilities verstehen und anwenden, können wir immerhin erreichen, dass AES anstelle 3DES von Clients verwendet wird. Erzwingen können wir jedoch nichts.

Konfiguriert werden können die propagierten Capabilities mit folgendem Registry-Schlüssel auf dem NDES-Server:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\MSCEP\CACapabilitiesAlgorithms

Im Auslieferungszustand von NDES ist dieser Registrierungsschlüssel nicht vorhanden. Er kann mit folgendem Befehl (mit Standardeinstellungen) erstellt werden:

certutil -f -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms "SHA-512\nSHA-256\nSHA-1\nDES3"

Die "POSTPKIOperation" und "Renewal" Operationen sind nicht konfigurierbar, somit müssen und können sie nicht per Registry gesetzt werden.

Um Beispielsweise die Unterstützung für Advanced Encryption Standard (AES) hinzuzufügen:

certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms +AES

Die Werte werden als einfache Strings in der Registry hinterlegt und so auch ausgegeben. Daher muss man unbedingt auf die korrekte Schreibweise (wie im RFC 8894 definiert) achten.

Um Beispielsweise die Unterstützung für Triple DES und SHA-1 zu entfernen:

certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms -DES3
certutil -setreg mscep\CACapabilitiesAlgorithms\CACapabilitiesAlgorithms -"SHA-1"

Das Entfernen von 3DES und SHA-1 sollte wohlüberlegt sein, da es als Fallback für Clients verwendet werden kann, die kein AES verstehen. Entfernt man diese Capabilities, verwenden Clients unter Umständen noch schwächere Algorithmen. Sie sollten am Besten unterhalb stärkerer Algorithmen platziert werden.

Nach erfolgter Änderung muss der NDES-Dienst neu gestartet werden. Am einfachsten kann das durch Neustart des IIS-Dienstes erfolgen.

iisreset

Clientseitiges Verhalten

Wie sich SCEP-Clients verhalten, hängt von der konkreten Implementierung ab.

Bei manchen SCEP-Clients (z.B. Blackberry Enterprise Mobility Suite) kann man die Verwendung bestimmter Algorithmen konfigurieren (die angebotenen Capabilities des NDES-Servers werden dann in der Regel ignoriert).

SCEP-Clients, welche die Windows-APIs nutzen (beispielsweise Microsoft Intune, certutil oder PSCertificateEnrollment), werten die vom NDES-Server angebotenen Capabilities von oben nach unten aus und verwenden den ersten Hashalgorithmus sowie Verschlüsselungsalgorithmus aus der Liste, der vom öffentlichen Schlüssel des Client unterstützt wird. Welche das sind, hängt davon an, welcher Algorithmus und welcher CSP/KSP für den Zertifikantrag verwendet wurde.

Aber Vorsicht! Wenn ein Client keinen der angebotenen Algorithmen unterstützt, macht er einen Fallback auf etwas, das der zugrundeliegende CSP/KSP versteht! Mehr dazu im Folgenden.

Funktionstest

Nachdem wir unsere Änderungen vorgenommen haben, sollten wir die Funktion des NDES-Dienstes überprüfen. Eine vollständige Anleitung hier findet sich im Artikel "Funktionstest durchführen für den Registrierungsdienst für Netzwerkgeräte (NDES)".

Wir konzentrieren uns auf die tatsächliche Beantragung eines Zertifikats per SCEP. Das können wir bequem mit dem PSCertificateEnrollment PowerShell Modul vornehmen. Es fragt die Capabilities des NDES-Servers ab und wendet sie entsprechend beim Zertifikatantrag an.

Wichtig fürs Verständnis ist hier, dass PSCertificateEnrollment für das Schlüsselpaar des Zertifikatantrags in der Standardeinstellung den "Microsoft Software Key Storage Provider" verwendet, der sowohl 3DES als auch AES versteht.

$otp = Get-NDESOTP -ComputerName NDES01.intra.adcslabor.de
Get-NDESCertificate `
  -Subject "CN=hello" `
  -ChallengePassword $otp `
  -ComputerName "NDES01.intra.adcslabor.de"

Da SCEP in der Standardeinstellung mit unverschlüsseltem HTTP arbeitet, können wir mit Wireshark in die Kommunikation schauen und die SCEP-Nachricht extrahieren.

Wir können diese nun mit dem ASN.1 Editor von Vadims Podans öffnen und uns die innere PKCS7 Nachricht ansehen.

Mit den Standardeinstellung von NDES werden wir hier "3des" als Verschlüsselungsalgorithmus für die PKCS7 Enveloped Data erkennen.

Nach der Umstellung der Capabilities sollten wir erkennen, dass nun "aes128-CBC" steht.

Fallstricke

Welche Verschlüsselung tatsächlich verwendet wird, hängt von mehreren Faktoren ab.

Schlüsselspeicher-Anbieter des beantragenden Clients muss passen

NDES erzwingt keinen bestimmten Algorithmus. Clients kommen selbst mit völlig veralteten Algorithmen durch.

Zum Testen erzeugen wir unser Schlüsselpaar auf dem Client einmal mit dem (nicht empfohlenen!) Microsoft Base Cryptographic Provider v1.0, der weder 3DES noch AES versteht.

$otp = Get-NDESOTP -ComputerName NDES01.intra.adcslabor.de
Get-NDESCertificate `
  -Subject "CN=hello" `
  -ChallengePassword $otp `
  -ComputerName "NDES01.intra.adcslabor.de" `
  -Ksp "Microsoft Base Cryptographic Provider v1.0"

Nun sehen wir, dass die Nachricht mit dem RC2 Algorithmus verschlüsselt wurde. NDES nimmt diese Nachricht an und verarbeitet diese problemlos.

Schlüsselspeicher-Anbieter des NDES-Servers muss passen

Auch der Schlüsselspeicher des NDES-Servers (genauer gesagt – des verwendeten CEP Encryption Zertifikats) muss die verwendeten Algorithmen versehen.

Das klingt erst einmal widersinnig – denn NDES unterstützt lediglich Cryptographic Service Provider (CSP), von denen nur wenige über Unterstützung für 3DES oder gar AES verfügen.

Wird allerdings ein Microsoft Software-CSP verwendet, wird die CryptoAPI (CAPI2) des NDES-Servers den Schlüssel des CEP-Encryption Zertifikats transparent als NCrypt-Schlüssel öffnen um die Operation durchzuführen.

Wird hingegen der Cryptographic Service Provider eines Drittanbieters (etwa wenn für NDES ein Hardware Security Modul eingesetzt wird) verwendet, ist dies nicht möglich. Wenn der 3rd Party CSP die entsprechenden Algorithmen nicht implementiert hat, können sie nicht mit NDES genutzt werden.

Schlägt ein SCEP-Zertifikatantrag aus diesem Grund fehlt, wird NDES das Ereignis mit ID 18 der Quelle Microsoft-Windows-NetworkDeviceEnrollmentService protokollieren. Auf Clientseite wird man den Fehlercode 0x80090005 (-2146893819 NTE_BAD_DATA) vom NDES-Server kommuniziert bekommen.