Protecting Cryptographic Libraries against Side-Channel and Code-Reuse Attacks
Dieser Beitrag analysiert die Sicherheitslücken populärer kryptografischer Bibliotheken gegenüber Seitenkanal- und Speicherbeschädigungsangriffen, bewertet deren aktuelle Schutzmaßnahmen und schlägt Verbesserungen für deren Entwicklungsprozesse vor.
Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen
Stellen Sie sich kryptografische Bibliotheken als die High-Tech-Tresore des Internets vor. Sie sind die Softwarewerkzeuge, die Ihre Passwörter verschließen, Ihre Nachrichten verschlüsseln und Ihre Identität verifizieren. Ohne sie wäre unsere digitale Welt weit offen. Diese Arbeit argumentiert jedoch, dass selbst die besten Tresore Schwachstellen haben und dass die Menschen, die sie bauen (die Entwickler), sowie die Werkzeuge, die sie dafür verwenden (die Compiler), nicht immer genug tun, um sie zu schützen.
Hier ist eine Aufschlüsselung der Hauptpunkte der Arbeit unter Verwendung einfacher Analogien.
1. Die zwei Arten von Dieben
Die Arbeit identifiziert zwei Hauptwege, auf denen Angreifer versuchen, in diese digitalen Tresore einzubrechen:
Der „Stoppuhr-Dieb" (Seitenkanalangriffe):
Stellen Sie sich einen Dieb vor, der nicht versucht, das Schloss zu knacken. Stattdessen steht er außerhalb des Tresors und lauscht. Er bemerkt, dass es dem Tresor ein leicht längeres dauert, bis die Tür zugeklappt ist, wenn der Wächter einen bestimmten Schlüssel versucht, als wenn er einen falschen Schlüssel versucht. Indem er diese winzigen Unterschiede misst, kann der Dieb den Geheimcode herausfinden, ohne das Schloss jemals zu berühren.- Der Punkt der Arbeit: Kryptografischer Code enthält oft „geheimnisabhängige" Schritte. Wenn der Code je nach einem geheimen Passwort unterschiedlich lange zur Ausführung benötigt, kann ein Hacker mit einer Stoppuhr dieses Passwort stehlen.
Der „Copy-Paste-Entführer" (Code-Wiederverwendungsangriffe):
Stellen Sie sich eine Bibliothek vor, in der die Bücher in einer unordentlichen, unsicheren Sprache geschrieben sind. Ein Dieb findet ein Loch im Boden (einen Speicherfehler) und wirft eine Bombe, die die Dielen aufbricht. Sobald der Boden gebrochen ist, muss der Dieb keine neue Waffe bauen; er nimmt einfach einen Hammer, eine Säge und eine Leiter, die bereits im Lagerraum der Bibliothek standen. Er „näht" diese vorhandenen Werkzeuge zusammen, um hinauszuklettern und das Gebäude zu übernehmen.- Der Punkt der Arbeit: Viele Bibliotheken sind in Sprachen wie C oder C++ geschrieben, die Speicherfehler zulassen. Hacker nutzen diese Fehler, um den Programmfluss zu entführen, indem sie kleine, harmlose Code-Stücke, die bereits in der Bibliothek enthalten sind, nutzen, um einen massiven Angriff zu starten.
2. Der aktuelle Zustand des Tresors
Die Autoren untersuchten 11 beliebte kryptografische Bibliotheken (wie OpenSSL, das von Millionen Websites verwendet wird), um zu sehen, wie gut sie geschützt sind.
- Das „Stoppuhr"-Problem: Die meisten Entwickler kennen Timing-Angriffe und versuchen, sie zu beheben, indem sie Code schreiben, der unabhängig davon, was passiert, genau die gleiche Ausführungszeit benötigt. Die Arbeit ergab jedoch, dass nur 2 von 11 Bibliotheken ihr Endprodukt tatsächlich testen, um sicherzustellen, dass der „Stoppuhr"-Trick nicht funktioniert. Es ist wie ein Koch, der die Suppe vor dem Servieren probiert, aber vergisst zu prüfen, ob das Salz tatsächlich aufgelöst ist.
- Das „Copy-Paste"-Problem: Entwickler verwenden Standard-Sicherheitstools (wie „Stack-Canaries", die wie Fallstricke funktionieren), um Speicherfehler zu stoppen. Obwohl diese helfen, sind sie nicht perfekt. Die Arbeit ergab, dass die meisten Bibliotheken nicht die stärksten verfügbaren Sicherheitseinstellungen verwenden, was sie anfällig für raffinierte Entführungen macht.
3. Der defekte Bauplan (Das Compiler-Problem)
Dies ist der Kern des Arguments der Arbeit. Entwickler schreiben den Code (den Bauplan), aber ein Compiler ist die Maschine, die diesen Bauplan in den tatsächlichen funktionierenden Maschinencode übersetzt.
- Der Konflikt: Compiler sind darauf ausgelegt, Code schnell und effizient zu machen. Sie sind wie ein sehr eifriger Redakteur, der jeden „Ballast" streichen will, um die Geschichte kürzer zu machen.
- Der Fehler: Manchmal ist der „Ballast", den der Compiler streicht, tatsächlich eine Sicherheitsmaßnahme. Zum Beispiel schreibt ein Entwickler zusätzlichen Code, um sicherzustellen, dass ein Prozess die gleiche Zeit benötigt (um den Stoppuhr-Dieb zu stoppen). Der Compiler, der denkt, dieser zusätzliche Code sei nutzloser Abfall, löscht ihn. Das Ergebnis? Der Code ist wieder schnell, aber das Sicherheitsloch ist zurück.
4. Neue Werkzeuge für den Job (Sichere Kompilierung)
Die Arbeit schlägt vor, dass wir eine neue Art von „Redakteur" oder Compiler benötigen, der Sicherheit genauso gut versteht wie Geschwindigkeit. Sie testeten vier verschiedene experimentelle Werkzeuge:
- Der „Wächter" (SecComp): Dieses Tool ermöglicht es Entwicklern, bestimmte Teile des Codes als „nicht anfassen" zu markieren. Es zwingt den Compiler, die Sicherheitsmaßnahmen an Ort und Stelle zu lassen. Nachteil: Es ist noch nicht kostenlos nutzbar.
- Der „Mischer" (Multicompiler/MCR): Dieses Tool nimmt den Code und räumt die Möbel jedes Mal neu auf, wenn es das Programm erstellt. Es ist wie das Verschieben von Hammer und Säge in verschiedene Räume jeden Tag. Wenn ein Dieb einbricht, kann er die benötigten Werkzeuge nicht finden, weil sich das Layout geändert hat. Nachteil: Es verlangsamt das Programm erheblich, wenn es verwendet wird, um den „Stoppuhr-Dieb" zu stoppen.
- Der „Architekt" (SecDivCon): Dieses Tool baut den Code mit Sicherheitsregeln, die von Anfang an eingearbeitet sind, und stellt sicher, dass das Endprodukt sowohl schnell als auch sicher ist. Nachteil: Der Bau dauert sehr lange und funktioniert nur gut für kleine, spezifische Aufgaben.
- Der „Linearisierer" (PCFL): Dieses Tool schreibt unordentlichen Code automatisch in eine gerade, vorhersehbare Linie um, die unmöglich zu timen ist. Nachteil: Es stoppt keine „Copy-Paste-Entführer"-Angriffe.
5. Das endgültige Urteil
Die Arbeit kommt zu dem Schluss, dass wir derzeit in einer Lücke zwischen Geschwindigkeit und Sicherheit feststecken.
- Entwickler versuchen, sichereren Code manuell zu schreiben, verfehlen aber oft das Ziel.
- Compiler sind zu sehr auf Geschwindigkeit fokussiert und löschen versehentlich Sicherheitsfunktionen.
- Aktuelle Tools sind entweder zu langsam, zu komplex oder decken nicht alle Arten von Angriffen ab.
Die Lösung: Die Autoren fordern eine dreiseitige Anstrengung:
- Compiler-Hersteller müssen Entwicklern mehr Kontrolle geben, damit sie sagen können: „Löschen Sie diese Sicherheitsfunktion nicht, auch wenn sie langsam aussieht."
- Hersteller sicherer Compiler müssen Werkzeuge entwickeln, die sowohl Timing- als auch Entführungsangriffe gleichzeitig behandeln, nicht nur den einen oder den anderen.
- Bibliotheks-Entwickler müssen aufhören, auf Hoffnung zu setzen, und beginnen, diese neuen, sichereren Kompilierungstools zu verwenden, um sicherzustellen, dass ihre Tresore wirklich verschlossen sind.
Kurz gesagt: Wir haben die Baupläne für sichere Tresore, aber die Maschinen, die sie bauen, sind zu eifrig, um Abkürzungen zu nehmen. Wir müssen die Maschinen lehren, Sicherheit genauso zu priorisieren wie Geschwindigkeit.
Ertrinken Sie in Arbeiten in Ihrem Fachgebiet?
Erhalten Sie tägliche Digests der neuesten Arbeiten passend zu Ihren Forschungsbegriffen — mit technischen Zusammenfassungen, in Ihrer Sprache.