Managament , Fachartikel

Sichere Systeme – Security beim Hardwaredesign

Sichere Systeme – Security beim Hardwaredesign

Beim Design von sicheren Systemen wird oft die Sichtweise auf die Hardware vergessen. Dadurch sind diese Geräte anfällig für Hacker-Attacken und anfällig für Datenverlust. Es sind Vorgehensmodelle, aber auch die kleineren Dinge, die bei einer Entwicklung bzw. bei der späteren Produktauswahl beachtet werden sollten.

Als eines der kritischen Systeme ist unser Straßenverkehr zu sehen. Jeder kennt es: In dicht besiedelten und infrastrukturell gut ausgestatteten Regionen reicht ein Kfz mit Defekt, um große Teile des Straßenverkehrs zu stören oder gar zum Erliegen zu bringen. Dies, und vorrangig die Personen-Sicherheit, sind die Gründe, weshalb in diesem kritischen (chaotischen) System die Hardware – unsere Kfz – alle zwei Jahre zur Hauptuntersuchung müssen. Ohne die bestandene Prüfung gibt es keine Betriebserlaubnis in diesem fragilen System.

Das ist nur eine der – vom Bundesministerium des Inneren (BMI) – definierten kritischen Infrastrukturen. Warum wird aber bei den kritischen Infrastrukturen im Sektor Informationstechnik – insbesondere in Steuerungsanlagen für Energie (Elektrizität, Gas, Mineralöl) – der Hardware wenig bis nahezu keine Beachtung gewidmet?  

Prozesse, Abläufe und Software sowie deren Parametrierung besitzen hohen Stellenwert in Bezug auf IT-Sicherheit. Gleiches gilt jedoch nicht für die, aus sehr vielen Einzelteilen zusammengefügte, Hardware. Es ist nahezu unmöglich nachzuvollziehen, woher diese Einzelteile stammen und wie diese genau funktionieren. Recht schnell kommt man zu der Frage, ob auch wirklich nur die benötigten Bauteile verbaut sind und dadurch das Minimalprinzip – eine strikte Forderung für Informationssicherheit im Bereich Software – auch eingehalten wird.

Als Endkunde, Betreiber und Entwickler von Hardware-Produkten ist es das Beste, was wir tun können, ein Verständnis für mögliche Angriffe auf das System in Hinblick auf die Hardware zu bekommen. Es ist essentiell wichtig zu verstehen, dass Security keine „App“ oder ein nachträglich zugefügtes „Feature“ ist. Ein System muss von Grund auf mit der Anforderung „Sicherheit“ geplant, konstruiert und gefertigt werden.

Mit genügender Motivation, Gelegenheit und Fähigkeiten kann ein Angreifer jedes beliebige System brechen. Sicherheit ist ein Prozess, kein Produkt. Sicherheit muss grundsätzlich schon während der Konzeptphase in ein Produkt eingebracht und für jeden Teil des Entwurfs berücksichtigt werden.

Lösungen für den Betrieb und die Überwachung von kritischen Systemen sollten darum mit dem Hauptanliegen der Sicherheit von Grund auf entworfen werden.

Das NIST (National Institute of Standards and Technology) hat mit den „Engineering Principles for Information Technology Security“ [1] ein Dokument veröffentlicht, welches Sicherheitsprinzipien zur Verfügung stellt, die für alle Phasen eines Produkt-Designs angewendet werden sollten:

Sicherheitsrichtlinie für das Systemdesign. Die Sicherheitsrichtlinie identifiziert Ziele für das Systemdesign und unterstützt und definiert die Verfahren, Standards und Kontrollen des Entwicklungszyklus.

Sicherheit als Integraler Bestandteil für das gesamte Systemdesign und den Entwicklungsprozess. Es ist sehr schwer, Sicherheitsmaßnahmen nach einer fertigen Systementwicklung nachträglich einzufügen.

Risikoreduzierung auf ein akzeptables Niveau. Ein Risiko ist immer eine Kombination aus der Wahrscheinlichkeit, dass eine Bedrohung für einen Angriff ausgenutzt wird und aus den daraus resultierenden Auswirkungen. Eine Beseitigung aller Risiken ist faktisch nicht möglich, jedoch muss eine wahrscheinlichkeitsbasierte Kosten-Nutzen-Analyse für jede Funktion bei der Entwicklung von sicherer Hardware durchgeführt werden.

