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

A AES-GCM (Galois/Számláló mód) és a AES-CCM (számláló CBC-MAC) 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 a NIST SP 800-38D, a Blokk Rejtjelezési Módok Ajánlásait: Galois/Counter Mode (GCM) és GMACcímű dokumentumban leírt egyszer használatos értékek útmutatóját, 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 fontolja meg a AES-CBC használatát egy üzenethitelesítő kóddal (MAC), alternatívaként az Encrypt-then-MAC séma alkalmazásával. Ügyeljen arra, hogy külön kulcsokat használjon 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ókért, lásd: 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 párnázá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

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

Kulcsok élettartama

  • Definiáljon egy kriptográfiai időszakot az összes kulcsra.
    • 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 három évig érvényes használati időszaka van, amit úgy is ismernek, mint a címzett-használati időszak.
  • 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

  • Használja a BCryptGenRandom-t a BCRYPT_USE_SYSTEM_PREFERRED_RNG jelzővel.

Win32/64

  • Az örökölt kód kernel módban használhatja RtlGenRandom.
  • Az új kódnak BCryptGenRandom vagy CryptGenRandomkell használnia.
  • A C függvény Rand_s() is ajánlott (amely Windows rendszeren meghívja CryptGenRandom).
  • 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

  • A /dev/urandom eszköz a véletlenszerű adatok kriptográfiailag erős forrását biztosítja, ahogyan a getrandom(2) rendszerhívást 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 lehetséges, használja a CNG-t, ha a kiadás Windows rendszeren történik.
  • Kód aláírásának ellenőrzése: WinVerifyTrust a Windows-platformokon a kód aláírások ellenőrzésére szolgáló 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)

  • Kriptográfiai alapelemek: 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 felhasználó által választott jelszavakból való kulcsszármaztatás, vagy a jelszavaknak az autentikációs rendszerbe való tárolása céljából történő kivonatolása egy olyan speciális eset, amelyre ez az útmutató nem terjed ki; a fejlesztőknek szakértőt kell kérniük.

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 pszeudondomfü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. kiadás): Javaslat a diszkrét logaritmus kriptográfiát használó kulcslétrehozási sémákhoz Pair-Wise.

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 (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:

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

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 tanúsítványok nem jelentenek megbízhatóságot önmagukban, nem támogatják a visszavonást, és nem támogatják a kulcs megújítását.

Kriptográfiai 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.

A kivonatalapú 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 javasolt; 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 minimális, javasoljuk, hogy támogassa a HMAC-SHA384-et.

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 végezze el a megújítást.
  • 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.
  • 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. A részletes hibák naplózása csak akkor történjen a kiszolgálón, ha a részletes naplózás engedélyezett.
  • 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.