Cryptografische microsoft SDL-Aanbevelingen

Artikel
02/07/2024

Inleiding

Dit document bevat aanbevelingen en aanbevolen procedures voor het gebruik van versleuteling op Microsoft-platforms. Veel van de inhoud hier is geparafraseerd of samengevoegd op basis van de eigen interne beveiligingsstandaarden van Microsoft die worden gebruikt om de levenscyclus van security development 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 nodig heeft voor eigen producten en services.

Ontwikkelaars op niet-Windows-platforms kunnen ook profiteren van deze aanbevelingen. Hoewel de API- en bibliotheeknamen kunnen verschillen, zijn de aanbevolen procedures met betrekking tot de keuze van het algoritme, de sleutellengte en gegevensbescherming op verschillende platforms vergelijkbaar.

Beveiligingsprotocol, algoritme en sleutellengte Aanbevelingen

SSL-/TLS-versies

Producten en services moeten cryptografisch 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 eerdere versies
SSL 3 en SSL 2 moeten standaard worden uitgeschakeld

Symmetrische blok ciphers, coderingsmodi en initialisatievectors

Coderingen blokkeren

Voor producten die symmetrische blok-coderingen gebruiken:

Advanced Encryption Standard (AES) wordt aanbevolen voor nieuwe code.
Drie-sleutel triple Data Encryption Standard (3DES) is toegestaan in bestaande code voor achterwaartse compatibiliteit.
Alle andere blokcoderingen, waaronder RC2, DES, 2-Key 3DES, DESX en Skipjack, mogen alleen worden gebruikt voor het ontsleutelen van oude gegevens en moeten worden vervangen als ze worden gebruikt voor versleuteling.

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

Coderingsmodi

Symmetrische algoritmen kunnen in verschillende modi worden gebruikt, waarvan de meeste de versleutelingsbewerkingen aan opeenvolgende blokken met tekst zonder opmaak en codering koppelen.

Symmetrische blok-coderingen moeten worden gebruikt met een van de volgende coderingsmodi:

Cipher Block Chaining (CBC)
Ciphertext Stealing (CTS)
XEX-based Tweaked-Codebook with Ciphertext Stealing (XTS)

Sommige andere coderingsmodi, zoals hieronder, hebben valkuilen voor de implementatie waardoor ze waarschijnlijker onjuist worden gebruikt. In het bijzonder moet de werkingsmodus van het Electronic Code Book (ECB) worden vermeden. Als u dezelfde initialisatievector (IV) hergebruikt met blokcoderingen in 'modi voor streaming-coderingen', zoals CTR, kunnen versleutelde gegevens worden onthuld. Aanvullende beveiligingsbeoordeling wordt aanbevolen als een van de onderstaande modi wordt gebruikt:

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

Initialisatievectoren (IV)

Alle symmetrische blok-coderingen moeten ook worden gebruikt met een cryptografisch sterk willekeurig getal als initialisatievector. Initialisatievectors mogen nooit een constante waarde zijn. Zie Generatoren voor willekeurige getallen voor aanbevelingen voor het genereren van cryptografische sterke willekeurige getallen.

Initialisatievectors mogen nooit opnieuw worden gebruikt bij het uitvoeren van meerdere versleutelingsbewerkingen, omdat hiermee informatie kan worden weergegeven over de gegevens die worden versleuteld, met name bij het gebruik van streaming-coderingsmodi zoals Uitvoerfeedback (OFB) of Teller (CTR).

Asymmetrische algoritmen, sleutellengten en opvullingsmodi

RSA

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

ECDSA

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

ECDH

ECDH met >= 256-bits sleutels wordt aanbevolen
Ecdh-gebaseerde sleuteluitwisseling moet gebruikmaken van een van de drie NIST-goedgekeurde curven (P-256, P-384 of P521).

Geheel getal Diffie-Hellman

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

Sleutellevensduur

Alle asymmetrische sleutels moeten een maximale levensduur van vijf jaar hebben, aanbevolen levensduur van één jaar.
Alle symmetrische sleutels moeten een maximale levensduur van drie jaar hebben; aanbevolen levensduur van één jaar.
U moet een mechanisme opgeven 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 nog steeds worden gebruikt om gegevens te lezen (bijvoorbeeld voor ontsleuteling of verificatie).

Generatoren voor willekeurige getallen

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

CNG

