Forum: FPGA, VHDL & Co. Eigene SoC-Software vor Duplizierung schützen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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:

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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.

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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

von Christoph Z. (christophz)


Lesenswert?

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.

von aäfdkj (Gast)


Lesenswert?

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.

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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:

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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.

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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.

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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.

: Bearbeitet durch User
von Martin S. (strubi)


Lesenswert?

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.

von W.S. (Gast)


Lesenswert?

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.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

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.

von Martin S. (strubi)


Lesenswert?

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..

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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:

von Harald E. (Firma: Automatisierungstechnik) (heisat1984)


Lesenswert?

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. ?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.