Udostępnij za pośrednictwem

Zalecenia kryptograficzne dotyczące języka Microsoft SDL

  • Artykuł

Te informacje są używane jako informacje referencyjne podczas projektowania produktów do używania tych samych interfejsów API, algorytmów, protokołów i długości kluczy, których firma Microsoft wymaga od własnych produktów i usług. Większość zawartości jest oparta na własnych wewnętrznych standardach zabezpieczeń firmy Microsoft używanych do tworzenia cyklu projektowania zabezpieczeń.

Deweloperzy na platformach innych niż Windows mogą korzystać z tych zaleceń. Chociaż nazwy interfejsów API i bibliotek mogą być różne, najlepsze rozwiązania dotyczące wyboru algorytmu, długości klucza i ochrony danych są podobne na różnych platformach.

Zalecenia dotyczące protokołu zabezpieczeń, algorytmu i długości klucza

Wersje protokołu TLS/SSL

Produkty i usługi powinny używać kryptograficznie bezpiecznych wersji protokołu TLS/SSL:

  • Należy włączyć protokół TLS 1.3.
  • Protokół TLS 1.2 można włączyć, aby zwiększyć zgodność ze starszymi klientami.
  • Protokoły TLS 1.1, TLS 1.0, SSL 3 i SSL 2 muszą być wyłączone

Symetryczne szyfry blokowe, tryby szyfrowania i wektory inicjowania

Blokuj szyfry

W przypadku produktów korzystających z szyfrów bloków symetrycznych:

  • Zalecana jest usługa Advanced Encryption Standard (AES).
  • Wszystkie inne szyfry blokowe, w tym 3DES (Triple DES/TDEA) i RC4 muszą zostać zastąpione, jeśli są używane do szyfrowania.

W przypadku algorytmów szyfrowania bloków symetrycznych wymagana jest minimalna długość klucza wynosząca 128 bitów, ale zalecamy obsługę kluczy 256-bitowych. Jedynym algorytmem szyfrowania bloku zalecanym dla nowego kodu jest AES(AES-128, AES-192 i AES-256 są dopuszczalne, zauważając, że AES-192 brakuje optymalizacji na niektórych procesorach).

Tryby szyfrowania

Algorytmy symetryczne mogą działać w różnych trybach, z których większość łączy operacje szyfrowania na kolejnych blokach zwykłego tekstu i szyfrowania.

Szyfry bloków symetrycznych powinny być używane z jednym z następujących trybów szyfrowania:

Niektóre inne tryby szyfrowania, takie jak te, które następują, mają pułapki implementacji, które sprawiają, że są one bardziej prawdopodobne, aby były niepoprawnie używane. W szczególności należy unikać trybu działania elektronicznej książki kodowej (EBC). Ponowne użycie tego samego wektora inicjowania (IV) przy użyciu szyfrów blokowych w trybach "szyfrowania przesyłania strumieniowego", takich jak CTR, może spowodować ujawnienie zaszyfrowanych danych. Jeśli którykolwiek z poniższych trybów jest używany, zaleca się przeprowadzenie dodatkowego przeglądu zabezpieczeń:

  • Opinie wyjściowe (OFB)
  • Opinie szyfrowania (CFB)
  • Licznik (CTR)
  • Wszystkie inne elementy, które nie znajdują się na powyższej liście "zalecane"

Wektory inicjowania (IV)

Wszystkie symetryczne szyfry bloków powinny być również używane z kryptograficznie silną liczbą losową jako wektor inicjowania. Wektory inicjowania nigdy nie powinny być wartością stałą lub predykalną. Zobacz Generatory liczb losowych, aby uzyskać zalecenia dotyczące generowania kryptograficznie silnych liczb losowych.

Wektory inicjowania nigdy nie powinny być ponownie używane podczas wykonywania wielu operacji szyfrowania. Ponowne użycie może ujawniać informacje o szyfrowanych danych, szczególnie w przypadku korzystania z trybów szyfrowania przesyłania strumieniowego, takich jak Dane zwrotne wyjściowe (OFB) lub Licznik (CTR).

Zalecenia dotyczące usługi AES-GCM i AES-CCM

AES-GCM (Galois/Counter Mode) i AES-CCM (Counter with CBC-MAC) są powszechnie używane uwierzytelnione tryby szyfrowania. Łączą one poufność i ochronę integralności, co ułatwia bezpieczną komunikację. Jednak ich kruchość leży w nienależących do ponownego użycia. Gdy ten sam wektor inicjalizacji jest używany dwa razy, może prowadzić do katastrofalnego konsekwencji.

