Microsoft SDL titkosítási Javaslatok

  • Cikk

Bevezetés

Ez a dokumentum ajánlásokat és ajánlott eljárásokat tartalmaz a titkosítás Microsoft-platformokon való használatához. Az itt található tartalmak nagy része a Microsoft saját belső biztonsági szabványai alapján van megszabva vagy összesítve a biztonsági fejlesztési életciklus létrehozásához. Referenciának szánták, amikor olyan termékeket tervez, amelyek ugyanazokat az API-kat, algoritmusokat, protokollokat és kulcshosszokat használják, amelyeket a Microsoft saját termékeihez és szolgáltatásaihoz igényel.

A nem Windows-platformokon lévő fejlesztők is élvezhetik ezeket a javaslatokat. Bár az API- és kódtárnevek eltérőek lehetnek, az algoritmusválasztással, a kulcshosszsal és az adatvédelemmel kapcsolatos ajánlott eljárások a platformokon hasonlóak.

Biztonsági protokoll, algoritmus és kulcshossz Javaslatok

SSL/TLS-verziók

A termékeknek és szolgáltatásoknak az SSL/TLS kriptográfiailag biztonságos verzióit kell használniuk:

  • A TLS 1.2-t engedélyezni kell

  • A TLS 1.1 és a TLS 1.0 csak a visszamenőleges kompatibilitás érdekében engedélyezett

  • Alapértelmezés szerint le kell tiltani az SSL 3-at és az SSL 2-t

Szimmetrikus blokkjelek, titkosítási módok és inicializálási vektorok

Rejtjelek blokkolása

Szimmetrikus blokkjeleket használó termékek esetén:

  • Az Advanced Encryption Standard (AES) új kódhoz ajánlott.

  • A háromkulcsos tripla adattitkosítási szabvány (3DES) a meglévő kódban megengedett a visszamenőleges kompatibilitás érdekében.

  • Minden más blokktitkosítás, beleértve az RC2, a DES, a 2-Key 3DES, a DESX és a Skipjack titkosítást, csak a régi adatok visszafejtéséhez használható, és titkosítás esetén lecserélhető.

Szimmetrikus blokktitkosítási algoritmusok esetén a kulcs minimális hossza 128 bit. Az új kódhoz ajánlott egyetlen blokktitkosítási algoritmus az AES (AES-128, AES-192 és AES-256 mind elfogadható, ami azt jelzi, hogy az AES-192 nem optimalizál bizonyos processzorokat). A háromkulcsos 3DES jelenleg elfogadható, ha már használatban van a meglévő kódban; az AES-be való áttérés ajánlott. A DES, a DESX, az RC2 és a Skipjack már nem tekinthető biztonságosnak. Ezeket az algoritmusokat csak a meglévő adatok visszafejtéséhez szabad használni a visszamenőleges kompatibilitás érdekében, és az adatokat egy ajánlott blokktitkosítással kell újratitkosítani.

Titkosítási módok

A szimmetrikus algoritmusok különböző módokon működhetnek, amelyek többsége összekapcsolja a titkosítási műveleteket az egymást követő egyszerű szöveg- és rejtjelszöveg-blokkokon.

A szimmetrikus blokkok titkosítását az alábbi titkosítási módok egyikével kell használni:

Néhány más, az alábbihoz hasonló titkosítási mód implementálási buktatókkal rendelkezik, amelyek nagyobb valószínűséggel használják őket helytelenül. Különösen kerülni kell az elektronikus kódjegyzék (EKB) működési módját. Ha ugyanazt az inicializálási vektort (IV) újra felhasználja blokk-titkosításokkal a "streamelési titkosítási módokban", például a CTR-ben, a titkosított adatok felfedését okozhatja. Az alábbi módok bármelyikének használata esetén további biztonsági felülvizsgálat javasolt:

  • Kimeneti visszajelzés (OFB)

  • Titkosítási visszajelzés (CFB)

  • Számláló (CTR)

  • Számláló CBC-MAC (CCM) használatával

  • Galois/Counter Mód (GCM)

  • Bármi más, ami nem szerepel a fenti "ajánlott" listán

Inicializálási vektorok (IV)

