Mikrocontroller Sicherheit - Kann man einen µC hacken/cracken?

Ich überlege ein Gerät zu bauen, dass ein Problem lösen soll: Setzt man 
eine gute Verschlüsselung ein, kann diese Sicherheit durch die 
Angreifbarkeit des PCs bzw. des Betriebssystems beeinträchtigt werden.
So bringt eine Verschlüsselung nichts, wenn der Angreifer schon auf dem 
Rechner ist und entschlüsselte Inhalte mitlesen kann bzw. zu 
verschlüsselnde Texte vorher abgreifen.

Ich dachte mir, ich bastel ein kleines Gerät mit einem Display, 
übertrage mit einem Kabel die verschlüsselten Daten, trenne die 
Kabelverbindung und das Gerät entschlüsselt und zeigt den Text an.

Der Klartext befindet sich also zu keinem Zeitpunkt auf dem PC sondern 
auf einem sehr minimalistischen Gerät das auf diese eine Aufgabe 
reduziert ist mit seinen Fähigkeiten.

Ich fürchte keine Angriffe, aber interessiere mich für die theoretische 
Möglichkeit.
Vorstellen kann ich mir, dass ein Trojaner auf dem PC, einen 
verschlüsselten Text vor der Übertragung auf das Gerät so manipuliert 
und erweitert, dass es z.B. den µC dazu veranlasst den entschlüsselten 
Klartext zu speichern und bei der nächsten PC Verbindung an den Trojaner 
zu übertragen.

Angesichts bestimmter denkbarer Szenarien, kann man dann halt nicht 
behaupten, dass es unmöglich sei das der PC Zugriff auf den Klartext 
erlangt.

Es wäre schön wenn man selbst solche theoretischen Szenarien 
ausschließen könnte.

Max D. schrieb:
> Ein relativ guter Schutz ist die Verwendung eines µC mit
> Harvard-Architektur.
> Dadurch dass Ram und Rom getrennt sind ist es sehr schwer exploits
> anzubringen. Mit einem Buffer-Overflow kann man maximal den Ram
> beeinträchtigen, man kann also nicht einfach befehle an die CPU
> schicken.
Naja, bei PC-Architekturen ist das ja mittlerweile ganz genauso (NX bit 
und so). Und dennoch gibts mehr Exploits und Sicherheitslücken denn 
je...
> PS: Es besteht zwar immernoch die theoretische Möglichkeit über
> overflow-tricks den µC zu Sprüngen zu bringen, man kann aber nur die
> Befehle verwenden (bei angenommener voller kontrolle über den
> programmcounter, in der praxis eigtl. unmöglich) die der Programmierer
> in seinem Code verwendet hat.
Zum Glück gibts davon nicht so viele. Bei großen Programmen findet sich 
gewiss einiges was man gebrauchen kann. Wenn das beim PC funktioniert, 
warum nicht beim µC?

Erschwerend hinzu kommt, dass viele µC-Programme nicht von "richtigen" 
Programmierern sondern "nur" von ETechnikern etc. programmiert werden 
die es mit solchen Details wie Buffer-Größen vielleicht nicht immer so 
genau nehmen...

Keks schrieb:
> Vorstellen kann ich mir, dass ein Trojaner auf dem PC, einen
> verschlüsselten Text vor der Übertragung auf das Gerät so manipuliert
> und erweitert, dass es z.B. den µC dazu veranlasst den entschlüsselten
> Klartext zu speichern und bei der nächsten PC Verbindung an den Trojaner
> zu übertragen.
Warum soll der Trojaner den Text nicht direkt entschlüsseln? Warum der 
Umweg über den µC? Irgendwie ist deine Aufgabenstellung wirr. Und sie 
hat irgendwie wenig mit der Angreifbarkeit von µC-Programmen zu tun.

Dr. Sommer schrieb:
> Warum soll der Trojaner den Text nicht direkt entschlüsseln? Warum der
> Umweg über den µC? Irgendwie ist deine Aufgabenstellung wirr. Und sie
> hat irgendwie wenig mit der Angreifbarkeit von µC-Programmen zu tun.

