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
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
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.
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.
>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.
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.
>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)
Lustig ;) Du willst in HW einen Hash über einen Code machen, der einen Hash berechnet. Warum dann den originalen Hash nicht gleich in HW?
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.
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
@Michael: Muss da nicht noch am Ende data2mem aufgerufen werden, um das mem-File an die richtige Stelle im bit-File zu bekommen? Duke
>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.
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.
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.
Es geht doch viel einfacher. Man nimmt Klebstoff und dann kann keiner mehr etwas auslesen.
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 ;)
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.
"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?
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 ;)
Was gibt es denn für Möglichkeiten für erkennbare Ausfallerscheinungen ?
Na komm, etwas mehr Kreativität bitte... Hängt halt vom Gerät ab.
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,
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!!
Sabotage an medizinischen Laborergebnissen finde ich mal echt unter aller Kirche.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.