Sdílet prostřednictvím

Kryptografická doporučení Microsoft SDL

  • Článek

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:

  • Doporučuje 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ého bloku je vyžadována minimální délka klíče 128 bitů, ale doporučujeme podporovat 256bitové klíče. 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é další režimy šifry, jako jsou ty, které následují, mají nástrahy implementace, které je pravděpodobnější, že se nesprávně použijí. Zejména je třeba zabránit režimu elektronického knihy kódu (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)
  • Čítač (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í režimů šifrování streamování, jako je výstupní zpětná vazba (OFB) nebo čítač (CTR).

Doporučení AES-GCM & AES-CCM

AES-GCM (Galois/Counter Mode) a AES-CCM (counter with CBC-MAC) jsou široce používané 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ý vektor nonce (inicializační vektor), může to vést ke katastrofickým důsledkům.

Doporučujeme postupovat podle pokynů, které nejsou uvedeny v nist SP 800-38D, doporučení pro režimy blokové šifry provozu: Galois/Counter Mode (GCM) a GMAC, přičemž se zvláštní pozornost věnuje části 8.3 týkající se maximálního počtu vyvolání.

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í neaktivních uložených dat, kdy použití čítače nebo zajištění, abyste mohli sledovat maximální počet volání pro daný klíč, by byl nepraktický.

Pro šifrování neaktivních uložených dat můžete také zvážit použití AES-CBC s ověřovacím kódem zpráv (MAC) jako alternativu pomocí schématu Encrypt-then-MAC, abyste pro šifrování a mac použili 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í pseudorandom funkce | CSRC (nist.gov).

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

RSA

  • RsA se dá použít pro šifrování, 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 by měl používat pouze režim odsazení PKCS #1 v1.5, aby byl kompatibilní.
  • Použití odsazení null se nedoporučuje.
  • Doporučuje se minimálně 2048bitová délka klíče, ale doporučujeme podporovat délku 3072bitového klíče.

ECDSA a ECDH

  • Podpisy založené na ECDH na klíčích a 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.

Celé číslo Diffie-Hellman

  • 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 cryptoperiod 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 mít proces nahrazení klíčů, abyste dosáhli omezené aktivní životnosti. 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

Win32/64

  • Starší verze kódu může používat RtlGenRandom v režimu jádra.
  • 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.

.NET

PowerShell

Aplikace pro Windows Store

Linux/macOS

  • Zařízení /dev/urandom poskytuje kryptograficky silný zdroj náhodných dat, stejně jako getrandom(2) volání systému.

Podporované kryptografické knihovny platformy 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í verzí podpory bez známých ohrožení zabezpečení.
  • 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ěřování certifikátu (jak se používá v omezeném ověřování certifikátů pro podepisování kódu nebo SSL/TLS/DTLS): ROZHRANÍ API CAPI2; Například CertGetCertificateChain a CertVerifyCertificateChainPolicy.

Spravovaný kód (.NET)

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é funkce odvození klíče. 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 schémata vytvoření klíč-moudrý pár pomocí diskrétní logaritm kryptografie.

K odvození klíčů z existujících klíčů použijte rozhraní API BCryptKeyDerivation 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í API BCryptDeriveKey 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ěz vztahů důvěryhodnosti. Certifikáty by měly být zřetězený s kořenovou certifikační autoritou (CA) důvěryhodnou 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. Podepsané svým držitelem ze své podstaty neudělují důvěru, odvolání podpory ani obnovení klíče podpory.

Kryptografické funkce hash

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.

Hashovací algoritmy MAC/HMAC/keyed

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 ( HMAC) založeného na hodnotě hash nebo blokové šifry se doporučuje, pokud se doporučuje použít také všechny základní algoritmy hash nebo symetrického šifrování. V současné době 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.
    • Kdykoli prodloužíte certifikát, měli byste ho obnovit novým klíčem.
  • 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í nepotřebných informací, například přímé hlášení chyb mimo rozsah nebo neplatné délky. Protokolovat podrobné chyby pouze na serveru a pouze v případě, že je povolené 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 kořenového v důvěryhodné certifikační autoritě vymaže základ pro spoléhání se na přidružený privátní klíč a povolí odvolání a aktualizace, pokud dojde k selhání zabezpečení.