Na weil der Trojaner den Schlüssel für die Entschlüsselung nicht 
besitzt. Die Entschlüsselung läuft ja im µC ab. Wenn ein Angreifer also 
die Verschlüsselung nicht brechen kann, muss er irgendwie den µC 
angreifen, weil dort die Entschlüsselung stattfindet.

Bei komplexeren µCs (etwa ARM) hat man ggf. schon ziemlich ähnliche 
Probleme. Dazu kommt, das die fast immer eine JTAG Schnittstelle bieten. 
Ist erst einmal wieder Aktiviert, ist fast alles für einen Angreifer 
offen - zumindest in der Theorie. In der Regel besteht auch die 
Möglichkeit den Code Bereich zu beschreiben, etwa für Bootloader.

Bei einfachen µCs (etwa PIC12, 8051) gibt es da eher weniger 
Möglichkeiten. Zum Teil hat man nur einmal beschreibbaren 
Programmspeicher und mehr oder weniger gut funktionierende Schutzbits 
die ein Auslesen des Codes verhindern. Für spezielle Fälle gibt es auch 
extra gut geschützte µCs - mit entsprechend eher weniger Information 
darüber. Durch die geringe Größe des Codes, kann man auch tatsächlich 
fehlerfreien Code haben (nicht 100% sicher, aber doch sehr 
Wahrscheinlich) - so dass es ggf. solche Lücken wie Buffer overflow 
einfach nicht gibt. Einen nur durch ein Password oder ähnliches 
geschützten Zugang braucht man in vielen Anwendungen auch gar nicht. Da 
fehlt schon die Tür und nicht nur der Schlüssel.

Der Schutz ist bei vielen µCs nicht perfekt (z.B. Schutzbits beim AVR 
lassen sich angeblich unter umgehen, sei es auch nur mit öffnen des 
Gehäuses).

Die Funktion des Programms kann man natürlich per externem 
Logic-analyser Dokumentieren - bei einfachen Funktionen ließe sich die 
ggf. auch duplizieren.

>Es wäre schön wenn man selbst solche theoretischen Szenarien
>ausschließen könnte.

Das kann man nicht ausschliessen. Das ist nicht plausibel zu begründen 
ohne in die Tiefe zu gehen.
Das Hauptargument ist, das es keinen Weg gibt zu beweisen, dass ein 
Programm (und in Deinem Fall ja auch noch der uC) unter allen 
Umständen immer nur genau das macht, was er soll.

Ich vermute mal, das es darum geht, dass Du solch ein Produkt entwickeln 
und anpreisen willst.

Wenn Du Dich mal mit Testmethoden beschäftigst, dann wirst Du sehen das 
diese darauf beruhen die Korrektheit für eine Auswahl an Testdaten zu 
zeigen, nicht aber für die Gesamtheit der möglichen Daten und 
Umweltbedingungen. Wenn Du Dir dazu mal einige Exploits und versuche von 
Reverse-Engineering ansiehst, wirst Du sehen, das es oft exotisch 
scheinende, ja geradezu absurde Umstände sind, die ein System angreifbar 
machen. Sowas kann man prinzipiell nicht voraussehen.

Solange es keinen Physischen Zugriff auf die Box gibt, kann man so etwas 
einfaches wie die Verschlüsselung auch "Sicher" machen, so dass es vom 
PC aus nichts Böses rüber kommt.

Angreifbar bleibt so ein System aber z.B. über eine Kamera (wenn man es 
dumm anstellt auch die Webcam am PC) oder eventuell Elektromagnetische 
Abstrahlungen, wenn man nicht aufpasst.

Keine Sau wird sich für das System von Keks interessieren
wenn damit nicht wenigstens sechstelliger Umsatz gemacht
wird. Vorher muss man sich kaum Sorgen um Angriffe machen.

Lohnt sich nicht.

HertzFrequenz schrieb:
> Ich vermute mal, das es darum geht, dass Du solch ein Produkt entwickeln
> und anpreisen willst.