Zalecamy przestrzeganie wytycznych innych niż opisane w temacie NIST SP 800-38D, zalecenie dotyczące trybów szyfrowania blokowego operacji: Galois/Counter Mode (GCM) i GMAC, szczególną uwagę na sekcję 8.3 dotyczącą maksymalnej liczby wywołań.

Kolejną opcją jest generowanie unikatowych kluczy AES-GCM/CCM dla każdego zaszyfrowanego komunikatu, co skutecznie ogranicza maksymalną liczbę wywołań do 1. Takie podejście jest zalecane w przypadku szyfrowania danych magazynowanych, gdzie użycie licznika lub upewnienie się, że można śledzić maksymalną liczbę wywołań dla danego klucza, byłoby niepraktyczne.

W przypadku szyfrowania danych magazynowanych można również rozważyć użycie protokołu AES-CBC z kodem uwierzytelniania komunikatów (MAC) jako alternatywą przy użyciu schematu Encrypt-then-MAC, upewniając się, że używasz oddzielnych kluczy do szyfrowania i dla komputerów MAC.

Weryfikacja integralności

Jest to typowe błędne przekonanie, że szyfrowanie domyślnie zapewnia zarówno poufność, jak i integralność. Wiele algorytmów szyfrowania nie zapewnia żadnego sprawdzania integralności i może być narażonych na manipulowanie atakami. Przed wysłaniem i po otrzymaniu należy wykonać dodatkowe kroki w celu zapewnienia integralności danych.

Jeśli nie możesz użyć uwierzytelnionego algorytmu szyfrowania ze skojarzonymi danymi (AEAD), takim jak AES-GCM, alternatywą byłoby zweryfikowanie integralności przy użyciu kodu uwierzytelniania komunikatów (MAC) przy użyciu schematu Encrypt-then-MAC, upewniając się, że używasz oddzielnych kluczy do szyfrowania i dla komputerów MAC.

Używanie oddzielnego klucza do szyfrowania i dla komputera MAC jest niezbędne. Jeśli nie można przechowywać tych dwóch kluczy, prawidłową alternatywą jest wyprowadzenie dwóch kluczy z klucza głównego przy użyciu odpowiedniej funkcji wyprowadzania kluczy (KDF), jednej do celów szyfrowania i jednego dla komputerów MAC. Aby uzyskać więcej informacji, zobacz SP 800-108 Rev. 1, Zalecenie dotyczące wyprowadzania klucza przy użyciu funkcji pseudorandom | CSRC (nist.gov).

Algorytmy asymetryczne, długości kluczy i tryby wypełnienia

RSA

  • RsA może służyć do szyfrowania, wymiany kluczy i podpisów.
  • Szyfrowanie RSA powinno używać trybów wypełnienia OAEP lub RSA-PSS.
  • Istniejący kod powinien używać trybu uzupełniania PKCS #1 w wersji 1.5, aby zapewnić zgodność.
  • Nie zaleca się używania dopełniania o wartości null.
  • Zalecana jest minimalna długość klucza 2048-bitowego, ale zalecamy obsługę długości klucza 3072-bitowego.

ECDSA i ECDH

  • Oparte na ECDH wymiany kluczy i sygnatury oparte na ECDSA powinny używać jednej z trzech krzywych zatwierdzonych przez NIST (P-256, P-384 lub P521).
  • Obsługa P-256 powinna być traktowana jako minimalna, ale zalecamy obsługę protokołu P-384.

Liczba całkowita Diffie-Hellman

  • Zalecana jest długość >klucza = 2048 bitów
  • Parametry grupy powinny być dobrze znaną grupą nazwaną (na przykład RFC 7919) lub wygenerowaną przez zaufaną firmę i uwierzytelnianą przed użyciem.

Okresy istnienia kluczy

  • Zdefiniuj cryptoperiod dla wszystkich kluczy.
    • Na przykład: Klucz symetryczny szyfrowania danych, często nazywany kluczem szyfrowania danych lub kluczem szyfrowania danych, może mieć okres użycia do dwóch lat na potrzeby szyfrowania danych, znany również jako okres użycia jednostki źródłowej. Można zdefiniować, że ma prawidłowy okres użycia odszyfrowywania przez trzy lata, znany również jako okres użycia adresata.
  • Należy podać mechanizm lub mieć proces wymiany kluczy w celu osiągnięcia ograniczonego aktywnego okresu istnienia. Po zakończeniu aktywnego okresu istnienia klucz nie może być używany do tworzenia nowych danych (na przykład na potrzeby szyfrowania lub podpisywania), ale może być nadal używany do odczytywania danych (na przykład do odszyfrowywania lub weryfikacji).

