Megosztás a következőn keresztül:

Microsoft SDL-titkosítási javaslatok

  • Cikk

Ezeket az információkat referenciaként használhatja a termékek tervezésekor a Microsoft által a saját termékeihez és szolgáltatásaihoz szükséges API-k, algoritmusok, protokollok és kulcshosszok használatára. A tartalom nagy része a Microsoft saját belső biztonsági szabványán alapul, amelyet a biztonsági fejlesztési életciklus létrehozásához használnak.

A nem Windows-platformokon lévő fejlesztők számára hasznos lehet ezek a javaslatok. 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 protokollra, algoritmusra és kulcshosszra vonatkozó javaslatok

TLS/SSL-verziók

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

  • A TLS 1.3-at engedélyezni kell.
  • A TLS 1.2 engedélyezhető a régebbi ügyfelekkel való kompatibilitás javítása érdekében.
  • A TLS 1.1, a TLS 1.0, az SSL 3 és az SSL 2 le kell tiltani

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) használata ajánlott.
  • A titkosításhoz használt összes többi blokk-titkosítást, beleértve a 3DES-t (Triple DES/TDEA) és az RC4-et is ki kell cserélni.

A szimmetrikus blokktitkosítási algoritmusokhoz minimálisan 128 bites kulcshosszra van szükség, de javasoljuk a 256 bites kulcsok támogatását. 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).

Titkosítási módok

A szimmetrikus algoritmusok különböző módokon működnek, 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 titkosítási mód, például az azt követők, olyan implementációs buktatókkal rendelkeznek, amelyek nagyobb valószínűséggel használják őket helytelenül. Különösen el kell kerülni 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ódban", 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)
  • Bármi más, ami nem szerepel az előző "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 vektoroknak soha nem szabad állandónak vagy előre meghatározott értéknek lenniük. 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. Az újrafelhasználás információkat jeleníthet meg a titkosított adatokról, különösen akkor, ha streamelési titkosítási módokat használ, például kimeneti visszajelzést (OFB) vagy számlálót (CTR).

AES-GCM & AES-CCM-javaslatok

Az AES-GCM (Galois/Counter Mode) és az AES-CCM (CBC-MAC számláló) széles körben használják a hitelesített titkosítási módokat. A bizalmasság és az integritás védelmét egyesítik, így hasznossá teszik őket a biztonságos kommunikációhoz. Törékenységük azonban a nem szándékos újrafelhasználásban rejlik. Ha ugyanazt a nonce (inicializálási vektort) kétszer használják, az katasztrofális következményekkel járhat.

Javasoljuk, hogy kövesse az NIST SP 800-38D, a Blokkbomba titkosítási üzemmódokra vonatkozó javaslat: Galois/Counter Mode (GCM) és GMAC, különös figyelmet fordítva a 8.3. szakaszra a meghívások maximális számával kapcsolatban.

Egy másik lehetőség egyedi AES-GCM/CCM-kulcsokat hozna létre minden titkosított üzenethez, ami gyakorlatilag 1-re korlátozza a meghívások maximális számát. Ez a módszer ajánlott az inaktív adatok titkosításához, ahol egy számláló használata vagy annak biztosítása, hogy nyomon tudja követni egy adott kulcs meghívásainak maximális számát, nem praktikus.

Az inaktív adatok titkosításához az AES-CBC-t is használhatja üzenethitelesítési kóddal (MAC) alternatívaként egy Encryption-then-MAC séma használatával, így külön kulcsokat használhat a titkosításhoz és a MAC-hez.

Integritás ellenőrzése

Gyakori tévhit, hogy a titkosítás alapértelmezés szerint a bizalmasságot és az integritást is biztosítja. Számos titkosítási algoritmus nem biztosít integritás-ellenőrzést, és sebezhető lehet a illetéktelen támadásokkal szemben. További lépéseket kell tenni az adatok integritásának biztosítása érdekében a küldés és a fogadás előtt.

Ha nem tud hitelesített titkosítási algoritmust használni a társított adatokkal (AEAD), például az AES-GCM-sel, az integritást egy üzenethitelesítő kóddal (MAC) is érvényesítheti egy Encryption-then-MAC sémával, így külön kulcsokat használ a titkosításhoz és a MAC-hez.

A titkosításhoz és a MAC-hez elengedhetetlen egy külön kulcs használata. Ha nem lehet tárolni a két kulcsot, akkor egy érvényes alternatíva az, ha a főkulcsból két kulcsot egy megfelelő kulcslevezetési függvény (KDF) használatával nyerünk, egyet titkosítási célokra, egyet PEDIG MAC-hez. További információ: SP 800-108 Rev. 1, Recommendation for Key Derivation Using Pseudorandom Functions | CSRC (nist.gov).

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

RSA

  • Az RSA titkosításhoz, kulcscseréhez és aláírásokhoz használható.
  • 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.
  • Legalább 2048 bites kulcshossz ajánlott, de javasoljuk, hogy támogassa a 3072 bites kulcshosszt.

ECDSA és ECDH

  • Az ECDH-alapú kulcscserének és 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.
  • A P-256 támogatása a minimum, de javasoljuk, hogy támogassa a P-384-et.

