Wydanie biblioteki kryptograficznej OpenSSL 3.0.0

Po trzech latach prac i 19 wersjach testowych, wydano bibliotekę OpenSSL 3.0.0 z implementacją protokołów SSL/TLS i różnych algorytmów szyfrowania. Nowa gałąź wprowadza zmiany, które naruszają wsteczną kompatybilność na poziomie API i ABI, ale zmiany te nie wpłyną na działanie większości aplikacji, których portowanie z OpenSSL 1.1.1 wymaga jedynie ponownego skompilowania. Wsparcie dla poprzedniej wersji OpenSSL 1.1.1 będzie prowadzone do września 2023 roku.

Znacząca zmiana numeracji wersji jest związana z przejściem na tradycyjną numerację „Major.Minor.Patch”. Pierwsza cyfra (Major) w numerze wersji zmienia się teraz tylko w przypadku naruszenia kompatybilności na poziomie API/ABI, a druga (Minor) przy wprowadzaniu nowych funkcji bez zmiany API/ABI. Aktualizacje korygujące będą wydawane ze zmianą trzeciej cyfry (Patch). Numer 3.0.0 od razu po 1.1.1 został wybrany, aby uniknąć nakładania się z opracowywanym modułem FIPS do OpenSSL, dla którego stosowano numerację 2.x.

Drugą ważną zmianą dla projektu było przejście z podwójnej licencji (OpenSSL i SSLeay) na licencję Apache 2.0. Poprzednio stosowana licencja OpenSSL była oparta na tekście przestarzałej licencji Apache 1.0 i wymagała wyraźnego wspominania o OpenSSL w materiałach reklamowych przy korzystaniu z bibliotek OpenSSL, a także dodania specjalnej notatki w przypadku dostarczania OpenSSL w składzie produktu. Takie wymagania sprawiały, że stara licencja była niekompatybilna z GPL, co stwarzało trudności przy korzystaniu z OpenSSL w projektach licencjonowanych na warunkach GPL. Aby obejść tę niekompatybilność, projekty GPL zmuszone były stosować specyficzne umowy licencyjne, w których główny tekst GPL uzupełniano punktem zezwalającym na związanie aplikacji z biblioteką OpenSSL i zaznaczającym, że wymagania GPL nie odnoszą się do związania z OpenSSL.

W porównaniu z gałęzią OpenSSL 1.1.1, w OpenSSL 3.0.0 wprowadzono ponad 7500 zmian, które przygotowało 350 programistów. Najważniejsze nowości w OpenSSL 3.0.0:

