Dans ce document, le comité de gestion d'OpenSSL décrit les principes de base de l'architecture stratégique d'OpenSSL. À partir de 3.0.0, plusieurs versions seront nécessaires pour passer de l'architecture actuelle (version 1.1.1) à l'avenir.

De nombreux changements sont attendus dans l'architecture. Nous proposons un chemin de migration possible. La version d'OpenSSL 3.0.0 affecte de manière minimale la grande majorité des applications existantes, presque toutes les applications alphabétisées devront simplement être recompilées.

La fonctionnalité actuelle fournie par l'interface du moteur sera remplacée par l'interface logicielle au fil du temps. OpenSSL 3.0.0 conservera le support du moteur. L'architecture future peut être entièrement implémentée au plus tôt OpenSSL 4.0.0.

Architecture actuelle

OpenSSL comprend actuellement quatre composants principaux:

1. libcrypto. La bibliothèque principale pour fournir des implémentations de nombreuses primitives cryptographiques. De plus, il fournit un ensemble de services de support pour libssl et libcrypto, ainsi que des implémentations de protocoles tels que CMS et OCSP.
   
2. Le moteur. La fonctionnalité de libcrypto peut être étendue via l'API du moteur.
   
   En règle générale, les moteurs sont des modules chargés dynamiquement enregistrés dans libcrypto et utilisant les crochets disponibles pour implémenter des algorithmes cryptographiques, le plus souvent des implémentations alternatives d'algorithmes déjà fournis par libcrypto (par exemple, avec prise en charge de l'accélération matérielle), mais ils peuvent également inclure des algorithmes qui ne sont pas implémentés dans OpenSSL par par défaut (par exemple, le mécanisme GOST implémente la famille d'algorithmes russe GOST). Certains moteurs sont livrés avec la distribution OpenSSL, tandis que d'autres sont livrés avec des tiers (encore une fois, GOST).
   
3. libssl. Une bibliothèque qui dépend de libcrypto et implémente les protocoles TLS et DTLS.
   
4. Les applications Un ensemble d'outils de ligne de commande qui utilise les composants de base de libssl et libcrypto pour fournir un ensemble de fonctions cryptographiques et autres, telles que:
   
   
   • Génération et vérification des clés et des paramètres
     
   • Génération et vérification de certificats
     
   • Outils de test SSL / TLS
     
   • Vérification ASN.1
     
   • et autres
   
   OpenSSL présente actuellement les fonctionnalités suivantes:
   
   
   1. EVP L'API de couche EVP (enveloppe) fournit une interface abstraite de haut niveau pour la fonctionnalité cryptographique, sans être liée à une implémentation spécifique. L'utilisation directe d'implémentations spécifiques d'algorithmes cryptographiques contournant les interfaces EVP n'est pas recommandée. Il fournit également des opérations composées telles que la signature et la vérification. Certaines opérations composées sont également fournies en tant qu'opérations de niveau EVP (par exemple, HMAC-SHA256). EVP permet également l'utilisation d'algorithmes cryptographiques d'une manière algorithmique-agnostique (par exemple, EVP_DigestSign fonctionne pour les algorithmes RSA et ECDSA).
      
   2. FIPS140 n'est pas pris en charge, il est disponible uniquement dans OpenSSL-1.0.2, qui est antérieur à l'architecture actuelle et n'est pas compatible avec l'API ou l'ABI.
   
   

   Concept de composant

   
   L'architecture existante est une structure simple à quatre niveaux avec une couche cryptographique en bas. La couche TLS dépend de la couche cryptographique et les applications dépendent à la fois de la couche TLS et de la couche cryptographique.
   
   Remarque: la présence d'un composant dans le diagramme ne signifie pas que le composant est une API publique ou est destiné à un accès / utilisation direct par l'utilisateur final.
   
   
   
   

   Diagramme de package

   
   Les composants décrits ci-dessus sont regroupés dans des bibliothèques (libcrypto et libssl) et les interfaces du noyau correspondantes, ainsi que l'exécutable de ligne de commande (openssl) pour lancer diverses applications. Ceci est illustré dans le diagramme ci-dessous.
   
   
   
   

   Architecture future

   
   Caractéristiques de la future architecture:
   
   
   • Les services du noyau constituent les blocs de construction utilisés par les applications et les fournisseurs (par exemple, BIO, X509, SECMEM, ASN1, etc.).
     
   • Les fournisseurs utilisent des algorithmes cryptographiques et des services d'assistance. Un fournisseur implémente une ou plusieurs des fonctions suivantes:
     
     
     • Primitives cryptographiques pour l'algorithme: chiffrement, déchiffrement, signature, hachage, etc.
       
     • Sérialisation de l'algorithme, par exemple, la fonction de conversion de la clé privée en fichier PEM. La sérialisation peut être dans des formats ou à partir de formats qui ne sont pas actuellement pris en charge.
       
     • Stocker le backend du chargeur. OpenSSL est actuellement livré avec un chargeur de démarrage pour lire les clés, les paramètres et d'autres éléments des fichiers. Les fournisseurs peuvent implémenter des téléchargeurs pour lire les données à partir d'autres emplacements (par exemple, à partir d'un annuaire LDAP).
     
     Le fournisseur peut être entièrement autonome ou utiliser des services fournis par différents fournisseurs ou services de noyau. Par exemple, une application peut utiliser des primitives cryptographiques pour un algorithme implémenté par un fournisseur d'accélérateurs matériels, mais utiliser les services de sérialisation d'un autre fournisseur pour exporter des clés au format PKCS # 12.
     
     Le fournisseur par défaut (qui contient le cœur des implémentations actuelles de l'algorithme cryptographique OpenSSL) sera «intégré», mais d'autres fournisseurs pourront se charger dynamiquement au moment de l'exécution.
     
     Le ou les modules des fournisseurs hérités fourniront des implémentations cryptographiques pour des algorithmes plus anciens (par exemple DES, MDC2, MD2, Blowfish, CAST). Nous publierons des règles sur comment et quand les algorithmes passeront d'un fournisseur par défaut à un fournisseur obsolète.
     
     Le fournisseur FIPS qui implémente le module cryptographique OpenSSL FIPS peut se charger dynamiquement au moment de l'exécution.
     
   • Le noyau permet d'accéder aux services offerts par les fournisseurs d'applications (et autres). Les vendeurs donnent au noyau l'accès aux méthodes. Un noyau est un mécanisme par lequel des implémentations spécifiques de choses comme des algorithmes sont découvertes.
     
     Le noyau implémente une fonction de recherche basée sur les propriétés pour trouver des algorithmes. Par exemple, cela trouvera un algorithme où "fips = true" ou "keysize = 128, constant_time = true". Les détails seront publiés dans les documents de projet ultérieurs.
     
   • Implémentations de protocole telles que TLS, DTLS.
   
   L'architecture future présente les caractéristiques suivantes:
   
   
   • La couche EVP devient une enveloppe mince pour les services mis en œuvre via les fournisseurs. La plupart des appels passent par un pré-traitement, un post-traitement ou aucun traitement du tout.
     
   • De nouvelles API EVP apparaîtront pour rechercher dans le noyau l'implémentation de l'algorithme qui sera utilisé pour tout appel EVP.
     
   • Les informations seront transférées entre la bibliothèque principale et les fournisseurs de la même manière, quelle que soit leur implémentation.
     
   • Les API obsolètes (telles que les API cryptographiques de bas niveau qui ne passent pas par la couche EVP) seront exclues. Notez qu'il existe des API obsolètes pour des algorithmes qui ne sont pas obsolètes (par exemple, AES n'est pas un algorithme obsolète, mais AES_encrypt est une API obsolète).
     
   • Le module cryptographique OpenSSL FIPS sera implémenté en tant que fournisseur chargé dynamiquement. Il sera autonome (c'est-à-dire qu'il peut dépendre uniquement des bibliothèques d'exécution du système et des services fournis par le noyau).
     
   • D'autres interfaces peuvent également être converties pour utiliser le noyau au fil du temps (par exemple, OSSL_STORE).
     
   • L'utilisation du moteur revient aux fournisseurs. "Au revoir, ingénieurs, bonjour, fournisseurs . "
   
   

   Concept de composant

   
   Le schéma ci-dessous donne un aperçu des composants de la future architecture OpenSSL.
   
   Remarque: la présence d'un composant dans le diagramme ne signifie pas que le composant est une API publique ou est destiné à un accès / utilisation direct par l'utilisateur final.
   
   
   
   Les composants suivants sont présentés ici:
   
   
   • Applications: utilitaires de ligne de commande: ca, chiffres, cms, dgst, etc.
     
   • Protocoles: le composant offre la possibilité de communiquer entre les points d'extrémité à l'aide de protocoles standard:
     
     • Protocoles TLS: implémentation de tous les protocoles TLS / DTLS pris en charge et infrastructure de service:
       
       • SSL BIO: BIO pour la communication TLS
         
       • Statem: machine d'état TLS
         
       • Enregistrement: couche d'enregistrement TLS
     • Autres protocoles
       
       • CMS: implémentation de la norme de syntaxe des messages cryptographiques
         
       • OCSP: Implémentation du protocole de statut de certificat en ligne
         
       • TS: mise en œuvre du protocole d'horodatage
     • Services d'assistance: composants spécialement conçus pour prendre en charge la mise en œuvre du code de protocole
       
       • Paquet: composant interne pour lire les messages de protocole
         
       • Wpacket: un composant interne pour l'enregistrement des messages de protocole
   • Noyau: il s'agit du composant fondamental qui connecte les demandes de service (par exemple, le chiffrement) au fournisseur de services. Il permet aux fournisseurs d'enregistrer leurs services ainsi que leurs propriétés. Le noyau offre également la possibilité de trouver un service avec un ensemble donné de propriétés que le service doit exécuter. Par exemple, les propriétés du service de chiffrement peuvent inclure "aead", "aes-gcm", "fips", "security-bits = 128", etc.
     
   • Fournisseur par défaut: implémente un ensemble de services par défaut enregistrés dans le noyau.
     
     • Services de support
       
       • Implémentations de bas niveau: il s'agit d'un ensemble de composants qui implémentent réellement des primitives cryptographiques.
   • Fournisseur FIPS: met en œuvre un ensemble de services vérifiés et disponibles pour le noyau FIPS. Comprend les services de support suivants:
     
     • POST: Auto-test de mise sous tension
       
     • KAT: Tests de réponse connus
       
     • Contrôle d'intégrité
       
     • Implémentations de bas niveau: il s'agit d'un ensemble de composants qui implémentent réellement des primitives cryptographiques (pour satisfaire l'exigence FIPS autonome).
   • Fournisseur d'algorithmes hérités: fournit des implémentations d'algorithmes hérités qui seront fournis via l'API EVP.
     
   • Fournisseur tiers: ne fait pas partie de la distribution OpenSSL. Les tiers peuvent vendre leurs propres fournisseurs.
     
   • Services généraux: forment les blocs de construction utilisés par les applications et les fournisseurs (par exemple, BIO, X509, SECMEM, ASN1, etc.).
     
   • API obsolètes. API "bas niveau": ici le mot "obsolète" se réfère spécifiquement à l'API, et non à l'algorithme lui-même. Par exemple, AES n'est pas un algorithme obsolète, mais il existe des API obsolètes (par exemple, AES_encrypt).
   
   

   Diagramme de package

   
   Les différents composants décrits ci-dessus dans le schéma conceptuel des composants sont physiquement conditionnés dans:
   
   
   • Applications exécutables pour les utilisateurs
     
   • Bibliothèque (s) pour applications
     
   • Module (s) chargeable dynamiquement pour le noyau.
   
   
   
   
   Les packages réels suivants sont affichés ici:
   
   
   • Le fichier exécutable est OpenSSL. Application en ligne de commande.
     
   • Libssl. Contient tout ce qui est directement lié à TLS et DTLS. Son contenu est sensiblement le même que dans le libssl actuel. Notez que certains services de support seront déplacés vers libcrypto.
     
   • Libcrypto Cette bibliothèque contient les composants suivants:
     
     • Implémentations des principaux services: X509, ASN1, EVP, OSSL_STORE, etc.
       
     • Le noyau
       
     • Protocoles non TLS ou DTLS
       
     • Services de support de protocole (par exemple Packet et Wpacket)
       
     • Fournisseur par défaut contenant les implémentations de tous les algorithmes par défaut
   • Libcrypto-legacy. Fournit des API de bas niveau héritées. La mise en œuvre des algorithmes pour ces API peut provenir de n'importe quel fournisseur.
     
   • Module FIPS. Contient un fournisseur FIPS qui implémente un ensemble de services vérifiés par FIPS et enregistrés dans le noyau.
     
   • Module hérité. Contient un fournisseur obsolète.