mikrocontroller.net

Forum: FPGA, VHDL & Co. Wie sicher ist die Bitstream-Encryption Xilinx?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Tobias B. (Firma: www.elpra.de) (ttobsen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oszi40 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Clemens N. (cleemens)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: torusle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Mampf F. (mampf) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.