Kryptografiska rekommendationer för Microsoft SDL

Introduktion

Det här dokumentet innehåller rekommendationer och metodtips för att använda kryptering på Microsoft-plattformar. Mycket av innehållet här parafraseras eller aggregeras från Microsofts egna interna säkerhetsstandarder som används för att skapa livscykeln för säkerhetsutveckling. Den är avsedd att användas som referens när du utformar produkter för att använda samma API:er, algoritmer, protokoll och nyckellängder som Microsoft kräver av sina egna produkter och tjänster.

Utvecklare på plattformar som inte kommer från Windows kan också dra nytta av dessa rekommendationer. Även om API- och biblioteksnamnen kan skilja sig åt liknar metodtipsen för algoritmval, nyckellängd och dataskydd på olika plattformar.

Rekommendationer för säkerhetsprotokoll, algoritm och nyckellängd

SSL/TLS-versioner

Produkter och tjänster bör använda kryptografiskt säkra versioner av SSL/TLS:

  • TLS 1.2 ska vara aktiverat

  • TLS 1.1 och TLS 1.0 bör endast aktiveras för bakåtkompatibilitet

  • SSL 3 och SSL 2 bör inaktiveras som standard

Symmetriska block chiffer, chifferlägen och initieringsvektorer

Blockera chiffer

För produkter som använder symmetriska block chiffer:

  • Advanced Encryption Standard (AES) rekommenderas för ny kod.

  • Trenyckels trippel datakrypteringsstandard (3DES) är tillåten i befintlig kod för bakåtkompatibilitet.

  • Alla andra block chiffer, inklusive RC2, DES, 2-Key 3DES, DESX och Skipjack, bör endast användas för dekryptering av gamla data och bör ersättas om de används för kryptering.

För symmetriska blockkrypteringsalgoritmer rekommenderas en minsta nyckellängd på 128 bitar. Den enda blockkrypteringsalgoritm som rekommenderas för ny kod är AES (AES-128, AES-192 och AES-256 är alla acceptabla, och konstaterar att AES-192 saknar optimering på vissa processorer). 3DES med tre nycklar är för närvarande acceptabelt om det redan används i befintlig kod. övergång till AES rekommenderas. DES, DESX, RC2 och Skipjack anses inte längre vara säkra. Dessa algoritmer bör endast användas för att dekryptera befintliga data för bakåtkompatibilitet, och data bör krypteras om med hjälp av ett rekommenderat blockkryptering.

Chifferlägen

Symmetriska algoritmer kan användas i en mängd olika lägen, varav de flesta länkar ihop krypteringsåtgärderna på efterföljande block av klartext och chiffertext.

Symmetriska block chiffer ska användas med något av följande chifferlägen:

Vissa andra chifferlägen som de som ingår nedan har implementeringsgropar som gör att de är mer benägna att användas felaktigt. I synnerhet bör man undvika att använda den elektroniska kodboken (ECB). Återanvändning av samma initieringsvektor (IV) med block chiffer i "strömmande chifferlägen", till exempel CTR, kan leda till att krypterade data avslöjas. Ytterligare säkerhetsgranskning rekommenderas om något av nedanstående lägen används:

  • Feedback om utdata (OFB)

  • Chifferfeedback (CFB)

  • Räknare (CTR)

  • Räknare med CBC-MAC (CCM)

  • Galois/Counter Mode (GCM)

  • Allt annat som inte finns med i listan "rekommenderas" ovan

Initieringsvektorer (IV)

Alla symmetriska block chiffer bör också användas med ett kryptografiskt starkt slumpmässigt tal som initieringsvektor. Initieringsvektorer bör aldrig vara ett konstant värde. Se Slumptalsgeneratorer för rekommendationer om hur du genererar kryptografiskt starka slumpmässiga tal.

Initieringsvektorer bör aldrig återanvändas när du utför flera krypteringsåtgärder, eftersom detta kan avslöja information om de data som krypteras, särskilt när du använder strömnings chifferlägen som Utdatafeedback (OFB) eller räknare (CTR).

