Microsoft SDL-cryptografische Aanbevelingen

Artikel
11/28/2021
11 minuten om te lezen

Inleiding

Dit document bevat aanbevelingen en aanbevolen procedures voor het gebruik van versleuteling op Microsoft-platforms. Veel van de inhoud hier wordt geparafraseerd of samengevoegd op basis van de eigen interne beveiligingsstandaarden van Microsoft die worden gebruikt om de levenscyclus van beveiligingsontwikkeling te maken. Het is bedoeld om te worden gebruikt als referentie bij het ontwerpen van producten om dezelfde API's, algoritmen, protocollen en sleutellengten te gebruiken die Microsoft van haar eigen producten en services nodig heeft.

Ontwikkelaars op niet-Windows platforms kunnen ook profiteren van deze aanbevelingen. Hoewel de API- en bibliotheeknamen mogelijk verschillen, zijn de best practices met betrekking tot algoritmekeuze, sleutellengte en gegevensbescherming op verschillende platforms vergelijkbaar.

Beveiligingsprotocol, algoritme en sleutellengte Aanbevelingen

SSL/TLS-versies

Producten en services moeten cryptografische beveiligde versies van SSL/TLS gebruiken:

TLS 1.2 moet zijn ingeschakeld
TLS 1.1 en TLS 1.0 moeten alleen zijn ingeschakeld voor compatibiliteit met achterwaartse compatibiliteit
SSL 3 en SSL 2 moeten standaard worden uitgeschakeld

Symmetrische bloksleutels, coderingsmodi en initialisatievectoren

Ciphers blokkeren

Voor producten met symmetrische bloksleutels:

Advanced Encryption Standard (AES) wordt aanbevolen voor nieuwe code.
Driesleutelige driedubbele gegevensversleutelingsstandaard (3DES) is toegestaan in bestaande code voor achterwaartse compatibiliteit.
Alle andere bloksleutels, waaronder RC2, DES, 3DES met 2 toetsen, DESX en Skipjack, mogen alleen worden gebruikt voor het ontsleutelen van oude gegevens en moeten worden vervangen als deze worden gebruikt voor versleuteling.

Voor symmetrische blokversleutelingsalgoritmen wordt een minimale sleutellengte van 128 bits aanbevolen. Het enige versleutelingsalgoritme dat wordt aanbevolen voor nieuwe code is AES (AES-128, AES-192 en AES-256 zijn allemaal acceptabel, omdat AES-192 op sommige processors geen optimalisatie heeft). 3DES met drie toetsen is momenteel acceptabel als deze al in bestaande code wordt gebruikt. overgang naar AES wordt aanbevolen. DES, DESX, RC2 en Skipjack worden niet langer als veilig beschouwd. Deze algoritmen mogen alleen worden gebruikt voor het ontsleutelen van bestaande gegevens ter wille van achterwaartse compatibiliteit en gegevens moeten opnieuw worden versleuteld met behulp van een aanbevolen blokcodering.

Cipher-modi

Symmetrische algoritmen kunnen in verschillende modi werken, waarvan de versleutelingsbewerkingen op opeenvolgende blokken tekst zonder tekst en cijfertekst worden gekoppeld.

Symmetrische bloksleutels moeten worden gebruikt met een van de volgende coderingsmodi:

Cipher Block Chaining (CBC)
Ciphertext Stealing (CTS)
XEX-gebaseerde Tweaked-Codebook met Ciphertext Stealing (XTS)

Sommige andere coderingsmodi, zoals de onderstaande codeermodi, hebben implementatie-valkuilen die ervoor zorgen dat ze waarschijnlijk onjuist worden gebruikt. Met name de modus Electronic Code Book (ECB) moet worden vermeden. Als u dezelfde initialisatievector (IV) gebruikt met blokcodering in 'streaming ciphers modes', zoals CTR, kunnen versleutelde gegevens worden onthuld. Extra beveiligingsbeoordeling wordt aanbevolen als een van de onderstaande modi wordt gebruikt:

Feedback over uitvoer (OFB)
Feedback van cipher (CFB)
Teller (CTR)
Teller met CBC-MAC (CCM)
Galois/Counter Mode (GCM)
Iets anders dat niet in de bovenstaande 'aanbevolen' lijst staat

