Vertrauenswürdigkeit im Prozessor-Design: Best Practices für sichere und zuverlässige ICs

Moderne integrierte Schaltungen (ICs) liefern die Rechen- und Systemsteuerungsfähigkeiten, um enorme Datenmengen zu verarbeiten, sicherheitskritische Entscheidungen in Echtzeit zu treffen und sensible Daten zu schützen. Das Design eines anwendungsspezifischen ICs (ASIC) oder FPGA-System-on-Chip (SoC) von Grund auf wäre prohibitiv teuer und zeitaufwändig. Viele kritische Funktionen werden daher mittels Third-Party Intellectual Properties (IPs) implementiert. Prozessor-Cores werden beispielsweise von spezialisierten Organisationen bezogen und bieten über ihre Instruction Set Architecture (ISA) eine flexible, software-programmierbare Funktion, die die Schnittstelle zwischen Hardware und Software definiert. Open-Source-Prozessorarchitekturen ermöglichen tiefere Prüfung und rigorose Sicherheitszusicherung in Systemen, die sich einer fluiden Bedrohungslage gegenübersehen. Dieser Artikel beschreibt einen Ansatz für Sicherheitszusicherung von IPs und SoCs basierend auf der RISC-V Open-Source-ISA.

RISC-V: Die erste industrietaugliche Open-Source-ISA

An der University of California erfunden und von der gemeinnützigen RISC-V Foundation verwaltet, ist RISC-V die erste Open-Source-ISA, die eine echte industrielle Wahl für ein breites Anwendungsspektrum geworden ist.

Das Ökosystem aus Tools, Software und Expertise ist robust und wächst stetig. Viele Einzelpersonen und Organisationen haben bereits Open-Source-Hardware-IPs gespendet, die die RISC-V ISA implementieren. Die OpenHW Group zielt beispielsweise darauf ab, die lang ersehnte Aussicht auf Open-Source-Hardware – insbesondere Prozessorkerne – für High-Volume-Chips zur Realität zu machen.

Der Aufstieg von RISC-V hat viele Gründe: Von Grund auf mit benutzerdefinierter Erweiterbarkeit konzipiert, erlaubt RISC-V ein neues Level an Hardware-Optimierung für spezifische Workloads. Da Moores Law sich verlangsamt, ist Customization entscheidend, um das Leistungsniveau zu halten, das technologische Fortschritte in der Halbleiterfertigung nicht mehr liefern können. Zudem ist die RISC-V-Architektur frei von Lizenzkosten und Royalties, was mehr Unternehmen ermöglicht, innovative, erschwingliche Produkte zu entwickeln. Vieles passiert im Bereich IoT und Wearables mit KI-Fähigkeiten.

Sicherheitsrisiken bei Third-Party RISC-V Cores

SoC-Integratoren nutzen häufig Open-Source- oder Third-Party-RISC-V-Prozessor-IPs. Diese Designs und ihre Toolchains können mit Custom Instructions erweitert werden. Eine hochwertige Verifikationsumgebung, die mit dem IP geliefert wird, und zusätzliche System-Level-Tests können Vertrauen geben, dass das IP keine kritischen Bugs hat. Für viele Anwendungen reicht das jedoch nicht aus, und es gibt weitere ernste Risiken.

Schwachstellen und Hardware-Trojaner

Traditionell wurden Sicherheitslücken in elektronischen Systemen mit System-Level- und Software-Problemen assoziiert. Kürzlich sind Hardware-IPs, insbesondere Prozessoren, ins Zentrum der Aufmerksamkeit gerückt (siehe Abb. 1). Prozessor-Implementierungen nutzen Pipeline-basierte Mikroarchitekturen und enthalten oft Performance- und Power-Optimierungsfeatures. Komplexität erhöht das Risiko, nicht nur funktionale Bugs, sondern auch Sicherheitslücken zu übersehen. Die Sicherheitsforscher, die 2018 Meltdown und Spectre entdeckten, zeigten, dass Performance-Optimierungsfeatures in Prozessoren für nefarious Zwecke missbraucht werden können. Seither wurden viele weitere Schwachstellen in High-End- und Low-End-Prozessoren entdeckt. Side-Channel- und Transient-Execution-Angriffe können sichere Enklaven durchbrechen und es böswilligen Applikationen ermöglichen, vertrauliche Daten zu leaken oder sogar die Systemkontrolle zu übernehmen. Im Gegensatz zu Software lassen sich Hardware-Probleme nicht einfach per Over-the-Air-Updates beheben. Die Behebung eines Hardware-Problems durch Software verursacht oft schwere Performance-Degradation.

