Sdílet prostřednictvím

Kryptografická doporučení Microsoft SDL

Tyto informace použijte jako referenci při navrhování produktů tak, aby používaly stejná rozhraní API, algoritmy, protokoly a délky klíčů, které Microsoft vyžaduje u svých vlastních produktů a služeb. Většina obsahu je založená na vlastních interních standardech zabezpečení Microsoftu, které se používají k vytvoření životního cyklu vývoje zabezpečení.

Vývojáři na jiných platformách než Windows můžou tato doporučení využívat. I když se názvy rozhraní API a knihoven můžou lišit, osvědčené postupy zahrnující volbu algoritmu, délku klíče a ochranu dat jsou na různých platformách podobné.

Doporučení k protokolu zabezpečení, algoritmu a délce klíčů

Verze TLS/SSL

Produkty a služby by měly používat kryptograficky zabezpečené verze protokolu TLS/SSL:

  • Musí být povolený protokol TLS 1.3.

  • Protokol TLS 1.2 je možné povolit, aby se zlepšila kompatibilita se staršími klienty.

  • Musí být zakázané protokoly TLS 1.1, TLS 1.0, SSL 3 a SSL 2.

Symetrické blokové šifry, režimy šifer a inicializační vektory

Blokové šifry

Pro produkty používající symetrické blokové šifry:

  • Vyžaduje se Advanced Encryption Standard (AES).

  • Všechny ostatní blokové šifry, včetně 3DES (Triple DES/TDEA) a RC4 musí být nahrazeny, pokud se používají k šifrování.

U algoritmů šifrování symetrických bloků doporučujeme podporovat 256bitové klíče, ale povolit až 128 bitů. Jediný blokový šifrovací algoritmus doporučený pro nový kód je AES (AES-128, AES-192 a AES-256 jsou všechny přijatelné, a to znamená, že AES-192 nemá optimalizaci u některých procesorů).

Režimy šifry

Symetrické algoritmy můžou fungovat v různých režimech, z nichž většina spojuje operace šifrování v následných blocích prostého textu a šifrového textu.

Symetrické blokové šifry by se měly používat s jedním z následujících režimů šifr:

Některé jiné režimy šifrování, takové jako ty, které budou následovat, skrývají úskalí v implementaci, což zvyšuje pravděpodobnost jejich nesprávného použití. Zejména je třeba zabránit režimu elektronické kódové knihy (ECB). Opětovné použití stejného inicializačního vektoru (IV) s blokovými šiframi v režimech streamovaných šifer, jako je CTR, může způsobit odhalení šifrovaných dat. Pokud se používá některý z následujících režimů, doporučuje se další kontrola zabezpečení:

  • Výstupní zpětná vazba (OFB)

  • Šifrová zpětná vazba (CFB)

  • Počítadlo (CTR)

  • Cokoli jiného, co není v předchozím seznamu doporučených položek

Inicializační vektory (IV)

Všechny symetrické blokové šifry by se také měly používat s kryptograficky silným náhodným číslem jako inicializační vektor. Vektory inicializace by nikdy neměly být konstantní nebo predikovatelnou hodnotou. Doporučení pro generování kryptograficky silných náhodných čísel najdete v tématu Generátory náhodných čísel.

Při provádění více operací šifrování by se vektory inicializace nikdy neměly opakovaně používat. Opakované použití může odhalit informace o šifrovaných datech, zejména při použití streamovacích šifrovacích režimů, jako je výstupní zpětná vazba (OFB) nebo čítač (CTR).

doporučení pro AES-GCM a AES-CCM

AES-GCM (Galois/Counter Mode) a AES-CCM (Counter with CBC-MAC) se běžně používají jako režimy ověřeného šifrování. Kombinují důvěrnost a ochranu integrity, což je užitečné pro zabezpečenou komunikaci. Jejich křehkost však spočívá v opakovaném použití. Pokud se použije stejné nonce (inicializační vektor) dvakrát, může to vést ke katastrofickým důsledkům.

Doporučujeme postupovat podle pokynů, které nejsou popsány v nist SP 800-38D, doporučení pro režimy blokové šifry: Galois/Counter Mode (GCM) a GMAC, přičemž zvláštní pozornost věnujte částem 8.1, 8.2 a 8.3 týkajícím se požadavků na jedinečnost klíče a nece/IV.