Initialisatievectoren (IV)

Alle symmetrische bloksleutels moeten ook worden gebruikt met een cryptografisch sterk willekeurig getal als initialisatievector. Initialisatievectoren mogen nooit een constante waarde zijn. Zie Random Number Generators voor aanbevelingen voor het genereren van cryptografische sterke willekeurige getallen.

Initialisatievectoren mogen nooit opnieuw worden gebruikt bij het uitvoeren van meerdere versleutelingsbewerkingen, omdat hierdoor informatie kan worden onthuld over de gegevens die worden versleuteld, met name bij het gebruik van streamingcoderingsmodi zoals Output Feedback (OFB) of Counter (CTR).

Asymmetrische algoritmen, toetslengten en opvullingsmodi

RSA

RSA moet worden gebruikt voor versleuteling, sleuteluitwisseling en handtekeningen.
RSA-versleuteling moet de opvullingsmodi OAEP of RSA-PSS gebruiken. Bestaande code moet pkcs #1 v1.5 opvullingsmodus gebruiken voor alleen compatibiliteit.
Gebruik van null-opvulling wordt niet aanbevolen.
Toetsen > = 2048 bits worden aanbevolen

ECDSA

ECDSA met > = 256 bitstoetsen wordt aanbevolen
ECDSA-handtekeningen moeten een van de drie door NIST goedgekeurde curven (P-256, P-384 of P521) gebruiken.

ECDH

ECDH met > = 256 bitstoetsen wordt aanbevolen
EcDH-gebaseerde sleuteluitwisseling moet een van de drie door NIST goedgekeurde curven (P-256, P-384 of P521) gebruiken.

Integer Diffie-Hellman

Toetslengte > = 2048 bits wordt aanbevolen
De groepsparameters moeten een bekende benoemde groep zijn (bijvoorbeeld RFC 7919), of worden gegenereerd door een vertrouwde partij en geverifieerd vóór gebruik

Sleutellevensduur

Alle asymmetrische sleutels moeten een levensduur van maximaal vijf jaar hebben, met de aanbevolen levensduur van één jaar.
Alle symmetrische sleutels moeten een levensduur van maximaal drie jaar hebben. aanbevolen levensduur van één jaar.
U moet een mechanisme bieden of een proces hebben voor het vervangen van sleutels om de beperkte actieve levensduur te bereiken. Na het einde van de actieve levensduur mag een sleutel niet worden gebruikt om nieuwe gegevens te produceren (bijvoorbeeld voor versleuteling of ondertekening), maar kan deze nog steeds worden gebruikt om gegevens te lezen (bijvoorbeeld voor ontsleuteling of verificatie).

Generatoren voor willekeurige getallen

Alle producten en services moeten cryptografische veilige generatoren voor willekeurige getallen gebruiken wanneer willekeurigheid vereist is.

CNG

BCryptGenRandom gebruiken met de BCRYPT_USE_SYSTEM_PREFERRED_RNG vlag

CAPI

Gebruik CryptGenRandom om willekeurige waarden te genereren.

Win32/64

Oudere code kan RtlGenRandom gebruiken in de kernelmodus
Nieuwe code moet BCryptGenRandom of CryptGenRandom gebruiken.
De functie C Rand_s() wordt ook aanbevolen (die op Windows CryptGenRandom belt)
Rand_s() is een veilige en performante vervanging voor Rand(). Rand() mag niet worden gebruikt voor cryptografische toepassingen, maar is alleen ok voor interne tests.
De functie SystemPrng wordt aanbevolen voor code in de kernelmodus.

.NET

Gebruik RNGCryptoServiceProvider of RNGCng.

Windows Store-apps

Store-apps kunnen CryptographicBuffer.GenerateRandom of CryptographicBuffer.GenerateRandomNumber gebruiken.

Niet aanbevolen

Onveilige functies met betrekking tot het genereren van willekeurige getallen zijn rand,System.Random (.NET), GetTickCount en GetTickCount64
Het gebruik van de dubbele elliptische curve random number generator ('DUAL_EC_DRBG')-algoritme wordt afgeraden.