Mehrstufige Sicherheit: Es sollten Systeme entworfen werden, die mehrschichtige Sicherheitsmechanismen und keine Single-Point-of-Failures enthalten.

Einfachheit: Je komplexer Mechanismen sind, desto eher können diese ausnutzbare Lücken enthalten. Einfache Mechanismen und Designs haben tendenziell weniger ausnutzbare Schwachstellen und benötigen zudem auch weniger administrativen Aufwand.

Minimalprinzip: Die Anzahl der Mechanismen, denen zu vertrauen ist, sollte minimiert werden. Es ist einfacher, nur einen Sicherheitsbereich zu überschauen und zu kontrollieren, als eine Vielzahl von Bereichen – auch während des Systementwurfs und beim Hardware-Layout.
Dieser Grundsatz beinhaltet auch, nur die minimal notwendigen Funktionen zu implementieren und das Hardware-Design nicht mit überflüssigen Marketing-Features auszustatten. Als Nebenprodukt vereinfacht dieser Grundsatz auch den Systemtest.

Keine Marketing-Sicherheitsmechanismen. Jeder implementierte Sicherheitsmechanismus sollte das Ergebnis eines zuvor definierten Sicherheits-Ziels sein. Zusätzlich implementierte Mechanismen erhöhen die Komplexität und damit die Wahrscheinlichkeit möglicher Lücken.

Oft werden auch ohne erneute Beachtung der Auswirkung auf die Systemsicherheit Änderungen an einem Produkt, zum Beispiel dem Hardware-Layout oder der Firmware, durchgeführt. Dieser Prozess, selbst bei kleinen Änderungen am Design die Systemsicherheit zu beachten und zu überprüfen, ist leider allzu oft ein Opfer der finanziellen und zeitlichen „Optimierung“ von Produktentwicklung und Produktion.

Welche Angriffsvektoren gibt es auf der Hardware-Ebene?

Denkbar sind die verschiedensten Angriffsszenarien und Angriffsvektoren auf der Hardware-Ebene. Nach Pfleeger’s „Security in Computing“ [2] ist eine Einteilung in vier Klassen gegeben:

1. Abhören: Der Zugang zu geschützten Informationen ohne Öffnen des Gerätes, beispielsweise das klassische Sniffing über ein Netzwerk.
Beim Systemdesign könnte dies durch die Überwachung der externen Schnittstellen des Gerätes oder durch die Analyse von elektromagnetischen Strahlen, Schwankungen innerhalb der Stromversorgung oder des Protokoll-Timings erkannt werden. Problematisch ist die fast unmögliche nachträgliche Erkennung.

2. Unterbrechung: Beispiele hierfür sind der Denial-of-Service-Angriff, eine böswillige Zerstörung oder auch Einwirkungen durch höhere Gewalt.

3. Manipulation und Modifikation der Hardware, zum Beispiel Änderung des Schaltungsdesigns oder das Einbringen von „neuen“ Bauelementen. Diese Manipulationen sind teilweise schwer zu erkennen – erst recht, wenn diese bei der Produktion erfolgt sind.

4. Fabrikation hat eine Schnittmenge mit der zuvor beschriebenen Manipulation. Die Änderung eines Gerätes bei der Fabrikation ist äußerst schwer zu erkennen. Diese Änderungen können ausschließlich durch eine Überprüfung der Hardware durch entsprechende System-/Test-Software erkannt werden.

<next>

 

Was ist bei der Hardware-Entwicklung zu beachten?

Die Hardware-Entwicklung ist generell in drei Ebenen zu kategorisieren. Das Gehäuse, das Platinen-Layout und die Firmware. Die Absicherung eines Systems sollte auch in dieser Reihenfolge erfolgen.

Das Design eines sicheren Produktgehäuses ist entscheidend dabei, ob und wie ein Angreifer Zugriff auf die internen Schaltkreise eines Gerätes erlangt. Ist das Öffnen eines Gehäuses nicht erkennbar, stellt ein Reverse Engineering eine einfache Methode zur Informationsgewinnung und einer möglichen Manipulation dar. Gerade bei Embedded-Geräten sollte ein Produktgehäuse entwickelt werden, welches nur mit Service-Werkzeugen zu öffnen ist, so dass jegliche Manipulation am Gehäuse direkt erkannt werden kann. Dies stellt auch keinen ausreichenden Schutz sondern nur eine Hürde dar, da Service-Werkzeuge beschafft und imitiert werden kann.

