Microsoft SDL Cryptographic Rekommendationer

  • Artikel

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. Det är tänkt 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å icke-Windows-plattformar kan också dra nytta av dessa rekommendationer. Även om API- och biblioteksnamnen kan skilja sig åt är metodtipsen för algoritmval, nyckellängd och dataskydd likartade på olika plattformar.

Säkerhetsprotokoll, algoritm och nyckellängd Rekommendationer

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

  • Trenycklars 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 att dekryptera 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 notera 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 ska krypteras igen 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 samman krypteringsåtgärderna på efterföljande block med 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 dem mer benägna att användas felaktigt. I synnerhet bör man undvika att använda den elektroniska kodboken (ECB). Om du återanvänder samma initieringsvektor (IV) med block chiffer i "strömmande chifferlägen" som CTR kan 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ömmande 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 för ett års livslängd.

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

  • Du bör ange 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 sin aktiva livslängd bör en nyckel inte användas för att skapa nya data (till exempel för kryptering eller signering), men 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 ska använda BCryptGenRandom eller CryptGenRandom.

  • C-funktionen 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 kryptografiska program, men är endast ok för intern testning.

  • Funktionen SystemPrng rekommenderas för kernel-lägeskod.

.NET

Windows Store-appar

Rekommenderas inte

Kryptobibliotek som stöds av Windows Platform

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 kryptobibliotek som inte är plattformsbaserade för användning. I allmänhet uppdateras plattformskrypteringsbibliotek oftare eftersom de levereras som en del av ett operativsystem i stället för att paketeras med ett program.

Alla användningsbeslut om plattform eller icke-plattformskryptering bör vägledas av följande krav:

  1. Biblioteket ska vara en aktuell version som stöds utan kända säkerhetsrisker

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

  3. (Valfritt) Biblioteket ska endast kunna stödja äldre säkerhetsprotokoll/algoritmer för bakåtkompatibilitet

Intern kod

Hanterad kod

  • Kryptopri primitiver: Använd API:et som definierats i System.Security.Cryptography-namnrymd--- CNG-klasserna är att föredra.

  • 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 programmet i fråga.

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

  • SSL/TLS/DTLS: Använd API:er som definierats under namnområdet System.Net (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 nyckelhä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. bör utvecklare 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äknarläge, med HMAC som pseudorandomfunktion

  • NIST SP 800-56A (revision 2): Rekommendation för parvisa nyckeletableringsscheman med diskret logaritmkryptografi. I synnerhet rekommenderas "Enstegsnyckelavledningsfunktion" i avsnitt 5.8.1.

Om du vill härleda nycklar från befintliga nycklar använder du API:et BCryptKeyDerivation med en 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, supportå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 hashar i säkerhetssyfte till mindre än 128 bitar rekommenderas inte.

MAC/HMAC/nyckelade hash-algoritmer

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 hash-baserad MAC (HMAC) eller block-chifferbaserad 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 implementera dem på nytt. Detta omfattar signeringsformat (t.ex. använd ett standardformat, befintligt format).

  • 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ändare. När du returnerar ett fel till en fjärruppringare (t.ex. webbklient eller klient i ett klientserverscenario) använder du endast ett allmänt felmeddelande.

    • Undvik att ange onödig information, till exempel att direkt rapportera fel med out-of-range eller ogiltig längd. Logga utförliga fel endast på servern och endast om utförlig loggning är aktiverad.

  • Ytterligare säkerhetsgranskning rekommenderas starkt för alla design 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 i ett nytt eller icke-standardiserat sätt o Exempel på ö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 aktiverar återkallande 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 datakryptering (TDE) för att skydda känsliga data.

Du bör använda en krypteringsnyckel för TDE-databas (DEK) som uppfyller kraven på SDL-kryptografialgoritm och 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 Windows Credential Manager-API:et 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 skyddSynkronisering

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