Delen via

Cryptografische aanbevelingen voor Microsoft SDL

  • Artikel

Gebruik deze informatie 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. Veel van de inhoud is gebaseerd op de eigen interne beveiligingsstandaarden van Microsoft die worden gebruikt om de levenscyclus voor beveiligingsontwikkeling te maken.

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

Aanbevelingen voor beveiligingsprotocol, algoritme en sleutellengte

TLS/SSL-versies

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

  • TLS 1.3 moet zijn ingeschakeld.
  • TLS 1.2 kan worden ingeschakeld om de compatibiliteit met oudere clients te verbeteren.
  • TLS 1.1, TLS 1.0, SSL 3 en SSL 2 moeten zijn uitgeschakeld

Symmetrische blok-coderingsmodi, coderingsmodi en initialisatievectors

Coderingen blokkeren

Voor producten die symmetrische blok-coderingen gebruiken:

  • Advanced Encryption Standard (AES) wordt aanbevolen.
  • Alle andere blokcoderingen, waaronder 3DES (Triple DES/TDEA), en RC4 moeten worden vervangen als ze worden gebruikt voor versleuteling.

Voor symmetrische blokversleutelingsalgoritmen is een minimale sleutellengte van 128 bits vereist, maar we raden u aan 256-bits sleutels te ondersteunen. 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).

Coderingsmodi

Symmetrische algoritmen kunnen worden uitgevoerd in verschillende modi, 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:

Sommige andere coderingsmodi, zoals die volgen, hebben valkuilen in 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. Extra beveiligingsbeoordeling wordt aanbevolen als een van de onderstaande modi wordt gebruikt:

  • Feedback over uitvoer (OFB)
  • Feedback over codering (ENCRYPTION)
  • Teller (CTR)
  • Niets anders dan in de voorgaande lijst 'aanbevolen'

Initialisatievectoren (IV)

Alle symmetrische blok-coderingen moeten ook worden gebruikt met een cryptografisch sterk willekeurig getal als initialisatievector. Initialisatievectors mogen nooit een constante of prediceerbare 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. Hergebruik kan informatie onthullen over de gegevens die worden versleuteld, met name bij het gebruik van streaming-coderingsmodi zoals Uitvoerfeedback (OFB) of Teller (CTR).

AES-GCM & AES-CCM-aanbevelingen

AES-GCM (Galois/Counter Mode) en AES-CCM (Teller met CBC-MAC) worden veel gebruikt geverifieerde versleutelingsmodi. Ze combineren vertrouwelijkheids- en integriteitsbescherming, waardoor ze nuttig zijn voor veilige communicatie. Hun fragiliteit ligt echter in niet-hergebruik. Wanneer dezelfde nonce (initialisatievector) tweemaal wordt gebruikt, kan dit leiden tot catastrofale gevolgen.

We raden u aan de nonce-richtlijnen te volgen zoals beschreven in NIST SP 800-38D, aanbeveling voor blokcoderingsmodi van werking: Galois/Counter Mode (GCM) en GMAC, waarbij speciale aandacht wordt besteed aan sectie 8.3 met betrekking tot het maximum aantal aanroepen.

Een andere optie wordt gegenereerd unieke AES-GCM/CCM-sleutels voor elk bericht dat wordt versleuteld, waardoor het maximum aantal aanroepen wordt beperkt tot 1. Deze methode wordt aanbevolen voor het versleutelen van data-at-rest, waarbij het gebruik van een teller of het bijhouden van het maximum aantal aanroepen voor een bepaalde sleutel onpraktisch is.

Voor het versleutelen van data-at-rest kunt u ook overwegen AES-CBC te gebruiken met een berichtverificatiecode (MAC) als alternatief met behulp van een Encrypt-then-MAC-schema, waarbij u ervoor zorgt dat u afzonderlijke sleutels gebruikt voor versleuteling en voor de MAC.

Integriteitsverificatie

Het is een veelvoorkomende misvatting dat versleuteling standaard zowel vertrouwelijkheid als integriteitsgarantie biedt. Veel versleutelingsalgoritmen bieden geen integriteitscontrole en zijn mogelijk kwetsbaar voor manipulatieaanvallen. Er moeten extra stappen worden ondernomen om de integriteit van gegevens te waarborgen voordat ze worden verzonden en na ontvangst.

Als u geen geverifieerd versleutelingsalgoritme kunt gebruiken met gekoppelde gegevens (AEAD), zoals AES-GCM, kunt u ook de integriteit valideren met een berichtverificatiecode (MAC) met behulp van een versleutelings- en MAC-schema, zodat u afzonderlijke sleutels gebruikt voor versleuteling en voor de MAC.