Minden szimmetrikus blokkjelet kriptográfiailag erős véletlenszerű számmal is használni kell inicializálási vektorként. Az inicializálási vektorok soha nem lehetnek állandó értékek. A kriptográfiailag erős véletlenszerű számok létrehozására vonatkozó javaslatokért tekintse meg a Véletlenszerű számgenerátorok című témakört.

Az inicializálási vektorokat soha nem szabad újra felhasználni több titkosítási művelet végrehajtásakor, mivel ez információkat jeleníthet meg a titkosítandó adatokról, különösen akkor, ha streamelési titkosítási módokat használ, mint például a Kimeneti visszajelzés (OFB) vagy a Counter (CTR).

Aszimmetrikus algoritmusok, kulcshosszok és kitöltési módok

RSA

  • Az RSA-t titkosításhoz, kulcscseréhez és aláírásokhoz kell használni.

  • Az RSA-titkosításnak OAEP- vagy RSA-PSS-kitöltési módokat kell használnia. A meglévő kód csak a kompatibilitás érdekében használja a PKCS #1 v1.5 párnázási módot.

  • A null kitöltés használata nem ajánlott.

  • Kulcsok >= 2048 bit használata ajánlott

ECDSA

  • Az ECDSA >használata = 256 bites kulcsokkal javasolt

  • Az ECDSA-alapú aláírásoknak a három NIST által jóváhagyott görbe (P-256, P-384 vagy P521) egyikét kell használniuk.

ECDH

  • Az ECDH >használata = 256 bites kulcsokkal javasolt

  • Az ECDH-alapú kulcscserének a három NIST által jóváhagyott görbe (P-256, P-384 vagy P521) egyikét kell használnia.

Egész szám Diffie-Hellman

  • Kulcs hossza >= 2048 bit ajánlott

  • A csoportparamétereknek jól ismert csoportnak kell lenniük (pl. RFC 7919), vagy egy megbízható fél által létrehozott és a használat előtt hitelesítettnek kell lenniük

Kulcsélettartamok

  • Minden aszimmetrikus kulcsnak legfeljebb öt éves élettartamúnak kell lennie, ajánlott egyéves élettartam.

  • Minden szimmetrikus kulcsnak legfeljebb hároméves élettartamúnak kell lennie; ajánlott egyéves élettartam.

  • A korlátozott aktív élettartam elérése érdekében meg kell adnia egy mechanizmust, vagy rendelkeznie kell a kulcsok cseréjének folyamatával. Az aktív élettartam lejárta után a kulcs nem használható új adatok előállításához (például titkosításhoz vagy aláíráshoz), de az adatok olvasására is használható (például visszafejtéshez vagy ellenőrzéshez).

Véletlenszám-generátorok

Minden terméknek és szolgáltatásnak kriptográfiailag biztonságos véletlenszerű számgenerátorokat kell használnia, ha véletlenszerűségre van szükség.

CNG

  • A BCryptGenRandom használata a BCRYPT_UStandard kiadás_SYSTEM_PREFERRED_RNG jelzővel

CAPI

Win32/64

.

  • Az RNGCryptoServiceProvider használata

Windows Áruházbeli alkalmazások

Nem ajánlott

  • A véletlenszerű számgeneráláshoz kapcsolódó nem biztonságos függvények közé tartozik a rand, a System.Random (.NET), a GetTickCount és a GetTickCount64

  • A kettős háromliptikus görbe véletlenszerű számgenerátor ("DUAL_EC_DRBG") algoritmus használata nem ajánlott.

Windows platform által támogatott kriptográfiai kódtárak

A Windows platformon a Microsoft az operációs rendszerbe beépített titkosítási API-k használatát javasolja. Más platformokon a fejlesztők dönthetnek úgy, hogy kiértékelik a nem platformalapú titkosítási kódtárakat. Általánosságban elmondható, hogy a platformszintű kriptográfiai kódtárak gyakrabban frissülnek, mivel az operációs rendszer részeként szállítanak, és nem egy alkalmazáshoz vannak csomagolva.