Asymmetriska algoritmer, nyckellängder och utfyllnadslägen

RSA

  • RSA bör användas för kryptering, nyckelutbyte och signaturer.

  • RSA-kryptering bör använda utfyllnadslägena OAEP eller RSA-PSS. Befintlig kod bör endast använda PKCS #1 v1.5-utfyllnadsläge för kompatibilitet.

  • Användning av null-utfyllnad rekommenderas inte.

  • Nycklar >= 2 048 bitar rekommenderas

ECDSA

  • ECDSA med >= 256 bitars nycklar rekommenderas

  • ECDSA-baserade signaturer bör använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521).

ECDH

  • ECDH med >= 256 bitars nycklar rekommenderas

  • ECDH-baserat nyckelutbyte bör använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521).

Integer Diffie-Hellman

  • Nyckellängd >= 2 048 bitar rekommenderas

  • Gruppparametrarna ska antingen vara en välkänd namngiven grupp (t.ex. RFC 7919) eller genereras av en betrodd part och autentiseras före användning

Nyckellivslängder

  • Alla asymmetriska nycklar bör ha en maximal livslängd på fem år, vilket rekommenderas ett års livslängd.

  • Alla symmetriska nycklar bör ha en livslängd på högst tre år. rekommenderad livslängd på ett år.

  • Du bör tillhandahålla en mekanism eller ha en process för att ersätta nycklar för att uppnå den begränsade aktiva livslängden. Efter slutet av den aktiva livslängden ska en nyckel inte användas för att producera nya data (till exempel för kryptering eller signering), utan kan fortfarande användas för att läsa data (till exempel för dekryptering eller verifiering).

Slumptalsgeneratorer

Alla produkter och tjänster bör använda kryptografiskt säkra slumptalsgeneratorer när slumpmässighet krävs.

CNG

CAPI

Win32/64

  • Äldre kod kan använda RtlGenRandom i kernelläge

  • Ny kod bör använda BCryptGenRandom eller CryptGenRandom.

  • Funktionen C Rand_s() rekommenderas också (som i Windows anropar CryptGenRandom)

  • Rand_s() är en säker och högpresterande ersättning för Rand(). Rand() bör inte användas för några kryptografiska program, men är endast ok för intern testning.

  • Funktionen SystemPrng rekommenderas för kernellägeskod.

.NET

Windows Store-appar

Rekommenderas inte

  • Osäkra funktioner som rör slumptalsgenerering inkluderar rand,System.Random (.NET), GetTickCount och GetTickCount64

  • Användning av slumptalsgeneratorn med dubbla elliptiska kurvor ("DUAL_EC_DRBG") rekommenderas inte.

Windows Platform-stödda kryptobibliotek

På Windows-plattformen rekommenderar Microsoft att du använder de krypto-API:er som är inbyggda i operativsystemet. På andra plattformar kan utvecklare välja att utvärdera icke-plattformskrypteringsbibliotek för användning. I allmänhet uppdateras plattformskryptbibliotek oftare eftersom de levereras som en del av ett operativsystem i stället för att paketeras med ett program.

Alla användningsbeslut om plattformskryptering jämfört med icke-plattformskryptering bör vägledas av följande krav:

  1. Biblioteket ska vara en aktuell supportversion utan kända säkerhetsrisker

  2. De senaste säkerhetsprotokollen, algoritmerna och nyckellängderna bör stödjas

  3. (Valfritt) Biblioteket bör endast ha stöd för äldre säkerhetsprotokoll/algoritmer för bakåtkompatibilitet

Intern kod

Hanterad kod

  • Kryptoprimiter: Använd API:et som definierats i System.Security.Cryptography-namnområdet--- CNG-klasserna föredras.

  • Använd den senaste versionen av .Net Framework. Detta bör minst vara .Net Framework version 4.6. Om en äldre version krävs kontrollerar du att regkey "SchUseStrongCrypto" är inställd på att aktivera TLS 1.2 för det aktuella programmet.

  • Certifikatverifiering: Använd API:er som definierats under namnområdet System.Security.Cryptography.X509Certificates .

  • SSL/TLS/DTLS: Använd API:er som definierats under System.Net namnområde (till exempel HttpWebRequest).