Kritische Punkte bei jedem Produktgehäuse sind grundsätzlich alle Arten von Schnittstellen. Hier sollte unbedingt das Minimalprinzip angewandt werden. Nicht benötigte Programmier- oder Diagnose-Schnittstellen, wie die oft eingesetzte JTAG IEEE 1149.1 Schnittstelle, sollten auf keinen Fall von außen zugänglich sein. Ebenso sollten auch JTAG-Schnittstellen auf der Leiterplatine in der Serienproduktion vermieden werden.
 


Abbildung-1: Hier wir die JTAG-Schnittstelle eines Routers benutzt.

Auch ein Verschleiern der Programmier- und Diagnose-Schnittstellen ist kein wirklicher Schutz. Das nachfolgende Bild zeigt die Service-Schnittstelle eines RSA SecurID-Tokens. Diese ist einfach überklebt. Es wurde versucht, die Schnittstelle zu verschleiern. Jedoch ist ein Öffnen der Schnittstelle und Wiederverschließen sehr leicht möglich. Leider ist es kaum erkennbar, wenn diese Schnittstelle geöffnet und wieder verschlossen wurde.

 
Abbildung-2: Beispiel einer Verschleierung von Programmier- bzw. Diagnose-Schnittstelle eines RSA SecurID Tokens

Sollte es einem Angreifer möglich sein, sich mit einer Programmier- bzw. Diagnose-Schnittstelle zu verbinden, ist es relativ einfach, die funktionalen Zusammenhänge zu analysieren. Multimeter, Oszilloskop oder Logikanalysator ermöglichen einen schnellen Aufschluss zum Typ der Schnittstelle. Sobald die Schnittstelle bekannt ist, kann die Analyse des Datenstroms durchgeführt werden – oft vorbei an allen möglichen Sicherheits-Funktionen auf Ebene der Software.

Ein Abgriff von Informationen und unter Umständen auch von Daten über solch eine Schnittstelle ist im Nachhinein nahezu unmöglich festzustellen.

Darum ist es notwendig, Mechanismen einzubauen, welche Manipulationen am Gehäuse kenntlich machen. Dazu sind grundsätzlich vier Möglichkeiten gegeben.

  • Beständigkeit, d.h. ein mechanisch stabiles Gehäuse ähnlich einem Panzerschrank.
  • Beweissicherung durch z.B. zerbrochene innere Siegel oder Farbpatronen ähnlich der Diebstahlsicherung bei Kleidungsstücken.
  • Detektion, d.h. Erkennung, dass zum gegenwärtigen Zeitpunkt eine Manipulation stattfindet. Dies kann etwa durch Sensoren am bzw. im Gehäuse realisiert werden.
  • Die Reaktion eines Gehäuses bzw. Gerätes auf eine Manipulation kann von Löschung der Datenträger bis hin zur Selbstzerstörung der Schaltkreise in Form von durchgebrannten integrierten Sicherungen geschehen.

 

Die wirksamste Schutzmöglichkeit ist die Anwendung mehrerer dieser Stufen.

<next>



Eine Vielzahl der Schwachstellen und Sicherheitslücken eines Gerätes auf Ebene der Hardware geht auf Designfehler im Platinen-Layout zurück.

Anderson und Kuhn beschreiben in „Low Cost Attack on Tamper Resistant Devices“ [3] eine Reihe von Angriffsszenarien, welche mit sehr wenig Aufwand realisiert werden können. Beispiele sind Angriffsszenarien auf SmartCards und „sichere“ Mikrocontroller.

Einfache Szenarien reichen vom Lesen und Modifizieren des Inhalts von Mikroprozessoren oder Speicher-Modulen bis hin zum Ersatz und der Ergänzung von Bauelementen auf den Platinen.

Fortgeschrittene Szenarien reichen von Microprobing, also dem Öffnen von Chip-Gehäusen und der Analyse, bis zur Beobachtung oder Manipulation der Strukturen auf Ebene der Silizium-Chips.

 
Abbildung-3: Mit Säure geöffneter IC. Es sind sehr schön die Bondig-Drähte zu erkennen. An diese kann nun entweder direkt abgegriffen oder der Silizium-Chip photographisch weiter ausgewertet werden.