A platformmal és a nem platformos titkosítással kapcsolatos használati döntéseket a következő követelményeknek kell vezérelniük:

  1. A kódtárnak egy jelenleg támogatott verziónak kell lennie, amely nem rendelkezik ismert biztonsági résekkel

  2. Támogatni kell a legújabb biztonsági protokollokat, algoritmusokat és kulcshosszokat

  3. (Nem kötelező) A kódtárnak képesnek kell lennie a régebbi biztonsági protokollok/algoritmusok támogatására csak a visszamenőleges kompatibilitás érdekében

Natív kód

  • Crypto Primitívek: Ha a kiadás windowsos vagy Windows Phone-telefon, használja a CNG-t, ha lehetséges. Ellenkező esetben használja a CryptoAPI-t (más néven CAPI-t, amely windowsos vista-ról örökölt összetevőként támogatott).

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

    • A WinHTTP-alkalmazásokat a WinHttpSetOptionhasználatával kell létrehozni a TLS 1.2 támogatásához

  • Kód aláírásának ellenőrzése: A WinVerifyTrust a Windows-platformokon a kódaadványok ellenőrzéséhez támogatott API.

  • Tanúsítványérvényesítés (kódaláíráshoz vagy SSL/TLS/DTLS-hez használt korlátozott tanúsítványérvényesítéshez): CAPI2 API; például CertGetCertificateChain és CertVerifyCertificateChainPolicy

Felügyelt kód

  • Crypto Primitívek: Használja a System.Security.Cryptography névtérben definiált API-t--- a CNG-osztályokat részesíti előnyben.

  • Használja az elérhető .Net-keretrendszer legújabb verzióját. Ennek legalább a .Net-keretrendszer 4.6-os verziójának kell lennie. Ha régebbi verzióra van szükség, győződjön meg arról, hogy a "SchUseStrongCrypto" regkey úgy van beállítva, hogy engedélyezze a TLS 1.2-t a szóban forgó alkalmazáshoz.

  • Tanúsítványérvényesítés: A System.Security.Cryptography.X509Certificates névtérben definiált API-k használata.

  • SSL/TLS/DTLS: A System.Net névtérben (például HttpWebRequest) definiált API-k használata.

Fő származtatási függvények

A kulcs származtatása a titkosítási kulcs anyagának egy megosztott titkos kódból vagy egy meglévő titkosítási kulcsból való származtatásának folyamata. A termékeknek ajánlott kulcs származtatási függvényeket kell használniuk. A kulcsok felhasználó által választott jelszavakból való származtatása vagy a hitelesítési rendszerekben a tárterülethez tartozó kivonatolási jelszavak egy speciális eset, amelyre ez az útmutató nem terjed ki; a fejlesztőknek szakértőt kell kérnie.

A következő szabványok a használathoz ajánlott KDF-függvényeket határozzák meg:

  • NIST SP 800-108: Javaslat a pszeudondomfüggvények használatával történő kulcs származtatására. Különösen a KDF számláló módban, a HMAC-val pszeudorandom függvényként

  • NIST SP 800-56A (2. változat): Javaslat a különálló logaritmus-titkosítást használó párszintű kulcslétrehozási sémákra. Különösen az 5.8.1 szakaszban javasolt az "Egylépéses kulcs származtatási függvénye".

A kulcsok meglévő kulcsokból való származtatásához használja a BCryptKeyDerivation API-t az egyik algoritmussal:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM

  • BCRYPT_SP80056A_CONCAT_ALGORITHM

A kulcsok közös titkos kódból (kulcsszerződés kimenetéből) való származtatásához használja a BCryptDeriveKey API-t az alábbi algoritmusok egyikével:

  • BCRYPT_KDF_SP80056A_CONCAT

  • BCRYPT_KDF_HMAC

A tanúsítványok érvényesítése

Az SSL-t, TLS-t vagy DTLS-t használó termékeknek teljes mértékben ellenőrizniük kell a hozzájuk csatlakozó entitások X.509-tanúsítványait. Ez magában foglalja a tanúsítványok ellenőrzését is":

  • Tartománynév.

  • Érvényességi dátumok (mind a kezdő, mind a lejárati dátum).

  • Visszavonás állapota.

  • Használat (például "Kiszolgálóhitelesítés" kiszolgálókhoz, "Ügyfél-hitelesítés" az ügyfelek számára).

  • Megbízhatósági lánc. A tanúsítványoknak olyan legfelső szintű hitelesítésszolgáltatóhoz (CA) kell láncolnia, amelyet a platform megbízhatónak vagy a rendszergazda explicit módon konfigurál.

