In diesem Dokument beschreibt das OpenSSL Management Committee die Grundprinzipien der strategischen OpenSSL-Architektur. Ab 3.0.0 sind mehrere Versionen erforderlich, um von der aktuellen Architektur (Version 1.1.1) in die Zukunft zu wechseln.

In der Architektur werden zahlreiche Änderungen erwartet. Wir bieten einen möglichen Migrationspfad an. Die Veröffentlichung von OpenSSL 3.0.0 wirkt sich nur minimal auf die überwiegende Mehrheit der vorhandenen Anwendungen aus. Fast alle Anwendungen mit Lese- und Schreibkenntnissen müssen nur neu kompiliert werden.

Die aktuelle Funktionalität der Motorschnittstelle wird im Laufe der Zeit durch die Softwareschnittstelle ersetzt. OpenSSL 3.0.0 behält die Motorunterstützung bei. Zukünftige Architekturen können frühestens mit OpenSSL 4.0.0 vollständig implementiert werden.

Aktuelle Architektur

OpenSSL besteht derzeit aus vier Hauptkomponenten:

1. libcrypto. Die Hauptbibliothek für die Bereitstellung von Implementierungen zahlreicher kryptografischer Grundelemente. Darüber hinaus bietet es eine Reihe unterstützender Dienste für libssl und libcrypto sowie Protokollimplementierungen wie CMS und OCSP.
   
2. Der Motor. Die Funktionalität von libcrypto kann über die Engine-API erweitert werden.
   
   In der Regel sind Engines dynamisch geladene Module, die in libcrypto registriert sind und verfügbare Hooks verwenden, um kryptografische Algorithmen zu implementieren. Dies sind meistens alternative Implementierungen von Algorithmen, die bereits von libcrypto bereitgestellt werden (z. B. mit Unterstützung für Hardwarebeschleunigung). Sie können jedoch auch Algorithmen enthalten, die nicht in OpenSSL von implementiert sind Standardmäßig (z. B. implementiert der GOST-Mechanismus die russische GOST-Algorithmusfamilie). Einige Engines werden mit der OpenSSL-Distribution geliefert, andere mit Drittanbietern (wieder GOST).
   
3. libssl. Eine Bibliothek, die von libcrypto abhängt und die TLS- und DTLS-Protokolle implementiert.
   