BCryptGenRandom gebruiken met de vlag BCRYPT_USE_SYSTEM_PREFERRED_RNG

CAPI

Gebruik CryptGenRandom om willekeurige waarden te genereren.

Win32/64

Verouderde code kan RtlGenRandom gebruiken in kernelmodus
Nieuwe code moet BCryptGenRandom of CryptGenRandom gebruiken.
De C-functie Rand_s() wordt ook aanbevolen (die in Windows CryptGenRandom aanroept)
Rand_s() is een veilige en goed presterende vervanging voor Rand(). Rand() mag niet worden gebruikt voor cryptografische toepassingen, maar is alleen geschikt voor interne tests.
De functie SystemPrng wordt aanbevolen voor kernelmoduscode.

.NET

RNGCryptoServiceProvider gebruiken

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 het algoritme voor willekeurige getalgenerator met dubbele elliptische curven ('DUAL_EC_DRBG') wordt niet aanbevolen.

Door Windows Platform ondersteunde cryptobibliotheken

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

Elke gebruiksbeslissing met betrekking tot platform versus niet-platform crypto moet worden begeleid 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 alleen oudere beveiligingsprotocollen/algoritmen kunnen ondersteunen voor compatibiliteit met eerdere versies

Systeemeigen code

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

Beheerde code

Crypto Primitives: Gebruik de API die is gedefinieerd in System.Security.Cryptography-naamruimte---de CNG-klassen hebben de voorkeur.
Gebruik de nieuwste versie van .Net Framework die beschikbaar is. Dit moet minimaal .Net Framework versie 4.6 zijn. Als een oudere versie is vereist, moet u ervoor zorgen dat de regkey 'SchUseStrongCrypto' is ingesteld om TLS 1.2 in te schakelen voor de betreffende toepassing.
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

Sleutelontduivatie is het proces van het afleiden van cryptografisch sleutelmateriaal uit een gedeeld geheim of een bestaande cryptografische sleutel. Producten moeten aanbevolen belangrijke afleidingsfuncties gebruiken. Het afleiden van sleutels van door de gebruiker gekozen wachtwoorden of hash-wachtwoorden voor opslag in een verificatiesysteem is een speciaal geval dat niet wordt gedekt door deze richtlijnen; ontwikkelaars moeten een expert raadplegen.

De volgende standaarden geven KDF-functies op die worden aanbevolen voor gebruik:

NIST SP 800-108: Aanbeveling voor belangrijke afleiding met behulp van pseudorandomfuncties. Met name de KDF in de tellermodus, met HMAC als pseudorandomfunctie
NIST SP 800-56A (revisie 2): aanbeveling voor pair-wise belangrijke inrichtingsschema's met behulp van discrete logaritme cryptografie. In het bijzonder wordt de functie 'Sleutel derivatie met één stap' in sectie 5.8.1 aanbevolen.

Als u sleutels wilt afleiden van 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 van 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 gebruikmaken van SSL, TLS of DTLS moeten de X.509-certificaten van de entiteiten waarmee ze verbinding maken, volledig verifiëren. Dit omvat verificatie van de certificaten':