Angriffsszenarien, welche auf die Veränderungen der Betriebsumgebung, wie z.B. extreme Temperaturen, Schwankung der Versorgungsspannung oder Protokollverletzungen zielen, gehören zu den aufwendigsten Szenarien.

Die Firmware enthält typischerweise den Programmcode, um die zugrundeliegende Hardware des Systems zu steuern. Ein Auslesen und Analysieren der Firmware kann einem potentiellen Angreifer ein detailliertes Verständnis des Gerätes geben. Weiterhin könnte er die Firmware ändern und wieder einspielen. Generell sollte deshalb in jeglicher Firmware eine Authentifizierung und Integritätsprüfung möglich sein, um fremdartige Firmware abzulehnen bzw. Manipulationen zu erkennen.

Um Änderungen an der Hardware bzw. der Firmware zu erkennen, sollte eine Selbstdiagnose während des Betriebes möglich sein. Prüfsummen oder Hashes von kritischen Speicherbereichen (z.B. ROM) könnten zyklisch überprüft werden, um die Integrität der Daten sicherzustellen.

Weiterhin sollte in der Firmware die Art und Weise geregelt werden, wie auf Systemfehler reagiert wird. Das beinhaltet also auch, ob das System bei einem Fehler einen „fail open“ oder einen „fail closed“ durchführt. Die meisten Systeme sollten einen „fail closed“ durchführen, d.h. bei einem erkannten Fehler einen Stopp oder einen „shutdown“ durchführen. In Safety-Relevanten Systemen wie in der Medizintechnik, sollte bekannt sein, ob sich ein Beatmungsgerät bei einem Fehler abschaltet oder trotz eines erkannten Fehlers weiter arbeitet (es bietet sich hier ein „fail open“ an).

Die Verbreitung von „field-upgradeable hardware“, also Geräten, die nachträglich mit weiteren Features und Funktionen durch z.B. Firmwareupdates ausgestattet werden können, gibt potentiellen Angreifern weitere Gelegenheiten, ein Gerät zu manipulieren. Einige Hersteller bieten dazu auf ihren Webseiten Firmware-Aktualisierungen an, die teilweise für jeden frei zugänglich sind. Auch dies bietet einem Angreifer die Möglichkeit, sehr leicht ein Reverse-Engineering durchzuführen. Gerade eine Firmware bietet eine sehr gute Möglichkeit, in die „inneren Funktionen“ eines Gerätes zu schauen.

Hier lautet die Forderung, dass Firmware nicht für jeden frei zugänglich gemacht werden sollte. Support-Verträge oder auch ein einfacher Abgleich der System-Seriennummer oder des System-Zertifikats vor einem Download bieten zumindest einen einfachen Zugriffsschutz.

Firmware sollte zusätzlich immer mit einer Integritätsprüfung oder nach Möglichkeit in einem verschlüsselten Container ausgeliefert werden. Ein Öffnen des Containers darf dann nur auf dem Gerät mit hinterlegten Schlüsseln möglich sein.

Was sollte bei der Produktentwicklung unbedingt beachtet werden?

Auf der Ebene der Leiterbahnen sollten Verbindungen so kurz wie möglich gehalten werden. Masseleitungen sollten nach Möglichkeit immer parallel ausgerichtet werden, auch wenn diese sich auf einem anderen Platinen-Layer befinden. „Noisy Power-Supplies“, also unsauber geglättete Spannungsversorgungen, sollten mit Abstand zu digitalen - und besonders wichtig - analogen Leitungen verlegt werden. Entsprechend ausgelegte Masseplatten (Ground) und Spannungsversorgungen sollten mit Sorgfalt konzipiert sein, um die EMI (Elektromagnetische Interferenzen) so gering wie möglich zu halten. Sind Testmesspunkte notwendig, z.B. für Qualitätssicherung oder CE-Prüfung, sollten diese als Kupferflächen („copper-filled pad“) anstatt einfacher Durchgangslöcher ausgeführt sein.

