API OpenSSL : structures fondamentales et pièges

L’API EVP (enveloppe) est l’interface de haut niveau d’OpenSSL pour les opérations cryptographiques et constitue l’API appropriée à utiliser dans le code applicatif. Elle masque les détails propres aux algorithmes derrière une interface cohérente, prend automatiquement en charge l’accélération matérielle via les moteurs et les fournisseurs, et gère correctement les détails du remplissage et des modes. Les API de bas niveau propres aux algorithmes d’OpenSSL sont obsolètes dans les versions récentes et doivent être évitées.

Le chiffrement symétrique dans OpenSSL utilise l’objet de contexte EVP_CIPHER_CTX. La séquence des opérations est la suivante : EVP_CIPHER_CTX_new pour allouer le contexte, EVP_EncryptInit_ex pour l’initialiser avec l’algorithme de chiffrement et la clé, EVP_EncryptUpdate à plusieurs reprises pour traiter les données, EVP_EncryptFinal_ex pour vider le dernier bloc et récupérer la sortie restante, puis EVP_CIPHER_CTX_free pour libérer la mémoire. Omettre EncryptFinal_ex est une erreur courante qui produit une sortie tronquée.

Le calcul d’empreinte de message utilise également EVP_MD_CTX : EVP_MD_CTX_new, EVP_DigestInit_ex avec l’algorithme (EVP_sha256(), EVP_sha3_256(), etc.), EVP_DigestUpdate avec des blocs de données, puis EVP_DigestFinal_ex pour récupérer le hachage. Les opérations HMAC utilisent un HMAC_CTX distinct ou la nouvelle API EVP_MAC. L’abstraction EVP permet de remplacer l’algorithme de hachage en modifiant un seul appel de fonction.

EVP_PKEY est l’objet unifié de clé asymétrique d’OpenSSL. Il prend en charge RSA, ECDSA, Ed25519, DH et d’autres algorithmes au moyen d’une seule interface. Les clés sont créées à partir de fichiers PEM ou DER avec PEM_read_PrivateKey et PEM_read_PUBKEY, ou générées avec EVP_PKEY_keygen. EVP_PKEY_sign et EVP_PKEY_verify effectuent la signature et la vérification pour tout type de clé en utilisant les mêmes appels de fonction.

BIO (entrées-sorties de base) est la couche d’abstraction des entrées-sorties d’OpenSSL, qui permet de lire et d’écrire des données protégées par TLS ou des données brutes à travers une chaîne d’objets BIO. Une chaîne BIO peut être composée de BIO_new_ssl (couche TLS) suivi de BIO_new_connect (connexion TCP). L’écriture dans le BIO SSL chiffre et envoie automatiquement les données ; la lecture déchiffre les données reçues. Les objets BIO prennent en charge les fichiers, les sockets, les tampons mémoire et les filtres (base64, mise en tampon).

Les connexions TLS dans OpenSSL utilisent deux objets : SSL_CTX (le contexte), qui stocke la configuration commune — certificat, clé privée, ensemble de certificats CA, limites de version du protocole et liste de chiffrements —, et SSL, qui représente une connexion individuelle dérivée du contexte. Créez un seul SSL_CTX par application, puis créez à partir de celui-ci un objet SSL pour chaque connexion. SSL_read et SSL_write transfèrent du texte en clair ; OpenSSL gère en interne toute la mise en trame et tout le chiffrement TLS.

L’erreur la plus dangereuse dans OpenSSL consiste à ignorer les valeurs de retour. EVP_EncryptFinal_ex, SSL_read et SSL_write renvoient tous des valeurs négatives ou zéro pour signaler des erreurs. Appeler SSL_read dans une boucle sans vérifier SSL_get_error peut provoquer des boucles infinies ou faire manquer des erreurs. La valeur de retour de toute fonction OpenSSL susceptible d’échouer doit être vérifiée ; les échecs indiquent souvent des conditions importantes pour la sécurité, comme des échecs de négociation ou des erreurs de validation de certificat.

SSL_read et SSL_write peuvent renvoyer SSL_ERROR_WANT_READ ou SSL_ERROR_WANT_WRITE, ce qui indique que l’opération doit être réessayée après une attente des entrées-sorties. Il ne s’agit pas de véritables erreurs, mais de notifications d’entrées-sorties non bloquantes. Le code qui n’appelle pas SSL_get_error et n’effectue pas correctement une branche selon want-read ou want-write provoquera soit une boucle d’attente active, soit une interprétation incorrecte de ces conditions comme des erreurs. Utilisez toujours SSL_get_error pour interpréter les valeurs de retour négatives des opérations d’entrées-sorties TLS.

OpenSSL contient de nombreuses fonctions de bas niveau obsolètes qui ne doivent pas apparaître dans du nouveau code : appels directs à DES_encrypt1, utilisation directe des fonctions de hachage SHA1 ou MD5 sans la couche EVP, utilisation de RSA_private_encrypt au lieu de EVP_PKEY_sign et utilisation de AES_encrypt (AES ECB sans authentification). Ces API contournent les contrôles de sécurité, utilisent des algorithmes obsolètes ou sont tout simplement moins sûres que leurs équivalents EVP. Les avertissements du compilateur signalent souvent l’utilisation d’API obsolètes.

OpenSSL utilise une gestion explicite de la mémoire ; chaque objet alloué doit être libéré explicitement. Les fuites de mémoire courantes sont les suivantes : oublier EVP_CIPHER_CTX_free après le chiffrement, ne pas appeler SSL_free après la fermeture d’une connexion ou ne pas appeler X509_free après la vérification d’un certificat. Dans les serveurs qui fonctionnent en continu, ces fuites provoquent un épuisement progressif de la mémoire. Utilisez des outils comme valgrind ou AddressSanitizer pour détecter les fuites de mémoire d’OpenSSL pendant le développement.

OpenSSL 3.0 a introduit le modèle des fournisseurs, qui remplace l’ancienne API ENGINE pour l’accélération matérielle. Les fournisseurs sont des modules chargeables qui implémentent des algorithmes cryptographiques : le fournisseur par défaut (logiciel), le fournisseur historique (anciens algorithmes), le fournisseur FIPS (validé selon FIPS 140-2) et des fournisseurs tiers pour les modules de sécurité matérielle. Le fournisseur FIPS permet un fonctionnement conforme en limitant les algorithmes disponibles à ceux approuvés par FIPS 140-2, sans modifier le code de l’application.

Pourquoi l’API EVP d’OpenSSL est-elle privilégiée par rapport aux API de bas niveau propres aux algorithmes ?

Récapitulatif de l’API OpenSSL : utilisez toujours l’API EVP de haut niveau, EVP_CIPHER_CTX pour les opérations symétriques, EVP_MD_CTX pour le hachage, EVP_PKEY pour les clés asymétriques, les chaînes BIO pour l’abstraction des entrées-sorties, SSL_CTX et SSL pour les connexions TLS ; vérifiez toujours les valeurs de retour et appelez SSL_get_error, libérez tous les objets alloués pour éviter les fuites, évitez les fonctions de bas niveau obsolètes et utilisez les fournisseurs d’OpenSSL 3.0 pour la conformité FIPS ou l’accélération matérielle.