Další možností je vygenerovat jedinečné klíče AES-GCM/CCM pro každou zašifrovanou zprávu, čímž se efektivně omezí maximální počet vyvolání na 1. Tento přístup se doporučuje pro šifrování dat uložených v klidu, kde by použití čítače nebo zajištění možnosti sledovat maximální počet použití pro daný klíč bylo nepraktické.

Pro šifrování dat v klidu můžete také zvážit použití AES-CBC s ověřovacím kódem zprávy (MAC) jako alternativu s použitím schématu Encrypt-then-MAC a ujistit se, že pro šifrování a MAC používáte samostatné klíče.

Ověření integrity

Jedná se o běžnou mylnou představu, že šifrování ve výchozím nastavení poskytuje důvěrnost i záruku integrity. Mnoho šifrovacích algoritmů neposkytuje žádnou kontrolu integrity a může být zranitelné vůči útokům na manipulaci. Před odesláním a po přijetí je nutné provést další kroky k zajištění integrity dat.

Pokud nemůžete použít ověřený šifrovací algoritmus s přidruženými daty (AEAD), jako je AES-GCM, alternativou by bylo ověření integrity pomocí ověřovacího kódu zprávy (MAC) pomocí schématu Encrypt-then-MAC a ujistěte se, že používáte samostatné klíče pro šifrování a mac.

