Ausschließliches Verwenden von genehmigten symmetrischen Blockchiffren und Schlüssellängen
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Für Produkte dürfen nur die symmetrischen Blockchiffren und zugeordneten Schlüssellängen verwendet werden, die vom Crypto Advisor (Kryptografiebeauftragter) Ihrer Organisation ausdrücklich genehmigt wurden. Zu den genehmigten symmetrischen Algorithmen bei Microsoft gehören die folgenden Blockchiffren:
Für neuen Code sind AES-128, AES-192 und AES-256 akzeptabel.
In Bezug auf die Abwärtskompatibilität mit vorhandenem Code ist 3DES mit drei Schlüsseln akzeptabel.
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 Blockverschlüsselungsalgorithmus, der für neuen Code empfohlen wird, ist AES (AES-128, AES-192 und AES-256 sind akzeptabel).
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.
Beachten Sie, dass alle symmetrischen Blockchiffren zusammen mit einem genehmigten Chiffremodus verwendet werden müssen. Hierfür muss ein geeigneter Initialisierungsvektor (IV) genutzt werden. Bei einem geeigneten IV handelt es sich normalerweise um eine Zufallszahl und niemals um einen konstanten Wert.
Die Verwendung von älteren oder in anderer Hinsicht nicht genehmigten Kryptografiealgorithmen und geringeren Schlüssellängen zum Lesen von vorhandenen Daten (im Gegensatz zum Schreiben neuer Daten) kann nach einer Überprüfung durch das „Crypto Board“ Ihrer Organisation erlaubt werden. Es muss aber eine Ausnahme dieser Anforderung beantragt werden. Bei Bereitstellungen in Unternehmen sollte für Produkte erwägt werden, dass Administratoren bei Verwendung von unsicherer Kryptografie zum Lesen von Daten gewarnt werden. Diese Warnungen sollten eine gute Beschreibung und verwertbare Informationen enthalten. In einigen Fällen kann es hilfreich sein, die Nutzung von unsicherer Kryptografie per Gruppenrichtlinie zu steuern.
Zulässige .NET-Algorithmen für verwaltete kryptografische Flexibilität (sortiert nach Präferenz)
AesCng (FIPS-konform)
AuthenticatedAesCng (FIPS-konform)
AESCryptoServiceProvider (FIPS-konform)
AESManaged (nicht FIPS-konform)
Beachten Sie, dass keiner dieser Algorithmen mit der Methode SymmetricAlgorithm.Create oder CryptoConfig.CreateFromName angegeben werden kann, ohne Änderungen an der Datei „machine.config“ vorzunehmen. Beachten Sie auch, dass AES in älteren .NET-Versionen als .NET 3.5 die Bezeichnung RijndaelManaged hat und dass AesCng und AuthenticatedAesCng per CodePlex verfügbar sind und CNG im zugrunde liegenden Betriebssystem erforderlich ist.
Verwenden von genehmigten Blockchiffremodi und Initialisierungsvektoren für symmetrische Chiffren
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Alle symmetrischen Blockchiffren müssen zusammen mit einem genehmigten Modus für symmetrische Chiffren verwendet werden. Die einzigen genehmigten Modi sind CBC und CTS. Vor allem der Vorgangsmodus ECB (Electronic Code Book) sollte vermieden werden. Für die Verwendung von ECB benötigen Sie die Zustimmung des Crypto Board Ihrer Organisation. Jedwede Nutzung von OFB, CFB, CTR, CCM und GCM oder eines beliebigen anderen Verschlüsselungsmodus muss vom Crypto Board Ihrer Organisation geprüft werden. Die Wiederverwendung des gleichen Initialisierungsvektors (IV) mit Blockchiffren in „Streamingchiffremodi“, z.B. CTR, kann dazu führen, dass verschlüsselte Daten offengelegt werden. Außerdem müssen alle symmetrischen Blockchiffren zusammen mit einem geeigneten Initialisierungsvektor (IV) verwendet werden. Ein geeigneter IV ist eine in kryptografischer Hinsicht sichere Zufallszahl und niemals ein konstanter Wert.
Verwenden von genehmigten asymmetrischen Algorithmen, Schlüssellängen und Auffüllungen
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Die Verwendung von unzulässigen kryptografischen Algorithmen stellt ein erhebliches Risiko für die Produktsicherheit dar und muss vermieden werden. Für Produkte dürfen nur kryptografische Algorithmen und die dazugehörigen Schlüssellängen und Auffüllungen verwendet werden, die vom Crypto Board Ihrer Organisation ausdrücklich genehmigt wurden.
RSA- kann für die Verschlüsselung, den Schlüsselaustausch und Signaturen verwendet werden. Für die RSA-Verschlüsselung dürfen nur die Auffüllmodi OAEP oder RSA-KEM verwendet werden. Für vorhandenen Code darf der Auffüllmodus PKCS #1 v1.5 ausschließlich zu Kompatibilitätszwecken genutzt werden. Die Verwendung der Nullauffüllung ist explizit untersagt. Für neuen Code sind Schlüssel mit mindestens 2048 Bit erforderlich. Für vorhandenen Code dürfen Schlüssel mit weniger als 2048 Bit nur aus Gründen der Abwärtskompatibilität unterstützt werden, nachdem dies vom Crypto Board Ihrer Organisation geprüft wurde. Schlüssel mit weniger als 1024 Bit dürfen nur zum Entschlüsseln bzw. Überprüfen von alten Daten verwendet werden und müssen ausgetauscht werden, wenn sie für Verschlüsselungs- oder Signaturvorgänge verwendet werden.
ECDSA- darf nur für Signaturen verwendet werden. Für neuen Code ist ECDSA mit Schlüsseln mit mindestens 256 Bit erforderlich. Für ECDSA-basierte Signaturen muss eine der drei Kurven mit NIST-Genehmigung genutzt werden (P-256, P-384 oder P521). Kurven, die gründlich analysiert wurden, dürfen nur nach einer Prüfung durch das Crypto Board Ihrer Organisation verwendet werden.
ECDH- darf nur für den Schlüsselaustausch verwendet werden. Für neuen Code ist ECDH mit Schlüsseln mit mindestens 256 Bit erforderlich. Für den ECDH-basierten Schlüsselaustausch muss eine der drei Kurven mit NIST-Genehmigung genutzt werden (P-256, P-384 oder P521). Kurven, die gründlich analysiert wurden, dürfen nur nach einer Prüfung durch das Crypto Board Ihrer Organisation verwendet werden.
DSA- ist unter Umständen akzeptabel, nachdem dieses Verfahren vom Crypto Board Ihrer Organisation geprüft und genehmigt wurde. Wenden Sie sich an Ihren Sicherheitsberater, um einen Termin für die Überprüfung durch das Crypto Board Ihrer Organisation auszumachen. Beachten Sie Folgendes, falls die Verwendung von DSA genehmigt wird: Die Nutzung von Schlüsseln mit einer Schlüssellänge von weniger als 2.048 Bit muss untersagt werden. CNG unterstützt ab Windows 8 Schlüssellängen von 2.048 Bit und mehr.
Diffie-Hellman- darf nur für die Verwaltung von Sitzungsschlüsseln verwendet werden. Für neuen Code sind Schlüssellängen von mindestens 2048 Bit erforderlich. Für vorhandenen Code dürfen Schlüssellängen von weniger als 2048 Bit nur aus Gründen der Abwärtskompatibilität unterstützt werden, nachdem dies vom Crypto Board Ihrer Organisation geprüft wurde. Schlüssel mit weniger als 1024 Bit dürfen nicht verwendet werden.
Verwenden von genehmigten Zufallszahlengeneratoren
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Für Produkte müssen genehmigte Zufallszahlengeneratoren verwendet werden. Pseudozufallsfunktionen, z.B. die C-Runtimefunktion „rand“, die .NET Framework-Klasse „System.Random“ oder Systemfunktionen wie „GetTickCount“, dürfen in Code dieser Art daher niemals genutzt werden. Die Verwendung des DUAL_EC_DRBG-Algorithmus (Dual Elliptic Curve Random Number Generator) ist untersagt.
CNG- BCryptGenRandom (Die Verwendung des Flags BCRYPT_USE_SYSTEM_PREFERRED_RNG wird empfohlen, sofern der Aufrufer für die Ausführung nicht einen IRQL-Wert größer als Null verwendet [PASSIVE_LEVEL].)
CAPI- cryptGenRandom
Win32/64- RtlGenRandom (für neue Implementierungen sollte BCryptGenRandom oder CryptGenRandom verwendet werden) * rand_s * SystemPrng (für Kernelmodus)
.NET- RNGCryptoServiceProvider oder RNGCng
Windows Store Apps- Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom oder .GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bytes )
Apple OS X (<10.7)- Verwenden Sie „/dev/random“ zum Abrufen von Zufallszahlen.
Java (einschließlich Google Android Java-Code)- java.security.SecureRandom-Klasse. Beachten Sie, dass Entwickler für Android 4.3 (Jelly Bean) die für Android empfohlene Problemumgehung verwenden und ihre Anwendungen aktualisieren müssen, um PRNG mit Entropie über „/dev/urandom“ oder „/dev/random“ explizit zu initialisieren.
Vermeiden der Verwendung von symmetrischen Streamchiffren
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Symmetrische Streamchiffren, 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).
Verwenden von genehmigten MAC-, HMAC- und schlüsselgebundenen Hashalgorithmen
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Für Produkte dürfen nur genehmigte Algorithmen vom Typ MAC (Message Authentication Code) oder HMAC (Hash-Based Message Authentication Code) verwendet werden.
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 zulässig, sofern auch alle zugrunde liegenden Hash- oder symmetrischen Verschlüsselungsalgorithmen für die Verwendung genehmigt sind. Dies gilt derzeit für die HMAC-SHA2-Funktionen (HMAC-SHA256, HMAC-SHA384 und HMAC-SHA512) und die auf Blockchiffren basierenden MACs CMAC/OMAC1 und OMAC2 (auf AES-Basis).
Die Verwendung von HMAC-SHA1 kann aus Gründen der Plattformkompatibilität zulässig sein, aber Sie müssen eine Ausnahme von diesem Verfahren beantragen und den Prozess zur Kryptografieüberprüfung Ihrer Organisation durchlaufen. Eine Kürzung von HMACs auf weniger als 128 Bit ist nicht zulässig. Die Verwendung von Kundenmethoden zum Hashen eines Schlüssels und von Daten ist nicht genehmigt, und vor der Verwendung muss eine Prüfung durch das Crypto Board Ihrer Organisation erfolgen.
Ausschließliches Verwenden von genehmigten kryptografischen Hashfunktionen
Titel
Details
Komponente
Webanwendung.
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Für die Produkte muss die SHA-2-Familie der Hashalgorithmen (SHA256, SHA384 und SHA512) verwendet werden. Wenn ein kürzerer Hash erforderlich ist, z.B. eine Ausgabelänge von 128 Bit für eine Datenstruktur mit dem kürzeren MD5-Hash, ist es für Produktteams zulässig, einen der SHA2-Hashes (normalerweise SHA256) zu kürzen. Beachten Sie, dass SHA384 eine gekürzte Version von SHA512 ist. Das Kürzen von kryptografischen Hashes auf weniger als 128 Bit aus Sicherheitsgründen ist nicht zulässig. Für neuen Code dürfen die Hashalgorithmen MD2, MD4, MD5, SHA-0, SHA-1 oder RIPEMD nicht verwendet werden. Aus computertechnischer Sicht kann es für diese Algorithmen zu Hashkonflikten und somit zu Fehlern kommen.
Zulässige .NET-Hashalgorithmen für verwaltete kryptografische Flexibilität (sortiert nach Präferenz):
SHA512Cng (FIPS-konform)
SHA384Cng (FIPS-konform)
SHA256Cng (FIPS-konform)
SHA512Managed (nicht FIPS-konform) (verwenden Sie SHA512 als Algorithmusnamen in Aufrufen von HashAlgorithm.Create oder CryptoConfig.CreateFromName).
SHA384Managed (nicht FIPS-konform) (verwenden Sie SHA384 als Algorithmusnamen in Aufrufen von HashAlgorithm.Create oder CryptoConfig.CreateFromName).
SHA256Managed (nicht FIPS-konform) (verwenden Sie SHA256 als Algorithmusnamen in Aufrufen von HashAlgorithm.Create oder CryptoConfig.CreateFromName).
SHA512CryptoServiceProvider (FIPS-konform)
SHA256CryptoServiceProvider (FIPS-konform)
SHA384CryptoServiceProvider (FIPS-konform)
Verwenden von sicheren Verschlüsselungsalgorithmen zum Verschlüsseln von Daten in der Datenbank
Mit Verschlüsselungsalgorithmen werden Datentransformationen definiert, die von unbefugten Benutzern nicht leicht umgekehrt werden können. In SQL Server können Administratoren und Entwickler zwischen mehreren Algorithmen wählen, z.B. DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-Bit RC4, DESX, 128-Bit AES, 192-Bit AES und 256-Bit AES.
SSIS-Pakete sollten verschlüsselt und digital signiert werden
Die Quelle eines Pakets ist die Einzelperson oder die Organisation, die das Paket erstellt hat. Das Ausführen eines Pakets von einer unbekannten oder nicht vertrauenswürdigen Quelle kann riskant sein. Sie sollten digitale Signaturen verwenden, um die unbefugte Manipulation von SSIS-Paketen zu verhindern. Außerdem müssen SSIS-Pakete verschlüsselt werden, um die Vertraulichkeit der Pakete beim Speichern und Übertragen sicherzustellen.
Hinzufügen einer digitalen Signatur zu kritischen sicherungsfähigen Elementen von Datenbanken
In Fällen, in denen die Integrität eines kritischen sicherungsfähigen Elements von Datenbanken überprüft werden muss, müssen digitale Signaturen verwendet werden. Sicherungsfähige Elemente von Datenbanken, z.B. gespeicherte Prozedur, Funktion, Assembly oder Trigger, können digital signiert werden. Unten ist ein Beispiel dafür angegeben, wann dies hilfreich ist: Angenommen, ein unabhängiger Softwarehersteller (Independent Software Vendor, ISV) leistet Support für eine Software, die an einen Kunden geliefert wurde. Vor der Supportleistung möchte der ISV sicherstellen, dass ein sicherungsfähiges Element der Datenbank in der Software nicht versehentlich oder in böser Absicht bewusst manipuliert wurde. Wenn das sicherungsfähige Element digital signiert ist, kann der ISV die digitale Signatur prüfen und die Integrität bestätigen.
Verwenden der erweiterbaren Schlüsselverwaltung von SQL Server zum Schützen von Verschlüsselungsschlüsseln
Mit der erweiterbaren Schlüsselverwaltung (Extensible Key Management, EKM) von SQL Server können die Verschlüsselungsschlüssel, mit denen die Datenbankdateien geschützt werden, auf einem externen Gerät gespeichert werden. Beispiele hierfür sind eine Smartcard, ein USB-Gerät oder ein EKM/HSM-Modul. Hiermit wird auch der Schutz von Daten durch Datenbankadministratoren ermöglicht (mit Ausnahme von Mitgliedern der sysadmin-Gruppe). Daten können mit Verschlüsselungsschlüsseln verschlüsselt werden, auf die nur der Datenbankbenutzer auf dem externen EKM/HSM-Modul Zugriff hat.
Verwenden des Features AlwaysEncrypted, wenn Verschlüsselungsschlüssel für das Datenbankmodul nicht offengelegt werden sollen
Always Encrypted ist ein Feature zum Schützen von vertraulichen Daten, z.B. Kreditkartennummern oder nationalen bzw. regionalen Identifikationsnummern (z.B. Sozialversicherungsnummer), die in Azure SQL-Datenbank oder SQL Server-Datenbanken gespeichert sind. Mit Always Encrypted können Kunden vertrauliche Daten in Clientanwendungen verschlüsseln, ohne die Verschlüsselungsschlüssel für das Datenbankmodul (SQL-Datenbank oder SQL Server) jemals offenzulegen. Zu diesem Zweck ermöglicht Always Encrypted eine Trennung zwischen den Besitzern der Daten (die diese anzeigen dürfen) und den Personen, die die Daten verwalten (aber ansonsten keinen Zugriff haben).
Sicheres Speichern von kryptografischen Schlüsseln auf dem IoT-Gerät
Titel
Details
Komponente
IoT-Gerät
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
Gerätebetriebssystem: Windows IoT Core, Gerätekonnektivität: Azure IoT-Geräte-SDKs
Legen Sie private symmetrische oder Zertifikatschlüssel sicher in einem per Hardware geschützten Speicher ab, z.B. TPM oder Smartcardchips. Windows 10 IoT Core unterstützt die Verwendung eines TPM, und Sie können mehrere kompatible TPMs nutzen: diskretes TPM (dTPM). Es wird empfohlen, ein Firmware-TPM oder diskretes TPM zu verwenden. Ein Software-TPM sollte nur zu Entwicklungs- und Testzwecken eingesetzt werden. Nachdem ein TPM verfügbar ist und die Schlüssel darin bereitgestellt wurden, sollte der Code zum Generieren des Tokens geschrieben werden, ohne dass darin enthaltene sensible Informationen hartcodiert werden.
Beispiel
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Es ist erkennbar, dass der primäre Geräteschlüssel nicht im Code enthalten ist. Stattdessen ist er im TPM unter Slot 0 gespeichert. Das TPM-Gerät generiert ein SAS-Token mit kurzer Gültigkeitsdauer, das dann zum Herstellen der Verbindung mit dem IoT Hub verwendet wird.
Generieren eines zufälligen symmetrischen Schlüssels mit einer ausreichenden Länge für die Authentifizierung gegenüber IoT Hub
Titel
Details
Komponente
IoT-Cloudgateway
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
Wahl des Gateways: Azure IoT Hub
Referenzen
–
Schritte
IoT Hub enthält eine Geräteidentitätsregistrierung und generiert beim Bereitstellen eines Geräts automatisch einen zufälligen symmetrischen Schlüssel. Es wird empfohlen, dieses Feature der Azure IoT Hub-Identitätsregistrierung zum Generieren des Schlüssels zu nutzen, der für die Authentifizierung eingesetzt wird. IoT Hub ermöglicht auch, dass beim Erstellen des Geräts ein Schlüssel angegeben wird. Wenn während der Bereitstellung des Geräts außerhalb von IoT Hub ein Schlüssel generiert wird, wird die Erstellung eines zufälligen symmetrischen Schlüssels mit mindestens 256 Bit empfohlen.
Sicherstellen der Verwendung einer Richtlinie für die Geräteverwaltung, die für die Nutzung eine PIN erforderlich macht und das Remotelöschen ermöglicht
Titel
Details
Komponente
Dynamics CRM – Mobiler Client
SDL-Phase
Bereitstellung
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Sicherstellen der Verwendung einer Richtlinie für die Geräteverwaltung, die für die Nutzung eine PIN erforderlich macht und das Remotelöschen ermöglicht
Sicherstellen der Verwendung einer Richtlinie für die Geräteverwaltung, die PIN/Kennwort/automatische Sperre erforderlich macht und alle Daten verschlüsselt (z.B. BitLocker)
Titel
Details
Komponente
Dynamics CRM – Outlook-Client
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Sicherstellen der Verwendung einer Richtlinie für die Geräteverwaltung, die PIN/Kennwort/automatische Sperre erforderlich macht und alle Daten verschlüsselt (z.B. BitLocker)
Sicherstellen, dass für Signaturschlüssel bei Verwendung von Identity Server ein Rollover durchgeführt wird
Stellen Sie sicher, dass für Signaturschlüssel bei Verwendung von Identity Server ein Rollover durchgeführt wird. Unter dem Link im Abschnitt „Referenzen“ wird beschrieben, wie dies geplant werden sollte, ohne dass es für Anwendungen, die von Identity Server abhängig sind, zu Ausfällen kommt.
Stellen Sie sicher, dass in Identity Server eine in kryptografischer Hinsicht sichere Client-ID und ein sicherer geheimer Clientschlüssel verwendet werden.
Titel
Details
Komponente
Identity Server
SDL-Phase
Entwickeln
Zutreffende Technologien
Allgemein
Attribute
–
Referenzen
–
Schritte
Stellen Sie sicher, dass in Identity Server eine in kryptografischer Hinsicht sichere Client-ID und ein sicherer geheimer Clientschlüssel verwendet werden. Zum Generieren einer Client-ID und des Geheimnisses sollten die folgenden Richtlinien beachtet werden:
Generieren einer zufälligen GUID als Client-ID
Generieren eines kryptografisch zufälligen Schlüssels mit 256 Bit als Geheimnis