Microsoft SDL Cryptographic Recommendations

  • Článek
  • 11 min ke čtení

Úvod

Tento dokument obsahuje doporučení a doporučené postupy pro používání šifrování na platformách Microsoft. Velká část obsahu tady je parafrázovaná nebo agregovaná z vlastních standardů interního zabezpečení microsoftu používaných k vytvoření životního cyklu vývoje zabezpečení. Má být použit jako odkaz při navrhování produktů tak, aby používaly stejná rozhraní API, algoritmy, protokoly a délky klíčů, které Microsoft vyžaduje od svých vlastních produktů a služeb.

Z těchto doporučení těží Windows také vývojáři na jiných platformách. I když se názvy rozhraní API a knihoven mohou lišit, doporučené postupy týkající se volby algoritmů, délky klíče a ochrany dat jsou podobné na různých platformách.

Protokol zabezpečení, algoritmus a délka klíče Recommendations

Verze SSL/TLS

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

  • Tls 1.2 by měl být povolený.

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

  • Ssl 3 a SSL 2 by měly být ve výchozím nastavení zakázané.

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

Blokovat šifry

U produktů používajících symetrické blokové šifry:

  • standard AES (Advanced Encryption Standard) (AES) se doporučuje pro nový kód.

  • Třík key triple Data Encryption Standard (3DES) je přípustné ve stávajícím kódu z důvodu zpětné kompatibility.

  • Všechny ostatní blokové šifry, včetně RC2, DES, 3DES s 2 klávesami, 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í.

U algoritmů symetrického šifrování bloků se doporučuje minimální délka klíče 128 bitů. Jediný algoritmus šifrování bloku doporučený pro nový kód je AES (AES-128, AES-192 a AES-256 jsou přijatelné, a to s tím, že AES-192 nemá u některých procesorů optimalizaci). 3DES se třemi klávesami je v současné době přijatelný, pokud se už používá ve stávajícím kódu. doporučuje se přechod na AES. DES, DESX, RC2 a Skipjack už nejsou považované 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é blokové šifry.

Režimy šifrování

Symetrické algoritmy mohou fungovat v různých režimech, z nichž většina spojuje operace šifrování na po sobě jdoucích blocích prostého textu a šifry.

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

Některé další režimy šifrování, jako jsou ty, které jsou uvedené níže, mají nástrahy implementace, které je upravují tak, že se nesprávně používají. Je třeba se zejména vyhnout režimu práce elektronického kódu (ECB). Opakované použití stejného inicializačního vektoru (IV) s blokovými šiframi v režimech streamování šifer, jako je CTR, může způsobit odhalení zašifrovaných dat. Další kontrola zabezpečení se doporučuje, pokud se používá některý z níže uvedených režimů:

  • Zpětná vazba výstupu (OFB)

  • Cipher Feedback (CFB)

  • Counter (CTR)

  • Počítadlo s CBC-MAC (CCM)

  • Galois/Counter Mode (GCM)

  • Nic dalšího, co není v seznamu doporučených položek výše

Inicializační vektory (IV)

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

Inicializační vektory by se nikdy neměly opakovaně používat při provádění více operací šifrování, protože to může odhalit informace o zašifrovaných datech, zvláště když používáte režimy šifry streamování, jako je výstupní zpětná vazba (OFB) nebo Counter (CTR).

Asymetrické algoritmy, délky kláves 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. Stávající kód by měl používat režim odsazení PKCS #1 v1.5 jenom kvůli kompatibilitě.

  • Použití odsazení hodnot null se nedoporučuje.

  • Klávesy > = 2048 bitů se doporučuje

ECDSA

  • Doporučuje se ECDSA > s = 256bitovou klávesou.

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

ECDH

  • Doporučuje se ECDH > s = 256bitovou klávesou.

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

Integer Diffie-Hellman

  • Doporučuje se > délka klíče = 2 048 bitů.

  • Parametry skupiny by měly být buď známé pojmenované skupiny (například RFC 7919), nebo vygenerované důvěryhodnou stranou a ověřené před použitím.

Životnost klíče

  • Všechny asymetrické klíče by měly mít maximální pětiletou životnost, doporučenou dobu životnosti na jeden rok.

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

  • Měli byste zadat mechanismus nebo proces nahrazování klíčů, aby se dosáhlo omezené životnosti. Po skončení jeho aktivní životnosti by se klíč neměl používat k vytvoření nových dat (například k šifrování nebo podepisování), ale může se použít ke čtení dat (například k dešifrování nebo ověření).