Het gebruik van een afzonderlijke sleutel voor versleuteling en voor de MAC is essentieel. Als het niet mogelijk is om de twee sleutels op te slaan, is een geldig alternatief om twee sleutels af te leiden van de hoofdsleutel met behulp van een geschikte functie voor sleutelafleiden (KDF), één voor versleutelingsdoeleinden en één voor MAC. Zie SP 800-108 Rev. 1, Aanbeveling voor Key Derivation Using Pseudorandom Functions | CSRC (nist.gov).

Asymmetrische algoritmen, sleutellengten en opvullingsmodi

RSA

  • RSA kan 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.
  • Minimaal een 2048-bits sleutellengte wordt aanbevolen, maar we raden u aan een 3072-bits sleutellengte te ondersteunen.

ECDSA en ECDH

  • Op ECDH gebaseerde sleuteluitwisseling en op ECDSA gebaseerde handtekeningen moeten gebruikmaken van een van de drie NIST-goedgekeurde curven (P-256, P-384 of P521).
  • Ondersteuning voor P-256 moet als minimum worden beschouwd, maar we raden u aan P-384 te ondersteunen.

Geheel getal Diffie-Hellman

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

Sleutellevensduur

  • Definieer een cryptoperiode voor alle sleutels.
    • Bijvoorbeeld: Een symmetrische sleutel voor gegevensversleuteling, ook wel gegevensversleutelingssleutel of DEK genoemd, kan een gebruiksperiode van maximaal twee jaar hebben voor het versleutelen van gegevens, ook wel bekend als de gebruiksperiode van de oorsprongsteller. U kunt definiëren dat deze een geldige gebruiksperiode heeft voor ontsleuteling gedurende drie jaar, ook wel bekend als de periode voor het gebruik van geadresseerden.
  • 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

Win32/64

  • Verouderde code kan RtlGenRandom gebruiken in de 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.

.NET

Powershell

Windows Store-apps

Linux/macOS

  • Het /dev/urandom apparaat biedt een cryptografisch sterke bron van willekeurige gegevens, net zoals de getrandom(2) systeemoproep.
  • Onveilige functies met betrekking tot het genereren van willekeurige getallen zijn onder andere: rand, System.Random (.NET), GetTickCount, GetTickCount64 en Get-Random (PowerShell-cmdlet).
  • Het gebruik van het algoritme voor willekeurige getalgenerator met dubbele elliptische curven ('DUAL_EC_DRBG') is niet toegestaan.

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 geleid door de volgende vereisten:

  • De bibliotheek moet een huidige in-ondersteuningsversie zijn zonder bekende beveiligingsproblemen.
  • De meest recente 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 bevindt, gebruikt u CNG, indien mogelijk.
  • 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 (.NET)

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 (revisie 1): aanbeveling voor sleutelontzetting met behulp van pseudorandomfuncties. Met name de KDF in de tellermodus, met HMAC als pseudorandomfunctie
  • NIST SP 800-56A (revisie 3): aanbeveling voor pair-wise sleutelinrichtingsschema's met behulp van discrete logaritme cryptografie.

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 TLS of DTLS moeten de X.509-certificaten van de entiteiten waarmee ze verbinding maken, volledig verifiëren. Dit proces omvat verificatie van de volgende onderdelen van het certificaat:

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

Gebruik geen zelfondertekende certificaten. Zelfondertekend geeft niet inherent vertrouwen, ondersteuning intrekken of het verlengen van ondersteuningssleutels.

Cryptografische hashfuncties

Producten moeten gebruikmaken van de SHA-2-serie hash-algoritmen (SHA-256, SHA-384 en SHA-512). Het afkappen van cryptografische hashes voor beveiligingsdoeleinden tot minder dan 128 bits is niet toegestaan. Hoewel het gebruik van SHA-256 het minimum is, raden we u aan SHA-384 te ondersteunen.

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). Hoewel het gebruik van HMAC-SHA256 het minimum is, raden we u aan HMAC-SHA384 te ondersteunen.

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. Deze metagegevens moeten het gebruikte algoritme, sleutelgrootten en opvullingsmodi bevatten.
  • Waar beschikbaar moeten producten gebruikmaken van gevestigde, door het platform geleverde cryptografische protocollen in plaats van ze opnieuw te implementeren, inclusief ondertekeningsindelingen (bijvoorbeeld een standaard, bestaande indeling).
  • Rapporteer geen cryptografische bewerkingsfouten aan eindgebruikers. Wanneer u een fout retourneert naar een externe beller (bijvoorbeeld een 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.
  • Extra beveiligingsbeoordeling wordt ten zeerste aanbevolen voor elk ontwerp met de volgende items:
    • Een nieuw protocol dat voornamelijk gericht is op beveiliging (zoals een verificatie- of autorisatieprotocol)
    • Een nieuw protocol dat cryptografie op een nieuwe of niet-standaard manier gebruikt. Voorbeelden van overwegingen 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. 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 als er sprake is van een beveiligingsfout.