Freigeben über

Kryptografische Empfehlungen für Microsoft SDL

  • Artikel

Verwenden Sie diese Informationen als Referenz beim Entwerfen von Produkten, um die gleichen APIs, Algorithmen, Protokolle und Schlüssellängen zu verwenden, die Microsoft für seine eigenen Produkte und Dienste benötigt. Ein Großteil der Inhalte basiert auf den eigenen internen Sicherheitsstandards von Microsoft, die zum Erstellen des Security Development Lifecycle verwendet werden.

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

TLS/SSL-Versionen

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

  • TLS 1.3 muss aktiviert sein.
  • TLS 1.2 kann aktiviert werden, um die Kompatibilität mit älteren Clients zu verbessern.
  • TLS 1.1, TLS 1.0, SSL 3 und SSL 2 müssen deaktiviert sein

Symmetrische Blockchiffren, Verschlüsselungsmodi und Initialisierungsvektoren

Blockchiffren

Für Produkte mit symmetrischen Blockchiffren:

  • Advanced Encryption Standard (AES) wird empfohlen.
  • Alle anderen Blockchiffre, einschließlich 3DES (Triple DES/TDEA) und RC4, müssen ersetzt werden, wenn sie für die Verschlüsselung verwendet werden.

Für symmetrische Blockverschlüsselungsalgorithmen ist eine Mindestlänge von 128 Bit erforderlich, es wird jedoch empfohlen, 256-Bit-Schlüssel zu unterstützen. 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).

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 im Folgenden aufgeführten, weisen Implementierungsfehler auf, welche die Wahrscheinlichkeit einer falschen Verwendung erhöhen. Insbesondere müssen 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)
  • Alles andere, was nicht in der vorherigen Liste "empfohlen" enthalten ist

Initialisierungsvektoren (IV)

Alle symmetrischen Blockchiffren sollten auch mit einer kryptografisch starken Zufallszahl als Initialisierungsvektor verwendet werden. Initialisierungsvektoren sollten niemals ein konstanter oder vorhersehbarer 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. Die Wiederverwendung kann Informationen über die verschlüsselten Daten offenlegen, insbesondere bei Verwendung von Streamingchiffremodi wie Output Feedback (OFB) oder Counter (CTR).

AES-GCM- & AES-CCM-Empfehlungen

AES-GCM (Galois/Counter Mode) und AES-CCM (Counter mit CBC-MAC) sind weit verbreitete authentifizierte Verschlüsselungsmodi. Sie kombinieren Vertraulichkeits- und Integritätsschutz, wodurch sie für sichere Kommunikation nützlich sind. Ihre Fragilität liegt jedoch in der Nonce-Wiederverwendung. Wenn derselbe Nonce (Initialisierungsvektor) zweimal verwendet wird, kann es katastrophalen Folgen haben.

Es wird empfohlen, die Nonce-Richtlinien zu befolgen, wie in NIST SP 800-38D beschrieben, Empfehlung für Blockchiffremodi des Betriebs: Galois/Counter Mode (GCM) und GMAC, wobei besonders auf Abschnitt 8.3 hinsichtlich der maximalen Anzahl von Aufrufen zu achten ist.

Eine weitere Option wären eindeutige generierte AES-GCM/CCM-Schlüssel für jede verschlüsselte Nachricht, bei denen die maximale Anzahl von Aufrufen effektiv auf 1 begrenzt wird. Dieser Ansatz wird für die Verschlüsselung ruhender Daten empfohlen, bei denen die Verwendung eines Zählers oder die Sicherstellung, dass Sie die maximale Anzahl von Aufrufen für einen bestimmten Schlüssel nachverfolgen können, unpraktisch wäre.

Zum Verschlüsseln ruhender Daten können Sie auch die Verwendung von AES-CBC mit einem Nachrichtenauthentifizierungscode (MAC) als Alternative mithilfe eines Encrypt-then-MAC-Schemas in Betracht ziehen, um sicherzustellen, dass Sie separate Schlüssel für die Verschlüsselung und für den MAC verwenden.

Integritätsüberprüfung

Es ist ein häufiges Missverständnis, dass die Verschlüsselung standardmäßig sowohl Vertraulichkeits- als auch Integritätsüberprüfung bietet. Viele Verschlüsselungsalgorithmen bieten keine Integritätsprüfung und sind möglicherweise anfällig für Manipulationsangriffe. Zusätzliche Schritte müssen ausgeführt werden, um die Integrität der Daten vor dem Senden und nach dem Empfang sicherzustellen.

Wenn Sie keinen authentifizierten Verschlüsselungsalgorithmus mit zugehörigen Daten (AEAD) wie AES-GCM verwenden können, besteht eine Alternative darin, die Integrität mit einem Nachrichtenauthentifizierungscode (MAC) mithilfe eines Encrypt-then-MAC-Schemas zu überprüfen, um sicherzustellen, dass Sie separate Schlüssel für die Verschlüsselung und für den MAC verwenden.

