Hallo Leute, hab folgendes Problem: Verwende ein Lattice-SC-FPGA, das über keine Bitstream-Sicherungsmaßnahme verfügt (Krypto-Block o.Ä.) Wie kann ich mittels eines kleinen FPGAs (mit integriertem Flash-Speicher) oder CPLDs das Anlaufen der SC-Funktion unterbinden ? Das kleinere FPGA wäre über ein paar Leitungen mit dem SC verbunden. Hat jemand soetwas schon mal gemacht ? Vielen Dank für eure Ideen Grüsse, Stefan
das geht ja, und man sollte wirlich einen flash-FPGA nehmen nicht flash mcu, weil rauslesen von geschutzten flash-mcu kostet in asien etwa 1000 eur fast egal welches flash-controller actel flash ist aber viel sicherer naturlich ist es moglich mit sicheren ic auch den schutz falsch machen.. Antti
@ Stefan Was willst du schützen? Den Bitstrom zum FPGA? Oder willst du einen Nachbau eines ganzen Gerätes verhindern?
@ Antti Verstehe nicht ganz, worauf du hinaus willst ? Fakt ist, wir benutzen Lattice-SC-FPGAs. @Lothar Der Bitstrom zum FPGA soll nicht geschützt werden, da das SC-FPGA ohne Umwege aus dem Config-Flashbaustein konfiguriert werden soll. Das zuätzliche kleinere flash-basierte FPGA soll im Prinzip (möglichst für den Angreifer in einer nicht nachvollziehbaren Art und Weise) die Funktion des SC-FPGAs aktivieren, oder mit anderen Worten: Ohne die Kenntnis des "Helfer"-Designs (im kleinen FPGA, CPLD) kann das SC-FPGA nicht verwendet werden. Grüsse, Stefan
anti-clone schutz a) SRAM FPGA ohne encryption + flasch MCU == 1000 EUR und ist gehackt b) SRAM FPGA ohne encryption + flasch FPGA/encrytpted (Actel) - SICHER b- man es doch auch falsch machen so das die sichre IC doch keine sicher bietet :( antti
Ich kann leider nicht ganz so viel zu deiner Frage schreiben, da ich so etwas noch nie selbst realisiert habe. Ich habe aber mal in einer Vorlesung was von "Challenge-Response-Authentifizierung" gehört -> gOOgle dürfte eine haufen Seiten ausspucken. Ich denke dass du mit diesem Verfahren dein Problem lösen kannst. Jedoch kann ich dir leider nichts über den Aufwand der Implementierung noch über die Sicherheit sagen.
Hallo Antti,
man muss aber nicht unbedingt ein Flash-FPGA von Actel verwenden ...
auch XP-FPGA von Lattice konfiguriert sich aus dem eigenen Flash.
>b) SRAM FPGA ohne encryption + flasch FPGA/encrytpted (Actel) - SICHER
Gibt es Application Notes hierzu ? Wird hier der Bitstream komplett
verschlüsselt ? Das ist ja nicht das, was ich wirklich möchte (siehe
antwort
an Lothar).
Grüsse,
stefan
es muss nicht actel sein, aber XP und XP2 sind immerhin noch SRAM FPGA egal das die intern flash haben, Actel ist von geburt her flash technologie, das macht das rauslesen sehr viel mehr komplizierter WIE, ja es muss challenge-response etwas sein und auch so das immer voll neue sequenzen verwendet werden, und dann musss es auch richtig mit dem design "gekoppelt" sein, weil das BITfile patching ist auch nicht so unmoglich wie man es denkt fur xilinx gibt es bit zu netlist decompilers und lattice is fast gleiche arhitecture dh ware auch nicht allzu schwer den bit file zu dekompilieren Antti PS kanns gerne privat email, addresse findest schon :)
Habt Ihr Buch-Quellen oder Application Notes mit einem konkreten Implementierungsansatz, um mein Haupt-FPGA-Design geschützt zu aktiveren bzw. zu deaktivieren ? Die FPGA-Journal-Beiträge sind i.d.R. sehr allgemein gehalten. Grüsse, Stefan
Für SRAM-FPGAs wäre zB. eine Art TPM möglich: www.xilinx.com/support/documentation/application_notes/xapp780.pdf Allerdings erfordert das auf FPGA-Seite auch einiges an Logik. Xilinx macht in der Appnote den SHA1-Hash und die one-wire-Kommunikation mit einer Picoblaze-CPU. Die hat aber den Nachteil, dass alles per SW gemacht wird und das Programm in einem Blockram steht. Und das ist wieder recht einfach auslesbar/manipulierbar. Besser ist es, das meiste in "echter" HW zu machen, kostet aber Arbeit... Ein Teil kann ruhig in einer CPU gemacht werden, solange es nur der ist, den man über Sniffing ohnehin mithören kann... Etwas hinderlich ist, dass es das Datenblatt vom DS2432 nur gegen NDA gibt. Auf einigen chinesischen Seiten wird der auch schon unter "gehackt" geführt, ob das stimmt, weiss ich nicht...
http://www.altera.com/support/refdesigns/sys-sol/indust_mil/ref-des-secur.html?GSA_pos=2&WT.oss_r=1&WT.oss=design%20security Cheers, Roger
Hallo Roger, danke für den interessanten Link. Wenn ich mir das genau anschaue, so frage ich mich, ob es für einen Angreifer nicht relativ einfach wäre, das (in der Skizee des Links rot markierte) Enable-Signal manuell auf High zu setzen ? Gerade ein Clock-Enable eines im Design oft verwendeten Taktes könnte relativ schnell ins Auge springen, oder ? Grüsse, Stefan
Den Bitstream zu verstehen um zu sehen wo und wie so ein Enable Signal verwendet wird, und es dann auch noch wegpatchen - ich wuerde sagen das gestaltet sich wohl als aeusserst schwierig. Jedoch nicht unmoeglich. Cheers, Roger
Hallo Roger, danke für deine Einschätzung. Handelt es sich bei dem Altera-RefDesign um propietäre Templates oder kann man die auch in Nicht-"A"-Bausteinen verwenden ? Grüsse, Stefan
Das Reference Design ist doch recht Altera lastig, zumal das meiste in AHDL geschrieben ist. Aber man kann sich davon inspirieren lassen und dann ein 3DES oder gleich AES core von http://www.opencores.org nehmen. Cheers, Roger
Hallo 123, in Zusammenhang mit Deinem Link habe ich folgendes Paper von Altera gefunden: http://www.altera.com/literature/wp/wp-01033.pdf @Roger Kannst Du mir sagen, ob dieses Referenzdesign ebenfalls AHDL-lastig ist ? Grüsse, Stefan
Stefan schrieb:
> Kannst Du mir sagen, ob dieses Referenzdesign ebenfalls AHDL-lastig ist
Kann ich leider nicht, da ich dieses design nicht habe.
Cheers, Roger
Gibt es zu dem MAXIM-Referenzdesign von Altera (SHA-Engine) ein Evalboard ? Grüsse, Stefan
Glaube nicht. Aber prinzipiell kannst du die Sache auch selber bauen. Ein CPLD müsste dann die Aufgabe des Dallas Chips übernehmen.
@ Stefan Hast du dir schon mal die Frage gestellt, wie hoch das Interesse ist, dein FPGA-Design zu knacken. Lohnt sich das, oder ist es einfacher, zu messen, was hineingeht, was herauskommt und das "Dazwischen" dann nachzubilden? Interessanter dürfte doch sein, ob jemand deine Hardware nachbaut und einfach deinen Bitstrom verwendet. Das kann jeder bessere Bastler, davor müsstest du dich schützen. Xilinx hat auch eine Appnote, wo ein SHA-1-Wire Baustein an einen PicoBlaze angekoppelt wird, und daraus ein Good/Bad-Signal erzeugt wird. Wenn du dann noch zeitlich versetzt zur Abfrage eine Fehlfunktion auslöst, kommt keiner mehr dahinter, was da passiert ist...
Hallo Lothar, die von dir beschriebene App. Note ist das gleiche in Grün wie das was Stefan bei Altera ausgebraben hat. Einfache Freund-Feind Detektion zur Verhinderung des Bitstream Kopierens.
> Einfache Freund-Feind Detektion zur Verhinderung des Bitstream Kopierens. Richtig. Meine Frage war ja, ob das nicht ausreicht... Wenn der SHA-Baustein nicht da ist, wird die sinnvolle Funktion des FPGAs eingestellt. Besser, weil verwirrender: es läuft fast korrekt weiter, aber ab und an passieren irgendwelche seltsamen Fehler...
Hallo Sören,
>Aber prinzipiell kannst du die Sache auch selber bauen.
Verständnisfrage: Wenn ich nicht weiss, wie das Design im MAXIM
im Einzelnen aussieht, und wenn das Altera-Referenzdesign genau auf
dieses MAXIM-Design abgestimmt ist,
wie kann ich dann ohne weitere Kenntnisse das MAXIM-Design nachbauen, so
dass das Altera-Referenzdesign immer noch lauffähig ist ?
Oder hat der MAXIM-Baustein die gleichen Innereien wie das
Altera-Referenzdesign ?
Grüsse,
Stefan
Im Prinzip ist es symmetrisch, du müsstest also nur die FPGA-Logik zweimal bauen. Die Idee basiert einfach auf dem Hash-Prinzip. Der Maxim verwurstet 16 32-Bit-Worte (512Bit) per SHA1 zu einem 160Bit-Hash. Der Inhalt der 16 Worte setzt sich u.a. aus der Seriennummer, einem "geheimen" einprogrammierten Schlüssel und einer "Challenge" zusammen. Die werden dem Chip vom FPGA aus geschickt. Die Challenge ist dabei irgendein Zufallswert. Der Hashwert (Digest) wird wieder ausgelesen und *im FPGA* mit einem auf dieselbe Weise berechneten Digest verglichen. Ist es identisch, war der Schlüssel identisch und nur um den gehts. Das ganze System lebt aber von ein paar Vorraussetzungen: - Der Schlüsselwert ist im FPGA irgendwo in der Logik begraben (vorgeladenes RAM ist KO), im Maxim (hoffentlich) nicht auslesbar. - Die Zufallszahl der Challenge muss wirklich zufällig sein. Das führt meistens zu recht seltsamen Schaltungen, die die Metastabilität ausnutzen... - Der Ablauf des SHA1 auf beiden Seiten darf nicht tracebar oder manipulierbar sein, beim DS* nimmt man das mal an... Aber es hilft ja nix, wenn das FPGA ein Fake-Digest injiziert bekommen kann, und damit zu allem Ja und Amen sagt. - Der letzte Punkt bedeutet eigentlich, dass zB. die Lösung von Xilinx fürn A... ist, weil der Picoblaze aus einem Blockram läuft, und das ganz einfach manipulierbar ist. D.h. der SHA1 muss eigentlich in echter HW ablaufen. Das geht schon, ist aber etwas Gefummel. Was zB. dagegen völlig harmlos ist, ist das Auslesen der DS-Seriennummer in SW und die Übermittlung an die SHA1-HW. Das kann man durch Sniffing ohnehin mitbekommen, also ist es egal, wie sich man das macht. Solange der Default-Zustand der Erkennung "Feind" ist ;-) Man sollte sich also schon gut überlegen, was man wie macht und welche Ansprüche man so an den Cloneschutz hat. Ein Loch an der falschen Stelle und der ganze Aufwand war umsonst...
> Das ganze System lebt aber von ein paar Vorraussetzungen:
Eine andere Vorraussetzung an diesen Systemen ist, dass das Bit-File
nicht manipulierbar ist.
Diese Annahme stimmt nur insoweit, dass man aus einem Bit-File nur unter
größten Mühen eine HDL-Beschreibung bekommt.
Aber für einen Angriff auf diese Systeme braucht man das nicht. Es
reicht, wenn man z.B. im Bit-File ein Bit findet, dass den Output des
internen Zufallsgenerators auf einen festen Wert legt. Oder die Eingänge
des Vergleichers, oder, oder, oder.
Das schöne daran: Man kann diese Suche automatisieren und auch
parallelisieren. Und die Hardware dafür ist auch billig, nämlich das
Ziel-FPGA.
es gibt BIT to NETLIST converter fur xilinx dh ist gar nicht so grosser aufwand.. Antti
Naja, dann hat man den ganzen Logikwust ohne jegliche Annotationen. Da müsste man erstmal den Teil finden, der den Digest-Vergleich macht oder dann die Sperre einschaltet. Ginge bei einem XC3042 sicherlich (nur passt da kaum ein SHA1 rein), aber bei allem, was über 200kGates und tausenden FFs liegt, ist das sicherlich etwas haarig. Zum Reverse-Engineeren eine bestimmten "supertollen" und geheimen Eigenschaft des FPGAs ist das sicherlich noch hilfreich/denkbar, aber nur fürs Clonen alleine ist das IMO zuviel Aufwand. Wenn es länger dauert, das Ding zu clonen, als selbst from-scratch zu entwickeln, ist was faul am Geschäftsmodell ;)
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.