OpenSSL-API: zentrale Strukturen und Fallstricke

Die EVP- (Envelope-)API ist die High-Level-Schnittstelle von OpenSSL für kryptografische Operationen und die richtige API für Anwendungscode. Sie abstrahiert algorithmusspezifische Details hinter einer einheitlichen Schnittstelle, unterstützt Hardwarebeschleunigung durch Engines und Provider automatisch und behandelt Padding sowie Modusdetails korrekt. Die algorithmusspezifischen Low-Level-APIs von OpenSSL sind in modernen Versionen veraltet und sollten vermieden werden.

Die symmetrische Verschlüsselung in OpenSSL verwendet das Kontextobjekt EVP_CIPHER_CTX. Die Operationsfolge lautet: EVP_CIPHER_CTX_new zum Anlegen des Kontexts, EVP_EncryptInit_ex zum Initialisieren mit Verschlüsselungsverfahren und Schlüssel, EVP_EncryptUpdate zur wiederholten Verarbeitung von Daten, EVP_EncryptFinal_ex zum Verarbeiten des letzten Blocks und Abrufen der verbleibenden Ausgabe sowie EVP_CIPHER_CTX_free zum Freigeben des Speichers. Das Überspringen von EncryptFinal_ex ist ein häufiger Fehler und führt zu einer abgeschnittenen Ausgabe.

Die Berechnung von Message Digests verwendet EVP_MD_CTX auf ähnliche Weise: EVP_MD_CTX_new, EVP_DigestInit_ex mit dem Algorithmus (EVP_sha256(), EVP_sha3_256() usw.), EVP_DigestUpdate mit Datenblöcken und EVP_DigestFinal_ex zum Abrufen des Hashes. HMAC-Operationen verwenden einen separaten HMAC_CTX oder die neuere EVP_MAC API. Die EVP-Abstraktion ermöglicht es, Hash-Algorithmen durch eine einzige Änderung am Funktionsaufruf auszutauschen.

EVP_PKEY ist das einheitliche Objekt für asymmetrische Schlüssel in OpenSSL und unterstützt RSA, ECDSA, Ed25519, DH sowie weitere Algorithmen über eine einzige Schnittstelle. Schlüssel werden mit PEM_read_PrivateKey und PEM_read_PUBKEY aus PEM- oder DER-Dateien erstellt oder mit EVP_PKEY_keygen generiert. EVP_PKEY_sign und EVP_PKEY_verify führen das Signieren und Verifizieren für jeden Schlüsseltyp mit denselben Funktionsaufrufen durch.

BIO (Basic I/O) ist die I/O-Abstraktionsschicht von OpenSSL, über die TLS-geschützte oder rohe Daten durch eine Kette von BIO-Objekten gelesen und geschrieben werden können. Eine BIO-Kette kann beispielsweise aus BIO_new_ssl (TLS-Schicht) bestehen, das mit BIO_new_connect (TCP-Verbindung) verkettet ist. Das Schreiben in die SSL-BIO verschlüsselt und sendet die Daten automatisch; beim Lesen werden empfangene Daten entschlüsselt. BIO-Objekte unterstützen Dateien, Sockets, Speicherpuffer und Filter (Base64, Pufferung).

TLS-Verbindungen in OpenSSL verwenden zwei Objekte: SSL_CTX (Kontext) speichert die gemeinsame Konfiguration: Zertifikat, privaten Schlüssel, CA-Bundle, Grenzen für Protokollversionen und Cipher-Liste. SSL stellt eine einzelne, aus dem Kontext abgeleitete Verbindung dar. Erstellen Sie pro Anwendung ein SSL_CTX-Objekt und anschließend für jede Verbindung ein SSL-Objekt daraus. SSL_read und SSL_write übertragen Klartext; OpenSSL übernimmt die gesamte TLS-Frame-Strukturierung und Verschlüsselung intern.