Ha ezen ellenőrzési tesztek bármelyike sikertelen, a terméknek meg kell szüntetnie a kapcsolatot az entitással.

Az "önaláírt" tanúsítványokban bízó ügyfelek (például egy exchange-kiszolgálóhoz alapértelmezett konfigurációban csatlakozó levelezőügyfél) figyelmen kívül hagyhatják a tanúsítvány-ellenőrzési ellenőrzéseket. Az önaláírt tanúsítványok azonban nem közvetítenek megbízhatóságot, nem támogatják a visszavonást vagy a támogatási kulcs megújítását. Csak akkor megbízhatók az önaláírozott tanúsítványok, ha egy másik megbízható forrásból szerezte be őket (például egy megbízható entitástól, amely hitelesített és integritás által védett átvitelen keresztül biztosítja a tanúsítványt).

Titkosítási kivonatfüggvények

A termékeknek az SHA-2 kivonatoló algoritmuscsaládot (SHA256, SHA384 és SHA512) kell használniuk. A titkosítási kivonatok 128 bitesnél kisebb biztonsági célokra való csonkolása nem ajánlott.

MAC/HMAC/kulcsos kivonatoló algoritmusok

Az üzenethitelesítési kód (MAC) egy üzenethez csatolt információ, amely lehetővé teszi a címzett számára, hogy titkos kulcs használatával ellenőrizze mind a feladó hitelességét, mind az üzenet integritását.

Hash-alapú MAC (HMAC) vagy blokk-titkosításon alapuló MAC használata ajánlott mindaddig, amíg az összes mögöttes kivonat- vagy szimmetrikus titkosítási algoritmus használata is ajánlott; jelenleg ez magában foglalja a HMAC-SHA2 függvényeket (HMAC-SHA256, HMAC-SHA384 és HMAC-SHA512).

A HMAC-k csonkolása 128 bitesnél kisebbre nem ajánlott.

Tervezési és üzemeltetési szempontok

  • Szükség esetén meg kell adnia egy mechanizmust a titkosítási kulcsok cseréjéhez. A kulcsokat az aktív élettartamuk végéhez érve vagy a titkosítási kulcs feltörése esetén kell cserélni. Amikor megújít egy tanúsítványt, új kulccsal kell megújítani.

  • Az adatok védelmére titkosítási algoritmusokat használó termékeknek elegendő metaadatot kell tartalmazniuk a tartalommal együtt ahhoz, hogy a jövőben támogatást nyújtsanak a különböző algoritmusokra való migráláshoz. Ennek tartalmaznia kell a használt algoritmust, a kulcsméreteket, az inicializálási vektorokat és a párnázási módokat.

  • Ahol elérhető, a termékeknek a meglévő, platform által biztosított titkosítási protokollokat kell használniuk ahelyett, hogy újra implementálják őket. Ide tartoznak az aláírási formátumok (például szabványos, meglévő formátum használata).

  • Szimmetrikus adatfolyam-titkosításokat, például RC4-eket nem szabad használni. Szimmetrikus adatfolyam-titkosítások helyett a termékeknek blokk-titkosítást kell használniuk, különösen az AES-t, amelynek kulcshossza legalább 128 bit.

  • Ne jelentse a titkosítási műveletek hibáit a végfelhasználóknak. Ha hibát ad vissza egy távoli hívónak (például webügyfélnek vagy ügyfélkiszolgálói forgatókönyvben), csak általános hibaüzenetet használjon.

    • Kerülje a szükségtelen információk megadását, például a tartományon kívüli vagy érvénytelen hosszhibák közvetlen bejelentését. Részletes hibák naplózása csak a kiszolgálón, és csak akkor, ha a részletes naplózás engedélyezve van.

  • További biztonsági felülvizsgálat kifejezetten ajánlott minden olyan kialakításhoz, amely az alábbiakat tartalmazza:

    • Elsősorban a biztonságra összpontosító új protokoll (például hitelesítési vagy engedélyezési protokoll)

    • Egy új protokoll, amely a titkosítást új vagy nem szabványos módon használja, például a következők:

      • A protokollt megvalósító termék meghív bármilyen titkosítási API-t vagy metódust a protokoll implementációjának részeként?

      • A protokoll függ a hitelesítéshez vagy engedélyezéshez használt egyéb protokolltól?

      • A protokoll definiálja a titkosítási elemek, például kulcsok tárolási formátumait?

  • Az önaláírt tanúsítványok éles környezetekben nem ajánlottak. Az önaláírt tanúsítványok használata, például a nyers titkosítási kulcs használata, nem biztosít semmilyen alapot a felhasználók vagy a rendszergazdák számára a megbízhatósági döntés meghozatalához.

    • Ezzel szemben egy megbízható hitelesítésszolgáltatóban gyökerező tanúsítvány használata egyértelművé teszi a társított titkos kulcsra való támaszkodás alapjait, és biztonsági hiba esetén lehetővé teszi a visszavonást és a frissítéseket.