Domeinnaam.
Geldigheidsdatums (zowel begin- als vervaldatums).
Intrekkingsstatus.
Gebruik (bijvoorbeeld 'Serververificatie' voor servers, 'Clientverificatie' voor clients).
Vertrouwensketen. Certificaten moeten worden gekoppeld aan een basiscertificeringsinstantie (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 zelfondertekende certificaten vertrouwen (bijvoorbeeld een e-mailclient die verbinding maakt met een Exchange-server in een standaardconfiguratie), kunnen verificatiecontroles van certificaten negeren. Zelfondertekende certificaten geven echter niet inherent vertrouwen, ondersteuning intrekken of het verlengen van ondersteuningssleutels. U moet alleen zelfondertekende certificaten vertrouwen als u ze hebt verkregen uit een andere vertrouwde bron (bijvoorbeeld een vertrouwde entiteit die het certificaat levert via een geverifieerd en met integriteit beveiligd transport).

Cryptografische hashfuncties

Producten moeten gebruikmaken van de SHA-2-serie hash-algoritmen (SHA256, SHA384 en SHA512). Afkapping van cryptografische hashes voor beveiligingsdoeleinden tot minder dan 128 bits wordt niet aanbevolen.

MAC/HMAC/keyed hash-algoritmen

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

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

Afkapping van HMAC's tot minder dan 128 bits wordt niet aanbevolen.

Ontwerp- en operationele overwegingen

U moet zo nodig een mechanisme opgeven 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 aangetast. Wanneer u een certificaat verlengt, moet u het vernieuwen met een nieuwe sleutel.
Producten die cryptografische algoritmen gebruiken om gegevens te beveiligen, moeten voldoende metagegevens bevatten, samen met die inhoud ter ondersteuning van migratie naar verschillende algoritmen in de toekomst. Dit omvat het gebruikte algoritme, sleutelgrootten, initialisatievectors en opvullingsmodi.
- Zie Cryptografische flexibiliteit op MSDN voor meer informatie over cryptografische flexibiliteit.
Waar beschikbaar moeten producten gebruikmaken van gevestigde, door het platform geleverde cryptografische protocollen in plaats van ze opnieuw te implementeren. Dit omvat ondertekeningsindelingen (bijvoorbeeld een standaard, bestaande indeling).
Symmetrische stream-coderingen zoals RC4 mogen niet worden gebruikt. In plaats van symmetrische stream-coderingen moeten producten een blok-codering gebruiken, met name AES met een sleutellengte van ten minste 128 bits.
Rapporteer geen cryptografische bewerkingsfouten aan eindgebruikers. Wanneer u een fout retourneert naar een externe beller (bijvoorbeeld webclient of client in een clientserverscenario), gebruikt u alleen een algemeen foutbericht.
- Vermijd onnodige informatie, zoals het rechtstreeks rapporteren van fouten buiten het bereik of ongeldige lengtefouten. Alleen uitgebreide fouten op de server vastleggen en alleen als uitgebreide logboekregistratie is ingeschakeld.
Aanvullende beveiligingsbeoordeling wordt ten zeerste aanbevolen voor elk ontwerp dat het volgende bevat:
- Een nieuw protocol dat voornamelijk gericht is 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 aangeroepen als onderdeel van de protocolimplementatie?
  - Is het protocol afhankelijk van een ander protocol dat wordt gebruikt voor verificatie of autorisatie?
  - Definieert het protocol opslagindelingen voor cryptografische elementen, zoals sleutels?
Zelfondertekende certificaten worden niet aanbevolen voor productieomgevingen. Het gebruik van een zelfondertekend certificaat, zoals het gebruik van een onbewerkte cryptografische sleutel, biedt gebruikers of beheerders geen basis voor het nemen van een vertrouwensbeslissing.
- Het gebruik van een certificaat dat is geroot in een vertrouwde certificeringsinstantie maakt daarentegen duidelijk de basis voor het vertrouwen op de bijbehorende persoonlijke sleutel en maakt intrekking en updates mogelijk in geval van een beveiligingsfout.

Gevoelige gegevens versleutelen vóór opslag

DPAPI/DPAPI-NG

Voor gegevens die moeten worden bewaard tijdens het opnieuw opstarten van het systeem:

CryptProtectData
CryptUnprotectData
NCryptProtectSecret (Windows 8 CNG DPAPI)

Voor gegevens die niet hoeven te worden bewaard tijdens het opnieuw opstarten van het systeem:

CryptProtectMemory
CryptUnprotectMemory

Voor gegevens die moeten worden bewaard en geopend door meerdere domeinaccounts en computers:

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

SQL Server TDE

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

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

Er zijn enkele belangrijke overwegingen voor het gebruik van SQL TDE waarmee u rekening 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 onderweg zijn naar of van de database; U moet ook versleutelde verbindingen met de SQL Server-database inschakelen. Zie Versleutelde Verbinding maken-instructies inschakelen voor de Database Engine (SQL Server Configuration Manager) voor hulp bij het inschakelenvan versleutelde verbindingen.
Als u een met TDE beveiligde database naar een ander SQL Server-exemplaar verplaatst, moet u ook het certificaat verplaatsen dat de TDE Data Encryption Key (DEK) beveiligt en installeert in de hoofddatabase van het doel-SQL Server-exemplaar. Zie het TechNet-artikel Een met TDEbeveiligde database 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 naamruimten Windows.Security.Cryptography en Windows.Security.Cryptography.DataProtection om geheimen en gevoelige gegevens te beveiligen.

ProtectAsync
ProtectStreamAsync
Beveiliging opheffen
ProtectStreamAsync opheffen

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

.NET