Als eifriger Leser (bisher sehr passiv) dieses Forum habe ich mich einfach mal registriert um ein Problem aktiv zu diskutieren. Ich hätte eine Frage zum Schutz von Software auf FPGA-Bausteinen - besonders in SoC-Systemen, kenne mich aber damit leider noch nicht aus. Ich habe bisher zusammentragen können, dass es eine Art von DNA gibt sowie E-Fuses, um Code zu schützen, blicke aber nicht, wie das geht und ob das für meinen Anwendungsfall anwendbar ist. Bevor ich in die falsche Richtung denke oder entwickle, wäre ein Tipp ganz hilfreich. Zunächst der Sachstand: Ich bin MicroController-Entwickler in einem Grosskonzern und darf nebenher Produkte vertreiben, da ich das schon bei einem Einstieg tat. Ich verfüge eine über Jahre entwickelte Software für einen ARM-Core, die auch für ein stand-alone ARM-System entwickelt- eine Weile vertrieben wurde. Die soll jetzt neu aufgesetzt und lizensiert verteilt werden. Dazu soll sie auf ein aktuelles SoC portiert werden, für das eine Reihe von Erweiterungsmodulen im Markt ist und das potenzielle Kunden gerne als Entwicklungsplattform nehmen. Ferner soll es auf ein SoC eines Drittherstellers, der solche Module liefert und die bei den Kunden als Schaltzentrale in ihren Geräten dienen und dort gut bekannt sind. Es gibt rund 5.000 + 8.000 Installationen weltweit. Ein Teil dieser Kundschaft hat auch Bedarf für meine Anwendung, muss diese aber derzeit als eine Art "Messgerät" kaufen. Es ist in etwa so, wie eine Firma, die STM-Devel-Plattformen in ihrem Produkten einsetzt und Teilfunktion eines "Oszilloskops" benutzt, um überhaupt zu entwickeln. Ich liefere denen nun sozusagen Code für so eine Plattform, mit der sie dann das machen können, was sie wollen, ohne ein "Oszilloskop" zu brauchen, das dann frei wird, für andere Aufgaben oder von denen man weniger anschaffen muss. Ich liefere damit für mich und den Kunden sehr kostengünstig etwas, was ich schon zu 90% habe und der Kunde profitiert von einer sehr günstigen Hardware. Es ist aber nötig, den potenziellen Kunden regelmäßig updates zu senden, die sie einfach aufspielen können müssen, weil das System regelmäßig an eine sich im Markt ändernde Bedingung angepasst werden muss. Ich kann also nicht mehr einfach eine embedded HW kaufen oder bauen, die Software reinwerfen und schützen, wie vorher. Es handelt sich bei der angepeilten Hardware um jeweils ein SoC-Entwicklungssystem, das man frei kaufen kann, daher gibt es keine Möglichkeit, eine Weitergabe der Software zu verhindern, ohne ein aktives Lizensierungsmodell zu etablieren. Vorgeschlagen wird das Andocken über Linux an Server und Aktivierung per Code. Das ist auch zu aufwändig und sprengt meinen Zeit´- und Kostenrahmen. Auch eine eigene HW scheidet aus. Ich muss mich aus Kostengründen an existente HW dranhängen. Die Sache rechnet sich ungefähr so, dass die SW 300,- kosten soll, die Soc-Hardware muss der Kunde kaufen und kommt maximal auf 600,- er hat aber eine Funktion, die im Fertiggerät derzeit >4.000 kostet. Kunden, die schon solche Plattformen nutzen, fahren nochmal billiger. Ich könnte also für meine SW sogar noch mehr nehmen, es ist aber unmöglich, für geschätzt 500 Kunden in Europa bei jedem update (sicher alle 4 Wochen) einen Lizensierungslauf zu machen. Ich suche deshalb eine Möglichkeit, das System mit der HW selber zu schützen, auch wenn es nicht die eigene ist und ich die gfs gar nicht in die Finger bekomme. Es gibt auf dem SoC ein TEMP-EEprom, in das man einen Code einbrennen könnte, aber es wäre für jeden Elektorniker leicht, den zu kopieren und an jeden Elektronikbastler weltweit weiterzugeben. Auch könnte sich eine Gruppe von Personen einen Code holen und dann die halbe Stadt damit arbeiten. Ich habe nun die Idee, das mit dem FPGA zu schützen:
Es soll so funktionieren, dass die SoC-Software einen kleinen FPGA-Teil enthält, der neben den IO-Funktionen in der Lage ist, die HW auszulesen und der SW melden kann, in welcher HW er sich befindet und was für ein FPGA er ist. Die Sourcen für die SoC-FPGA-PL gibt es vom Hersteller. Soweit ich weiß, enthält der FPGA einen DNA-Code. Ich nehme an, dass es eine VHDL gibt, die in der Lage ist, diesen auszulesen. Diese wollte ich in die Sourcen einsetzen und das FPGA kundenspezifisch bauen, damit jeder Kunde EINMAL einen FPGA-Code bekommt, den er reinladen muss, oder den ich bei Auslieferung des SoC einbringe und dann nur noch Software überladen braucht. Das FPGA soll so programmiert werden, dass dieses Kunden-VHDL nur auf diesem FPGA funktioniert, also ein einfacher Vergleich, ist der DNA Code im FPGA der, den mir der Kunde bei der Bestlellung mitgeteilt hat und den ich in die Sourcen eingesetzt habe. Der Kunde könnte es zwar weitergeben, aber es arbeitet nicht. Die SW soll so programmiert werden, dass der FPGA "positiv" melden muss. Dafür habe ich schon eine sichere Idee wie ich das machen möchte, ohne dass es von aussen gefälscht, gelesen und vorgetäuscht werden kann. Ich habe nämlich die Befürchtung, dass genau das passieren wird, weil die Anwendung auch für ambitionierte Elektronikfreunde interessant sein könnte und es nur einen einzigen Hacker braucht, der das angeht. Meine Codierung stellt sicher, dass die SW nur funktioniert, wenn sie ihr Gegenstück "sieht". Das funktioniert in einer anderen Anwendung rein in SW auch über das lokale Ethernet in Firmen. Der Punkt ist also sicher- ich brauche nur irgendeine Form einer gebrandeten Hardware. Die Frage ist, funktioniert das so? Kann ich eine SW für das SoC bauen lassen, die nur einen FPGA-Teil programmiert und eine, die nur den PS-Teil programmiert? Den FPGA würde man kundenseitig auch einmalig mit einem JTAG beschreiben können, um das Flash anzusteuern. Nach meiner Vorstellung sollte es so sein, dass der Kunde "sein" FPGA image einmal einbrennt / eingebrannt bekommt und danach so oft er will, neue SW überladen kann. Die SW ist dann für alle Kunden dieselbe und liegt auf meiner HP, wäre also frei verteilbar, funktioniert aber nicht ohne ein kundenspezifisches FPGA. P.S. in der Vergangenheit war es so, dass ich eine HW erworben hatte, dort das flash beschrieben hatte und die SW dann einen plausiblen Code im Flash lesen musste, um zu arbeiten. Das Flash war so manipuliert, dass man es nicht einfach auslesen konnte und auch nicht beschreiben konnte. Auch das wurde aber schon vereinzelt dupliziert, wie ich feststellen musste. Das waren aber wohl nur interne Duplikate bei Industriekunden. Die neue Software enthält hingegen Funktionen, die auch für Bastler in Interesse sein könnten. Dann laufe ich in dieselbe Problematik hinein, wie gewisse Hersteller von LogicAnalazern, deren SW auf Billighardware portiert wird. Leider ist die HW, mit der ich gearbeitet hatte, veraltet und auch nicht mehr zu erwerben. Eine aktuelle und verbesserte ist zu teuer. Die SoC-Plattformen bieten hingegen ein Vielfaches an Möglichkeiten und sind bei den Kunden so verbreitet wie PCs. Ähnlich könnte sich auch die SW verteilen, wenn ich sie nicht schütze. Nur ein NDA, wie bei Kunden bisher, wird da nicht reichen. Es reicht ein einziger Nutzer bei einem Kunden, der den kundenspezifischen Namen im Flash überschreibt und die SW ins Netz stellt. Dann freut sich nur der Hersteller der Plattform, der die dann um so besser verkaufen kann. Mti dem hatte ich mich schon kurzgeschlossen, aber der wollte mein App nicht kaufen und eine Beteiligung an den Verkäufen, wenn er es mitliefert, ist zu aufwändig, da Kleckerbetrag. Der lässt die auch in China produzieren und von dort schon an die Distris verteilen, wie ich erfuhr. Ich muss also entweder selber die HW vom Distri kaufen und programmieren oder dem Kunden etwas senden, was nur er verwenden kann. Die Idee ist, eine dummy image, das den DNA Code auslesen kann und ihn sichtbar macht, damit der Kunde ihn mit schickt.
Ich hoffe ich habe jetzt keinen erschlagen mit dem Text. Wäre nett, wenn jemand der mit solchen Systemen schon gebaut hat, mir einen Tipp geben könnte, wie man das am Schlauesten macht. Das mit den E-fuses ist mir u.B. suspekt. Laut einem Herstellerhinweis kann man seine FPGA-Software damit verschließen, aber nach meinem Verständnis geht das dann nur einmal.
Harald E. schrieb: > Die neue Software enthält hingegen Funktionen, die auch > für Bastler in Interesse sein könnten. Vor Bastlern hätte ich keine Angst. > Dann laufe ich in dieselbe Problematik hinein, wie gewisse Hersteller > von LogicAnalazern, deren SW auf Billighardware portiert wird. Das hat den Originalherstellern aber übrigens nicht geschadet, sondern eher noch zur Bekanntheit und Verbreitung beigetragen. > Der Punkt ist also sicher- ich brauche nur irgendeine Form einer > gebrandeten Hardware. Nimm einen DS28E10. Funktioniert bei uns tadellos, keine Klone bekannt. https://www.maximintegrated.com/en/products/embedded-security/secure-authenticators/DS28E10.html
Harald E. schrieb: > dass es eine Art von DNA gibt Ich vermute, du meinst hier PUF: https://en.wikipedia.org/wiki/Physical_unclonable_function Harald E. schrieb: > Die SW > soll so programmiert werden, dass der FPGA "positiv" melden muss. Dafür > habe ich schon eine sichere Idee wie ich das machen möchte, ohne dass es > von aussen gefälscht, gelesen und vorgetäuscht werden kann. Das haben schon viele vor dir gedacht, die einen Kopierschutz in irgendeine Software eingebaut haben. Meistens reichte dann doch ein passend gesetzter Jump in Assembler um das zu umgehen. Chain of Trust, der FPGA/SoC soll dann nur noch signierten Code ausführen, der Booloader nur signierte Software etc. Ist mit SRAM basierten FPGAs aber nicht so einfach. Harald E. schrieb: > Die Sache rechnet sich ungefähr so, dass die SW 300,- kosten soll, die > Soc-Hardware muss der Kunde kaufen und kommt maximal auf 600,- er hat > aber eine Funktion, die im Fertiggerät derzeit >4.000 kostet. Dann verkauf es doch mit unterschiedlichen Preisen für Profis und Bastler. Ist ein Model das sich bei mehreren Projekten erfolgreich auf die Bekanntheit ausgewirkt hat und die Motivation zum Kopieren stark reduziert. Harald E. schrieb: > Die Frage ist, funktioniert das so? Kann ich eine SW für das SoC bauen > lassen, die nur einen FPGA-Teil programmiert und eine, die nur den > PS-Teil programmiert? Den FPGA würde man kundenseitig auch einmalig mit > einem JTAG beschreiben können, um das Flash anzusteuern. Nach meiner > Vorstellung sollte es so sein, dass der Kunde "sein" FPGA image einmal > einbrennt / eingebrannt bekommt und danach so oft er will, neue SW > überladen kann. Kommt sehr vom eingesetzten SoC ab. Die haben verschiedene Abläufe wie die Booten. Ich kann selber nur vom 7-Series Zynq reden. Da ist es schon mal anders als deine Vorstellung, da nähmlich der ARM Core zuerst bootet und ein Bootloader, den du in das externe Flash schreiben musst dann den FPGA Teil beschreibt mit dem Bitstream der auch im externen Flash steht. Danach lädt der Bootloader typischerweise die Anwendersoftware vom Flash oder springt in einen weiteren Bootloader der dann mehr kann (Software laden von SD Karte Netzwerk oder was auch immer). Harald E. schrieb: > Soweit ich weiß, enthält der FPGA einen DNA-Code. Ich nehme an, dass es > eine VHDL gibt, die in der Lage ist, diesen auszulesen. Diese wollte ich > in die Sourcen einsetzen und das FPGA kundenspezifisch bauen, damit > jeder Kunde EINMAL einen FPGA-Code bekommt, den er reinladen muss, oder > den ich bei Auslieferung des SoC einbringe und dann nur noch Software > überladen braucht. Das FPGA soll so programmiert werden, dass dieses > Kunden-VHDL nur auf diesem FPGA funktioniert, also ein einfacher > Vergleich, ist der DNA Code im FPGA der, den mir der Kunde bei der > Bestlellung mitgeteilt hat und den ich in die Sourcen eingesetzt habe. Du kennst Project X-Ray? Dann basteln wir halt so lange an einem Kundenspezifischen Bitstream herum, bis der auf jedem FPGA bootet. Nicht trivial aber wenn dein Produkt ein so krasses haben-muss Produkt ist, wird das wohl gemacht werden. Sonst natürlich nicht, und wir Bastler wären zufrieden dir einfach 30 € pro Jahr zu geben.
Christoph Z. schrieb: > Dann verkauf es doch mit unterschiedlichen Preisen für Profis und > Bastler. Ist ein Model das sich bei mehreren Projekten erfolgreich auf > die Bekanntheit ausgewirkt hat und die Motivation zum Kopieren stark > reduziert. Das funktioniert ganz gut. Dass ich mir privat einen J-Link EDU gekauft habe, hat in der Firma zu mindestens 2 Käufen der Vollversion geführt. Den Segger hätte ich privat nie gekauft, hätte er viel mehr als die ca. 50€ gekostet. So profitiert jeder.
Lothar M. schrieb: > Vor Bastlern hätte ich keine Angst Dein Selbstbewusstsein in Ehren aber aus nächster Nähe habe ich schon andere mit ähnlichen Projekten kaputtgehen sehen, weil ihnen was gehackt wurde. Lothar M. schrieb: > Nimm einen DS28E10. Funktioniert bei uns tadellos Das wäre in der Tat das Beste, scheidet aber leider aus, weil das nicht auf den anvisierten boards drauf ist. Ich müsste dann eine Zusatzplatine bauen und liefern. Das läuft dann auf die Lösung 3 hinaus - siehe unten:
Als eine weitere Idee: Es wird Kunden geben, die ihre Plattform für ihren Zweck nutzen möchten und permanent zwischen meiner Funktion und der ihren hin und herschalten möchten. Von daher könnte es sein, dass es auch schon deshalb nicht geht, einmal den FPGA zu laden und dann nur noch die SW, weil beim Rückschalten auf die Kunden-APP alles wieder weg wäre und der Kunde dann erst wieder meine primäre FPGA-SW laden müsste. Zwischenfrage: Kann man das Flash so nutzen, dass der Kunde seine Kunden-APP drin hat (also SoC-Software + eingebaute SoC-FPGA-firmware) und parallel meine beiden Versionen, also SoC-FPGA-firmware + allgemeine SW? ... also für den Fall, dass das SoC das ermöglicht (siehe die Einschränkung von Christoph). Angenommen, das geht nicht, folgende Frage: Wäre es möglich, Teile des FPGA partiell zu rekonfigurieren? D.h. man startet das System mit einer Komplett-Software, die alles enthält und die kundenspezifisch nur auf seinem FPGA läuft und dann herzugehen und aus dem Flash einen aktuellen Teil drüber zu laden? Es wäre mit etwas Aufwand nämlich möglich, die sich ändernden Informationen per Daten-Code im FPGA abzulegen, also als Tabelle oder Anweisungssequenz. Es gibt in der SW nämlich einen konfigurierbaren Prozessor wie eine MINI-RISC, welche Codes abarbeiten kann. Damit wären die monatlichen Anpassungen leistbar. Die Codes kämen eben aus dem FPGA-ROM, statt aus Tabellen im C-Code. Es wäre prima wenn man das irgendwie hinbekommen könnte, weil ich nämlich sonst einen intelligenten dongle bauen und verschicken müsste. Siehe Vorschlag von Lothar M. Die Notlösung wäre ein kleines Zusatzmodul, das man kaufen kann und das einen eigenen FPGA hat, den ich kundenspezifisch programmieren kann, um Funktionen freizuschalten, nur habe ich noch nicht rausbekommen, welcher FPGA das ist und ob der auch DNA hat. Außerdem erhöht das den Aufwand und verhindert, dass die Lösung auch für einige Bastler interessant ist. Ich gehe davon aus, dass zumindest die HF-Bastelfraktion Interesse an so einem System hat.
Christoph Z. schrieb: > Du kennst Project X-Ray? Dann basteln wir halt so lange an einem > Kundenspezifischen Bitstream herum, bis der auf jedem FPGA bootet. Bisher nicht. Ich habe noch nicht viel mit FPGAs gemacht. Ich nehme an, du meinst das hier: https://symbiflow.readthedocs.io/projects/prjxray/en/latest/ Das klingt für mich nach organisiertem Hacken. Das soll nicht heißen, dass ich das schlecht finde oder für illegal halte, es ist nur leider so, dass dies ein Beispiel dafür ist, wie sehr manche einen Sport daraus machen, die IP, wo manch einer Tausende Stunden reingesteckt hat, für andere kostenfrei zu "klauen". Christoph Z. schrieb: > Das haben schon viele vor dir gedacht, die einen Kopierschutz in > irgendeine Software eingebaut haben. > Meistens reichte dann doch ein passend gesetzter Jump in Assembler um > das zu umgehen. So einfach ist das nicht. Es ist eben nicht nur eine Abfrage. In dem FPGA und den darin hinterlegten (zu hinterlegenden) Daten steckt erheblich mehr drin. Man kann nicht einfach etwas ändern und es zum laufen bringen, weil man nicht erkennt, wann es richtig läuft und wann nicht. Den Messergebnissen ist das nicht unbedingt anzusehen. Es geht u.a. um Kalibrierdaten, die (bei einer neuen Funktion) auch mit den IOs des FPGA zu tun haben werden. D.h. es ist Teil der Funktion, dass sich das FPGA auf das PCB anpasst und dies fließt bisher nur in die Daten, nach neuer Planung auch in den Code. Steckt man dort ein falsches image rein mit gefälschtem Code, kriegt man Werte, aber sie sind praktisch wertlos. Hinzu kommt, dass die Hackerei nach der Methode oben eine Halbwertszeit hat und nur bis zum nächsten update lebt. Wie gesagt ginge nach meinem Posting hier auch ein reiner Dongle, der dann zwar dümmer wäre, als der FPGA, dafür aber direkt die Sicherheit brächte. Leider erfordert das, dass ich den liefern und irgendwie in die HW einbauen muss. Auf dem SoC-System des Anbieters ist aber schon ein FPGA drauf, der für intelligente Funktion vorgesehen ist und der für diverse Dinge mitbenutzt werden wird. Damit könnte man ihn auch für den SW Schutz mitverwenden. ich habe nämlich noch das Problem, dass ich in dem Idealfall nur SW liefern muss, während ich in jedem anderen Fall auch HW liefern muss, was eine andere Qualität hat, steuerlicher und arbeitsrechtlicher Art. Wahrscheinlich auch Haftung etc.
Christoph Z. schrieb: > Ich vermute, du meinst hier PUF: Das ist ja cool! Hätte ich nicht gedacht, dass soetwas geht. -------------------------- Bei einer Ringoszillator-PUF werden verschiedene Glieder mit zeitlicher Verzögerung rückgekoppelt und beispielsweise auf einen Eingang eines Multiplexers gelegt. Die Dauer der Schwingung hängt wieder von kleinen Produktionstoleranzen ab und ist individuell für den PUF. Der Rückgabewert wird aus dem Vergleich von Oszillatorfrequenzen erreicht oder aus dem Auslesen eines Multiplexers zu einem bestimmten Zeitpunkt. Durch geschickten Vergleich lassen sich Schwankungen in den Umgebungsbedingungen vorteilhaft eliminieren. ------------------------------ Ich frage mich aber, wie man das auswertet. Dafür reichen meine FPGA-Kenntnisse nicht aus. Wenn der FPGA einen digitalen DNA-Code hat (also wirklich jeder CHIP einen eigenen) dann reicht mir das aus, den mit den den Freischaltcode zu nehmen. Es gibt nämlich noch einen geplanten Schutz: Das System schreibt Protokolldaten in ein file und dies erfolgt als Ausgabe eines serieller Datenstroms über UART. In diesen UART-Daten stehen nicht nur Datum, Erfassungswerte und Protokolltyp, sondern auch die Firma und der user, der die Messung gemacht hat. Den User-Output müsste er erst einmal ändern. Das hat schon im alten System dafür gesorgt, dass Firmen es nicht so ganz offensichtlich mehrfach nutzen konnten.
TL;DR;, unterm Strich kann ich nur sagen: Mach' eine eigene Hardware. Alles andere ist nach meiner Erfahrungen (und der vieler Kollegen im aehnlichen Geschaeft) eher zum Scheitern oder zur sinnlosen Verzettelung verurteilt. Von Lattice gibt es ein paar pfiffige Ansaetze, sich 'sein' FPGA zu schuetzen ohne dass man sich allenfalls selbst aussperrt und neue HW liefern muss. Interessant ist auch einfach, Mechanismen einzubauen, die unrechtmaessige Nutzung protokollieren. Haelt sich nach meiner Erfahrung im Promillebereich (bei einer einfachen Seriennummer und XOR-Check). Und ja, hackbar sein macht ein Produkt allenfalls erst interessanter, als die grossartige eigene Erfindung.
Harald E. schrieb: > Ich hätte eine Frage zum Schutz von Software auf FPGA-Bausteinen - > besonders in SoC-Systemen, kenne mich aber damit leider noch nicht aus. Du bist erst einmal angestellt und willst privat etwas dazuverdienen. Gelle? Und zwar mit Software, die auf normaler Kauf-Hardware läuft. Und die schätzt du kraft deiner Nase als 300€ wert ein. Hmm, es ist imer wieder das Gleiche: Softwareleute erhoffen sich von ihrer Arbeit den anschließenden Gold-Regen. Mein Rat: mach deine Software frei von Lizenzgehadere und mache sie billiger, z.B. 35€/Stück. Dann kriegst du zwar weniger herein, aber es ist ja nur nebenberuflich und du sparst dir einen Haufen Ärger mit dem Buchführen der vergebenen Lizenzen usw. Und merke: der echte Straßenpreis regelt das und nicht etwa die Vorstellungen der Programmierer. W.S.
Harald E. schrieb: > Ich frage mich aber, wie man das auswertet. Vergiss es. Das hört sich zwar recht geschwollen (und irgendwie nach einem Patentauszug) an, funktioniert aber in der Praxis garantiert nicht zuverlässig oder wenigstens hinreichend.
Harald E. schrieb: > Das klingt für mich nach organisiertem Hacken. Das soll nicht heißen, > dass ich das schlecht finde oder für illegal halte, es ist nur leider > so, dass dies ein Beispiel dafür ist, wie sehr manche einen Sport daraus > machen, die IP, wo manch einer Tausende Stunden reingesteckt hat, für > andere kostenfrei zu "klauen". Nochwas dazu: Mit Sport oder Klauen hat das so gar nichts zu tun. Project XRAY reverse-engineert das Mapping von Bitstream auf die FPGA-Primitiven zum Zweck, OpenSource PnR-Tools nutzen zu koennen. An den Quellcode des IP kommt man auch mit Reverse-Engineering-Tools nicht. Quellcode zu einem SoC laesst sich hingegen sehr leicht aus den SRAM-Initialisierungs-Blocks auslesen und in Assembler rueckuebersetzen. Das war's dann aber schon. Dem kann man allerdings mit genuegend Obfuskierung (gibt's das im Deutschen?) entgegenwirken, dass der Reverse-Engineer schon mal viel Muehe hat, die Architektur zu erraten, die in deinem Fall schon verraten wurde. Faellt mir grade noch einer ein: Ich hatte einen Kunden aus der Roboterecke, der HW und SW angeboten hat. Seine pragmatische Antwort, wie er die SW an die HW bindet resp billiges Klonen unterbindet: Dann kaufe ich die Hardware halt bei DEM. Die SW wurde dann sowieso OpenSource. Also: Besser nochmal ueber die Buecher gehen..
Oh, Oh, Oh, also langsam: Martin S. schrieb: > Mach' eine eigene Hardware. Scheidet aus. Das System ist zu komplex um es preisgünstig nachzubauen. Es wären Stückzahlen im Bereich der 5000 nötig gfs 10.000. Das ist wie "bau deinen eigenen Industrie-PC" um die SW zu schützen. Martin S. schrieb: > Von Lattice gibt Das System läuft mit einem Xilinx UltrasScale-Baustein. Einen kleinen, aber aber eben mit einem der Glasfaseranschluss und eben noch einiges mehr hat, was ich verwenden kann. W.S. schrieb: > Du bist erst einmal angestellt und willst privat etwas dazuverdienen. > Gelle? Nein ich bin "erst einmal" Inhaber eines ING-Büros (gewesen), wurde dann für eine Weile in einem Sonderprojekt angestellt und weggekauft. Bin dann fest in einen Konzern, während das ING-Büro weitergeführt wird. Nix privat. Ich habe auch noch 2-3 andere Sachen, die laufen - eine davon MIT eigener Hardware. W.S. schrieb: > Und zwar mit Software, die auf normaler Kauf-Hardware läuft. Richtig. So wie es unzählige Software gibt die auf PCs, Industrie-PCs, Linux-Systemen und anderen embedded Systemem laufen. Oder nehmen wir eine Software für eine PLC oder VPX. Martin S. schrieb: > Mit Sport oder Klauen hat das so gar nichts zu tun. Das hatte ich auch sofort verneint, wenn du richtig liest. Zudem wurde das Projekt ja mir gegenüber (und nicht "von mir") als eine Möglichkeit dargestellt, den bitstream zu knacken. Ich sehe das eher als unbedeutende Gefahr. Wenn ein Kopierschutz drauf ist, der an die HW gekoppelt ist, sollte das ausreichen, um massenhaftes Kopieren zu unterbinden. Der Phreak, der es gebrauchen kann, wird liebend gern etwas Geld hinlegen, weil es ihm nämlich Zeit spart. Wenn er erst hacken muss, wird es unrentabel für ihn. Die Nutzer legen ja Tausende hin. Martin S. schrieb: > "Dann kaufe ich die Hardware halt bei DEM." Das mache ich gerne auch, wenn ich eine billigere finde. Das ist aber nicht das Problem. Ich verdiene nichts an der Hardware, sondern möchte eine allgemeine flexible Hardware für mich nutzen. Aber jetzt nochmal zum eigentlich Thema:
Also: Ich habe mir das sehr gut überlegt und was ich machen möchte, ist auch nichts Ungewöhnliches: Im Gegenteil, ich nutze eine allgemeine Plattform eines Herstellers so, wie er es sich denkt, nämlich als Kleinserienprodukt. Das Einzige, was ich nicht machen muss, ist eine eigene Hardware für meinen Zweck zu bauen, um sein System als "on-top" einzusetzen. Es ergibt sich nämlich die komfortable Situation, dass - in Verbindung mit einigen Erweiterungsplatinen - schon alles verfügbar ist, was der Mensch braucht. Es braucht nur eine Software mit Intelligenz. Ich führe als Beispiel eine VX oder einen anderen single board PC an, der in Systemen integriert wird. Im vorliegenden System ist es nur so, dass die Zusatzplatine so einfach und billig ist, dass man mit SOC + EXP auf 600,- bis 700,- Euro rauskommt. Das kann (und "soll" von mir aus) jeder machen. Nur wenn er eine Software kauft, die besondere Funktionen hat und die im Arbeit oder die Anschaffung von weiterem Eqipment spart, soll er auch dafür bezahlen. (Für das vorherige System wurde ja auch bezahlt). Es ist nur so, dass das SOC-System, das für mich passt, leider nicht mit irgendwelchen Sicherheitsfunktionen ausgestattet ist. Es gibt keine Festplatte oder MAC/PHY der eine Seriennummer hätte, die man abfragen könnte, wie es bei PCs der Fall ist. Ich habe mich vor einiger Zeit mit Xilinx-Entwicklung befasst und erinnere mich, dass auch dort die Lizenz an die Platte gebunden ist. Da ich ohnehin das FPGA etwas anpassen muss, kann ich auch gleich die security dort einbauen, oder? Lothar M. schrieb: > Vergiss es. Das hört sich zwar recht geschwollen (und irgendwie nach > einem Patentauszug) an, funktioniert aber in der Praxis garantiert nicht > zuverlässig oder wenigstens hinreichend. Laut der Sichtung der Dokumente ist es wohl so, dass maximal 32 FPGAs der selben Serie die gleiche DNA-Nummer haben. Das würde mir eigentlich schon reichen. Was spricht dagegen? Wenn es mit dem branding des FPGA nicht geht, muss eben ein dongle her. Dazu hattest Du den Chip von Maxim empfohlen. Leider ist das Dokument nur unter NDA zu bekommen, wie ich feststellen musste. Könnte man kurz skizzieren, wie das funktioniert? Ich nehme an, der Chip hat eine feste Nummer ( oder eine die ich vergeben kann) und die dann per Software ausgelesen wird. Wie wird sichergestellt, dass dieser Vorgang im FPGA nicht abgehört oder entschlüsselt wird? Und wenn man den als sicher ansieht, warum wäre dann das DNA-Code lesen unsicher? Der Chip wäre mir grundsätzlich nicht unsympathisch, da 1-wire-IF. Das wäre kein Problem, denke ich, wenn es Verilog dafür gibt, ihn sicher auszulesen. Und wenn er nicht zu teuer ist. ?
Harald E. schrieb: > Das hatte ich auch sofort verneint, wenn du richtig liest. Lies nochmal: >> wie sehr manche einen Sport daraus >> machen, die IP, wo manch einer Tausende Stunden reingesteckt hat, für >> andere kostenfrei zu "klauen". Notabene: Es kommt hier nicht sehr gut an, Stueckzahlen zu suggerieren, die durchaus ein serioeses Ingenieurbuero fuer dich kostenguenstig produzieren wuerde, sich dann aber kostenlos hier das Knowhow abzuholen. Bau' eine einfache Seriennummerabfrage ein, und gut ist. Wenn du einen hackerresistenten Schutz willst, legst du dem Profi 30k hin, und gleich dasselbe dem freundlichen R-Engineer fuer den Penetrationstest, oder du machst halt deine Hausaufgaben selber.
Würde auch zustimmen, entweder ein einfacher Kopierschutz der ehrliche Leute hilft ehrlich zu bleiben, oder musst spezial-Hardware bauen und an die idealerweise auch einige Funktionen auslagern, damit die Überprüfung der HW nicht einfach raushackbar ist.
https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4594.html APPLICATION NOTE 4594 PROTECT YOUR FPGA AGAINST PIRACY: COST-EFFECTIVE AUTHENTICATION SCHEME PROTECTS IP IN SRAM-BASED FPGA DESIGNS Gruss Holger.
Harald E. schrieb: > Scheidet aus. Das System ist zu komplex um es preisgünstig nachzubauen. > Es wären Stückzahlen im Bereich der 5000 nötig gfs 10.000. Das ist wie > "bau deinen eigenen Industrie-PC" um die SW zu schützen. Bei den Stueckzahlen gehst du zum Board Hersteller und sagst, er moege doch bitte den Baustein den Lothar vorgeschlagen hat, mit drauf packen. Wenn du ihm garantiert 5000 Stueck abnimmst, wird er das mit Kusshand tun und wahrscheinlich kostet das Board kein Cent mehr.
Angehängte Dateien:
-
vivado_bit_key.PNG
310 KB
https://www.xilinx.com/video/fpga/security-lock-before-you-leave.html Learn how to enable bitstream encryption to secure your design. This video shows how to enable AES-256 GCM bitstream encryption to protect your design from unintended use or reverse engineering. https://www.xilinx.com/support/documentation/user_guides/ug570-ultrascale-configuration.pdf Protecting a Bitstream Like processor code, a bitstream that defines the device’s functionality loads into the device during power-on. Since this configuration data is stored off chip there exists a possibility of unauthorized duplication / modification. Like processors, there are multiple techniques to protect the bitstream and any embedded intellectual property (IP) cores. The surest way to protect the confidentiality of your IP is to encrypt the configuration data using an AES-256 key. Keys for the on-chip decryption logic can be stored in either battery-backed RAM or one time programmable eFUSEs. This technique allows for off-chip storage of your IP protected with high grade encryption. Bitstream Security, eFUSEs, and Device DNA Bitstream Encryption and Authentication The UltraScale architecture-based FPGAs have on-chip Advanced Encryption Standard (AES) decryption and authentication logic to provide a high degree of design security. Without knowledge of the encryption key, adversaries cannot analyze an externally intercepted bitstream to modify or clone the design. Encrypted FPGA designs cannot be copied or reverse-engineered.
Vivado Menue: https://www.xilinx.com/support/documentation/application_notes/xapp1267-encryp-efuse-program.pdf Encrypted Bitstream Implementation Overview. Gruss Holger.
Harald E. schrieb: > Dazu hattest Du den Chip von Maxim empfohlen. Leider ist das Dokument > nur unter NDA zu bekommen, wie ich feststellen musste. Welches "Dokument" meinst du? Für einen ziemlich tiefgehenden Blick reicht doch das, was als "Technical Documentation" frei zugänglich ist: https://www.maximintegrated.com/en/products/embedded-security/secure-authenticators/DS28E10.html#tech-docs https://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4594.html https://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3826.html https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1201.html > Könnte man kurz skizzieren, wie das funktioniert? Ich nehme an, der Chip > hat eine feste Nummer ( oder eine die ich vergeben kann) und die dann > per Software ausgelesen wird. Du schreibst selber deine Informationen und Freischaltcodes in den Speicher des Chips. Und diese Datenübertragung ist per SHA gesichert. > Wie wird sichergestellt, dass dieser > Vorgang im FPGA nicht abgehört oder entschlüsselt wird? "Abhören" kann die Übertragung jeder, er braucht dafür nur einen 1-Draht-Logicanalyzer. Der Witz liegt am entschlüsseln dieser Daten. > warum wäre dann das DNA-Code lesen unsicher? Eine Voraussetzung für die Unsicherheit ist, dass ich diese DNA natürlich auch ganz einfach auslesen kann. Und dann geht es (etwas vereinfacht gesagt) etwa so: mal angenommen, ich habe 20 Klone deiner Steuerungen gebaut. Und ich habe 2 deiner Steuerungen mit gleichen Optionen aber natürlich mit 2 unterschiedlichen DNA gekauft. Dann erzeugst du mir fürs nächste Update 2 Bitfiles und sendest die mir zu. Und ich mache einen FileCompare zwische den beiden und weiß, wo du den Vergleich des Codes machst und wo ich die DNA der FPGAs meiner 20 Klone einbauen muss. > Der Chip wäre mir grundsätzlich nicht unsympathisch, da 1-wire-IF. Das > wäre kein Problem, denke ich, wenn es Verilog dafür gibt, ihn sicher > auszulesen. Die Kommunikation zum Maxim SHA-Device wird per Picoblaze-Software abgefragt. > Und wenn er nicht zu teuer ist. ? Eine Preisindikation gibts bei Maxim nach Klick auf "Buy". Und dann lässt du deinen Einkäufer von der Leine und der handelt das mit deinen Stückzahlen auf die Hälfte runter. Der Trick ist, dass letztendlich die freigeschalteten Optionen im SHA-Device gespeichert sind, und es nur 1 einzigen Bitstream für alle deine Steuerungen gibt. Du hampelst also nicht jeder Steuerung mit einem eigenen händisch erzeugten Bitstrem hinterher, sondern die Steuerung selber weiß, was sie kann und schaltet sich selber die Funktionen frei. Und wenn du trotzdem für jeden Kunden einen eigenen Bitstream erzeugen willst, dann kannst du auch das.
:
Bearbeitet durch Moderator
Zusammengefasst: Du möchtest eine Software vertreiben, die auf einer frei zugänglichen Hardware läuft. Ferner möchtest du verhindern, dass jemand deine Software auf einem Gerät laufen lassen kann, für das er nicht bezahlt hat. Soweit richtig? Einigermaßen sicher wäre die Bindung an eine zusätzliche Hardware. Das kann ein Dongle sein, oder ein Chip zusätzlich zur verfügbaren Hardware (z.B. eine Platine, die man auf einen Arduino oder Raspberry Pi draufsteckt). Die Software kann dann die Existenz dieses Chips prüfen. Wichtig ist, dass die korrekte Funktion des Dongles/Chips für die Funktion der Software notwendig ist, sonst kann man das mit genug Aufwand umgehen. Weniger sicher ist die Bindung an eine Seriennummer, die bei den meisten SoCs eingebaut ist. Bei der Bestellung der Software muss dann die Seriennummer des Chips angegeben werden und du generierst eine spezielle Version der Software für genau diese Seriennummer. Mit genug Aufwand kann man das immer umgehen. Wenn du Angst vor Hackern und Bastlern hast, dann musst du den Aufwand nach oben treiben: Ein Dongle macht dich für Bastler wahrscheinlich unattraktiv genug, dass niemand den Aufwand treiben wird. Das gleiche gilt, wenn du die Generierung des Images so teuer machst, dass niemand ein Dutzend Images zur Analyse in die Hände bekommt. Oder du machst dein Produkt schlicht so teuer, dass eine Neuentwicklung billiger ist. Zusätzliche Sicherheit erschwert natürlich die Nutzung deines Produkts für den ehrlichen Käufer. Sollte also wider erwarten eine gehackte Variante in Umlauf kommen, wird diese für die gesamte Zielgruppe - moralisch verwerflich oder einwandfrei - attraktiver. Die aktuelle Variante in der IT ist im Übrigen, nicht mehr die Software zu sichern, sondern sie an einen Online-Dienst zu binden.
Martin S. schrieb: > Lies nochmal: Danke für dein Zitat, meines Satz. Aber lies du bitte mal, was ich direkt danach geschrieben habe. :-) Tobias B. schrieb: > Harald E. schrieb: >> Scheidet aus. Das System ist zu komplex um es preisgünstig nachzubauen. >> Es wären Stückzahlen im Bereich der 5000 nötig gfs 10.000. Das ist wie >> "bau deinen eigenen Industrie-PC" um die SW zu schützen. > Bei den Stueckzahlen gehst du zum Board Hersteller und sagst, Leider den Sinn meiner Aussage nicht verstanden. Es sind eben keine 5.000 Stk.! Es sind gfs 500-1000 im Höchstfall und dies eben nur, wenn weite Teile der Nutzer keine Extrahardware kaufen müssen. Ist das so schwer zu verstehen? Das ist eine "Der Nutzer kann seinen PC auch noch für was anderes nutzen"-Software. Nur nicht für PCs sondern SoCs. Holger schrieb: > APPLICATION NOTE 4594 > PROTECT YOUR FPGA AGAINST PIRACY: COST-EFFECTIVE AUTHENTICATION SCHEME Das sieht doch schon einmal ganz gut aus. Danke. Holger schrieb: > Encrypted Bitstream Implementation Overview. super, das hatte ich bisher noch nicht finden können.
Lothar M. schrieb: > Und dann geht es (etwas vereinfacht gesagt) etwa so: mal angenommen, ich > habe 20 Klone deiner Steuerungen gebaut. Und ich habe 2 deiner > Steuerungen mit gleichen Optionen aber natürlich mit 2 unterschiedlichen > DNA gekauft. Dann erzeugst du mir fürs nächste Update 2 Bitfiles und > sendest die mir zu. Und ich mache einen FileCompare zwische den beiden > und weiß, wo du den Vergleich des Codes machst und wo ich die DNA der > FPGAs meiner 20 Klone einbauen muss. Das ist einleuchtend, dass das geht. Ich dachte allerdings, dass der Bitstream so verschlüsselt / (verworren) ist, dass man das nicht so einfach machen kann. Dann müsste man pro Kunde auch noch andere Sachen am bitstream ändern, nehme ich an, damit das Platzieren zu anderen Ergebnissen führt. > Die Kommunikation zum Maxim SHA-Device wird per Picoblaze-Software > abgefragt. Oha! Der läuft aber soweit mir bekannt, auch mit C? Kann diese Software dann nicht genau so analysiert und geknackt werden, dass die Freischaltung an das übergeordnete System für alles erfolgt, egal, was der Baustein sagt? Ich meine, der PICOBLAZe tritt aus meiner Sicht nur an die Stelle des ARM im SoC. Dann kann ich den SW-Schutz auch auf die ARM-SW beschränken und bin genau so weit wie vorher (?)
Ist eine Laufzeitbegrenzung mit anschließender Zusendung eines Freischaltung(mit aus dem Chip generierter challenge) möglich?
S. R. schrieb: > Die aktuelle Variante in der IT ist im Übrigen, nicht mehr die Software > zu sichern, sondern sie an einen Online-Dienst zu binden. Mag sein - ist aber mit einem zunehmenden Aufwand verbunden. und sobald es irgend eine erträgliche Alternative gibt, ist man zu 99% raus aus jeglichem Geschäft. Und was als gerade noch erträglich bei den Anwendern gilt, hängt auch von vielen Faktoren ab. Mein Rat hier also nochmal: Kein Kopierschutz und billige Preise. Das wirkt ohne eigenes Zutun. Allerdings nur dann, wenn man etwas wirklich Sinnvolles den Kunden anbietet. W.S.
Mucky F. schrieb: > Ist eine Laufzeitbegrenzung mit anschließender Zusendung eines > Freischaltung(mit aus dem Chip generierter challenge) möglich? Theoretisch ja, aber eine Laufzeitbeschränkung wäre auch zu knacken oder zu umgehen und die möchte ich auch nicht, um mich nicht unter Druck zu bringen. Es wird auch Kunden geben, die keine updates brauchen oder haben wollen. W.S. schrieb: > Kein Kopierschutz Ohne Kopierschutz kauft es keiner, sondern benutzt es einfach. > billige Preise. Es gibt keine billigen Preise sondern nur niedrige und alles unter 500,- ist in dem Fall "niedrig". Es muss ja auch einiges für den Kunden zugeschnitten werden, aka "Einrichtung" und 2-3h fallen da ohnehin an. Es gibt auch keine Diskussion um den Preis. Eine Firma muss ohnehin einen Bestellvorgang auslösen und es registrieren und fakturieren. Also einmal SAP-Mann aktivieren, der den Knopf drückt und einen im Controlling, der unterzeichnet. Das sind auch Kosten im Bereich von 100,- aufwaerts. Hobbylizenz für nichtkommerzielle Nutzung könnte man diskutieren, wird aber keiner machen, der nicht Bedarf hat.
Harald E. schrieb: >> Kein Kopierschutz > Ohne Kopierschutz kauft es keiner, sondern benutzt es einfach. Und mit hinreichend kompliziertem Kopierschutz benutzt es keiner. Du darfst halt nie vergessen, dass jegliche Form von Kopierschutz und Sicherheitstheater in erster Linie dem ehrlichen Käufer schadet; demjenigen mit der geknackten Version ist das egal. Die Computerspieleindustrie hat es bis zu dem Punkt getrieben, wo selbst die ehrlichen Käufer lieber Kopien benutzt haben - oder sogar mussten, weil der originale Schutz zu unzuverlässig war. Da kommt Freude auf.
Die eFUSEs in den Ultrascales nützen dir m.M. nach nichts, wenn du nicht der Boardhersteller bist. Dort kann man bei den Ultrascales einen Schlüssel für einen Signaturcheck und für die Verschlüsselung der Firmware reinlegen. Allerdings eben nur einen und der muss dann für sämtliche Firmware benutzt werden, die da reingeht. Wahrscheinlich ist das bei den von dir genutzten Boards nicht aktiv, da ja offensichtlich deine eigene FW ohne Schlüssel eingespielt werden kann. Setzt du jetzt aber einen Schlüssel in den eFUSEs für deine FW, kann die original-FW nicht mehr eingespielt werden, da die den Schlüssel nicht kennt.
VHDL hotline schrieb im Beitrag #6727763: > Setzt du jetzt > aber einen Schlüssel in den eFUSEs für deine FW, kann die original-FW > nicht mehr eingespielt werden, da die den Schlüssel nicht kennt. Aber muss die den denn kennen? Sie läuft ja auch bisher ohne? Oder Verweigert der FPGA das Beladenwerden mit einer firmware, wenn die fuses gesetzt sind? Diese Frage betrifft doch praktisch jede Evaluierungs-Plattform von FPGAs. Die würden alle nicht mehr laufen, wenn ich als Benutzer einmal die FUSEs setze. S. R. schrieb: > Die Computerspieleindustrie hat es bis zu dem Punkt getrieben, wo selbst > die ehrlichen Käufer lieber Kopien benutzt haben - oder sogar mussten, > weil der originale Schutz zu unzuverlässig war. Da kommt Freude auf. Lag aber auch daran, dass der Schutz oft darin bestand, dass ein Code von Flash-Dongles hin und her geschrieben wurde oder ein Zähler dafür sorgte, dass jedes Teil nur in einer Console funktionierte und dann mit der Zeit über den Jordan ging. Ich benutze auf den Entwicklungsplattformen keine FUSEs. Es gibt immer eine indivuduelle Hardware mit fest verbautem Flash zu Kennung. Die Mühe, FPGAs zu hacken, um den Code zu nutzen macht sich niemand, weil der FPGA immer nur ein Teil des Systems ist.
Markus W. schrieb: > Aber muss die den denn kennen? Sie läuft ja auch bisher ohne? Wenn du den Secure Boot aktivierst (per eFUSE), dann muss man die kennen. Der FPGA erlaubt kein Einspielen von nicht/anders signierter FW mehr, das ist ja der Sinn des sicheren Boot. Für Evaluierungsplattformen sollte das daher sinnvollerweise nicht aktiviert sein und bei der HW des TO ist es dann wohl auch nicht aktiv.
Harald E. schrieb: > Laufzeitbeschränkung wäre auch zu knacken oder zu umgehen und Das muss man dann auch machen. Da sind dann noch ein paar weiter die etwas später kommen. > die möchte ich auch nicht, um mich nicht unter Druck zu bringen Da kommt dann halt ne Fehlermeldung, muss ja keiner wissen.
Angehängte Dateien:
-
fpga_key2.PNG
74 KB
https://www.intel.com/content/www/us/en/programmable/products/reference-designs/all-reference-designs/industrial/ref-des-secur-mem.html FPGA Design Security Solution Using a Secure Memory Device Reference Design Unter dem Link ist noch ein RefDesign drin. Oder der Ident-Chip gleich mit in die Leiterplatte in den 6 Lagen einlaminieren.
VHDL hotline schrieb im Beitrag #6727815: > FPGA erlaubt kein Einspielen von nicht/anders signierter FW > mehr, das ist ja der Sinn des sicheren Boot Ach!
Harald E. schrieb: > Leider den Sinn meiner Aussage nicht verstanden. Es sind eben keine > 5.000 Stk.! Es sind gfs 500-1000 im Höchstfall und dies eben nur, wenn > weite Teile der Nutzer keine Extrahardware kaufen müssen. Ist das so > schwer zu verstehen? Das ist eine "Der Nutzer kann seinen PC auch noch > für was anderes nutzen"-Software. Nur nicht für PCs sondern SoCs. Selbst bei 500 bis 1000 Stueck wird er das machen. Ein OneWire Chip mit 3 Beinchen klatscht der dir Nachts im Schlaf mit drauf. Wie waere es wenn du einfach mal beim Hersteller nachfragst, anstatt soviele Digne anzunehmen? Ich dachte du hattest mal ein Ing. Buero, da war Kommunikation mit dem Hersteller doch gaengige Praxis, oder? ;-)
Tobias B. schrieb: > Wie waere es wenn du einfach mal beim Hersteller nachfragst, anstatt > soviele Digne anzunehmen? Ich dachte du hattest mal ein Ing. Buero, da > war Kommunikation mit dem Hersteller doch gaengige Praxis, oder? ;-) Eine grundsätzliche Diskussion mit dem Hersteller scheint ja stattgefunden zu haben, denn er schreibt: Harald E. schrieb: > Mti dem hatte ich mich schon kurzgeschlossen ... > ... , ist zu aufwändig, da Kleckerbetrag. Ich würde auch nicht erwarten, dass einer ein neues board design auflegt, nur weil ein einzelner Nutzer eine kleine Änderung haben möchte. Außerdem möchte der TE offensichtlich nur Software verkaufen und mit harter Ware nichts (mehr) zu tun haben. S. R. schrieb: > Zusammengefasst: Du möchtest eine Software vertreiben, die auf einer > frei zugänglichen Hardware läuft. Ferner möchtest du verhindern, dass > jemand deine Software auf einem Gerät laufen lassen kann, für das er > nicht bezahlt hat. Für mich ist die Vorgehensweise "Software liefern" ein klassischer Fall für eine Softwaresicherung. Den weiteren Ausführungen von S.R. ist nichts hinzuzufügen.
Tippgeber schrieb: > Ich würde auch nicht erwarten, dass einer ein neues board design > auflegt, nur weil ein einzelner Nutzer eine kleine Änderung haben > möchte. Außerdem möchte der TE offensichtlich nur Software verkaufen und > mit harter Ware nichts (mehr) zu tun haben. Das kann ich mir bei bestem Willen aber nicht vorstellen. Bei Dave, Enclustra, Trenz und wie sie alle heissen, lohnt es sich in der Regel schon ab 100 Stueck ein eigenes FPGA Board zu machen. Da kann ich mir schwer vorstellen, dass bei 500 Stueck sich eine minimalste Anpassung nicht lohnen soll. Das ganze hier erscheint irgendwie strange. :-/
S. R. schrieb: > Und mit hinreichend kompliziertem Kopierschutz benutzt es keiner. Der Vorgänger wurde auch benutzt und bezahlt. Mach Dir mal keine Sorgen :-) In Zeiten, in denen jeder sein Telefon alle 2 Jahre aktualisiert und hunderte Euros für Unsinn ausgibt, sind Softwarekosten unter 500,- kein Thema. Tobias B. schrieb: > Das kann ich mir bei bestem Willen aber nicht vorstellen. Bei Dave, > Enclustra, Trenz Wenn du eine eigene HW bestellst, musst du sie auch bezahlen und rund 500,- x (in meinem Fall) 250 Stk Mindestabnahme (wurde angeboten) kommt auf eine nicht vorfinanzierbare Summe. Jedenfalls nicht in einem Coronajahr. Aber wieder zum Technischen:
Sodele, das mit den FUSE habe ich jetzt kapiert. Scheidet demnach aus, Danke an Holger. Bliebe noch die DNA: Angenommen, ich bilde aus dem DNA des FPGA und dem Namen des Kunden sowie der Softwareversion einen CODE, dann müsste dieser in die Verilog-Software hinein, um sicherzustellen, dass die Firmware (die für den FPGA-Chip) nur bei einem Kunden und einer Hardware läuft. Das Problem mit den 32 gleichen DNAs wäre auch mit erledigt.(?) Bliebe also nur, das so sicher zu machen, dass man nicht einfach einen Bitstrom hacken kann.
Das FPGA bietet zuviele Angriffsmoglichkeiten. Benutze das eeprom. Z.b. 256 byte. Das sind 8x 32byte oder 256 bit 32 byte für user ID(30 für ID, 1 für checksum, 1 für Rest checksum), 4 byte für unix-time, 4byte für Option, 2byte für Version. 16bit für auth, 16 bit checksum, 4byte system ID. Dann kommen auth+ checksum + 128 byte HW calib Daten, und dann ein slot für update sowie ein slot für Statistik. Slot 1 benutzt einen asymmetrischen key, wie auch slot2 oder slot7. Slot3-6 verwenden auch die 64 bit DNA im decryption key. Ein kleiner pic micro im fpga welcher auch sonstige wichtige Funktionen steuert. Sollte der demo modus oder timeout modus verwendet werden wird das update bzw Statistik Slots anders benutzt. Wenn kein separates eeprom kann man auch das config EPROM verwenden.
Harald E. schrieb: > Tobias B. schrieb: >> Das kann ich mir bei bestem Willen aber nicht vorstellen. Bei Dave, >> Enclustra, Trenz > Wenn du eine eigene HW bestellst, musst du sie auch bezahlen und rund > 500,- x (in meinem Fall) 250 Stk Mindestabnahme (wurde angeboten) kommt > auf eine nicht vorfinanzierbare Summe. Jedenfalls nicht in einem > Coronajahr. Asooooo, aber dann sehe ich auch nicht, warum das Produkt so wertvoll ist zu schuetzen. Entweder du vertraust darauf, dass es in den entsprechenden Stueckzahlen weggeht. weswegen man es auch ordentlich schuetzen muss oder die realistischen Stueckzahlen sind vll. doch deutlich niedriger als man erwartet, aber dann ist es auch egal ob es geschuetzt wird. Was sagt der Business Plan zu der ganzen Idee? Koennen Risikokapitalgeber davon ueberzeugt werden, dass das Produkt durch die Decke geht?
Tobias B. schrieb: > Asooooo, aber dann sehe ich auch nicht, warum das Produkt so wertvoll > ist zu schuetzen. Es ist wertvoll genug, dass es jemand für lau nutzt, wenn er es umsonst bekommt. Schau mal, wieviele kostenlose APPs Du benutzt, nur weil sie umsonst sind. Würde man dafür zahlen müssen, hätten die Meisten nur die Hälfte davon drauf. > Entweder du vertraust darauf, dass es in den > entsprechenden Stueckzahlen weggeht. Da gibt es nichts zu vertrauen. Der Entwicklungsaufwand ist zu 80% bereits geleistet und stammt aus dem Vorgänger. Der soll nun ersetzt werden. Wie weit ich das noch ausbaue, hängt von Markt ab. > Was sagt der Business Plan zu der ganzen Idee? Sie oben: Geschätzt mindestens 5.000 Installationen weltweit mit einer Plattform dieses Herstellers in der Sparte der Anwendung (Maschinensteuerung und -überwachung). Wahrscheinlich mehr. Tendenz steigend, da weltweit die Anforderungen steigen und die Firmen immer wieder umrüsten. SoC-Plattformen finden dort starke Verbreitung. Langfristig sicher 10.000 Installationen. Etwa 5% bis 20% der Kunden können mit meinem Produkt etwas anfangen. Sie können es während der Inbetriebnahme nutzen (und müssen dann eine Plattform zweckentfremden) oder als Überwachung mit einsetzen, also 1-2 weitere kaufen. Die Produktionsanlagen, die dort stehen und Maschinen, die da laufen, gehen in die Mio. Die Elektronik drum herum immerhin noch in die Hunderttausende + eben soviel an Ingenieur-Inbetriebnahmezeit. Da macht etwas Messtechnik nicht viel aus. Wie schon erwähnt, müssen die momentan mindestens eine DAQ-Karte, Datenlogger und / oder noch einen Analyser hinstellen oder ein Fertiggerät des Wettbewerbs in der Größenordnung von bis zu 5.000 Euro bemühen, das sie nur halb nutzen. Wenn sich die Kunden, die das so machen, aber mein System zulegen (und damit rund 2k sparen) können sie auch gleich 2 nehmen, die Techniker damit ausstatten und noch IB-Zeit sparen. Von den (s.o.) 250-1000 Kunden, die das betrifft, sollte die Hälfte davon Gebrauch machen, langfristig das Doppelte. Ich rechne mit am Ende 500 Einheiten. Das ist also ein Umsatz, der kein Investment verträgt. Billig rauswerfen sehe ich daher nicht. Ich bin kein APP-Programmierer. Dann kriege ich nämlich 5.000 Abnehmer, die eine Software für 99,- kaufen, aber einen Arbeitsaufwand in der Größenordnung von 3h pro Kunde und arbeite am Ende für 20,- die Stunde. > Risikokapitalgeber davon ueberzeugt werden, dass das Produkt durch die > Decke geht? Nix Kapitalgeber! Ich verkaufe die SW Stückweise ohne weitere Vorinvestition.
Tippgeber schrieb: > Außerdem möchte der TE offensichtlich nur Software verkaufen und > mit harter Ware nichts (mehr) zu tun haben. Wie bereits erwähnt, läuft das Vorprodukt auf eigens produzierter (Zusatz-)Hardware, die der Kunde erwerben konnte. Chris schrieb: > Das FPGA bietet zuviele Angriffsmoglichkeiten. Jetzt bin ich wieder unsicher. Warum schreibt der Hersteller dann dies: Holger schrieb: > The UltraScale architecture-based FPGAs have on-chip Advanced > Encryption Standard (AES) decryption and authentication logic to > provide a high degree of design security. Without knowledge of > the encryption key, adversaries cannot analyze an externally > intercepted bitstream to modify or clone the design. Encrypted > FPGA designs cannot be copied or reverse-engineered. Das klingt doch prima. Wie könnte man das trotzem knacken?
Harald E. schrieb: > Wenn es mit dem branding des FPGA nicht geht, muss eben ein dongle her. > Dazu hattest Du den Chip von Maxim empfohlen. Leider ist das Dokument > nur unter NDA zu bekommen, wie ich feststellen musste. Warum nimmst Du nicht einfach einen DS18B20 als Dongle? Die haben alle eine eindeutige Seriennummer (48 Bit). Für jede SW Lieferung (Neu) legst Du einen DS18B20 bei, den Du vorher ausgelesen hast und die Seriennummer in Deiner SW hinterlegt hast. Den DS18B20 lieferst Du dann mit und der Kunde muss ihn eben an einen vorgegebenen Portpin knüppern. Was meinst Du zu dieser Idee?
Harald E. schrieb: > Das klingt doch prima. > Wie könnte man das trotzem knacken Du vergisst dass der Kunde in deinem speziellem Fall den AES key separat bekommt, sei es obfuscated or not und diesen selbst einprogrammiert. Würdest du HW liefern dann sieht die Sache anderer aus, müsstest allerdings jtag durch efuse verbieten da es sonst angreifbar wäre.
Hast du dir schon mal https://www.wibu.com/de.html angeschaut? Ich selbst habe es noch nicht benutzt und daher k.A. ob es was taugt oder was es kostet. Ich kenne die nur weil sie viel Werbung machen. Hat diese Fremdhardware einen USB-Anschluss? Dann wäre eine Lösung mit Dongle wahrscheinlich am besten. Wibu hat aber auch Dongles im Speicherkartenformat.
Harald E. schrieb: > Sie oben: Geschätzt mindestens 5.000 Installationen weltweit mit einer > Plattform dieses Herstellers in der Sparte der Anwendung > (Maschinensteuerung und -überwachung). Wahrscheinlich mehr. Tendenz > steigend, da weltweit die Anforderungen steigen und die Firmen immer > wieder umrüsten. SoC-Plattformen finden dort starke Verbreitung. > Langfristig sicher 10.000 Installationen. Aber dann raff ichs immer noch nicht. Dann lohnt es sich doch locker, wenn du dir professionelle Expertise einkaufst und nach Unterzeichnung eines NDAs auch Details offen legen kannst. Mit den wenigen Details die du hier preisgeben willst, wirst du nie eine Loesung bekommen die deinen Anspruechen genuegt. Gerade wenn du sagst, dass die Hardware fix ist und nicht daran geruettelt werden kann.
Markus W. schrieb: >> Die Computerspieleindustrie hat es bis zu dem Punkt getrieben, wo selbst >> die ehrlichen Käufer lieber Kopien benutzt haben - oder sogar mussten, >> weil der originale Schutz zu unzuverlässig war. Da kommt Freude auf. > Lag aber auch daran, dass der Schutz oft darin bestand, dass ein Code > von Flash-Dongles hin und her geschrieben wurde oder ein Zähler dafür > sorgte, dass jedes Teil nur in einer Console funktionierte und dann mit > der Zeit über den Jordan ging. Ich dachte z.B. an timingabhängige Schutzmechanismen für CDs (die auf originaler Hardware nicht funktionieren, je nach Hersteller des CD-Laufwerks). Die Malware-Varianten oder die Arcade-Schutzmechanismen sind noch eine ganz andere Klasse. Harald E. schrieb: > Wie bereits erwähnt, läuft das Vorprodukt auf eigens produzierter > (Zusatz-)Hardware, die der Kunde erwerben konnte. Und davon möchtest du wegkommen, richtig? Wenn einen Dongle akzeptieren kannst, warum keinen Dongle für die vorhandene Hardware? Ein-zwei Pins, wo du einen Securitychip anknoten kannst, wäre sinnvoll. An deiner Stelle würde ich einfach auf einen vom Hersteller vorgesehenen Weg setzen (z.B. den Ausleseschutz bei Mikrocontrollern) und darauf vertrauen, dass meine Kundschaft den Aufwand für einen Hack scheut. Einen hundertprozentigen Schutz bekommst du sowieso nicht hin. Du richtest dich offensichtlich an einen eher kleinen Kreis von Industriekunden. Wahrscheinlich sogar schon jetzt Kunden von dir. Für die sind 2000€ für ein paar Lizenzen ein geringeres Problem als ein paar Monate reverse engineering, wo der Erfolg nicht feststeht. Oder hast du Angst vorm bösen Chinesen, der das Gesamtprodukt kopiert und billiger verkauft? Nachtrag: Bitte definiere erstmal das Angriffsmodell. Wovor hast du konkret Angst, wie definiert sich der maximale Schaden in diesem Fall, und wie hoch ist der Aufwand des Schutzes? Bevor du selbst nicht weißt, was du willst - oder es hier nicht schreibst - wirst du keine Lösung finden.
:
Bearbeitet durch User
Harald E. schrieb: >> Und mit hinreichend kompliziertem Kopierschutz benutzt es keiner. > Der Vorgänger wurde auch benutzt und bezahlt. > Mach Dir mal keine Sorgen :-) Der Vorgänger bestand aus Hardware. Das ist ein physisches Produkt, da gelten andere Regeln.
Harald E. schrieb: > Holger schrieb: >> The UltraScale architecture-based FPGAs have on-chip Advanced >> Encryption Standard (AES) decryption and authentication logic to >> provide a high degree of design security. Without knowledge of >> the encryption key, adversaries cannot analyze an externally >> intercepted bitstream to modify or clone the design. Encrypted >> FPGA designs cannot be copied or reverse-engineered. > Das klingt doch prima. > > Wie könnte man das trotzem knacken? Die Frage ist nicht wie man das knackt, sondern wie aufwändig das Ganze ist. Grundsätzlich ist erst mal jede Verschlüsselung knackbar, es ist nur eine Frage der Zeit und des sonstigen Aufwandes und da scheidet sich Spreu vom Weizen. Es kommt darauf an ob sich der immense Aufwand des Knackens lohnt und am Ende dann noch etwas rum kommt. In 99,9% der Fälle dürfte es günstiger sein, das verschlüsselte Produkt zu kaufen.
S. R. schrieb: > Harald E. schrieb: >>> Und mit hinreichend kompliziertem Kopierschutz benutzt es keiner. >> Der Vorgänger wurde auch benutzt und bezahlt. >> Mach Dir mal keine Sorgen :-) > Der Vorgänger bestand aus Hardware. > Das ist ein physisches Produkt, da gelten andere Regeln. Es ging Dir doch darum, dass es mit Kopierschutz keiner benutzt. Das stimmt eben nicht. Der Aufwand war vorher sogar noch höher für den Kunden, weil er ein NDA unterzeichnen musste. Chris schrieb: > Du vergisst dass der Kunde in deinem speziellem Fall den AES key separat > bekommt, sei es obfuscated or not und diesen selbst einprogrammiert. Warum sollte der den bekommen müssen? Um zwischen Softwareversionen auf derselben HW unschalten zu können, nehme ich an. Dann lasse wir den Punkt weg und kalkulieren nur den Fall, dass er eine neue HW nimmt, um meine SW zu betreiben. Das sollte nicht wesentlich schlechter sein, weil sich viele Kunden ohnehin nicht den Aufwand machen dürften. Nur so als Beispiel das Ergebnis eines heutigen Sondierungsgespräches in einer anderen Sache: Dort ist es so, dass der Kunde für jede Messaufgabe einen eigenen PC hinstellt, teilweise als remote, um vom Arbeitsplatz drauf zugreifen zu können. Einen vollständigen PC mit Installation, der nur zu 10% genutzt wird. Grund: Man will keine LAPTOPs mehr hin und her schleppen, anschließen, konfigurieren, booten, LABVIEW anpassen und laden und die Verkabelung einprogrammieren. Bequemlichkeit lassen sich die Firmen was kosten.
OldMan schrieb: > Warum nimmst Du nicht einfach einen DS18B20 als Dongle? Das wäre das gleiche wie der von Lothar vorgeschlagene Spezial-Dongle. Tobias B. schrieb: > Aber dann raff ichs immer noch nicht. Dann lohnt es sich doch locker, > wenn du dir professionelle Expertise einkaufst und nach Unterzeichnung > eines NDAs auch Details offen legen kannst. Welche Expertise soll ich einkaufen? Wie man SW verdongelt? > Mit den wenigen Details die du hier preisgeben willst, wirst du nie eine > Loesung bekommen Was muss man denn noch wissen um zu klären, wie bei einem SoC ein SW-Schutz funktionieren kann. Das ist doch nicht von der Anwendung abhängig. > dass die Hardware fix ist und nicht daran geruettelt werden kann. nicht gerüttelt werden soll! Das ist eine Idealanforderung. Wenn es nicht geht, kommt eben der dongle. Blechbieger schrieb: > Hast du dir schon mal > https://www.wibu.com/de.html > angeschaut? Ja, aber zu kompliziert. Ich brauche auch nicht noch einen Mitverdiener.
Zeno schrieb: > ie Frage ist nicht wie man das knackt, sondern wie aufwändig das Ganze > ist. Grundsätzlich ist erst mal jede Verschlüsselung knackbar, es ist > nur eine Frage der Zeit und des sonstigen Aufwandes und da scheidet sich > Spreu vom Weizen. Das ist richtig, allerdings ergibt sich daraus - wenn man es zu Ende denkt - die Lösung, den Aufwand zu hoch zu treiben, dass die Entschlüsselungsdauer 1 Mio Jahre ist, um potenzielle Cracker vom Versuch abzuschrecken. Wenn man gute Codes knacken will, braucht es Annahmen über die Verschlüsselungsmethode und Ergebnisse aus Versuchen, die mathematisch untersucht werden. Das lohnt aber nur bei sehr wichtigen Systemem und wird wahrscheinlich nur bei Geheimdiensten gemacht :-) > Es kommt darauf an ob sich der immense Aufwand des > Knackens lohnt und am Ende dann noch etwas rum kommt. In 99,9% der Fälle > dürfte es günstiger sein, das verschlüsselte Produkt zu kaufen. So ist es. Jedenfalls im professionellen Umfeld. Es gibt allerdings das Problem, das hier noch nicht erörtert wurde, das aber immer mehr um sich greift: Hersteller X verkauft seine HW mit Software und verdient an beidem. Hersteller Y baut die HW billig nach und nutzt die Software des Herstellers X. Oder der Plagiator baut eine Zusatzhardware und nutzt das Original, wie bei der Methode "Tintenstrahldrucker", wo es billige Nachbauten der Druckköpfe und der Patronen gibt. Selbst im Medizinsektor ist mir das schon begegnet, wo es aus Asien plötzlich austauschbares Zubehör für Produkte meines Kunden gab, der am Service verdiente, indem er Kunden das Hauptgerät günstig zur Verfügung stellte und einen Wartungsvertrag abschloss. Da braucht es schon eine geschickte Verriegelung. Die dar aber nicht nur aus einem Code bestehen, der irgendwann mal abgefragt ist. Die IMHO beste Methode ist eine laufzeitbegrenzte Software, die nach 1J zum Service zwingt und danach die HW zum Erliegen bringt. Dann hat man als Hersteller regelmäßig die Chance, die Schutzstrategie seiner HW zu ändern und eine einmal geknakcte Vorgehensweise hält nicht lange vor.
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.