Ich möchte ein Elektronikprojekt zum nachbauen freigeben, jedoch unbegrenztes kopieren erschweren. Gibt es da bewährte Verfahren? Der Nutzer soll sich die Elektronik nach meinen Fertigungsdateien selbst beim bestücker bestellen und dann einen Bootloader aufspielen, dann mir die UID mitteilen und von mir die endgültige Software bekommen. Es sollte also eine Signaturverifikation im Bootloader basierend auf einer UID (zufallsgeneriert oder Hardware-mac...) und einem mit dem Bootloader mitgelieferten Public Key passieren. Den Private Key dazu behalte ich für mich. Vielleicht überprüft der BL vorher noch die Readout-protection bits. Aktuelles Target: CH32V208 Gibt es da quelloffene Bootloaderprojekte für sowas? Vielleicht im universum der UEFI-Firmwares?
Flip B. schrieb: > Ich möchte ein Elektronikprojekt zum nachbauen freigeben, jedoch > unbegrenztes kopieren erschweren. Gibt es da bewährte Verfahren? Der > Nutzer soll sich die Elektronik nach meinen Fertigungsdateien selbst > beim bestücker bestellen und dann einen Bootloader aufspielen, dann mir > die UID mitteilen und von mir die endgültige Software bekommen. Ich glaube, von Dir würde ich nix nachbauen wollen ...
Jens G. schrieb: > Ich glaube, von Dir würde ich nix nachbauen wollen ... Okay, das tut zwar nichts zum Thema, aber magst du Gründe nennen? Oder ist es einfach nur ein fescher Spruch der dir in die Tastatur gefallen ist?
Flip B. schrieb: > Jens G. schrieb: >> Ich glaube, von Dir würde ich nix nachbauen wollen ... > > Okay, das tut zwar nichts zum Thema, aber magst du Gründe nennen? Oder > ist es einfach nur ein fescher Spruch der dir in die Tastatur gefallen > ist? Eigentlich ganz einfach: ich mag keine künstliche Abhängigkeiten ... Wenn mir der µC irgendwann mal kaputt geht, muß ich wieder bei Dir antraben, um nach einer neuen SW zu betteln ... Kennt man ja schon von ELV - man kann mit deren geflashten µCs/Speichern nachbauen, aber Ersatz gibts dann nach gewisser Zeit keinen mehr.
:
Bearbeitet durch User
Okay, kann ich nachvollziehen, ich würde auch sehr gern das ganze Projekt veröffenltichen. Leider würden vorhersehbar einige das Ding Serienfertigen lassen und daraus Profit schlagen, bzw. ihre Produkte statt mit teureren Kommerziellen lösungen, mit der Hardware bauen, aber die ersparnis aus dem Einkauf nicht an die endkunden weitergeben. Bei Hardware ist es in meinen Augen auch schwer, etwas über lizensbedingungen einzuschränken, wenn das in einem Produkt tief drin ausgeliefert wird, interessiert das keinen käufer, so lange es funktioniert. Alternative zum seriennummergebundenen Binary-Blob o-ä- wäre einfach nicht-veröffentlichung.
:
Bearbeitet durch User
Flip B. schrieb: > Okay, kann ich nachvollziehen, ich würde auch sehr gern das ganze > Projekt veröffenltichen. Leider würden vorhersehbar einige das Ding > Serienfertigen lassen und daraus Profit schlagen, bzw. ihre Produkte > statt mit teureren Kommerziellen lösungen, mit der Hardware bauen, aber > die ersparnis aus dem Einkauf nicht an die endkunden weitergeben. Ja, kann ich auch nachvollziehen. Ansonsten kann ich zur eigentlichen Frage auch nix sagen ...
:
Bearbeitet durch User
Ich finde den Ansatz durchaus interessant! Der Komponenten-Tester hier aus dem Forum ist doch das beste Beispiel dafür, wie die Chinesen aus unseren Innovationen Geld machen. Sicherlich kann man das so nicht verhindern, aber zumindest erstmal die erste Hürde erhöhen. Ist eben nur die Frage, ob der Autor so einer Firmware bereit ist, sich diesem administrativen Aufwand (individuelle Keys für jeden User zu generieren) zu stellen. Vielleicht sollte man mal darüber nachdenken, für diese Art von Validierung ein zentrales Portal zu schaffen, bei dem sowas automatisiert passiert. Zu Ende gedacht ist das sicher nicht, aber komplett verwerfen würde ich das auch nicht.
:
Bearbeitet durch User
Flip B. schrieb: > Leider würden vorhersehbar einige das Ding > Serienfertigen lassen und daraus Profit schlagen Ganz einfache Frage: was machst du, wenn jemand deine Softwareverschlüsselung „knackt“ (was ja wohl kein Problem sein sollte), und das Produkt dann weiterverkauft. Ja, das darf der dann nicht, aber hast du die Mittel, dagegen anzugehen? Oliver
Wenn Du Bootloader und die vermutlich verschlüsselte Software herausgibts hat man alles um den Schutz zu umgehen, also z.B. die verschlüsselte Software zu entschlüsseln oder die Signaturprüfung zu patchen. Das "Geheimnis" (Schlüssel oder Bootloader) muss schon vorher möglichst sicher in der Hardware abgelegt sein damit der Schutz sinnvoll ist.
:
Bearbeitet durch User
Oliver S. schrieb: > Ganz einfache Frage: was machst du, wenn jemand deine > Softwareverschlüsselung „knackt“ (was ja wohl kein Problem sein sollte), > und das Produkt dann weiterverkauft. Ohne die Verschlüsselungsmethode und ihre Implementierung zu kennen sagst du, dass es kein Problem sein sollte, sie zu knacken? Könntest Politiker werden … Abgesehen davon halte ich den Ansatz für hinterfragbar: Wenn das Projekt vom TE nicht selbst zu Geld gemacht werden soll, ist’s doch unerheblich, ob jemand das nachbaut und verkauft? Wenn man seinen Namen noch geschickt drin unterbringt, könnte man’s dann ja so auch zu einiger Bekanntheit bringen. Und wenn es wirklich so gut ist, dass jeder es haben wollen würde, dann könnte man über eine Patentanmeldung oder/und Lizenzen nachdenken. Das würde vielleicht den auf Nachbau spezialisierten Chinesen nicht stören, aber man könnte sich von den Leuten entschädigen lassen, die’s in größerer Stückzahl im außerchinesischen Markt in Verkehr bringen …
Jack V. schrieb: > Ohne die Verschlüsselungsmethode und ihre Implementierung zu kennen > sagst du, dass es kein Problem sein sollte, sie zu knacken? Nun ja, er verteilt den bootloader mit dem darin enthaltenen public key. „Knacken“ muß man da natürlich gar nichts, nur etwas Assembler können, um den bootloader zu modifizieren. Oliver
Jack V. schrieb: > Und wenn es wirklich so gut ist, dass jeder es haben wollen würde, > dann könnte man über eine Patentanmeldung oder/und Lizenzen nachdenken. Du kennst die Kosten für Patente, zumal so ein Patent für jeden Einzelstaat/-region erteilt werden muss? Nachdenken alleine hilft nicht - dafür wandert ordentlich Kohle über den Tisch. Das fängt beim Patentanwalt an. Das muss so ein Projekt erstmal einspielen, d.h. man muss sich über den Bedarf in der Welt sehr im Klaren sein.
:
Bearbeitet durch User
Flip B. schrieb: > selbst beim bestücker bestellen ... > Aktuelles Target: CH32V208 Also China Bestücker, mit China PCB und China Teilen. Aber die Chinesen sollen es nicht nachbauen können wenns so richtig zündet. Weil Chinesen ja keine SW schreiben können? Dafür möchtest Du dich dann mit 10.000 UID Anfragen herumschlagen. Für lau. Bei der großartigen Idee gibst Du dem Chinesen die beste aller Steilvorlagen. Ich würde dem Chinesen das doppelte bezahlen, nur damit ich nicht alles selbst regeln und machen muss. Zudem sind Einzelstücke beim Bestücker unverhältnismäßig teuer. Flip B. schrieb: > Gibt es da quelloffene Bootloaderprojekte für sowas? Noch besser! Sogar diese Arbeit soll Dir abgenommen werden. Und der BL Programmierer soll bitteschön keine Maßnahmen gegen unbegrenztes Kopieren ergriffen haben. Geb es frei oder lass es. Ein wenig freigeben weil Du keinen Bock auf HW hast und es Dir offenhalten willst an der SW zu verdienen, ist kein Plan. Lass doch einfach mal 100Stk bauen und vertreibe die inkl. SW über einen Partner der sich um das rechtliche kümmert. Das kommt dem Kunden billiger und bringt Dir ein wenig Geld.
Rainer W. schrieb: > Das muss so ein Projekt erstmal einspielen, d.h. man muss sich über den > Bedarf in der Welt sehr im Klaren sein. Das wollte ich mit „Und wenn es wirklich so gut ist, dass jeder es haben wollen würde, […]“ gesagt haben, ja. Für die Kosten fände sich bei einem solchen Produkt eine Lösung. Oliver S. schrieb: > Nun ja, er verteilt den bootloader mit dem darin enthaltenen public key. > „Knacken“ muß man da natürlich gar nichts, nur etwas Assembler können, > um den bootloader zu modifizieren. Denkbar wäre vielleicht ein Programm zum Beschicken des μC mit der Firmware. Das könnte die eindeutige ID des Controllers auslesen und an den TE schicken. Dessen Gegenstück könnte dann die Firmware so modifizieren, dass sie nur auf dem betreffenden Controller lauffähig ist, und sie verschlüsselt an das besagte Programm zurückschicken, das den Blob on teh fly entschlüsselt, auf den μC schreibt und dessen Leseschutz aktiviert. Klar könnte man nun mit „aber wenn man nur ’n bisschen mit Assembler …“ zu argumentieren versuchen, aber dann frage ich: „Und warum passiert das nicht allenthalben, wenn milliardenfach Firmware-Updates auf diesem Weg in Hardware gebracht werden?“ Ich halte es aber weiterhin für den falschen Weg, die Verbreitung auf diesem Weg kontrollieren zu wollen, wenn nicht selbst kommerzielle Interessen bestehen. In jedem anderen Fall würde schließlich keinem ein Schaden entstehen, wenn jemand das Produkt zu Geld macht. Ich meine: Das gesamte Internet und vieles an heutiger Elektronik gibt es im Grunde nur, weil genau das gemacht worden ist – in wirklich vielen komplexeren Produkten ist freier Code drin.
Abstrakt ausgedrückt, du möchtest den Supply Chain kontrollieren ohne den Supply Chain zu kontrollieren. Das funktioniert nicht. Was auch nicht funktioniert ist Copyright auf deine Software. Besonders nicht, wenn du dadurch zum Nachbau animierst dass du die Schaltung veröffentlichst. Nebenbei bemerkt, wenn du die Schaltung veröffentlichst ist das eigenständige Programmieren einer kompatiblen Software reine Fleißarbeit. So besonders wird deine Software nämlich nicht sein. Die gute und gleichzeitig schlechte Nachricht ist dass die Wahrscheinlichkeit dass dein Projekt ein Hit wird gering ist. Dass heißt deine Sorge dass ein chinesischer Hersteller die Massenproduktion auf nimmt ist eher unbegründet. Das ist mehr so ein Sechser im Lotto. Wenn du absolut nicht damit leben kannst dass irgend jemand mit deinem Projekt Geld verdient dann veröffentliche es nicht.
Jack V. schrieb: > Klar könnte man nun mit „aber wenn man nur ’n bisschen mit Assembler …“ > zu argumentieren versuchen, aber dann frage ich: „Und warum passiert das > nicht allenthalben, wenn milliardenfach Firmware-Updates auf diesem Weg > in Hardware gebracht werden?“ Weil in diesen Fällen der Key zum Entschlüsseln nicht öffentlich geliefert wird - wie der Fragesteller das aber vor hat und du es auch vorgeschlagen hast: > an das besagte Programm zurückschicken, das > den Blob on teh fly entschlüsselt, Was dieses besagte Programm nur kann wenn es den Entschlüsselungs-Key hat und dieses Programm ist in den Händen des Angreifers. Das Szenario funktioniert wenn der Entschlüsselungs-Key über einen separaten Weg in die Hardware gebracht wurde. Ohne dass ein Angreifer Zugriff entlang des Weges hat und ohne dass der Key oder die entschlüsselte Firmware aus der Hardware ausgelesen werden können.
Jack V. schrieb: > Denkbar wäre vielleicht ein Programm zum Beschicken des μC mit der > Firmware. Das könnte die eindeutige ID des Controllers auslesen und an > den TE schicken. Dessen Gegenstück könnte dann die Firmware so > modifizieren, dass sie nur auf dem betreffenden Controller lauffähig > ist, und sie verschlüsselt an das besagte Programm zurückschicken, das > den Blob on teh fly entschlüsselt, auf den μC schreibt und dessen > Leseschutz aktiviert. Der Zielprozessor hat 128kB Flash, 64kB Ram, und 144Mhz. Da geht nix „on the fly“. Und solange du Zugriff auf den bootloader mit Key und Entschlüsselungsalgorithmus hast, ist das alles eh nutzlos. Die einzige sichere Lösung in den Fall wäre, nicht die Software zu verschicken, sondern den fertig programmierten Prozessor. Aber dann muß den jemand auflöten… Oliver
Oliver S. schrieb: > Die einzige sichere Lösung in den Fall wäre, nicht die Software zu > verschicken, sondern den fertig programmierten Prozessor. Aber dann muß > den jemand auflöten… Was ja kein Problem wäre - es soll ja zum Nachbauen sein.
Flip B. schrieb: > Der Nutzer soll sich die Elektronik nach meinen Fertigungsdateien selbst > beim bestücker bestellen und dann einen Bootloader aufspielen, dann mir > die UID mitteilen und von mir die endgültige Software bekommen. Darauf lässt sich niemand ein, schätze ich. Das Risiko ist viel zu hoch, dass du die Software nicht lieferst oder sie nicht funktioniert. Dann bleibt man auf der (teuren) Hardware sitzen. Und was ist wenn der Mikrocontroller ausgetauscht werden muss? Derartig verdongelte Software war schon in den 90er Jahren verhasst und ist inzwischen kaum noch anzutreffen. Die Kombination mit einem quasi raubkopierten STM32 finde ich ganz besonders fragwürdig.
:
Bearbeitet durch User
Flip B. schrieb: > Leider würden vorhersehbar einige das Ding Serienfertigen lassen und > daraus Profit schlagen, bzw. ihre Produkte statt mit teureren > Kommerziellen lösungen, mit der Hardware bauen, aber die ersparnis aus > dem Einkauf nicht an die endkunden weitergeben Na und? Ist das dein Problem? Wer anderen nicht die Butter auf dem Brot gönnt ist selbst nicht viel besser. Gibst du denn einen Teil deiner Einnahmen an die Entwickler der kostenlosen Tools und Programmcodes ab, die du in dem Projekt verwendest?
:
Bearbeitet durch User
Oliver S. schrieb: > Der Zielprozessor hat 128kB Flash, 64kB Ram, und 144Mhz. Da geht nix „on > the fly“. Ich meinte, schrieb und du zitiertest es, dass das Programm zum Beschicken des μCs die Entschlüsselung on teh fly vornehmen, das Ergebnis auf den Controller schreiben und diesen dann zusperren solle. Wie gesagt – es ist ja nicht so, dass das Prinzip sonderlich neu wäre oder gar erst noch erfunden werden müsse. Das wird in etwa so gemacht.
Jack V. schrieb: > Ich meinte, schrieb und du zitiertest es, dass das Programm zum > Beschicken des μCs die Entschlüsselung on teh fly vornehmen, das > Ergebnis auf den Controller schreiben und diesen dann zusperren solle. Und ich schrieb, egal, was du da auch anstellst, irgendwo kommst du an die entschlüsselte Software, ohne allzu großen Aufwand. Wenn die Entschlüsselung auf dem PC passiert, geht die unverschlüsselte Software über die Schnittstelle, und kann einfach mitgeschnitten werden. Wenn da noch eine Verschlüsselungsschicht dazwischen sitzt, musst du halt den bootloader anpassen. Da steckt die Entschlüsselung und der Key drin. Oliver
:
Bearbeitet durch User
Ich habe sowas vor einiger Zeit mal gemacht. Verwendet habe ich XTEA. https://de.wikipedia.org/wiki/Extended_Tiny_Encryption_Algorithm. Den Key habe ich mir aus der UUID der CPU gebildet. Zusätzlich wurde die FW per CRC gesichert. Das hat ganz gut funktioniert, und man konnte den USB Mitschnitt nicht mehr direkt verwenden da erst im Loader entschlüsselt wurde. Allerdings ist es ein erheblicher Aufwand die Binaries bereitzustellen. Sowas über einen längeren Zeitraum automatisch bereitzustellen ist ein erheblicher Aufwand. Du willst die Binaries sicher nicht von Hand erzeugen und per Email verteilen. Ein Problem mit den UUIDs sehe ich in den potentiell schwachen Schlüsseln da diese Nummern sich ziemlich ähnlich sind und keinesfalls Zufallszahlen sind. Es stellt sich halt die Frage ob der Aufwand gerechtfertigt ist. Wenn das wirklich die Killer App wird wird sich ziemlich schnell jemand finden der den Loader dissassembliert.
Thomas Z. schrieb: > und man konnte den USB > Mitschnitt nicht mehr direkt verwenden da erst im Loader entschlüsselt > wurde. Ihr lest alle nicht was er machen will: Flip B. schrieb: >> Der Nutzer soll ... einen Bootloader aufspielen, Das heißt der Nutzer hat den Bootloader mit dem Entschlüsselungs-Key und -Algorithmus VOR SICH LIEGEN damit er ihn selber auf dem µC einspielen kann. Damit bricht die ganze Scheiße von wegen irgendwie klever im Bootloader eine Firmware zu entschlüsseln zusammen. Denn unter anderem ist damit folgendes möglich: Der Entschlüsselungs-Key kann aus dem vorliegenden Bootloader-Binary extrahiert werden kann. Damit, und dem richtigen Algorithmus, der auch im vorliegenden Binary implementiert ist, kannst du eine Firmware auf dem Trocknen außerhalb des µC entschlüsseln. Der Bootloader kann vor dem Einspielen gehackt werden, so dass er nach der ganzen Kryptographie-Augenwischerei im µC die entschlüsselte Firmware über einen Ausgabe des µC im Klartext ausgibt. Die geplante Singnaturverifikation kann aus dem Bootloader vor dem Aufspielen rausgepatcht werden. Dann wird keine Signatur mehr verifiziert. Kannst du also alles knicken.
Hannes J. schrieb: > Das heißt der Nutzer hat den Bootloader mit dem Entschlüsselungs-Key und > -Algorithmus VOR SICH LIEGEN damit er ihn selber auf dem µC einspielen > kann. Das ist richtig. Dazu muss das Loader Binary aber erst mal disassembliert und verstanden werden. Das ist schon mit etwas Aufwand verbunden. Der User kennt weder den Key noch den Algorithmus. Die einzige Info ist, dass der Key irgendwie aus der UUID gebildet wird. Natürlich kann man sowas hacken. Ich habe selbst schon TEA gehackt aber nur weil der Programmierer Konstanten verwendet hat die dann via Google direkt zum Beispiel Algo führten. Wenn man solche Bugs einbaut, kann man das auch gleich sein lassen.
Thomas Z. schrieb: > Das ist richtig. Dazu muss das Loader Binary aber erst mal > disassembliert und verstanden werden. Ja und? Wenn das supergeheime Projekt so einen wirtschaftlichen Erfolg verspricht, dann wird sich dafür schon jemand finden. Letztendlich muß man ja nur die Stelle finden, an der geprüft wird, daß der Prozessor gegen Auslesen geschützt ist, dazu den CRC-Vergleich, und die raus-NOPen.Danach findet man das entschlüsselte Programm im Speicher. Oliver
:
Bearbeitet durch User
Thomas Z. schrieb: > > Das ist richtig. Dazu muss das Loader Binary aber erst mal > disassembliert und verstanden werden. Das ist schon mit etwas Aufwand > verbunden. Was bei einem Bootloader von der Größe her mit sehr überschaubaren Aufwand machbar ist. Und den Bootloader künstlich größer zu machen ist selten eine Option wenn man den Flash für die eigentliche Software braucht.
Man vergibt selbst eine UID (oder liest sie aus irgendeinem der Controller aus), fordert 1x einen Key dafür an und lässt den ganzen Kram im Emulator laufen. Das entschlüsselte Ergebnis kann man dann auf jeden Controller schieben. Ich frage mich allerdings, wie umfangreich die SW des TO ist, wenn dieser diese Problematik nicht selbst erkennt. Vermutlich ist sie die Verschlüsselung nicht wert. Das hatten wir ja schon häufiger hier. Gruß Jobst
also mein szenario ist nicht, dass die Industrie da besonders interesse hätte, also wer es Disassembliert und seine UID einträgt darf es gerne kopieren. Die Hemmschwelle soll eben so sein, dass es einfacher ist, bei mir einmal bescheidzugeben dass es nun ein weiteres Gerät gibt. Und das ohne Cloud-zwang. Vielleicht reicht es auch, eine der firmware-funktionen nur als Binär-Blob mit seriennummernbindung auszuliefern. Dann kann auch der Bootloader und alles weitere Öffentlich sein. Der Nutzerkreis ist auch sehr eingeschränkt. Es könnte auch reichen, wenn man in den Bestückungsdruck einen vermerk macht "check registration: www.domain.de/check/" und da dann als käufer sehen kann, ob die UID des Prozessors registriert wurde. Also einfach eine durchsuchbare liste. Für die Kommerzielle nutzung würde ich diese registrierung dann schon an eine 100€ spende an z.b. KiCad knüpfen. Wenn jemand für profit viele dieser dinger verkauft, würden er bei Kunden in diesem Nutzerkreis seine reputation zerstören.
Was du da vor hast wird effektiv nicht funktionieren. Ich weiß ja nicht, was dein super geheimes Produkt so tolles machen kann, aber wenn man die Hardware inklusive Schaltplänen kennt, ist eigene Firmware schreiben nicht wirklich aufwendig. Was du nutzen könntest, wäre sowas wie SFI von ST: https://www.st.com/resource/en/application_note/an4992-introduction-to-secure-firmware-install-sfi-for-stm32-mcus-stmicroelectronics.pdf Aber das gibts nur für die dickeren Controller und der Aufwand steht in keinem Verhältnis. Je nachdem was die Salamischeibe tut, werden die, die es nutzen wollen, vermutlich eigene Firmware schreiben. Vielleicht bauen es einige sogar in besser nach, man weiß es nicht. Es wird ja nicht die Lösung für Kernfusion sein. Wenn du uns mal erklären würdest, was das geheime super Produkt so kann, könnte man das vermutlich besser einschätzen.
Kevin M. schrieb: > Was du nutzen könntest, wäre sowas wie SFI von ST: Nein kann er nicht nutzen. Für das ST modell muss ein Hardware Token (HSM) zum OEM, der damit die Keys erzeugt. Das funktioniert nicht zum selbst flashen, da dann ja das HSM zu jedem Kunden muss (dann kannst du gleich den programmierten Chip schicken) Du könntest dir aber dein eigenes Programmoertool schreiben das das als Relay weiterleitet. So in der Art: Programmiertool verbindet sich mit Chip, holt Zertifikat und public Key vom Chip, leitet die zu dir, du prüfst, ob Zertifikat und Keys von einem ST Chip stammen (sonst könnte dir ja jemand einen public Key schicken, zu dem er den privaten kennt). Danach erzeugst du das key File und schickst es an den Programmer. Dieser spielt es auf den Chip und dieser entschlüsselt das dann mit seinem Key. Wenn ich ehrlich bin, würde ich aber eher das Programmiertool klauen und verwenden wollen, da sehe ich einen Markt. Bei der Firmware wahrscheinlich nicht. Sg
Flip B. schrieb: > Der Nutzerkreis ist auch sehr eingeschränkt. Dann ist Dein Problem nicht existent. Du willst eine einfache Sache für den Kunden maximal kompliziert machen, weil Du zwar nicht die Kontrolle abgeben willst, aber auch nicht die Produktion managen willst. Man kann den Kuchen nicht essen UND behalten.. Das Projekt ist eh schon für wenige interessant. Ein Erfolg damit fraglich. Jede weitere Hürde halbiert die Nutzerzahlen. In zwei Jahren hast Du dann keinen Bock mehr, bekommst einen Schlaganfall oder läufst vor den Bus. Und dann sitzt man da mit diesem unsinnigen Projekt, bei dem man zwar alles selber machen muss, es dann aber nicht besitzt, weil DU nicht loslassen kannst. Erfreu Dich am Erfolg, wenns einer wird. Und wenn einer das in Massen baut, ist das doch eine Wertvolle Dienstleistung für all diejenigen die es haben aber nicht selber bauen wollen. Und wenn es frei ist, kann auch keiner Fantasiepreise nehmen, weil eben JEDER es vollständig bauen kann. Die Dinge sollen sich entwickeln. Bei Open HW / SW ist man idealerweise nur der Geburtshelfer und begleitet das Projekt tatkräftig. Aber damit es wachsen kann, muss man es freilassen.
Kevin M. schrieb: > [...] aber wenn man die > Hardware inklusive Schaltplänen kennt, ist eigene Firmware schreiben > nicht wirklich aufwendig. Interessante Ansicht. Bei mir ist die Firmware fast immer mit Abstand der aufwendigste Teil.
Flip B. schrieb: > wenn man in den Bestückungsdruck einen vermerk macht "check > registration: www.domain.de/check/" und da dann als käufer > sehen kann, ob die UID des Prozessors registriert wurde. Mal abgesehen davon, daß dabei die Frage bleibt, wie sehr das die Käufer wirklich interessiert, wenn sie dafür die HW vermutlich günstiger kriegen, als sie nachbaubar wäre, wie schwer ists für den Chinesen wohl, des aus dem Bestückungsdruck raus zu löschen, oder genau dort einen Aufkleber mit Seriennr. o.ä. hinzupappen?
Taeglich gruesst das Murmeltier... Sicherheit auf Level "Geheimhaltung deiner Firmware" hast du mit deinem Konzept nicht, die meisten Chips lassen sich irgendwie per SWD oder JTAG in die Emulation glitchen. Damit ist ein gewiefter RE im System, und der ganze Aufwand fuer die Cryptoloesung ist fuer die Katz. Ansonsten wurden die Argumente schon oben aufgezaehlt, die dein Vorhaben ad absurdum fuehren. Ich verstehe allerdings eine gewisse Motivation, sich nicht mit WEEE und EAR rumschlagen zu muessen, aber die Tage, das ueber China abzuwickeln, sind gezaehlt. Ich wuerde das pragmatisch machen. Genaues lasse ich mal aus, aber ich habe schlicht einen Hash-Wert irgendwo, der sowohl embedded wie auch remote (PC, etc.) ueberprueft wird, also im Grund, ob die Programmierung "genuine" ist. Wenn nicht, kommen die Supportanfragen (hier genau einmal in 20 Jahren vorgekommen, und war nicht mal unredliche Absicht). Kann man natuerlich ganz einfach knacken. Wenn du dann feststellst, dass deine HW als Hackerziel populaer wird, legst du sie entsprechend neu auf, suchst dir einen vertrauenswuerdigen Distributor, lieferst ihm deine Programmierloesung mit Datenbank, und bringst ab und an ein tolles neues Firmware-Feature, was die Klonkrieger (noch) nicht haben. Der Rest ist Kundenservice. Witzigerweise funktioniert so gesehen Security by Obscurity viel besser. Manchmal hilft auch eine obskure CPU-Architektur, die ghidra nicht kennt. Als Hacker will ich grundsaetzlich keine Hardware haben, die bei einem gekippten Bit schon als "bricked" gilt, weil ich sie nicht neu flashen kann.
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.