Eigentlich nicht. Ich lerne und versuche ja gerade noch zu verstehen wie 
sicher µC eigentlich sind.

> Wenn Du Dich mal mit Testmethoden beschäftigst, dann wirst Du sehen das
> diese darauf beruhen die Korrektheit für eine Auswahl an Testdaten zu
> zeigen, nicht aber für die Gesamtheit der möglichen Daten und
> Umweltbedingungen. Wenn Du Dir dazu mal einige Exploits und versuche von
> Reverse-Engineering ansiehst, wirst Du sehen, das es oft exotisch
> scheinende, ja geradezu absurde Umstände sind, die ein System angreifbar
> machen. Sowas kann man prinzipiell nicht voraussehen.

Das stimmt. Es liegt wohl in einem grundlegenden Prinzip der Natur 
begründet, dass zu keinem Zeitpunkt alle möglichen Variablen der 
Gegenwart und Zukunft betrachtet werden können.
Eine Art Evolution, jede geniale Überlebenstechnik muss mit einem 
zukünftigen Raubtier rechnen der diesen Schutz effektiv überwinden kann. 
Aufgrund der vielleicht unendlichen Möglichkeiten.

Dennoch lässt sich Sicherheit aber effektiv erhöhen. Und ich glaube das 
ist  der Fall, wenn man sensible Daten, von einer so komplexen Umgebung 
wie die eines PC Betriebssystems, auf eine einfachere und besser 
kontrollierbare Umgebung verschiebt.

cyblord ---- schrieb:
> Denn irgendwie muss der
> Klartext ja erstmal verschlüsselt werden und das soll ja auf dem PC
> passieren. Und da kann der Trojaner auch zuschlagen.

Auch die Verschlüsselung sollte logischerweise auf dem µC stattfinden.


holger schrieb:
> Lohnt sich nicht.

Es geht aber nicht um meine Daten. Und sich Gedanken über 
Sicherheitskonzepte zu machen lohnt sich immer.
Ich jedenfalls interessiere mich allgemein für IT Sicherheit.

HertzFrequenz schrieb:

> Das Hauptargument ist, das es keinen Weg gibt zu beweisen, dass ein
> Programm (und in Deinem Fall ja auch noch der uC) unter allen
> Umständen immer nur genau das macht, was er soll.

Doch, natürlich gibt es diese Möglichkeit. Es ist nur eine Frage der 
Komplexität, ob sie praktikabel anwendbar ist.

Bei den verhältnismäßig kleinen Programmen in µC mit sehr überschaubaren 
Möglichkeiten zur "Eingabe" ist sie es oft.

cyblord ---- schrieb:
> Und wie kommt der Klartext da rein?

Über eine einfache Tastatur.

Kai S. schrieb:
> Wenn der Programmcode z.B. nur Empfangen und kein
> Senden vorsieht, dann wird der PC selbst bei angeschlossenem Kabel keine
> Chance haben, an die entschlüsselten Daten heranzukommen.

Ich glaube das kann man so nicht sagen. Bei einem Exploit kann neuer 
Code eingeschleust und ausgeführt werden. Das könnte durch einen Fehler 
passieren durch die Verarbeitung der empfangenen Daten.

Wenn der Angreifer den µC kennt, kann er auch die entsprechenden Befehle 
einschleusen um eine Sendefunktion auszuführen.

cyblord ---- schrieb:
> Evt. ein Beispiel wäre gut.

Nehmen wir Alice und Bob :D

Alice will eine Nachricht an Bob senden. Alice setzt eine 
Verschlüsselungsmethode ein die sehr sicher ist. Doch Alice kann nicht 
ausschließen das ihr PC einen Trojaner enthält. Der Klartext könnte vor 
der Verschlüsselung ausspioniert werden.

Alice hat ein kleines Gerät mit einem Display und einer Tastatur.
Das ganze wird von einem oder mehreren µC angetrieben.
Es ist auf die nötigste Funktionalität begrenzt. Es kann Text auf dem 
Display anzeigen, Text verschlüsseln und entschlüsseln und mit dem PC 
kommunizieren oder halt mit einem Speichermedium wie einer SD-Card.