Windows platform ondersteunde cryptobibliotheken

Op het Windows platform raadt Microsoft aan de crypto-API's te gebruiken die in het besturingssysteem zijn ingebouwd. Op andere platforms kunnen ontwikkelaars ervoor kiezen om niet-platform cryptobibliotheken te evalueren voor gebruik. Over het algemeen worden platformcryptobibliotheken vaker bijgewerkt omdat ze worden geleverd als onderdeel van een besturingssysteem, in plaats van dat ze worden gebundeld met een toepassing.

Elke gebruiksbeslissing met betrekking tot platform versus niet-platform crypto moet worden geleid door de volgende vereisten:

De bibliotheek moet een huidige in-supportversie zijn zonder bekende beveiligingsproblemen
De nieuwste beveiligingsprotocollen, algoritmen en sleutellengten moeten worden ondersteund
(Optioneel) De bibliotheek moet in staat zijn oudere beveiligingsprotocollen/algoritmen alleen te ondersteunen voor compatibiliteit met achterwaartse gegevens

Native Code

Crypto-primitmiteert: als uw release is Windows of Windows Phone, gebruikt u CNG indien mogelijk. Gebruik anders de CryptoAPI (ook wel CAPI genoemd, die wordt ondersteund als een oud onderdeel op Windows vanaf Windows Vista).
SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2of IXMLHTTPRequest3.
- WinHTTP-apps moeten worden gemaakt met WinHttpSetOption om TLS 1.2 te ondersteunen
Verificatie van codehandtekeningen: WinVerifyTrust is de ondersteunde API voor het verifiëren van codehandtekeningen op Windows platforms.
Certificaatvalidatie (zoals gebruikt in beperkte certificaatvalidatie voor code ondertekening of SSL/TLS/DTLS): CAPI2 API; bijvoorbeeld CertGetCertificateChain en CertVerifyCertificateChainPolicy

Beheerde code

Crypto-primitief: Gebruik de API die is gedefinieerd in System.Security.Cryptography namespace--- de CNG-klassen hebben de voorkeur.
Gebruik de nieuwste versie van het .Net Framework dat beschikbaar is. Dit moet minimaal .Net Framework versie 4.6 zijn. Als een oudere versie vereist is, moet u ervoor zorgen dat de regkeySchUseStrongCrypto is ingesteld om TLS 1.2 in te stellen voor de toepassing in kwestie.
Certificaatvalidatie: Gebruik API's die zijn gedefinieerd onder de naamruimte System.Security.Cryptography.X509Certificates.
SSL/TLS/DTLS: GEBRUIK API's die zijn gedefinieerd onder de System.Net naamruimte (bijvoorbeeld HttpWebRequest).

Belangrijke afleidingsfuncties

Sleutelversleuteling is het proces waarbij cryptografische sleutelmateriaal wordt afgeleid van een gedeeld geheim of een bestaande cryptografische sleutel. Voor producten moeten de aanbevolen functies voor het afleidingsgebeuren worden gebruikt. Het gebruik van sleutels van door de gebruiker gekozen wachtwoorden of het hashen van wachtwoorden voor opslag in een verificatiesysteem is een speciaal geval dat niet onder deze richtlijn valt. ontwikkelaars moeten een expert raadplegen.

In de volgende standaarden worden KDF-functies opgegeven die worden aanbevolen voor gebruik:

NIST SP 800-108: Aanbeveling voor sleutelverdeding met behulp van pseudorandomfuncties. Met name de KDF in de tellerstand, met HMAC als een pseudorandomfunctie
NIST SP 800-56A (revisie 2): Aanbeveling voor Pair-Wise key establishment schemes using Discrete Logarithm Cryptography. In het bijzonder wordt de functie 'Functie voor het ontraden van een enkele stap' in sectie 5.8.1 aanbevolen.

Als u sleutels wilt afleiden uit bestaande sleutels, gebruikt u de BCryptKeyDerivation-API met een van de algoritmen:

BCRYPT_SP800108_CTR_HMAC_ALGORITHM
BCRYPT_SP80056A_CONCAT_ALGORITHM