Die RISC-V-Architektur bietet viele Features zur Implementierung sicherer eingebetteter Systeme. Die Privilege Specification definiert vier Privileg-Modi (Machine, Supervisor, Hypervisor, User). Custom Instructions und ISA-Erweiterungen im Ratifikationsprozess, wie die Kryptografische Erweiterung, bieten zusätzliche Sicherheitsfähigkeiten. Designer können mehrere sichere Enklaven implementieren, um Applikationen zu isolieren und Leckage sensibler Daten zu verhindern. Dennoch können RTL-Mikroarchitektur-Features noch Sicherheitslücken verursachen. Diese Risiken können nicht vollständig auf ISA-Ebene adressiert werden. Ein neuer erforschter Ansatz ist die Nutzung einer augmentierten ISA (aISA), um Aspekte der Instruktionsausführung auf Mikroarchitektur-Ebene zu definieren und beispielsweise den Zustand von Buffern oder Registern zu kontrollieren, die auf ISA-Ebene nicht sichtbar sind. RTL-Funktionsbugs könnten all diese Sicherheitsfeatures kompromittieren.

Ein weniger wahrscheinliches, aber weitaus schwerwiegenderes Risiko ist das Vorhandensein von bösartiger Logik oder Hardware-Trojanern im RISC-V-Core. Ein Hardware-Trojaner ist eine Logikfunktion, die absichtlich stealthy designed ist und nur unter sehr seltenen, dem Angreifer bekannten Umständen aktiviert. Eine spezifische Sequenz von Daten- und Control-Events, die im Ziel-Use-Case nicht auftreten würde, triggert die Trojaner-Logik, die dann ein schädliches Payload liefert – z. B. Leckage eines Secrets oder kritische Korruption des Systemverhaltens. SoC-Integrationen mit Open-Source- oder Third-Party-RISC-V-Cores können dieses Risiko nicht länger ignorieren.

Sicherzustellen, dass ein Prozessor tut, was er soll, ist schwer. Sicherzustellen, dass er nichts tut, was er nicht soll, ist eine noch größere Herausforderung, die weitgehend ungelöst ist. Sicherheitskritische Systeme und Systeme, bei denen Datenschutz oberste Priorität hat, brauchen effiziente, hochwertige Lösungen, die das Risiko von Sicherheitslücken und Trojanern adressieren.

Smart Hardware Assurance

Die Zusicherung von Vertrauen und Sicherheit von RISC-V IPs erfordert innovative, effiziente technische Lösungen, die funktionale Korrektheitsansätze ergänzen und primär die beabsichtigten Use Cases des IPs adressieren (siehe Abb. 2). IP-Anbieter sind verantwortlich für den Einsatz State-of-the-Art Trust- und Security-Verifikationsprozesse, während IP-Integratoren Zugang zu unabhängigen Assurance-Lösungen haben sollten, die schnell und ohne tiefes Wissen der IP-Implementierungsdetails deploybar sind.

Formale Methoden können Hardware-Funktionen exhaustiv analysieren und beweisen, dass das IP oder SoC exakt einem erwarteten Verhalten entspricht, oft in SystemVerilog Assertions erfasst. Hardware-Formalverifikation mit kommerziellen Model Checkern hat in den letzten zehn Jahren breite Adoption gefunden. Typischerweise haben IP-Anbieter und SoC-Integratoren Formalverifikations-Experten in ihren Reihen, die das Risiko fehlender funktionaler Bugs minimieren. Während bestimmte gut definierte Formalverifikationsaufgaben durch Apps automatisiert werden können, ist im Allgemeinen erheblicher Engineering-Aufwand nötig, um das erwartete Verhalten des IPs in Assertions zu erfassen. Zudem gibt es keine Garantie, dass genügend Assertions geschrieben wurden. Undokumentierte Funktionen oder unbeabsichtigte Lücken im Assertion-Set könnten zu unverifizierter IP-Funktionalität führen.

Die Open-Source-Natur von RISC-V ermöglicht die Entwicklung vorgepackter, unabhängiger Assurance-Lösungen. OneSpins RISC-V Integrity Verification Solution kann beispielsweise auf eine breite Palette von Mikroarchitekturen angewendet werden. Sie umfasst Modelle der RISC-V ISA und Privileged ISA, die erweiterbar sind und Custom Instructions aufnehmen können. Ein entscheidender Aspekt ist die Basis auf OneSpins GapFreeVerification™-Prozess, der einen rigorosen Beweis liefert, dass das Assertion-Set, das die RISC-V ISA modelliert, vollständig und lückenfrei ist. Dieser Aspekt ist von höchster Wichtigkeit, wenn die Erkennung von Hardware-Trojanern oder undokumentierter Logik ein entscheidendes Ziel ist. Die Lösung ermöglicht SoC-Integratoren mit begrenzter RISC-V- und RTL-Expertise, Vertrauen in Qualität und Vertrauenswürdigkeit des IPs zu gewinnen. IP-Entwickler können sie nutzen, um Sicherheitslücken und funktionale Bugs vor Release zu detektieren.