Alice schreibt ihren geheimen Text auf dem Gerät, lässt es 
verschlüsseln, verbindet das Gerät mit dem PC, überträgt die Datei auf 
den PC und sendet diese z.B. mit einer Email an Bob.

Bob empfängt den verschlüsselten Text. Aber auch Bob kann nicht 
ausschließen ob sein PC wirklich sicher ist.
Also verbindet Bob sein Gerät mit dem PC, überträgt den verschlüsselten 
Text, trennt die Verbindung zum PC und lässt sich den entschlüsselten 
Text auf dem kleinen Gerät anzeigen.


Ein Angreifer der die Kommunikation von Alice und Bob abhören will, hat 
es nun viel schwieriger an den entschlüsselten Text zu kommen. Ihnen 
bringen nun die tausenden Exploits nichts mehr die es für PC 
Betriebssysteme und PC Programme gibt (siehe legalen Handel mit Exploits 
und Schwarzmarkt).

Der Angreifer ist gezwungen den µC anzugreifen um an den Klartext zu 
kommen.
Ich schließe aber Methoden aus, wo der Angreifer physisch vor Ort sein 
muss. Wenn sich z.B. Firmen da schützen wollen, müssen die eben noch 
andere Sicherheitsvorkehrungen haben, als nur so ein Gerät für die 
Verschlüsselung.

Im Grunde ist die Idee schon ganz gut. USB ist allerdings relativ 
aufwändig und benötigt in Mikrocontrollern auch recht viel 
unübersichtliche Hardware Module. Die Playstation3 wurde das erste mal 
für jedermann über eine Schwachstelle im USB Stack (gut, da war es USB 
Host aber trotzdem) gehackt. Du könntest einen externen USB Controller 
Chip wie einen FTDI Nutzen, der dir die Daten seriell gibt. Das ist 
programmiertechnisch billig erkaufte Sicherheit, denn du lagerst den USB 
Stack in einen externen Prozessor aus. Wenn jemand den USB Stack hackt 
seis drumm, dann ist er auch nicht viel weiter. Du musst dann nurnoch 
ein simples serielles Protokoll implementieren, dies sollte relativ 
sicher werden.
Dazu noch ein Tastaturinterface (am besten PS/2) und ein Display. Dürfte 
sich in Grenzen halten mit der Angreifbarkeit.

Professionell ist natürlich anders. Die STM32 Prozessoren haben 
entsprechende Fuses, hier ist mir auch kein Angriffsvektor bekannt. 
Diese deaktivieren JTAG, Bootloader, sogar das Lesen des Flashes von 
außerhalb. Zusätzlich kannst du, falls du Code von extern ausführen 
willst, in den OTP Speicher die Checksumme/Signatur des Second-Stage 
Bootloaders brennen, und diese beim Start prüfen. Das sollte aber nicht 
nötig sein. Dann musst du eben höllisch aufpassen, nirgends (vor allem 
im USB Teil) Lücken zu lassen. Sollte aber auch machbar sein.

@ Keks
>Dennoch lässt sich Sicherheit aber effektiv erhöhen.

Das ist, wenn ich Dich recht verstehe, ein Missverständnis. Mein Einwand 
bezog sich auf folgenden Wunsch von Dir:

>Es wäre schön wenn man selbst solche theoretischen Szenarien
>ausschließen könnte.

nicht darauf, ob es wünschenswert wäre, die Sicherheit wenigstens 
graduell zu erhöhen. Das ist, soweit es eben klar ist, dass es sich um 
eine graduelle Sicherheit handelt, nicht um eine absolute durchaus 
möglich.

@ cyblord
>Doch, natürlich gibt es diese Möglichkeit. Es ist nur eine Frage der
>Komplexität, ob sie praktikabel anwendbar ist.

Wieder einmal eine Deiner genial irrelevanten Bemerkungen.