Generatory liczb losowych

Wszystkie produkty i usługi powinny używać kryptograficznie zabezpieczonych generatorów liczb losowych, gdy jest wymagana losowość.

CNG

Win32/64

.NET

PowerShell

Aplikacje Windows Store

Linux/macOS

  • Urządzenie /dev/urandom zapewnia kryptograficznie silne źródło danych losowych, podobnie jak wywołanie getrandom(2) systemowe.

Biblioteki kryptograficzne obsługiwane przez platformę Windows

Na platformie Windows firma Microsoft zaleca korzystanie z interfejsów API kryptograficznych wbudowanych w system operacyjny. Na innych platformach deweloperzy mogą zdecydować się na ocenę nieplatformowych bibliotek kryptograficznych do użycia. Ogólnie rzecz biorąc, biblioteki kryptograficzne platformy są aktualizowane częściej, ponieważ są dostarczane jako część systemu operacyjnego, w przeciwieństwie do pakietu z aplikacją.

Każda decyzja o użyciu dotycząca platformy a kryptografii nieplatformowej powinna kierować się następującymi wymaganiami:

  • Biblioteka powinna być bieżącą wersją bez znanych luk w zabezpieczeniach.
  • Powinny być obsługiwane najnowsze protokoły zabezpieczeń, algorytmy i długości kluczy.
  • (Opcjonalnie) Biblioteka powinna obsługiwać tylko starsze protokoły zabezpieczeń/algorytmy w celu zapewnienia zgodności z poprzednimi wersjami.

Kod natywny

  • Crypto Primitives: jeśli twoja wersja jest w systemie Windows, użyj CNG, jeśli to możliwe.
  • Weryfikacja podpisu kodu: WinVerifyTrust jest obsługiwanym interfejsem API do weryfikowania podpisów kodu na platformach Windows.
  • Weryfikacja certyfikatu (używana w weryfikacji ograniczonego certyfikatu do podpisywania kodu lub SSL/TLS/DTLS): interfejs API CAPI2; na przykład CertGetCertificateChain i CertVerifyCertificateChainPolicy.

Kod zarządzany (.NET)

Funkcje wyprowadzania kluczy

Wyprowadzanie klucza to proces wyprowadzania materiału klucza kryptograficznego z wspólnego wpisu tajnego lub istniejącego klucza kryptograficznego. Produkty powinny używać zalecanych funkcji wyprowadzania kluczy. Wyprowadzanie kluczy z haseł wybranych przez użytkownika lub wyznaczanie skrótów haseł do przechowywania w systemie uwierzytelniania jest specjalnym przypadkiem, który nie jest objęty tym wskazówkami; deweloperzy powinni skonsultować się z ekspertem.

Następujące standardy określają zalecane funkcje KDF do użycia:

  • NIST SP 800-108 (poprawka 1): zalecenie dotyczące wyprowadzania klucza przy użyciu funkcji pseudorandom. W szczególności funkcja KDF w trybie licznika z HMAC jako funkcja pseudorandom
  • NIST SP 800-56A (poprawka 3): Zalecenie dotyczące schematów ustanowienia kluczy z zastosowaniem dyskretnej logarytmicznej kryptografii.

Aby uzyskać klucze z istniejących kluczy, użyj interfejsu API BCryptKeyDerivation z jednym z algorytmów:

  • BCRYPT_SP800108_CTR_HMAC_ALGORITHM
  • BCRYPT_SP80056A_CONCAT_ALGORITHM

Aby uzyskać klucze z udostępnionego wpisu tajnego (dane wyjściowe umowy klucza), użyj interfejsu API BCryptDeriveKey z jednym z następujących algorytmów:

  • BCRYPT_KDF_SP80056A_CONCAT
  • BCRYPT_KDF_HMAC

Walidacja certyfikatu

Produkty korzystające z protokołu TLS lub DTLS powinny w pełni zweryfikować certyfikaty X.509 jednostek, z którymi się łączą. Ten proces obejmuje weryfikację następujących części certyfikatu:

  • Nazwa domeny.
  • Daty ważności (daty rozpoczęcia i wygaśnięcia).
  • Stan odwołania.
  • Użycie (na przykład "Uwierzytelnianie serwera" dla serwerów, "Uwierzytelnianie klienta" dla klientów).
  • Łańcuch zaufania. Certyfikaty powinny łączyć się z głównym urzędem certyfikacji zaufanym przez platformę lub jawnie skonfigurowanym przez administratora.

