Ziele und Vorgehen

Ziel des Projektes „Generierung seitenkanalfreier Software für eingebettete Systeme“ (FreeSBee) ist es, eine werkzeuggestützte Methodik zu erforschen, um Schwachstellen basierend auf Timing-Seitenkanälen (teil-)automatisiert zu erkennen und zu beheben.

Dazu werden zunächst vertrauliche Informationen, beispielsweise geheime Schlüssel oder Codeabschnitte, im Quellcode per Annotationen markiert, um alle Stellen im Code ausfindig zu machen, die potenziell einen Seitenkanalangriff zur Folge haben können. Nach der übersetzung der Software in Maschinensprache werden härtende Codetransformationen angewendet, damit die Ausführungszeit dieser Codestellen unabhängig von vertraulichen Informationen wird. Als Ergebnis können ganze Klassen von Sicherheitslücken in IoT-Systemen verhindert werden.

Die folgende Abbildung zeigt die in FreeSBee angedachten Transformationen zur (teil-)automatisierten Härtung gegen Timing-Angriffe. Diese Transformationen können in drei Phasen unterteilt werden, die sich an den Phasen traditioneller Compiler orientieren.

Front-End

Im Front-End werden Annotationen und Transformationen auf dem Quellcode durchgeführt. Hierzu markieren („annotieren“) die Anwender Deklarationen vertraulicher Informationen mit der im Projekt entwickelten Sprache „Source Code Annotations“. Der annotierte Quellcode ist der Ausgangspunkt für das automatisierte Härten der Software.

Das Framework nutzt statische Quellcodeanalysen, insbesondere eine erweiterte Taint-Analyse, zur Bestimmung von Informationsflüssen der gekennzeichneten vertraulichen Informationen. Hierzu wird unter anderem das Werkzeug Astrée des Partners AbsInt zum Einsatz kommen, welches die statische Analyse von C- und C++-Programmen ermöglicht.

Auch Werkzeuge, die auf dem LLVM/Clang-Framework aufbauen, sollen im Rahmen des Projektes berücksichtigt werden. Im Fokus stehen statische Analyseverfahren, um alle Ausführungspfade abzudecken (engl. „path coverage“) und um datenunabhängig zu bleiben, was insbesondere die Detektion von impliziten Datenflüssen verbessert.

Um Nachteile der statischen Analyse auszugleichen – beispielsweise ein „Over-Tainting“ zu vermeiden –, sollen ergänzend dynamische Verfahren und Werkzeuge einbezogen werden, wie z. B.

Diese sollen aber nur unterstützend verwendet werden. Die Ergebnisse der Analyse werden mittels Code-Transformationen in Form von Annotationen in den Quellcode zurückgeführt. Resultat dieser ersten Phase ist Quellcode, in dem alle potentiellen Ursachen von Laufzeitvarianzen, die von sensiblen Daten abhängen, markiert sind. Die Anwender*innen können den annotierten Code überprüfen beziehungsweise manuell anpassen.

Middle-End

Im Middle-End wird der annotierte Quellcode in das für den Compiler spezifische Zwischenformat (IR, engl. „intermediate representation“) übersetzt.

Alle kritischen Stellen, beispielsweise Sprünge abhängig von sensitiven Daten, sind basierend auf den Transformationen und der Datenflussanalyse aus dem Front-End im Quellcode annotiert. Diese Annotation werden ins Zwischenformat mit übernommen und die entsprechenden Stellen, bzw. die daraus resultierenden Timing-Seitenkanäle, durch entsprechende Transformationen aufgehoben.

Im Middle-End werden auf dem plattformunabhängigen Zwischenformat erste Härtungsschritte durchgeführt. Alle kontrollflußbasierten Laufzeitvarianzen werden durch Ersetzung betreffender Konstrukte aufgelöst. Hierzu wird im Projekt eine entsprechende Bibliothek mit Code-Mustern entwickelt, welche auch bei Datenabhängigkeiten eine konstante Ausführungszeit garantieren.

Neben allgemein anwendbaren Patterns sollen im Projekt auch datenabhängige Muster auf Basis der beispielsweise zuvor über statische Analysen ermittelten Wertebereiche angewendet werden. Dies dient der Behebung datenflussbasierter Laufzeitvarianzen. In diese Kategorie fallen Mechanismen zum Bereinigen von Cache-Einträgen oder die Zuweisung von Daten zu „non-cacheable“ oder „volatilen“ Variablen.

Einige Laufzeitvarianzen sind jedoch plattformabhängig und können daher effektiv nur in der folgenden, dritten Phase behoben werden.

Back-End

Die Back-End-Phase operiert auf einem plattformabhängigen Zwischenformat unter Einbeziehung von Informationen über die konkrete Zielplattform.

Auch in dieser Phase erhält die übersetzung der Zwischenformate die ursprünglichen Annotationen aus der Front-End-Analyse. Annotierte Codestellen, die in der Middle-End-Phase nicht behoben werden konnten bzw. an die Back-End-Phase weitergeleitet wurden, werden nun behandelt.

Die automatisierte Härtung gegen datenabhängige Laufzeitvarianzen erfolgt anhand plattformspezifischer Ersetzungsmuster. Diese Muster sind in der „Platform Dependent Transformation Library“ gespeichert, welche für jede Plattform neu erzeugt werden muß. Die Demonstration erfolgt für eine RISC-V-basierte Hardware-Plattform, die mithilfe des Rocket-Chip-Generator-Ansatzes erzeugt wird.

Im letzten Schritt wird der gehärtete Code mittels semantikerhaltender Binärcode-Generierung übersetzt. Das Ergebnis ist ein gegen Timing-Angriffe gehärtetes ausführbares Binary für eine gegebene Hardware-Zielplattform.

Da in der Back-End-Phase plattformabhängige Timing-Seitenkanäle behoben werden, muß diese Stufe bei einem Wechsel der Plattform erneut durchlaufen werden. Bei der Nutzung des Front- und Middle-Ends bietet das FreeSBee-Framework jedoch die Möglichkeit, eine hardwareunabhängige Teilhärtung durchzuführen.