Microsoft SDL Cryptographic Rekommendationer

  • Artikel
  • 10 minuter för att läsa

Introduktion

Det här dokumentet innehåller rekommendationer och metodtips för kryptering på Microsoft-plattformar. Mycket av innehållet här är parat eller aggregerat från Microsofts egna interna säkerhetsstandarder som används för att skapa en livscykel för säkerhetsutveckling. Den är avsedd att användas som referens när man 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å andra plattformar än Windows också dra nytta av de här rekommendationerna. Även om NAMNEN på API:er och biblioteken kan vara olika så är de bästa metoderna som innefattar algoritmval, nyckellängd och dataskydd liknande på olika plattformar.

Security Protocol, Algorithm and Key Length 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 ska endast aktiveras för bakåtkompatibilitet

  • SSL 3 och SSL 2 ska vara inaktiverade som standard

Symmetriska blockchiffrer, chifferlägen och initieringsvektorer

Blockera chiffer

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

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

  • 3DES (Three-Key Triple Data Encryption Standard) finns i befintlig kod för bakåtkompatibilitet.

  • Alla andra blockchiffrer, inklusive RC2, DES, 2-Key 3DES, DESX och Skipffer, ska 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 algoritmen för blockkryptering som rekommenderas för ny kod är AES (AES-128, AES-192 och AES-256 är godtagbara, med noter på att AES-192 saknar optimering på vissa processorer). Trenyckels-3DES är för närvarande acceptabelt om det redan används i befintlig kod. övergång till AES rekommenderas. DES, DESX, RC2 och Skip skipp skippar är inte längre säkra. Dessa algoritmer bör endast användas för att dekryptera befintliga data för bakåtkompatibilitet, och data bör krypteras på nytt med hjälp av ett rekommenderat blockchiffr.

Chifferlägen

Symmetriska algoritmer kan fungera i en mängd olika lägen, och de flesta av dem länkar samman krypteringsåtgärder på efterföljande block med oformaterad text och chiffertext.

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

Vissa andra chifferlägen, som de som anges nedan, har fallgropar som gör att de blir mer sannolikt att de används felaktigt. I synnerhet bör man undvika åtgärdens läge för elektronisk kodbok (SÅD). Om du återanvänder samma initieringsvektor (IV) med block-chiffer i "streaming-chifferlägen" som CTR kan krypterade data visas. Ytterligare säkerhetsgranskning rekommenderas om något av följande lägen används:

  • Utdatafeedback (OFB)

  • Chifferfeedback (CFB)

  • Räknare (CTR)

  • Räknare med CBC-MAC (CCM)

  • Galois/Räknare-läge (GCM)

  • Något annat som inte finns med i listan "rekommenderas" ovan

Initieringsvektorer (IV)

Alla symmetriska block-chiffer bör också användas med ett kryptografiskt starkt slumptal som en initieringsvektor. Initieringsvektorer ska aldrig vara ett konstant värde. Se Slumpmässiga talgeneratorer för rekommendationer om att generera kryptografiskt starka slumptal.

Initieringsvektorer ska aldrig återanvändas när flera krypteringsåtgärder utförs, eftersom det kan avslöja information om data som krypteras, särskilt när du använder chifferlägen som OFB (Output Feedback) eller Räknare (CTR).

Asymmetriska algoritmer, tangentlängder och utfyllnadslägen

RSA

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

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

  • Du bör inte använda nullutfyllnad.

  • Tangenter > = 2 048 bitar rekommenderas

ECDSA

  • ECDSA med > = 256-bitarsnycklar rekommenderas

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

ECDH

  • ECDH med > = 256-bitarsnycklar rekommenderas

  • ECDH-baserad nyckelutbyte bör använda någon av de tre niST-godkända kurvorna (P-256, P-384 eller P521).

Integer Diffie-Sådare

  • Tangentlängd > = 2 048 bitar rekommenderas

  • Gruppparametrarna bör antingen vara en kä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, rekommenderad ettårig livslängd.

  • Alla symmetriska nycklar ska ha maximalt tre års livslängd. rekommenderade ett års livslängd.

  • 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 dess aktiva livslängd bör 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).