Egész szám Diffie-Hellman

  • Kulcs hossza >= 2048 bit ajánlott0
  • A csoportparamétereknek jól ismert nevű csoportnak kell lenniük (például RFC 7919), vagy egy megbízható fél által generált és használat előtt hitelesített csoportnak kell lenniük.

Kulcsélettartamok

  • Adjon meg egy kriptoperiódát az összes kulcshoz.
    • Például: Az adattitkosítás szimmetrikus kulcsának (más néven adattitkosítási kulcsnak vagy DEK-nak) az adatok titkosításához legfeljebb két évig terjedő használati időszaka lehet, más néven a kezdeményező használati időszaka. Megadhatja, hogy a visszafejtéshez érvényes használati időszaka van még három évre, más néven a címzett-használat időszakára.
  • 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_U Standard kiadás_SYSTEM_PREFERRED_RNG jelzővel.

Win32/64

  • Az örökölt kód kernel módban használhatja az RtlGenRandom-ot .
  • Az új kódnak a BCryptGenRandom vagy a CryptGenRandom parancsot kell használnia.
  • A C függvény Rand_s() is ajánlott (amely Windows rendszeren meghívja a CryptGenRandom-t).
  • A Rand_s() a Rand() biztonságos és teljesítő pótlása.
  • A Rand() nem használható titkosítási alkalmazásokhoz.

.NET

PowerShell

Windows Áruházbeli alkalmazások

Linux/macOS

  • Az /dev/urandom eszköz a véletlenszerű adatok kriptográfiailag erős forrását biztosítja, ahogy a getrandom(2) rendszer hívja is.

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 nemplatformos 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 nemplatformos titkosítással kapcsolatos használati döntéseket a következő követelményeknek kell követnie:

  • A kódtárnak egy jelenleg támogatott verziónak kell lennie, amely nem rendelkezik ismert biztonsági résekkel.
  • A legújabb biztonsági protokollokat, algoritmusokat és kulcshosszokat támogatni kell.
  • (Nem kötelező) A kódtárnak képesnek kell lennie arra, hogy csak a visszamenőleges kompatibilitás érdekében támogassa a régebbi biztonsági protokollokat/algoritmusokat.

Natív kód

  • Crypto Primitívek: Ha a kiadás Windows rendszeren van, használja a CNG-t, ha lehetséges.
  • 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 (.NET)

  • Crypto Primitívek: Használja a System.Security.Cryptography névtérben definiált API-t.
  • Használja az elérhető .NET legújabb verzióját.

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 (1. változat): Javaslat a pseudorandom függvényeket használó 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 (3. változat): Javaslat a különálló logaritmus-titkosítást használó párszintű kulcslétrehozási sémákhoz.

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

Ha kulcsokat szeretne kinyerni egy megosztott titkos kódból (egy kulcsszerződés kimenetéből), használja a BCryptDeriveKey API-t az alábbi algoritmusok egyikével:

  • BCRYPT_KDF_SP80056A_CONCAT
  • BCRYPT_KDF_HMAC

Tanúsítvány érvényesítése

A 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 a folyamat a tanúsítvány alábbi részeinek ellenőrzését foglalja magában:

  • 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 a platform által megbízhatónak vagy a rendszergazda által explicit módon konfigurált legfelső szintű hitelesítésszolgáltatóhoz (CA) kell láncolnak.

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

Ne használjon "önaláírt" tanúsítványokat. Az önaláírt nem közvetíti a megbízhatóságot, a támogatás visszavonását vagy a támogatási kulcs megújítását.

Titkosítási kivonatfüggvények

A termékeknek az SHA-2 kivonatoló algoritmuscsaládot (SHA-256, SHA-384 és SHA-512) kell használniuk. A titkosítási kivonatok biztonsági célú csonkolása 128 bitesnél kisebbre nem engedélyezett. Bár az SHA-256 használata a minimum, javasoljuk, hogy támogassa az SHA-384-et.

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). Bár a HMAC-SHA256 használata a minimum, javasoljuk a HMAC-SHA384 támogatását.

A HMACs-k 128 bitesnél kisebbre való csonkolása 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 utá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 a metaadatnak tartalmaznia kell a használt algoritmust, a kulcsméreteket és a kitöltési módokat.
    • A titkosítási agilitásról további információt a titkosítási agilitás című cikkben talál.
  • Ahol elérhető, a termékeknek a meglévő, platform által biztosított titkosítási protokollokat kell használniuk ahelyett, hogy át kellene őket helyezniük, beleértve az aláírási formátumokat is (például szabványos, meglévő formátumot).
  • 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élnek ügyfélkiszolgálói forgatókönyv esetén), 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.
  • Minden olyan kialakításhoz, amely a következő elemeket tartalmazza, fokozottan ajánlott a biztonsági felülvizsgálat:
    • Elsősorban a biztonságra összpontosító új protokoll (például hitelesítési vagy engedélyezési protokoll)
    • Új protokoll, amely a titkosítást új vagy nem szabványos módon használja. Példák a következőkre:
      • 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 használata nem ajánlott. Az önaláírt tanúsítványok, például a nyers titkosítási kulcsok 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 a 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 engedélyezi a visszavonást és a frissítéseket.