Cybersicherheit

Die Chip-Sicherheit wechselt von der Compliance zur kontinuierlichen Abwehr

Eine Diskussion unter Experten von Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics und Synopsys kommt zu dem Schluss, dass Chip-Sicherheit keine Funktion mehr ist, die am Ende des Designs hinzugefügt wird, und auch keine Zertifizierung zur Erlangung der Marktzulassung. Die Ausweitung der Angriffe über eingebettete Software, FPGAs, Netzwerke und Chiplets erfordert eine kontinuierliche Sichtbarkeit der Komponenten, eine Nachverfolgung von Schwachstellen und eine Überwachung nach der Markteinführung.

2026-08-26
7 Min. Lesezeit
10 Aufrufe
فريق تحرير certi.news
Die Chip-Sicherheit wechselt von der Compliance zur kontinuierlichen Abwehr

Die Absicherung eines Chips ist keine Frage mehr einer abschließenden Überprüfung oder einer Zertifizierung, die dem Produkt vor der Markteinführung beigefügt wird. Sie ist vielmehr zu einem Prozess geworden, der sich vom Design über die Bereitstellung bis zur Überwachung erstreckt. Dies ist die wichtigste Schlussfolgerung aus einer geschlossenen Diskussionsrunde, die Semiconductor Engineering während der Design Automation Conference veranstaltete und an der Experten von Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics und Synopsys teilnahmen. Dieser Beitrag stützt sich auf Auszüge aus dieser von Ann Mutschler moderierten Diskussion.

Die Angriffsfläche wächst mit der Verbreitung von künstlicher Intelligenz, Chiplets, softwaredefinierten Systemen, FPGAs und vernetzten Systemen. Das Risiko beschränkt sich daher nicht auf einen physischen Defekt in der Schaltung oder einen Angriff auf den Chip selbst. Es kann vom Netzwerk, von eingebetteter Software oder von einer programmierbaren Schicht ausgehen und anschließend eine Schwachstelle ausnutzen, um auf das System zuzugreifen oder es zu stören.

Von der Zertifizierung zur tatsächlichen Nutzung

Yathiendra Vunnam von Cadence wies darauf hin, dass viele Kunden eine mehrschichtige Verteidigung einsetzen, unter Verwendung von Mechanismen wie IPsec und MACsec über verschiedene Ebenen des OSI-Modells hinweg, um Anforderungen an Leistung und Rechenkapazität zu erfüllen. Er erläuterte jedoch auch, dass sich einige Unternehmen auf die Zertifizierung konzentrieren, weil sie ihnen beim Verkauf des Produkts hilft, und anschließend den erforderlichen Schutzumfang reduzieren, um ein kleineres, kostengünstigeres und wiederverwendbares Design zu erreichen.

Das Problem besteht laut Scott Best von Rambus darin, dass der Besitz einer Schutztechnologie nicht deren korrekte Anwendung belegt. Ein Kunde kann Schutz vor Seitenkanalangriffen oder Fault-Injection-Angriffen oder eine PUF-Technologie verlangen und diese Elemente anschließend als erledigte Punkte auf einer Anforderungsliste behandeln, ohne zu klären, wie sie in das endgültige System integriert und darin verwendet werden. Dasselbe gilt für die Einhaltung von Rahmenwerken wie CRA und ISO 26262 oder den Erhalt von CSIP Level 3 von Keysight oder einem Wettbewerber.

Das bedeutet nicht, dass Zertifizierungen oder Standards wertlos sind. Es bedeutet vielmehr, dass sie allein keinen ausreichenden Beleg dafür liefern, dass ein Produkt unter realen Betriebsbedingungen sicher ist. Die von den Teilnehmern hervorgehobene Lücke besteht im Unterschied zwischen dem Vorhandensein eines Sicherheitsmechanismus auf dem Papier und seiner Fähigkeit, nach der Integration mit der übrigen Hardware, Software und den Netzwerken tatsächlich zu funktionieren.

Die Sichtbarkeit beginnt mit der Komponentenliste

Alexander Petr von Keysight EDA sagte, dass moderne Systeme auf übereinanderliegenden Ebenen aufgebaut werden: ein Chip, dann ein Package, eine Platine, ein System und schließlich ein vernetztes Ökosystem aus Rechenzentren und weitläufigen Netzwerken. Da immer mehr Funktionen in eingebettete Software verlagert werden, ist die Kenntnis darüber, was in ein Produkt gelangt, eine Voraussetzung für die Nachverfolgung von Risiken.

Dazu gehört die Erstellung einer Softwareliste für Hardwarekomponenten, oder, wie Petr es formulierte, die Bedeutung einer Software Bill of Materials for hardware, ergänzt durch die Nachverfolgung von Schwachstellen und die Überwachung nach der Markteinführung. Die Schwierigkeit nimmt bei Open-Source-Software zu, da Petr auf Versuche böswilliger Akteure hinwies, in Open-Source-Communities einzudringen und Hintertüren einzuschleusen. Auch die Entdeckung einer Zero-Day-Schwachstelle reicht nicht aus. Ein Unternehmen muss zunächst wissen, ob sein System die betroffene Komponente verwendet, und anschließend, ob es in der Lage ist, sie zu reparieren oder eine geeignete Abwehr zu entwickeln.