Kritische Verbindungen, wie z.B. Datenpfade und Busse, sollten auf innenliegenden Platinen-Layern verlegt sein, um diese zu verstecken und ein leichtes Manipulieren zu verhindern. Verbindungen zwischen den einzelnen Layern der Platine, welche mehrere Layer verbinden und nicht mit den Außenlayern verbunden sind, bieten einen sinnvollen Schutz gegen ein Abtasten und Analysieren mit z.B. Logikanalyzern.

Die Abläufe und Informationen in einem Gerät können durch eine Analyse der internen Daten-, Kontroll- und Steuerbusse mit z.B. einem Logikanalyzer ausgelesen werden. Durch einfaches Entfernen von z.B. Lötstopplack auf der Leitplatte ist ein Zugriff auf die Bussysteme möglich. Man sollte sich vor Augen halten, dass ein Auslesen von Speicherbereichen (RAM, ROM, etc.) über die Bus-Systeme jederzeit möglich ist.

In Huangs „Hacking the Xbox: An introduction to Reverse Engineering“ [4] beschreibt der Autor, wie mit einfachen Methoden der Xbox Hypertransport-Bus ausgelesen werden kann. Es war ihm damit möglich, die Schlüssel für die symmetrische Verschlüsselung zur Absicherung des Boot-Loaders auszulesen. Dadurch war er in der Lage, seinen eigenen, ungesicherten Code auf der Spielkonsole auszuführen.

<next>

 

Ein Umzug dieses kritischen Bus-Systems auf einen innenliegenden Layer der Platine, wäre ein wirksamer Schutz gewesen. Bei der Verwendung von einschichtigen Platinen kann der Einsatz von Verkapselungsmitteln (Spezielle Lacke) einen gewissen Schutz bewirken.

Die meisten Speicherbausteine bieten generell sehr wenig bis keine Sicherheitsmerkmale. Ein Auslesen von Speicherbereichen unterliegt keinerlei Absicherung. Einige Speicherbausteine bieten einfache Sicherungsmethoden, Änderungen an z.B. ROM- oder Flash-Inhalten mittels durchgebrannter Sicherung zu schützen. Ein Auslesen ist jedoch trotz des Schreibschutzes möglich.

Ein Auslesen von RAM-Bausteinen oder anderen flüchtigen Speichern ist recht einfach möglich. Eine Sicherung gegen Auslesen der Klartextinhalte ist schwer möglich.

Maxim – ehemals Dallas Semiconductor - hat einen EEPROM-Speicherbaustein (DS28E15) im Produktportfolio, welcher den SHA-256 Algorithmus verwendet, um gespeicherte Inhalte zu schützen. Atmel Semiconductors hat mit der CryptoMemory-Familie ein ganzes Arsenal an geschützten Speicherbausteinen im Programm. Die Maßnahmen reichen von Flash-Bausteinen mit Authentifizierung bis hin zu Verschlüsselungs-Funktionen im Baustein selber.

Die meisten der eingesetzten Standard-Speicherbausteine werden jedoch anhand wirtschaftlicher Faktoren ausgewählt. Sie enthalten meistens keine Sicherheitsfunktionen und stellen ein generelles Risiko dar.

 

Programmierbare Logikbausteine (PLDs) und Field Programmable Gate Arrays (FPGAs) bieten ebenfalls für potentielle Angreifer ein offenes Tor. Dipert gibt in seinem Artikel „Cunning circuits confound crooks“ [5] einen Überblick über die Vor- und Nachteile der PLD- und FPGA-Technologie. Im Wesentlichen sind diese besonders anfällig für einen Angriff im Zusammenspiel mit SRAM. Diese laden beim Einschalten ihre Konfiguration aus dem SRAM in den FPGA. Der Bitstrom zwischen dem Konfigurationsspeicher (SRAM) und dem FPGA muss lediglich abgefangen werden, um die gesamte FPGA-Konfiguration zu erhalten.

Eine Schutzmaßnahme wäre hier, unbenutzte Pins (Anschlüsse) so zu überwachen, dass Pegeländerungen erkannt werden können. Das Gerät könnte somit einen untypischen Betriebsmodus erkennen. Dies wiederum könnte auf ein Abgreifen von Bus- und Schnittstellen-Informationen hindeuten.

Darüber hinaus sollte beim Entwurf der Zustandsmaschine der FPGAs darauf geachtet werden, dass alle möglichen Zustände abgedeckt sind. Für nicht verwendete Zustände sollten Standardwerte eingestellt werden.
 
