Eintrittsprävention: Erschweren der Systemanalyse / Reverse Engineering

Auch die Erfahrungen aus anderen Wirtschaftszweigen zeigen, dass präventive Schutzvor-kehrungen von (teils ebenfalls eingebetteten) IT-Systemen trotz umfangreich betriebenen Entwicklungsaufwands in vielen Fällen im Laufe des Produktlebenszyklus umgangen oder gebrochen werden. Ein Beispiel sind teils technisch tiefgreifende Verfahren, die oft als

„Jailbreaking“ oder „rooting“ bezeichnet werden und i.d.R. die Installation beliebiger Software ermöglichen. Entsprechende Eingriffe wurden in der Vergangenheit z.B. bereits für diverse Smartphones, Spielkonsolen oder TV-Geräte verschiedener Hersteller umgesetzt (siehe z.B.

[Kuri13], [KrLa10] und [Beck14]). Auch Geldautomaten sollen bereits in mehreren Fällen ge-zielt mit maßgeschneidertem Schadcode infiziert worden sein [TwSb13].

Selbst Systeme mit fehlerfrei implementierten Schutzkonzepten gegen die Installation unau-torisierter Software bieten keine absolute Sicherheit gegen die Installation von Malware. So konnten in der Praxis bereits mehrfach funktionale Software-Signaturprüfungen umgangen werden. Hierzu gelang es Angreifern z.B., die zugehörigen Signaturschlüssel aus IT-Systemen der Herstellers zu entwenden [Shin13] oder – falls dies z.B. aufgrund der Speiche-rung in sicheren Hardwaremodulen nicht möglich ist – die zu signierende Schadsoftware durch kompromittierte interne Entwicklungsserver zu schleusen, die zu Code-Signing-Anfragen berechtigt sind [Schm12].

be-reits zu beobachten sind. Einige Beispiele diesbezüglicher Strategien, die sich im erforderli-chen Aufwand sowie ihrer Wirksamkeit teils unterscheiden, werden im Folgenden kompakt vorgestellt und diskutiert.

Erschweren des physischen Zugangs zum Geräteinneren

Über Maßnahmen, die vom Einsatz spezieller Schrauben bis hin zu physischem Verplomben oder Verkleben des Gerätegehäuses reichen, kann einem Angreifer bereits das Öffnen zu-mindest deutlich erschwert werden (siehe z.B. Abschnitt „tamper resistance“ in [Wolf09]).

Darüber hinaus können entsprechende Maßnahmen gezielt so eingesetzt werden, dass das Gerät bei einer unautorisierten Öffnung beschädigt wird oder man diese über detektive Maß-nahmen wie sog. „tamper switches“ [BaCa05] erkennen kann.

Erschweren der Analyse des inneren Geräteaufbaus

Über diverse weitere Ansätze kann zudem versucht werden, die Analyse eines bereits geöff-neten Geräts zu erschweren. Häufig versuchen Angreifer zunächst, die auf der Leiterplatte eingesetzten Chips zu identifizieren, was i.d.R. leicht anhand der aufgedruckten Typenbe-zeichnung möglich ist. Um den Aufwand zu erhöhen, kann der Gerätehersteller diese im Produktionsprozess unkenntlich machen (z.B. durch Abschleifen) oder von vornherein Chip-Chargen mit kundenspezifischen Aufdrucken ordern. Auch beim Layout und der Fertigung der Platine selbst können Maßnahmen zur Erschwerung der nachträglichen Analyse getrof-fen werden, z.B. durch Verwendung mehrer Lagen, durch Plazieren unnötiger bzw. irrefüh-render Leiterbahnen und Durchkontaktierungen, oder durch Vergießen/Versiegeln sensibler Platinenbereiche z.B. mit Epoxidharz (vgl. z.B. [BaCa05]).

Erschweren des logischen Zugriffs auf Speicherinhalte

Ausgehend von einem identifizierten Chip kann ein Angreifer häufig öffentlich zugängliche Dokumentation (z.B. im Internet verfügbare Datenblätter) nutzen, um unabhängig von der eigentlichen Gerätefunktionalität direkt mit vorhandenen Chips zu kommunizieren. Ein we-sentliches Angriffsziel hierbei stellt die Extraktion und Auswertung darauf gespeicherter Da-ten dar. Um dies zu verhindern bzw. zu erschweren, kommen für den Gerätehersteller ver-schiedene Maßnahmen infrage.

Einige davon adressieren das Problem, dass über Debugschnittstellen, die von vielen Mikro-controllern bereitgestellt werden (vgl. Abschnitt 2.4.5) vielfach auch Zugriffe auf die internen Speicher möglich sind. Auf für die Serie produzierten Geräten sollten entsprechende Schnitt-stellen daher weder auf spezielle Stecker oder sonstige Kontaktpunkte auf der Platine aus-geführt sein. Zudem sollten ggf. vom Mikrocontroller gebotene Deaktivierungsmöglichkeiten genutzt werden oder andernfalls physische Vorkehrungen getroffen werden, dass auch ein direkter Zugriff an den zugehörigen Pins des Mikrocontrollers nicht möglich ist.

