Rekomendacje kryptograficzne języka Microsoft SDL

  • Artykuł

Wprowadzenie

Ten dokument zawiera zalecenia i najlepsze rozwiązania dotyczące używania szyfrowania na platformach firmy Microsoft. Większość zawartości w tym miejscu jest sparafrasowana lub agregowana na podstawie własnych wewnętrznych standardów zabezpieczeń firmy Microsoft używanych do tworzenia cyklu projektowania zabezpieczeń. Jest on używany jako odwołanie 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.

Deweloperzy na platformach innych niż Windows mogą również 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.

Protokół zabezpieczeń, algorytm i długość klucza Rekomendacje

Wersje protokołu SSL/TLS

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

  • Należy włączyć protokół TLS 1.2

  • Protokoły TLS 1.1 i TLS 1.0 powinny być włączone tylko w celu zapewnienia zgodności z poprzednimi wersjami

  • Protokół SSL 3 i SSL 2 powinny być domyślnie wyłączone

Symetryczne szyfry blokowe, tryby szyfrowania i wektory inicjowania

Szyfry blokowe

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

  • Usługa Advanced Encryption Standard (AES) jest zalecana w przypadku nowego kodu.

  • Trzykrotne potrójne szyfrowanie danych Standard (3DES) jest dopuszczalne w istniejącym kodzie w celu zapewnienia zgodności z poprzednimi wersjami.

  • Wszystkie inne szyfry blokowe, w tym RC2, DES, 2-Key 3DES, DESX i Skipjack, powinny być używane tylko do odszyfrowywania starych danych i powinny zostać zastąpione w przypadku szyfrowania.

W przypadku algorytmów szyfrowania bloków symetrycznych zalecana jest minimalna długość klucza wynosząca 128 bitów. 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). Funkcja 3DES z trzema kluczami jest obecnie akceptowalna, jeśli jest już używana w istniejącym kodzie; zalecane jest przejście do AES. DES, DESX, RC2 i Skipjack nie są już uważane za bezpieczne. Te algorytmy powinny być używane tylko do odszyfrowywania istniejących danych ze względu na zgodność z poprzednimi wersjami, a dane powinny być ponownie szyfrowane przy użyciu zalecanego szyfrowania blokowego.

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 wymienione poniżej, 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 inicjalizacji (IV) z szyframi blokowymi w trybach szyfrowania przesyłania strumieniowego, takim 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)

  • Licznik z CBC-MAC (CCM)

  • Tryb Galois/Licznik (GCM)

  • Wszystkie inne elementy, które nie znajdują się na powyższej liście "zalecane"

Wektory inicjalizacji (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łą. 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, ponieważ mogą to ujawniać informacje o zaszyfrowanych danych, szczególnie w przypadku korzystania z trybów szyfrowania przesyłania strumieniowego, takich jak Dane zwrotne (OFB) lub Licznik (CTR).

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

RSA

  • RsA należy używać 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 wypełniania o wartości null.

  • Zalecane są klucze >= 2048 bitów

ECDSA

  • Zalecana jest usługa ECDSA z >= 256-bitowymi kluczami

  • Podpisy oparte na ECDSA powinny używać jednej z trzech krzywych zatwierdzonych przez NIST (P-256, P-384 lub P521).

ECDH

  • Zalecana jest funkcja ECDH z >= 256-bitowymi kluczami

  • Wymiana kluczy oparta na ecDH powinna używać jednej z trzech krzywych zatwierdzonych przez NIST (P-256, P-384 lub P521).

Liczba całkowita Diffie-Hellman

  • Zalecana jest długość >klucza = 2048 bitów

  • Parametry grupy powinny być dobrze znaną grupą nazwaną (np. RFC 7919) lub wygenerowaną przez zaufaną firmę i uwierzytelnianą przed użyciem

Okresy istnienia kluczy

  • Wszystkie klucze asymetryczne powinny mieć maksymalny okres istnienia pięciu lat, zalecany okres istnienia jednego roku.

  • Wszystkie klucze symetryczne powinny mieć maksymalnie trzyletni okres istnienia; zalecany okres istnienia jednego roku.

  • 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 powinien być używany do tworzenia nowych danych (na przykład na potrzeby szyfrowania lub podpisywania), ale nadal może być 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

CAPI

Win32/64

.NET

Aplikacje Windows Store

Niezalecane

  • Niezabezpieczone funkcje związane z generowaniem liczb losowych obejmują rand,System.Random (.NET), GetTickCount i GetTickCount64

  • Nie zaleca się używania algorytmu generatora liczb losowych z podwójną krzywą wielokropkową ("DUAL_EC_DRBG").

Biblioteki kryptograficzne obsługiwane przez platformę systemu 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ę bibliotek kryptograficznych nieplatformowych do użycia. Ogólnie rzecz biorąc, biblioteki kryptograficzne platformy będą aktualizowane częściej, ponieważ są dostarczane jako część systemu operacyjnego, w przeciwieństwie do pakietu z aplikacją.

Wszelkie decyzje dotyczące użycia dotyczące platformy a kryptografii nieplatformowej powinny kierować się następującymi wymaganiami:

  1. Biblioteka powinna być bieżącą wersją bez znanych luk w zabezpieczeniach

  2. Najnowsze protokoły zabezpieczeń, algorytmy i długości kluczy powinny być obsługiwane

  3. (Opcjonalnie) Biblioteka powinna obsługiwać starsze protokoły zabezpieczeń/algorytmy tylko w celu zapewnienia zgodności z poprzednimi wersjami

Kod natywny

  • Crypto Primitives: Jeśli wersja jest dostępna w systemie Windows lub Windows Telefon, użyj CNG, jeśli to możliwe. W przeciwnym razie użyj interfejsu CryptoAPI (nazywanego również CAPI, który jest obsługiwany jako starszy składnik w systemie Windows z systemu Windows Vista).

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

    • Aby obsługiwać protokół TLS 1.2, należy skompilować aplikacje WinHTTPHttpSetOption

  • 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

Kluczowe funkcje wyprowadzania

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: zalecenie dotyczące wyprowadzania kluczy przy użyciu funkcji pseudorandom. W szczególności funkcja KDF w trybie licznika z HMAC jako funkcja pseudorandom

  • NIST SP 800-56A (poprawka 2): zalecenie dotyczące schematów ustanowienia kluczy w parach przy użyciu dyskretnej kryptografii logarytmicznej. W szczególności zalecana jest funkcja wyprowadzania klucza jednoetapowego w sekcji 5.8.1.

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 SSL, TLS lub DTLS powinny w pełni zweryfikować certyfikaty X.509 jednostek, z którymi się łączą. Obejmuje to weryfikację certyfikatów":

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

Klienci, którzy ufają certyfikatom z podpisem własnym (na przykład klient poczty łączący się z serwerem Exchange w domyślnej konfiguracji), mogą ignorować kontrole weryfikacji certyfikatu. Certyfikaty z podpisem własnym nie przekazują jednak z natury relacji zaufania, odwołania obsługi ani odnawiania klucza obsługi. Certyfikaty z podpisem własnym należy ufać tylko wtedy, gdy zostały uzyskane z innego zaufanego źródła (na przykład zaufanej jednostki, która dostarcza certyfikat w ramach transportu chronionego przez uwierzytelnienie i integralność).

Funkcje skrótu kryptograficznego

Produkty powinny używać rodziny algorytmów wyznaczania wartości skrótu SHA-2 (SHA256, SHA384 i SHA512). Nie zaleca się obcinania skrótów kryptograficznych na potrzeby zabezpieczeń do mniej niż 128 bitów.

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.

Użycie mac opartego na skrótach (HMAC) lub mac opartego 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).

