www.mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA Kopierschutz mit einem DS2432


Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:
Angehängte Dateien:

Hallo,

Ich will verhindern das mein Design in China geklont wird. Bei Xilinx
bin ich über die XAPP780 gestolpert. Im Prinzip wird dort eine Freund /
Feind Erkennung gemacht. Das dies keine 100% Sicherheit gibt ist mir
bewusst. Eine denkbare Angriffsmöglichkeit wäre zum Beispiel den BRAM
mit dem Picoblaze Code auszulesen und zu verändern.

1) Hat jemand schon mal das XAPP780 so umgesetzt ? mit welchen
Erfahrungen ?
2) Wie Aufwändig wäre es für einen Angreifer, das Picoblaze Programm zu
manipulieren ?
3) Ist Tatsächlich der geheime Schlüssel im Klartext im FPGA hinterlegt
? oder nur ein Hash ?

Laborsauron
Autor: Kest (Gast)
Datum:

Hallo,

ich habe sowas ähnliches schon mal gemacht. Allerdings mit Altera FPGA
und einem CPLD, den man nicht auslesen konnte. Im Endeffekt, hat das
FPGA ohne CPLD nicht funktioniert.

Aber ehrlich, den Aufwand, den man betreiben müsste, um den Device zu
clonen wir kein Schwein bezahlen ;-) Für das Geld und Zeit hätte man
locker was Neues entwickeln können.

Mit Picoblaze wäre ich etwas vorsichtig (falls die Entschlüsselung und
Überprüfung in Software passiert), denn man könnte tatsächlich BRAM
auslesen (denke ich). Aber wenn man alles selber implementiert, dann ist
alles in Butter.

Grüße,
Kest
Autor: Björn Cassens (bjoernc) Benutzerseite
Datum:

naja was du auch machen könntest wäre eine AES verschlüsselung direkt
auf dem Conf-Prom, dazu gabs meines erachtens nach auch eine XAPP für.
Autor: spartanne (Gast)
Datum:

Michael Sauron schrieb:
> 1) Hat jemand schon mal das XAPP780 so umgesetzt ? mit welchen
> Erfahrungen ?

Umgesetzt ja, ist schon etwas her. Die OneWire-Timings im Code von
Xilinx passen je nach verwendetem Baustein allerdings nicht. Man kommt
meiner Meinung nach nicht umher den PicoBlaze-Code genauer zu
betrachten.

Michael Sauron schrieb:
> 2) Wie Aufwändig wäre es für einen Angreifer, das Picoblaze Programm zu
> manipulieren ?

Gute Frage. Wenn man das BRAM ausliest hat man vermutlich Chancen zur
Manipulation. Hmm, stimmt mich gerade etwas nachdenklich...

Michael Sauron schrieb:
> 3) Ist Tatsächlich der geheime Schlüssel im Klartext im FPGA hinterlegt
> ? oder nur ein Hash ?

Der geheime Schlüssel steht nicht im BRAM sondern sinnvollerweise in den
LUTs. Das zu knacken heisst man müsste das ganze Bitfile rückwärts zum
Source-Code konvertieren, was ein zu hoher Aufwand wäre.


Wichtig bei der ganzen Geschichte ist es einen zufälligen Seed für den
Hash-Algorithmus zu erzeugen. Eine Pseudo-Zufallszahl wird nicht
reichen. Da braucht es schon eine echte Zufallszahl.
Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:

>Die OneWire-Timings im Code von
>Xilinx passen je nach verwendetem Baustein allerdings nicht

welche Alternativen gibt es denn zum DS2432 ?

Und woher kann ich eigentlich den DS2432 bekommen ? hab ihn bei den
Üblichen verdächtigen nicht gefunden.
Autor: Georg A. (Gast)
Datum:

