Hallo! Ich setze für ein neues Projekt einen FPGA (Cyclone EP1C6) ein. Funktioniert soweit auch alles sehr gut. Da die Daten aber in einem externen Speicher abgelegt werden (bei mir ein EPCS1SI8), frage ich mich, wie es mit dem Schutz der Schaltung gegen Nachbauer aussieht? Ein zuvor zusätzlich eingeplanter CPLD soll nun wegfallen, dieser hätte die Schaltung sonst sicher gegen Nachbauten geschützt. Potentielle Nachbauer könnten doch sicher den externen Speicher des FPGA auslesen, die Schaltung durchklingeln und nachbauen und das ausgelesene Programm auf den Nachbau programmieren. Gibt es da noch eine Schutzmöglichkeit? Können eventuell auch Daten in das FPGA direkt gebrannt werden (ev. eine Seriennummer oder ähnliches), die dann nicht direkt auslesbar ist? Wäre toll, wenn mir jemand zum Thema Softwareschutz bei externem FPGA ConfMem etwas sagen könnte! Danke! Grüße André
fast keine moeglichkeiten. das einzige was ein bishen hilft is ein externes 'secure microcontroller' der nach dem FPGA config dann "tricks" macht : sehr viel bullshit ein und rausshiebt und dann vershclusselte sachen reinpackt was wiederum irgendwie in FPGA gepruft wird. das ganze datenstrom muss aber nicht repeating und voll als random aussehen. Antti
>Ein zuvor zusätzlich eingeplanter CPLD soll nun wegfallen, dieser >hätte die Schaltung sonst sicher gegen Nachbauten geschützt. Wie das? Wenn der CPLD irgendwann den FPGA konfiguriert, dann kann man genauso mithören und die Daten wieder aufzeichnen. Sicherheit gibt es meines Wissens nur, wenn eine Decryption-Engine im FPGA eingebaut ist, oder wenn der FPGA Flash-basierend ist. Das letztere scheint jetzt erst im Kommen zu sein, aber das ist nur eine Frage der Zeit bis es nur noch solche gibt :-)
Ist vermutlich ein Grund mit einem verifizierten design einen ASIC Produzenten zu beauftragen.
...mir fällt da auch keine Lösung welche auf "verschlüsselung" oder externen Bauteilen basiert. Schließlich kann die Schaltung immer durchgeklingelt und der Datenstrom ausgelesen werden (auch wenn es mit einem hohen aufwand verbunden ist und es für einen Entwickler keine freude bereiten kann). Eine Lösung wäre, einen BGA Typ als FPGA einzusetzen (=> Durchklingeln unmöglich) oder um das Durchklingeln zu erschweren eine Mulitlayer Platine
@Bustle Hast du mal ne BGA-Platine von unten gesehen ? Die, die ich gesehen habe, haben unter jedem ball ein via. Damit kann man sowas ziemlich einfach hacken. Und selbst wenn das nicht so waehre, muesste man nur die herausgefuehrten Leiterbahnen fuer das config interface finden und mitlesen.
@Daz nene, so leicht ist das nicht mehr. Angenommen der BGA ist auf der Top-Side, so können die Leiterbahnen auf dieser Seite nicht nur einer Region von "Pins" zugeteilt werden. Auch Vias auf der Botton-Side können können nur einer Region zugeordnet werden. => also "unmöglich" die Pinbelegung herauszufinden (da wäre der Aufwand einer Neuentwicklung geringer). (Ich gehe momentan von einer parallel Programmierung aus). Auch die Zuordnung der Daten zum Datenpin ist dann nicht mehr nachvollziehbar. Natürlich die non-plus-ultra Lösung. Wäre ein BGA FPGA im Multilayer-Design (parallel Programmierung) => ah genau noch eine Lösung, die Platine anschließend vergießen (oder so :-))
Andre, ich hab bei Altera gerade gelesen, dass man Stratix FPGA Designs leicht in den hauseigenen HardCopy ASIC ueberfuehren kann. Wenn du nicht auf Xilinx festgelegt bist, koennte das vielleicht eine Option sein.
@Bustle: Das versteh ich nicht ganz was du meinst. Schließlich verwendet man doch FPGAs, deren Pinbelegung nicht geheim ist. Man braucht dann nur entsprechende Signale auf der Bottom-Seite der Platine abgreifen, da die Vias der BGAs sowiso komplett durch die Platine gehen.
Bustle, viel einfacher kommt man an das config memory. Ist ja auch ein externer Baustein und wohl kaum ein BGA. Wieauchimmer, zur Not kann man beides mit dem Heissluftfoehn abziehen, in ein debug System einsetzen und an alle Daten herankommen.
Hi, schaut doch mal in das Xilinx Application Note 780. Ich denke, dass es auf die gleiche Art und Weise auch mit nem CPLD gegangen wäre. Somit ist es prinzipiell schon möglich das Design gegen cloning zu schützen - allerdings braucht man doch jedes mal einen externen chip (ob cpld oder dieser ds2432). Gruß, Thomas
...das wird wahrscheinlich die beste Lösungen sein. (siehe Breti, mal beim Hersteller nachfragen) Schließlich müssen die sich mal über sowas Gedanken gemacht haben und bestrebt sein dir in diesem Punkt zu helfen.
Hallo erstmal ;) Gleich zu Anfang: ich habe zwar in meinem Studium mit FPGAs "spielen" müssen, komme aber eher aus der µC / Informatik-Schiene ! Also wenn ich hier absoluten Müll ablasse, nicht böse sein ;) Soweit ich mich noch erinnern kann sind in FPGAs auch ROMs einarbeitbar/darstellbar, soweit korrekt ? Also warum nicht im FPGA einen Bereich definieren, der einen internen Key darstellt und gleich noch eine passende Decodierlogik dazu ? Es würde ja reichen einen 8bit Wert mittels mehrfachen XOR über die zu lesenden/schreibenden Datenwörter laufen zu lassen, um ein direktes auslesen des Programms aus dem externen Speicher zu verhindern. Diese Schaltung müsste fest in den FPGA gebrannt sein und direkt hinter dem Bootloader oder wie es sich hier nennt liegen. Mit "durchklingeln" ist wohl ein Testlauf gemeint der die interne Verschaltung des FPGA aufzeigt ? Da ich nicht genau weiß, wie das gemacht wird kann ich nur mutmaßen. Also, wenn es eine Signalverfolgung ist, wäre es möglich durch sogenanntes Wormholerouting (wer Transputer kennt und die C004 Linkswitches wird wissen was ich meine) nur eine bestimmte Signalfolge in einen bestimmten Bereich des FPGAs zu leiten und alles andere einfach drum herum. Die Idee dahinter ist einfach die, das ein "Durchklingler" ja nicht die vollständigen Spezifikationen hat, oder Irre ich hier ? Ist nur eine Idee ;) Markus
Dann brauchst Du aber einen beschreibbaren, nichtfluechtigen und nicht
auslesbaren bereich im fpga fuer den key.
Die Xilinx Spartans haben sowas nicht. Bei den Virtexen gibt es welche,
die was aehnliches eingebaut. Die Konfigurationsdaten liegen dabei
kodiert im flash und werden beim laden automatisch von einer speziellen
"dekodierengine" im virtex entschluesselt.
Gruss,
Thomas
>Diese Schaltung müsste fest in den FPGA gebrannt sein und direkt >hinter dem Bootloader oder wie es sich hier nennt liegen. Und genau das "fest einbrennen" geht eben bei dem genannten Cyclone-FPGA nicht. Es ist SRAM-basiert, und muss von aussen die Konfigurationsdaten bekommen. Wenn man einen FLASH-basierten FPGA benutzt (von Actel), hat man diese Probleme nicht.
OK, wie gesagt ist es lange her ;) Ich weiß nicht welcher Typ das war, aber man konnte ohne große Probleme eine Logik fest verdrahten, indem Fuses gesetzt wurden. Wenn natürlich alles immer dynamisch eingeladen wird funktioniert das nicht. Nur Frage ich mich dann, wie das Problem mit einem zweiten FPGA des gleichen Typs gelöst war, der müßte doch auch erstmal von außen programmiert werden ? Nochmal nachgelesen, also ist der CPLD mit Flash bzw. Fuses ausgestattet und der Cyclone hat nur SRAM ? Dann bleibt wirklich nichts anderes übrig als einen weiteren Baustein dazwischen zu schalten. Sorry mein Fehler, Markus
[quote]Dann bleibt wirklich nichts anderes übrig als einen weiteren
Baustein dazwischen zu schalten.[/quote]
Das nützt auch nichts, da aus diesem dann ja wieder die entschlüsselten
daten herauskommen und zum fpga gehen. dort könnte man sie abfangen und
auslesen.
Gruß,
Thomas
Stratix II FPGAs unterstuetzen verschluesselte Konfigurationsdaten. Im FPGA wird der Key fest gespeichert. Der externe Konfigurationsspeicher enthaelt die mit AES verschluesselten Daten. Siehe: http://www.altera.com/products/devices/stratix2/features/security/st2-security.html
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.