RISC-V-Prozessoren vor Cyberangriffen und Trojanern schützen

Aktuelle Prozessorkerne sind oft Bestandteil in anwendungsspezifischen integrierten Schaltungen (ASICs) oder FPGAs (Field Programmable Gate Arrays) und übernehmen dort wesentliche Steuerungs- und Datenverarbeitungsfunktionen. Die Befehlssatzarchitektur (Instruction Set Architecture, ISA) der Prozessoren bildet die Schnittstelle zwischen Hardware und Software und sorgt für die Flexibilität und Programmierbarkeit der benötigten Funktionen.

Bild 1: Die CVE-MITRE-Datenbank verzeichnete 2015 6488 Schwachstellen, 43 Prozent davon klassifiziert als softwaregestützte Hardwareschwachstellen. 2018 kamen Meltdown und Spectre dazu, Schwachstellen auf dem Prozessor. DARPA, OneSpin

Die RISC-V-Open-Source-ISA wird bei fortgeschrittenen elektronischen Systeme immer häufiger eingesetzt, da sie es Entwicklern erlaubt, hochgradig kundenspezifische Erweiterungen hinzuzufügen. Die wachsende Akzeptanz von RISC-V fördert auch das Ökosystem von Werkzeugen, Software und Fachwissen, was wiederum die Verbreitung in einer immer größeren Palette von Anwendungen vorantreibt. Darüber hinaus fallen keine Lizenzkosten oder Nutzungsgebühren an, so dass ein größerer Kreis an Unternehmen innovative und zugleich erschwingliche Produkte entwickeln kann. Diese Entwicklung lässt sich auch schon im Bereich des IoT und der tragbaren Geräte mit künstlicher Intelligenz beobachten.

SoC-Integratoren verwenden häufig Open-Source- oder RISC-V-Prozessor-IPs von Drittanbietern. Diese Designs und die zugehörigen Toolchains lassen sich durch kundenspezifische Befehle ergänzen. Eine mit dem IP bereitgestellte qualitativ hochwertige Verifikationsumgebung und zusätzliche Tests auf Systemebene können eine gewisse Sicherheit geben, dass das IP keine kritischen Fehler aufweist. Leider reicht dies für viele Anwendungen nicht aus, und es sind noch andere ernsthafte Risiken zu berücksichtigen. Dabei ist erwähnenswert, dass in Open-Source-Hardware gefundene Fehler und Schwachstellen von der Open-Source-Gemeinschaft gemeldet und gewartet werden (ähnlich wie bei einer Crowdsourcing-Aktivität).

Sicherheitslücken in der Hardware

Traditionell wurden Sicherheitslücken in elektronischen Systemen mit Problemen auf der Systemebene und in der Software in Verbindung gebracht. In jüngerer Zeit sind auch Hardware-IPs, und hier vor allem Prozessoren, in den Fokus gerückt (Bild 1). Prozessorimplementierungen verwenden Pipeline-basierte Mikroarchitekturen und enthalten häufig Funktionen zur Leistungs- und Energieoptimierung. Die damit einhergehende Komplexität erhöht nicht nur das Risko für funktionale Fehler, sondern auch für Sicherheitslücken. Die Sicherheitsforscher, die Anfang 2018 die Meltdown- und Spectre-Angriffe entdeckten, haben aufgezeigt, dass Leistungsoptimierungsfunktionen in Prozessoren zweckentfremdet und für schädliche Zwecke einsetzbar sind. Seitdem sind viele Schwachstellen sowohl in High-End- als auch in Low-End-Prozessoren entdeckt worden. Seitenkanal- und Transient-Execution-Angriffe können in sichere Enklaven eindringen und es böswilligen Anwendungen ermöglichen, vertrauliche Daten auszuspähen oder sogar die Kontrolle über das System zu übernehmen. Und im Gegensatz zu Softwareproblemen lassen sich Hardwareprobleme nicht einfach mit Over-the-Air-Updates beheben. Ihre Umgehung mit Hilfe von Software zieht zudem häufig schwere Leistungseinbußen nach sich.

Bei RISC-V-Kernen sind eingeschleuste, bösartige Logikelemente oder Hardwaretrojaner selten, können aber deutlich höheren Schaden anrichten. Ein Hardwaretrojaner ist eine vom Angreifer getarnte logische Funktion, die nur unter speziellen Umständen aktiv wird. Dabei wird die Trojanerlogik durch eine bestimmte Abfolge von Daten- und Steuerereignissen ausgelöst, die im vom Designer vorgesehenen Normalbetrieb nicht auftritt und die nur dem Angreifer bekannt ist. Einmal aktiviert sorgt der Trojaner für schädliche Nutzlast, gibt geheime Daten preis oder korrumpiert das Systemverhalten im kritischen Maße. SoC-Integrationen mit Open-Source- oder RISC-V-Cores von Drittanbietern können dieses Risiko nicht länger ignorieren.