Nachdem der Picoblaze-Code von Xilinx etwas undurchsichtig ist und die
Sache mit dem BRAM ein ziemliches Einfallsloch darstellt, ist für eine
echte Sicherung eine HW-Implementierung des SHA deutlich besser. Ist
zwar etwas Gefummel, aber machbar und schnell muss es ja auch nicht
laufen. Den One-Wire-Kram kann man immer noch mit einer CPU
(Pico/Microblaze) machen, das ist ja nicht sicherheitsrelevant, solange
das Wissen um den korrekten Hash und die richtige Reaktion darauf in der
SHA-HW selbst bleibt. BTDT.

Für das vollständige Datenblatt vom DS2432 braucht man zumindest
offiziell ein NDA von Maxim. Kaufen kann man den AFAIK nur über
offizielle Distris, zB. Spezial-Elektronik, hängt auch am NDA.
Autor: duckundwech (Gast)
Datum:

>und die Sache mit dem BRAM ein ziemliches Einfallsloch darstellt

genau das ist eine gute Frage, ist das wirklich ein schwachpunkt ?
Ich könnte ja einen Hash über das BRAM machen, und schauen, ob er
unverändert ist. (natürlich ausserhalb des Picoblaze)
Autor: Georg A. (Gast)
Datum:

Lustig ;) Du willst in HW einen Hash über einen Code machen, der einen
Hash berechnet. Warum dann den originalen Hash nicht gleich in HW?
Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:
Angehängte Dateien:

Ich hab jetzt mal versucht das ganze umzusetzen, hab aber meine Probleme
damit.

Ich benutze einen Spartan3 und habe die ISE 9.2.04

Loadtest funktioniert auch einwandfrei, und meldet ein ordentlich
beschriebenen DS2432.
Wenn ich jedoch IFFTEST ausführe, passiert garnichts. Ich hab mir das
mal im Simulator angesehen, und festgestellt das das Blockram des
Picoblaze komplett leer ist. Das Blockram sollte eigentlich mit der
Datei iff_scr_v30.mem gefüllt werden. Das Design ist von der Xilinx
Seite und wurde von mir nicht verändert. Ich habe den eindruck, dass die
mem Datei komplett ignoriert wird. Leider habe ich noch nie etwas mit
mem oder bmm Dateien gemacht. Ich verstehe auch die einbindung von
iff_scr_v30 nicht. Der Dateiname wird nirgends angegeben. Reicht da etwa
die blose anwesenheit der Datei, damit sie eingebunden wird ?
Woran kann es liegen, das der Picoblaze kein Programm hat.

Bevor jemand fragt, nein ich habe keine Testbench dafür, sondern mir
einen Takt mit Test Bench Waveform generiert.
Autor: Frank K. (fchk)
Datum:

Warum nimmst Du nicht ein FPGA, das für Deine Aufgaben besser geeignet
ist? Ich werfe hier mal ACTEL in den Raum. Kein Config-PROM - weniger
Angriffsfläche.

fchk
Autor: Duke Scarring (Gast)
Datum:

@Michael:

Muss da nicht noch am Ende data2mem aufgerufen werden, um das mem-File
an die richtige Stelle im bit-File zu bekommen?

Duke
Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:

>Muss da nicht noch am Ende data2mem aufgerufen werden, um das mem-File
>an die richtige Stelle im bit-File zu bekommen?

Ich habe bisher noch nie  mit data2mem gearbeitet.
Aber data2mem wird in der Doku auch nirgends erwähnt.
Ausserdem hab ich ja ein gültiges mem File (unverändet aus dem Beispiel)
Aus irgendwelchen gründen die ich noch nicht verstehe, wird das Bram
leer gelassen.

Aber ich versteh auch nicht, wie und wo die datei iff_scr_v30.mem
eingebunden werden soll. Der Dateiname ist weder im der IFFTEST.BMM
Datei noch in der Datei IFF1.VHD zu finden.
Es ist mir irgendwie schleierhaft wie aus den 3  genannten Dateien ein
Blockram entstehen soll.
Autor: Georg A. (Gast)
Datum:

