Dela via

Kryptografiska rekommendationer för Microsoft SDL

  • Artikel

Använd den här informationen 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. Mycket av innehållet baseras på Microsofts egna interna säkerhetsstandarder som används för att skapa livscykeln för säkerhetsutveckling.

Utvecklare på icke-Windows-plattformar kan dra nytta av dessa rekommendationer. Även om API- och biblioteksnamnen kan skilja sig åt är metodtipsen för val av algoritm, nyckellängd och dataskydd likartade på olika plattformar.

Rekommendationer för säkerhetsprotokoll, algoritmer och nyckellängder

TLS/SSL-versioner

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

  • TLS 1.3 måste vara aktiverat.
  • TLS 1.2 kan aktiveras för att förbättra kompatibiliteten med äldre klienter.
  • TLS 1.1, TLS 1.0, SSL 3 och SSL 2 måste inaktiveras

Symmetriska block chiffer, chifferlägen och initieringsvektorer

Blockera chiffer

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

  • Advanced Encryption Standard (AES) rekommenderas.
  • Alla andra block chiffer, inklusive 3DES (Triple DES/TDEA), och RC4 måste ersättas om de används för kryptering.

För symmetriska blockkrypteringsalgoritmer krävs en minsta nyckellängd på 128 bitar, men vi rekommenderar att du stöder 256-bitarsnycklar. 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).

Chifferlägen

Symmetriska algoritmer kan användas i olika lägen, varav de flesta kopplar 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 följer har implementeringsgropar som gör dem mer benägna att användas felaktigt. I synnerhet måste man undvika det elektroniska kodbokssättet (ECB). Om du återanvänder samma initieringsvektor (IV) med block chiffer i "strömmande chifferlägen" som CTR kan krypterade data avslöjas. Extra säkerhetsgranskning rekommenderas om något av nedanstående lägen används:

  • Feedback om utdata (OFB)
  • Chifferfeedback (CFB)
  • Räknare (CTR)
  • Allt annat som inte finns i föregående "rekommenderade" lista

Initieringsvektorer (IV)

Alla symmetriska block chiffer bör också användas med ett kryptografiskt starkt slumpmässigt tal som initieringsvektor. Initieringsvektorer får aldrig vara ett konstant eller predikatvä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. Återanvändning 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).

AES-GCM- och AES-CCM-rekommendationer

AES-GCM (Galois/Counter Mode) och AES-CCM (Räknare med CBC-MAC) används ofta autentiserade krypteringslägen. De kombinerar konfidentialitet och integritetsskydd, vilket gör dem användbara för säker kommunikation. Men deras skörhet ligger i nonce återanvändning. När samma nonce (initieringsvektor) används två gånger kan det leda till katastrofala konsekvenser.

Vi rekommenderar att du följer riktlinjerna för nonce enligt beskrivningen i NIST SP 800-38D, rekommendation för blockkrypteringslägen: Galois/Counter Mode (GCM) och GMAC, med särskild uppmärksamhet på avsnitt 8.3 om det maximala antalet anrop.

Ett annat alternativ skulle genereras unika AES-GCM/CCM-nycklar för varje meddelande som krypteras, vilket effektivt begränsar det maximala antalet anrop till 1. Den här metoden rekommenderas för kryptering av vilande data, där det skulle vara opraktiskt att använda en räknare eller se till att du kan spåra det maximala antalet anrop för en viss nyckel.

För att kryptera vilande data kan du också överväga att använda AES-CBC med en kod för meddelandeautentisering (MAC) som ett alternativ med hjälp av ett Encrypt-then-MAC-schema, så att du använder separata nycklar för kryptering och för MAC.

Integritetsverifiering

Det är en vanlig missuppfattning att kryptering som standard ger både konfidentialitet och integritetssäkerhet. Många krypteringsalgoritmer ger ingen integritetskontroll och kan vara sårbara för manipuleringsattacker. Extra åtgärder måste vidtas för att säkerställa dataintegriteten innan de skickas och efter mottagandet.

Om du inte kan använda en autentiserad krypteringsalgoritm med associerade data (AEAD), till exempel AES-GCM, skulle ett alternativ vara att verifiera integriteten med en kod för meddelandeautentisering (MAC) med hjälp av ett Encrypt-then-MAC-schema och se till att du använder separata nycklar för kryptering och för MAC.

