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_functionHarald 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.
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.
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.
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-docshttps://www.maximintegrated.com/en/design/technical-documents/app-notes/4/4594.htmlhttps://www.maximintegrated.com/en/design/technical-documents/app-notes/3/3826.htmlhttps://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.
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 (?)
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.
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.
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.