Du kannst mit data2mem die Daten auch ins bitfile schreiben. Versuch
doch mal
data2mem -bm xxx.bmm -bd xxx.mem -bt orig.bit -o new.bit.
Autor: Michael Sauron (Firma: www.das-labor.org) (laborsauron)
Datum:

Hab mir grad mal die Anleitung zu data2mem angesehen. Da wird
ersichtlich, das der BRAM erst mit Impact in das Bitfile geschrieben
wird. Das erklärt auf alle fälle schon mal das leere BRAM bei der
Simulation. Warum das in der XAPP780 nicht erwähnt wird, ist mir aber
schleierhaft.
Autor: Heinrich (Gast)
Datum:

Es geht doch viel einfacher. Man nimmt Klebstoff und dann kann keiner
mehr etwas auslesen.
Autor: Georg A. (Gast)
Datum:

Das ist nicht ganz zu Ende gedacht. Einerseits gibt es kein Material,
was man nicht vorsichtig abschleifen/abtragen kann. Mag etwas mühsam
sein, aber wenn die Motivation da ist... Und zweitens ist es bei vielen
FPGA-System ja so, dass der Bitstream upgedatet werden kann/muss/soll.
D.h. er liegt in irgendeinem Filesystem/Flash rum und eine CPU
initialisiert das FPGA oder es gibt Wege, übers FPGA das in-system ins
Config-Flash reinzuschreiben. Das heisst aber, dass der Bitstream
irgendwo roh rumliegt und zugreifbar ist. Sowas lässt sich kaum
schützen, wenn man nicht jetzt die Virtex-Methode mit den AES-Keys im
batteriegepufferten SRAM machen will.

Da ist es dann deutlich einfacher, dem FPGA ein TPM zur Verfügung zu
stellen, womit das FPGA selbst verifizieren kann, dass es in einer
originalen HW sitzt. Dann darf natürlich das TPM nicht klonbar sein. Vom
DS2432 habe ich da bislang nichts gelesen, was aber natürlich nichts
heissen muss ;)
Autor: Weltbester FPGA Pongo (Gast)
Datum:

Der einzig wirksame Schutz gegen direktes Clonen sind Aktionen des
FPGAs, die eine originale Hardware erkennen und sich sporadisch falsch
verhalten, wenn sie was anderes sehen. Dazu ist es nötig, daß in der
Produktion authentische Informationen in das board eingesprägt werden,
die nicht als solche zu erkennen sind und die mit board-unabhängigen
Informatioen zusammenspielen müssen, damit man nicht einfach boards hart
kopieren kann.

Dazu braucht man nur einen Flashspeicher, in den boardabhängige
Kalibierdaten geschrieben werden müssen. Das Kalibierprogramm schreibt
dann in die unwertigen Bits von z.B: Gain-Offset-Korrekturwerten noch
Codes hinein, die ganz bestimmte Werte haben müssen, z.B. einen
speziellen CRC, der aus dem Rest gebildet wird.

Ein konkretes Beispiel ist eine Applikation, die folgendes tut:

Jeder ADC-Kanals bekommt einen GOC-Wert, der aus einer
Kurzschlussmessung in der fab ermittelt wird. Dieser besteht aus einem
16bit Gain- und einem Offset-Korrekturwert, die beide in ein 48
bit-Register geschrieben werden, allerdings mit vertauschten Bits und
Lücken. In die restlichen Bits wird ein CRC-Code reingeschrieben, der
aus dem Rest gebildet wird, allerdings auch wieder mit vertauschten
Bits.

Es gibt mehrere FPGA Versionen pro Kunde mit unterschiedlichen
Strategien zur Verteilung von Bits, die zufällig auf die boards gespielt
werden. Passend dazu kann ein Kalibrierprogramm die FPGA Versionen lesen
und den Strategien zuordnen. Die Boards werden kundenspezifisch geprägt.

