Kryptografische Empfehlungen für Microsoft SDL

  • Artikel

Einführung

Dieses Dokument enthält Empfehlungen und bewährte Methoden für die Verwendung der Verschlüsselung auf Microsoft-Plattformen. Ein Teil der Inhalte hier ist paraphrasiert oder aggregiert aus den internen Sicherheitsstandards von Microsoft, die zum Erstellen des Sicherheitsentwicklungslebenszyklus (Security Development Lifecycle, SDL) verwendet werden. Es soll als Referenz beim Entwerfen von Produkten verwendet werden, um die gleichen APIs, Algorithmen, Protokolle und Schlüssellängen zu verwenden, die Microsoft für seine eigenen Produkte und Dienste benötigt.

Entwickler auf Nicht-Windows-Plattformen können ebenfalls von diesen Empfehlungen profitieren. Obwohl die API- und Bibliotheksnamen unterschiedlich sein können, sind die bewährten Methoden für Algorithmusauswahl, Schlüssellänge und Datenschutz plattformübergreifend ähnlich.

Empfehlungen zu Sicherheitsprotokoll, Algorithmus und Schlüssellänge

SSL/TLS-Versionen

Produkte und Dienste sollten kryptografisch sichere Versionen von SSL/TLS verwenden:

  • TLS 1.2 muss aktiviert sein.

  • TLS 1.1 und TLS 1.0 sollten nur aus Gründen der Abwärtskompatibilität aktiviert werden.

  • SSL 3 und SSL 2 sollten standardmäßig deaktiviert sein

Symmetrische Blockchiffren, Verschlüsselungsmodi und Initialisierungsvektoren

Blockchiffren

Für Produkte mit symmetrischen Blockchiffren:

  • Für neuen Code ist Advanced Encryption Standard (AES) erforderlich.

  • 3DES (Triple Data Encryption Standard) mit drei Schlüsseln ist in vorhandenem Code für die Abwärtskompatibilität zulässig.

  • Alle anderen Blockchiffren, z. B. RC2, DES, 3DES mit zwei Schlüsseln, DESX und Skipjack, dürfen nur zum Entschlüsseln von alten Daten verwendet und müssen nach der Verwendung für die Verschlüsselung ausgetauscht werden.

Für Algorithmen zur Verschlüsselung symmetrischer Blöcke ist für Schlüssel eine Mindestlänge von 128 Bit erforderlich. Der einzige für neuen Code empfohlene Blockverschlüsselungsalgorithmus ist AES (AES-128, AES-192 und AES-256 sind akzeptabel, da AES-192 bei einigen Prozessoren nicht optimiert werden kann). 3DES mit drei Schlüsseln ist derzeit akzeptabel, wenn dieses Verfahren im vorhandenen Code bereits verwendet wird. Die Umstellung auf AES wird aber empfohlen. DES, DESX, RC2 und Skipjack werden nicht mehr als sicher angesehen. Diese Algorithmen dürfen nur aus Gründen der Abwärtskompatibilität zum Entschlüsseln von vorhandenen Daten verwendet werden und Daten sollten mit einem empfohlenen Blockchiffre neu verschlüsselt werden.

Verschlüsselungsmodi

Symmetrische Algorithmen können in einer Vielzahl von Modi verwendet werden, von denen die meisten die Verschlüsselungsvorgänge für aufeinander folgende Klartext- und Chiffretextblöcke miteinander verknüpfen.

Symmetrische Blockchiffren sollten mit einem der folgenden Verschlüsselungsmodi verwendet werden:

Einige andere Verschlüsselungsmodi, z. B. die unten aufgeführten, weisen Implementierungsfehler auf, welche die Wahrscheinlichkeit einer falschen Verwendung erhöhen. Insbesondere sollte der Betriebsmodus Electronic Code Book (ECB) vermieden werden. Die Wiederverwendung des gleichen Initialisierungsvektors (IV) mit Blockchiffren in „Streaming-Chiffremodi“, z. B. CTR, kann dazu führen, dass verschlüsselte Daten offengelegt werden. Eine zusätzliche Sicherheitsprüfung wird empfohlen, wenn einer der folgenden Modi verwendet wird:

  • Ausgabefeedback (OFB)

  • Chiffren-Feedback (CFB)

  • Leistungsindikator (Counter, CTR)

  • Leistungsindikator mit CBC-MAC (CCM)

  • Galois/Counter-Modus (GCM)

  • Alles andere, was nicht in der obigen Liste als „empfohlen“ enthalten ist