Bizalmas adatok titkosítása a tárolás előtt

DPAPI/DPAPI-NG

A rendszer újraindításai között megőrzendő adatok:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

Olyan adatok esetében, amelyeket nem kell a rendszer újraindításai között őrizni:

  • CryptProtectMemory

  • CryptUnprotectMemory

Több tartományi fióknak és számítógépnek kell őriznie és elérnie az adatokat:

SQL Server TDE

Az SQL Server transzparens adattitkosítás (TDE) használatával védheti a bizalmas adatokat.

Olyan TDE-adatbázistitkosítási kulcsot (DEK) kell használnia, amely megfelel az SDL titkosítási algoritmusnak és a kulcserősség követelményeinek. Jelenleg csak AES_128, AES_192 és AES_256 ajánlott; TRIPLE_DES_3KEY nem ajánlott.

Az SQL TDE használatának néhány fontos szempontja van, amelyeket érdemes szem előtt tartania:

  • Az SQL Server nem támogatja a FILESTREAM-adatok titkosítását, még akkor sem, ha a TDE engedélyezve van.

  • A TDE nem biztosít automatikusan titkosítást az adatbázisba vagy az adatbázisból átvitt adatokhoz; az SQL Server-adatbázis titkosított kapcsolatait is engedélyeznie kell. A titkosított kapcsolatok engedélyezésével kapcsolatos útmutatásért lásd: Titkosított Csatlakozás ions engedélyezéseaz adatbázismotorhoz (SQL Server Konfigurációkezelő).

  • Ha egy TDE által védett adatbázist egy másik SQL Server-példányra helyez át, akkor a TDE adattitkosítási kulcsot (DEK) védő tanúsítványt is át kell helyeznie, és telepítenie kell a cél SQL Server-példány főadatbázisába. További részletekért tekintse meg a TechNet TDE által védett adatbázis áthelyezése egy másik SQL Serverre című cikkét.

Hitelesítő adatok kezelése

A Windows Credential Manager API vagy a Microsoft Azure KeyVault használatával védheti a jelszavakat és a hitelesítő adatokat.

Windows Áruházbeli alkalmazások

A Titkos kódok és bizalmas adatok védelméhez használja a Windows.Security.Cryptography és a Windows.Security.Cryptography.DataProtection névterek osztályait.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • AzStreamAsync védelmének megszüntetése

A Windows.Security.Credentials névtér osztályai segítségével védheti a jelszavakat és a hitelesítő adatokat.

.NET

A rendszer újraindításai között megőrzendő adatok:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

Olyan adatok esetében, amelyeket nem kell a rendszer újraindításai között őrizni:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

Konfigurációs fájlok esetén használja a

VAGY RSAProtectedConfigurationProvider vagy DPAPIProtectedConfigurationProvider a konfiguráció védelméhez RSA-titkosítással vagy DPAPI-val.

Az RSAProtectedConfigurationProvider egy fürt több gépén is használható. További információt a Konfigurációs adatok titkosítása védett konfiguráció használatával című témakörben talál.