Nyckelhärledningsfunktioner

Nyckelhärledning är processen att härleda kryptografiskt nyckelmaterial från en delad hemlighet eller en befintlig kryptografisk nyckel. Produkter bör använda rekommenderade viktiga härledningsfunktioner. Att härleda nycklar från användarvalda lösenord eller hash-lösenord för lagring i ett autentiseringssystem är ett specialfall som inte omfattas av den här vägledningen. utvecklarna bör kontakta en expert.

Följande standarder anger de KDF-funktioner som rekommenderas för användning:

  • NIST SP 800-108: Rekommendation för nyckelhärledning med pseudorandomfunktioner. I synnerhet KDF i räknareläge, med HMAC som pseudorandomfunktion

  • NIST SP 800-56A (revision 2): Rekommendation för Pair-Wise nyckeletableringsscheman med diskret logaritmkryptografi. I synnerhet rekommenderas funktionen "Enstegsnyckelhärledning" i avsnitt 5.8.1.

Om du vill härleda nycklar från befintliga nycklar använder du API:et BCryptKeyDerivation med någon av algoritmerna:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Om du vill härleda nycklar från en delad hemlighet (utdata från ett nyckelavtal) använder du API:et BCryptDeriveKey med någon av följande algoritmer:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

Certifikatverifiering

Produkter som använder SSL, TLS eller DTLS bör fullständigt verifiera X.509-certifikaten för de entiteter som de ansluter till. Detta omfattar verifiering av certifikaten":

  • Domännamn.

  • Giltighetsdatum (både start- och förfallodatum).

  • Återkallningsstatus.

  • Användning (till exempel "Serverautentisering" för servrar, "Klientautentisering" för klienter).

  • Förtroendekedja. Certifikat bör länkas till en rotcertifikatutfärdare (CA) som är betrodd av plattformen eller som uttryckligen konfigurerats av administratören.

Om något av dessa verifieringstester misslyckas bör produkten avsluta anslutningen till entiteten.

Klienter som litar på "självsignerade" certifikat (till exempel en e-postklient som ansluter till en Exchange-server i en standardkonfiguration) kan ignorera verifieringskontroller av certifikat. Självsignerade certifikat förmedlar dock inte förtroende, stödåterkallelse eller stöd för nyckelförnyelse. Du bör bara lita på självsignerade certifikat om du har hämtat dem från en annan betrodd källa (till exempel en betrodd entitet som tillhandahåller certifikatet via en autentiserad och integritetsskyddad transport).

Kryptografiska hashfunktioner

Produkter bör använda SHA-2-serien med hashalgoritmer (SHA256, SHA384 och SHA512). Trunkering av kryptografiska hashvärden i säkerhetssyfte till mindre än 128 bitar rekommenderas inte.

MAC/HMAC/nyckelade hashalgoritmer

En kod för meddelandeautentisering (MAC) är en information som är kopplad till ett meddelande som gör att mottagaren kan verifiera både avsändarens äkthet och meddelandets integritet med hjälp av en hemlig nyckel.

Användning av antingen en hashbaserad MAC (HMAC) eller blockkrypteringsbaserad MAC rekommenderas så länge alla underliggande hash- eller symmetriska krypteringsalgoritmer också rekommenderas för användning. för närvarande omfattar detta funktionerna HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 och HMAC-SHA512).

Trunkering av HMACs till mindre än 128 bitar rekommenderas inte.