Použití samostatného klíče pro šifrování a mac je nezbytné. Pokud není možné uložit dva klíče, je platnou alternativou odvození dvou klíčů z hlavního klíče pomocí vhodné funkce odvození klíče (KDF), jedné pro účely šifrování a jednoho pro MAC. Další informace naleznete v tématu [SP 800-108 Rev. 1, doporučení pro odvození klíče pomocí pseudonáhodných funkcí | CSRC (nist.gov)](https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf.

Asymetrické algoritmy, délky klíčů a režimy odsazení

šifrování RSA

  • RSA lze použít pro přenos klíčů, výměnu klíčů a podpisy.

  • Šifrování RSA by mělo používat režimy odsazení OAEP nebo RSA-PSS.

  • Existující kód může pro podepisování použít režim odsazení PKCS #1 v1.5.

  • Použití PKCS#1 v1.5 pro šifrování není povoleno.

  • Použití vycpávání nulami se nedoporučuje.

  • Minimální délka 2048bitového klíče je, ale doporučujeme podporovat délku 3072bitového klíče.

ECDSA a ECDH

  • ECDH-založené výměny klíčů a podpisy založené na ECDSA by měly používat jednu ze tří křivek schválených NIST (P-256, P-384 nebo P521).

  • Podpora P-256 by měla být považována za minimum, ale doporučujeme podporovat P-384.

ML-DSA

  • Musí používat standard FIPS 204. Nepoužívejte verze v konceptu standardu.

  • Doporučuje se používat ML-DSA v kombinaci s klasickým podpisovým algoritmem (tj. ECDSA nebo RSA). Pro interoperabilitu se upřednostňuje použití kombinátorů definovaných pomocí IETF (draft) nebo jiných standardů.

  • Pro ML-DSA je platným hybridním (složeným) mechanismem podepsat stejná data pomocí modelu Classic i ML-DSA a ověřit obojí (pokud se ověření nezdaří, ověření selže).

ML-KEM

  • Musí používat standard FIPS 203. Nepoužívejte verze v konceptu standardu.

  • Doporučuje se použít kombinační nebo hybridní kryptografický systém kombinující ML-KEM a klasický algoritmus KEM (tj. ECDH). Pro interoperabilitu se upřednostňuje použití kombinátorů definovaných pomocí IETF (draft) nebo jiných standardů.

SLH-DSA

  • Musí používat standard FIPS 205. Nepoužívejte verze v konceptu standardu.

  • Všechny SLH-DSA sady parametrů jsou povolené, ale doporučená sada parametrů bude záviset na případu použití.

  • Žádný známý rozdíl zabezpečení mezi verzemi SHA-2 a SHAKE (SHA-3)

LMS a XMSS

  • Pro ověření podpisu je bezpečné podporovat LMS nebo XMSS.

  • Před implementací/nasazením infrastruktury pro podepisování a generování klíčů důrazně doporučujeme konzultovat s odborníkem na danou problematiku. Není známo žádné slabosti, ale lidské indukované chyby je velmi možné a snadné, protože je důležité správně spravovat stav.

Celočíselná Diffie-Hellman

  • I když je celočíselná Diffie-Hellman (DH) schválena pro výměnu klíčů, není to nejúčinnější moderními standardy. Důrazně doporučujeme místo toho používat ECDH.
  • Doporučuje se délka klíče >= 2048 bitů.
  • Parametry skupiny by měly být buď dobře známou pojmenovanou skupinou (například RFC 7919), nebo vygenerované důvěryhodnou stranou a ověřenou před použitím.

Životnost klíčů

  • Definujte kryptoperiodu pro všechny klíče.

    • Příklad: Symetrický klíč pro šifrování dat, často označovaný jako šifrovací klíč dat nebo klíč DEK, může mít období použití až dva roky pro šifrování dat, označované také jako období použití původce. Můžete definovat, že má platné období využití pro dešifrování po dobu tří dalších let, označované také jako období využití příjemce.

  • Měli byste poskytnout mechanismus nebo zavést proces pro nahrazení klíčů a tím dosáhnout omezené doby aktivního použití. Po skončení aktivní životnosti nesmí být klíč použit k vytváření nových dat (například pro šifrování nebo podepisování), ale může se stále používat ke čtení dat (například k dešifrování nebo ověření).

Generátory náhodných čísel

Všechny produkty a služby by měly používat kryptograficky zabezpečené generátory náhodných čísel, pokud je vyžadována náhodnost.

CNG

  • Použijte BCryptGenRandom s příznakem BCRYPT_USE_SYSTEM_PREFERRED_RNG.

Win32/64

  • Starší verze kódu může v režimu jádra používat RtlGenRandom.

  • Nový kód by měl používat BCryptGenRandom nebo CryptGenRandom.

  • Funkce C Rand_s() se také doporučuje (což ve Windows volá CryptGenRandom).

  • Rand_s() je bezpečná a výkonná náhrada za Rand().

  • Rand() nesmí být používán pro žádné kryptografické aplikace.

platforma .NET

PowerShell

  • Použijte Get-SecureRandom (PowerShell).

Aplikace pro Windows Store

Kryptografické knihovny podporované platformou Windows

Na platformě Windows microsoft doporučuje používat kryptografická rozhraní API integrovaná do operačního systému. Na jiných platformách se můžou vývojáři rozhodnout vyhodnotit neplatformní kryptografické knihovny pro použití. Obecně platí, že kryptografické knihovny platformy se aktualizují častěji, protože se dodávají jako součást operačního systému, a ne se sbalují s aplikací.

Jakékoli rozhodnutí o využití týkající se platformy a neplatformních kryptografických služeb by mělo být řízeno následujícími požadavky:

  • Knihovna by měla být aktuální podporovanou verzí bez známých bezpečnostních zranitelností.

  • Měly by se podporovat nejnovější protokoly zabezpečení, algoritmy a délky klíčů.

  • (Volitelné) Knihovna by měla být schopná podporovat starší protokoly nebo algoritmy zabezpečení pouze kvůli zpětné kompatibilitě.

Nativní kód

  • Crypto Primitives: Pokud je vaše verze ve Windows, použijte CNG, pokud je to možné.

  • Ověření podpisu kódu: WinVerifyTrust je podporované rozhraní API pro ověřování podpisů kódu na platformách Windows.

  • Ověření certifikátu (jak se používá v omezeném ověřování certifikátů pro podepisování kódu nebo TLS/DTLS): ROZHRANÍ API CAPI2; Například CertGetCertificateChain a CertVerifyCertificateChainPolicy.

Funkce odvozování klíčů

Odvození klíče je proces odvozování materiálu kryptografického klíče ze sdíleného tajného klíče nebo existujícího kryptografického klíče. Produkty by měly používat doporučené klíčové odvozovací funkce. Odvozování klíčů z hesel zvolených uživatelem nebo hashování hesel pro úložiště v ověřovacím systému je zvláštní případ, na který se tyto pokyny nevztahují; by se měli obrátit na odborníka.

Následující standardy určují doporučené funkce KDF:

  • NIST SP 800-108 (revize 1): Doporučení pro odvození klíče pomocí pseudonáhodných funkcí. Zejména KDF v režimu čítače s HMAC jako pseudonáhodnou funkcí

  • NIST SP 800-56A (revize 3): Doporučení pro Pair-Wise schémata vytváření klíčů využívající diskrétní logaritmus kryptografii.

K odvození klíčů z existujících klíčů použijte BCryptKeyDerivation API s jedním z algoritmů:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

K odvození klíčů ze sdíleného tajného kódu (výstup smlouvy o klíči) použijte rozhraní BCryptDeriveKey API s jedním z následujících algoritmů:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

Ověření certifikátu

Produkty, které používají protokol TLS nebo DTLS, by měly plně ověřit certifikáty X.509 entit, ke kterým se připojují. Tento proces zahrnuje ověření následujících částí certifikátu:

  • Název domény.

  • Data platnosti (datum začátku i konce platnosti).

  • Stav odvolání.

  • Použití (například Ověřování serveru pro servery, Ověřování klienta pro klienty).

  • Řetězec důvěry. Certifikáty by měly být zřetězené s kořenovou certifikační autoritou (CA), které jsou důvěryhodné platformou nebo explicitně nakonfigurované správcem.

Pokud některý z těchto ověřovacích testů selže, měl by produkt ukončit připojení k entitě.

Nepoužívejte certifikáty podepsané svým držitelem. Vlastnoručně podepsané ze své podstaty nevyvolávají důvěru, neposkytují podporu pro odvolání ani podporu pro obnovení klíčů.

Kryptografické hash-funkce

Produkty by měly používat řadu hash algoritmů SHA-2 (SHA-256, SHA-384 a SHA-512). Zkrácení kryptografických hodnot hash pro účely zabezpečení na méně než 128 bitů není povoleno. I když je použití SHA-256 minimální, doporučujeme podporovat SHA-384.

Algoritmy hašování MAC/HMAC/na základě klíče

Ověřovací kód zprávy (MAC) je část informací připojená ke zprávě, která umožňuje příjemci ověřit pravost odesílatele i integritu zprávy pomocí tajného klíče.

Použití MAC založeného na hash (HMAC) nebo na blokově šifrovaného MAC se doporučuje, za předpokladu, že všechny základní algoritmy pro hash nebo symetrické šifrování jsou také doporučené; aktuálně to zahrnuje funkce HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 a HMAC-SHA512). I když je využití HMAC-SHA256 minimální, doporučujeme podporovat HMAC-SHA384.