Es sollte auch in Erwägung gezogen werden, digitale „Wasserzeichen“ zu verwenden, um das Design in der Form von einzigartigen Eigenschaften zu schützen. Dies stellt zusätzlich noch einen Produkt- bzw. Patentschutz dar.
 
Weitere Möglichkeiten bietet eine erweiterte Speicherverwaltung. Dabei werden FPGAs oder andere Schaltungen eingesetzt, um Schnittstellen zu überwachen. D.h., Busse werden überwacht und lassen Lese-/Schreibzugriffe nur auf zuvor definierte Speicherbereiche zu. Der Versuch, andere Speicherbereiche auszulesen, wird verhindert und kann eine Alarmierung auslösen.

Ein prominentes Beispiel, wie sich eine Nichtberücksichtigung der aufgeführten Empfehlungen auswirken kann, ist der Angriff auf den Speicherbereich mittels Firewire, SATA oder Thunderbolt. Das angepriesene Feature DMA (Direct Memory Access) stellt an sich ein Sicherheitsproblem dar. Mit einfachen Mitteln lassen sich über diese Schnittstellen diejenigen Speicherbereiche auslesen, welche die Passwörter des Betriebssystems beinhalten. Eine Überwachung des „DMA“, also eine Art Firewalling des Speicherbereiches mittels FPGA- und Treiberunterstützung, würde hier ausreichenden Schutz liefern.

Weitere Vorkehrungen sollten hinsichtlich der Schwankungen bei der Spannungsversorgung getroffen werden. Minimale und maximale Grenzen sollten definiert und durch geeignete Schutzschaltungen abgesichert sein, egal, ob Vergleicher, Watchdogs oder „supervisory-circuits“ (z.B. von Maxim und Linear Technology) eingesetzt werden. Mit einem Low-Dropout Linear-Regler oder einem Gleichspannungswandler wird dazu beigetragen, dass das Gerät die angedachte Spannungsversorgung erhält.

Ein Beispiel für einen Angriff unter Verwendung von Netzspannungsschwankungen ist der Mikrocontroller PIC16C84. Ein Angreifer erhielt durch das Anheben der Versorgungsspannung um ca. 0,5 V (in Summe 13,5 V) Zugriff auf das Security-Bit. Er konnte die Prüfung umgehen, ohne den Speicherbereich direkt zu manipulieren, und erhielt Zugriff auf den geschützten Speicherbereich des Mikrocontrollers.

Ein prominenteres Beispiel sind Seitenkanalangriffe, in diesem Fall eine SPA (Simple Power Analysis). Sie stellt eine Methode dar, bei welcher der Energieverbrauch eines Mikroprozessors während einer kryptographischen Berechnung aufgezeichnet wird. Der Energieverbrauch des Mikroprozessors variiert in Abhängigkeit der jeweils ausgeführten Operation. Es ist dadurch möglich, einen Rückschluss zur ausgeführten Operation und indirekt auf den Schlüssel der kryptographischen Berechnung zu erhalten.

Es existieren mehrere Möglichkeiten von Gegenmaßnahmen, von Rauschgeneratoren in der Spannungsversorgung, entsprechenden Filtern, bis hin zu parallel durchgeführten Störberechnungen.

Die Seitenkanalangriffe haben eine gewisse Schnittmenge mit sogenannten Timing-Angriffen. Timing-Angriffe werden generell in zwei Kategorien aufgeteilt.

Passive Timing-Angriffe: Hier wird versucht – wie bei einem Seitenkanalangriff - einen Rückschluss aus der benötigten Zeit der einzelnen Rechenschritte auf die durchgeführten Operationen herzustellen. Kryptographische Operationen lassen sich daraus ableiten und gegebenenfalls Rückschlüsse auf das kryptographische Material ziehen. Beschrieben werden diese Prozesse u.a. in Kochers “Timing Attacks on Implementations of Diffie-Hellman, RSA, DSS, and Other Systems” [6].