Jeśli którykolwiek z tych testów weryfikacyjnych zakończy się niepowodzeniem, produkt powinien zakończyć połączenie z jednostką.

Nie używaj certyfikatów z podpisem własnym. Podpis własny nie przekazuje z natury zaufania, odwołania obsługi ani odnawiania klucza pomocy technicznej.

Funkcje skrótów kryptograficznych

Produkty powinny używać rodziny algorytmów wyznaczania wartości skrótu SHA-2 (SHA-256, SHA-384 i SHA-512). Obcinanie skrótów kryptograficznych na potrzeby zabezpieczeń do mniej niż 128 bitów nie jest dozwolone. Chociaż użycie algorytmu SHA-256 jest minimalne, zalecamy obsługę algorytmu SHA-384.

Algorytmy skrótów MAC/HMAC/keyed

Kod uwierzytelniania komunikatów (MAC) jest elementem informacji dołączonym do wiadomości, która umożliwia odbiorcy zweryfikowanie zarówno autentyczności nadawcy, jak i integralności wiadomości przy użyciu klucza tajnego.

Korzystanie z mac opartych na skrótach (HMAC) lub mac opartych na szyfrach blokowych jest zalecane, o ile wszystkie podstawowe algorytmy szyfrowania skrótu lub symetrycznego są również zalecane do użycia. Obecnie obejmuje to funkcje HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 i HMAC-SHA512). Chociaż użycie HMAC-SHA256 jest minimalne, zalecamy obsługę HMAC-SHA384.

Obcięcie hmACs do mniej niż 128 bitów nie jest zalecane.

Zagadnienia dotyczące projektowania i działania

  • W razie potrzeby należy podać mechanizm wymiany kluczy kryptograficznych. Klucze powinny zostać zastąpione po osiągnięciu końca aktywnego okresu istnienia lub złamaniu zabezpieczeń klucza kryptograficznego.
    • Za każdym razem, gdy odnowisz certyfikat, należy go odnowić przy użyciu nowego klucza.
  • Produkty korzystające z algorytmów kryptograficznych do ochrony danych powinny zawierać wystarczającą ilość metadanych wraz z zawartością do obsługi migracji do różnych algorytmów w przyszłości. Te metadane powinny obejmować używany algorytm, rozmiary kluczy i tryby uzupełniania.
    • Aby uzyskać więcej informacji na temat elastyczności kryptograficznych, zobacz artykuł Zwinność kryptograficzna.
  • Jeśli są dostępne, produkty powinny używać ustalonych protokołów kryptograficznych udostępnianych przez platformę, a nie ich ponownego wdrażania, w tym formatów podpisywania (na przykład używać standardowego, istniejącego formatu).
  • Nie zgłaszaj niepowodzeń operacji kryptograficznych użytkownikom końcowym. W przypadku zwracania błędu do zdalnego wywołującego (na przykład klienta internetowego lub klienta w scenariuszu klient-serwer) użyj tylko ogólnego komunikatu o błędzie.
    • Unikaj podawania niepotrzebnych informacji, takich jak bezpośrednie zgłaszanie błędów poza zakresem lub nieprawidłowej długości. Rejestruj pełne błędy tylko na serwerze i tylko wtedy, gdy pełne rejestrowanie jest włączone.
  • Dodatkowe przeglądy zabezpieczeń są zdecydowanie zalecane w przypadku każdego projektu zawierającego następujące elementy:
    • Nowy protokół, który koncentruje się głównie na zabezpieczeniach (takich jak protokół uwierzytelniania lub autoryzacji)
    • Nowy protokół, który używa kryptografii w sposób nowatorski lub nietypowy. Przykładowe zagadnienia obejmują:
      • Czy produkt, który implementuje protokół, wywołuje dowolne interfejsy API lub metody kryptograficzne w ramach implementacji protokołu?
      • Czy protokół zależy od dowolnego innego protokołu używanego do uwierzytelniania lub autoryzacji?
      • Czy protokół zdefiniuje formaty magazynu dla elementów kryptograficznych, takich jak klucze?
  • Certyfikaty z podpisem własnym nie są zalecane. Korzystanie z certyfikatu z podpisem własnym, takiego jak użycie nieprzetworzonego klucza kryptograficznego, nie zapewnia użytkownikom ani administratorom żadnej podstawy do podejmowania decyzji o zaufaniu.
    • Z kolei użycie certyfikatu rooted w zaufanym urzędzie certyfikacji jasno określa podstawę do polegania na skojarzonym kluczu prywatnym i włącza odwoływanie i aktualizacje, jeśli wystąpi awaria zabezpieczeń.