Es ist völlig, klar, das es bei sehr einfachen Systemen, d.h. solchen 
mit wenigen Variablen, möglich ist ihr Verhalten abdeckend zu tested.
Aber ein System, von dem wir hier reden, das einen Mikrocontroller 
beinhaltet, der Daten von einer Länge wie sie einer üblichen Nachricht 
entsprechen, verarbeitet, fällt darunter mit so einer geringen 
Wahrscheinlichkeit, dass mir und jedem vernünftigen Praktiker mit mir, 
denke ich, diese Einschränkung überflüssig erschien.

Kurz gesagt, trifft meine Bemerkung viel wahrscheinlicher zu, als Deine 
korrekte Erweiterung der Aussage hier relevant ist. Wenn man bei jeder 
Erklärung jeden möglichen Sonderfall berücksichtigen würde, wäre jede 
Antwort ein Lehrwerk für sich.

Keks schrieb:
> Angenommen ein µC ladet User generierte Daten und verarbeitet diese.

Erst gestern (?) wurde die Xilinx AES Verschlüsselung mit einer Side 
Channel Attacke gebrochen.

AES erzeugt auf dem FPGA eine detektierbare Stromschwankung... das 
30.000 gemacht+Modell+Statistik und man hatte den Key.

TMC Pro wurde mit der Annahme aufgehebelt das sich Daten ständig 
wiederholen.

Alte Mikrocontroller konnte man mit Power Glitches während dem Auslesen 
umbiegen.

Ein paar PIC-Serien kann man aufätzen und die Fuses starkem UV-Licht 
aussetzen (Flash+RAM abkleben)... dann kriechen die Elektronen unter die 
Metallschicht und man kommt ans EEPROM.

Sicherheit von uC-Systemen:

Schnell entwickeln, schnelle Markteinführung und starkes Marketing.
Wenn ein relevanter Teil der Zielgruppe erreicht wurde und der Markt von 
Kopisten und Plagiatoren aufgegriffen wird, sollte man schon das nächste 
heiße Eisen schmieden. Ist auf jeden Fall zielführender als Zeit mit der 
vermeintlichen Absicherung eines Systems zu verschwenden. Es gilt ja 
auch: je höher der Aufwand beim Schutz, desto lohnender der Crack...

Ein Negativ-Beispiel:

An der Supermarkt Kasse steht ein Terminal, um mit der EC Karte bezahlen 
zu können. Die Kommunikation zur Karte und Bank macht dieses kleine 
Gerät. Die Kasse übermittelt lediglich den zu zahlenden Betrag und 
empfängt eine Erfolgsmeldung.

Hier hat man die Sicherheit der Kasse erhöht, indem der Zahlungsvorgang 
durch einen externen Mikrocontroller durchgeführt wird.

Und doch wurden sie in großem Stil gehackt, nämlich durch direkten 
Zugriff auf die Hardware vor Ort am helligsten Tag direkt vor den Augen 
der Kassierer.

Ein anderes Beispiel: Beim Installieren einer Android App stimmt der 
Benutzer zu, dass die App auf bestimmte Daten zugreift. Doch währen der 
Benutzer darüber nachdenkt, ob er "ja" oder "nein" anklicken soll, kann 
die App auf ALLE Daten zugreifen und es wurde bereits in großem Umfang 
so gemacht - mit einer Taschenlampen App!

Selbst richtig gut ausgeklügelte Software wird manchmal auf erschreckend 
primitive Weise umgangen.

Denke bei Deinem Konzept über solche Szenarien nach. Frage dich: Wie 
kann man mein Gerät gänzlich umgehen oder austauschen? Wie kann man das 
Gerät missbrauchen oder dessen Funktion von außen reverse-engineeren.

@ cyblord

>Lern erstmal zitieren du Vogel, bevor du blödsinn redest. Das Zitat ist
>nicht von mir.

Vogel? He he. Qualitativ nicht viel anders als c-hater oder MaWin.
Hat also keinen Falschen getroffen. Darfst Dich angesprochen fühlen.
Viel Spaß dabei.