Slumpmässiga talgeneratorer

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

CNG

CAPI

Win32/64

  • Äldre kod kan använda RtlGenRandom i kernel-läge

  • Den nya koden ska använda BCryptGenRandom eller CryptGenRandom.

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

  • Rand_s() är en säker och utförd 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äge-kod.

.NET

Windows Store-appar

Rekommenderas inte

Windows Crypto-bibliotek som stöds på plattformen

På Windows rekommenderar Microsoft att du använder crypto-API:erna som är inbyggda i operativsystemet. På andra plattformar kan utvecklare välja att utvärdera kryptobibliotek som inte är plattformsoberoende för användning. I allmänhet uppdateras plattformkryptokryptbibliotek oftare eftersom de levereras som en del av ett operativsystem i motsats till att paketeras med ett program.

Alla användningsbeslut om plattform kontra crypto-av plattform bör vägledas genom följande krav:

  1. Biblioteket bör vara en aktuell version utan support, utan kända säkerhetsproblem

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

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

Inbyggd kod

Hanterad kod

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

  • Använd den senaste versionen av .Net Framework som är tillgänglig. Som minst bör detta vara .Net Framework version 4.6. Om en äldre version krävs ser du till att registernyckeln "SchUseStrongCrypto" är inställd på att aktivera TLS 1.2 för programmet i fråga.

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

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

Key Desion-funktioner

Nyckelkodning är processen att avrvinga kryptografiska nyckelmaterial från en delad hemlig eller en befintlig kryptografiknyckel. Produkter bör använda rekommenderade nyckelfunktioner. Att inaktivera nycklar från lösenord som användaren valt eller hashkoda lösenord för lagring i ett autentiseringssystem är ett specialfall som inte omfattas av denna vägledning. utvecklare bör kontakta en expert.

I följande standarder anges vilka KDF-funktioner som rekommenderas för användning:

  • NIST SP 800-108: Rekommendation för keyIon med pseudorandom-funktioner. Särskilt KDF i räknarläge, med HMAC som en pseudorandom-funktion

  • NIST SP 800-56A (revision 2): Rekommendation för Pair-Wise viktiga färgscheman med hjälp av fristående logaritmkryptografi. Särskilt "Enkelstegstangentfunktion" i avsnitt 5.8.1 rekommenderas.

Använd API:t BCryptKeyDerivation med någon av algoritmerna för att härleda nycklar från befintliga nycklar:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

För att härleda nycklar från en delad hemligt (utdata från ett nyckelavtal) använder du BCryptDeriveKey API 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 verifiera X.509-certifikaten för enheterna de ansluter till helt. Detta omfattar verifiering av certifikaten:

  • Domännamn.

  • Giltighetsdatum (både start- och utgångsdatum).

  • Återkallelsestatus.

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

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

Om något av dessa verifieringstest misslyckas bör produkten avsluta anslutningen med enheten.

Klienter som litar på "själv signerade" certifikat (till exempel en e-postklient som ansluter till en Exchange-server i en standardkonfiguration) kan ignorera kontroller av certifikatverifiering. Men själv signerade certifikat överför inte på ett sätt förtroende, återkallelse av stöd eller stöd för nyckelförnyelse. Du bör bara lita på självsignerade certifikat om du har fått dem från en annan betrodd källa (till exempel en betrodd enhet som tillhandahåller certifikatet via en autentiserad och integritetsskyddad transport).

Cryptographic Hash-funktioner

Produkter bör använda SHA-2-familjen med hash-algoritmer (SHA256, SHA384 och SHA512). Trunkering av kryptografiska hash-hashs för säkerhetsändamål till mindre än 128 bitar rekommenderas inte.

MAC/HMAC/viktiga hash-algoritmer

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

Vi rekommenderar att du antingen använder en hashbaserad MAC(HMAC) eller block-cipherbaserad MAC 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 HMAC till mindre än 128 bitar rekommenderas inte.

