Guten Morgen, wollte euch mal fragen, ob es theoretisch möglich ist die Software eines Produktes über eine Debugschnittstelle wie JTAG/SWD zu hacken? Wenn ja, wie schützen sich moderne Unternehmen dagegen, dass die Software ihres Produktes gehacked wird? Danke! Gruß Manuel
Antwort 1: Nein. Jeder anständige Microkontroller kann gegen auslesen geschützt werden. Antwort 2: Mit beliebig viel Aufwand kann man fast alles "hacken". Oliver
Über die jtag schnittstelle kann man die software nicht "hacken". Bei fast allen chips kann man die jtag schnittstelle deaktivieren, teils sogar durch sogenannte fuses unumkehrbar wegbrennen. Es gibt spezielle unternehmen meist in china die z.b. Über diese schnittstelle dennoch an die binares kommen. Das geschieht aber nicht über software hacking sondern über hardware hacking Da kannst du nichts ändern.. Gibt sehr viele möglichkeiten.. Softwarehacks (z.b. Bufferoverflow) hardware hacks ( http://www.flylogic.net/blog/) Du kannst dich garnicht schützen auch nicht mit den sogenannten secure mcu's... Wenn einer 300000$in die hand nimmt bekommt er auch das raus. Für alte atmel mcu's reichen da schon 300$ :-) Grüße
Also ist eine Debug Schnittstelle nicht unsicherer in Bezug auf Software Piraterie als z.B. CAN oder USART? Wir möchten zukünftig den STM32 verwenden, also schon einen "etwas besseren µC". Dieser verfügt zusätzlich über eine Read out protection, welche ich mir nochmals genauer anschauen muss.. Ich dachte das es über eine Debugschnittstelle relativ einfach sein sollte die Software zu stehlen, scheitn ja aber nicht so zu sein.. Das Problem ist das wir Softwareupdates im Feld durchführen möchten und nun über die Schnittstelle unserer Wahl nachdenken. Wenn alles gleich "sicher" ist würde unsere Wahl auf JTAG/SWD fallen. Danke
Manuel Reisser schrieb: > Also ist eine Debug Schnittstelle nicht unsicherer in Bezug auf Software > Piraterie als z.B. CAN oder USART? 1. Falls Du vergißt, die JTAG-Schnittstelle zu deaktivieren, ist sie der Traum jeden Hackers. Er kann einfach einen Debugger anschließen, sich den Assembler-Code anschauen, das Verhalten studieren, Break-Points setzen usw. Ich kenne einen größeren Fall, wo versäumt wurde, eine solche Schnittstelle zu deaktivieren und dann die Geräte von findigen Tüftlern "getuned" wurden. 2. Du vergleichst Birnen mit Äpfeln: Eine CAN- oder USART-Schnittstelle ist so sicher oder unsicher, wie das Protokoll, das darauf läuft. Wenn Du deine JTAG-Schnittstelle an einen UART anschließt, ist Deine UART-Schnittstelle so unsicher wie Deine JTAG-Schnittstelle. CAN und USART sagen erstmal nichts darüber aus, was für Informationen damit transportiert werden. Du kannst über CAN Deine EC-Kartennummer plus Geheimzahl in Klartext transportieren. Ist CAN deswegen unsicher?
Manuel Reisser schrieb: > Das Problem ist das wir Softwareupdates im Feld durchführen möchten und > nun über die Schnittstelle unserer Wahl nachdenken. Dann brauchst Du eine Schnittstelle, die sich verschlüsseln läßt. Das geht mit JTAG/SWD (vermutlich) nicht. Du mußt also einen Bootloader schreiben, der dann entschlüsselt. Du mußt einmalig per JTAG/SWD den Bootloader + Schlüssel hineinprogrammieren und dann JTAG/SWD disablen. Peter
Hallo Bronco, du hast natürlich recht mit deinem 2. Punkt, sorry.. Es geht mir um ein Standard Can-Protokoll oder halt RS232.. Hallo Peter, kannst du mir das vielleicht genauer erklären "Bootloader, der dann entschlüsselt". Es war auch so gedacht das der Bootloader zunächst über JTAG aufgespielt wird. Wenn ich jedoch später im Feld über JTAG updaten möchte darf ich JTAG ja nicht disablen, oder? Danke
> Du mußt einmalig per JTAG/SWD den Bootloader + Schlüssel > hineinprogrammieren und dann JTAG/SWD disablen. Den Schlüssel dann in einen batteriegepufferten SRAM speichern und tamperdetections einbauen. z.B. Taster der bei öffnen des Gehäuses den Schlüssel löscht. Oder einen Lichtsensor, Bewegungsmelder, usw. Bei sicherheitskarten (z.B. Geldkarte) sind noch ein Kondensator auf dem Chip der bei sabotage noch schnell das EPROM löscht obwohl man schnell die Betriebssdpannung wegnimmt (z.B. nachdem man den PIN falölsch eingetippt hat) nen Fotosensor ist auch drin, und nen µm dicker Goldfaden der um den Chip gewickel ist und dessen Widerstand ständig gemessen wird. Bei richtig krassen Karten (z.B. um Atomwaffen als vernichtet zu buchen ) wird die gesammte Karte aus Silizium gefertigt damit man nur Flusssäure benutzen kann zum Ätzen und die zersetzt auch dem Chip. http://insecure.org/stf/tamperproof_smartcards.txt
Es reicht schon, wenn der Bootloader keine Möglichkeit zum Auslesen des des Codes hat. Wenn dann die JTAG Schnittstelle deaktiviert ist bzw. die Security ID (oder wie auch immer das beim STM heißt) aktiviert ist, dann reicht das wohl für die meisten Anwendungen. Die Updatesoftware am PC kann folgendermaßen überprüfen, ob der Flashvorgang erfolgreich war: Der µC sendet nach dem Flashen die CRC des Flashinhalts. Die Software berechnet die CRC auch und vergleicht.
Wenn ihr im Feld über JTAG programmieren wollt kannst du alles vergessen was zum Bootloader gesagt wurde. Du brauchst keinen. Beim STM32 kann man nach dem programmieren das Flash vor Auslesen schützen, dann kommt man auch mit JTAG nicht mehr ran. Bevor man dann ein Update einspielen kann muss man die Protection wieder deaktivieren. Kennt man den Schlüssel nicht, so kann man die Protection auch deaktivieren, der STM32 löscht dann aber das ganze Flash. Was ja nichts ausmacht, wenn man eh ein neues Programm aufspielen will.
Das gilt natürlich nur, fasll Updates nur von vertrauenswürdigen Personen durchgeführt werden. Wenn Software auch an Kunden herausgegeben werden soll in Form von Lademodulen, dann vergiss JTAG und was ich oben gesagt habe und siehe oben "Peter Dannegger".
Hallo, ich bin momentan noch ein wenig überfragt was ihr mit "Schlüssel" meint. Eine Option im Feld upzudaten wird ein eigens geschriebenes Protokoll sein, welches über CAN kommuniziert. Die andere Option soll JTAG bleiben, falls es bei Option A zu irgendwelchen Problemen kommen sollte. Updates werden normalerweise nur von vertrauenswürdigen Personen durchgeführt Danke für eure Hilfe
Manuel Reisser schrieb: > ich bin momentan noch ein wenig überfragt was ihr mit "Schlüssel" meint. Der Punkt ist: 1. Darf jederman eine x-beliebige Firmware aufspielen? Dann ist es ganz einfach: Einen Bootloader schreiben, mit dem man das Flash schreiben, aber nicht auslesen kann - fertig. Nachteil: Falls jemand so clever ist, eine getuned-te Firmware zu basteln (z.B. indem er Dir ein saftiges Schmiergeld für die Sourcen gezahlt hat), kann er diese problemlos auf Dein Gerät aufspielen. Z.B. im Automotive-Geschäft das berüchtige "Chip-Tuning". 2. Darf nur eine authorisierte Person eine Firmware aufspielen? Dann muß im µC ein Paßwort o.ä. hinterlegt sein, daß diese Person kennen und richtig angeben muß, um eine neue Firmware aufspielen zu können. 3. Darf nur eine authorisierte (vom Hersteller signierte ) Firmware aufgespielt werden? Dann muß diese Firmware eine Signatur enthalten (siehe Public-Key-Verfahren), die mit einem im µC hinterlegten Key kryptografisch auf Echtheit geprüft wird (ähnlich PGP). Falls die Signatur nicht paßt, wird die Firmware nicht akzeptiert. Das ist aber sehr aufwendig.
Hallo, zu Punkt 2: wie wird dieses Passwort im µC hinterlegt? das Passwort dient dann nicht nur zum neu aufspielen einer Software sondern auch zum Schutz vor herauslesen der Software, richtig?
Manuel Reisser schrieb: > wie wird dieses Passwort im µC hinterlegt? Das liegt in Deiner künstlerischen Freiheit, bzw. an Deinen Anforderungen. Du kannst es als Konstante im Flash ablegen, oder als Variable im EEPROM ablegen, oder nach einem Algorithmus abhängig vom Datum berechnen... > das Passwort dient dann nicht nur zum neu aufspielen einer Software > sondern auch zum Schutz vor herauslesen der Software, richtig? Das liegt in Deiner künstlerischen Freiheit, bzw. an Deinen Anforderungen. Überleg mal, welchen Anwendungsfall es wirklich gibt, wo man das Programm-Flash auslesen muß! Setzen wir mal folgendes heraus: 1. Du hast eine saubere Versionierung Deiner Firmware, d.h. Du kannst eindeutig zuordnen, welche Firmware sich augenblicklich im Flash befinden sollte, wenn Du die Versionsinformation ausliest. 2. Du hast einen Mechanismum in der Firmware (z.B. CRC über der Programmcode), mit dem der µC selbständig ermitteln kann, ob sein Programmcode korrekt und integer ist. Wenn Du nun weißt, daß die Version 1.23 drinn sein sollte (weil Du die Versionsinformation 1.23 ausgelesen hat) und der µC geprüft hat, daß sein Programmcode korrekt und integer ist, dann weißt Du ganz genau, daß der Flash-Inhalt 1:1 Deinem Hexfile V1.23 entspricht. Wozu also noch auslesen?
Hi Bronco, danke, hast mir weitergeholfen! Und wie deaktiviere ich die JTAG Schnittstelle wenn ich das machen wöllte?
Manuel Reisser schrieb: > danke, hast mir weitergeholfen! Aber mach bitte nicht einfach blind das, was wir Dir hier empfehlen! Außer Dir kennt keiner im Forum Dein Projekt! Was für Dein Projekt richtig ist, hängt von Deinem Projekt ab, von den Anforderungen, vom Lastenheft, vom Pflichtenheft. Gehirn einschalten und selber überlegen: was brauch ich und was nicht. Was wünscht der Auftraggeber? Was geben eventuelle Normen vor (z.B. Eichpflicht, Manipulationssicherheit usw.)? Und nicht päbstlicher sein als der Pabst! Eine offene Debugschnittstelle kann auch eine große Hilfe sein, falls ein Fehler auftritt, der sich nur bei einem bestimmten Kunden vor Ort reproduzieren läßt. Dann gehst Du dort hin und kannst direkt mit dem Debugger nachgucken, wo's hängt. Wie gesagt, es hängt von Deinen Anforderungen ab.
Profi schrieb: > geht nicht beim STM32 Also hab ich garkeine andere Wahl als die JTAG Schnittstelle offen zu lassen und mit einem Schlüssel zu sicher, seh ich das richtig?
Profi schrieb: > geschützt wird nicht die JTAG Schnittstelle sondern das Flash. Gegen Auslesen. Das mach ich mir der Read-out-protection, richtig? damit sollte ich ja weiterhin in der Lage sein das Flash zu bschreiben, oder nicht?
Manuel Reisser schrieb im Beitrag... > Also hab ich garkeine andere Wahl als die JTAG Schnittstelle offen zu > lassen und mit einem Schlüssel zu sicher, seh ich das richtig? > Das mach ich mir der Read-out-protection, richtig? > damit sollte ich ja weiterhin in der Lage sein das Flash zu bschreiben, > oder nicht? Sag mal, ist es so schwer, das Datenblatt Deines µCs zu lesen? Da steht doch alles drinn!
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.