Wie man die Anforderungen von IEEE 1735 erfüllt (und übertrifft!)

Letzten Monat erhielt ich eine E-Mail mit einem Anwerbeangebot von jemandem, der behauptete, Senior Recruiter bei Workday zu sein.

Professionell. Persönlich. Keine Tippfehler. Mein Vorname in der Betreffzeile, damit alle E-Mail-Filter umgangen werden.

Ich habe nicht geantwortet. Ich habe die Absenderdomain überprüft: `hiring-workday.co`.

Nicht `arbeitstag.com`. DNS-Einträge zeigten, dass das Mail-Routing über `emx.mail.ru`. Rohe SMTP-Header bestätigten Ursprung bei `send35.i.mail.ru [89.221.237.130]`, ein russischer Relay-Server, um 1:23 Uhr Moskauer Zeit. DKIM-Selektor: `mailru`. DMARC-Richtlinie: `p=NONE`. Cloudflare-Proxy, TTL 0 für jeden Datensatz. Speziell entwickelte Infrastruktur für die Zustellung und anschließende Anonymisierung.

Der Text wurde höchstwahrscheinlich von einer KI generiert. Ich weiß das, weil ein Personalvermittler, der mein Profil tatsächlich gelesen hätte, etwas daraus erwähnt hätte. Stattdessen wurden vier Datenpunkte von LinkedIn – Name, Titel, Branche, Standort – in eine Vorlage eingespeist und gleichzeitig auf Tausende von Zielen angewendet. Die Personalisierung ist die Angriffsfläche. Die Infrastruktur ist der verräterische Hinweis.

Systeme werden allzu oft nicht mit Blick auf den tatsächlichen Angreifer entwickelt. Das LinkedIn-Profil wurde für die manuelle Kontaktaufnahme durch Personalverantwortliche konzipiert. Heute nutzen Angreifer automatisierte Prozesse in großem Umfang und setzen KI ein, um öffentliche Daten in missbrauchtes Vertrauen umzuwandeln. Diese Diskrepanz zwischen dem vom System angenommenen Angreifer und dem tatsächlich agierenden Angreifer ist nicht auf soziale Plattformen beschränkt. Sie stellt das grundlegende Versagen von Sicherheitssystemen in allen Bereichen dar.

Dies brachte mich auf die Idee, über den Präzedenzfall IEEE P1735 – Recommended Practice for Encryption and Management of Electronic Design Intellectual Property – nachzudenken, einem Standard, der zum Schutz von Hardware-Design-IP wie HDL-Code für Verilog/VHDL in der Halbleiter-Lieferkette entwickelt wurde.

Im Jahr 2017 veröffentlichten Chotaray, Nahiyan, Shrimpton, Forte und Tehranpoor „Standardizing Bad Cryptographic Practice“ und widerlegten damit den IEEE-Standard 1735-2014. Eine 2021 veröffentlichte Arbeit von Spieth, Schweins, Ender, Fyrbiack, May und Paar demonstrierte die vollständige Wiederherstellung privater Schlüssel aus Produktionsimplementierungen bei Intel, Cadence, Siemens, Lattice und anderen Unternehmen.

Der Standard verwendete AES-CBC mit RSA-Schlüsselübertragung. Die Kryptografie war nicht die Schwachstelle, sondern wohl das Bedrohungsmodell. P1735 stufte das EDA-Tool als vertrauenswürdig ein. Es modellierte den Angreifer als passiven IP-Nutzer, der versucht, eine geschützte Datei im Ruhezustand zu lesen. Es modellierte keinen Angreifer, der die Ausführungsumgebung kontrolliert, dem Tool manipulierte Chiffretexte als Eingaben zuführen und dessen Fehlerausgaben systematisch auslesen kann.

Da der Standard AES-CBC ohne Authentifizierung auf Datenblockebene vorschrieb und EDA-Tools explizit dazu aufforderte, beschreibende Syntaxfehler während der Verarbeitung zurückzugeben, wurde das Tool selbst zum Entschlüsselungsorakel. Die eigene Usability-Richtlinie des Standards – „Qualitätsfehlermeldungen spiegeln die Qualität des geschützten geistigen Eigentums wider“ – diente als Angriffsvektor. (Anmerkung: Die Empfehlungen berücksichtigten nicht CWE 209 – Informationspreisgabe durch Fehlermeldungen). Die Veröffentlichung von 2021 ging noch weiter: Sie fand bereits in EDA-Tool-Implementierungen eingesetzte RSA-basierte White-Box-Kryptografieverfahren. Dies belegt, dass die Branche die Man-at-the-End-(MATE)-Bedrohung unabhängig erkannt und White-Box-Kryptografie (WBC) als Lösung gewählt hatte, jedoch ohne die notwendige Laufzeitintegritätsschicht, um die Implementierung vor einem Angreifer im Ausführungsumfeld zu schützen.