Design- och driftöverväganden

  • Du bör tillhandahålla en mekanism för att ersätta kryptografiska nycklar vid behov. Nycklar bör ersättas när de har nått slutet av sin aktiva livslängd eller om kryptografiken 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 inkludera tillräckligt med metadata tillsammans med innehållet för att stödja migrering till olika algoritmer i framtiden. Det bör inkludera den algoritm som används, nyckelstorlekar, initieringsvektorer och utfyllnadslägen.

  • När produkterna är tillgängliga bör de använda etablerade kryptografiska protokoll som tillhandahålls av plattformen i stället för att implementera dem igen. Det omfattar signeringsformat (t.ex. använda standardformat eller befintligt format).

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

  • Rapportera inte kryptografiska fel till slutanvändare. Använd endast ett allmänt felmeddelande när du returnerar ett fel till en fjärransluten uppringare (t.ex. en webbklient eller klient i ett klientserverscenario).

    • Undvik att ange onödig information, t.ex. direktrapportering utanför intervallet eller fel med ogiltig längd. Logga utförliga fel endast på servern och endast om utförlig loggning har aktiverats.

  • Ytterligare säkerhetsgranskning rekommenderas starkt för alla utformningar som använder följande:

    • Ett nytt protokoll som främst är fokuserat på säkerhet (t.ex. ett autentiserings- eller auktoriseringsprotokoll)

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

      • Kan en produkt som implementerar protokollet anropa eventuella krypto-API:er eller metoder som en del av protokollimplementering?

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

      • Definierar protokollet lagringsformat för kryptografiska element som nycklar?

  • Själv signerade certifikat rekommenderas inte för produktionsmiljöer. Användningen av ett själv signerat certifikat, t.ex. användningen av en raw cryptographic key, ger inte användare eller administratörer någon grund för att fatta ett förtroendebeslut.

    • Användning av ett certifikat i en betrodd certifikatutfärdare utgör däremot en tydlig grund för att förlita sig på den associerade privata nyckeln och möjliggöra återkallelse och uppdateringar i händelse av ett säkerhetsfel.

Kryptera känsliga data innan Storage

DPAPI/DPAPI-NG

För data som måste finnas kvar vid systemstarter:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

För data som inte behöver vara beständiga vid systemstarter:

  • CryptProtectMemory

  • CryptUnprotectMemory

För data som måste vara beständiga och åtkomlade 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 TDE-databaskrypteringsnyckel (DEK) som uppfyller SDL-kryptografiska algoritmen och kraven på nyckelstyrka. För närvarande AES_128 vi AES_192, AES_256 och svar. TRIPLE_DES_3KEY rekommenderas inte.

Det finns några viktiga överväganden när du SQL TDE som du bör tänka på:

  • SQL Server stöder inte kryptering av FILESTREAM-data, även när TDE är aktiverat.

  • TDE tillhandahåller inte automatiskt kryptering för data som överförs till eller från databasen. Du bör också aktivera krypterade anslutningar till SQL Server databas. Mer information om hur du aktiverar krypterade anslutningar finns i Konfigurationshanteraren för SQL Server (Enable Encrypted Connections to the Database Engine) (aktivera krypterade anslutningar).

  • Om du flyttar en TDE-skyddad databas till en annan SQL Server-instans ska du också flytta certifikatet som skyddar TDE-datakrypteringsnyckeln (DEK) och installera det i huvuddatabasen för mål-SQL Server-instansen. Mer information finns i TechNet-artikeln Flytta en TDE-skyddaddatabas till en SQL Server databas.

Hantering av autentiseringsuppgifter

Använd API:Windows Credential Manager ellerKeyVault Microsoft Azure skydda data om lösenord och autentiseringsuppgifter.

Windows Store-appar

Använd klasserna i Windows. Security.Cryptographyoch Windows. Security.Cryptography.DataProtection namespaces to protect secrets and sensitive data.

  • ProtectAsync

  • ProtectStreamAsync

  • Ta bortprotectAsync

  • UnprotectStreamAsync

Använd klasserna i Windows. Security.Credentials namespace to protect password and credential data.

.NET

För data som måste finnas kvar vid systemstarter:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

För data som inte behöver vara beständiga vid systemstarter:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

För konfigurationsfiler använder du

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

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