Initialisierungsvektoren (IV)

Alle symmetrischen Blockchiffren sollten auch mit einer kryptografisch starken Zufallszahl als Initialisierungsvektor verwendet werden. Initialisierungsvektoren sollten nie ein konstanter Wert sein. Empfehlungen zum Generieren kryptografisch starker Zufallszahlen finden Sie unter Zufallszahlengeneratoren.

Initialisierungsvektoren sollten nie wiederverwendet werden, wenn mehrere Verschlüsselungsvorgänge ausgeführt werden, da dadurch Informationen zu den verschlüsselten Daten offengelegt werden können, insbesondere bei Verwendung von Streaming-Chiffrierungsmodi wie Ausgabefeedback (Output Feedback, OFB) oder Leistungsindikator (CTR).

Asymmetrische Algorithmen, Schlüssellängen und Auffüllmodi

RSA

  • RSA kann für die Verschlüsselung, den Schlüsselaustausch und Signaturen verwendet werden.

  • RSA-Verschlüsselung sollte die OAEP oder RSA-PSS-Auffüllmodi verwenden. Vorhandener Code sollte nur aus Kompatibilitätsgründen den Auffüllmodus PKCS #1 v1.5 verwenden.

  • Die Verwendung von Null-Auffüllung wird nicht empfohlen.

  • Schlüssel > = 2048 Bits werden empfohlen

ECDSA

  • ECDSA mit > = 256-Bit-Schlüsseln wird empfohlen

  • ECDSA-basierte Signaturen sollten eine der drei von NIST genehmigten Kurven (P-256, P-384 oder P521) verwenden.

ECDH

  • ECDH mit > = 256-Bit-Schlüsseln wird empfohlen.

  • Für ECDSA-basierte Signaturen muss eine der drei Kurven mit NIST-Genehmigung genutzt werden (P-256, P-384 oder P521).

Integer Diffie-Hellman

  • Schlüssellänge > = 2048 Bits wird empfohlen

  • Die Gruppenparameter sollten entweder eine bekannte benannte Gruppe (z. B. RFC 7919) sein oder von einer vertrauenswürdigen Partei generiert und vor der Verwendung authentifiziert werden.

Schlüssellebensdauer

  • Alle asymmetrischen Schlüssel müssen eine maximale Gültigkeitsdauer von fünf Jahren haben. Die empfohlene Gültigkeitsdauer ist ein Jahr.

  • Alle symmetrischen Schlüssel müssen eine maximale Gültigkeitsdauer von drei Jahren haben. Die empfohlene Gültigkeitsdauer ist ein Jahr.

  • Sie sollten einen Mechanismus oder einen Prozess zum Ersetzen von Schlüsseln bereitstellen, um die begrenzte aktive Lebensdauer zu erreichen. Nach Dem Ende seiner aktiven Lebensdauer sollte ein Schlüssel nicht verwendet werden, um neue Daten zu erzeugen (z. B. für Verschlüsselung oder Signierung), sondern kann weiterhin zum Lesen von Daten verwendet werden (z. B. für die Entschlüsselung oder Überprüfung).

Zufallszahlengenerator

Alle Produkte und Dienste sollten kryptografisch sichere Zufallszahlengeneratoren verwenden, wenn Zufallszahlen erforderlich sind.

CNG

  • Verwenden Sie BCryptGenRandom mit dem Flag BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

Win32/64

.NET

Windows Store-Apps

Nicht empfohlen

  • Unsichere Funktionen in Zusammenhang mit Zufallsnummerngeneration umfassen rand,System.Random (.NET), GetTickCount und GetTickCount64

  • Die Verwendung des Dual Elliptic Curve Random Number Generator Algorithmus („DUAL_EC_DRBG“) wird nicht empfohlen.

Von der Windows-Plattform unterstützte Kryptografiebibliotheken

Auf der Windows-Plattform empfiehlt Microsoft die Verwendung der in das Betriebssystem integrierten Kryptografie-APIs. Auf anderen Plattformen können Entwickler entscheiden, nicht plattformspezifische Kryptografiebibliotheken für die Verwendung auszuwerten. Im Allgemeinen werden Plattform-Kryptografiebibliotheken häufiger aktualisiert, da sie als Teil eines Betriebssystems geliefert werden, anstatt mit einer Anwendung gebündelt zu werden.