Aktive Timing-Angriffe: Dabei handelt es sich um invasive Angriffe, welche physischen Zugriff auf den Uhrenquarz benötigen. Das Ziel dieser Angriffe ist die Manipulation des Taktkristalls, um beispielsweise die Generierung von Passwörtern bei Authentifizierungs-Tokens zu beschleunigen und die one-time-passwords für die Zukunft zu berechnen. Abhilfe schafft hier nur eine aufwändige Erkennung und Überwachung der internen Uhr. Mögliche Reaktionen auf ein Abschalten oder Stören der eingebauten Uhr wären das Gerät komplett abzuschalten oder ganze Speicherbereiche zu löschen.

Kryptographische Co-Prozessoren, welche eine, meist schnellere, Berechnung von kryptographischen Algorithmen erlauben, sind sehr komplex. Die meisten der angebotenen Prozessoren bieten eine Reihe von Sicherungsmaßnahmen einschließlich Erkennung von Manipulationen, mehrschichtigem System-Design, Selbstüberwachung, Eigeninitialisierung, eigene Taktgeber usw.

Bei Verwendung dieser Co-Prozessoren sollte darauf geachtet werden, dass nach Möglichkeit alle Verschlüsselungsfunktionen der Anwendung in diesen auch bearbeitet werden. Bennet Yee legte bereits mit seinem 1994 erschienen Dokument „Using Secury Coprocessors“ den Grundstein für den sinnvollen Einsatz dieser Hardware-Module.

Fazit

Zusammenfassend zeigen die dargestellten Risiken und deren Gegenmaßnahmen, dass gegen viele hardwarenahe Angriffe ein Schutz durchaus möglich ist.
Jedoch stellt sich recht schnell die Frage:

Wie soll der Betreiber oder gar der Endbenutzer die vorhandenen Sicherheitsfeatures prüfen?

 

Um hier die Analogie zum eingangs erwähnten Kfz zu schließen, erst eine genaue Begutachtung und Prüfung des Autos – oder auch des Systems – gibt Aufschluss über den sicheren Zustand.

Als Betreiber, z.B. einer kritischen Infrastruktur, hat man gegebenenfalls die Möglichkeit, den Hersteller direkt zu kontaktieren und die Umsetzung der dargestellten Sicherungsmaßnahmen zu erfragen und zu prüfen. Dieser Vorschlag einer Prüfung ist aber leider nicht immer umsetzbar. Es sollte darum ein risikobasierter Ansatz gewählt werden. Das bedeutet, dass die Kritikalität des Systems in Bezug zu dem möglichen Risiko einer Kompromittierung gesetzt wird. Je höher die Kritikalität des Systems, desto eher sollten die hier beschriebenen Aspekte geprüft und beachtet werden.

Als Beispiel sind hier militärische Geräte zu nennen. Deren Eignung für den Einsatz wird unter anderem auch auf der Ebene des Platinen-Layouts geprüft.

Der Massenmarkt für die Endbenutzer, überschwemmt mit asiatischen IT-Produkten, lässt wenig Spielraum für eine sichere Geräte-Entwicklung. Hier bleibt nur zu hoffen, dass die Entwickler sich genügend Gedanken über ein sicheres Hardware-Design gemacht haben. Eine Kontrolle oder Prüfung vor dem Kauf ist äußerst schwierig.

Die Notwendigkeit der Sicherheit beim Hardware-Design steht außer Frage. Die gezeigten Schwachstellen und Angriffsszenarien zeigen deutlich, wie wichtig der Blick auf die Hardware ist. Sie zeigen auch, dass Software – und sei diese auch noch so sicher konfiguriert und programmiert –nicht vor Angriffen auf der Ebene der Hardware schützt. Es sollte aus diesem Grund immer auch ein kritischer Blick auf die Hardware geworfen werden – insbesondere bei Systemen, die in Bereichen der Kritischen Infrastruktur eingesetzt werden.

Autor: Gregor Domhan, GAI NetConsult GmbH

Referenzen:

[1] http://csrc.nist.gov/publications/nistpubs/800-27A/SP800-27-RevA.pdf 
    SP 800-27 Rev.A vom Juni 2004:
„Engineering Principles for Information Technology Security (A Baseline
for Achieving Security)“

[2] Charles P. Pfleeger’s „Security in Computing“
    Oktober 2006, ISBN: 978-0132390774

[3] https://www.cl.cam.ac.uk/~mgk25/tamper2.pdf
    1996, 1997
    Ross Anderson and Markus Kuhn.
„Low Cost Attacks on tamper Resistant Devices“

