Hallo, folgendes Gedankenspiel: Ein System besteht aus einem Master und mehreren Slaves. Der Master erfragt sich zyklisch Daten von den Slaves (z.B. per Bluetooth-UART-Adapter). Bei den Slaves besteht grundsätzlich die Möglichkeit, dass durch Unbefugte eine modifizierte oder eine andere Software aufgespielt wird und dem Master dadurch gefälschte Daten gesendet werden. Eine Änderung der Slave-Hardware, um Eingriffe zu verhindern, ist nicht möglich. Grundsätzlich ist davon auszugehen, dass die Daten zwischen Master und Slave verschlüsselt übertragen werden. Die Frage ist nun, welche Methoden/Verfahren es gibt, die es dem Master ermöglichen, dass der Client (Software-seitig) modifiziert wurde. Folgende Ideen gab es bereits: 1) Slave sendet zusätzlich zu den Daten einen MD5-Hash, der aus den Daten selbst und einem ihm eindeutig zugewiesenen Key berechnet wird 2) Im Prinzip wie die erste Idee, allerdings kann anstelle eines einzelnen Keys eine Art TAN-Liste für jeden Slave hinterlegt werden. Entsprechend müssen ausreichend viele TANs hinterlegt sein, oder die Möglichkeit bestehen neue TANs vom Server an den Client zu senden. Bin in dem Thema aber nicht wirklich fit und bin mal gespannt, welche Methoden/Verfahren es gibt.
Das ist ja auch eine Frage welche kriminelle Energie dahintersteckt und welche Hardwaremöglichkeiten. Wenn z.B. ein PC als Slave angeschlossen oder eingeschleift wird, kann der dem Master alles Gewünschte vorgaukeln, falls jemand das Programm analysiert hat. Wenn aber die Hardware des Slave unveränderlich ist, UND wenn dessen Software den Speicher fast vollständig belegt, könnte der Slave dem Master einfach diverse Bröckchen seines Programmspeichers zu Überprüfung schicken. Master fragt z.B. "was steht an Stelle 07feh" und der Slave braucht nur nachzuschauen und sagt z.B. "3ch". Auf diese Weise kann der Master das Programm des Slave nach und nach vollständig überprüfen, oder Checksummen bestimmter Programmteile errechnen, ohne dass diese im Speicher des Slave erscheinen.
Matt B. schrieb: > 1) Slave sendet zusätzlich zu den Daten einen MD5-Hash, der aus den > Daten selbst und einem ihm eindeutig zugewiesenen Key berechnet wird Nennt sich HMAC und sollte ausreichen, sofern du dafür sorgst, dass der Key auf den Slaves geheim bleibt. Also Lock Bits setzen, wobei das auch nicht jeden abhält aber schonmal recht viele. Die "TAN Liste" hat keinen wirklichen Vorteil und braucht mehr Speicher. Wenn jemand einen geheimen Key auslesen kann, dann kann er das auch für mehrere.
Sebastian V. O. schrieb: > sofern du dafür sorgst, dass der > Key auf den Slaves geheim bleibt. Also Lock Bits setzen... ...die Lockbits kann man einfach zurücksetzen. Hierzu muss man das Gehäuse öffnen und die Lockbits mit UV-Licht beleuchten. Sebastian V. O. schrieb: > wobei das auch > nicht jeden abhält aber schonmal recht viele... ...wenn die Daten so wichtig sind, dass man eine Softwaremanipulation verhindern muss, dann wird man auch mit einem Zurücksetzen der Lockbits rechnen müssen.
Die Abfrage des Slave Codes als eine Art "Geheimnis" für den Slave ist eine gute Idee. Solange der Slave nicht mehr Speicher hat, ist da kein Platz für zusätzlichen Code, oder ein Abbild des Originals. Den nicht genutzten Teil muss man halt noch irgendwie nicht trivial auffüllen. Die Abfrage muss auch nicht offensichtlich sein, und kann z.B. "Verschlüsselt" (z.B. Checksumme/Hash über Teil des Codes ab ... + zusätzlichen Salt) sein, so dass es für einen Angreifer nicht so leicht ist an den original Code des µC zu kommen um einen falschen Slave mit mehr Speicher nachzubauen.
Schreiber schrieb: > ...die Lockbits kann man einfach zurücksetzen. Hierzu muss man das > Gehäuse öffnen und die Lockbits mit UV-Licht beleuchten. Und das Equipment dazu hat jeder Bastler im Keller? Und ob man jetzt einen Key in den Slaves oder den Code selbst nimmt ist doch ziemlich egal wenn der Angreifer den Code auslesen kann. Dann kommt einfach der nächst größere µc rein, um die Codeabfrage zu überlisten, und den Rest kann man dann mit eigenem Zeugs vollpacken.
Matt B. schrieb: > Die Frage ist nun, welche Methoden/Verfahren es gibt, die es dem Master > ermöglichen, dass der Client (Software-seitig) modifiziert wurde. Das geht prinzipiell nicht, zumindest nicht mit normalen Mikrocontrollern. > Folgende Ideen gab es bereits: > > 1) Slave sendet zusätzlich zu den Daten einen MD5-Hash, der aus den > Daten selbst und einem ihm eindeutig zugewiesenen Key berechnet wird Ja, den Key kann man aus einem normalen Mikrocontroller auslesen. "Deckel ab", Flash und EEprom mit schwarzer Farbe abdecken, mit UV-Licht die "Code Protection Fuses" rücksetzen und ganz normal auslesen. Wenn Du den Schlüssel hast kannst Du beliebige Daten fälschen. > 2) Im Prinzip wie die erste Idee, allerdings kann anstelle eines > einzelnen Keys eine Art TAN-Liste für jeden Slave hinterlegt werden. > Entsprechend müssen ausreichend viele TANs hinterlegt sein, oder die > Möglichkeit bestehen neue TANs vom Server an den Client zu senden. Gleiches Problem. Man kann die TAN auslesen wie oben. Du kannst die Verbindung mit so was schützen, aber Du kannst keinen Angreifer der Zugriff auf die Hardware hat davon abhalten den Schlüssel auszulesen... zumindest nicht mit billiger Standardhardware... Was es gibt ist Folgendes: Du speicherst die Schlüssel im RAM. Du baust in Deine Schaltung einen Teil ein, der wenn ein Draht unterbrochen ist, die Versorgungsspannung für den Mikrocontroller schnell kurzschließt (unterbrechen reicht nicht, da bleibt die Spannung für viele Minuten noch hoch genug um den Speicherinhalt zu erhalten). Den isolierten aber dünnen Draht wickelst Du dann um Deine Schaltung in mehreren Lagen. Das ganze kommt dann in ein undurchsichtiges Gießharz. Gleichzeitig baust Du noch einen Temperatursensor ein, der bei Unterschreitung einer Minimaltemperatur die Schlüssel löscht. Mit dem kommst Du in einem Bereich in dem es ein Angreifer mit Sportsgeist schwierig hat. So was schaut dann so aus: http://www.puff65537.com/Home/4758-tear-down
Sebastian V. O. schrieb: > Schreiber schrieb: >> ...die Lockbits kann man einfach zurücksetzen. Hierzu muss man das >> Gehäuse öffnen und die Lockbits mit UV-Licht beleuchten. > > Und das Equipment dazu hat jeder Bastler im Keller? Nein nicht jeder, aber das meiste bekommt man im Baumarkt. So macht man solche Chips auf: http://media.ccc.de/browse/congress/2014/31c3_-_6084_-_en_-_saal_6_-_201412281130_-_uncaging_microchips_-_peter_laackmann_-_marcus_janke.html#video Die Lockbits kann man mit jeder UV-Lampe beleuchten, zur Not sogar mit Sonnenlicht. Vorher sollte man jedoch Flash und EEPROM abdecken, das geht mit schwarzer UV-undurchlässiger Farbe und einer ruhigen Hand. Microcontroller sind nicht so unglaublich winzig.
Sebastian V. O. schrieb: >> ...die Lockbits kann man einfach zurücksetzen. Hierzu muss man das >> Gehäuse öffnen und die Lockbits mit UV-Licht beleuchten. > > Und das Equipment dazu hat jeder Bastler im Keller? fast jeder und wenn nicht gibts alles erforderliche Zubehör preiswert bei ebay und in der Apotheke. Im wesentlichen brauchts dazu: ein paar Pipetten, Spritzflasche, feinen Pinsel, Zahnstocher, Glasschälchen und eine UV-Lampe An Verbrauchsmaterial brauchts zusätzlich: Nagellack, rauchende Salpetersäure und Aceton mit einigen µCs zum Üben und einem billigen Mikroskop kommt man recht einfach ans Ziel. Handschuhe und Schutzbrille sind noch ein sinnvolles Zusatzzubehör. Ulrich H. schrieb: > so dass es für einen Angreifer nicht so leicht > ist an den original Code des µC zu kommen was soll daran schwierig sein? µC auslesen und disasemblieren, fertig
Es kommt natürlich immer darauf an was man schützen will und vor wem. Die Variante mit Key und Lockbits ist schonmal deutlich besser als gar kein Schutz und sehr einfach zu implementieren. Rein aus Interesse würde mich ja mal interssieren ob hier schonmal jemand höchstpersönlich die Lockbits eines µcs mit privater Ausrüstung zurück gesetzt hat. Mit genug Aufwand kann man jede Sicherung überwinden. Auch noch so tolle Sensoren/Detektionsmechanismen lassen sich überwinden.
Mal eine ganz andere Idee zum Thema: Der Master macht über ISP ein Verify, dh. liest den gesamten Code. Im Zweifelsfall kann so der Master dabei sogar noch Firmwareupdates an alle Slaves verteilen. Ist natürlich die Frage, ob dafür genug Zeit bzw. Speicher im Master zur Verfügung steht. Der Nachteil ist natürlich, dass du dein Programm für jeden sichtbar über die ISP-Pins schickst...
Matt B. schrieb: > Bei den Slaves besteht grundsätzlich die Möglichkeit, dass durch > Unbefugte eine modifizierte oder eine andere Software aufgespielt wird > und dem Master dadurch gefälschte Daten gesendet werden. > > Eine Änderung der Slave-Hardware, um Eingriffe zu verhindern, ist nicht > möglich. > Wenn Du sagst "modifiziert", dann gehe ich mal davon aus, das der Code auf dem Slave Oscar bekannt ist. Diese Situation habe ich mal vor Jahren "Naked Eve" getauft, weil Oscar ALLE Informationen EINES Teilnehmers (Eve) kennt. Meines Wissens nach ist dann weder Verschlüsselung noch Signing sicher möglich. > > Die Frage ist nun, welche Methoden/Verfahren es gibt, die es dem Master > ermöglichen, dass der Client (Software-seitig) modifiziert wurde. Wenn Du die Software auf dem Slave vorgeben kannst und der Slave nicht gerade ein ATTiny sein muss, dann kannst Du folgendes Verfahren probieren: Dein Slave hat kein Program, das Daten sendet. Nur einen Bootloader. Beim PowerUp erhält der Slave sein Programm vom Master, legt es im RAM ab und führt es dann aus. Das runtergeladene Progamm enthält (u.a.) eine Verschlüsselungsroutine, der Key dazu ist auch im (runtergeladenen) Program. Um jetzt die Datenübertragung zu starten schickt der Master eine Initialisierungsanfrage mit einer Zufallszahl (challenge). Das runtergeladene Program antwortet mit einer verschlüsselten (!) Zahl, die aus der Zufallszahl und seiner eigenen Codechecksumme berechnet wird. Der Master prüft diese Antwort und "vertraut" dem Slave, wenn die Antwort OK ist. Der Trick: Der KEY, die VERSCHLÜSSELUNGSROUTINE und die POSITION von Key & Verschlüsselungsroutine im Code werdend bei jedem Download des Programms neu generiert, ist also Oscar nicht bekannt. Es ist nicht wirklich schwer, aus N+1 vorgefertigten Verschlüsselungsroutinen (.obj) randommäßig eine auszusuchen und diese an eine andere Stelle im Code zu "linken" (ok, es ist auch nicht trivial, aber machbar). Oscar kann keine Hardwareanalyse machen (nur Bootloader im Slave). MITM oder Sniffing bringen nur Informationen über die aktuelle Session (who cares, Du wolltest nur Manipulation verhindern). Cloning klappt auch nicht, da sich der Code bei jeder Session ändert und sein Hash am Anfang der Session geprüft wird. Auf "kleineren" Prozessoren kann man auch ein "Macroprogramm" übertragen, das bestimmte, im FLASH gepeicherte, Subroutinen in einer (dann jeweils anderen) Reihenfolge ausführt (Die Subs sollten dann natürlich nicht kommutativ sein ;-). Dann kommt man auch mit relativ wenig RAM aus. Hth Andreas
Mich würde mal interessieren was das für Geräte sind und worin die Motivation liegen würde sie zu manipulieren. Tintenpatronen vielleicht zufällig?
Auch wenn die Lock Bits und ähnliches nicht perfekt sind, sollte man sie auch nutzen. Je nach µC sind die auch nicht so einfach zu knacken. Wenn der Speicher im µC gelesen werden kann, ist die Verschlüsselung bei der Übertragung hinfällig, aber vorher sollte man natürlich vermeiden den Code bei der Übertragung Preis zu geben. Gegen einen µC mit mehr Speicher kann man sich einige Zeit schützen, indem man den größten verfügbaren Typ aus der Serie nutzt. Ein längeres Programm macht auch die Analyse schwerer. Nur ein Bootloader (mit Verschlüsselung) auf dem µC und den eigentlichen Code zu übertragen ist auch keine so schlechte Idee, braucht aber einen µC der dies erlaubt, und wenn möglich den Bootloader vor dem Zugriff aus dem normalen Code schützt.
Also die AVRs kann man meines Wissens NICHT mit UV entsperren sondern nur sperren. Die Lockbits werden beim löschen aufgeladen und beim sperren entladen (deswegen sind die auch "gefühlt" invertiert).
Ulrich H. schrieb: > wenn möglich den Bootloader vor dem Zugriff aus > dem normalen Code schützt. Warum ? Eigentlich sollte der Loader ja nicht sinnvoll manipulierbar sein, weil: Andreas H. schrieb: > Das > runtergeladene Program antwortet mit einer verschlüsselten (!) Zahl, die > aus der Zufallszahl und seiner eigenen Codechecksumme berechnet wird. Habe ich da in der Eile eine Lücke übersehen ? Grüße Andreas
P.S: Ulrich H. schrieb: > Nur ein Bootloader (mit Verschlüsselung) auf dem µC Bei meiner Idee oben wäre eine Verschlüsselung im Bootloader nicht notwendig (waste of FLASH). Lass Oscar doch sniffen. Das Problem ist ja nicht geheimhaltung, sondern Datenmanipulation ;-) Grüße Andreas
Der Ansatz, irgendwelche Keys, Prüfsummen, TAN Nummern etc zu verwenden ist sinnlos. Beispiel Prüfsumme vom Programmspeicher: Ein modifiziertes Programm kann einfach die erwartete Prüfsumme senden, anstatt eine von seinem Programm zu berechnen. Programme können so modifiziert werden, dass die was anderes machen und dennoch die gültigen Keys und TAN Nummern verwenden. Außerdem kann der ganze Mikrocontroller des Slave durch einen anderen ersetzt werden, der möglicherweise viel mehr Speicher hat. Bestes Beispiel sind die gefälschten Codekarten für Premiere Decoder (aus den 90ern). Selbst Spielkonsolen wurde schon durch modifizierte Firmware ergänzt, ohne dass die Server der Hersteller das bemerken konnten.
Max D. schrieb: > Also die AVRs kann man meines Wissens NICHT mit UV entsperren sondern > nur sperren. Die Lockbits werden beim löschen aufgeladen und beim > sperren entladen (deswegen sind die auch "gefühlt" invertiert). Nein. Der gelöschte und entladene Zustand ist "1", genauso wie beim EEPROM und beim Flash auch. UV-Licht entlädt es und setzt es damit auf 1. Irgendwo in Russland gibts ne Firma (hab leider die www Adresse nicht zur Hand, aber sollte zu finden sein) die lesen Dir jeden AVR aus, Preis ~$600 pro Stück. Also der Widerstand eines AVR-Lockbits beträgt somit ungefähr 600 Dollar.
:
Bearbeitet durch User
Dann würde mir noch die MSP430er Familie einfallen. Die haben eine irreversible Jtag-Fuse... Ansonsten wie die POS-Terminals machen: Die ganze chose im RAM halten und beim kleinsten Verdacht die Versorgung kurzschließen. Die Frage ist hier nur: Wer soll ferngehalten werden ? Ist das Problem ein Skript-kiddie das Telefonkarten wieder auflädt ? Oder ist dein Token der Zugang zu einer Schweizer Bank ? Der Aufwand muss immer im Verhältniss zum Ergebniss stehen. Bei dem erwähnten Kiddie reichen sicher die Lockbits. Echte 100% Sicherheit kann es nicht geben. Man kann aber den Zugang sehr schwer machen. Nicht umsonst werden "echte" (Hardware) Tresore danach klassifiziert wie lange ein Profi zum knacken braucht...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.