Als u sleutels wilt afleiden uit een gedeeld geheim (de uitvoer van een sleutelovereenkomst) gebruikt u de BCryptDeriveKey-API met een van de volgende algoritmen:

BCRYPT_KDF_SP80056A_CONCAT
BCRYPT_KDF_HMAC

Certificaatvalidatie

Producten die SSL, TLS of DTLS gebruiken, moeten de X.509-certificaten van de entiteiten met waar ze verbinding mee maken, volledig verifiëren. Dit geldt ook voor verificatie van de certificaten:

Domeinnaam.
Geldigheidsdatums (zowel begin- als vervaldatums).
Intrekkingsstatus.
Gebruik (bijvoorbeeld 'Serververificatie' voor servers, 'Clientverificatie' voor clients).
Vertrouwensketen. Certificaten moeten worden geketend naar een hoofdcertificeringsinstantie (CA) die wordt vertrouwd door het platform of expliciet is geconfigureerd door de beheerder.

Als een van deze verificatietests mislukt, moet het product de verbinding met de entiteit beëindigen.

Clients die vertrouwen op 'zelf ondertekende' certificaten (bijvoorbeeld een e-mailclient die verbinding maakt met een Exchange-server in een standaardconfiguratie) kunnen controle van certificaten negeren. Zelf ondertekende certificaten brengen echter niet inherent vertrouwen over, ondersteunen intrekking of ondersteuning van sleutelvernieuwing. U moet alleen zelfondertekende certificaten vertrouwen als u deze hebt verkregen uit een andere vertrouwde bron (bijvoorbeeld een vertrouwde entiteit die het certificaat verstrekt via een geverifieerd en met integriteit beveiligd transport).

Cryptografische hashfuncties

Producten moeten de SHA-2-familie van hash-algoritmen (SHA256, SHA384 en SHA512) gebruiken. Het wordt afgeraden om cryptografische hashes voor beveiligingsdoeleinden af te ronden tot minder dan 128 bits.

MAC/HMAC/keyed hash algorithms

Een berichtverificatiecode (MAC) is een stukje informatie dat is gekoppeld aan een bericht waarmee de geadresseerde zowel de echtheid van de afzender als de integriteit van het bericht kan verifiëren met een geheime sleutel.

Het gebruik van een mac op basis van hash(HMAC) of mac met blokcodering wordt aanbevolen, zolang alle onderliggende hash- of symmetrische versleutelingsalgoritmen ook worden aanbevolen voor gebruik. Dit omvat momenteel de functies HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 en HMAC-SHA512).

Het wordt afgeraden om HMACs uit te delen tot minder dan 128 bits.

Ontwerp- en operationele overwegingen

U moet zo nodig een mechanisme bieden voor het vervangen van cryptografische sleutels. Sleutels moeten worden vervangen zodra ze het einde van hun actieve levensduur hebben bereikt of als de cryptografische sleutel is gehackt. Wanneer u een certificaat verlengt, moet u dit verlengen met een nieuwe sleutel.
Producten die cryptografische algoritmen gebruiken om gegevens te beschermen, moeten voldoende metagegevens bevatten, samen met die inhoud, zodat ze in de toekomst kunnen worden gemigreert naar verschillende algoritmen. Dit moet het gebruikte algoritme, de sleutelgrootten, initialisatievectoren en opvullingsmodi bevatten.
- Zie Cryptographic Agile op MSDN voor meer informatie over Cryptographic Agile.
Waar beschikbaar moeten producten gebruikmaken van bestaande, platformverkende cryptografische protocollen in plaats van ze opnieuw te implementeren. Dit geldt ook voor ondertekeningsindelingen (bijvoorbeeld het gebruik van een standaardnotatie, bestaande indeling).
Symmetrische stroomcodes, zoals RC4, mogen niet worden gebruikt. In plaats van symmetrische stroomcodes moeten producten een blokcoder gebruiken, met name AES met een sleutellengte van ten minste 128 bits.
Cryptografische bewerkingsfouten niet rapporteren aan eindgebruikers. Als u een fout retournt naar een externe beller (bijvoorbeeld een webclient of client in een clientserverscenario), gebruikt u alleen een algemeen foutbericht.
- Vermijd het verstrekken van overbodige informatie, zoals het rechtstreeks rapporteren van fouten buiten het bereik of ongeldige lengtefouten. Log verbose fouten alleen op de server en alleen als uitgebreide logboekregistratie is ingeschakeld.
Extra beveiligingsbeoordeling wordt ten zeerste aanbevolen voor elk ontwerp met de volgende elementen:
- Een nieuw protocol dat voornamelijk is gericht op beveiliging (zoals een verificatie- of autorisatieprotocol)
- Een nieuw protocol dat gebruikmaakt van cryptografie op een nieuwe of niet-standaard manier o Voorbeeldoverwegingen zijn:
  - Wordt een product dat het protocol implementeert, crypto-API's of methoden aanroepen als onderdeel van de implementatie van het protocol?
  - Is het protocol afhankelijk van een ander protocol dat wordt gebruikt voor verificatie of autorisatie?
  - Definieert het protocol opslagindelingen voor cryptografische elementen, zoals sleutels?