• Zaproponowano nowy moduł FIPS, który obejmuje wdrożenie algorytmów kryptograficznych zgodnych z normą bezpieczeństwa FIPS 140-2 (w tym miesiącu planowane jest rozpoczęcie procesu certyfikacji modułu, a uzyskanie certyfikatu FIPS 140-2 oczekiwane jest w przyszłym roku). Nowy moduł jest znacznie prostszy w użyciu i jego integracja z wieloma aplikacjami nie będzie trudniejsza niż zmiana pliku konfiguracyjnego. Domyślnie moduł FIPS jest wyłączony i wymaga podania opcji enable-fips w celu aktywacji.
• W libcrypto wprowadzono koncepcję dostawców plug-in, które zastąpiły koncepcję silników (API ENGINE uznano za przestarzałe). Dzięki dostawcom można dodawać własne implementacje algorytmów do takich operacji jak szyfrowanie, deszyfrowanie, generowanie kluczy, obliczanie MAC, tworzenie i weryfikacja podpisów cyfrowych. Możliwe jest zarówno podłączenie nowych, jak i tworzenie alternatywnych implementacji już obsługiwanych algorytmów (domyślnie dla każdego algorytmu teraz używany jest zintegrowany w OpenSSL dostawca).
• Dodano wsparcie dla protokołu zarządzania certyfikatami CMP (Certificate Management Protocol, RFC 4210), który można wykorzystać do żądania certyfikatów od serwera centrum certyfikacji, aktualizacji certyfikatów i ich unieważniania. Praca z CMP odbywa się za pomocą nowego narzędzia openssl-cmp, w którym również zaimplementowano wsparcie dla formatu CRMF (RFC 4211) oraz przesyłania zapytań przez HTTP/HTTPS (RFC 6712).
• Zrealizowano pełnoprawnego klienta dla protokołów HTTP i HTTPS, wspierającego metody GET i POST, przekierowywanie zapytań, pracę przez proxy, kodowanie ASN.1 oraz obsługę timeoutów.
• Dodano nowe API EVP_MAC (Message Authentication Code API), które upraszcza dodawanie nowych implementacji MAC.
• Zaproponowano nowy interfejs programistyczny do generowania kluczy — EVP_KDF (Key Derivation Function API), który ułatwia dodawanie nowych implementacji KDF i PRF. Stare API EVP_PKEY, przez które udostępniano algorytmy scrypt, TLS1 PRF i HKDF, zostało przekształcone w postaci warstwy, zrealizowanej na bazie API EVP_KDF i EVP_MAC.
• W implementacji protokołu TLS udostępniono możliwość korzystania z wbudowanych w jądro Linux klienta i serwera TLS w celu przyspieszenia operacji. Aby wykorzystać udostępnioną przez jądro Linux implementację TLS, należy włączyć opcję „SSL_OP_ENABLE_KTLS” lub ustawienie „enable-ktls”.
• Dodano wsparcie dla nowych algorytmów:
  • Algorytmy tworzenia kluczy (KDF) — „SINGLE STEP” i „SSH”.
  • Algorytmy kodowania wiadomości (MAC) — „GMAC” i „KMAC”.
  • Algorytm inkapsulacji kluczy RSA (KEM) „RSASVE”.
  • Algorytm szyfrowania „AES-SIV” (RFC-8452).
  • W API EVP dodano wywołania z obsługą inwersyjnych szyfrów, wykorzystujących algorytm AES do szyfrowania kluczy (Key Wrap): „AES-128-WRAP-INV”, „AES-192-WRAP-INV”, „AES-256-WRAP-INV”, „AES-128-WRAP-PAD-INV”, „AES-192-WRAP-PAD-INV” i „AES-256-WRAP-PAD-INV”.
  • W API EVP dodano obsługę algorytmów wypożyczania szyfrogramu (CTS): „AES-128-CBC-CTS”, „AES-192-CBC-CTS”, „AES-256-CBC-CTS”, „CAMELLIA-128-CBC-CTS”, „CAMELLIA-192-CBC-CTS” i „CAMELLIA-256-CBC-CTS”.
  • Dodano obsługę podpisów elektronicznych CAdES-BES (RFC 5126).
  • W AES_GCM wdrożono parametr AuthEnvelopedData (RFC 5083), umożliwiający szyfrowanie i deszyfrowanie wiadomości, które są uwierzytelnione i szyfrowane przy użyciu trybu AES GCM.
• Do publicznego API przeniesiono funkcje PKCS7_get_octet_string oraz PKCS7_type_is_other.
• W API PKCS#12 algorytmy, które są domyślnie stosowane w funkcji PKCS12_create(), zostały zastąpione przez PBKDF2 i AES, a do obliczania MAC zastosowano algorytm SHA-256. Aby przywrócić wcześniejsze zachowanie, wprowadzono opcję „-legacy”. Dodano wiele nowych rozszerzonych wywołań PKCS12_*_ex, PKCS5_*_ex oraz PKCS8_*_ex, jak PKCS12_add_key_ex(), PKCS12_create_ex() i PKCS12_decrypt_skey_ex().
• Dla platformy Windows dodano wsparcie dla synchronizacji wątków przy użyciu mechanizmu SRWLock.
• Dodano nowe API do śledzenia, włączane przez parametr enable-trace.
• Rozszerzono zakres kluczy obsługiwanych w funkcjach EVP_PKEY_public_check() oraz EVP_PKEY_param_check(): RSA, DSA, ED25519, X25519, ED448 i X448.
• Usunięto podsystem RAND_DRBG, zamiast tego wprowadzono API EVP_RAND. Usunięto funkcje FIPS_mode() i FIPS_mode_set().
• Znacząca część API została uznana za przestarzałą — używanie przestarzałych wywołań w kodzie projektów będzie skutkować wyświetlaniem ostrzeżeń podczas kompilacji. W tym przypadku oficjalnie uznano za przestarzałe niskopoziomowe API związane z określonymi implementacjami algorytmów (np. AES_set_encrypt_key i AES_encrypt). Oficjalne wsparcie w OpenSSL 3.0.0 jest teraz dostępne tylko dla wysokopoziomowych API EVP, które są abstrahowane od konkretnych typów algorytmów (do tego API należą na przykład funkcje EVP_EncryptInit_ex, EVP_EncryptUpdate i EVP_EncryptFinal). W jednej z następnych istotnych wersji przestarzałe API zostaną usunięte. Implementacje przestarzałych algorytmów, takich jak MD2 i DES, dostępne przez API EVP, zostały przeniesione do osobnego modułu 'legacy', który jest domyślnie wyłączony.
• Dokumentacja i zestaw testów zostały znacznie rozszerzone. W porównaniu z gałęzią 1.1.1 objętość dokumentacji wzrosła o 94%, a rozmiar kodu zestawu testowego o 54%.

Źródło: opennet.ru