Veröffentlichung der Kryptobibliothek OpenSSL 3.0.0

Nach drei Jahren Entwicklung und 19 Testveröffentlichungen fand die Veröffentlichung der Bibliothek OpenSSL 3.0.0 statt, die die Protokolle SSL/TLS und verschiedene Verschlüsselungsalgorithmen implementiert. Der neue Branch umfasst Änderungen, die die Rückwärtskompatibilität auf API- und ABI-Ebene verletzen, aber die Änderungen werden die Funktionsweise der meisten Anwendungen nicht beeinträchtigen, für deren Migration von OpenSSL 1.1.1 eine Neubau genügen wird. Die Unterstützung des alten Branches OpenSSL 1.1.1 wird bis September 2023 fortgesetzt.

Die erhebliche Änderung der Versionsnummer steht im Zusammenhang mit der Umstellung auf die traditionelle Nummerierung "Major.Minor.Patch". Die erste Zahl (Major) in der Versionsnummer wird ab sofort nur bei einer Verletzung der Kompatibilität auf API-/ABI-Ebene geändert, während die zweite Zahl (Minor) bei der Funktionserweiterung ohne Änderung von API/ABI geändert wird. Korrekturupdates werden mit einer Änderung der dritten Zahl (Patch) bereitgestellt. Die Nummer 3.0.0 wurde unmittelbar nach 1.1.1 gewählt, um Überschneidungen mit dem in Entwicklung befindlichen FIPS-Modul für OpenSSL zu vermeiden, für das die Nummerierung 2.x verwendet wurde.

Eine weitere wichtige Änderung für das Projekt war der Übergang von der doppelten Lizenz (OpenSSL und SSLeay) zur Apache 2.0 Lizenz. Die zuvor verwendete eigene OpenSSL-Lizenz basierte auf dem Text der veralteten Apache 1.0 Lizenz und verlangte eine ausdrückliche Nennung von OpenSSL in Werbematerialien bei Verwendung der OpenSSL-Bibliotheken sowie die Hinzufügung eines speziellen Hinweises im Falle der Lieferung von OpenSSL als Teil eines Produkts. Solche Anforderungen machten die alte Lizenz mit der GPL inkompatibel, was bei der Verwendung von OpenSSL in GPL-lizenzierten Projekten Schwierigkeiten verursachte. Um diese Inkompatibilität zu umgehen, sahen sich GPL-Projekte gezwungen, spezifische Lizenzvereinbarungen zu verwenden, in denen der Haupttext der GPL um einen Absatz ergänzt wurde, der ausdrücklich die Bindung der Anwendung an die OpenSSL-Bibliothek erlaubte und erwähnte, dass die Anforderungen der GPL nicht auf die Bindung an OpenSSL angewendet werden.

Im Vergleich zum Branch OpenSSL 1.1.1 wurden in OpenSSL 3.0.0 über 7500 Änderungen von 350 Entwicklern vorgenommen. Zu den wichtigsten Neuerungen in OpenSSL 3.0.0 gehören:

