Hallo zusammen,
hätte eine Frage wegen Programmsicherung.
Wenn ich die Lockbits z.B. Mega8 setze ist der Controller ja gegen
auslesen abgesichert,
wenn ich aber nun ein update anbieten möchte und demjenigen die HEX
zukommen lasse hat er ja das Programm.
Gibt es die Möglichkeit eine Hex ins Flash aufzuspielen das dann ein
Passwort das im Eprom hinterlegt ist vergleicht ohne dass man das Eprom
auslesen kann.
Weil wenn man den Chip neu programmiert sind ja alle Locks wieder weg
somit könnte man das Eprom wieder auslesen.
Ich hoffe ihr versteht meine Frage.
Gruß
Andy
Hallo
Was du meinst ist ein Bootloader der eine verschlüsselte Firmware
entgegen nimmt, entschlüsselt und dann flasht.
Ob es was bringt ist eine andere sache, denn wenn dein Programm wirklich
was Wert ist, wird sich jemand finden der es trotz Lockbits ausließt
oder auslesen lässt.
Es gibt Firmen die das anbieten, auch hier im Forum schon gesehen.
da1l6
Du willst einen Kopierschutz bauen?
Du möchtest in deinem Programm eine Abfrage machen, welche im EEPROM
einen Schlüssel ausliest, ohne den das Programm nicht laufen würde?
Du lieferst ja mit der HEX das Programm. Was hindert mich daran, die HEX
nun soweit zu analysieren, dass ich selbst den gesuchten Schlüssel ins
EEPROM schreiben kann, oder was hindert mich daran, dein Programm so zu
verändern, dass die Abfrage nicht mehr benötigt wird?
Guest schrieb:> Du möchtest in deinem Programm eine Abfrage machen, welche im EEPROM> einen Schlüssel ausliest, ohne den das Programm nicht laufen würde?
Soweit ich das verstanden habe, soll die HEX Datei bereits verschlüsselt
sein. Der bereits im (gegen Auslesen gesicherten) Controller befindliche
Bootloader entschlüsselt mit den im EEPROM befindlichen Daten
(Schlüssel) die HEX Datei und brennt das Ergebnis ins FLASH.
> Du lieferst ja mit der HEX das Programm. Was hindert mich daran, die HEX> nun soweit zu analysieren, dass ich selbst den gesuchten Schlüssel ins> EEPROM schreiben kann, oder was hindert mich daran, dein Programm so zu> verändern, dass die Abfrage nicht mehr benötigt wird?
Dich hindert die Tatsache, dass du eine verschlüsselte HEX hast.
Ein weiterer Vorteil wäre, dass man Updates pro Controller verkaufen
könnte, indem man jedem Controller einen eigenen Schlüssel verpasst.
Es ist möglich mit einem asymmetrischen Verfahren das zu realisieren,
also wie bei PGP einen private und public key erzeugen.
Den private key wie schon erwähnt als Sicherung in einen verschlüsselten
Bootloader/Firmware packen und dann mit dem public key die neue Firmware
ausstatten und dort den neuen private key einbauen.
Da der aktuelle private key in der verschlüsselten Firmware ist gibt es
kaum eine Möglichkeit den zu kompromittieren.
Natürlich jedesmal in der neuen Firmware neue Schlüssel verwenden.
Asymmetrische Kryptographie allein ist hier vollkommen fehl am Platze da
sie wesentlich längere Schlüssellängen verwendet und damit auch höhere
Anforderungen an die Plattform in Bezug auf RAM und Rechenleistung
stellt. Deswegen wird asymmetrische Kryptographie auch in der Regel nur
verwendet um symmetrische Schlüssel zu verschlüsseln und anschließend
sicher auszutauschen. Und warum sollte ein neuer private Schlüssel in
das Firmware-Update eingebaut werden? Wenn überhaupt muss der private
Schlüssel vom Controller selber generiert und intern gespeichert werden,
ansonsten ist er nicht mehr privat.
Sofern man also eine gewisse Sicherheit braucht und den genannten Atmega
nutzen muss empfiehlt sich Folgendes:
1. Controller mit einem Bootloader versehen welcher Firmware-Updates
über externe Schnittstellen (z.B. UART) entgegennehmen und entschlüsseln
kann
2. Controller mit einem individuellen symmetrischen Schlüssel versehen
welcher im EEPROM persistent hinterlegt wird und dem Bootloader
zugänglich ist
3. Firmware-Updates für jeden Controller mit dem jeweiligen Schlüssel
verschlüsseln
4. Dem Kunden ein Tool zur Verfügung stellen welches Firmware-Updates
zum Controller (d.h. an den Bootloader) übermittelt
5. Lockbits nach Anforderung setzen
Das bietet allerdings nur eine sehr grundlegende Absicherung, da gerade
günstige Controller keinerlei Sicherheitsmaßnahmen wie tamper detection
oder tamper resistance bieten. Zudem können, je nach verwendeten
Kryptoalgorithmen und Implementierungen Seitenkanalangriffe durchgeführt
werden mit welchen sich kryptographische Schlüssel ermitteln lassen. Ob
solche Angriffe eine Gefahr sind hängt davon ab, welchen Nutzen ein
Angreifer von einem Erfolg hat.
Andy schrieb:> wenn ich aber nun ein update anbieten möchte und demjenigen die HEX> zukommen lasse hat er ja das Programm.
Nö, ein Hex ist kein Programm. Man kann es disassemblieren, aber das
macht es nicht verständlicher. Alle Namen und Kommentare sind weg.
Ob sich das jemand antut, hängt von der Schöpfungshöhe ab, die muß dann
schon sehr hoch sein.
Er kann natürlich mit dem Hex das ganze Gerät nachbauen, wenn er auch
den Schaltplan dazu hat.
Beschreib dochmal Deine super duper Erfindung. Dann kann man besser
einschätzen, ob überhaupt ein Schutz notwendig ist und welcher.
Peter Dannegger schrieb:> Nö, ein Hex ist kein Programm. Man kann es disassemblieren, aber das> macht es nicht verständlicher. Alle Namen und Kommentare sind weg.
Das ist doch gerade der Sinn des Disassemblierens? Dadurch erhalte ich
aus dem erstmal unverständlichen Hexcode Assembler und kann damit ggf.
schonmal auf gewisse Funktionalität schließen. Disassembler wie IDA Pro
liefern hier bereits automatisiert erstaunlich gute Ergebnisse.
Peter Dannegger schrieb:> Ob sich das jemand antut, hängt von der Schöpfungshöhe ab, die muß dann> schon sehr hoch sein.
Entweder von der Schöpfungshöhe oder vom Wert der gespeicherten Daten
(z.B. kryptographische Schlüssel), das ist richtig.
Sven schrieb:> Peter Dannegger schrieb:>> Nö, ein Hex ist kein Programm. Man kann es disassemblieren, aber das>> macht es nicht verständlicher. Alle Namen und Kommentare sind weg.>> Das ist doch gerade der Sinn des Disassemblierens? Dadurch erhalte ich> aus dem erstmal unverständlichen Hexcode Assembler und kann damit ggf.> schonmal auf gewisse Funktionalität schließen.
Hast du das schon mal gemacht? Mit einem AVR-Hex?
Dann probiers mal. Und dann: viel Spass bei der Analyse.
Es mag hier ja viele Poser geben, aber ja, habe ich. Und
selbstverständlich ist es nicht gerade trivial, das wollte ich auch gar
nicht sagen. Aber mit ein wenig Erfahrung kann man doch schon recht viel
über ein Programm herausfinden. Wenn man weiß, dass SPDR auf RAM-Adresse
0x002F gemappt ist, dann braucht man beispielsweise den disassemblierten
Code nur auf Schreib-/Lesezugriffe auf diese Adresse zu durchsuchen um
zu wissen, dass eine Datenübertragung über SPI stattfindet- Anschließend
kann man sich weiter nach oben hangeln und prüfen, welche Daten
übermittelt werden. Und dann sieht man vielleicht, dass zunächst per SPI
ein externes EEPROM gelesen wird und die empfangenen Daten in eine
Entschlüsselung fließen. Weitere Untersuchungen zeigen dann, dass die
Daten dort als Schlüssel verwendet werden. Und schon hat man alle Infos
um den Schlüssel aus dem EEPROM zu extrahieren und selbst zu verwenden.
Das nur als Beispiel, es kommt natürlich auf das jeweilige Ziel an.
