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
So wie ich es bisher gesehen habe lässt es sich nicht auslesen wenn die lockbits gesetzt sind.
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.
Wer für den Schlüssel ein externes EEPROM nimmt sollte sich eh nen anderen Beruf wählen.
Das ist richtig, aber die Kreativität von Entwicklern treibt zuweilen recht bunte Blüten ;)
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.