Wenn das FPGA erkennt, dass ein falscher CRC eingestellt wurde, dann
rechnet es sporadichs falsch, bzw wenn versucht wird unsinnige
Kalibrierwerte einzustellen, dann rechnet es immer falsch. Letzteres
kann man durch Ausprobieren noch herausfinden, ersteres nicht.

Der Chinese braucht immer ein aktuelles Programm mit den Kalibriercodes,
das er sich illegal verschaffen müsste.

Die boards sind so eingestellt, daß sie alle 2 Jahre in die Wartung
müssen und das FPGA-image "abläuft"!  Selbst wenn dann Geräte
auftauchen, die mit geclonten Codes funktionieren würden, könnte man die
leicht identifizieren bzw der Kunde hat nicht viel davon.
Autor: faustian (Gast)
Datum:

"Der einzig wirksame Schutz gegen direktes Clonen sind Aktionen des
FPGAs, die eine originale Hardware erkennen und sich sporadisch falsch
verhalten, wenn sie was anderes sehen. "

Naja, aber ist ein schlecht funktionierender, identisch aussehender Klon
nicht mittelfristig noch VIEL schaedlicher fuer eine Marke als ein
zuverlaessiger?
Autor: Georg A. (Gast)
Datum:

Nicht, wenn er sehr schnell sehr deutliche und "erkennbare" *)
Ausfallserscheinungen zeigt. Das muss je nach Gerätetyp innerhalb von
Minuten bis Tagen passieren, wo der Käufer auf jeden Fall noch mit der
Gewissheit beim Service anrufen kann, dass das Gerät schon bei der
Auslieferung defekt war. Das hat auch den Nebeneffekt, dass die Cloner
bei passendem Fehlerbild sich auch nicht sicher sein können, ob sie was
falsch gemacht haben (zB. falsches HF-Layout,
falsche/unterdimensionierte Bauteilwerte, etc.).

*) Was der "Load Error 296" heisst, sollte ja inzwischen auch jeder
Eagle-User wissen. Die Hotline wusste es sicher von Anfang an ;)
Autor: Matze (Gast)
Datum:

Was gibt es denn für Möglichkeiten für erkennbare Ausfallerscheinungen ?
Autor: Georg A. (Gast)
Datum:

Na komm, etwas mehr Kreativität bitte... Hängt halt vom Gerät ab.
Autor: Fpga Kuechle (fpgakuechle)
Datum:

faustian schrieb:
> "Der einzig wirksame Schutz gegen direktes Clonen sind Aktionen des
> FPGAs, die eine originale Hardware erkennen und sich sporadisch falsch
> verhalten, wenn sie was anderes sehen. "

Nein, das ist überhaupt kein Schutz gegen das Clonen!
Es verhindert nicht im geringsten das Hardware gebaut wird die sich zu
95%
genauso verhält wie das Orginal. Wird der Clone nicht ausreichend
getestet, fallen die sporad. Fehler nicht auf. Und selbst was hindert
den Cloner, die Geräte als Low Cost - Low Quality zu verkaufen. Im
ungünstigen Fall entscheidet sich ein Kunde, der den Low Quality Clone
kennt, auch gegen das Orginalprodukt. Man weiss ja nicht, ob die sporad.
Fehler nicht mitgeklont wurden.

MfG,
Autor: J. S. (Firma: Selbstständig) (engineer) Benutzerseite
Datum:

Wir reden nicht von low Quality, das stimmt, aber bei Grossgeräten
klappt das hervorragend.

>"ein, das ist überhaupt kein Schutz gegen das Clonen!"

Doch, wenn die Kunden nämlich wegbleiben und Schadenersatz verlangen

>Naja, aber ist ein schlecht funktionierender, identisch aussehender
>Klon nicht mittelfristig noch VIEL schaedlicher fuer eine Marke als
>ein zuverlaessiger?

Ja, aber man kann ja publizieren, dass Clons unterwegs sind, die
bestimmte Fehler zeigen und dann hat der Händler das Problem, bzw die
Kunden des Gerätenutzers gehen auf die Barrikaden:

