Guten Abend, seit Virtix 2 gibt es Side-Channel-Attacken, die über Strommessungen oder EM-Messungen (sogar ohne Modifikationen am Board [1]) die AES-Keys für die Bitstream-Encryption aus den FPGAs herauskitzeln können. Heißt es, man kann jegliche Sicherheits-kritischen Applikationen mit allen Xilinx-FPGAs (Serien 5, 6, 7 und ich glaube außer der Ultrascale-Familie) ausschließen? Das wäre ein ziemlicher Downer ... Wieso hat Xilinx diesbezüglich nichts unternommen? Schneidet da Altera besser ab? Viele Grüße, Mampf [1]: https://eprint.iacr.org/2016/249.pdf
Mampf F. schrieb: > Heißt es, man kann jegliche Sicherheits-kritischen Applikationen mit > allen Xilinx-FPGAs (Serien 5, 6, 7 und ich glaube außer der > Ultrascale-Familie) ausschließen? Warum? Bitstream-Encryption ist dazu gedacht, daß eine Konfiguration nur auf dem Device läuft, für das es gedacht (und z.B. lizensiert) ist. Wenn die (Hardware-) AES-Ver- (bzw. Ent-) Schlüsselung für Bitstream-Encryption geknackt ist, heißt das längst nicht, daß alle kryptographischen Operationen auf dem Device abgegriffen werden können, sondern lediglich, daß deine IP nicht mehr geschützt ist, weil man den Bitstream (mit viel Aufwand) eben doch mitlesen kann. Vielleicht bin ich ja naiv, aber m.E. ist der nicht mehr gewährleistete IP-Schutz (und nur um den geht es hier) kein Grund, sicherheitskritische Anwendungen auszuschließen?
Markus F. schrieb: > Bitstream-Encryption ist dazu gedacht, daß eine Konfiguration nur auf > dem Device läuft, für das es gedacht (und z.B. lizensiert) ist. Ein moegliches Szenario, aber genauso gut moechte man das Reverse-Engineering unterbinden. Aus dem Bitstream lassen sich halt doch jede Menge Informationen rauskitzeln. Einfach mal nach "xilinx bitfile reverse engineering" suchen, selbst vom CCC gibts da etwas.
Wo ist jetzt das Problem? Mit genug Aufwand kriegt man jede Verschlüsselung geknackt, spätestens über gezielte Angriffe auf die zugrundeliegende Hardware. Das sollte nicht überraschen. Die Hersteller nehmen sich da alle nix.
S. R. schrieb: > Mit genug Aufwand kriegt man jede Verschlüsselung geknackt, spätestens > über gezielte Angriffe auf die zugrundeliegende Hardware. Das sind 3€ fuers Phrasenschwein. ;-) Natuerlich bekommt man frueher oder spaeter jede Verschluesselung geknackt (wobei knacken hier das falsche Wort ist, besser waere den Schluessel erraten). Aber bei AES mit einem 256 bit Schluessel sitzt man doch eine Weile dran, so dass es zu Lebzeiten des Angreifers keine Chance zur Entschluesselung gibt. Bisher ist auch nichts bekannt, dass AES gebrochen waere. Von daher ist das durchaus eine wirkungsvolle Methode sein Bitfile zu schuetzen.
Um das Phrasenschwein nochmals zu befüttern: Kryptographie löst keine Probleme, sie transformiert nur jedes Problem in ein Schlüsselaustauschproblem. Tobias B. schrieb: > Bisher ist auch nichts bekannt, dass AES gebrochen waere. Man muss AES nicht brechen, um die real existierenden Implementationen zu brechen. Das kann über Sidechannel-Angriffe gehen, über soziale Angriffe oder andere Möglichkeiten. Spielt keine Rolle. Tobias B. schrieb: > Von daher ist das durchaus eine wirkungsvolle Methode > sein Bitfile zu schuetzen. Wenn man das unbedingt müssen will, ja. Es dürfte besser sein als alles, was man selber hingezaubert bekommt. Aber wer glaubt, dass das irgendwie vollständig sicher sei, liegt sicher falsch - wie die Angriffe zeigen. Und die Frage "sind die anderen besser?" ist in dem Zusammenhang eher unsinnig.
Tobias B. schrieb: > aber genauso gut moechte man das > Reverse-Engineering unterbinden Das hat dann aber mit "Ausschluß sicherheitskritischer Applikationen" (wie im 1. Post angedeutet) nichts mehr zu tun. "security by obscurity" funktioniert längst nicht mehr. Die Keys konnten "erschnüffelt" (bzw. ein brute force Angriff wesentlich erleichtert) werden, indem die Leistungsaufnahme des Chips während des Ladens des verschlüsselten Bitfiles gemessen wurde (so jedenfalls habe ich das verstanden). Das ist m.E. nur möglich, wenn der Chip solange nichts anderes tut. Mit einer realen Anwendung "überlagert" dürfte da nichts mehr zu machen sein.
Mampf F. schrieb: > Das wäre ein ziemlicher Downer ... Wieso hat Xilinx diesbezüglich nichts > unternommen? > > Schneidet da Altera besser ab? Actel/Microsemi hat da was unternommen. Die Frage ist, wieviel unternommen werden soll... Das weitere Reverse-Engineering des dann ausgelesenen Netzlisten-Zoos ist deutlich viel aufwendiger als das Auslesen eines Key aus dem Chip (was mit mehr mechanischem Aufwand verbunden ist, und eben gerade bei Actel nicht so einfach geht). Wenn sich allerdings im zurückgelesenen IP sich der für alle Kommunikation mit dieser Art Gerät offenbart, tja. Markus F. schrieb: > "security by obscurity" funktioniert längst nicht mehr. Sie funktioniert manchmal auch besser, als wenn die Spezialisten schon wissen, wonach sie suchen müssen, dank einer "untergejubelten" Wassermarke..
Markus F. schrieb: > Das ist m.E. nur möglich, wenn der Chip solange nichts anderes tut. Was ziemlich sicher der Fall ist, denn während er den Bitstream lädt, weiß er noch nicht, was er tun soll. Und zufällig an den Pins wackeln ist wahrscheinlich keine gute Idee.
S. R. schrieb: > Markus F. schrieb: >> Das ist m.E. nur möglich, wenn der Chip solange nichts anderes tut. > > Was ziemlich sicher der Fall ist, denn während er den Bitstream lädt, > weiß er noch nicht, was er tun soll. Und zufällig an den Pins wackeln > ist wahrscheinlich keine gute Idee. Natürlich. Was ich meinte war, daß das Erschnüffeln von Keys bei einer "sicherheitskritischen Anwendung" (wie vom TO im ersten Post impliziert) mit der Vorgehensweise nicht mehr möglich sein dürfte, weil da eben höchstwahrscheinlich zeitgleich noch etwas anderes passiert.
Markus F. schrieb: > weil da eben höchstwahrscheinlich zeitgleich noch etwas anderes passiert. Warum muß man immer was gut verschlüsseltes knacken, wenn es irgendwo schön im Speicher liegt? Eine messerscharfe Frage ist immer, "wo einer den Hebel ansetzt".
So, was ist denn das Angriffsszenario? Mit genügend Geld und Zeit bekommt man alles auf, also um was geht es? Wo kann der Angreifer den Strom messen? Kann der Angreifer die Hardware modifizierten, also Kondensatoren weglöten?
Strubi schrieb: > Actel/Microsemi hat da was unternommen. Die Frage ist, wieviel > unternommen werden soll... > Das weitere Reverse-Engineering des dann ausgelesenen Netzlisten-Zoos > ist deutlich viel aufwendiger als das Auslesen eines Key aus dem Chip > (was mit mehr mechanischem Aufwand verbunden ist, und eben gerade bei > Actel nicht so einfach geht). Konkreter Fall ist, dass in einem meiner FPGAs ein Cortex M1 läuft und im ROM, das eigentlich durch die bitstream-encryption geschützt sein sollte, ein Private Key für ein externes Secure-Element liegt. Das PDF, das ich im ersten Post verlinkt hatte, schreibt was von ca. 1,5 Tage, die es dauert, über EM-Messung den AES-Key zu bekommen - und das ohne Modifikationen am FPGA-Board. Nur mittels EM-Sonde. Die Frage ist jetzt natürlich, ob das, was dort geschützt werden soll, den Aufwand rechtfertigt. Und wie einfach in der Praxis der Angriff durchgeführt werden kann. Also inwieweit das schon automatisiert wurde. Wenn man nur eine 20EUR Sonde auf das FPGA kleben und ein Programm starten muss, das völlig selbständig nach 1,5 Tagen den AES-Key ausspuckt, wäre das ziemlich übel. Ich hatte auch darüber nachgedacht, den AES-Key in eine AXI-Peripherie auszulagern, da die Bitstreams noch nicht reverse-Engineered wurden. Aber das bringt auch keine Sicherheit, da man den entschlüsselten Bitstream dann einfach in ein FPGA ohne aktivierte Encryption laden kann. Man kann das ROM dann auch noch easy auswechseln und würde dann über manipulierte Software auf den AES-Key zugreifen können. Was denkt ihr darüber?
:
Bearbeitet durch User
Wenn du deinen private key als Konstante im Design hast, wird der durch Verschaltung von interconnect Ressourcen im FPGA "gespeichert". Die Bits für die Schaltstellen sind "irgendwo" im Bitstream und wahrscheinlich auch bei jedem Durchlauf woanders. Beim BRAM wäre das anders. Aber auch da ist meines Wissens das Reverse Engineering des Bitstreams recht aufwendig. Wenn du etwas mehr Sicherheit haben willst, lagere den Key in ein VHDL Modul aus. Dann kann man ihn auch wenn man die Bitstream Verschlüsselung hackt, nicht ohne irren Aufwand extrahieren... Und das Rom tauschen? Naja da müsste man ja immer noch erst mal wissen wie der M1 den Key aus dem Design holt...
:
Bearbeitet durch User
Mampf F. schrieb: > Was denkt ihr darüber? Dass ein Angreifer neben der Hardware auch hinreichend großes Wissen benötigt, um den Angriff erfolgreich auszuführen. Ergo: Ist sehr teuer. Ich bezweifle, dass dein schützenswertes Element so sehr schützenswert ist.
Christian R. schrieb: > Wenn du deinen private key als Konstante im Design hast, wird der > durch > Verschaltung von interconnect Ressourcen im FPGA "gespeichert". Die Bits > für die Schaltstellen sind "irgendwo" im Bitstream und wahrscheinlich > auch bei jedem Durchlauf woanders. Jup, richtig, das war meine Überlegung. > Beim BRAM wäre das anders. Aber auch > da ist meines Wissens das Reverse Engineering des Bitstreams recht > aufwendig. Wenn du etwas mehr Sicherheit haben willst, lagere den Key in > ein VHDL Modul aus. Dann kann man ihn auch wenn man die Bitstream > Verschlüsselung hackt, nicht ohne irren Aufwand extrahieren... > Und das Rom tauschen? Naja da müsste man ja immer noch erst mal wissen > wie der M1 den Key aus dem Design holt... Nein, das ist leider nicht so. Die M1-Software ist open-source. Es wäre daher ziemlich einfach, einen angepassten Source-Code zu kompilieren, der zB per UART den Private Key nach außen sendet. Dann braucht man den bitstream nicht reverse engineeren. S. R. schrieb: > Mampf F. schrieb: >> Was denkt ihr darüber? > > Dass ein Angreifer neben der Hardware auch hinreichend großes Wissen > benötigt, um den Angriff erfolgreich auszuführen. Ergo: Ist sehr teuer. Ja, das ist die große Frage ... Glaub ich werde die Autoren des Papers mal anschreiben und sie fragen, wie hoch der finanzielle Aufwand ist und wie schwierig es ist, die Attacken durchzuführen. > Ich bezweifle, dass dein schützenswertes Element so sehr schützenswert > ist. Ja, im Prinzip gebe ich dir recht. Allerdings kann man von "sicher" nicht mehr wirklich sprechen und das könnte mögliche Anwendungen einschränken.
:
Bearbeitet durch User
Ja klar ist das recht einfach, kuckt euch z.B. mal https://www.emsec.ruhr-uni-bochum.de/research/publications/BiFI/ an. Klar gibt es da große Probleme, du musst schon schauen "wie" sicher du arbeiten willst. Nur den AES Key zu leaken ist mit sowas recht einfach, der Ansatz erfordert nicht unglaublich viel Wissen und nur recht wenig Zeit.
Mampf F. schrieb: > Nein, das ist leider nicht so. > > Die M1-Software ist open-source. Es wäre daher ziemlich einfach, einen > angepassten Source-Code zu kompilieren, der zB per UART den Private Key > nach außen sendet. Hm, jetzt rein praktisch betrachtet ist der Aufwand ja trotzdem beachtlich. Nachdem man über 200.000 Boot-Zyklen den Bitstream AES Key erraten hat, hat man den Bitstream. OK. Dann muss man noch den ROM inhalt extrahieren, was per Reverse Engineering zwar eventuell möglich aber doch aufwendig ist, denn je nach Breite und Tiefe der BRAM Einheiten würfelt ja Xilinx die Stücken optimiert zusammen. Da müsste man erst mal genau wissen, wo welcher Teil drin steht. Dann tauscht man das ROM komplett aus. OK, aber dazu muss man ja die sythetisierte Peripherie und deren Adressen kennen, incl. deiner AXI Komponente, die deinen Key liefert. Dann könnte man rein theoretisch dieses Minimalsystem nachbauen und deinen Key auslesen. Sicher, möglich, aber ist dein Key den Aufwand wert? Das geht ja insgesamt dann schon in Richtung NSA/FSB Techniken. > Dann braucht man den bitstream nicht reverse engineeren. Ist das überhaupt schon gemacht worden? Ich bin da nicht auf dem neuesten Stand.
HSM-Modulhersteller machen schlicht ein Gehäuse drum, "Deckel auf" löscht den Key per Schalter. Oder Module werden so vergossen, daß man ohne physische Zerstörung nicht dran kommt.
Man kann viel machen. JTAG Fuse durchbrennen, FPGA und Flash im BGA Gehäuse verwenden und mit Underfiller nicht (zerstörungsfrei) lösbar mit der Platine verbinden. Aber wie bei jeder "Sicherheit": Wenn einer unbedingt rein will, schafft er das auch.
Beitrag #5870806 wurde vom Autor gelöscht.
Christian R. schrieb: > Dann muss man noch den ROM > inhalt extrahieren, was per Reverse Engineering zwar eventuell möglich > aber doch aufwendig ist, denn je nach Breite und Tiefe der BRAM > Einheiten würfelt ja Xilinx die Stücken optimiert zusammen. Das glaube ich, ist gar nicht so schwierig. Es gibt von ARM ein paar Scripte, die den ROM-Inhalt direkt im Bitstream auswechseln können. Funktioniert nur mit unverschlüsselten Bitstreams, aber wenn der mal entschlüsselt ist, würde es wahrscheinlich gehen. Per TCL-Skripte kann man aus dem Design extrahieren, wo die BRAMs sind und mit dieser map, kann man das ROM ersetzen. Dann kann man den entschlüsselten Bitstream vermutlich in ein FPGA laden, das keine eFUSEs gesetzt hat.
:
Bearbeitet durch User
Christian R. schrieb: >> Dann braucht man den bitstream nicht reverse engineeren. > > Ist das überhaupt schon gemacht worden? Ich bin da nicht auf dem > neuesten Stand. https://github.com/SymbiFlow/prjxray
Mampf F. schrieb: > Per TCL-Skripte kann > man aus dem Design extrahieren, wo die BRAMs sind und mit dieser map, > kann man das ROM ersetzen. Eventuell würde sich je nach Version des Synthese-Tools, Settings oder kleinen Anpassungen am Design die Lage der BRAMs ändern, weshalb es vlt doch nicht ganz einfach ist ... aber evtl könnte man im bitstream dann die ROM-Teile zusammensuchen, wenn man das original-Binary hätte. Wenn der Source mit der gleichen Toolchain kompiliert wurde, könnte das schon klappen.
:
Bearbeitet durch User
Mampf F. schrieb: >> Ich bezweifle, dass dein schützenswertes Element >> so sehr schützenswert ist. > > Ja, im Prinzip gebe ich dir recht. Allerdings kann man von > "sicher" nicht mehr wirklich sprechen und das könnte mögliche > Anwendungen einschränken. Es gibt keine absolute Sicherheit. Wenn du so einen Schiss hast, dass dir jemand dein Design klaut, dann baue in das Gerät eine Batterie ein, die du mit dem Gehäuse verknüpfst. Den Bitstream lädst du dann aus batteriegepuffertem SRAM - wenn einer das Gehäuse aufmacht, ist der Bitstream weg. Kann man auch erweitern und den Bitstream einmalig bei der Produktion des Geräts laden und per Batterie dafür sorgen, dass der FPGA für die Lebensdauer nicht neu befüllt werden muss. Ich sehe da sogar ein Geschäftsmodell...
S. R. schrieb: > Wenn du so einen Schiss hast, dass dir jemand dein Design klaut, dann > baue in das Gerät eine Batterie ein, die du mit dem Gehäuse verknüpfst. > Den Bitstream lädst du dann aus batteriegepuffertem SRAM - wenn einer > das Gehäuse aufmacht, ist der Bitstream weg. Nein, das Design ist sowieso Open-Source. Genauso wie der Source des M1. In einem externen Secure-Element sind Nutzdaten gespeichert, die sicher sein sollten und für die Entschlüsselung der Kommunikation zwischen Secure-Element und FPGA kommt ein AES-Schlüssel zum Einsatz, den der M1 auch kennen muss. Mir geht es eigentlich nur um die Sicherheit des Schlüssels für die Kommunikation mit dem Secure-Element. Mittlerweile wurde beim Autor des Papers (Link im ersten Beitrag) nachgefragt, welches Equipment man für einen praktischen Angriff bräuchte. Das sind sowas 35k für Oszi, 5-10k für EM-Setup ... Also doch aufwändiger, als man beim Lesen des Papers erstmal vermutet hätte.
Mampf F. schrieb: > Konkreter Fall ist, dass in einem meiner FPGAs ein Cortex M1 läuft und > im ROM, das eigentlich durch die bitstream-encryption geschützt sein > sollte, ein Private Key für ein externes Secure-Element liegt. Ich kenne ja deinen Aufbau nicht, aber sollte der Private Key nicht im Secure Element gespeichert sein? Es ist doch der Sinn eines SE, das man an den Schlüssel nicht rankommt.
torusle schrieb: > Mampf F. schrieb: >> Konkreter Fall ist, dass in einem meiner FPGAs ein Cortex M1 läuft und >> im ROM, das eigentlich durch die bitstream-encryption geschützt sein >> sollte, ein Private Key für ein externes Secure-Element liegt. > > Ich kenne ja deinen Aufbau nicht, aber sollte der Private Key nicht im > Secure Element gespeichert sein? Es ist doch der Sinn eines SE, das man > an den Schlüssel nicht rankommt. Nein, bei symmetrischer Verschlüsselung benötigt man den Key sowohl im Secure-Element als auch im M1. Bei asymmetrischer Verschlüsselung wäre ein Private Key im SE, und ein Private Key im M1. Irgendwie muss der M1 ja verschlüsselte Datenübertragung entschlüsseln ... Das geht nicht, ohne dass er einen Key kennt.
Mampf F. schrieb: > Irgendwie muss der M1 ja verschlüsselte Datenübertragung entschlüsseln > ... Das geht nicht, ohne dass er einen Key kennt. Vielleicht habe ich Deinen Aufbau nicht richtig verstanden, aber wäre es nicht eine Option, wenn der M1 den Datenstrom an einen IP-Core schickt, der die Ver- bzw. Entschlüsselung übernimmt? Dann wäre der Key im IP-Core aber nicht im Speicher des M1 zu finden. Mampf F. schrieb: > Das sind sowas 35k für Oszi, 5-10k für EM-Setup ... Also doch > aufwändiger, als man beim Lesen des Papers erstmal vermutet hätte. Das ist m.E. relativ gängiges Equipment, auf das ich z.B. auch Zugriff hätte. Duke
Duke Scarring schrieb: > Mampf F. schrieb: >> Irgendwie muss der M1 ja verschlüsselte Datenübertragung entschlüsseln >> ... Das geht nicht, ohne dass er einen Key kennt. > Vielleicht habe ich Deinen Aufbau nicht richtig verstanden, aber wäre es > nicht eine Option, wenn der M1 den Datenstrom an einen IP-Core schickt, > der die Ver- bzw. Entschlüsselung übernimmt? > Dann wäre der Key im IP-Core aber nicht im Speicher des M1 zu finden. Hmm, du meinst, der M1 sollte selbst gar keinen Zugriff auf den im Bitstream gespeicherten Key zum Entschlüsseln der Kommunikation haben und es anstelle von einem IP-Core machen lassen, der irgendwo im Bitstream ist? Glaub nicht, dass das die Lösung ist. An irgendeinem Punkt hat der M1 die Nutzdaten aus dem SE im Klartext und wenn man den Bitstream entschlüsseln kann, kann man auch das ROM des M1 austauschen. Dann kann man auch eine gepatchte Software im Bitstream integrieren, die die Nutzdaten per zB RS232 rausschicken kann. Man hätte dann zwar nicht den Key für die Verschlüsselung der Kommunikation, aber den will man ja eigentlich eh nicht. Man würde die Nutzdaten haben wollen. > Mampf F. schrieb: >> Das sind sowas 35k für Oszi, 5-10k für EM-Setup ... Also doch >> aufwändiger, als man beim Lesen des Papers erstmal vermutet hätte. > Das ist m.E. relativ gängiges Equipment, auf das ich z.B. auch Zugriff > hätte. Ach, die nötige Software und einiges an Erfahrung hatte ich noch vergessen :) Ich glaub, der Aufwand ist für das, was da eigentlich verschlüsselt wird, zu hoch.
Mampf F. schrieb: >>> Das sind sowas 35k für Oszi, 5-10k für EM-Setup ... Also doch >>> aufwändiger, als man beim Lesen des Papers erstmal vermutet hätte. >> Das ist m.E. relativ gängiges Equipment, auf das ich z.B. auch Zugriff >> hätte. Es geht auch günstiger, wenn man das Glück hat, trotz Deaktivierung noch JTAG-Zugriff zu erlangen...so geschehen bei der 'sicheren' Lockbox von Analog Devices oder beim Spartan6. Mampf F. schrieb: > Ich glaub, der Aufwand ist für das, was da eigentlich verschlüsselt > wird, zu hoch. Nach allen theoretischen Betrachtungen: Bevor du noch Challenge-Response-Authentifizerung zwischen M1 und IP-Core implementierst: Warum nicht einfach einen kleinen ZPU-Kern mit ins Fabrik backen, der den Datenaustausch ohne Zutun des ARM erledigt? So habe ich's gemacht, und aus Neugier mal in die resultierende *.bit analysiert, wie gut man (mit Vorwissen) an den privaten Schlüssel rankommt: a) Im BRAM sehr leicht zu finden b) In Distributed Logik schon ein recht aufwendiges Unterfangen Wenn man dann schon nur die Opcodes im Encoder-ROM mit einer einfachen XOR-Methode verwurstet, ist das ganze nicht mehr wiederzuerkennen. Und da funktioniert security by obscurity eben sehr gut. In so einigen mir unter die Nase gekommenen Implementierungen liegen die Schlüssel einfach im Klartext rum, weil offenbar gedacht wird: Da kommt schon keiner ran. Obfuscate, Beate!
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.