Es kam die Frage auf wie man BIT-Files die man zu Kunden schickt, um diese im Feld auf bestehende Schaltungen zu bringen, schützen könnte. Es gab wohl eine Krisensitzung deswegen und die Befürchtung steht im Raum, daß das BIT-file mittels KI-Software analysiert und re-engineered werden könnte.
Meines Erachtens bekommt man mit dem Programmierfile / Mask-File lediglich die Netzliste zusammen, wenn man die Informationen über den Chip und dessen Resourcen hinzuzieht.
Daraus die Funktion zu ermitteln, dürfte schwierig sein. Allerdings denke ich daß man alles vor einem Multiplizierer durchaus in eine Gleichung übersetzen könnte. Auch Zähler müssten leicht zu identifizieren sein, um daraus eine Schaltung zu generieren. Hinzu kommen die Adressen und Daten an BRAMs.
Wie ließe sich das verhindern?
AES-Encryption geht meines Wissens nur so, daß man das file als fertig programmiertes Flash auf dem PCB ausliefert und unauslesbar macht.
profile
qwen3-coder:30b
Um diese Frage präzise beantworten zu können, benötige ich zunächst weitere Informationen. Es gibt verschiedene Arten von FPGA-Programmfiles, z.B. HDL-Dateien (wie VHDL oder Verilog), bitstream-Dateien (wie .bit oder .rbf) und andere Formate.
HDL-Dateien (VHDL/Verilog): Diese sind Textdateien, die von Menschen lesbar sind und in der Regel nicht direkt per KI dekodiert werden müssen. Sie können jedoch mit KI-gestützten Tools analysiert oder generiert werden.
Bitstream-Dateien: Diese sind binäre Dateien, die von einem FPGA direkt verwendet werden können. Obwohl sie binär sind, kann man sie mit KI-Tools analysieren, um ihre Struktur zu verstehen, aber nicht unbedingt "dekodieren" im herkömmlichen Sinne.
Andere Formate: Es gibt auch spezifische Formate für verschiedene FPGA-Hersteller (z.B. Xilinx oder Intel), die möglicherweise andere Eigenschaften aufweisen.
Welche Art von FPGA-Programmfile meintest du genau? Möchtest du wissen, ob es möglich ist, einen bestimmten Typ von Datei mit KI zu analysieren oder zu dekodieren? Falls ja, können wir den genauen Dateityp oder den Inhalt näher betrachten.
Es geht um .bit-Dateien von Xilinx. Kann eine KI diese analysieren und deren Funktionsweise erklären?
profile
qwen3-coder:30b
Ergebnis von ask_user ansehen
Ich werde eine allgemeine Erklärung über .bit-Dateien von Xilinx und deren Analyse mit KI bereitstellen. Diese Dateien sind binäre Dateien, die von Xilinx-FPGAs verwendet werden, um die Konfiguration des Chips zu speichern.
Allgemeine Informationen zu .bit-Dateien von Xilinx
.bit-Dateien sind binäre Dateien, die zur Konfiguration von Xilinx-FPGA-Chips (Field-Programmable Gate Arrays) verwendet werden. Sie enthalten die erforderlichen Daten, um den FPGA auf eine bestimmte Funktionalität zu programmieren.
Struktur einer .bit-Datei
Eine .bit-Datei besteht aus mehreren Abschnitten:
Header: Enthält Informationen über die Datei, wie z.B. die Version und das verwendete FPGA.
Configuration Data: Die Hauptdaten, die den FPGA konfigurieren, bestehen aus Bitmuster, die die Verbindungen und Funktionen der FPGA-Logik definieren.
Checksums: Um sicherzustellen, dass die Datei nicht beschädigt ist.
Analyse mit KI
Obwohl .bit-Dateien binär sind, können sie mit KI-Tools analysiert werden:
Struktur- und Inhaltserkennung: KI kann helfen, die Struktur der Datei zu erkennen und den Inhalt zu interpretieren.
Funktionsanalyse: Durch maschinelles Lernen können Muster in den Konfigurationsdaten identifiziert werden, was zur Erklärung der Funktionalität des FPGAs führen kann.
Vergleich mit anderen Dateien: KI kann .bit-Dateien mit bekannten Mustern vergleichen, um ihre Funktion zu verstehen.
Einschränkungen
Binäre Natur: Da .bit-Dateien binär sind, ist die direkte Interpretation durch KI schwierig.
Hersteller-spezifisch: Die Struktur kann von Hersteller zu Hersteller variieren.
Zugriff auf Dokumentation: Um die vollständige Funktionsweise zu verstehen, benötigt man oft zusätzliche Dokumentation oder spezifische Tools.
Fazit
Obwohl .bit-Dateien nicht direkt mit KI dekodiert werden können, kann KI helfen, ihre Struktur und Funktionalität zu analysieren. Es ist wichtig, dass die Analyse durch geeignete Tools und zusätzliche Informationen ergänzt wird.
Wenn du eine spezifische .bit-Datei zur Analyse hast, können wir den Prozess genauer durchgehen.
ps:
Ich hab inzwischen gelernt, das binäre Dateien erst mal ins Hex-Format umgewandelt werden sollten, dann kann die KI mehr damit anfangen.
Daraus die Funktion zu ermitteln, dürfte schwierig sein.
Ich denke, das kommt drauf an. :-D
Es gibt fuer einige wenige FPGAs auch Opensourcetools. Also haben
Menschen da herausgefunden wofuer die einzelnen bits stehen.
In dem Falle kann die KI das sicher auch und das 1000x schneller.
Wenn aber gar nicht bekannt ist was ein Bit bewirkt sieht es schwierig aus.
Aber war es nicht so das man die Bitfiles der groesseren FPGAs auch
verschluesseln kann? Dann wuerde das ja das Problem loesen und gleichzeitig
beweisen das man sich ohne Verschluesselung berichtigt Sorgen machen muss.
AES-Encryption geht meines Wissens nur so, daß man das file als fertig
programmiertes Flash auf dem PCB ausliefert und unauslesbar macht.
Bei Xilinx kann man den Schlüssel ins FPGA speichern, entweder volatil per Batterie gepuffert oder einmalig in eine Fuse. Bei der Gelegenheit kann man auch das jtag per Fuse durchbrennen.
Das mit zum passenden Schlüssel verschlüsselte File kann man in den Flash packen und nach Belieben updaten, es wird dann nur geladen wenn es mit dem richtigen Schlüssel verschlüsselt ist. In den Fuse Optionen kann man auch einstellen, dass keine unverschlüsselten Files geladen werden dürfen, also geht dann nur noch eures.
Ich habe mir den Spass vor einer Weile mal gegeben, von einem Bit-File ist man mit KI-Fuzzing relativ schnell bei der Architektur, somit bei einer Netzliste. Einen in der Fabric versteckten Schlüssel auffinden: Check. Der Crypto-Bootloader (noch Spartan6) ist also hinfällig. Aus der Netzliste wirklich wart- und lesbare HDL herzustellen ist schon schwieriger, aber neuere Claude-Agenten sind erschreckend gut im Aufräumen.
Wenn einzelne Module mit Bauchgefühl von der HI isoliert werden, kannst du auf jeden Fall eine Rechenpipeline relativ gut identifizieren und schauen, was da genau passiert.
Schwieriger wird es schon bei obskuren Architekturen, wie kleinen Rechen-Units mit eigenem oder etwas umgemapptem Transputer-Style-Befehlssatz.
Im Grunde genommen müssen wir uns dran gewöhnen, dass es bald keinen Unterschied zwischen Open und Closed-Source mehr geben wird. Dann verlagert sich die Schlacht auf die juristische Ebene. Ob es dann einfacher wird, dem Konkurrenten den Klau nachzuweisen, sei dahingestellt, ob sich Richter auf eine KI-Analyse stützen dürfen ist ja auch noch nicht geklärt.
Thema "Gegen Auslesen schützen": Der Crypto-Bootstream ist solange sicher, bis der Key irgendwo rauspurzelt. Da sind schon einige super ausgedachte Konzepte völlig gegroundet worden, weil es dann eben doch ging, sich in den JTAG-Zugang reinzuglitchen, oder die schwereren Jungs offenbar mit dem AFM (atomic force microscope) auffahren.
Schlussendlich ist man immer wieder bei Security through obfuscation, oder bei sehr architekturspezifischen Lösungen. FPGAs mit internem Flash wo wirklich der JTAG gefuset werden kann helfen schon mal. Versuche, das z.B. beim MachXO3 zu umgehen, resultierten zumindest in einem komplett toten Chip.
Was die Zähler angeht: Viele Glitch- oder Seitenkanalattacken basieren darauf, dass irgendwann mal ein einfacher Binärcounter umschlägt und sich das dann in der Versorgungsspannung messbar macht. Brauchte noch nicht mal KI um diese zu identifizieren und in die "besseren" Gray- oder LFSR-Counter umzuwandeln.
Da sind schon einige super ausgedachte Konzepte völlig gegroundet worden,
weil es dann eben doch ging
Alles geht irgendwann und irgendwie. Man muss nur den Aufwand hoch genug
treiben damit ehrlich nachprogrammieren weniger aufwendig ist als zu kopieren.
Man darf sich dann nur nicht ins Internet stellen und ein:
Haha, ich bin die coole XY-Firma, mein Megaansatz bekommt ihr nicht geknackt.
Weil damit motiviert man dann gleich 1000Studenten mit zuviel Zeit, die
sich herausgefordert fuehlen und da ist dann mal einer drunter der es doch schafft. :)
Oder das die KI mit bisschen Vibe-Coding das gleiche hinbekommt,
für was Entwickler früher paar Jahre gebraucht haben ;-)
Interessante Zeiten....
Das denke ich auch, allerdings gilt das IMHO nur fuer die ersten 90%,
die letzten 10% sind dann aber Erfahrungen aus der Praxis die in
ein Projekt eingeflossen sind und die sich niemanden mehr so
richtig logisch erschliessen.
Da wird es dann hart, besonders wenn der Nachprogrammierer nicht
weiss was er macht.
IMHO grenzt das Anliegen des TO schon an Wunderglauben. Es scheint ja heutzutage nicht ungewöhnlich das man von einer KI Wunder erwartet, dabei ist eine KI nur ein automatisierter Internetschnüffler ...
In der Vergangenheit wurden einfache FPGA's (oder was man so nannte, es waren wohl eher CPLD) bezüglich des bitstreams partiell decodiert. Aber dazu waren BlackBox-Messungen an realen Exemplaren nötig. so an Lattice MAchXO Typen geschehen (Project Oxide -> https://github.com/gatecat/prjoxide/blob/main/README.md ). Auch bei Lattice ice wurden male Erfolge verlautbart:
Also müsste man erstmal einen passenden teststand bauen den man dann einige Zeit durchlaufen lässt. Das erinnert mich irgendwie an Blechtley park und seine Brute-Force machinery
Sollte man damit Erfolg haben, hat man immer noch nicht alle nötigen Daten für ein eigenes P&R, es fehlen die (internen) timing-Infos. Und ohne die kann man die Limits für die Pfadlängen abhängig von den User-timing-constraints nicht überprüfen.
Und hinsichtlich der Zukunfssicherheit sind auch nicht alle Hürden genommen, vom Hersteller undokumentierte Feauture fallen auch mal in späteren Revision/Varianten weg. In den schnellen transceivern von AMD (GTH u.ä.) sollen etliche undokumentierte Feature Register-settings stecken.
wurden einfache FPGA's ... bezüglich des bitstreams partiell decodiert.
ich halte das auch bei komplexen FPGAs für möglich und das sind sicher auch schon welche dran.
Nur ist das eben eine andere Richtung von der Funktion ausgehend, unter Anwendung von Randbedingungen eine Schaltung zu entwerfen oder deren Funktion zu beschreiben und dann vom Synthesizer unter Anwendung der Physik des FPGAs die LUTs zu programmieren.
Hat man alles über die LUTs herausgefunden, hat man nur eine Netzliste. Diese wieder nach oben in eine höhere Hierarchie zu erheben, erfordert das Hinzufügen von Information die man nicht hat.
Wenn die Funktion des Systems nicht genügend gut bekannt ist, geht das nicht. Man bekommt nur ein unzureichendes Abbild.
Wenn aber die Funktion bekannt ist, kann man die Software auch gleich komplett schreiben lassen. Das scheint mir einfacher.
Zur Verschlüsselung von bitstreams (zwecks authentifizierung) ist
einiges geforscht
Am Ende ist es eine Frage des Aufwands. Mit wieviel Enthusiasmus wird sich jemand an die Entschlüsselung einer SW machen, wenn er deren Funktion nicht versteht, um später per Erweiterung davon zu profitieren, den gesamten Kasten für lau zu erhalten. Man könnte allenfalls einen trickreich programmierten Chip entzaubern, der irgendein Verfahren umsetzt, dessen Mathematik noch nicht publiziert ist oder die man darin nicht vermutet um herauszubekommen, wie jemand etwas macht.
Insgesamt muss der Aufwand zur Entschlüsselung geringer sein, als die Neuerstellung. Gerade mit KI ist letzteres ja sehr beschleunigt worden.
FPGA-BIT entschlüsseln würde man sicher noch hinbekommen, aber die Netzliste dürfte das Problem werden.
LUT resp. der Inhalt dieser 2**n*1bit Speicherzelle sehe ich nicht so problematisch, schwieriger dürften die routing resourcen (Versa-blocks) sein, da diese so garnicht in den docs beschrieben werden.
Wenn aber die Funktion bekannt ist, kann man die Software auch gleich komplett schreiben lassen. Das
scheint mir einfacher.
Denk ich auch. OK, gelegentlich werden tricks benutzt, um weniger resourcen zu benutzen, aber die reine Funktion ist schneller nachgebaut als detailgetreu re-engineered.
Befürchtung steht im Raum, daß das BIT-file mittels KI-Software analysiert und re-engineered werden
könnte.
Und was ist da konkret das Problem dabei resp danach? - das der Kunde dann seinen FPGA selber macht und keine Zulieferer/Dienstleister für die Firmware braucht ? - Unwahrscheinlich.
Die Notwendigkeit das Bitfile zu verschlüsseln ergibt sich aus meiner Erfahrung nach lediglich aus dem CRA, das eben für einige Produkte das Grundsicherheit gegen "cyberangriffe"/Manipulationen verlangt.
Interessant an dem Scenario ist IMHO nur, wie das in Bezug auf Patentierbarkeit ausschaut:
Wäre die Herausgabe eines Bitfiles (mit dem noch zu patentierenden design) an Dritte aufgrund der (IMHO) hypothetischen) Möglichkeit des Re-engineering bereits eine "Offenlegung/Veröffentlichung" (engl. "patent disclosure") die rechtlich eine Patenterteilung unmöglich macht ?
The 7 series FPGA AES encryption logic uses a 256-bit encryption key.
... der komplett wirkungslos ist, wenn man mit einem schnellen FPGA am JTAG oder per SelectMap das gut dokumentierte "Orakel" bemüht.
Man kann natürlich alle möglichen Schnittstellen deaktivieren, Binärzähler eliminieren, usw. damit von aussen kaum was zu ersniffen ist. Nur dann hat man sich halt auch ebenso leicht ausgesperrt oder ein Hardware-Update geht schief.
Bei manchen Lösungen kann man sich trotz deaktiviertem JTAG wieder hineinglitchen, wie die als damals unknackbar (ohne HMAC-Schwachstelle) beworbene Lockbox der Blackfin 52x Reihe.
IMHO grenzt das Anliegen des TO schon an Wunderglauben. Es scheint ja
heutzutage nicht ungewöhnlich das man von einer KI Wunder erwartet,
Schon mal ein ghidra-Dekompilat Claude zum Aufräumen gegeben? Das hat nichts mit Wundern zu tun. Schlicht Fleissarbeit und Pattern Matching.
Mit lokalen Agenten, die am JTAG nudeln dürfen, ist auch das Glitchen eine Job für die KI geworden. Willkommen in der neuen Welt.
The 7 series FPGA AES encryption logic uses a 256-bit encryption key.
... der komplett wirkungslos ist, wenn man mit einem schnellen FPGA am JTAG oder per SelectMap das
gut dokumentierte "Orakel" bemüht.
Series 7 ist ja diesbezüglich abgelöst, die Ultrascale+ haben längere Schlüssel (2048bit) und die "bekannten" Schwachstellen sind auch ausgemerzt. Alles dokumentiert, für den der das Lesen gewillt ist (UG908, UG570).
Wurde schon oben gesagt, kann man einen gescheiten teststand bauen ist das brute-forcen kein problem für den der sich ein script dafür schreibt.
Die KI kann natürlich auch ein script auskotzen, aber zum Teststand bauen braucht es noch richtige Hände ...
das BIT-file mittels KI-Software analysiert und re-engineered werden
könnte.
Mein Wissen hiervon ist noch aus den Jahren 2016 bis Anfang 2021, weil da ein paar enge Freunde an der Uni über FPGA-Reverse-Engineering geforscht haben. Damals war es möglich die Struktur vom Bitstream zu rekonstruieren. Man bekommt zwar eine Netlist raus, aber das wie mit Assembly, wo jemand nur genug Zeit reinstecken muss um es zu verstehen und den äquivalenten Quelltext zu schreiben. Damals hat sich die akademische Welt auf Physically Unclonable Function (PUF) konzentriert. Keine Ahnung wie der heutige Stand der Dinge ist.
Da heutige KI recht gut beim Pattern Matching geworden ist und aus Assembly guten Quelltext erzeugen kann, wird sie das bald auch mit Netlists machen können. Die Bitstream-Struktur von manchen FPGA-Architekturen, z.b. 7-series, ist schon gut dokumentiert und ich vermute, dass manche fernöstliche Firmen intern schon andere Architekturen dokumentiert haben.
Was du machen kannst, ist Partial Reconfiguration (DFX in neuen Versionen von Vivado) zu nutzen und die nachgeladenen Bitstreams besser zu schützen. Das macht es nur schwerer euer Gerät zu klonen, verhindert es aber nicht.
Series 7 ist ja diesbezüglich abgelöst, die Ultrascale+ haben längere
Schlüssel (2048bit) und die "bekannten" Schwachstellen sind auch
ausgemerzt. Alles dokumentiert, für den der das Lesen gewillt ist
(UG908, UG570).
Schau, was in Xilinx-Dokus steht, hinkt der Realität meist Jahre hinterher und googeln und KI befragen können wir alle. Da stehen dann auch einige Bugs aufgelistet, aber nicht ganz alle.
Ich sage nur: Die Schlüssellänge spielt keine Rolle, wenn in Vivado ganz, aber ganz dumme Fehler gemacht werden. Manchmal fragt man sich, ob mit Absicht.
(Kleine Seitenbemerkung: In der Vergangenheit konnte man ohne langes Suchen die Keys in Vivado finden um crypted IP in OpenSource-Tools zu simulieren).
Insofern sehe ich den meisten Krempel eher ad absurdum, entweder ist der ganze Aufwand sinnlos, oder die Gefahr ist zu gross, dass man sich aussperrt und der Kunde mit defekter Hardware dasteht. Vielleicht ist jetzt die Zeit, sein IP-Geschäftsmodell grundlegend zu überdenken.
Mein Wissen hiervon ist noch aus den Jahren 2016 bis Anfang 2021,
weil da ein paar enge Freunde an der Uni über FPGA-Reverse-Engineering geforscht haben.
Falls da was publiziert wurde (Abschlussarbeit, Diss etc.) würde ich da gern mal reinlesen.
Um welche Uni handelt es sich ? Vielleicht kann man auch Links nennen ?
Wäre die Herausgabe eines Bitfiles (mit dem noch zu patentierenden
design) an Dritte aufgrund der (IMHO) hypothetischen) Möglichkeit des
Re-engineering bereits eine "Offenlegung/Veröffentlichung" (engl.
"patent disclosure") die rechtlich eine Patenterteilung unmöglich macht ?
Wenn du das Produkt an irgendwelche Kunden öffentlich verkaufst und deine zu patentierbare Erfindung für den Endanwender sichtbar/nutzbar ist, dann ist das eine veröffentlichung.
So wie auch wenn du das Ding z. B. an einer Messe zeigst und (wichtig) erzählst, das das Ding diese Erfindung kann (Du kannst es an der Messe zeigen auf eine Art ohne von der Erfindung zu erzählen und sie auch nicht demonstrieren, nur was das Ding sonst so kann).
Wenn du das an deinen einzigen Kunden lieferst oder an einen kleinen Kreis von Alphatestern, dann mach mit all denen einen NDA. Das sollte dann klar sein, dass es eben nicht öffentlich ist.
Schon mal ein ghidra-Dekompilat Claude zum Aufräumen gegeben?
Meines Wissens deassembliert das tool nur ASM und höher gelagerte sequezielle Codes. Das sind Abläufe, die an sich sehr linear zu ermitteln sind und für die zusätzlich in den meisten Fällen auch noch die Zielhardware bekannt ist.
Das ist bei einem Maschinen-Code schon ein Problem, wenn man die HW z.B. nicht kennt und erst im Detail ermitteln muss, womit erst eimmal nicht klar ist, was passiert, wenn Bit 7 auf Port 4 gesetzt wird. Man kann das zwar herausbekommen, katalogisieren, dokumentieren und in C emulieren, aber funktionell verstanden ist es allein wegen des Codes noch lange nicht.
Wie geht das erst bei anonymen LUTs und der Hardware von FPGAs? Wenn man die Zielhardware nicht hat, kommen auf FPGA-Pins nur Bitmuster raus. Ob es ein Datenbus ist, der zusammengehört, könnte man noch raten, aber irgendwelche einzelnen enables für Chips verbergen schon ihre Funktion, wenn man die deren Typ nicht direkt ablesen kann, weil delabeled. Dann muss man auch die Chips reengineeren.
Gfs muss man auch einmal rausbekommen, welcher FPGA es genau ist. Man kann sich die FPGAs wie praktisch alle Chips auch ungelabelt oder phantasiegelabelt bestellen.
Der Trend wird damit wieder hingehen zu costum-ASICs, die um die FPGAs sitzen und Baugruppen, wo nur noch anonyme Käfer gleicher Baugröße sitzen, deren Beschriftung 1 Woche nach Auspacken aus der Stickstoffpackung wegoxidiert, nachdem sie verpappt sind.
Ich werfe das mal in die Disussion und wette, dass in spätestens 1 Jahr, wenn der erste FPGA droht gehackt zu werden, Altera und Xilinx damit rauskommen. Dann muss man nur noch in den Programmierfiles einen Hinweis auf den Chip entfernen.
Obfuskation ist vielleicht auch eine Möglichkeit: Lege soviel Müll wie möglich dazu, sodass man nicht mehr erkennen kann was der eigentliche Schaltkreis ist, es sei denn
man könnte den FPGA anhalten um die Flipflops auszulesen. Z.b. Ein FlipFlop das irgendwo
gesetzt wird und dass nur wenn es gesetzt ist dann den Müllpfad abstellt.
Das müsste schwer zu analysieren sein, vielleicht aber auch nicht...
Was sicher funktioniert ist wenn du das Protokoll änderst: Beim Start hast du einen
Hinterkanal über den ein "Müllabschaltschüssel" geschickt wird. Der bestimmt dann was echt ist und ist und was fake.
Es kam die Frage auf wie man BIT-Files die man zu Kunden schickt, um
diese im Feld auf bestehende Schaltungen zu bringen, schützen könnte. Es
gab wohl eine Krisensitzung deswegen
Ja und? Allzuviel neues dürfte da nicht rausgekommen sein. Zuerst sollte man eine Liste erstellen hinsichtlich der Angriffsflächen und Möglichkeiten, danach eine Liste mit den Sicherheitsebenen bei der Übertragung und beim Verwalten beim Kunden. Kann ein wenig komplex werden - warum müssen wir uns hier alles aus den Fingern saugen ohne genauere Hintergrundinfos?
Wie möchtest du denn den Code umgehen, um ein FPGA zu laden, das auf
diesen codiert ist?
Das ist ja doch der eigentliche Sinn.
Die Frage verstehe ich nicht so ganz, aber wenn ich den Key ermittelt habe, kann ich einen encrypteten validen Bitstream erzeugen und das Teil bootet. Genauso kann ich einen third-party Bitstream nach Schema F entschlüsseln und durch bit2ngc jagen. netgen macht daraus schliesslich HDL.
Das ist bei einem Maschinen-Code schon ein Problem, wenn man die HW z.B.
nicht kennt und erst im Detail ermitteln muss, womit erst eimmal nicht
klar ist, was passiert, wenn Bit 7 auf Port 4 gesetzt wird. Man kann das
zwar herausbekommen, katalogisieren, dokumentieren und in C emulieren,
aber funktionell verstanden ist es allein wegen des Codes noch lange
nicht.
Wenn der zugrundeliegende Prozessor irgendwie bekannt ist, errät Claude zumindest im Schnitt recht zielstrebig, worum es geht. Man muss ihm nur mit "Bauchgefühl" helfen, damit er keine Fehlannahmen trifft. Wenn die Peripherie undokumentiert ist, wird's mit dem Raten komplexer, aber meist macht Peripherie ja irgendwas nach aussen hin.
Was die HDL angeht: Aus den P&R-Datenbanken und den LOC-Details beim Fuzzing weiss ich oder der Agent jeweils, welche .bit-Abschnitte in welche Primitiven bzw LUTs mappen. Dem übergeordnet sind Primitiven, die sich nach dem Mapping natürlich in die Fabric-Elemente auflösen, dennoch lassen sie sich identifizieren (wie ebendiese Zähler, DSP-Pipeline-stages, FSM, etc).
Wenn ich somit gezielt einen LUT4-Baum vereinfacht haben möchte, dröselt mir das sogar eine recht dumme "KI" das in Muxer, FF, und die state-Machine usw. auf. Was ich bisher nicht versucht habe, ist ein komplettes Design zu desynthetisieren, da fehlen mir die Resourcen.
Was erschreckend ist: Beim Fuzzing wird ja eine Logik erst mal generiert, dann in Primitiven gemappt, und dann eruiert, wie es im Rahmen des blackbox-Vorgangs plaziert und geroutet wird. Daraus kondensiert sich eine Syntheseregel, KI hat gelernt, wie's geht und errät passend dazu die Funktion.
Schau Dir sonst mal an, was bei yosys an Arbeit zum RE insbesondere einiger Lattice-Architekturen gemacht wurde. Project X-Ray wäre auf der Xilinx-Seite zu erwähnen. Und "dazumal" ging das noch nicht so KI-autonom vonstatten.
Gfs muss man auch einmal rausbekommen, welcher FPGA es genau ist. Man
kann sich die FPGAs wie praktisch alle Chips auch ungelabelt oder
phantasiegelabelt bestellen.
Naja: JTAG-Pins identifizieren, IDCODE ermitteln.
Ist der JTAG gefuset, ist da Ende. Wenn aber irgend ein Binary von aussen kommt, gibt es meistens eine eindeutige Signatur. Bei Chips mit On-Chip-Flash schon haariger, da ist man dann auf das Hersteller-Binary angewiesen und liest a priori nur dann was aus, wenn es ein Türchen gibt, wie ein fehlerhafter USB-Stack, etc.
Aber ja, Lattice hat da z.B. schon Features, die das Klonen schwieriger machen. Oder wie bei manchen chinesischen Produkten: Man kann es sich leisten, einen Custom-8051 nur für das eine Gerät zu bauen und führt die hackende "Kundschaft" mit fehlerhaften Schaltplänen in die Irre. Und die neueren MachXO3 sind sicherlich ne harte Knacknuss.
Obfuskation ist vielleicht auch eine Möglichkeit: Lege soviel Müll wie
möglich dazu, sodass man nicht mehr erkennen kann was der eigentliche
Schaltkreis ist, es sei denn
man könnte den FPGA anhalten um die Flipflops auszulesen. Z.b. Ein
FlipFlop das irgendwo
gesetzt wird und dass nur wenn es gesetzt ist dann den Müllpfad
abstellt.
Das müsste schwer zu analysieren sein, vielleicht aber auch nicht...
Das habe ich mal probiert, um einen Key im Fabric zu verschleiern. Der prozedural generierte Nonsense führte allerdings zu ~50 mA mehr Stromverbrauch, und ich bin mir ziemlich sicher, dass Claude das schnell identifiziert hätte.
Mein Fazit: Die obskure Elektronik in ihrer Komplexität wird im Rahmen dieser Entwicklung wieder sowas wie ein Oldtimer mit allenfalls modifizierbarer Mechanik. Entweder ist es verdongelt und verklebt, oder man kann daran herumbasteln. Es gab mal eine Zeit, da bekam man zu seinem Videorekorder einen Schaltplan mit dazu...
Das habe ich mal probiert, um einen Key im Fabric zu verschleiern. Der
prozedural generierte Nonsense führte allerdings zu ~50 mA mehr
Stromverbrauch, und ich bin mir ziemlich sicher, dass Claude das schnell
identifiziert hätte.
Eine andere Idee: Xilinx hat anscheinend die Möglichkeit "sich selber zu programmieren":
(weiss nicht ob das stimmt aber google sagt ICAP).
Da wuerde ich einen kleinen Loarder schreiben der aud einen AES Schuessel wartet.
Den schickst du dann und danach den verschluesselten Bitstream. Den entschluesselst du
im FPGA und progammierst dich selber... klingt einfach aber ist sicher schwierig.
Der Bitstream ist jedenfalls immer verschluesselt. Wie du den Schluessel geheim hälst
ist eine andere Frage...
Wie Untersuchungen gezeigt haben, sind FPGAs anfällig für Hardware-Trojaner-Angriffe (HT), und es wurden zahlreiche Techniken – beispielsweise die auf RTL-Code (Register-Transfer-Level) basierende Analyse – vorgestellt, um HTs auf FPGAs zu erkennen. Die meisten Endnutzer von FPGAs verfügen jedoch nur über den Bitstream und nicht über den RTL-Code. Daher stellen wir eine neue Toolchain für das Reverse Engineering von FPGAs vor. Sie kann den FPGA-Bitstream präzise in einen RTL-Code umwandeln und unterstützt somit die Erkennung von HTs. Im Einzelnen erstellen wir zunächst eine integrierte Datenbank, die Informationen zur FPGA-Architektur sowie zur Zuordnung des Bitstreams enthält. Anschließend entwickeln wir zwei Werkzeuge, nämlich das Bitstream-Reversal-Tool (BRT) und das Netlist-Reversal-Tool (NRT). Diese können kombiniert werden, um den RTL-Code in angemessener Zeit aus dem FPGA-Bitstream zu gewinnen. Um die Wirksamkeit unserer Toolchain zu demonstrieren, bewerten wir sie qualitativ und quantitativ anhand von zwei Benchmarks (ISCAS’85 und ISCAS’89) sowie drei realen Anwendungen (8051-Kern, 68HC08 und AES). Unsere Toolchain ist umfassend, da sie alle Reverse-Engineering-Phasen abdeckt – vom Bitstream zur Netzliste und von der Netzliste zum Code –, ohne dass weitere Tools erforderlich sind. Darüber hinaus erstellt sie die Netzliste mit einer Korrektheitsrate von 100 % neu und generiert RTL-Code, der bei allen unseren Benchmarks funktional exakt dem Original entspricht. Nach unserem Kenntnisstand ist dies das erste Tool, das ein integriertes, präzises Reverse Engineering für FPGAs durchführen kann und damit den Weg für die netzlistenbasierte HT-Erkennung ebnet.
Genauso kann ich einen third-party Bitstream nach Schema F entschlüsseln
und durch bit2ngc jagen. netgen macht daraus schliesslich HDL.
Wie genau gehst du vor? So wie im Beitrag darüber skizziert per AI?
Und was heißt "netgen macht HDL"? Was kommt da heraus?
Eine Netzliste ist nach meinem Verständnis nach eine Verschaltung auf Gatterebene, entweder in Form von logischen Objekten wie Multiplexern und Decodern auf der Ebene des digitalen Verständnisses oder noch weiter untern unter Nutzung der dedizierten Blöcke im konkreten FPGA.
Das HDL das man daraus generieren kann, ist in beiden Fällen eines Strukturbeschreibung. Aus der müsste sich erst einmal durch "Nachdenken" schlußfolgern lassen, was da passiert.
Ich habe mir die Ntzliste von Xilinx einmal angesehen:
Die Schaltung beschreibt Addierer, Multiplizierer, Multplexer und auf der Implementierungsebene Look-Up-Tabellen. Dazu werden die PLLs gelistet, mit ihren Einstellungen.
Das alles wäre sicher verfügbar wenn man den Bitstream analysiert.
Nur ... was kann man damit anfangen? Habe ich ein Programm, daß 3 UARTs hat, finde ich die womöglich, kann einen Block kopieren und habe eine Vierte. Toll. Wenn ich mir eine Formel für eine komplexe Berechnung ansehe, dann tauchen dort auch solche Strukturen auf, aber wie man sie nutzen könnte, um sie zu ändern, sehe ich nicht.
Unsere Kunden sollen nicht einfach unser Bitfile nehmen, es kopieren und dann auf eine nachgebauten Plattform verwenden können. Das ist nämlich grundsätzlich möglich, weil wir u.a. Module von Enclustra einsetzen, die standardisierte interfaces haben, die auch gut dokumentiert sind.
Die im FPGA hinterliegende Schaltung ist in ihrer Funktion nur ungefährt bekannt. Die Gesamtfunktion des Systems ist aber genau bekannt, weil es eine Gebrauchsanleitung gibt und geben muss!. Damit könnte eine AI eine hardware entwerfen, die exakt die äußeren HW-Funktionen um das Modul herum erzeugt, danach die anderen Teile der Funktion in WIN-Software abbildet und schließlich die fertige bit-firmwar einfach in den Prozessor / das FPGA lädt, um dann das FPGA im Enclustramodul zu betreiben.
Das FPGA wäre dann nicht nur einfach nachgebaut, sondern sozusagen sogar eine Art constraint-file für Claude, wie der Prozessor agieren muss und wie die WIN-Software auf das SOC arbeiten muss. Diesbezüglich gibt es ja auch nur sehr begrenzte Möglichkeiten, die Win.EXE vor Dekodierung und Analyse zu schützen. Auch wäre das USB dorthin abhörbar.
Es gilt also, zu verhindern, dass
a) das Flash ausgelesen wird
b) der Datenstrom von da abgefangen wird
c) ein fremdes file in den FPGA geladen wird (für uns nicht relevant)
d) das programmierte FPGA ausgelesen wird
wenn das nicht verhindert wird, hätte jemand das bitfile / den programmierstream
Ab da muss verhindert werden, dass
e) das bitfile entschlüsselt wird
wenn das nicht verhindert wird, hätte jemand die Strukturen und indirekt die Netzliste
Ab da könnte er die originale Hardware nutzen, die einen entschlüsselten nicht verriegelten FPGA-bitstream nutzt.
Käufliche Hardware, an die jeder rankommt, wäre also an der Stelle nicht mehr durch einen codierten FPGA, der an Kunden gebunden ist, geschützt und indivualisierbar. Damit liegen alle Systeme, die ein solches Modul benutzen, offen.
Ab hier schützt nur noch selbst gebaut hardware, weil die erst nachgebaut werden muss.
Mit Hilfe des dekodierten FPGAs kann man aber auch diese mit Aufwand nachbauen oder per KI eine zumindest kompatible HW bauen, die den original FPGA-stream in offener Form unverändert nutzt.
Eine andere Idee: Xilinx hat anscheinend die Möglichkeit "sich selber zu
programmieren":
(weiss nicht ob das stimmt aber google sagt ICAP).
Da wuerde ich einen kleinen Loarder schreiben der aud einen AES
Schuessel wartet.
Den schickst du dann und danach den verschluesselten Bitstream. Den
entschluesselst du
im FPGA und progammierst dich selber... klingt einfach aber ist sicher
schwierig.
Der Bitstream ist jedenfalls immer verschluesselt. Wie du den Schluessel
geheim hälst
ist eine andere Frage...
Genau das ist jetzt eben eher ad absurdum...
Mit dem Spartan6 ging das ja erstmalig, so programmiere ich das FPGA übers Netz neu. Der "goldene" Bootloader vom SPI-Flash lädt den signierten Code nach, über die ICAP wird in den neuen Code gebootet. Der Key ist schon etwas obskur vernudelt, und die gängigen Tools finden die AES S-Box auch nicht auf anhieb, aber da der Bootloader ja auszulesen ist, hat man man mit dem Bitstream-RE doch schnell den Schlüssel im Klartext.
Schwierig ist der Vorgang ansich nicht, ist nur nicht so doll dokumentiert gewesen (damals).
Aber immerhin muss physischer Zugang zum Board/JTAG vorliegen, um das Image zu dumpen.
Wie genau gehst du vor? So wie im Beitrag darüber skizziert per AI?
Und was heißt "netgen macht HDL"? Was kommt da heraus?
Verilog oder VHDL in Primitiven-Form, also tausende LUTx aus dem Fabric, I/O blocks, usw. also unlesbar. Die KI räumt am dem Schritt dann gezielt auf und hilft, die Funktion zu erraten. Am Schluss kommt Python-HDL raus, die sich erneut synthetisieren und gegen die Netzliste co-verifizieren lässt.
Käufliche Hardware, an die jeder rankommt, wäre also an der Stelle nicht
mehr durch einen codierten FPGA, der an Kunden gebunden ist, geschützt
und indivualisierbar. Damit liegen alle Systeme, die ein solches Modul
benutzen, offen.
So ist es wohl. Oder du aktivierst halt Verschlüsselungen, oder kapselst allfällige Funktionalität in ein besser auslesegeschütztes FPGA.
Du kannst allenfalls mit eigenen Erweiterungen auffahren und mit Crypto-Chips (challenge-Response) die Funktionalität freischalten, wenn die Response/Lizenzcode, etc. passt). Aber ist auch ad absurdum ab dem Punkt, wo das originale Bitfile in seiner Funktion soweit offenliegt, dass man weiss, wo man es patchen muss. Das ist inzwischen bei gut dokumentierten Architekturen so einfach wie Assembly-Code patchen, würde ich sagen.
Ich hatte mal das Problem mit einem relativ einfach klonbaren Produkt, in das aber relativ viel Hirnschmalz von Seiten der Software einfloss. Ging mir dann nur noch darum, das sehr non-intrusiv zu detektieren, und dem Cracker zunächst ein Erfolgserlebnis zu verschaffen, dann sporadische Fehler zu werfen. Vielleicht auch eine Methode.
Genau das ist jetzt eben eher ad absurdum...
Mit dem Spartan6 ging das ja erstmalig, so programmiere ich das FPGA
übers Netz neu. Der "goldene" Bootloader vom SPI-Flash lädt den
signierten Code nach, über die ICAP wird in den neuen Code gebootet. Der
Key ist schon etwas obskur vernudelt, und die gängigen Tools finden die
AES S-Box auch nicht auf anhieb, aber da der Bootloader ja auszulesen
ist, hat man man mit dem Bitstream-RE doch schnell den Schlüssel im
Klartext.
Vielleich gibt es ja Xilinx Chips die Secure-boot für Bitstreams
implementieren: Mit Fuses mit denen man einen eigenen Root Schlussel
programmieren kann und keystores die man versiegeln kann und einem
Bootrom... damit muesste das doch möglich sein. Der erste Bootloader
ist dann signiert, der zweite verschlüsselt. Von einem Zynq vielleicht
der hat sicher SecureBoot...
Obfuskation ist vielleicht auch eine Möglichkeit: Lege soviel Müll wie
möglich dazu, sodass man nicht mehr erkennen kann was der eigentliche
Schaltkreis ist
Du meinst im FPGA? Oder in Form von Dummy Chips außen um das FPGA?
Innen wird das wenig helfen, fürchte ich, weil diese Daten ja nicht genutzt werden, sondern irgendwie nutzlos nach draußen gehen, wo sie nicht stören. Der Dieb des FPGAs wird das nachbauen und eventuell gar nicht merken, dass er etwas Nutzloses mitschleppt. Erst wenn er versteht, daß die Daten in einen Dummy-Chip gehen, der nichts tut, kann er es löschen. (oder auch sein lassen).
Ich sehe mehr Erfolg darin, die Daten zu anderen FPGAs zu verschlüsseln und dabei wenigstens 2 eigene einzusetzen, die die Daten zusammenführen. Dann können die anhand physikalischer Effekte ein dynamisches Protokoll aushandeln, welches außen nicht so einfach zu dekodieren ist. Dabei muss man auf Physik setzen:
Z.B kann man schnelle Serialzer nicht so einfach abhören, ohne die Signale zu verfälschen.
Man kann bestimmte PCB-Strukturen nutzen, um Laufzeiten mit ins Spiel zu bringen. Wenn man z.B. die Reaktion eines externen Bauteils zeitmäßig erfasst, muss der Kopierer exakt so ein Teil verwenden, gfs aus der gleichen Charge. Eine weitere Möglichkeit ist das Verpacken von FSK-informationen in Takten und Daten. Wenn das nicht jemand erkennt und einfach nur die Daten als solche nutzt und erzeugt, fehlen diese Infos. Ein Folge-FPGA wird dann erkennen, dass ein fake davor sitzt.
Ich habe derartige Methoden in meinem Synth implementiert, um sie zu testen. Da sind noch 2-3 andere Optionen, um die spezifische Physik von FPGAs ins Spiel zu bringen, z.B. eine besimmte Loop-Länge einer Inverterkette. Wenn die nicht mit den richtigen keeps aufgebaut ist, schwingt sie nicht oder anderes und kann nicht ausgewertet werden. Auch RAMs und andere Bauteile haben individuelle Marker. Da geht schon einiges. Mein Synth-FPGA kriegt z.B. ganz genau mit, ob es in einem aktuelles Trenzmodul läuft oder in einem älteren, weil es da ein paar Änderungen gab. Ich musste sogar schon etwas am Timing des designs ändern, damit die Daten nicht korrukpt gehen.
Es macht z.B. auch einen großen Unterschied, ob man die Daten aus einem Arty mit 100er - oder einem Nexys mit 200er zuführt. Das gleiche interne FPGA Design hat allein wegen der Verwendung eines anderen Oszillators und der Anpassung der PLL sowie Routing eine andere Signatur.
da muss verhindert werden, dass ... das bitfile entschlüsselt wird
Das ist das Problem. Der Schlüssel muss im FPGA hinterlegt sein und darf nicht aus dem Bitfile zu rekonstruieren sein. Wenn es aber gelingt, den Programmier-Datenstrom abzuhören, ist es grundsätzlich möglich, ihn auch zu entschlüsseln / aufzufinden. Ab da könnte man zumindest das Gerät mit eigenem File beladen.
Ob es gelingt, aus dem Bifile wieder nutzbaren Code zu machen, ist eine andere Sache.
Primitiven-Form, also tausende LUTx aus dem Fabric, I/O blocks, usw.
also unlesbar. Die KI räumt am dem Schritt dann gezielt auf und hilft,
die Funktion zu erraten. Am Schluss kommt Python-HDL raus, die sich
erneut synthetisieren und gegen die Netzliste co-verifizieren lässt.
Angenommen das geht, hat man 2 Themen:
Wie regeneriert / erzeugt man die constraints, um die Funktionen, die im HDL als behavioural formuliert sind, dann auch in eine funktionierende Hardware zu bringen? Mit Bezug zu den physikalischen Effekten im Beitrag drüber, gelingt es maximal erst einmal das FPGA-Design selber 1:1 zu reproduzieren. D.h. man hat die dieselbe Funktion durch die dieselbe FPGA-Komponenten-Nutzung. Es ist ein 1:1 Kopie ohne Schutz-Code und kann damit in baugleichen Systemen benutzt werden. Das schon wird ohne die constraints aber ein Problem. Wenn man wie ich das beschreibe Physik des FPGAs / des PCBs ins Spiel bringt, kann das bitfile nicht groß modifiziert werden. Man kann / wird also auf unterster Ebene den Schutz ausbauen und den Rest des FPGAs gleich lassen (müssen).
Ausgehend von einer vorhandenen Netzliste stellt sich dann die Frage, wie man diese zu einem interpretationsfähigen Design bekommt und das Verständnis rückgewinnt, wie und wieso etwas so gebaut wurde. Erst dann könnte man es um Funktionen erweitern und eigene Strukturen einbauen. Sofern das funktionell gelingt und man es auf Simulationsebene am Laufen hat, wäre dann wieder Punkt 1 zu lösen, um es auf die HW zu kriegen. Das design verschiebt sich und damit die Physik. Das müsste wieder berücksichtigt werden, wenn es als relevant im Systen eingebaut wurde.
In dem Zusammenhang erwähnte ich schon mal an anderer Stelle ein Beispiel: Es war ein Kundenprojekt Mitte der 2000er, wo ich gezielt hardware-Marker genutzt habe, um sie in der SW zu prüfen und zu kompensieren. Nachdem das im loop stand, war es nicht mehr möglich, die Software zu kopieren und in einem Gerätenachbau zu verwenden. Das hatten nämlich Chinesen bereits getan. Die Software erkannte, dass sie nicht in einem Original betrieben wurde. Das machte damals auch das FPGA und meldete es versteckt, respektive arbeite messtechnisch falsch. Selbst ein gefaktes und kopiertes FPGA hätte nicht im Nachbau funktioniert. Umgekehrt war es auch nicht mehr möglich eine kopierte Software mit eigenem Namen zu versehen, um sie in den gleichen oder kopierten Geräten zu benutzen. Ohne die exakte Kenntnis, wie die Hardware an bestimmten Stellen reagieren muss und wie sie beschaffen ist, funktioniert die SW nicht. Selbst wenn es gelungen wäre, die SW zu knacken, was die Chinesen sicher probiert haben (und heute wohl könnten!) ist es nicht möglich, sie zu ändern oder wesentlich zu erweitern, weil dann das timing nicht mehr passt, welches der FPGA indirekt überwacht.
Aus den P&R-Datenbanken und den LOC-Details ...
... dröselt mir das sogar eine recht dumme "KI" das in Muxer, FF, und die
state-Machine usw. auf.
Anbei eine Netzliste. Die kommt direkt vom Vivado. Schon anhand der Bezeichnungen kann man raten, was da passiert. Würde mich interessieren, was die KI daraus macht und was sie schlussfolgert.
Die Funktion als solche ist scheinbar trivial. In einem Pflichtenheft 1 Satz Text. Es stecken aber Aspekte drin, die sich nicht direkt aus dem HDL ergeben. Diese brauchen eine halbe Seite und ein Diagramm, das man verstehen muss. Berücksichtigt man die nicht, kann man das Modul nicht ändern, ohne dass die Funktion hinüber ist.
Es zu tippen dauerte inklusive der Simulation und einer Testsynthese mit Geradestellen des technischen timings mit genug slack gestern ziemlich genau 1h. Es aber funktionell anzupassen, dass es im Synth läuft nochmals eine weitere.
Vielleich gibt es ja Xilinx Chips die Secure-boot für Bitstreams implementieren
Anstatt einfach zu Raten was die heutigen FPGA Chips an Security Features implementiert haben könnten oder vielleicht machbar wäre, könnte man auch mal ein bisschen die Dokumentation zu aktuellen FPGAs durchlesen.
Von dem was ich bisher in die Finger bekommen habe, ist das der FPGA mit den weitreichensten Security Features. Er kann z. B. ein X509 Zertifikat zurückliefern, wenn er fertig ist, sich selber zu löschen und andere lustige Features.
Unsere Kunden sollen nicht einfach unser Bitfile nehmen, es kopieren und
dann auf eine nachgebauten Plattform verwenden können.
Es wurde wohl schon gesagt, aber trotzdem: so manches closed source oder auch closed Hardware Geschäftsmodell wird früher oder noch früher den Bach runtergehen.
Besser jetzt an einer wirklichen Lösung arbeiten, als vergeblich versuchen, das Unausweichliche zu verhindern.
Mein Lieblingsbeispiel ist immer noch die Telefonbuch-CD, die die damalige EX-Bundespost für schlanke 1800DM im Angebot hatte. Bis dann mal einer kam, der alle Telefonbücher „abtippen“ lies (in Wirklichkeit wars das damalige high tech in Form von OCR), und die CDs dann für 4,99DM anbot.
Bis dann mal einer kam, der alle Telefonbücher „abtippen“ lies (in Wirklichkeit wars das damalige high tech in Form von OCR), und die CDs dann für 4,99DM anbot.
... und der 2000 zu Schadensersatz in Höhe von 600 000 DM für diesen Datenraub verurteilt wurde, 2002 folgte dann die Insolvenz.
Anbei eine Netzliste. Die kommt direkt vom Vivado. Schon anhand der
Bezeichnungen kann man raten, was da passiert. Würde mich interessieren,
was die KI daraus macht und was sie schlussfolgert.
Auf die Schnelle: Dass das ein 4-Kanal-Mischer mit Gain und Clipping (bei 98%) ist, Audio 24 bit, 8-stufige Verarbeitungspipeline. Das ganze wird wohl schon isoliert sein, ansonsten sind LOC-Daten (die Infos die eigentlich aus dem BIT-File kommen) noch hilfreich.
Umwandlung in Lesbares mache ich jetzt mal nicht, frei nach: "des koscht in Böblingä abär was".
Z.B kann man schnelle Serialzer nicht so einfach abhören, ohne die
Signale zu verfälschen.
Man kann bestimmte PCB-Strukturen nutzen, um Laufzeiten mit ins Spiel zu
bringen. Wenn man z.B. die Reaktion eines externen Bauteils zeitmäßig
erfasst, muss der Kopierer exakt so ein Teil verwenden, gfs aus der
gleichen Charge. Eine weitere Möglichkeit ist das Verpacken von
FSK-informationen in Takten und Daten. Wenn das nicht jemand erkennt und
einfach nur die Daten als solche nutzt und erzeugt, fehlen diese Infos.
Ein Folge-FPGA wird dann erkennen, dass ein fake davor sitzt.
Schnelle Serializer: Hier im Wald gabs mal ne Firma, die mit im Grund Harddisk-Köpfen non-intrusiv den PCB-Datenverkehr mitgelesen hat. Naja.
Alle Ideen in Ehren, aber so physikalische Effekte am Rande der Ratings zu nutzen schreit a) nach riesigen Maintenance und Portabilitäts-Problemen (ich erinnere an Package Changes beim Spartan6, die aufgrund geänderter Dielektrizität das Timing versaut haben). Dasselbe bei PCB-Prozessen. Das will man sich wirklich nicht einbrocken.
b) ist mir da auch ein Fall bekannt, wo es den betreffenden Intruder so gar nicht interessiert hat, er bohrte ein Loch an der richtigen Stelle und hatte Zugriff. War eine unfassbare Blamage für den betreffenden Konzern.
Wie man's dreht und wendet, ich werde mir vermutlich nie mehr im Leben einen "sicheren" Kopierschutz ausdenken. Hier wurde gerade eben eine Heizungssteuerung aus den 90ern zu quasi-OpenSource (vom Binary zu recompilierbarem C-Code).
Da es sich um ein gewerbliches Thema handelt sehe ich folgende
Möglichkeiten:
dem Kunden keine Dateien zusenden sondern im Bedarfsfall einen
Servicetechniker schicken
technische Fragen mit einem FAE vom Lieferanten oder Hersteller klären
lassen
Das hat sich immer gut bewährt. Ich bin sogar mal dazu übergegangen, die damals superbilligen "Dockstar"-Dinger als nicht-auslesbare "Updater" zu verschicken. Da hätte man dann den ganzen JTAG-Strom reversen müssen, um auf irgendwelche Bits zu kommen. Heute ginge aber auch das mit KI-Eintrainieren sehr leicht.
Von dem was ich bisher in die Finger bekommen habe, ist das der FPGA mit
den weitreichensten Security Features. Er kann z. B. ein X509 Zertifikat
zurückliefern, wenn er fertig ist, sich selber zu löschen und andere
lustige Features.
Ist das noch was aus dem Actel-Vermächtnis? Ist zwar schon 20 Jahre her, aber da erinnere ich mich an ein spannendes Mittagessen mit einem Actel-FPGA-Spezi, der hat plausibel erklärt, wie sich der Chip jedwedem Ansinnen von Aufschleifen über Fuse-Locks-trotzdem-auslesen bis Glitchen offenbar erfolgreich widersetzt. Leider sind mir die Details entfallen.
Jain, mit dem Kauf von Microsemi noch früher Actel hat Microchip natürlich auch deren Technologien und, wichtiger, den Kundenkreis für diese FPGAs gekauft. Entsprechend sind die neueren FPGA Familien auch auf deren Bedürfnisse optimiert und weiterentwickelt worden.
Anstatt einfach zu Raten was die heutigen FPGA Chips an Security
Features implementiert haben
Was die an features implementiert haben, wissen die Klauvögel ja auch und haben daher den Ansatz, wo sie den Hebel ansetzen müssen, um es zu knacken. Meine Strategie ist ja eher auf funktionellen Schutz zu setzen, der nicht dokumentiert ist und auf den man erst einmal kommen muss.
4-Kanal-Mischer mit Gain und Clipping (bei 98%) ist, Audio 24 bit,
8-stufige Verarbeitungspipeline.
So ist es, ein "hochkarätiger" Audiomischer, allerdings konkret 8 Kanal und mit "Clipping" deshalb, weil es die Überlauf-verhinderung ist, wenn einer den Gain zu hoch gedreht haben sollte. Hinzu kommt eine Erkennung des Nutzungs des headrooms.
Was mathematisch nichts anderes ist, als ein lumpiges Y = G * (a + b .... g) und sich in 2 VHDL Zeilen formulieren liesse und auch mit 4-5 Takten bauen liesse, funktioniert aber nur so:
Der Knackpunkt dabei ist der Zeitpunkt des Zuführens des Gain-Wertes, sowie die Länge der pipeline. Wenn man das verändert, müsste man auch im MIDI-FPGA die Adresse ändern, weil sonst die Kanäle nicht stimmen. Und wer eine andere pipeline-Länge als n*4 benutzt, rotiert das sample in den falschen cluster und bekommt Rauschen. Und dann gibt es da noch die ominöse pass-throug-Kette mit den input delays und output delays: Die bäckt die Synthese hier auf 3 (-> wirkt als 7) zusammen. Bei minimal geändertem Timing anderer Komponenten, müssen hier andere Werte rein. Wenn man aber nicht vorgibt, wie die Strategie dafür auszusehen hat (steht bei mir in einem Excel) rotieren die Kanäle auch falsch und nix geht mehr.
Dieses file ist im Übrigens mit die kleinste Komponenten in meinem Synth von rund 300.
Eine Funktion aus der Komponente zu schätzen mag noch gehen, aber ein Gesamtsystem über mehrere FPGAs, die zudem noch mit einer Treibersoftware eingestellt werden müssen, ist nicht zu durchschauen, wenn man nicht alle Komponenten offen liegen hat.
Schnelle Serializer: Hier im Wald gabs mal ne Firma, die mit im Grund
Harddisk-Köpfen non-intrusiv den PCB-Datenverkehr mitgelesen hat.
fehlt da noch ein Wort im Satz?
Was Serializer angeht, ist es eine Frage der Signalführung und Abschirmung. Die sind ja durchaus störempfindlich und erfordern ein entsprechendes Layout des PCB. Wenn man da richtig baut, ist die Reichweite arg begrenzt. Das sehe ich ehrlich gesamt nicht, daß man das so ohne Weiteres abhören kann, besonders nicht, wenn mehrere Leitungen parallel liegen und auf ähnlichem Spektrum funken. Da muss man schon an das PCB ran. Nur Code an Claude schicken ist da nicht.
Und dann kommt die nächste Herausforderung:
Eine Entschlüsselung ist dann gut möglich, wenn man einen ausreiched langen Zeitraum auf einen genügend kurzen Code anwendet und auch ungefähr weiß, was da kommt. Die üblichen b8b10 sind in der Tat sehr einfach zu erkennen, zu taggen und auch dekodiert aufzuzeichnen. Ab dann muss man Bytes analysieren. Bei 64b66b macht es schon mal die Länge: Mehr Daten, längere Schlüssel -> mehr Zeitbedarf.
Dann kommen wechselnde Schlüssel per KeyShift -> mehrere Analysekanaäle gefordert -> ein vielfaches mehr Zeit.
Andere ungewöhnliche Leitungscodes wie 64b67b, oder wechselnde 63b68b+65b68b wird nochmal schwerer, da mehrere Coding-Ansätze benötigt werden, um erstmal den Code an sich als solchen Spezialcode zu erkennen und dann überhaupt erst einmal richtig zu verarbeiten. Das ist auch technisch eine Herausforderung. Die Transceiver in FGPAs z.B. kommen damit nicht direkt klar. U.u. braucht es dann spezielle HW, u.a. wegen CDR und den benötigten PLL-Frequenzen.