Generátory náhodných čísel

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

CNG

CAPI

Win32/64

.NET

Windows store

Nedoporučuje se

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

  • Použití algoritmu náhodného generátoru náhodných čísel s dvojitou eliptickou křivkou ("DUAL_EC_DRBG") se nedoporučuje.

Windows kryptografických knihoven podporovaných platformou

Na platformě Windows Microsoft doporučuje používat rozhraní API pro kryptografické služby integrovaná do operačního systému. Na jiných platformách se vývojáři mohou rozhodnout, že vyhodnocují ne platformové kryptografické knihovny pro použití. Obecně platí, že se knihovny kryptografických platforem aktualizují častěji, protože se dodá jako součást operačního systému na rozdíl od toho, aby se sbalili s aplikací.

Jakékoli rozhodnutí o použití platformy a ne platformové kryptografické by se mělo řídit následujícími požadavky:

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

  2. Měly by být podporovány nejnovější protokoly zabezpečení, algoritmy a délky klíčů.

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

Nativní kód

  • Crypto Primitives: Pokud je vaše verze Windows nebo Windows Phone, použijte CNG, pokud je to možné. V opačném případě použijte rozhraní CryptoAPI (nazývané také CAPI, které je podporované jako starší komponenta Windows od Windows Vista).

  • SSL/TLS/DTLS: WinINet,WinHTTP,Schannel,IXMLHTTPRequest2neboIXMLHTTPRequest3.

    • Aplikace WinHTTP by měly být vytvořené s WinHttpSetOption,abypodporovaly TLS 1.2.

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

  • Ověření certifikátu (používané při ověřování certifikátu s omezeným přístupem pro podepisování kódu nebo SSL/TLS/DTLS): ROZHRANÍ CAPI2 API; například CertGetCertificateChain a CertVerifyCertificateChainPolicy

Spravovaný kód

  • Kryptografické primitivy: Použijte rozhraní API definované v oboru názvů System.Security.Cryptography--- jsou upřednostňované třídy CNG.

  • Použijte nejnovější verzi dostupného 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 u příslušné aplikace nastavený regkey "SchUseStrongCrypto", který povolí TLS 1.2.

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

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

Funkce odvození kláves

Odvození klíče je proces odvození 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é derivační funkce. Odvození klíčů z hesel vybraných uživatelem nebo hesel hash pro ukládání v ověřovacím systému je zvláštní případ, na který se tyto pokyny nevztahují. vývojáři by se měli poradit s odborníkem.

Následující standardy určují funkce KDF doporučené pro použití:

  • NIST SP 800-108: Doporučení pro odvození klíčů pomocí pseudonáhodných funkcí. Konkrétně KDF v režimu protiúčtu s funkcí HMAC jako pseudonáhodným

  • NIST SP 800-56A (revize 2): Doporučení pro Pair-Wise zavedení klíčových systémů využívajících samostatnou logaritmovou kryptografii. Doporučuje se zejména funkce derivace jedním krokem v oddílu 5.8.1.