Nie zaleca się obcięcia HMACs do mniej niż 128 bitów.

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 w przypadku naruszenia 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. Powinno to obejmować używany algorytm, rozmiary kluczy, wektory inicjowania i tryby wypełnienia.

  • Jeśli są dostępne, produkty powinny używać ustanowionych protokołów kryptograficznych udostępnianych przez platformę, a nie ich ponownego implementowania. Obejmuje to formaty podpisywania (np. użyj standardowego, istniejącego formatu).

  • Nie należy używać szyfrów strumienia symetrycznego, takich jak RC4. Zamiast szyfrów strumienia symetrycznego produkty powinny używać szyfru blokowego, w szczególności AES o długości klucza co najmniej 128 bitów.

  • Nie zgłaszaj niepowodzeń operacji kryptograficznych użytkownikom końcowym. W przypadku zwracania błędu do zdalnego wywołującego (np. 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 obejmują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 korzysta z kryptografii w sposób nowatorski lub nietypowy o 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 w środowiskach produkcyjnych. 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 umożliwia odwoływanie i aktualizacje w przypadku awarii zabezpieczeń.

Szyfrowanie poufnych danych przed magazynem

DPAPI/DPAPI-NG

W przypadku danych, które muszą być utrwalane w przypadku ponownych uruchomień systemu:

  • CryptProtectData

  • CryptUnprotectData

  • NCryptProtectSecret (Windows 8 CNG DPAPI)

W przypadku danych, które nie muszą być utrwalane podczas ponownego uruchamiania systemu:

  • CryptProtectMemory

  • CryptUnprotectMemory

W przypadku danych, które muszą być utrwalane i uzyskiwane przez wiele kont domen i komputerów:

SQL Server TDE

Aby chronić poufne dane, można użyć funkcji Transparent Data Encryption (TDE) programu SQL Server.

Należy użyć klucza szyfrowania bazy danych TDE (DEK), który spełnia wymagania dotyczące algorytmu kryptograficznego SDL i siły klucza. Obecnie zalecane są tylko AES_128, AES_192 i AES_256; TRIPLE_DES_3KEY nie jest zalecane.

Istnieją pewne ważne zagadnienia dotyczące używania funkcji TDE SQL, które należy wziąć pod uwagę:

Zarządzanie poświadczeniami

Użyj interfejsu API menedżera poświadczeń systemu Windows lub usługi Microsoft Azure KeyVault, aby chronić dane haseł i poświadczeń.

Aplikacje ze Sklepu Windows

Użyj klas w przestrzeniach nazw Windows.Security.Cryptography i Windows.Security.Cryptography.DataProtection , aby chronić wpisy tajne i poufne dane.

  • ProtectAsync

  • ProtectStreamAsync

  • UnprotectAsync

  • UnprotectStreamAsync

Użyj klas w przestrzeni nazw Windows.Security.Credentials , aby chronić dane haseł i poświadczeń.

.NET

W przypadku danych, które muszą być utrwalane w przypadku ponownych uruchomień systemu:

  • ProtectedData.Protect

  • ProtectedData.Unprotect

W przypadku danych, które nie muszą być utrwalane podczas ponownego uruchamiania systemu:

  • ProtectedMemory.Protect

  • ProtectedMemory.Unprotect

W przypadku plików konfiguracji użyj polecenia

Albo RSAProtectedConfigurationProvider lub DPAPIProtectedConfigurationProvider, aby chronić konfigurację, używając odpowiednio szyfrowania RSA lub DPAPI.

Element RSAProtectedConfigurationProvider może być używany na wielu maszynach w klastrze. Aby uzyskać więcej informacji, zobacz Szyfrowanie informacji o konfiguracji przy użyciu chronionej konfiguracji.