Eine spezielle Problematik stellen externe Speicherchips dar, da ein Angreifer auf enthaltene Daten (ggf. nach temporärem Auslöten) häufig direkt und uneingeschränkt zugreifen kann.

Um auch die Analyse dort vorhandener Speicherinhalte zu erschweren, kann z.B. versucht werden, deren logische Ordnung z.B. über Verwürfelung aufzuheben oder sie über Chip-externe Maßnahmen hard- oder softwarebasiert zu verschlüsseln. Besonders schützenswer-te Daschützenswer-ten wie z.B. kryptographische Schlüssel sollschützenswer-ten nach Möglichkeit nur auf sicherer Hardware vorgehalten werden (siehe z.B. Forschungsaktivitäten aus Abschnitt 2.5.3).

Erschweren von Codeanalyse

Um dem Angreifer nach Möglichkeit auch die Analyse von Binärcode des betrachteten Ge-räts möglichst zu erschweren, an den er ggf. auch aus anderen Quellen (z.B. Softwareup-dates, vgl. Abschnitt 6.4.1) gelangen kann, bestehen ebenfalls verschiedene Optionen.

Ein vielfach auch für Angreifer hilfreicher Ansatzpunkt sind aus dem Programmcode referen-zierte Strings (Zeichenketten) z.B. zu Debugausgaben. Aus diesen lässt sich häufig die Funktionalität der umliegenden Funktionen ableiten, teils sogar mit Angabe von Funktions- und Variablennamen, die ansonsten dem kompilierten Code nicht mehr entnehmbar sind.

Derartige Ausgaben sollten aus Softwareversionen, die für Endnutzersysteme freigegeben werden, nach Möglichkeit komplett entfernt oder in ihrer Aussagekraft reduziert werden (z.B.

Ersetzen durch numerische Ereigniskennungen).

Um den Aufwand zur Analyse des Binärcodes weiter zu erhöhen, können darüber hinaus Techniken zur Verschleierung (obfuscation) eingesetzt werden. Ziel hierbei ist, den zu er-zeugenden Code unter Beinbehaltung seiner Funktionalität in eine für Menschen möglichst schwer verständliche Form zu überführen. Insbesondere in der Desktop-IT wurde bereits eine Vielzahl entsprechender Techniken und Werkzeuge entwickelt (siehe z.B. Kapitel 5 von [DaGB14]), die sich auf verschiedenen Ebenen (Quellcode, Zwischencode, Binärcode) an-wenden und z.B. Zielen wie Antidisassembly, Antidebugging und Antiemulation [Szor05] zu-ordnen lassen. Auch kommerziell vertriebene Obfuscation-Produkte greifen somit auf Tech-niken zurück, die nach [SkZe03] auch Schadcodeautoren häufig in gleicher oder ähnlicher Form zum Schutz ihrer "Produkte" einsetzen. Grundsätzlich könnte ein Einsatz entsprechen-der Techniken auch für Software auf eingebetteten IT-Systemen erwogen werden, sofern sie mit dort ggf. vorhandenen Ressourcenbeschränkungen sowie Echtzeitanforderungen (Ab-schnitt 2.4.3) vereinbar sind.

Erschweren der Analyse von Seitenkanälen

Eine besondere Herausforderung stellen teils technisch anspruchsvolle Angriffe dar, die auf dem Auswerten von Seitenkanälen basieren um an geheime Informationen wie z.B. kryptog-raphische Schlüssel zu gelangen. Technische Ansatzpunkte für diese sog. Seitenkanalan-griffe (engl.: side channel attacks, siehe z.B. [PaPe10] und [Wolf09]) stellen z.B. das Messen und Auswerten von Ausführungszeiten, Energieverbrauch oder elektromagnetischen Ab-strahlungen dar. Diese Größen sind häufig mit den gegenwärtig durchgeführten Berechnun-gen korreliert und können teils ausBerechnun-genutzt werden, um z.B. auf verwendete Parameter zu-rückzuschließen. Um Seitenkanalangriffe zu erschweren – d.h. die Erfolgsaussichten bzw.

den zu erwartenden Umfang verwertbarer Erkenntnisse zu minimieren – sind verschiedene Herangehensweisen und Techniken möglich [Smit14]. Beispielhafte Ansätze sind die Reduk-tion der InformaReduk-tionslecks (z.B. bzgl. Menge oder Reichweite/Messbarkeit entweichender Informationen) oder die Dekorrelation mit den sensitiven Geheimnissen (z.B. durch Hinzufü-gen künstlichen Rauschens). Auch durch gezielten Einsatz von o.g. Obfuscation-Strategien in der eingesetzten Programmlogik – wie z.B. das Einstreuen nutzloser Befehle – kann dafür gesorgt werden, dass in der Analyse diejenigen Stellen der auszuwertenden Abstrahlung deutlich schwieriger identifizierbar bzw. zuordenbar sind, die einen Bezug zu den relevanten Berechnungen aufweisen.