Jede Nutzungsentscheidung in Bezug auf Plattform- und Nicht-Plattform-Kryptografie sollte von den folgenden Anforderungen geleitet werden:

  1. Die Bibliothek sollte eine aktuelle unterstützte Version ohne bekannte Sicherheitsrisiken sein.

  2. Die neuesten Sicherheitsprotokolle, Algorithmen und Schlüssellängen sollten unterstützt werden.

  3. (Optional) Die Bibliothek sollte nur aus Gründen der Abwärtskompatibilität ältere Sicherheitsprotokolle bzw. Algorithmen unterstützen können.

Nativer Code

  • Kryptografie-Pimitives: Wenn Ihr Release unter Windows oder Windows Phone ist, verwenden Sie nach Möglichkeit CNG. Verwenden Sie andernfalls die CryptoAPI (auch als CAPI bezeichnet, die ab Windows Vista als Legacykomponente unter Windows unterstützt wird).

  • SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2 oder IXMLHTTPRequest3.

    • WinHTTP-Apps sollten mit WinHttpSetOptionerstellt werden, um TLS 1.2 zu unterstützen.

  • Überprüfung der Codesignatur: WinVerifyTrust ist die unterstützte API zum Überprüfen von Codesignaturen auf Windows-Plattformen.

  • Zertifikatüberprüfung (wie bei der eingeschränkten Zertifikatüberprüfung für die Codesignatur oder SSL/TLS/DTLS): CAPI2-API, Beispiel: CertGetCertificateChain und CertVerifyCertificateChainPolicy

Verwalteter Code

  • Kryptografie-Primitives: Verwenden Sie die im System.Security.Cryptography-Namespace definierte API – die CNG-Klassen werden bevorzugt.

  • Verwenden Sie die neueste verfügbare Version von .NET Framework. Dies sollte mindestens .NET Framework Version 4.6 sein. Wenn eine ältere Version erforderlich ist, stellen Sie sicher, dass der Regkey „SchUseStrongCrypto“ so festgelegt ist, dass TLS 1.2 für die in Frage kommende Anwendung aktiviert ist.

  • Zertifikatüberprüfung: Verwenden Sie APIs, die unter dem Namespace System.Security.Cryptography.X509Certificates definiert sind.

  • SSL/TLS/DTLS: Verwenden Sie APIs, die unter dem System.Net-Namespace definiert sind (z. B. HttpWebRequest).

Schlüsselableitungsfunktionen

Schlüsselableitung ist der Prozess der Ableitung von kryptografischem Schlüsselmaterial von einem gemeinsamen Geheimnis oder einem vorhandenen kryptografischen Schlüssel. Produkte sollten empfohlene Schlüsselableitungsfunktionen verwenden. Das Ableiten von Schlüsseln von vom Benutzer ausgewählten Kennwörtern oder das Hashing von Kennwörtern zum Speichern in einem Authentifizierungssystem ist ein Sonderfall, der in diesem Leitfaden nicht behandelt wird. Entwickler sollten sich an einen Experten wenden.

Die folgenden Standards geben KDF-Funktionen an, die zur Verwendung empfohlen werden:

  • NIST SP 800-108: Empfehlung zur Schlüsselableitung mit Pseudozufallsfunktionen. Insbesondere die KDF im Indikatormodus mit HMAC als Pseudozufallsfunktion

  • NIST SP 800-56A (Revision 2): Empfehlung für paarweise Schlüsseletablierungs-Schemata mit Kryptografie über diskrete Logarithmen. Insbesondere wird die „Einzelschritt-Schlüsselableitungsfunktion“ in Abschnitt 5.8.1 empfohlen.

Verwenden Sie zum Ableiten von Schlüsseln aus vorhandenen Schlüsseln die BCryptKeyDerivation-API mit einem der folgenden Algorithmen:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Verwenden Sie die BCryptDeriveKey-API mit einem der folgenden Algorithmen, um Schlüssel von einem gemeinsam verwendeten Geheimnis (der Ausgabe einer Schlüsselvereinbarung) abzuleiten:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

Zertifikatüberprüfung