Allerdings stellt es schon eine Herausforderung dar, sicherzustellen, dass ein Prozessor fehlerfrei arbeitet. Zu garantieren, dass er ausschließlich nur die Dinge tut, die er tun soll, ist eine noch anspruchsvollere Aufgabenstellung, die derzeit noch weitgehend ungelöst ist. Sicherheitskritische Systeme und Systeme, bei denen der Schutz der Privatsphäre an erster Stelle steht, benötigen effiziente, qualitativ hochwertige Lösungen, die dem Risiko von Sicherheitslücken und Trojanern entgegenwirken.

Intelligente Hardwareabsicherung

Bild 2: Die Verifikation der funktionalen Korrektheit schafft Vertrauen, dass sich eine Prozessorimplementierung wie spezifiziert verhält und die Anforderungen des Endanwenders erfüllt. OneSpin

Die Gewährleistung des Vertrauens und der Sicherheit der RISC-V-IPs erfordern innovative und effiziente technische Lösungen, die komplementär zu den Ansätzen der funktionalen Korrektheit sind, mit der in erster Linie die vorgesehenen Anwendungsfälle des IP abgesichert sind (Bild 2). IP-Anbieter sind für die Anwendung von Vertrauens- und Sicherheitsüberprüfungsverfahren nach dem neuesten Stand der Technik verantwortlich. Daneben sollten IP-Integratoren Zugang zu unabhängigen Absicherungslösungen haben, die schnell und ohne tiefgreifende Kenntnisse der IP-Implementierungsdetails einsetzbar sind.

Formale Methoden können Hardwarefunktionen umfassend analysieren und den Nachweis erbringen, dass das IP oder SoC genau das erwartete, meist mit System-Verilog-Assertions beschriebene, Verhalten zeigt. Die formale Verifikation von Hardware mittels kommerzieller Model-Checker hat sich seit zehn Jahren auf breiter Front durchgesetzt. Üblicherweise haben IP-Provider und SoC-Integratoren formale Verifikationsexperten in ihren Teams, um das Risiko zu minimieren, funktionale Fehler zu übersehen. Während bestimmte wohldefinierte formale Verifikationsaufgaben durch Apps automatisierbar sind, ist im Allgemeinen ein erheblicher technischer Aufwand erforderlich, um das erwartete Verhalten des IP mit Hilfe von Assertions zu erfassen. Darüber hinaus gibt es keine Garantie dafür, dass genügend Assertions erstellt worden sind. Undokumentierte Funktionen oder unbeabsichtigte Lücken im Assertions-Satz könnten dazu führen, dass IP-Funktionalität unverifiziert bleibt.

Unabhängige Absicherungslösungen mit RISC-V

Der Open-Source-Charakter von RISC-V ermöglicht die Entwicklung von vorgefertigten, unabhängigen Absicherungslösungen. Die RISC-V-Integritätsverifikationslösung von OneSpin lässt sich zum Beispiel auf eine Vielzahl von Mikroarchitekturen anwenden. Es enthält Modelle der RISC-V-ISA und Privileged ISA, die erweiterbar sind und für kundenspezifische Befehle nutzbar sind. Ein entscheidender Aspekt dieser Lösung ist, dass sie auf dem Gap-Free-Verification-Prozess von OneSpin basiert, der einen belastbaren Beweis dafür liefert, dass der Assertions-Satz, der die RISC-V ISA modelliert, vollständig und lückenlos ist. Dieser Aspekt ist von größter Bedeutung, wenn die Erkennung von Hardware-Trojanern oder undokumentierter Logik ein zentrales Ziel ist. Die Lösung ermöglicht es auch SoC-Integratoren mit begrenztem Fachwissen über RISC-V und die untersuchte RTL-Implementierung, Vertrauen in die Qualität und Vertrauenswürdigkeit des IP zu gewinnen. IP-Entwickler können damit Sicherheitsschwächen und Funktionsfehler vor der Freigabe aufdecken.

Funktioniert die Integritätsabsicherung bei RISC-V?