4. Anwendungen Eine Reihe von Befehlszeilentools, die die grundlegenden Komponenten von libssl und libcrypto verwenden, um eine Reihe von kryptografischen und anderen Funktionen bereitzustellen, wie z.
   
   
   • Generierung und Überprüfung von Schlüsseln und Parametern
     
   • Generierung und Überprüfung von Zertifikaten
     
   • SSL / TLS-Testtools
     
   • ASN.1-Überprüfung
     
   • usw.
   
   OpenSSL verfügt derzeit über die folgenden Funktionen:
   
   
   1. EVP Die EVP-Schicht-API (Envelope) bietet eine abstrakte Schnittstelle auf hoher Ebene für kryptografische Funktionen, ohne an eine bestimmte Implementierung gebunden zu sein. Die direkte Verwendung spezifischer Implementierungen kryptografischer Algorithmen unter Umgehung von EVP-Schnittstellen wird nicht empfohlen. Es bietet auch zusammengesetzte Operationen wie Signieren und Überprüfen. Einige zusammengesetzte Operationen werden auch als EVP-Level-Operation bereitgestellt (z. B. HMAC-SHA256). EVP ermöglicht auch die Verwendung kryptografischer Algorithmen auf algorithmisch-agnostische Weise (EVP_DigestSign funktioniert beispielsweise sowohl für RSA- als auch für ECDSA-Algorithmen).
      
   2. FIPS140 wird nicht unterstützt, es ist nur in OpenSSL-1.0.2 verfügbar, das vor der aktuellen Architektur liegt und nicht mit API oder ABI kompatibel ist.
   
   

   Komponentenkonzept

   
   Die vorhandene Architektur ist eine einfache vierstufige Struktur mit einer Kryptoschicht im unteren Bereich. Die TLS-Schicht hängt von der kryptografischen Schicht ab, und Anwendungen hängen sowohl von der TLS-Schicht als auch von der kryptografischen Schicht ab.
   
   Hinweis: Das Vorhandensein einer Komponente im Diagramm bedeutet nicht, dass die Komponente eine öffentliche API ist oder für den direkten Zugriff / die Verwendung durch den Endbenutzer vorgesehen ist.
   
   
   
   

   Paketdiagramm

   
   Die oben beschriebenen Komponenten sind in Bibliotheken (libcrypto und libssl) und den entsprechenden Kernel-Schnittstellen sowie in der ausführbaren Befehlszeile (openssl) zum Starten verschiedener Anwendungen gepackt. Dies ist in der folgenden Abbildung dargestellt.
   
   
   
   

   Zukünftige Architektur

   
   Merkmale der zukünftigen Architektur:
   
   
   • Kernel-Services bilden die Bausteine, die von Anwendungen und Anbietern verwendet werden (z. B. BIO, X509, SECMEM, ASN1 usw.).
     
   • Lieferanten verwenden kryptografische Algorithmen und Support-Services. Ein Anbieter implementiert eine oder mehrere der folgenden Funktionen:
     
     
     • Kryptografische Grundelemente für den Algorithmus: Verschlüsselung, Entschlüsselung, Signatur, Hashing usw.
       
     • Serialisierung für den Algorithmus, beispielsweise die Funktion zum Konvertieren des privaten Schlüssels in eine PEM-Datei. Die Serialisierung kann in Formaten oder aus Formaten erfolgen, die derzeit nicht unterstützt werden.
       
     • Loader-Backend speichern. OpenSSL wird derzeit mit einem Bootloader zum Lesen von Schlüsseln, Parametern und anderen Elementen aus Dateien geliefert. Anbieter können Downloader implementieren, um Daten von anderen Orten (z. B. aus einem LDAP-Verzeichnis) zu lesen.
     
     Der Anbieter kann vollständig autonom sein oder Dienste verwenden, die von verschiedenen Anbietern oder Kerneldiensten bereitgestellt werden. Beispielsweise kann eine Anwendung kryptografische Grundelemente für einen von einem Hardwarebeschleuniger-Anbieter implementierten Algorithmus verwenden, jedoch die Serialisierungsdienste eines anderen Anbieters verwenden, um Schlüssel in das PKCS # 12-Format zu exportieren.
     
     Der Standardanbieter (der den Kern der aktuellen Implementierungen des OpenSSL-Kryptografiealgorithmus enthält) ist "integriert", andere Anbieter können jedoch zur Laufzeit dynamisch geladen werden.
     
     Die Module der Legacy-Anbieter stellen kryptografische Implementierungen für ältere Algorithmen bereit (z. B. DES, MDC2, MD2, Blowfish, CAST). Wir werden Regeln veröffentlichen, wie und wann Algorithmen von einem Standardanbieter zu einem veralteten Anbieter wechseln.
     
     Der FIPS-Anbieter, der das OpenSSL FIPS-Kryptografiemodul implementiert, kann zur Laufzeit dynamisch geladen werden.
     
   • Der Kernel bietet Zugriff auf Dienste, die von Anwendungsanbietern (und anderen) angeboten werden. Anbieter gewähren dem Kernel Zugriff auf Methoden. Ein Kernel ist ein Mechanismus, mit dem bestimmte Implementierungen von Dingen wie Algorithmen entdeckt werden.
     
     Der Kernel implementiert eine eigenschaftsbasierte Suchfunktion, um Algorithmen zu finden. Dies findet beispielsweise einen Algorithmus, bei dem "fips = true" oder "keysize = 128, constant_time = true" ist. Details werden in nachfolgenden Projektdokumenten veröffentlicht.
     
   • Protokollimplementierungen wie TLS, DTLS.
   
   Zukünftige Architektur weist die folgenden Merkmale auf:
   
   
   • Die EVP-Schicht wird zu einem Thin Wrapper für Services, die von Lieferanten implementiert werden. Die meisten Anrufe werden mit minimaler Vorverarbeitung, Nachbearbeitung oder überhaupt keiner Verarbeitung durchgeführt.
     
   • Es werden neue EVP-APIs angezeigt, die den Kernel nach der Implementierung des Algorithmus durchsuchen, der für jeden EVP-Aufruf verwendet wird.
     
   • Informationen werden unabhängig von ihrer Implementierung auf dieselbe Weise zwischen der Hauptbibliothek und den Lieferanten übertragen.
     
   • Veraltete APIs (z. B. kryptografische APIs auf niedriger Ebene, die die EVP-Schicht nicht durchlaufen) werden ausgeschlossen. Beachten Sie, dass es veraltete APIs für Algorithmen gibt, die nicht veraltet sind (z. B. ist AES kein veralteter Algorithmus, aber AES_encrypt ist eine veraltete API).
     
   • Das OpenSSL FIPS-Kryptografiemodul wird als dynamisch geladener Anbieter implementiert. Es ist autonom (d. H. Es hängt möglicherweise nur von den vom Kernel bereitgestellten Systemlaufzeitbibliotheken und -diensten ab).
     
   • Andere Schnittstellen können im Laufe der Zeit auch in die Verwendung des Kernels konvertiert werden (z. B. OSSL_STORE).
     
   • Die Verwendung des Motors geht an die Lieferanten. "Tschüss, Ingenieure, hallo, Lieferanten . "
   
   

   Komponentenkonzept

   
   Das folgende Diagramm bietet einen Überblick über die Komponenten der zukünftigen OpenSSL-Architektur.
   
   Hinweis: Das Vorhandensein einer Komponente im Diagramm bedeutet nicht, dass die Komponente eine öffentliche API ist oder für den direkten Zugriff / die Verwendung durch den Endbenutzer vorgesehen ist.
   
   
   
   Folgende Komponenten werden hier gezeigt:
   
   
   • Anwendungen: Befehlszeilen-Dienstprogramme: ca, chiffren, cms, dgst usw.
     
   • Protokolle: Die Komponente bietet die Möglichkeit, mithilfe von Standardprotokollen zwischen Endpunkten zu kommunizieren:
     
     • TLS-Protokolle: Implementierung aller unterstützten TLS / DTLS-Protokolle und Serving-Infrastruktur:
       
       • SSL BIO: BIO für die TLS-Kommunikation
         
       • Statem: TLS-Zustandsmaschine
         
       • Datensatz: TLS-Datensatzschicht
     • Andere Protokolle
       
       • CMS: Implementierung des Cryptographic Message Syntax Standard
         
       • OCSP: Implementierung des Online-Zertifikatstatusprotokolls
         
       • TS: Implementierung des Zeitstempelprotokolls
     • Support Services: Komponenten, die speziell zur Unterstützung der Implementierung von Protokollcode entwickelt wurden
       
       • Paket: interne Komponente zum Lesen von Protokollnachrichten
         
       • Wpacket: Eine interne Komponente zum Aufzeichnen von Protokollnachrichten
   • Kernel: Dies ist die grundlegende Komponente, die Dienstanforderungen (z. B. Verschlüsselung) mit dem Dienstanbieter verbindet. Es ermöglicht Lieferanten, ihre Dienstleistungen zusammen mit ihren Immobilien zu registrieren. Der Kernel bietet auch die Möglichkeit, einen Dienst mit einem bestimmten Satz von Eigenschaften zu finden, die der Dienst ausführen soll. Zu den Eigenschaften des Verschlüsselungsdienstes gehören beispielsweise "aead", "aes-gcm", "fips", "security-bits = 128" usw.
     
   • Standardanbieter: Implementiert eine Reihe von im Kernel registrierten Standarddiensten.
     
     • Support-Services
       
       • Implementierungen auf niedriger Ebene: Dies ist eine Reihe von Komponenten, die tatsächlich kryptografische Grundelemente implementieren.
   • FIPS-Anbieter: Implementiert eine Reihe von Diensten, die überprüft werden und dem FIPS-Kern zur Verfügung stehen. Beinhaltet die folgenden Support-Services:
     
     • POST: Selbsttest beim Einschalten
       
     • KAT: Bekannte Antworttests
       
     • Integritätsprüfung
       
     • Implementierungen auf niedriger Ebene: Dies ist eine Reihe von Komponenten, die tatsächlich kryptografische Grundelemente implementieren (um die eigenständige FIPS-Anforderung zu erfüllen).
   • Legacy-Algorithmus-Anbieter: Bietet Implementierungen von Legacy-Algorithmen, die über die EVP-API bereitgestellt werden.
     
   • Drittanbieter: Nicht Teil der OpenSSL-Distribution. Dritte können ihre eigenen Lieferanten verkaufen.
     
   • Allgemeine Dienste: bilden die Bausteine, die von Anwendungen und Lieferanten verwendet werden (z. B. BIO, X509, SECMEM, ASN1 usw.).
     
   • Veraltete APIs. "Low-Level" -API: Hier bezieht sich das Wort "veraltet" speziell auf die API und nicht auf den Algorithmus selbst. Zum Beispiel ist AES kein veralteter Algorithmus, aber es gibt veraltete APIs dafür (zum Beispiel AES_encrypt).
   
   

   Paketdiagramm

   
   Die verschiedenen Komponenten, die oben im konzeptionellen Diagramm der Komponenten beschrieben wurden, sind physisch verpackt in:
   
   
   • Ausführbare Anwendungen für Benutzer
     
   • Bibliothek (en) für Anwendungen
     
   • Dynamisch ladbare Module für den Kernel.
   
   
   
   
   Die folgenden tatsächlichen Pakete werden hier gezeigt:
   
   
   • Die ausführbare Datei ist OpenSSL. Befehlszeilenanwendung.
     
   • Libssl. Enthält alles, was in direktem Zusammenhang mit TLS und DTLS steht. Der Inhalt entspricht weitgehend dem des aktuellen libssl. Beachten Sie, dass einige Support-Services nach libcrypto verschoben werden.
     
   • Libcrypto Diese Bibliothek enthält die folgenden Komponenten:
     
     • Implementierungen der Hauptdienste: X509, ASN1, EVP, OSSL_STORE usw.
       
     • Der Kern
       
     • Nicht-TLS- oder DTLS-Protokolle
       
     • Protokollunterstützungsdienste (z. B. Packet und Wpacket)
       
     • Standardanbieter mit Implementierungen aller Standardalgorithmen
   • Libcrypto-Erbe. Bietet ältere Low-Level-APIs. Die Implementierung der Algorithmen für diese APIs kann von jedem Anbieter stammen.
     
   • FIPS-Modul. Enthält einen FIPS-Anbieter, der eine Reihe von Diensten implementiert, die von FIPS überprüft und im Kernel registriert wurden.
     
   • Legacy-Modul. Enthält einen veralteten Anbieter.