Używaj tylko zatwierdzonych szyfrów bloków symetrycznych i długości kluczy
Tytuł
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Produkty muszą używać tylko tych symetrycznych szyfrów blokowych i skojarzonych długości kluczy, które zostały jawnie zatwierdzone przez doradcę kryptograficznego w organizacji. Zatwierdzone algorytmy symetryczne w firmie Microsoft obejmują następujące szyfry blokowe:
W przypadku nowego kodu AES-128, AES-192 i AES-256 są dopuszczalne
W celu zapewnienia zgodności z poprzednimi wersjami istniejącego kodu dopuszczalne jest użycie trzech kluczy 3DES
W przypadku produktów korzystających z szyfrów bloków symetrycznych:
Usługa Advanced Encryption Standard (AES) jest wymagana dla nowego kodu
Trzyklucza funkcja Triple Data Encryption Standard (3DES) jest dozwolona 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, mogą być używane tylko do odszyfrowywania starych danych i muszą zostać zastąpione w przypadku szyfrowania
W przypadku algorytmów szyfrowania bloków symetrycznych wymagana jest minimalna długość klucza wynosząca 128 bitów. Jedynym zalecanym algorytmem szyfrowania bloku dla nowego kodu jest AES (AES-128, AES-192 i AES-256 są dopuszczalne)
3DES z trzema kluczami jest obecnie akceptowalne, jeśli jest już używane w istniejącym kodzie; zalecane jest przejście do usługi AES. DES, DESX, RC2 i Skipjack nie są już uważane za bezpieczne. Te algorytmy mogą 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
Należy pamiętać, że wszystkie symetryczne szyfry blokowe muszą być używane z zatwierdzonym trybem szyfrowania, który wymaga użycia odpowiedniego wektora inicjalizacji (IV). Odpowiedni IV jest zazwyczaj liczbą losową i nigdy nie jest wartością stałą
Użycie starszych lub w inny sposób niezatwierdzonych algorytmów kryptograficznych i mniejszych długości kluczy do odczytywania istniejących danych (w przeciwieństwie do zapisywania nowych danych) może być dozwolone po przeglądzie organizacji Crypto Board. Należy jednak zgłosić wyjątek w odniesieniu do tego wymagania. Ponadto w przypadku wdrożeń w przedsiębiorstwie produkty powinny uwzględniać ostrzeżenia administratorów, gdy słabe kryptograficzne są używane do odczytywania danych. Takie ostrzeżenia powinny być objaśniające i umożliwiające podejmowanie działań. W niektórych przypadkach może być konieczne, aby zasady grupy kontrolować użycie słabej kryptografii
Dozwolone algorytmy platformy .NET na potrzeby zarządzanej elastyczności kryptograficznej (w kolejności preferencji)
AesCng (zgodne ze standardem FIPS)
AuthenticatedAesCng (zgodne ze standardem FIPS)
AESCryptoServiceProvider (zgodne ze standardem FIPS)
AESManaged (niezgodne ze standardem FIPS)
Należy pamiętać, że żaden z tych algorytmów nie można określić za pomocą SymmetricAlgorithm.Create metod lub CryptoConfig.CreateFromName bez wprowadzania zmian w pliku machine.config. Należy również pamiętać, że usługa AES w wersjach platformy .NET wcześniejszej niż .NET 3.5 ma nazwę RijndaelManagedi AesCng jest >dostępna za pośrednictwem platformy CodePlex i AuthenticatedAesCng wymaga CNG w bazowym systemie operacyjnym
Używanie zatwierdzonych trybów szyfrowania blokowego i wektorów inicjowania dla szyfrów symetrycznych
Tytuł
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Wszystkie symetryczne szyfry blokowe muszą być używane z zatwierdzonym trybem szyfrowania symetrycznego. Jedynymi zatwierdzonymi trybami są CBC i CTS. W szczególności należy unikać trybu działania elektronicznej książki kodowej (EBC); korzystanie z EBC wymaga przeglądu Zarządu Kryptograficznego organizacji. Wszystkie zastosowania OFB, CFB, CTR, CCM i GCM lub dowolnego innego trybu szyfrowania muszą być przeglądane przez organizację Crypto Board. Ponowne użycie tego samego wektora inicjowania (IV) z szyframi blokowymi w trybach "szyfrowania przesyłania strumieniowego", takich jak CTR, może spowodować ujawnienie zaszyfrowanych danych. Wszystkie szyfry bloków symetrycznych muszą być również używane z odpowiednim wektorem inicjowania (IV). Odpowiedni iv to kryptograficznie silna, losowa liczba i nigdy nie stała wartość.
Używanie zatwierdzonych algorytmów asymetrycznych, długości kluczy i uzupełniania
Tytuł
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Stosowanie zakazanych algorytmów kryptograficznych powoduje znaczne zagrożenie dla bezpieczeństwa produktów i należy go unikać. Produkty muszą używać tylko tych algorytmów kryptograficznych i skojarzonych długości kluczy oraz uzupełniania, które zostały jawnie zatwierdzone przez organizację Crypto Board.
RSA — może być używany do szyfrowania, wymiany kluczy i podpisu. Szyfrowanie RSA musi używać tylko trybów uzupełniania OAEP lub RSA-KEM. Istniejący kod może używać trybu uzupełniania PKCS #1 w wersji 1.5 tylko w celu zapewnienia zgodności. Używanie dopełnienia o wartości null jest jawnie zakazane. Klucze >= 2048 bity są wymagane dla nowego kodu. Istniejący kod może obsługiwać klucze < 2048 bitów tylko w celu zapewnienia zgodności z poprzednimi wersjami po przejrzeniu przez organizację Crypto Board. Klucze < 1024 bity mogą być używane tylko do odszyfrowywania/weryfikowania starych danych i należy je zastąpić, jeśli są używane do operacji szyfrowania lub podpisywania
ECDSA — może być używany tylko do podpisu. Usługa ECDSA z kluczami >=256-bitowymi jest wymagana dla nowego kodu. Podpisy oparte na ECDSA muszą używać jednej z trzech zatwierdzonych krzywych NIST (P-256, P-384 lub P521). Krzywe, które zostały dokładnie przeanalizowane, mogą być używane dopiero po przeglądzie z organizacją Crypto Board.
ECDH — może być używany tylko do wymiany kluczy. Funkcja ECDH z kluczami >=256-bitowymi jest wymagana dla nowego kodu. Wymiana kluczy oparta na ECDH musi używać jednej z trzech zatwierdzonych krzywych NIST (P-256, P-384 lub P521). Krzywe, które zostały dokładnie przeanalizowane, mogą być używane dopiero po przeglądzie z organizacją Crypto Board.
DSA — może być akceptowalna po przejrzeniu i zatwierdzeniu przez organizację Crypto Board. Skontaktuj się z doradcą ds. zabezpieczeń, aby zaplanować przegląd rady kryptograficznej w organizacji. Jeśli użycie dsa jest zatwierdzone, należy pamiętać, że należy zabronić używania kluczy mniejszych niż 2048 bitów długości. CNG obsługuje 2048-bitowe i większe długości kluczy od Windows 8.
Diffie-Hellman — może być używany tylko do zarządzania kluczami sesji. Długość >klucza = 2048 bitów jest wymagana dla nowego kodu. Istniejący kod może obsługiwać długości kluczy 2048 bitów < tylko w celu zapewnienia zgodności z poprzednimi wersjami po przejrzeniu przez organizację Crypto Board. Nie można używać kluczy < 1024 bitów.
Produkty muszą używać zatwierdzonych generatorów liczb losowych. Funkcje pseudorandom, takie jak funkcja środowiska uruchomieniowego języka C, .NET Framework klasy System.Random lub funkcje systemowe, takie jak GetTickCount, muszą więc nigdy nie być używane w takim kodzie. Stosowanie algorytmu generatora liczb losowych podwójnej eliptycznej krzywej (DUAL_EC_DRBG) jest zabronione
CNG- BCryptGenRandom (użycie flagi BCRYPT_USE_SYSTEM_PREFERRED_RNG zalecane, chyba że obiekt wywołujący może działać w dowolnym środowisku IRQL większym niż 0 [czyli PASSIVE_LEVEL])
Aplikacje ze Sklepu Windows — Windows.Security.Cryptography.CryptographicBuffer.GenerateRandom lub . GenerateRandomNumber
Apple OS X (10.7+)/iOS(2.0+)- int SecRandomCopyBytes (SecRandomRef random, size_t count, uint8_t *bajty )
Apple OS X (<10.7) — użyj /dev/random, aby pobrać losowe liczby
Java(w tym kod Java systemu Google Android)- klasa java.security.SecureRandom. Należy pamiętać, że w przypadku systemu Android 4.3 (Jelly Bean) deweloperzy muszą postępować zgodnie z zalecanym obejściem systemu Android i zaktualizować swoje aplikacje, aby jawnie zainicjować żądanie PRNG z entropii z poziomu /dev/urandom lub /dev/random
Nie używaj szyfrów strumienia symetrycznego
Tytuł
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Szyfry strumienia symetrycznego, takie jak RC4, nie mogą być używane. 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.
Produkty muszą używać tylko zatwierdzonych algorytmów uwierzytelniania komunikatów (MAC) lub opartych na skrótach algorytmów uwierzytelniania komunikatów (HMAC).
Kod uwierzytelniania wiadomości (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 komputera MAC opartego na skrótach (HMAC) lub mac opartego na szyfrach blokowych jest dozwolone, o ile wszystkie podstawowe algorytmy szyfrowania skrótu lub symetrycznego są również zatwierdzone do użycia; Obecnie obejmuje to funkcje HMAC-SHA2 (HMAC-SHA256, HMAC-SHA384 i HMAC-SHA512) oraz karty MACs oparte na szyfrach CMAC/OMAC1 i OMAC2 (są one oparte na protokole AES).
Użycie algorytmu HMAC-SHA1 może być dozwolone w celu zachowania zgodności platformy, ale będzie konieczne zgłoszenie wyjątku do tej procedury i poddanie się przeglądowi kryptograficznemu w organizacji. Obcięcie kontrolerów HMACs do mniej niż 128 bitów nie jest dozwolone. Użycie metod klienta do wyznaczania wartości skrótu klucza i danych nie jest zatwierdzane i musi przejść przegląd rady kryptograficznej organizacji przed użyciem.
Używanie tylko zatwierdzonych funkcji skrótu kryptograficznego
Tytuł
Szczegóły
Składnik
Aplikacja internetowa
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Produkty muszą używać rodziny algorytmów wyznaczania wartości skrótu SHA-2 (SHA256, SHA384 i SHA512). Jeśli potrzebny jest krótszy skrót, taki jak 128-bitowa długość danych wyjściowych, aby dopasować strukturę danych zaprojektowaną z krótszym skrótem MD5, zespoły produktów mogą obcinać jeden z skrótów SHA2 (zazwyczaj SHA256). Należy pamiętać, że SHA384 jest obciętą wersją SHA512. Obcięcie skrótów kryptograficznych na potrzeby zabezpieczeń do mniej niż 128 bitów nie jest dozwolone. Nowy kod nie może używać algorytmów wyznaczania wartości skrótu MD2, MD4, MD5, SHA-0, SHA-1 lub RIPEMD. Kolizje skrótów są możliwe do obliczenia dla tych algorytmów, co skutecznie je przerywa.
Dozwolone algorytmy skrótu platformy .NET dla zarządzanej elastyczności kryptograficznej (w kolejności preferencji):
SHA512Cng (zgodne ze standardem FIPS)
SHA384Cng (zgodne ze standardem FIPS)
SHA256Cng (zgodne ze standardem FIPS)
SHA512Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA512 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName)
SHA384Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA384 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName)
SHA256Managed (niezgodne ze standardem FIPS) (użyj algorytmu SHA256 jako nazwy algorytmu w wywołaniach metody HashAlgorithm.Create lub CryptoConfig.CreateFromName)
SHA512CryptoServiceProvider (zgodne ze standardem FIPS)
SHA256CryptoServiceProvider (zgodne ze standardem FIPS)
SHA384CryptoServiceProvider (zgodne ze standardem FIPS)
Używanie algorytmów silnego szyfrowania do szyfrowania danych w bazie danych
Algorytmy szyfrowania definiują przekształcenia danych, których nie można łatwo odwrócić przez nieautoryzowanych użytkowników. SQL Server umożliwia administratorom i deweloperom wybór spośród kilku algorytmów, w tym DES, Triple DES, TRIPLE_DES_3KEY, RC2, RC4, 128-bitowych WERSJI RC4, DESX, 128-bitowej AES, 192-bitowej AES i 256-bitowej AES
Pakiety usług SSIS powinny być szyfrowane i podpisane cyfrowo
Źródłem pakietu jest jednostka lub organizacja, która utworzyła pakiet. Uruchomienie pakietu z nieznanego lub niezaufanego źródła może być ryzykowne. Aby zapobiec nieautoryzowanemu manipulowaniu pakietami usług SSIS, należy używać podpisów cyfrowych. Ponadto, aby zapewnić poufność pakietów podczas przechowywania/przesyłania, pakiety usług SSIS muszą być szyfrowane
Dodawanie podpisu cyfrowego do zabezpieczanych krytycznych baz danych
W przypadkach, gdy należy zweryfikować integralność zabezpieczanej krytycznej bazy danych, należy użyć podpisów cyfrowych. Zabezpieczane bazy danych, takie jak procedura składowana, funkcja, zestaw lub wyzwalacz, mogą być podpisane cyfrowo. Poniżej przedstawiono przykład, kiedy może to być przydatne: załóżmy, że niezależny dostawca oprogramowania udzielił pomocy technicznej dla oprogramowania dostarczonego do jednego z ich klientów. Przed zapewnieniem pomocy technicznej niezależnego dostawcy oprogramowania chcą mieć pewność, że baza danych zabezpieczana w oprogramowaniu nie została naruszona przez pomyłkę lub przez złośliwą próbę. Jeśli zabezpieczany jest podpisany cyfrowo, niezależnego dostawcy oprogramowania mogą zweryfikować jego podpis cyfrowy i zweryfikować jego integralność.
Ochrona kluczy szyfrowania za pomocą programu SQL Server EKM
SQL Server rozszerzone zarządzanie kluczami umożliwia przechowywanie kluczy szyfrowania, które chronią pliki bazy danych w urządzeniu poza urządzeniem, takim jak karta inteligentna, urządzenie USB lub moduł EKM/HSM. Umożliwia to również ochronę danych przed administratorami bazy danych (z wyjątkiem członków grupy sysadmin). Dane mogą być szyfrowane przy użyciu kluczy szyfrowania, do których tylko użytkownik bazy danych ma dostęp do zewnętrznego modułu EKM/HSM.
Użyj funkcji AlwaysEncrypted, jeśli klucze szyfrowania nie powinny być ujawniane aparatowi bazy danych
Always Encrypted to funkcja przeznaczona do ochrony poufnych danych, takich jak numery kart kredytowych lub numery identyfikacyjne krajowe/regionalne (np. numery ubezpieczenia społecznego USA), przechowywane w bazie danych Azure SQL lub SQL Server bazach danych. Always Encrypted umożliwia klientom szyfrowanie poufnych danych w aplikacjach klienckich i nigdy nie ujawnia kluczy szyfrowania aparatowi bazy danych (SQL Database lub SQL Server). W związku z tym Always Encrypted zapewnia separację między tymi, którzy są właścicielami danych (i mogą je wyświetlać) oraz tymi, którzy zarządzają danymi (ale nie powinni mieć dostępu)
Bezpieczne przechowywanie kluczy kryptograficznych na urządzeniu IoT
Tytuł
Szczegóły
Składnik
Urządzenie IoT
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
System operacyjny urządzenia — Windows IoT Core, łączność urządzeń — zestawy SDK urządzeń usługi Azure IoT
Klucze prywatne symetryczne lub certyfikatu bezpiecznie w magazynie chronionym sprzętem, takich jak moduł TPM lub mikroukłady karty inteligentnej. Windows 10 IoT Core obsługuje użytkownika modułu TPM i istnieje kilka zgodnych modułów TPM, których można użyć: Dyskretny moduł TPM (dTPM). Zaleca się używanie oprogramowania układowego lub dyskretnego modułu TPM. Programowy moduł TPM powinien być używany tylko do celów programistycznych i testowych. Po udostępnieniu modułu TPM i aprowizacji kluczy kod, który generuje token, powinien zostać zapisany bez twardego kodowania poufnych informacji.
Przykład
TpmDevice myDevice = new TpmDevice(0);
// Use logical device 0 on the TPM
string hubUri = myDevice.GetHostName();
string deviceId = myDevice.GetDeviceId();
string sasToken = myDevice.GetSASToken();
var deviceClient = DeviceClient.Create( hubUri, AuthenticationMethodFactory. CreateAuthenticationWithToken(deviceId, sasToken), TransportType.Amqp);
Jak widać, klucz podstawowy urządzenia nie jest obecny w kodzie. Zamiast tego jest on przechowywany w module TPM w miejscu 0. Urządzenie TPM generuje krótkotrwały token SAS, który jest następnie używany do nawiązywania połączenia z IoT Hub.
Generowanie losowego klucza symetrycznego wystarczającej długości uwierzytelniania do IoT Hub
Tytuł
Szczegóły
Składnik
Brama chmury IoT
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Wybór bramy — Azure IoT Hub
Odwołania
Nie dotyczy
Kroki
IoT Hub zawiera rejestr tożsamości urządzenia i podczas aprowizowania urządzenia, automatycznie generuje losowy klucz symetryczny. Zaleca się użycie tej funkcji rejestru tożsamości Azure IoT Hub w celu wygenerowania klucza używanego do uwierzytelniania. IoT Hub umożliwia również określenie klucza podczas tworzenia urządzenia. Jeśli klucz jest generowany poza IoT Hub podczas aprowizacji urządzenia, zaleca się utworzenie losowego klucza symetrycznego lub co najmniej 256 bitów.
Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają użycia numeru PIN i umożliwiają zdalne wyczyszczenie
Tytuł
Szczegóły
Składnik
Dynamics CRM Mobile Client
Faza SDL
Wdrożenie
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają użycia numeru PIN i umożliwiają zdalne wyczyszczenie
Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają numeru PIN/hasła/automatycznego blokowania i szyfrują wszystkie dane (np. funkcję BitLocker)
Tytuł
Szczegóły
Składnik
Dynamics CRM Outlook Client
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Upewnij się, że obowiązują zasady zarządzania urządzeniami, które wymagają numeru PIN/hasła/automatycznego blokowania i szyfrują wszystkie dane (np. funkcję BitLocker)
Upewnij się, że klucze podpisywania są przerzucane podczas korzystania z programu Identity Server
Upewnij się, że klucze podpisywania są przerzucane podczas korzystania z programu Identity Server. Link w sekcji odwołania wyjaśnia, jak powinno to być planowane bez powodowania awarii aplikacji korzystających z serwera tożsamości.
Upewnij się, że kryptograficznie silny identyfikator klienta, klucz tajny klienta jest używany na serwerze tożsamości
Tytuł
Szczegóły
Składnik
Serwer tożsamości
Faza SDL
Kompilacja
Odpowiednie technologie
Ogólny
Atrybuty
Nie dotyczy
Odwołania
Nie dotyczy
Kroki
Upewnij się, że kryptograficznie silny identyfikator klienta, klucz tajny klienta jest używany na serwerze tożsamości. Podczas generowania identyfikatora klienta i wpisu tajnego należy użyć następujących wytycznych:
Generowanie losowego identyfikatora GUID jako identyfikatora klienta
Generowanie kryptograficznie losowego klucza 256-bitowego jako wpisu tajnego