Die Verwendung eines separaten Schlüssels für die Verschlüsselung und für MAC ist unerlässlich. Wenn es nicht möglich ist, die beiden Schlüssel zu speichern, besteht eine zulässige Alternative darin, zwei Schlüssel vom Hauptschlüssel mithilfe einer geeigneten Schlüsselableitungsfunktion (KDF) abzuleiten, eine für Verschlüsselungszwecke und eine für MAC. Weitere Informationen finden Sie unter SP 800-108 Rev. 1, Empfehlung für die Schlüsselableitung mit Pseudorandom-Funktionen | CSRC (nist.gov).

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.
  • Es wird mindestens eine Schlüssellänge von 2048-Bit empfohlen, es wird jedoch empfohlen, eine Schlüssellänge von 3072-Bit zu unterstützen.

ECDSA und ECDH

  • ECDH-basierter Schlüsselaustausch- und ECDSA-basierte Signaturen sollten eine der drei von NIST genehmigten Kurven (P-256, P-384 oder P521) verwenden.
  • Die Unterstützung für P-256 sollte als Minimum betrachtet werden, es wird jedoch empfohlen, P-384 zu unterstützen.

Integer Diffie-Hellman

  • Schlüssellänge > = 2048 Bits wird empfohlen0
  • 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

  • Definieren Sie eine Kryptoperiode für alle Schlüssel.
    • Beispiel: Ein symmetrischer Schlüssel für die Datenverschlüsselung, der häufig als Datenverschlüsselungsschlüssel oder DEK bezeichnet wird, kann einen Nutzungszeitraum von bis zu zwei Jahren für die Verschlüsselung von Daten aufweisen, auch bekannt als Absendernutzungszeitraum. Sie können definieren, dass es einen gültigen Nutzungszeitraum für die Entschlüsselung für drei weitere Jahre hat, auch bekannt als Empfängerverwendungszeitraum.
  • 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 darf ein Schlüssel nicht verwendet werden, um neue Daten zu erzeugen (z. B. für Verschlüsselung oder Signierung), kann aber 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 der BCRYPT_USE_SYSTEM_PREFERRED_RNG-Kennzeichnung.

Win32/64

  • Legacycode kann RtlGenRandom im Kernelmodus verwenden.
  • Neuer Code sollte BCryptGenRandom oder CryptGenRandom verwenden.
  • Die C-Funktion Rand_s() wird ebenfalls empfohlen (die in Windows CryptGenRandom aufruft).
  • Rand_s() ist ein sicherer und leistungsfähiger Ersatz für Rand().
  • Rand() darf nicht für kryptografische Anwendungen verwendet werden.

.NET

PowerShell

Windows Store-Apps

Linux/macOS

  • Das /dev/urandom-Gerät stellt eine kryptografisch starke Quelle zufälliger Daten bereit, ebenso wie der getrandom(2)-Systemaufruf.

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:

  • Die Bibliothek sollte eine aktuelle unterstützte Version ohne bekannte Sicherheitsrisiken sein.
  • Die neuesten Sicherheitsprotokolle, Algorithmen und Schlüssellängen sollten unterstützt werden.
  • (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 ist, verwenden Sie nach Möglichkeit CNG.
  • Ü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 (.NET)

  • Kryptografie-Primitives: Verwenden Sie die im System.Security.Cryptography-Namespace.
  • Verwenden Sie die neueste .NET-Version, die verfügbar ist.

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 (Revision 1): Empfehlung zur Schlüsselableitung mit Pseudozufallsfunktionen. Insbesondere die KDF im Indikatormodus mit HMAC als Pseudozufallsfunktion
  • NIST SP 800-56A (Revision 3): Empfehlung für paarweise Schlüsseletablierungs-Schemata mit Kryptografie über diskrete Logarithmen.

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 TLS oder DTLS verwenden, müssen die X.509-Zertifikate der Entitäten, mit denen sie eine Verbindung herstellen, umfassend überprüfen. Dieser Prozess umfasst die Überprüfung der folgenden Teile des Zertifikats:

  • 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.

Verwenden Sie keine selbstsignierten Zertifikate. Selbstsignierte vermitteln nicht grundsätzlich Vertrauen, unterstützen die Sperrung oder verlängern den Supportschlüssel.

Kryptografische Hashfunktionen

Produkte sollten die SHA-2-Familie von Hashalgorithmen (SHA-256, SHA-384 und SHA-512) verwenden. Das Kürzen von kryptografischen Hashes auf weniger als 128 Bit aus Sicherheitsgründen ist nicht zulässig. Während die Verwendung von SHA-256 das Minimum ist, empfehlen wir die Unterstützung von SHA-384.

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 wird 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). Während die Verwendung von HMAC-SHA256 das Minimum ist, empfehlen wir die Unterstützung von HMAC-SHA384.

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. Diese Metadaten sollten den verwendeten Algorithmus, die Schlüsselgrößen und die Abstandsmodi enthalten.
  • Sofern verfügbar sollten eingerichtete Produkte von der Plattform bereitgestellte kryptografische Protokolle verwenden, anstatt sie erneut zu implementieren, einschließlich Signaturformate (z. B. verwenden Sie ein vorhandenes Standardformat).
  • 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 Elemente enthält:
    • Ein neues Protokoll, das sich hauptsächlich auf die Sicherheit konzentriert (z. B. ein Authentifizierungs- oder Autorisierungsprotokoll).
    • Ein neues Protokoll, das Kryptografie auf neuartige oder nicht standardmäßige Weise verwendet. Zu berücksichtigende Beispiele sind:
      • 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 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.