Kryptografická doporučení Microsoft SDL

  • Článek

Úvod

Tento dokument obsahuje doporučení a osvědčené postupy pro použití šifrování na platformách Microsoftu. Většina obsahu zde je parafrázovaná nebo agregovaná z vlastních interních standardů zabezpečení microsoftu, které se používají k vytvoření životního cyklu vývoje zabezpečení. Je určena jako odkaz při navrhování produktů tak, aby používala stejná rozhraní API, algoritmy, protokoly a délky klíčů, které Společnost Microsoft vyžaduje u svých vlastních produktů a služeb.

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élky klíčů

Verze SSL/TLS

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

  • Měl by být povolený protokol TLS 1.2.

  • Kvůli zpětné kompatibilitě by měly být povolené protokoly TLS 1.1 a TLS 1.0.

  • Ve výchozím nastavení by měly být zakázané protokoly 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:

  • Pro nový kód se doporučuje advanced Encryption Standard (AES).

  • Tříklíčový trojnásobný standard šifrování dat (3DES) je v existujícím kódu povolený kvůli zpětné kompatibilitě.

  • Všechny ostatní blokové šifry, včetně RC2, DES, 2-Key 3DES, DESX a Skipjack, by se měly používat jenom k dešifrování starých dat a měly by být nahrazeny, pokud se používají k šifrování.

Pro šifrovací algoritmy symetrického bloku se doporučuje minimální délka klíče 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ů). Tříklíčový 3DES je v současné době přijatelný, pokud se již používá v existujícím kódu; doporučuje se přechod na AES. DES, DESX, RC2 a Skipjack se už nepovažují za bezpečné. Tyto algoritmy by se měly používat jenom k dešifrování existujících dat kvůli zpětné kompatibilitě a data by se měla znovu zašifrovat pomocí doporučeného blokového šifrování.

Režimy šifry

Symetrické algoritmy mohou fungovat v různých režimech, z nichž většina spojuje operace šifrování na 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é jsou uvedeny níže, mají nástrahy implementace, které je pravděpodobnější, že se nesprávně použijí. Zejména by se měl vyhnout režimu elektronického knihy kódu (ECB). Opětovné používání 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)

  • Čítač s CBC-MAC (CCM)

  • Galois/Counter Mode (GCM)

  • Cokoli jiného, co není v seznamu doporučených položek výše

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í hodnotou. Doporučení pro generování kryptograficky silných náhodných čísel najdete v tématu Generátory náhodných čísel.

Vektory inicializace by se při provádění více operací šifrování nikdy neměly opakovaně používat, protože to 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).

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

RSA

  • RsA by se měla používat 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 klíče >= 2048 bitů.

ECDSA

  • Doporučuje se ECDSA s = 256bitovými >klíči.

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

ELLIPTIC

  • Doporučuje se ECDH s = 256bitovými >klíči.

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

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ř. RFC 7919), nebo vygenerované důvěryhodnou stranou a ověřenou před použitím.

Životnost klíčů

  • Všechny asymetrické klíče by měly mít maximálně pět let životnosti, doporučenou životnost jednoho roku.

  • Všechny symetrické klíče by měly mít maximální tříletou životnost; doporučená životnost na jeden rok.

  • Měli byste poskytnout mechanismus nebo mít proces nahrazení klíčů, abyste dosáhli omezené aktivní životnosti. Po skončení aktivní životnosti by se klíč neměl používat 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

CAPI

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() by se nemělo používat pro žádné kryptografické aplikace, ale je v pořádku jenom pro interní testování.

  • Funkce SystemPrng se doporučuje pro kód v režimu jádra.

.NET

Aplikace pro Windows Store

Nedoporučuje se

  • Nezabezpečené funkce související s generováním náhodných čísel zahrnují rand, System.Random (.NET), GetTickCount a GetTickCount64

  • Použití algoritmu generátoru náhodných čísel se dvěma třemi tečkami ("DUAL_EC_DRBG") se nedoporučuje.

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, že budou vyhodnocovat kryptografické knihovny jiných platforem, než které se mají použít. Obecně platí, že kryptografické knihovny platformy budou aktualizovány č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 vs. neformních kryptografických služeb by mělo být řízeno následujícími požadavky:

  1. Knihovna by měla být aktuální verzí v podpoře bez známých ohrožení zabezpečení.

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

  3. (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 nebo Windows Telefon, použijte CNG, pokud je to možné. V opačném případě použijte CryptoAPI (označované také jako CAPI, což je podporováno jako starší součást systému Windows ze systému Windows Vista dále).

  • SSL/TLS/DTLS: WinINet, WinHTTP, Schannel, IXMLHTTPRequest2 nebo IXMLHTTPRequest3.

    • Aplikace WinHTTP by měly být vytvořené pomocí WinHttpSetOption, aby podporovaly protokol TLS 1.2.

  • 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

  • Crypto Primitives: Preferují se použití rozhraní API definovaného v oboru názvů System.Security.Cryptography---těžovací třídy CNG.

  • Použijte nejnovější dostupnou verzi rozhraní .Net Framework. Minimálně by to mělo být .Net Framework verze 4.6. Pokud je vyžadována starší verze, ujistěte se, že je klíč registru SchUseStrongCrypto nastavený tak, aby pro danou aplikaci povolil protokol TLS 1.2.

  • Ověření certifikátu: Použijte rozhraní API definovaná v oboru názvů System.Security.Cryptography.X509Certificates .

  • SSL/TLS/DTLS: Použijte rozhraní API definovaná v oboru názvů System.Net (například HttpWebRequest).

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: 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 2): Doporučení pro schémata vytvoření klíč-moudrý pár pomocí diskrétní logaritm kryptografie. Konkrétně se doporučuje "Funkce odvozování klíče s jedním krokem" v oddílu 5.8.1.

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ýstupu 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 SSL, TLS nebo DTLS, by měly plně ověřit certifikáty X.509 entit, ke kterým se připojují. To zahrnuje ověření certifikátů:

  • 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 se měly zřetězovat s kořenovou certifikační autoritou (CA), která je 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ě.

