Welche Konfiguration sollte ich für ein System verwenden, das einen ARM und ein FPGA enthält?

Ich habe ein Design, das ein Altera Cyclone FPGA verwendet, um eine Physically Unclonable Function (PUF) zu implementieren, und ein ARM-Gerät, um kryptografische Arbeit und I/O mit der PUF zu erledigen. Die PUF ist sehr groß und nimmt ziemlich viel Platz ein (nur etwa 1/4 passt auf den Cyclone)

Meine Frage ist, wäre ich am besten bedient, wenn ich ein FPGA bekomme, das groß genug ist, um sowohl den PUF- als auch den ARM-Kern aufzunehmen, oder ein kleineres FPGA für das PUF und einen zweiten, externen ARM-Chip? Können Sie einige Vorschläge machen?

Wenn ich zwei Chips verwenden würde, würden sie mit SPI kommunizieren. Es gibt nicht viel Kommunikation zwischen den beiden, und es muss auch nicht schnell gehen.

Antworten (4)

Ich kann Ihre spezifische Anwendung nicht kommentieren (da ich kein Kryptographie-Experte bin), aber das Platzieren eines Prozessors an Bord mit einem FPGA ist eine äußerst übliche Sache. Der Grund dafür ist hauptsächlich, dass Sie jetzt FPGA-Speicherplatz freigeben, um das zu tun, was FPGA gut kann, während Sie den weniger teuren separaten Prozessor verwenden, um das zu tun, was es gut kann, vielleicht sogar schneller als dies mit einer im FPGA laufenden Soft-CPU möglich wäre. Außerdem können größere FPGAs ziemlich teuer werden, verglichen mit schnelleren ARMs, die ziemlich preisgünstig sein können.

Grundsätzlich denke ich, dass Sie die beiden Chips verwenden sollten, aber es ist schwierig, eine sichere Aussage zu treffen, ohne Details über Ihren spezifischen Bereich zu kennen.

Ich denke, die richtige Antwort von zwei Chips vs. großem FPGA wird darauf hinauslaufen, welcher Art von Angriffen das Gerät ausgesetzt sein wird. Das bedeutet, dass Sie etwas über Ihre möglichen Angriffsszenarien und Sicherheitsanforderungen wissen müssen.

Was schadet es, wenn der Angreifer diese SPI-Kommunikation untersucht? Bekommt er Schlüssel? Klartext? Zwischenstufen des Verschlüsselungsprozesses? Wenn der Angreifer diese Sonde in Klartext umwandeln kann, was schadet das? Illegaler Zugriff auf einen Pay-Satelliten-TV-Kanal? Finanzdaten? Militärische Geheimnisse? Das ist das Wichtigste, was man verstehen muss. Es informiert alle Ihre anderen Fragen (denn natürlich, je sensibler die Daten sind, desto mehr lohnt es sich, sie zu schützen).

Befindet sich das Gerät an einem Ort, an dem der Angreifer unerkannt herumspielen kann?

Handelt es sich beispielsweise um ein Sicherheitssystem in einem Blu-ray-Player, muss man davon ausgehen, dass der Angreifer das Ding irgendwann im laufenden Betrieb öffnet. Wenn es sich andererseits um ein militärisches Kommunikationssystem handelt, das nur vom Präsidenten der Vereinigten Staaten verwendet wird, kann man davon ausgehen, dass der Angreifer keine Zeit mit dem Gerät verbringen wird.

Wie motiviert ist der Angreifer? Über welche Ressourcen verfügt der Angreifer wahrscheinlich?

Dürfen Sie das Ding in einer speziellen Box versiegeln, die das Board zerstören kann, wenn sie verletzt wird?

Sie brauchen ein gutes Profil dessen, womit Sie es zu tun haben, um diese Entscheidung zu treffen.

hängt von der Größe/Komplexität des ARM-Kerns und des benötigten FPGAs ab.

Die einzigen technischen Bedenken sind der Stromverbrauch (das einzelne große FPGA ist wahrscheinlich höher) und die Datenintegrität auf der SPI-Leitung. Das heißt, kann die Sicherheit Ihres Systems durch jemanden gefährdet werden, der die auf der SPI-Leitung gesendeten Daten ausspioniert?

Ansonsten ist der Preis das Problem. Vergessen Sie bei den Preisunterschieden nicht, Platz für die Leiterplatte und die erforderlichen externen Komponenten für jeden IC einzuplanen.

Für die erste Version habe ich es mit einem ARM7TDMI-S-Prozessor fertiggestellt. Sie haben die Integrität der SPI-Leitung erwähnt, das ist tatsächlich wichtig. Welche Möglichkeiten habe ich, die Übertragung zu sichern? (Das könnte jedoch für eine ganz eigene Frage sein)
Nun, ich glaube nicht, dass es etwas gibt, das perfekt ist, um die Leute von diesen Spuren fernzuhalten. Wenn die Daten auf der Leitung nicht verschlüsselt sind, wird Ihr SOL. Sie können BGA-Chippakete verwenden und die Signalspuren auf internen Schichten in der Leiterplatte ausführen. Das würde zumindest diejenigen ohne wirkliche Motivation fernhalten. Aber wenn einer der ICs sie nicht intern hat, benötigt SPI Pull-up-Widerstände, damit das Signal immer noch über die Oberfläche zugänglich ist.
+1 für den BGA-Intern-Layer-Trace-Vorschlag, außer dass SPI meines Wissens keine Pull-up-Widerstände benötigt, da SPI Punkt-zu-Punkt-Daisy-Chain anstelle einer gemeinsamen Bustopologie ist.
Ich hätte nicht "brauchen" sagen sollen, sondern "häufig erfordern". SPI kann ein gemeinsam genutzter Bus sein, dafür sind Chip-Select-Leitungen da. Das hat nichts mit dem Vorhandensein von Pull-up-Widerständen zu tun. Die Notwendigkeit von Pull-up-Widerständen hängt von der Art der I/O-Pins am Mikrocontroller (oder anderen Geräten am Bus) ab. Wenn sie Open-Collector sind, auch bekannt als Open-Drain in Mosfets, haben sie möglicherweise sehr schwache Pull-ups (~ 100 kOhm), der Bus funktioniert nicht bei höheren Geschwindigkeiten, sodass ein externer Pull-up mit geringerem Widerstand erforderlich ist. Sie können auch überhaupt keinen Pull-Up haben, in diesem Fall sind sie nicht in der Lage, die Leine hoch zu fahren.

Vom praktischen Designstandpunkt aus sind die separaten Chips eine gute Idee. Sicherheitsbedenken würden jedoch entweder eine verschlüsselte Kommunikation auf dem Bus, sorgfältige Maßnahmen, um sicherzustellen, dass keine wichtigen Daten über den Bus gehen, oder die Verwendung eines einzelnen monolithischen Chips erfordern.

Es gibt auch andere Probleme. FPGAs werden normalerweise aus dem Flash-Speicher programmiert (außer in einigen seltenen Fällen, in denen Dinge wie Anti-Fuses verwendet werden). Sie müssen auch befürchten, dass die Anwendung während der Konfiguration abgehört wird.

Auch nach der Konfiguration verfügen viele FPGAs und andere Mikrocontroller über JTAG-Pins, die verwendet werden können, um das Programm wieder aus dem Gerät auszulesen oder andere Aspekte der Programmierung zu inspizieren!