Design- och driftsöverväganden

  • Du bör tillhandahålla en mekanism för att ersätta kryptografiska nycklar efter behov. Nycklar bör ersättas när de har nått slutet av sin aktiva livslängd eller om den kryptografiska nyckeln har komprometterats. När du förnyar ett certifikat bör du förnya det med en ny nyckel.

  • Produkter som använder kryptografiska algoritmer för att skydda data bör innehålla tillräckligt med metadata tillsammans med innehållet för att stödja migrering till olika algoritmer i framtiden. Detta bör omfatta den algoritm som används, nyckelstorlekar, initieringsvektorer och utfyllnadslägen.

  • När det är tillgängligt bör produkterna använda etablerade kryptografiska protokoll som tillhandahålls av plattformen i stället för att omimplementering av dem. Detta inkluderar signeringsformat (t.ex. använd ett befintligt standardformat).

  • Symmetriska ström chiffer som RC4 bör inte användas. I stället för symmetriska ström chiffer bör produkter använda ett block chiffer, särskilt AES med en nyckellängd på minst 128 bitar.

  • Rapportera inte kryptografiska åtgärdsfel till slutanvändarna. När du returnerar ett fel till en fjärranropare (t.ex. webbklient eller klient i ett klientserverscenario) använder du endast ett allmänt felmeddelande.

    • Undvik att ange onödig information, till exempel direktrapportering av fel som inte är inom intervallet eller ogiltiga längdfel. Logga utförliga fel endast på servern och endast om utförlig loggning är aktiverat.
  • Ytterligare säkerhetsgranskning rekommenderas starkt för alla designer som innehåller följande:

    • Ett nytt protokoll som främst fokuserar på säkerhet (till exempel ett autentiserings- eller auktoriseringsprotokoll)

    • Ett nytt protokoll som använder kryptografi på ett nytt eller icke-standard sätt o Exempelöverväganden är:

      • Kommer en produkt som implementerar protokollet att anropa krypto-API:er eller -metoder som en del av protokollimplementeringen?

      • Är protokollet beroende av något annat protokoll som används för autentisering eller auktorisering?

      • Kommer protokollet att definiera lagringsformat för kryptografiska element, till exempel nycklar?

  • Självsignerade certifikat rekommenderas inte för produktionsmiljöer. Användning av ett självsignerat certifikat, till exempel användning av en rå kryptografisk nyckel, ger inte användare eller administratörer någon grund för att fatta ett förtroendebeslut.

    • Användningen av ett certifikat som är rotat i en betrodd certifikatutfärdare tydliggör däremot grunden för att förlita sig på den associerade privata nyckeln och möjliggör återkallning och uppdateringar i händelse av ett säkerhetsfel.

Kryptera känsliga data före lagring

DPAPI/DPAPI-NG

För data som måste sparas mellan systemomstarter:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

För data som inte behöver sparas mellan systemomstarter:

  • CryptProtectMemory

  • CryptUnprotectMemory

För data som måste sparas och nås av flera domänkonton och datorer:

SQL Server TDE

Du kan använda SQL Server Transparent Data Encryption (TDE) för att skydda känsliga data.

Du bör använda en krypteringsnyckel för TDE-databas (DEK) som uppfyller de kryptografiska SDL-algoritmerna och kraven på nyckelstyrka. För närvarande rekommenderas endast AES_128, AES_192 och AES_256. TRIPLE_DES_3KEY rekommenderas inte.

Det finns några viktiga saker att tänka på när du använder SQL TDE:

Hantering av autentiseringsuppgifter

Använd API:et för Windows Credential Manager eller Microsoft Azure KeyVault för att skydda lösenords- och autentiseringsuppgifter.

Windows Store-appar

Använd klasserna i namnrymderna Windows.Security.Cryptography och Windows.Security.Cryptography.DataProtection för att skydda hemligheter och känsliga data.

  • ProtectAsync

  • ProtectStreamAsync

  • Ta bort skyddetAsynkronisera

  • Ta bort skyddetStreamAsync

Använd klasserna i namnområdet Windows.Security.Credentials för att skydda lösenords- och autentiseringsuppgifter.

.NET

För data som måste sparas mellan systemomstarter:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

För data som inte behöver sparas mellan systemomstarter:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

För konfigurationsfiler använder du

antingen RSAProtectedConfigurationProvider eller DPAPIProtectedConfigurationProvider för att skydda din konfiguration med hjälp av antingen RSA-kryptering eller DPAPI.

RSAProtectedConfigurationProvider kan användas på flera datorer i ett kluster. Mer information finns i Kryptera konfigurationsinformation med skyddad konfiguration .