Reduktion der Angriffsfläche

Vielfach ist es angesichts diverser Angriffsvektoren unpraktikabel, ein gesamtes System (hier z.B.: Steuergerät) gegen unautorisierte physische Eingriffe abzuschotten, die teils mit hohem technischen und finanziellen Aufwand durchgeführt werden. Diese Tatsache wird gezielt durch eine weitere Strategie adressiert, bei der versucht wird, die Sicherheit eines komple-xen Gesamtsystems an die Sicherheit einer funktional eng umrissenen Teilkomponente zu binden, die speziell abgesichert wird.

In anderen Bereichen der Industrie werden z.B. Smartcards eingesetzt, die dafür entwickelt wurden, ebenfalls in unkontrollierten Umgebungen zum Einsatz kommen zu können. Unter anderem müssen sie in den Bereichen des Bezahlfernsehens, auf Bankkarten, in Mobiltele-fonen und in Ausweisdokumenten gegen verschiedene Angreifer Schutz bieten. Als eine gängige Schutzmaßnahme kommen in Smartcards z.B. direkt in die Chipoberfläche einge-brachte Geflechte von Sensorikelementen zum Einsatz. Mit ihrer Hilfe können invasive Zu-griffsversuche auf interne Leiterbahnen (die z.B. durch Mikrosonden erfolgen) erkannt und Reaktionen eingeleitet werden können (z.B. das Löschen sensitiver Informationen). Ausführ-liche Beispiele für weitere Angriffsstrategien sowie Designprinzipien, die Smartcards zugrun-degelegt werden können, können [KöKu99] entnommen werden.

Dass das Verfolgen dieser Strategie zunehmend auch im automotiven Bereich sinnvoll ist, zeigt der bereits z.T. auch hier beobachtbare Trend, die Sicherheit eines Geräts auf einen kompakten Sicherheitsanker mit speziellen Schutzfunktionen zu stützen. Darin abgelegte Informationen, z.B. sensibles kryptographisches Schlüsselmaterial ist besonders gut gegen unautorisierte, auch physisch-invasive Eingriffe geschützt. Die sicheren Hardwarekomponen-ten, die in Abschnitt 2.5 zum Stand der automotiven Technik und Forschung genannt werden, sind als einige Beispiele zu nennen, welche dieses Ziel verfolgen.

Diskussion

Die Auswahl aus entsprechenden Maßnahmen zum Erschweren der Systemanalyse sollte grundsätzlich mit Bedacht erfolgen. Für diese Zielstellung bestimmte Ansätze wie die oben vorgestellten sind zwar grundsätzlich geeignet, den erforderlichen Aufwand des Angreifers (unterschiedlich stark) zu erhöhen. Bei einer kritischen Diskussion zeigt sich jedoch schnell, dass viele von Ihnen dem in Abschnitt 2.1.5 vorgestellten Security-by-Obscurity-Prinzip ba-sieren, d.h. dem „principle of open design“ widersprechen. Eine vorschnelle, nicht ausrei-chend durchdachte Entscheidung für entspreausrei-chende Maßnahmen birgt daher durchaus Risi-ken – zumal der Aufwand zur Informationsbeschaffung bei einer worst-case-Betrachtung nur einmalig durch einen einzigen Angreifer erbracht werden muss, um anschließend durch be-liebige weitere Angreifer für bebe-liebige weitere Zielsysteme nutzbar zu sein. Wie es die in Ab-schnitt 2.1.5 angerissene Diskussion andeutet, kann der Einsatz solcher Maßnahmen den-noch eine sinnvolle und zu rechtfertigende Entscheidung darstellen. So schreibt z.B. auch Claudia Eckert zum Einsatz von Verschleierungstechniken beim Chipdesign von Smartcards:

Diese Maßnahmen zählen zu der eigentlich abzulehnenden Technik des Schutzes „security through obscurity“. Da sie hier aber nur begleitenden Schutzcharakter haben und die Sicherheit nicht allein auf der Verschleie-rung beruht, sind sie als sinnvolle Ergänzungen zu sehen.

Aus Abschnitt 10.3.2 in [Ecke08]

Sofern die Ergebnisse einer Systemanalyse dem Angreifer z.B. aufgrund eines sicherheits-bewussten Systemdesigns (Abschnitte 5.1.3 und 5.1.4) ohnehin keine verwertbaren Er-kenntnisse liefern, stellt die gezielte Erhöhung des Analyseaufwands somit durchaus eine sinnvolle ergänzende Sicherheitsmaßnahme dar: Die von den Angreifern zur Überwindung zusätzlicher Hürden aufzuwendenden (Zeit-)Ressourcen gehen diesen gleichzeitig für an-derweitige Angriffsaktivitäten verloren.