Pokud chcete odvodit klíče ze stávajících klíčů, použijte rozhraní API BCryptKeyDerivation s jedním z algoritmů:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Pokud chcete odvodit klíče ze sdíleného tajného klíče (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í SSL, TLS nebo DTLS, by měly plně ověřit certifikáty X.509 entit, ke které se připojují. To zahrnuje ověření certifikátů":

  • Název domény

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

  • Stav odvolání

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

  • Řetěz důvěryhodnosti. Certifikáty by měly být zřetězované 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 spojení s entitou.

Klienti, kteří důvěřují certifikátům podepsaných svým držitelem (například poštovní klient, který se připojuje k Exchange serveru ve výchozí konfiguraci), mohou kontroly ověření certifikátů ignorovat. Certifikáty podepsané svým držitelem ale neodmyslitelně nevyjadřují důvěru, odvolání podpory ani prodlužování klíčů podpory. Certifikáty s vlastním podpisem byste měli důvěřovat jenom v případě, že jste je získali z jiného důvěryhodného zdroje (například důvěryhodnou entitu, která certifikát poskytuje prostřednictvím ověřeného přenosu chráněného integritou).

Kryptografické funkce hash

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

Algoritmus hash MAC/HMAC/keyed

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

Použití macu založeného na algoritmu hash (HMAC) nebo macu založeného na blokové šifrě se doporučuje, pokud se pro použití doporučují také všechny základní algoritmus hash nebo symetrické šifrování. 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 zadat mechanismus pro nahrazení kryptografických klíčů podle potřeby. Klíče by měly být nahrazeny, jakmile skončí jejich aktivní životnost nebo dojde k ohrožení kryptografického klíče. Při každém prodloužení certifikátu byste ho měli obnovit novým klíčem.

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

  • Pokud jsou k dispozici, měly by produkty místo jejich opětovné implementace používat zavedené kryptografické protokoly poskytované platformou. Patří sem formáty podepisování (například použít standardní, stávající formát).

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

  • Nehlásit selhání kryptografických operací koncovým uživatelům. Při vrácení chyby vzdálenému volajícímu (například webovému klientovi nebo klientovi ve scénáři klient-server) použijte jenom obecnou chybovou zprávu.

    • Nepoužívejte žádné nepotřebné informace, například přímo oznamující chyby mimo rozsah nebo neplatné délky. Protokolovat podrobné chyby jenom na serveru a jenom v případě, že je povolené podrobné protokolování.

  • Další kontrola zabezpečení se důrazně doporučuje pro jakýkoli 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)

    • K novému protokolu, který používá kryptografii v novém nebo nestandardní metodě, patří:

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

      • Závisí protokol na jakémkoli jiném protokolu používané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čuje pro produkční prostředí. Použití certifikátu podepsaného svým držitelem, jako je použití nezpracovaných kryptografických klíčů, ze své podstaty neposkytuje uživatelům ani správcům žádný základ pro rozhodování o důvěryhodnosti.

    • Naopak použití certifikátu, který je zakořeněn v důvěryhodné certifikační autoritě, dává jasně najevo základ pro spoléhání se na přidružený soukromý klíč a umožňuje odvolání a aktualizace v případě selhání zabezpečení.

Šifrování citlivých dat před Storage

ROZHRANÍ DPAPI/DPAPI-NG

U dat, která je potřeba zachovat napříč restartováními systému:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 ROZHRANÍ DPAPI pro CNG)

U dat, která není potřeba uchovat po restartování systému:

  • CryptProtectMemory

  • CryptUnprotectMemory

U dat, která je potřeba zachovat a k nim získat přístup více účtů domény a počítačů:

SQL Server TDE

Pomocí funkce SQL Server transparentní šifrování dat (TDE) můžete chránit citlivá data.

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

Pro používání funkce TDE SQL důležité aspekty, které byste měli mít na paměti:

  • SQL Server nepodporuje šifrování dat FILESTREAM, i když je povolená funkce TDE.

  • TDE automaticky neposkytuje šifrování dat při přenosu do databáze nebo z databáze. měli byste také povolit šifrovaná připojení k SQL Server databáze. Pokyny k povolení šifrovaných připojení najdete v tématu Povolení šifrovaných připojení k databázovému stroji (SQL Server Správce konfigurace).

  • Pokud databázi chráněnou TDE přesunete do jiné instance SQL Server, měli byste také přesunout certifikát, který chrání šifrovací klíč dat TDE (DEK) SQL Server nainstalovat ho do hlavní databáze cílové instance SQL Server instance. Další podrobnosti najdete v článku o přesunutí chráněné databáze TDE na jiný SQL Server technetu.

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

Pomocí rozhraní API Windows Správce přihlašovacích údajů nebo Microsoft Azure KeyVault chránit data hesel a přihlašovacích údajů.

Windows store

Použijte třídy v Windows. Security.Cryptographya Windows. Obory názvů Security.Cryptography.DataProtection chrání tajemství a citlivá data.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

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

.NET

U dat, která je potřeba zachovat napříč restartováními systému:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

U dat, která není potřeba uchovat po restartování systému:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

U konfiguračních souborů použijte

buď RSAProtectedConfigurationProvider, nebo DPAPIProtectedConfigurationProvider k ochraně konfigurace pomocí šifrování RSA nebo ROZHRANÍ 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.