Zelf ondertekende certificaten worden niet aanbevolen voor productieomgevingen. Het gebruik van een zelf ondertekend certificaat, zoals het gebruik van een onbewerkte cryptografische sleutel, biedt gebruikers of beheerders geen basis voor het maken van een vertrouwensbeslissing.
- Het gebruik van een certificaat dat is gebaseerd op een vertrouwde certificeringsinstantie, maakt daarentegen duidelijk de basis voor het vertrouwen op de bijbehorende persoonlijke sleutel en maakt intrekking en updates in geval van een beveiligingsfout mogelijk.

Gevoelige gegevens versleutelen vóór Storage

DPAPI/DPAPI-NG

Voor gegevens die moeten blijven bestaan in systeem reboots:

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (Windows 8 CNG DPAPI)

Voor gegevens die niet hoeven te worden gebruikt in systeem reboots:

CryptProtectMemory
CryptUnprotectMemory

Voor gegevens die door meerdere domeinaccounts en computers moeten worden gebruikt en toegankelijk:

NCryptProtectSecret (in CNG DPAPI, beschikbaar vanaf Windows 8)
Microsoft Azure KeyVault

SQL Server TDE

U kunt de SQL Server Transparent Data Encryption (TDE) gebruiken om gevoelige gegevens te beveiligen.

U moet een TDE-databaseversleutelingssleutel (DEK) gebruiken die voldoet aan de SDL-cryptografische algoritme en de sleutelsterktevereisten. Momenteel worden alleen AES_128, AES_192 en AES_256 aanbevolen. TRIPLE_DES_3KEY wordt niet aanbevolen.

Er zijn enkele belangrijke aandachtspunten voor het gebruik SQL TDE waar u rekening mee moet houden:

SQL Server biedt geen ondersteuning voor versleuteling voor FILESTREAM-gegevens, zelfs niet wanneer TDE is ingeschakeld.
TDE biedt niet automatisch versleuteling voor gegevens die van of naar de database worden overgeslagen. u moet ook versleutelde verbindingen met de SQL Server inschakelen. Zie Versleuteldeverbindingen met de database-engine (SQL Server Configuration Manager) inschakelen voor informatie over het inschakelen van versleutelde verbindingen.
Als u een met TDE beveiligde database verplaatst naar een ander SQL Server-exemplaar, moet u ook het certificaat verplaatsen dat de TDE-gegevensversleutelingssleutel (DEK) beschermt en deze installeren in de hoofddatabase van het SQL Server-exemplaar. Zie het TechNet-artikel Een TDE-beveiligdedatabase verplaatsen naar een andere SQL Server voor meer informatie.

Referentiebeheer

Gebruik de Windows Credential Manager API of Microsoft Azure KeyVault om wachtwoord- en referentiegegevens te beveiligen.

Windows Store-apps

Gebruik de klassen in de Windows. Security.Cryptography en Windows. Security.Cryptography.DataProtection namespaces to protect secrets and sensitive data.

ProtectAsync
ProtectStreamAsync
Beveiliging opheffenAsync
Beveiliging opheffenStreamAsync

Gebruik de klassen in de Windows. Security.Credentials namespace om wachtwoord- en referentiegegevens te beveiligen.

.NET