Zkrácení HMAC na méně než 128 bitů se nedoporučuje.

Aspekty návrhu a provozu

  • Měli byste poskytnout mechanismus pro nahrazení kryptografických klíčů podle potřeby. Klíče by se měly nahradit, jakmile dosáhnou konce aktivní životnosti nebo dojde k ohrožení kryptografického klíče.

    • Pokaždé, když prodloužíte certifikát, měli byste ho obnovit novým klíčem (znovu vytvořit klíč).

  • Produkty, které k ochraně dat používají kryptografické algoritmy, by měly obsahovat dostatek metadat spolu s tímto obsahem, aby podporovaly migraci na různé algoritmy v budoucnu. Tato metadata by měla obsahovat použitý algoritmus, velikosti klíčů a režimy odsazení.

  • Pokud jsou dostupné, měly by produkty používat zavedené kryptografické protokoly poskytované platformou místo jejich opětovného vytvoření, včetně formátů podepisování (například použití standardního, existujícího formátu).

  • Neohlašujte selhání kryptografických operací koncovým uživatelům. Při vracení chyby vzdálenému volajícímu (například webovému klientovi nebo klientovi ve scénáři klienta-server) použijte pouze obecnou chybovou zprávu.

    • Vyhněte se poskytování zbytečných informací, například přímé hlášení chyb mimo rozsah nebo nesprávné délky. Protokolovat podrobné chyby pouze na serveru a pouze v případě, že je povoleno podrobné protokolování.

  • Pro každý návrh zahrnující následující položky důrazně doporučujeme provést další kontrolu zabezpečení:

    • Nový protokol, který se primárně zaměřuje na zabezpečení (například ověřovací nebo autorizační protokol)

    • Nový protokol, který používá kryptografii novým nebo nestandardním způsobem. Mezi příklady aspektů patří:

      • Bude produkt, který implementuje protokol, v rámci implementace protokolu volat nějaká kryptografická rozhraní API nebo metody?

      • Závisí protokol na jiném protokolu použitém k ověřování nebo autorizaci?

      • Bude protokol definovat formáty úložiště pro kryptografické prvky, jako jsou klíče?

  • Certifikáty podepsané svým držitelem se nedoporučují. Použití certifikátu podepsaného svým držitelem, jako je použití nezpracovaného kryptografického klíče, ze své podstaty neposkytuje uživatelům ani správcům žádný základ pro rozhodování o důvěryhodnosti.

    • Naproti tomu použití certifikátu od důvěryhodné certifikační autority jasně ozřejmí základ pro spoléhání se na přidružený privátní klíč a umožní odvolání a aktualizaci, pokud dojde k selhání zabezpečení.
  • Last updated on