Kryptografische Abhängigkeiten prüfen und auswählen

Die Wahl der kryptografischen Bibliothek gehört zu den folgenreichsten Sicherheitsentscheidungen in einem Projekt. Selbst gutwillige Entwickler können mit einer ungeeigneten Bibliothek unsichere Systeme erstellen. Eine gut konzipierte Bibliothek erschwert es dagegen, katastrophale Fehler zu machen. Die Auswahl sollte systematisch erfolgen und die bisherige Sicherheitsbilanz, das API-Design, den Wartungsstand und die Eignung für den vorgesehenen Zweck bewerten.

Eine der ersten Fragen zu jeder kryptografischen Bibliothek lautet, wann sie zuletzt unabhängig geprüft wurde und welchen Umfang dieses Audit hatte. Ein Audit von vor fünf Jahren für Version 1.0 bietet für die heute eingesetzte Version 3.0 weniger Sicherheit. Achten Sie auf Audits renommierter Sicherheitsfirmen (NCC Group, Trail of Bits, Quarkslab, Cure53), die genau die Funktionen abdecken, die Sie verwenden möchten. Einige Bibliotheken veröffentlichen Auditberichte öffentlich; das vollständige Fehlen eines Audits ist ein erheblicher Risikofaktor.

Prüfen Sie den CVE-Verlauf der Bibliothek in der NVD (National Vulnerability Database). Achten Sie darauf, wie viele CVEs existieren, welche Schweregrade sie haben, welche Arten von Schwachstellen sie darstellen (Logikfehler, Speicherbeschädigung oder Schwächen von Algorithmen) und wie schnell die Maintainer Patches veröffentlicht haben. Eine Bibliothek mit gelegentlichen, schnell behobenen CVEs zeugt von einer reaktionsfähigen Wartung. Viele CVEs mit hohem Schweregrad oder eine langsame Bereitstellung von Patches sind Warnsignale.

Ungewartete kryptografische Bibliotheken sind gefährlich. Prüfen Sie das Datum des letzten Commits, die Veröffentlichungshäufigkeit und ob auf Sicherheitshinweise reagiert wird. Bei einer Bibliothek, deren letzter Commit drei Jahre zurückliegt, können bekannte Schwachstellen bestehen, die nie behoben werden. Die Größe der Community ist wegen der Breite der Überprüfung relevant: Weitverbreitete Bibliotheken werden von Sicherheitsforschern genauer untersucht als Nischenprojekte.

Ein kleinerer, stärker vorgegebener API-Umfang ist aus Sicherheitssicht besser. Bibliotheken, die viele Algorithmen und Konfigurationsoptionen anbieten, eröffnen Möglichkeiten für Fehlkonfigurationen. Vergleichen Sie libsodium (eine Funktion pro Anwendungsfall, ein festgelegter Algorithmus) mit OpenSSL EVP (Chiffre, Modus, Schlüssellänge, Padding und IV-Verarbeitung werden separat gewählt). Je schwieriger es ist, eine Bibliothek falsch zu verwenden, desto besser eignet sie sich für sicherheitsbewusste Projekte.

Bei Operationen mit geheimen Daten (Schlüsselvergleich, Entschlüsselung, Signaturüberprüfung) muss die Implementierung Algorithmen mit konstanter Laufzeit verwenden, die weder abhängig von geheimen Werten Verzweigungen ausführen noch auf dieser Grundlage auf den Speicher zugreifen. Vergewissern Sie sich, dass die Dokumentation der Bibliothek ausdrücklich Garantien für konstante Laufzeit bei sensiblen Operationen nennt oder dass der Quellcode anerkannte Vergleichsfunktionen mit konstanter Laufzeit verwendet. Bibliotheken ohne diese Garantie sind anfällig für Timing-Seitenkanalangriffe.