Der gefährlichste Fehler bei OpenSSL besteht darin, Rückgabewerte zu ignorieren. EVP_EncryptFinal_ex, SSL_read und SSL_write geben negative Werte oder null zurück, um Fehler anzuzeigen. Der Aufruf von SSL_read in einer Schleife ohne Prüfung von SSL_get_error kann Endlosschleifen verursachen oder Fehler übersehen. Der Rückgabewert jeder möglicherweise fehlschlagenden OpenSSL-Funktion muss geprüft werden; Fehler weisen häufig auf sicherheitsrelevante Bedingungen wie fehlgeschlagene Handshakes oder Zertifikatsprüfungen hin.

SSL_read und SSL_write können SSL_ERROR_WANT_READ oder SSL_ERROR_WANT_WRITE zurückgeben. Dies bedeutet, dass die Operation nach dem Warten auf I/O wiederholt werden sollte. Dabei handelt es sich nicht um echte Fehler, sondern um Benachrichtigungen für nicht blockierende I/O. Code, der SSL_get_error nicht aufruft und nicht korrekt zwischen want-read und want-write unterscheidet, führt entweder zu einer stark ausgelasteten Endlosschleife oder behandelt diese Zustände fälschlicherweise als Fehler. Verwenden Sie immer SSL_get_error, um negative Rückgabewerte von TLS-I/O-Operationen zu interpretieren.

OpenSSL enthält viele veraltete Low-Level-Funktionen, die in neuem Code nicht verwendet werden sollten: direkte Aufrufe von DES_encrypt1, die direkte Verwendung der Hash-Funktionen SHA1 oder MD5 ohne die EVP-Schicht, RSA_private_encrypt anstelle von EVP_PKEY_sign sowie AES_encrypt (AES-ECB ohne Authentifizierung). Diese APIs umgehen Sicherheitsprüfungen, verwenden veraltete Algorithmen oder sind schlicht weniger sicher als ihre EVP-Entsprechungen. Compilerwarnungen weisen häufig auf die Verwendung veralteter APIs hin.

OpenSSL verwendet eine explizite Speicherverwaltung; jedes angelegte Objekt muss ausdrücklich freigegeben werden. Häufige Speicherlecks entstehen, wenn nach der Verschlüsselung EVP_CIPHER_CTX_free nicht aufgerufen wird, nach dem Schließen einer Verbindung SSL_free fehlt oder nach der Zertifikatsprüfung X509_free nicht aufgerufen wird. In langlebigen Servern führen diese Lecks allmählich zu einer Erschöpfung des verfügbaren Speichers. Verwenden Sie während der Entwicklung Werkzeuge wie valgrind oder AddressSanitizer, um Speicherlecks in OpenSSL zu erkennen.

OpenSSL 3.0 führte das Provider-Modell ein, das die ältere ENGINE API für Hardwarebeschleunigung ersetzt. Provider sind ladbare Module, die kryptografische Algorithmen implementieren: der Default-Provider (Software), der Legacy-Provider (ältere Algorithmen), der FIPS-Provider (nach FIPS 140-2 validiert) und Drittanbieter-Provider für HSMs. Der FIPS-Provider ermöglicht einen FIPS-konformen Betrieb, indem er die verfügbaren Algorithmen auf die nach FIPS 140-2 zugelassenen beschränkt, ohne dass der Anwendungscode geändert werden muss.

Warum wird die OpenSSL EVP API gegenüber algorithmusspezifischen Low-Level-APIs bevorzugt?

Zusammenfassung der OpenSSL API: Verwenden Sie immer die EVP-High-Level-API, EVP_CIPHER_CTX für symmetrische Operationen, EVP_MD_CTX für Hashing, EVP_PKEY für asymmetrische Schlüssel, BIO-Ketten für die I/O-Abstraktion sowie SSL_CTX und SSL für TLS-Verbindungen. Prüfen Sie immer die Rückgabewerte und rufen Sie SSL_get_error auf, geben Sie alle angelegten Objekte frei, um Speicherlecks zu verhindern, vermeiden Sie veraltete Low-Level-Funktionen und verwenden Sie die Provider von OpenSSL 3.0 für FIPS-Konformität oder Hardwarebeschleunigung.