Anwendungen, die SSL, TLS oder DTLS verwenden, müssen die X.509-Zertifikate der Entitäten, mit denen sie eine Verbindung herstellen, umfassend überprüfen. Dazu gehört das Verifizieren der Zertifikate:

  • Domain name.

  • Gültigkeitsdaten (Anfangs- und Ablaufdatum).

  • Sperrstatus.

  • Verwendung (beispielsweise „Serverauthentifizierung“ bei Servern und „Clientauthentifizierung“ bei Clients)

  • Vertrauenskette Zertifikate müssen mit einer Stammzertifizierungsstelle (Certification Authority, CA) verkettet sein, die von der Plattform als vertrauenswürdig eingestuft wird oder vom Administrator explizit konfiguriert wurde.

Wenn einer dieser Überprüfungstests fehlschlägt, sollte das Produkt die Verbindung mit der Entität beenden.

Clients, die „selbstsignierten“ Zertifikaten vertrauen (z. B. ein E-Mail-Client, der in einer Standardkonfiguration eine Verbindung mit einem Exchange-Server herstellt), ignorieren möglicherweise Prüfungen der Zertifikatverifizierung. Selbstsignierte Zertifikate vermitteln jedoch nicht grundsätzlich Vertrauen, Unterstützungssperren oder die Erneuerung von Supportschlüsseln. Sie sollten selbstsignierten Zertifikaten nur vertrauen, wenn Sie sie von einer anderen vertrauenswürdigen Quelle erhalten haben (z. B. eine vertrauenswürdige Entität, die das Zertifikat über einen authentifizierten und integritätsgeschützten Transport bereitstellt).

Kryptografische Hashfunktionen

Produkte sollten die SHA-2-Familie von Hashalgorithmen (SHA256, SHA384 und SHA512) verwenden. Das Kürzen von kryptografischen Hashes auf weniger als 128 Bit aus Sicherheitsgründen ist nicht zulässig.

MAC-, HMAC- und schlüsselgebundenen Hashalgorithmen

Ein Nachrichtenauthentifizierungscode (Message Authentication Code, MAC) ist ein Informationselement, das an eine Nachricht angefügt ist. Hiermit kann der Empfänger sowohl die Echtheit des Absenders als auch die Integrität der Nachricht anhand eines geheimen Schlüssels überprüfen.

Die Verwendung von hashbasiertem MAC (HMAC) oder auf Blockchiffren basierendem MAC ist empfohlen, sofern auch alle zugrunde liegenden Hash- oder symmetrischen Verschlüsselungsalgorithmen zur Verwendung empfohlen sind. Dies gilt derzeit für die HMAC-SHA2-Funktionen (HMAC-SHA256, HMAC-SHA384 und HMAC-SHA512).

Eine Kürzung von HMACs auf weniger als 128 Bit ist nicht zulässig.