Funktioniert es? – RocketCore Fallstudie

Der beschriebene RISC-V Integrity Assurance Prozess wurde erfolgreich auf mehrere RTL-Designs angewendet. Edaptive Computing, ein Unternehmen, das innovative Lösungen integriert, um Systeme von Systemen und Prozesse für US-Verteidigungsministerium und kommerzielle Kunden zu optimieren, assurieren und automatisieren, hat den Prozess auf den RocketCore angewendet. Der RocketCore ist ein Open-Source, silicon-proven 64-Bit RISC-V Core mit 39-Bit-Virtual-Memory-System. Er hat eine 5-Stage, Single-Issue, In-Order Pipeline mit Out-of-Order-Completion für Long-Latency-Instruktionen wie Division. Er umfasst erweiterte Features wie Branch Prediction und Instruction Replay.

Die RISC-V Integrity Verification Solution wurde auf das Design angewendet mit allen Instruktionen, Privileg-Levels, Interrupts und Exception-Mechanismen, und 8 Issues wurden detektiert (siehe Abb. 3). Details zu 3 davon:

Division Corner-Case

Ein tiefes Corner-Case-Bug im Zusammenhang mit der Out-of-Order-Completion der Divisionsinstruktion. Dieser Issue könnte dazu führen, dass ein Softwareprogramm, das Division nutzt, inkorrekte Ergebnisse berechnet und zu System-Fehlverhalten führt. Der Issue tritt nur unter einer Kombination seltener Umstände auf, weshalb vorherige Verifikationsbemühungen ihn verfehlten.

Replay von illegaler Instruktion

Dies ist kein Corner-Case-Bug. Das Replayen einer illegalen Instruktion kann Prozessorkycles verschwenden, aber wenn es nur in seltenen Situationen passiert, ist der Performance-Impact vernachlässigbar. Es gibt jedoch andere Aspekte: Instruction Replay kann unnötige Memory-Requests verursachen. Diese können Side-Effects haben, die für Side-Channel-Angriffe genutzt werden könnten. Daher muss dieses Verhalten entweder eliminiert oder klar verstanden und dokumentiert werden.

Undokumentierte Instruktion

Eine undokumentierte, nicht-standard Instruktion namens CEASE, die den Core anhält, wurde detektiert. Effektiv könnte der RISC-V RocketCore etwas tun, was er nicht soll. Undokumentierte, versteckte Funktionen sind inakzeptabel, wenn Trust und Security ein Anliegen sind, selbst wenn sie Use Cases betreffen, die als irrelevant für die Endapplikation gelten.

Die RocketCore-Fallstudie ist detailliert im GOMACTech 2019 Paper Complete Formal Verification of RISC-V Processor IPs for Trojan-Free Trusted ICs dargestellt. Für eine Kopie besuchen Sie onespin.com/resources/white-papers.

Ausblick

Der vorgestellte RISC-V Assurance-Prozess detektiert Szenarien, die Sicherheit beeinflussen könnten, und deckt systematisch undokumentierte Funktionen und Hardware-Trojaner auf, die das Prozessorverhalten beeinflussen, egal wie selten und stealthy sie sein mögen. Side-Channels werden jedoch nicht systematisch detektiert. Exhaustive Detektion aller potenziellen Side-Channels erfordert eine dedizierte Lösung mit entsprechender Technologie. Es gibt bereits Prototypen, die diese Herausforderung adressieren. Für mehr Informationen besuchen Sie onespin.com/resources/technical-articles und lesen Sie den EE Times Artikel Side-Channel Attacks on Embedded Processors.

Prozessor-Cores sind entscheidende IPs in eingebetteten Systemen. Ein typisches SoC integriert jedoch viele andere IPs, die ebenfalls Hardware-Trojaner enthalten könnten. Im Gegensatz zu RISC-V-Cores könnten unabhängige Trust-Assurance-Lösungen nicht ohne Weiteres verfügbar sein. In diesem Fall wäre ein automatisierter, niedrig-aufwändiger Trust-Assessment-Prozess wertvoll, der auf jedes IP anwendbar ist. Ein Prozess ohne Trusted Model des IPs kann die Abwesenheit eines Trojaners nicht garantieren. Es ist jedoch möglich, ungewöhnliche und verdächtige Code-Muster, bekannte Trojaner-Signaturen und Schwachstellen zu identifizieren, die in späteren Entwicklungsphasen für nefarious Zwecke ausgenutzt werden könnten. Ein Paper zu diesem Thema, An Automated Pre-Silicon IP Trustworthiness Assessment for Hardware Assurance, verfasst von AEROSPACE Corporation und OneSpin Ingenieuren, wird auf der GOMACTech 2020 Konferenz vorgestellt.