Klienti, kteří důvěřují certifikátům podepsaným svým držitelem (například poštovní klient, který se připojuje k serveru Exchange ve výchozí konfiguraci), můžou ignorovat kontroly ověření certifikátu. Certifikáty podepsané svým držitelem ale ze své podstaty neudělují důvěryhodnost, podporu odvolání ani obnovení klíče podpory. Certifikáty podepsané svým držitelem byste měli důvěřovat pouze v případě, že jste je získali z jiného důvěryhodného zdroje (například důvěryhodná entita poskytující certifikát přes ověřený přenos chráněný integritou).

Kryptografické funkce hash

Produkty by měly používat řadu hash algoritmů SHA-2 (SHA256, SHA384 a SHA512). Zkrácení kryptografických hodnot hash pro účely zabezpečení na méně než 128 bitů se nedoporučuje.

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í hashové nebo symetrické šifrovací algoritmy. V současné době to zahrnuje funkce HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 a HMAC-SHA512).

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 po dosažení konce aktivní životnosti nebo v případě 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. To by mělo zahrnovat použitý algoritmus, velikosti klíčů, vektory inicializace a režimy odsazení.

  • Pokud jsou dostupné, měly by produkty místo jejich opětovné implementace používat zavedené kryptografické protokoly poskytované platformou. To zahrnuje formáty podepisování (např. použití standardního, existujícího formátu).

  • Symetrické šifry datových proudů, jako je RC4, by se neměly používat. Místo symetrických šifer datových proudů by produkty měly používat blokovou šifru, konkrétně AES s délkou klíče nejméně 128 bitů.

  • Neoznamujte selhání kryptografických operací koncovým uživatelům. Při vracení chyby vzdálenému volajícímu (např. 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í.

  • Další kontrola zabezpečení se důrazně doporučuje pro každý návrh, který zahrnuje následující:

    • 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 v novém nebo nestandardním způsobu, o Příklad aspekty zahrnují:

      • 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 pro produkční prostředí nedoporučuje. 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 umožňuje odvolání a aktualizace v případě selhání zabezpečení.

Šifrování citlivých dat před úložištěm

DPAPI/DPAPI-NG

U dat, která je potřeba zachovat v rámci restartování systému:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

U dat, která není potřeba uchovávat v restartování systému:

  • CryptProtectMemory

  • CryptUnprotectMemory

Pro data, která je potřeba zachovat a přistupovat k datům více doménových účtů a počítačů:

Transparentní šifrování dat SQL Serveru

K ochraně citlivých dat můžete použít sql Server transparentní šifrování dat (TDE).

Měli byste použít šifrovací klíč databáze TDE (DEK), který splňuje požadavky na kryptografický algoritmus SDL a sílu klíče. V současné době se doporučuje pouze AES_128, AES_192 a AES_256; TRIPLE_DES_3KEY se nedoporučuje.

Při používání transparentního šifrování dat SQL byste měli mít na paměti několik důležitých aspektů:

Správa přihlašovacích údajů

K ochraně dat hesel a přihlašovacích údajů použijte rozhraní API správce přihlašovacích údajů systému Windows nebo Microsoft Azure KeyVault.

Aplikace pro Windows Store

K ochraně tajných kódů a citlivých dat použijte třídy v oborech názvů Windows.Security.Cryptography.DataProtection.

  • ProtectAsync

  • ProtectStreamAsync

  • Odemknout synchronizaci

  • UnprotectStreamAsync

K ochraně hesel a dat přihlašovacích údajů použijte třídy v oboru názvů Windows.Security.Credentials.

.NET

U dat, která je potřeba zachovat v rámci restartování systému:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

U dat, která není potřeba uchovávat v restartování systému:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

Pro konfigurační soubory použijte

buď RSAProtectedConfigurationProvider, nebo DPAPIProtectedConfigurationProvider k ochraně konfigurace pomocí šifrování RSA nebo DPAPI.

RsAProtectedConfigurationProvider lze použít na více počítačích v clusteru. Další informace najdete v tématu Šifrování informací o konfiguraci pomocí chráněné konfigurace .