Die Chiplet-Architektur bringt eine weitere Herausforderung hinzu. Die Möglichkeit, Einheiten aus unterschiedlichen Quellen zusammenzusetzen, kann die Kosten senken, da nicht jeder Block zwingend die fortschrittlichsten Knoten benötigen muss. Sie wirft jedoch eine praktische Frage auf: Wie überprüft der Designer die Sicherheit jedes Chiplets, und wie stellt er sicher, dass die am wenigsten sichere Einheit nicht das gesamte System gefährdet?

Regulierung erhöht das Bewusstsein, garantiert aber kein Verhalten

Die Teilnehmer waren sich einig, dass Vorschriften, darunter der europäische Cyber Resilience Act CRA, das Bewusstsein erhöht und einige Unternehmen zu Investitionen in Vertrauensanker und eingebettete Schutzmechanismen veranlasst haben. Chris Giles von Siemens EDA sagte, dass die Existenz des Gesetzes nicht ausreiche, da eine Durchsetzung notwendig sei, um die Anforderungen in kontinuierliche Investitionen zu überführen. Die Teilnehmer erwähnten, dass der für Halbleiter relevante Termin der 11. September 2026 ist, wobei weiterhin Fragen dazu bestehen, was offengelegt werden muss und wie dies praktisch umgesetzt werden soll.

Mohit Arora von Synaptics wies außerdem darauf hin, dass die Sanktionen bis zu 4 % des Jahresumsatzes betragen können. Reed Hinkel von Synopsys vertrat unterdessen die Ansicht, dass diese Art von Druck begonnen habe, Unternehmen, die zuvor gezögert hatten, dazu zu bewegen, einen großen Vertrauensanker auf dem Chip zu implementieren oder Ansätze des Open Compute Project wie Caliptra zu übernehmen. Die Diskussion zeigte jedoch, dass die Auswirkungen der Vorschriften auf das Verhalten noch nicht geklärt sind. Giles sagte, der CRA sei in den Gesprächen sehr präsent, er sei sich jedoch nicht sicher, ob er die Praktiken verändert habe. Petr wies darauf hin, dass bis zum Zeitpunkt der Diskussion keine Geldstrafen verhängt worden seien.

Was ändert sich praktisch?

Der erforderliche Wandel besteht nicht nur darin, zusätzliche Sicherheitstools oder Sicherheits-IP zu kaufen. Vielmehr muss die Verantwortung über die Teams für Design, Software, Produktmanagement und Betrieb hinweg verteilt werden. Je höher der Wert der Dienstleistung ist, die ein Produkt erbringt, desto höher sind die Kosten eines Sicherheitsversagens und die damit verbundene Haftung. Daher meinte Hinkel, dass Versprechen hinsichtlich hochwertiger Dienstleistungen mit der tatsächlichen Fähigkeit einhergehen müssten, Service-Level-Agreements einzuhalten und auf Schwachstellen zu reagieren.

Auch kommerzielle und militärische Anreize kamen in der Diskussion zur Sprache. Produkte, die das Vertrauen der Nutzer genießen, können größere Sicherheitsinvestitionen rechtfertigen. Ebenso treibt der Bedarf des US-Verteidigungsministeriums und seiner Zulieferer, darunter Boeing und Airbus, wie in der Diskussion erwähnt, einen Teil der Investitionen in diesem Bereich voran. Das hebt die Einschränkungen jedoch nicht auf: Sicherheit steht stets im Wettbewerb mit Kosten und Markteinführungstermin, und die Zertifizierung lässt sich möglicherweise weiterhin leichter messen als die Qualität der Bereitstellung und Überwachung.

Zur Post-Quanten-Kryptografie erklärte Hinkel, dass die Herausforderung nicht auf Hardware oder Firmware beschränkt sei, sondern sich auch auf Public-Key-Acceleratoren PKA erstrecke, die historisch auf übereinandergelagerten Schichten aufgebaut worden seien und sich nur schwer aktualisieren und erweitern ließen. Laut der Diskussion müssen Produkte die neuen Algorithmen innerhalb von drei Jahren unterstützen, während die Abschaffung der alten Algorithmen an einen Zeitraum von fünf Jahren geknüpft ist. Dies deutet darauf hin, dass die Vorbereitung auf die Post-Quanten-Kryptografie eine architektonische Neuordnung erfordert und nicht nur das Hinzufügen eines Algorithmus zu einem bestehenden Design.

Die wichtigste Erkenntnis für technische Leser lautet, dass nachweisbare Sicherheit das umfassen muss, was sich im Produkt befindet, wie es integriert wurde und wie es nach dem Verkauf überwacht werden soll. Die Zertifizierung bleibt dabei ein Prüfpunkt innerhalb dieses Prozesses, nicht dessen Ersatz. Die Einzelheiten der regulatorischen Durchsetzung, die Grenzen der Offenlegung von Schwachstellen und die Fähigkeit der Unternehmen, weit verbreitete Produkte im Markt zu behandeln, bleiben offene Fragen, die von der Quelle nicht geklärt wurden.

Nachrichtenquelle
Semiconductor Engineering
Originalquelle öffnen ↗
ف
Autor

فريق تحرير certi.news

Aus derselben Kategorie

Das könnte Sie interessieren

Alle Nachrichten anzeigen