Die Forscher kamen zu dem eindeutigen Schluss: Die Schwächen des IEEE-1735-Standards lassen sich angesichts des heutigen Hardware-Designprozesses nicht allein durch kryptografische Lösungen beheben. Jeder Schutzansatz, der etwas anderes annimmt, scheitert an der Grenze, die er nicht modelliert hat.

Die KI-gestützte Rekrutierungs-E-Mail und IEEE 1735 haben eine gemeinsame Ursache: Der Schutz wurde gegen den falschen Angreifer in der falschen Umgebung evaluiert. IEEE 1735 ging von einem passiven Leser aus, der tatsächliche Angreifer manipulierte jedoch die Ausführungsumgebung. 

 LinkedIn-Profile setzen voraus, dass ein menschlicher Leser manuell Kontakt aufnimmt, doch der Angreifer nutzt eine automatisierte Pipeline: Daten sammeln, klassifizieren, generieren und massenhaft ausliefern. Das LLM ist das EDA-Tool, der menschliche Posteingang das Orakel, und der extrahierte Klartext ist Vertrauen, nicht HDL.

Dies ist heutzutage der vorherrschende Fehlermodus bei der Beschaffung von Anwendungssicherheit.

Was dies für die Auswahl von Sicherheitslösungen bedeutet

Bei der Bewertung von Sicherheitsprodukten für öffentlich vertriebene Software prüfen Entwickler die Compliance-Abdeckung, die Integrationskomplexität und den Leistungsaufwand. Folgende Fragen werden dabei üblicherweise nicht berücksichtigt:  
(1) Was setzt dieser Schutz voraus, was der Angreifer nicht tun kann, und  
(2) Sind die Annahmen noch gültig, wenn der Angreifer über KI-gestützte Werkzeuge, vollen Zugriff auf die Ausführungsumgebung und ein unbegrenztes Abfragebudget verfügt? 
 
Eine Schutzarchitektur, die das richtige Bedrohungsmodell nicht berücksichtigt, d. h. Man-at-the-End oder Man-in-the-Client, bei dem der Angreifer die Kontrolle über das System hat, Gerät Die Software, auf der die Software läuft, versetzt sich in die gleiche Lage wie IEEE 1735. Die Kryptographie könnte sein Stimmt. Die Annahme der Abgrenzung ist falsch. Ein Angreifer, der sich bereits in der Ausführungsumgebung befindet, interagiert nicht mit dem AnwendungDie Art und Weise, wie der Schutz konzipiert wurde, führt in der Regel zu gravierenden Problemen.  
 
Die Antwort, auf die sich die Halbleiterindustrie schließlich geeinigt hat, ist White-Box-Kryptographie zum Schutz von Schlüsseln in einer feindlichen Ausführungsumgebung, kombiniert mit Integritätsprüfung zur Laufzeit, um aktive Manipulationen zu erkennen und darauf zu reagieren. Dies ist dieselbe Architektur, die dazu gehört at Die mobile Anwendungsschicht. Nicht als bloße Pflichterfüllung. Sondern als direkte Reaktion auf eine Bedrohung. Modell Der Standard wurde verfehlt. 
 
Ross Anderson argumentierte 1993 in „Warum Kryptosysteme versagen“" dass Sicherheitslücken selten kryptografischer Natur sind. Leistungsumfang dass die Mathematik stimmt, aber das Bedrohungsmodell und Die Annahmen über den Angreifer, seinen Zugriff und seine Umgebung erweisen sich als falsch. Andersons Karriere hat gezeigt, dass diese Annahmen zu technisch konformen, aber operativ fehlerhaften Systemen führen. IEEE 1735 und die KI-gestützte Rekrutierungspipeline, die auf LinkedIn-Profile abzielt, sind Beispiele dafür. 
 
Bevor Sie eine Sicherheitslösung für eine öffentlich verbreitete Anwendung freigeben, stellen Sie sich eine Frage: Gibt es Software-Schutzmechanismen, die alles abdecken, was ein Angreifer nicht tun kann? 
 
Wenn die Antwort nicht schriftlich festgehalten wird, wurde das Bedrohungsmodell nicht erstellt. 
 
Wenn yoSie möchten über Ihre IEEE 1735 oder andere White-Box-KryptoGrafikbedarf mit einemDrei, kontaktiere uns werden auf dieser Seite erläutert: https://digital.ai/why-digital-ai/contact/

Referenzen

Anderson, RJ (1994). Warum Kryptosysteme versagen  
https://doi.org/10.1145/188280.188291 
 
Chhotaray et al., „Standardisierung schlechter kryptographischer Praktiken“ https://doi.org/10.1145/3133956.3134040 
 
Speith et al., „Wie man sein geistiges Eigentum NICHT schützt“  
https://doi.org/10.1109/SP46214.2022.9833605 
 
https://cwe.mitre.org/data/definitions/209.html