[4] Andrew Huang: “Hacking the Xbox: An Introduction to Reverse Engineering”
    Juli 2003, ISBN: 978-1593270292

[5] Diperts “Cunning circuits confound crooks”
http://m.eet.com/media/1149202/22164-21df2.pdf  

[6] Paul C. Kocher: “Timing Attacks on Implementations of Diffie-Hellman, RSA,
DSS, and Other Systems”
http://www.cryptography.com/public/pdf/TimingAttacks.pdf 

[7]    Bennet Yee “Using Secure Coprocessors”
    1994
    http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.28.4872

Abbildungen:

Abbildung-1: Aus dem „27th. Chaos Communication Congress“
http://events.ccc.de/congress/2010/Fahrplan/attachments/
1608_JTAGenum_use.jpg


Abbildung-2:  Eigenaufnahme

Abbildung-3:

http://cms.diodenring.de/electronic/microcontroller/83-ic-decapsulation  

Diesen Artikel empfehlen

Autor: Gregor Domhan

IT-SiG verabschiedet – was kommt auf uns zu?

Die Informationstechnologie prägt seit Jahrzehnten die Unternehmen in immer stärkerem Maße und spätestens seit Mitte der 90-er Jahre kann man dies auch für das Internet feststellen. Dass das Internet somit schon lange kein „Neuland“ mehr für deutsche Unternehmen ist, dies hat nun mittlerweile auch...

Neue Vorgaben der Finanzverwaltung für die IT-Compliance

Eine Verwaltungsverordnung kann zwar dem Bürger keine direkten Pflichten auferlegen, dennoch ist die GoBD von erheblicher Bedeutung, da die Finanzämter das Schreiben des BMF bei der Bearbeitung der Steuerangelegenheiten zwingend befolgen müssen und sich daher die Bearbeitungspraxis der Finanzämter...

Netzwerke sicher virtualisieren mit Software-defined Networking (SDN)

Im Bereich der IT ist die Virtualisierungstechnik längst nicht mehr neu. Schon in den 60er Jahren experimentierten Hardwarehersteller wie IBM mit virtueller Speicherverwaltung zur Partitionierung von Ressourcen in deren Mainframes. Das ermöglichte ein quasi Multitasking und somit ein beinahe...

eHealth – Der „Neue Markt“ für Cyber-Kriminelle?

Hinweise auf bereits festgestellte oder befürchtete Datenschutzverletzungen im Gesundheitswesen ereilen uns nahezu täglich. Bei immer mehr elektronisch gespeicherten medizinischen Daten und zunehmendem Datenaustausch müssen wir wohl zukünftig mit noch mehr Alarmmeldungen wie den nachstehenden...

Gefährliche Dinge(r) im Internet-of-Things?

Viele sprechen heute schon von der vierten industriellen Revolution (nach Erfindung der Dampfmaschine, der Einführung der Elektrizität und dem Beginn des Computerzeitalters) und meinen damit die bereits angelaufene Vernetzung im Internet-of-Things (IoT). Gartner geht in der Studie „Forecast: The...

IPsec versus SSL VPN

Der Grundgedanke hinter einem „Virtual Private Network“ ist schnell erläutert. Es besteht der Wunsch, ein privates Netzwerk über ein unsicheres Medium, wie beispielweise das Internet, aufzubauen. Die Nutzung von fremden, bereits bestehenden Netzwerken ist so attraktiv, da sie eine überaus...

Sichere drahtlose Mesh-Netzwerke und mögliche Anwendungen

Drahtlose Mesh-Netzwerke Drahtlose Mesh-Netzwerke zeichnen sich zuallererst durch ihre drahtlose Kommunikation aus. In diesem Artikel liegt der Fokus auf IEEE 802.11 (WLAN) als Funktechnologie. Andere Technologien, wie zum Beispiel IEEE 802.16 (WiMAX), IEEE 802.15.4 (ZigBee) oder proprietäre...

Einsatz von Softwarelösungen zum Aufbau und Betrieb eines ISMS

Es ist hilfreich, sich die Idee eines ISMS als Trichter vorzustellen, welcher mit der Erfassung der informationellen Werte (auch als Assets bezeichnet) beginnt und mittels einer Risikobewertung zu einem konzentrierten Ergebnis, den Maßnahmen, gelangt. Ausgehend von der Frage, was ein Unternehmen...