Ich bringe mal folgendes Beispiel:

Eine Firma vertreibt ein teures Analysegerät, welches Chemikalien als
Verbrauchsstoffe, die mit einem RFID-Chip gesicherten Pack
bereitgestellt werden. Das Konzept ist so ähnlich, wie bei der Tinte und
den Druckern. Das Pack wird sehr gerne von den Chinesen geklont und
billig auf den Markt gebracht, weil sie die Chemikalien durch Kopieren
leicht und billig herstellen können, ohne die Forschungsleistung
erbracht zu haben, die in der Zusammensetzung und auch ihm Gerät steckt.

Wenn nun ein Labor sparen will, dann kauft es die Chemikalien-Packs
nicht vom Originalhändler sondern auch bei Mr. Wang aus Honghong. Der
Hersteller kann es nicht verhindern, daß das Labor 25% der Proben
billiger prozessiert - wenn dort aber Fehler auftreten (und sie treten
auf :-) ) dann hat das Labor einen Riesenärger am Hals, wenn z.B.
Blutproben nicht sauber dokumentiert prozessiert werden. Sobald da ein
Vorfall evident wird, wird geprüft, woher der Fehler kommt. Dann kommt
schon mal die FDA und verhängt Strafen oder das Paul-Ehrlich-Institut
entzieht die Plakette :-)

Ich kenne da eine deutsche Klinik, die keine Blutbilder mehr machen
darf!!
Autor: faustian (Gast)
Datum:

Sabotage an medizinischen Laborergebnissen finde ich mal echt unter
aller Kirche.
Autor: oszi40 (Gast)
Datum:

J. S. schrieb:
> nicht vom Originalhändler sondern auch bei Mr. Wang aus ...

Plagiate und Simulanten gibt es leider überall. Da hilft eher ein guter
Kundenservice und einige spezielle Updates. Wenn einer 1000 Messungen
macht und nie Material braucht, sollte die Wartungs-LED mal leuchten.
Autor: Bernd (Gast)
Datum:

Finde es immer lustig, wenn sich Leute über die kopierbarkeit
unterhalten.
OK, bin selber aus Deutschland, war aber schonmal bei einem
Hardwarehersteller in China.
Eine Firma besteht aus dem Firmenbos und vieleicht ein paar wenige
Mitstreiter. Der Rest sind unterbezahlte Mitarbeiter.
Das Problem hier ist die Unterschätzung derartigen Potentials. Alle
Leute dort sind unter 30 Jahre alt, hochmutiviert und wechseln nicht
selten jährlich die Firma. Ein Problem wird dort recht einfach gelöst.
Man suche sich einen Hersteller aus dem Westen, kaufe seine Produkte,
und setze 50 Ingeneoure daran. Es ist nur eine Frage der Zeit. Die Leute
sind auch Fachleute, auch wenn das Wissen nicht so breit ist wie im
Westen. Dafür kann man mit 5000 Euro aber viel Wissen bündeln.
Es gibt sicherlich keinen ausreichenden Kopierschutz, aber rein
Rechtlich lohnt es sich Gedanken zu machen um bei seiner Konkurrenz mal
zu schauen was sie entwickelt haben oder nicht.
Eagle hat einen sehr sinnvollen Kopierschutz. Sie habe in jedem
erstellten Produkt ein Wasserzeichen drin. Auch die meisten
einheimischen Hersteller verwenden ähnliche Systeme. Man schaue mal auf
Messen, was da los ist, im Moment werden sämtliche Stände geschlossen.
Bringt alles nicht viel, aber zu einfach würe ich es keinem machen.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder GIF-Format hochladen.
Siehe Bildformate
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken erkennst du die Nutzungsbedingungen an.

webmaster@mikrocontroller.netImpressumNutzungsbedingungenWerbung auf Mikrocontroller.net