Der im vorstehenden Abschnitt beschriebene RISC-V-Integritätssicherungsprozess wurde bereits bei mehreren RTL-Designs erfolgreich eingesetzt. Edaptive Computing, ein Unternehmen, das fortschrittliche Lösungen zur schnellen Optimierung, Absicherung und Automatisierung von System-of-Systems und von Prozessen für eine Vielzahl an Anwendungen integriert, hat das Verfahren beispielsweise auf den Rocket Core angewandt. Der Rocket Core ist ein quelloffener, produktionsreifer 64-Bit-RISC-V-Kern mit einem virtuellen 39-Bit-Speichersystem. Er verfügt über eine fünfstufige Pipeline, bei der ein Befehl pro Zyklus (single issue) und gemäß der programmierten Reihenfolge (in-order) bearbeitet wird. Befehle mit langen Latenzzeiten, wie eine Division, lassen sich dabei auch außer der Reihe fertig bearbeiten (out-of-order completion). Die Pipeline unterstützt die fortschritllichen Features Sprungvorhersage (branch prediction) und Befehlswiederholung (instruction replay; bei einem Fehler wird an die letzte, als korrekt bekannte Pipelinestufe gesprungen).

Bild 3: Liste der Probleme, die von OneSpins RISC-V-Integritätsverifikationslösungen erkannt und im Rahmen des GitHub Rocket-Core-Projekts veröffentlicht wurden. OneSpin

Die RISC-V-Integritätsverifikationsslösung wurde auf den Entwurf mit allen Befehlen, Privilegierungsstufen, Interrupts sowie Ausnahmemechanismen angewendet. Sie fand acht Probleme (siehe Bild 3). Drei von ihnen sollen im Folgenden näher beleuchtet werden:

• Division Corner-case: Dabei handelte es sich um einen tief im RTL-Code versteckten Fehler, der im Zusammenhang mit der Out-of-order Completion des Divisionsbefehls stand. Dieses Problem hätte bewirken können, dass ein Softwareprogramm, das die Divisionsoperation verwendet, falsche Ergebnisse berechnet und zu einem Fehlverhalten des Systems führt. Es tritt nur bei einer Kombination mehrerer oder seltener Umstände auf und wurde deshalb bei vorhergehenden Verifikationsdurchgängen übersehen.
• Wiederholung eines illegalen Befehls: Dieser Fehler tritt nicht nur unter außergewöhnlichen Randbedingungen auf ist daher kein Croner-case. Die Wiederholung eines illegalen Befehls kann Verarbeitungszyklen verschwenden. Die negativen Auswirkungen auf die Leistung sind zwar vernachlässigbar, wenn dies nur selten geschieht. Es gibt jedoch noch andere Aspekte zu berücksichtigen. Die Wiederholung eines Befehls kann unnötige Speicherzugriffe verursachen. Diese Zugriffe können Nebenwirkungen haben, die bei Seitenkanalangriffen zum Einsatz kommen können. Infolgedessen muss dieses Verhalten entweder beseitigt oder klar verstanden und dokumentiert werden.
• Undokumentierter Befehl: Es wurde ein nicht dem Standard entsprechender und undokumentierter Befehl mit der Bezeichnung Cease identifiziert, der den Kern anhält. Er kann dazu führen, dass sich der RISC-V-Rocket-Core anders verhält als gedacht. Undokumentierte, versteckte Funktionen sind nicht akzeptabel, wenn auf Vertrauen und Sicherheit Wert gelegt wird, selbst dann, wenn sie sich auf Anwendungsfälle beziehen, die für die spezifische Endanwendung als nicht relevant erachtet werden.

Ausblick

Der in diesem Artikel vorgestellte RISC-V-Absicherungsprozess erkennt Szenarien, die die Sicherheit beeinträchtigen können, und enthüllt systematisch undokumentierte Funktionen und Hardwaretrojaner, die das Verhalten des Prozessors beeinflussen, unabhängig davon, wie selten und gut versteckt sie sind. Seitenkanäle werden jedoch nicht systematisch erkannt. Die vollständige Erkennung aller potenzieller Seitenkanäle erfordert eine dedizierte Lösung mit entsprechender Technik. Es gibt bereits Prototypen für diese Lösung. Prozessorkerne sind wesentliche Bestandteile eingebetteter Systeme. Ein typisches SoC schließt jedoch viele andere IPs ein, die ebenfalls Hardwaretrojaner enthalten können. Anders als bei RISC-V-Kernen sind unabhängige Lösungen zur Vertrauensabsicherung möglicherweise nicht ohne weiteres verfügbar. In diesem Fall wäre ein automatisiertes, einfaches Verfahren zur Vertrauensbewertung wertvoll, das auf jedes IP anwendbar ist. Ein Prozess ohne vertrauenswürdiges IP-Modell kann die Abwesenheit eines Trojaners nicht gewährleisten. Es ist jedoch möglich, ungewöhnliche und verdächtige Codemuster und bekannte Trojanersignaturen sowie Schwachstellen zu identifizieren, die in späteren Entwicklungsstadien für betrügerische Zwecke ausnutzbar sind.

(na)