mikrocontroller.net

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


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

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
>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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
>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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
@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:

Bewertung
0 lesenswert
nicht lesenswert
>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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
Es geht doch viel einfacher. Man nimmt Klebstoff und dann kann keiner 
mehr etwas auslesen.

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
"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:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
Was gibt es denn für Möglichkeiten für erkennbare Ausfallerscheinungen ?

Autor: Georg A. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na komm, etwas mehr Kreativität bitte... Hängt halt vom Gerät ab.

Autor: Fpga Kuechle (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
Sabotage an medizinischen Laborergebnissen finde ich mal echt unter 
aller Kirche.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:

Bewertung
0 lesenswert
nicht lesenswert
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
  • 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.
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 bestätigst du, die Nutzungsbedingungen anzuerkennen.