Det är viktigt att använda en separat nyckel för kryptering och för MAC. Om det inte går att lagra de två nycklarna är ett giltigt alternativ att härleda två nycklar från huvudnyckeln med hjälp av en lämplig nyckelhärledningsfunktion (KDF), en för krypteringsändamål och en för MAC. Mer information finns i SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions | CSRC (nist.gov).

Asymmetriska algoritmer, nyckellängder och utfyllnadslägen

RSA

  • RSA kan 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.
  • Minst en 2048-bitars nyckellängd rekommenderas, men vi rekommenderar att du stöder en 3072-bitars nyckellängd.

ECDSA och ECDH

  • ECDH-baserade nyckelutbyten och ECDSA-baserade signaturer bör använda en av de tre NIST-godkända kurvorna (P-256, P-384 eller P521).
  • Stöd för P-256 bör betraktas som ett minimum, men vi rekommenderar att du stöder P-384.

Integer Diffie-Hellman

  • Nyckellängd >= 2 048 bitar rekommenderas0
  • Gruppparametrarna bör antingen vara en välkänd namngiven grupp (till exempel RFC 7919) eller genereras av en betrodd part och autentiseras före användning.

Nyckellivslängder

  • Definiera en kryptoperiod för alla nycklar.
    • Till exempel: En symmetrisk nyckel för datakryptering, som ofta kallas datakrypteringsnyckel eller DEK, kan ha en användningsperiod på upp till två år för kryptering av data, även kallat användningsperioden för upphovsgivaren. Du kan definiera att den har en giltig användningsperiod för dekryptering i ytterligare tre år, även kallat mottagaranvändningsperioden.
  • 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 dess aktiva livslängd få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

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() får inte användas för kryptografiska program.

.NET

PowerShell

Windows Store-appar

Linux/macOS

  • Enheten /dev/urandom tillhandahåller en kryptografiskt stark källa till slumpmässiga data, liksom systemanropet getrandom(2) .

Kryptobibliotek som stöds av Windows-plattformen

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 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 plattforms- eller icke-plattformskryptkrypt bör vägledas av följande krav:

  • Biblioteket ska vara en aktuell version som stöds utan kända säkerhetsrisker.
  • De senaste säkerhetsprotokollen, algoritmerna och nyckellängderna bör stödjas.
  • (Valfritt) Biblioteket bör endast kunna stödja äldre säkerhetsprotokoll/algoritmer för bakåtkompatibilitet.

Intern kod

  • Kryptopri primitiver: Om din version finns i Windows använder du CNG om möjligt.
  • Verifiering av kodsignatur: WinVerifyTrust är det API som stöds för att verifiera kodsignaturer på Windows-plattformar.
  • Certifikatverifiering (som används i begränsad certifikatverifiering för kodsignering eller SSL/TLS/DTLS): CAPI2 API; Till exempel CertGetCertificateChain och CertVerifyCertificateChainPolicy.

Hanterad kod (.NET)

Viktiga hä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:

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 TLS eller DTLS bör fullständigt verifiera X.509-certifikaten för de entiteter som de ansluter till. Den här processen omfattar verifiering av följande delar av certifikatet:

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

Använd inte "självsignerade" certifikat. Självsignerade förmedlar inte förtroende, supportåterkallelse eller stöd för nyckelförnyelse.

Kryptografiska hashfunktioner

Produkter bör använda SHA-2-serien med hashalgoritmer (SHA-256, SHA-384 och SHA-512). Trunkering av kryptografiska hashvärden i säkerhetssyfte till mindre än 128 bitar tillåts inte. Även om användningen av SHA-256 är det minsta, rekommenderar vi att du stöder SHA-384.

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). Även om användningen av HMAC-SHA256 är det minsta, rekommenderar vi att du stöder HMAC-SHA384.

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 når slutet av sin aktiva livslängd eller kryptografinyckeln komprometteras.
    • 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. Dessa metadata bör innehålla den algoritm som används, nyckelstorlekar 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 omimplementera dem, inklusive signeringsformat (till exempel använda ett standardformat, befintligt format).
  • Rapportera inte kryptografiska åtgärdsfel till slutanvändare. När du returnerar ett fel till en fjärranropare (till exempel webbklient eller klient i ett klient-serverscenario) 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.
  • Extra säkerhetsgranskning rekommenderas starkt för alla design som innehåller följande objekt:
    • 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. 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. 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 om det uppstår ett säkerhetsfel.