Eine gute kryptografische Bibliothek sollte moderne Algorithmen unterstützen und die Abkündigung veralteter Algorithmen planen. Sie sollte ChaCha20-Poly1305 oder AES-256-GCM für die Verschlüsselung, Ed25519 oder ECDSA P-256 für Signaturen, X25519 für den Schlüsselaustausch und Argon2id für das Passwort-Hashing anbieten. Bibliotheken, die ausschließlich veraltete Algorithmen wie DES, RC4, MD5 oder SHA-1 anbieten, sind unabhängig von ihren sonstigen Eigenschaften nicht für neue Bereitstellungen geeignet.

Bewerten Sie die transitiven Abhängigkeiten: Von welchen Bibliotheken hängt Ihre kryptografische Bibliothek ab, und wie ist deren Sicherheitsstand? Eine Bibliothek ohne externe Abhängigkeiten (wie libsodium) birgt nur ein minimales Risiko in der Lieferkette. Eine Bibliothek, die von einem Dutzend npm-Paketen mit jeweils eigenen Abhängigkeiten abhängt, hat eine große Angriffsfläche in der Lieferkette. Prüfen Sie, ob die Bibliothek reproduzierbare Builds verwendet, sodass sich verifizieren lässt, dass die bereitgestellte Binärdatei mit dem Quellcode übereinstimmt.

Für regulierte Branchen (Gesundheitswesen, Finanzwesen und Behörden) sind häufig nach FIPS 140-2 oder 140-3 validierte kryptografische Module erforderlich. Die FIPS-Validierung ist teuer und zeitaufwendig, daher verfügen nur wenige Bibliotheken darüber. OpenSSL mit seinem FIPS-Provider, BoringCrypto (verwendet in Gos crypto/tls) und einige HSM-Bibliotheken sind FIPS-validiert. Wenn Ihre Bereitstellung FIPS-Konformität erfordert, schränkt diese Vorgabe die Auswahl der Bibliothek erheblich ein.

Hardware Security Modules (HSMs) und Cloud-KMS-Dienste verfügen für Schlüsseloperationen häufig über proprietäre APIs. Eine enge Kopplung Ihrer Anwendung an AWS KMS oder einen bestimmten HSM-Anbieter birgt das Risiko einer Herstellerbindung. Prüfen Sie, ob die Bibliothek Abstraktionsebenen (wie Tinks KMS-Integration) bereitstellt, die einen Anbieterwechsel ermöglichen. Bedenken Sie außerdem, dass die Migrationskosten erheblich sein können, wenn der HSM-Anbieter den Support einstellt oder die Preise erhöht.

Die wichtigste Regel bei der Auswahl kryptografischer Abhängigkeiten lautet: Verwenden Sie bekannte, weitverbreitete Bibliotheken, die etablierte Standards implementieren, und implementieren Sie niemals selbst kryptografische Primitive. Unabhängig davon, wie gut Sie die Theorie verstehen: AES, RSA, elliptische Kurvenoperationen oder authentifizierte Verschlüsselung in produktivem Code korrekt zu implementieren, ist äußerst schwierig und das Risiko im Vergleich zur Verwendung einer bewährten Bibliothek fast nie wert.

Welcher Faktor ist bei der Bewertung einer kryptografischen Bibliothek für ein neues Projekt am wichtigsten?

Checkliste für die Bibliotheksauswahl: Prüfen Sie Umfang und Bericht eines aktuellen unabhängigen Audits, untersuchen Sie den CVE-Verlauf und die Reaktionszeit bei Patches, vergewissern Sie sich, dass die Bibliothek aktiv gewartet wird und die Community sich engagiert, bevorzugen Sie kleinere APIs, die Fehlgebrauch erschweren, bestätigen Sie Garantien für konstante Laufzeit bei sensiblen Operationen, stellen Sie die Unterstützung moderner Algorithmen sicher, bewerten Sie die Abhängigkeiten in der Software-Lieferkette, prüfen Sie bei regulierten Anwendungen die FIPS-Validierung, berücksichtigen Sie das Risiko einer Bindung an einen KMS-Anbieter und verwenden Sie immer etablierte Bibliotheken, statt Primitive selbst zu implementieren.