• Ein neues FIPS-Modul wurde vorgeschlagen, das die Implementierung kryptografischer Algorithmen beinhaltet, die dem Sicherheitsstandard FIPS 140-2 entsprechen (im Laufe dieses Monats wird der Zertifizierungsprozess für das Modul gestartet, und die FIPS 140-2-Zertifizierung wird im nächsten Jahr erwartet). Das neue Modul ist deutlich benutzerfreundlicher und die Integration in viele Anwendungen erfordert nicht mehr als eine Änderung der Konfigurationsdatei. Standardmäßig ist das FIPS-Modul deaktiviert und erfordert die Angabe der Option enable-fips zur Aktivierung.
• In libcrypto wurde das Konzept der Plug-in-Anbieter umgesetzt, das das veraltete Konzept der Engines (ENGINE API) ersetzt hat. Mit Hilfe von Anbietern können eigene Implementierungen von Algorithmen für Operationen wie Verschlüsselung, Entschlüsselung, Schlüsselerzeugung, MAC-Berechnung sowie für die Erstellung und Überprüfung digitaler Signaturen hinzugefügt werden. Sowohl neue Anbieter als auch alternative Implementierungen bereits unterstützter Algorithmen können erstellt werden (standardmäßig wird für jeden Algorithmus jetzt der in OpenSSL integrierte Anbieter verwendet).
• Die Unterstützung für das Zertifikatsmanagementprotokoll CMP (Certificate Management Protocol, RFC 4210) wurde hinzugefügt, das verwendet werden kann, um Zertifikate anzufordern von Server der Zertifizierungsstelle, Zertifikate zu aktualisieren und Zertifikate zurückzurufen. die Arbeit mit CMP erfolgt über das neue Dienstprogramm openssl-cmp, welches auch Unterstützung für das CRMF-Format (RFC 4211) und für das Senden von Anfragen über HTTP/HTTPS (RFC 6712) bietet.
• Ein vollwertiger Client für die Protokolle HTTP und HTTPS wurde implementiert, der die Methoden GET und POST, die Umleitung von Anfragen, die Arbeit über Proxy, die ASN.1-Codierung und das Timeout-Management unterstützt.
• Eine neue API EVP_MAC (Message Authentication Code API) wurde hinzugefügt, die das Hinzufügen neuer Implementierungen von MACs erleichtert.
• Eine neue API zur Schlüsselerzeugung – EVP_KDF (Key Derivation Function API) – wurde vorgeschlagen, die das Hinzufügen neuer Implementierungen von KDF und PRF erleichtert. Die alte API EVP_PKEY, über die die Algorithmen scrypt, TLS1 PRF und HKDF verfügbar waren, wurde in Form einer Schicht über den APIs EVP_KDF und EVP_MAC überarbeitet.
• In der Implementierung des TLS-Protokolls wurde die Möglichkeit geschaffen, die im Linux-Kernel eingebauten TLS-Clients und -Server zur Beschleunigung von Vorgängen zu nutzen. Um die vom Linux-Kernel bereitgestellte TLS-Implementierung zu aktivieren, ist die Aktivierung der Option „SSL_OP_ENABLE_KTLS“ oder die Einstellung „enable-ktls“ erforderlich.
• Die Unterstützung für neue Algorithmen wurde hinzugefügt:
  • Schlüsselableitungsalgorithmen (KDF) – „SINGLE STEP“ und „SSH“.
  • Nachrichtenauthentifizierungscode-Algorithmen (MAC) – „GMAC“ und „KMAC“.
  • RSA-Schlüsselinjektionsalgorithmus (KEM) „RSASVE“.
  • Verschlüsselungsalgorithmus „AES-SIV“ (RFC-8452).
  • In die EVP-API wurden Aufrufe mit Unterstützung für inversive Verschlüsselungsalgorithmen hinzugefügt, die den AES-Algorithmus zur Verschlüsselung von Schlüsseln verwenden (Key Wrap): „AES-128-WRAP-INV“, „AES-192-WRAP-INV“, „AES-256-WRAP-INV“, „AES-128-WRAP-PAD-INV“, „AES-192-WRAP-PAD-INV“ und „AES-256-WRAP-PAD-INV“.
  • In die EVP-API wurde die Unterstützung für die Algorithmusfamilie zur Entschlüsselung von Chiffretexten (CTS) hinzugefügt: „AES-128-CBC-CTS“, „AES-192-CBC-CTS“, „AES-256-CBC-CTS“, „CAMELLIA-128-CBC-CTS“, „CAMELLIA-192-CBC-CTS“ und „CAMELLIA-256-CBC-CTS“.
  • Unterstützung für digitale Signaturen mit CAdES-BES (RFC 5126) hinzugefügt.
  • In AES_GCM wurde der Parameter AuthEnvelopedData (RFC 5083) implementiert, der es ermöglicht, Nachrichten, die authentifiziert und mit dem AES GCM-Modus verschlüsselt wurden, zu verschlüsseln und zu entschlüsseln.
• Im öffentlichen API wurden die Funktionen PKCS7_get_octet_string und PKCS7_type_is_other bereitgestellt.
• In der API PKCS#12 wurden die algorithmischen Standards, die standardmäßig in der Funktion PKCS12_create() verwendet werden, durch PBKDF2 und AES ersetzt, und für die Berechnung von MAC wurde der Algorithmus SHA-256 verwendet. Eine Option „-legacy“ wurde hinzugefügt, um das frühere Verhalten wiederherzustellen. Eine große Anzahl neuer erweiterter Aufrufe PKCS12_*_ex, PKCS5_*_ex und PKCS8_*_ex, wie PKCS12_add_key_ex(), PKCS12_create_ex() und PKCS12_decrypt_skey_ex(), wurde hinzugefügt.
• Für die Windows-Plattform wurde die Unterstützung für die Synchronisation von Threads mithilfe des SRWLock-Mechanismus hinzugefügt.
• Eine neue API für das Tracing wurde hinzugefügt, die über den Parameter enable-trace aktiviert wird.
• Das Spektrum der unterstützten Schlüssel in den Funktionen EVP_PKEY_public_check() und EVP_PKEY_param_check() wurde erweitert: RSA, DSA, ED25519, X25519, ED448 und X448.
• Die RAND_DRBG-Subsysteme wurden entfernt, stattdessen wurde die API EVP_RAND vorgeschlagen. Die Funktionen FIPS_mode() und FIPS_mode_set() wurden entfernt.
• Ein wesentlicher Teil der API wurde als veraltet eingestuft — die Verwendung veralteter Aufrufe im Code von Projekten führt zu Warnungen bei der Kompilierung. Unter den veralteten Funktionen sind auch die niedrigstufigen APIs, die an bestimmte Implementierungen von Algorithmen gebunden sind (zum Beispiel AES_set_encrypt_key und AES_encrypt). Die offizielle Unterstützung in OpenSSL 3.0.0 erfolgt jetzt nur noch für hochrangige APIs EVP, die von einzelnen Algorithmustypen abstrahiert sind (zu diesen APIs gehören zum Beispiel die Funktionen EVP_EncryptInit_ex, EVP_EncryptUpdate und EVP_EncryptFinal). In einer der nächsten bedeutenden Versionen werden die veralteten APIs entfernt. Implementierungen von veralteten Algorithmen wie MD2 und DES, die über die API EVP zugänglich sind, wurden in ein separates „legacy“-Modul verschoben, das standardmäßig deaktiviert ist.
• Die Dokumentation und der Testumfang wurden erheblich erweitert. Im Vergleich zum Branchenschnitt 1.1.1 hat sich der Umfang der Dokumentation um 94 % erhöht, und die Größe des Testcodes um 54 %.

Quelle: opennet.ru