Überlegungen zu Entwurf und Betrieb

  • Sie sollten einen Mechanismus bereitstellen, um kryptografische Schlüssel nach Bedarf zu ersetzen. Schlüssel sollten ersetzt werden, sobald sie das Ende ihrer aktiven Lebensdauer erreicht haben oder wenn der kryptografische Schlüssel kompromittiert ist. Wenn Sie ein Zertifikat erneuern, sollten Sie es mit einem neuen Schlüssel erneuern.

  • Produkte, die kryptografische Algorithmen zum Schutz von Daten verwenden, sollten genügend Metadaten zusammen mit diesen Inhalten enthalten, um die zukünftige Migration zu verschiedenen Algorithmen zu unterstützen. Dies sollte den verwendeten Algorithmus, Schlüsselgrößen, Initialisierungsvektoren und Abstandsmodi umfassen.

  • Sofern verfügbar sollten eingerichtete Produkte von der Plattform bereitgestellte kryptografische Protokolle verwenden, anstatt sie erneut zu implementieren. Dies schließt Signaturformate ein (z. B. verwenden Sie ein standardisiertes, vorhandenes Format).

  • Symmetrische Stream-Chiffren, z.B. RC4, dürfen nicht verwendet werden. Anstelle von symmetrischen Streamchiffren sollte für Produkte ein Blockchiffre verwendet werden (AES mit einer Schlüssellänge von mindestens 128 Bit).

  • Melden Sie keine Fehler bei kryptografischen Vorgängen an Endbenutzer. Verwenden Sie beim Zurückgeben eines Fehlers an einen Remoteaufrufer (z. B. Webclient oder Client in einem Client-Server-Szenario) nur eine generische Fehlermeldung.

    • Vermeiden Sie das Bereitstellen unnötiger Informationen, z. B. das direkte Melden von Fehlern, die nicht im gültigen Bereich liegen oder ungültig sind. Protokollieren Sie ausführliche Fehler nur auf dem Server, und nur, wenn die ausführliche Protokollierung aktiviert ist.

  • Eine zusätzliche Sicherheitsüberprüfung wird dringend für jeden Entwurf empfohlen, der Folgendes enthält:

    • Ein neues Protokoll, das sich hauptsächlich auf die Sicherheit konzentriert (z. B. ein Authentifizierungs- oder Autorisierungsprotokoll).

    • Ein neues Protokoll, das Kryptografie in einer neuen oder nicht standardmäßigen Weise verwendet. Dies umfasst u. a. folgende Überlegungen:

      • Wird ein Produkt, welches das Protokoll implementiert, Krypto-APIs oder -Methoden als Teil der Protokollimplementierung aufrufen?

      • Hängt das Protokoll von einem anderen Protokoll ab, das für die Authentifizierung oder Autorisierung verwendet wird?

      • Definiert das Protokoll Speicherformate für kryptografische Elemente, z. B. Schlüssel?

  • Selbstsignierte Zertifikate werden für Produktionsumgebungen nicht empfohlen. Das Verwenden eines selbstsigniertes Zertifikats, z. B. die Verwendung eines kryptografischen Rohschlüssels, bietet Benutzern oder Administratoren grundsätzlich keine Grundlage für eine Vertrauensentscheidung.

    • Im Gegensatz dazu wird durch die Verwendung eines Zertifikats, das sich auf eine vertrauenswürdige Zertifizierungsstelle besingt, die Grundlage für die Verwendung des zugeordneten privaten Schlüssels deutlich gemacht, und im Falle eines Sicherheitsfehlers werden Sperr- und Aktualisierungsvorgänge ermöglicht.

Verschlüsseln vertraulicher Daten vor dem Speichern

DPAPI/DPAPI-NG

Für Daten, die über Systemneustarts hinweg beibehalten werden müssen:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

Für Daten, die nicht über Systemneustarts hinweg beibehalten werden müssen:

  • CryptProtectMemory

  • CryptUnprotectMemory

Für Daten, die beibehalten werden müssen und auf die von mehreren Domänenkonten und Computern zugegriffen werden müssen:

SQL-Server-TDE

Sie können SQL Server Transparent Data Encryption (TDE) verwenden, um vertrauliche Daten zu schützen.

Sie sollten einen TDE-Datenbankverschlüsselungsschlüssel (Database Encryption Key, DEK) verwenden, der die Anforderungen an den kryptografischen SDL-Algorithmus und die Schlüsselstärke erfüllt. Derzeit werden nur AES_128, AES_192 und AES_256 empfohlen; TRIPLE_DES_3KEY wird nicht empfohlen.

Es gibt einige wichtige Überlegungen zur Verwendung von SQL TDE, die Sie beachten sollten:

Verwaltung von Anmeldeinformationen

Verwenden Sie die Windows Anmeldeinformationsverwaltung-API oder Microsoft Azure KeyVault, um Kennwort- und Anmeldeinformationsdaten zu schützen.

Windows Store-Apps

Verwenden Sie die Klassen in den Namespaces Windows.Security.Cryptography und Windows.Security.Cryptography.DataProtection, um Geheimnisse und vertrauliche Daten zu schützen.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

Verwenden Sie die Klassen im Windows.Security.Credentials-Namespace, um Kennwort- und Anmeldeinformationsdaten zu schützen.

.NET

Für Daten, die über Systemneustarts hinweg beibehalten werden müssen:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

Für Daten, die nicht über Systemneustarts hinweg beibehalten werden müssen:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

Verwenden Sie für Konfigurationsdateien:

Entweder RSAProtectedConfigurationProvider oder DPAPIProtectedConfigurationProvider, um Ihre Konfiguration mit RSA-Verschlüsselung bzw. DPAPI zu schützen.

Der RSAProtectedConfigurationProvider kann auf mehreren Computern in einem Cluster verwendet werden. Weitere Informationen finden Sie unter Verschlüsseln von Konfigurationsinformationen mithilfe der geschützten Konfiguration.