DE102018127330A1

DE102018127330A1 - System-on-Chip und Verfahren zum Betreiben eines System-on-Chip

Info

Publication number: DE102018127330A1
Application number: DE102018127330.4A
Authority: DE
Inventors: Albrecht Mayer; Reinhard Deml; Viola Rieger; Alexander Zeh
Original assignee: Infineon Technologies AG
Current assignee: Infineon Technologies AG
Priority date: 2018-11-01
Filing date: 2018-11-01
Publication date: 2020-05-07
Also published as: US11562079B2; US20200143064A1; JP7366691B2; JP2020091849A

Abstract

In verschiedenen Ausführungsbeispielen wird ein System-on-Chip bereitgestellt. Das System-on-Chip kann einen Steuer-Schaltkreis mit einer Mehrzahl von Steuer-Schaltkreisbereichen aufweisen, wobei der Steuer-Schaltkreis eingerichtet ist zum Steuern einer Vorrichtung, einen Security-Schaltkreis, der einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist, wobei der Security-Schaltkreis eingerichtet ist, wahlweise nur einen Lesezugriff oder einen Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche zu ermöglichen, wobei der Security-Schaltkreis ferner eingerichtet ist, mittels des Schlüsselspeichers und des Hardwarebeschleunigers einen Kommunikationspfad zur gesicherten Kommunikation mit einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem bereitzustellen, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat zu treffen und den Lesezugriff oder den Lese- und Schreibzugriff auszuführen.

Description

Die Erfindung betrifft ein System-on-Chip (SoC) und ein Verfahren zum Betreiben eines System-on-Chip.
Mehrkern-Microcontroller, auch als „System-on-Chip“ bezeichnet, ermöglichen es, komplexe (betriebs-)sicherheitskritische (Echtzeit-)Hardwaresysteme zu steuern oder zu regeln.
Der deutsche Begriff „Sicherheit“ und damit zusammenhängende Begriffe (wie oben „sicherheitskritisch“) wird in zwei verschiedenen Zusammenhängen gebraucht, welche im Englischen mittels der Begriffe „safety“ bzw. „security“ unterschieden werden. Hierbei bezeichnet „safety“ eine Betriebssicherheit, also dass ein System in einem Zustand betrieben wird, in welchem seine Nutzung weder Schäden am System selbst noch an seiner Umgebung (z.B. einem Nutzer) verursacht. „Security“ hingegen bezieht sich auf eine Datensicherheit. Also darauf, dass ein Zugriff auf Daten und/oder Funktionen, welche von einem System bereitstellbar bzw. ausführbar sind, nur Zugriffsberechtigten ermöglicht sind. Zur Unterscheidung werden wir hierin die Begriffe „Security“ (und davon abgeleitete Begriffe wie „Secure“ usw.) bzw. „Datensicherheit“ für die Datensicherheit verwenden, und die Begriffe „Safety“ (und davon abgeleitete Begriffe wie „safe“ usw.) bzw. „Betriebsicherheit“ für die Betriebssicherheit. Sofern nicht aus dem Zusammenhang etwas Anderes hervorgeht, sind mit dem Begriff „Sicherheit“ (ohne weitere Differenzierung) sowohl die Betriebssicherheit als auch die Datensicherheit gemeint.
Die oben beschriebenen komplexen Systeme können einen im Wesentlichen unbeschränkten Eingabe(wert)- und Zustandsraum haben. Deshalb kann es vorkommen, dass bestimmte Anomalien (z.B. Zustände, welche von erwarteten erwünschten und auch von vorhergesehenen unerwünschten Zuständen abweichen) nur im Feld, d.h. im Betrieb beim Nutzer auftreten. Diese Art von Anomalien kann ihre Ursache in unerwarteten Eingabewerten und/oder in Angriffen auf eine Datensicherheit des Systems haben und Einfluss auf eine Verfügbarkeit des Systems haben.
Das bedeutet, dass ein Bedarf daran besteht, eine flexible, eine Datensicherheit (und auch eine Betriebssicherheit) des Systems gewährleistende Zugriffsmöglichkeit auf solche komplexen Systeme während ihres Betriebs beim Nutzer zu ermöglichen, um Anomalien (und möglicherweise ihre Ursachen) zu erkennen.
Bei manchen der gegenwärtig verfügbaren Systeme kann eine (Betriebs-)Software eine Diagnose- und Logbuch-Funktion aufweisen. Damit werden allerdings typischerweise nur solche Anomalien bzw. Fehlfunktionen erfasst, welche von vornherein erwartet wurden. Bei einer Anwendung eines solchen Diagnosewerkzeugs kann ein bestimmtes System, z.B. ein PKW, welcher eine Anomalie gezeigt hat, nachträglich mit Fehlererkennungs- bzw. Fehlerkorrekturmöglichkeiten (auch als Debug-Funktion bezeichnet) ausgerüstet werden, z.B. an eine Diagnoseeinheit angeschlossen werden. Die Fehlererkennungs- bzw. Fehlerkorrekturmöglichkeiten werden allerdings höchstens dann zu einem Erfolg führen, wenn die Anomalie leicht zu reproduzieren ist und nicht dadurch beeinflusst ist, dass das System durch das Anschließen der Diagnoseeinheit verändert wurde. Bei einer solchen Vorgehensweise besteht allerdings die Möglichkeit, dass sie ohnehin nur während einer Entwicklungsphase zugänglich ist, und nicht, wenn das System bereits im Besitz des Nutzers ist.
Ein weiteres gegenwärtig verfügbares System-on-Chip 100 mit einer Debug-Möglichkeit für ein darin integriertes Hostsystem 102 ist in 1A bis 1C dargestellt. Hierbei zeigt 1A eine Übersicht über das gesamte System-on-Chip 100 und eine damit verbundene externe Debug-Vorrichtung 104, und 1B und 1C zeigen zwei Beispiele dafür, wie der Debug-Zugriff im Hostsystem 102 gestaltet sein kann.
Das System-on-Chip 100 stellt einen (hinsichtlich Datensicherheit) gesicherten Zugriffskanal („Debug-Kanal“) zu einem Host-System 102 bereit.
Zum Aufbau des authentifizierten Debug-Kanals bedient sich das System-on-Chip 100 eines Hardware-Sicherheitsmoduls (HSM) 112. Das HSM 112 bildet ein vom Hostsystem 102 physisch getrenntes Modul mit Datensicherheitsbausteinen wie z.B. einen als „Secure CPU“ bezeichneten Sicherheitsprozessor 118, eine als „Krypto-Zelle“ bezeichnete ROM-Bibliothek 114, eine Debug-Steuereinheit (DCU, für „Debug Control Unit) 116, eine Schnittstelle 110, eine Boot ROM 112 und einen gesicherten Datenspeicher („Secured RAM“) 120.
Die ROM-Bibliothek 114 wird genutzt, um (Debug-)Zertifikate 108, welche dem HSM 112 von der externen Debug-Vorrichtung 104 mittels eines Debug-Zugangsports (DAP für „Debug Access Port) 106 und mittels der Schnittstelle 110 zugeführt werden, zu prüfen. Um sicherzustellen, dass das Debug-Zertifikat nur bei dem vorliegenden SoC 100 zur Authentifizierung genutzt werden kann, kann es nötig sein, das Debug-Zertifikat mit einem geheimen SoC-spezifischen Schlüssel zu signieren, welcher in einem unveränderbar programmierten OTP-RAM 124 auf dem Chip hinterlegt ist.
Mit oder nach dem Übermitteln des (Debug-)Zertifikats 108 kann die externe Debug-Vorrichtung 104 (z.B. mittels des Debug-Zugangsports 106) Debug-Anweisungen an das Hostsystem übertragen, z.B. an einen (Debug-)Zugangsport 132, 132D (in 1A nicht gekennzeichnet, er befindet sich dort, wo ein Schalter 126 beim Zugang ins Hostsystem 102 als Tresor veranschaulicht ist; in 1B ist der (Debug-)Zugangsport 132, 132D gekennzeichnet).
Der (Debug-)Zugangsport 132, 132D bleibt jedoch so lange verschlossen (mittels des Schalters 126), bis das (Debug-)Zertifikat 108 im HSM 112 authentifiziert wurde. Nach der Authentifizierung wird die DCU 116, welche eingerichtet ist, Zugriffe auf Debug-Interfaces (z.B. Debug-Zugangsports 132, 132D von Host-CPUs 128 und anderen Systemressourcen 130, 140, 142) zu steuern und zu verwirklichen, genutzt, um den (Debug-)Zugangsport 132, 132D (oder ggf. jeweils ein Debug-Zugangsport 132, 132D, zu einer Host-CPU 138 und zu einem Host-Speicher 142) freizuschalten.
Nach dem Öffnen des Debug-Zugangsports 132, 132D zum Hostsystem 102 können die von der externen Debug-Vorrichtung 104 übermittelten Debug-Anweisungen im Hostsystem 102 ausgeführt werden.
Dabei ist vorgesehen, dass die Debug-Anweisungen, welche mittels der Debug-Zugangsports 132, 132D übermittelt werden, z.B. mit einem dem JTAG-Standard entsprechenden Protokoll übertragen werden.
Das Ausführen der Debug-Anweisungen (als ein Debug-Protokoll) im Hostsystem 102 kann dabei beispielsweise, wie in 1B dargestellt, mittels speziell für das Debuggen bereitgestellter Komponenten erfolgen. Die zweckgebundenen Komponenten können beispielsweise einen physischen USB-Anschluss 132D, eine USB-Vorrichtungssteuerung 134D und ein Modul mit Standardanweisungen 136 aufweisen. Diese Konfiguration bietet den Vorteil, dass sie am wenigsten in das zum Betreiben einer Vorrichtung eingerichtete restliche System (insbesondere den zugehörigen physischen USB-Anschluss 132, die USB-Vorrichtungssteuerung 134 und die CPU(s) 128) eingreift und Debug-Möglichkeiten auch dann bereitstellt, wenn das restliche System sich (z.B. noch oder wieder) in einem so genannten „bare metal“-Zustand befindet, also z.B. noch keine Software dort installiert ist. Allerdings müssen dafür die teuren zusätzlichen zweckgebundenen Komponenten (z.B. der physische USB-Anschluss 132D, die USB-Vorrichtungssteuerung 134D und das Modul mit Standardanweisungen 136) bereitgestellt werden.
Bei einem kostengünstigeren Beispiel können die Debug-Anweisungen (als ein Debug-Protokoll) im Hostsystem 102 beispielsweise, wie in 1C dargestellt, mittels der zum Betreiben einer Vorrichtung eingerichteten Komponenten erfolgen. Das bedeutet, dass beispielsweise der physische USB-Anschluss 132, die USB-Vorrichtungssteuerung 134 und die CPU 128, welche zum Betreiben der Vorrichtung eingerichtet sind, gleichzeitig auch eingerichtet sind, das Debug-Protokoll auszuführen. Dies ist zum einen invasiv und erfordert zum anderen, dass die CPU 128 läuft, denn mit einem Anhalten der CPU 128 (was bei einem Debuggen möglicherweise nötig werden kann) verschwindet zugleich auch die Debug-Funktionalität.
Dementsprechend besteht ein Bedarf daran, ein System-on-Chip bereitzustellen, welches zwar einerseits keiner zusätzlichen Komponenten bedarf und damit kostengünstig ist, aber andererseits trotzdem in der Lage ist, sämtliche zum Steuern/Betreiben der Vorrichtung genutzten CPUs bei Bedarf anzuhalten, ohne die Debug-Funktionalität zu verlieren.
Ein weiterer Aspekt des System-on-Chip 100 aus 1A bis 1C betrifft das Öffnen der Debug-Ports 132, 132D mittels der DCU 116. Denn das Öffnen der Debug-Ports 132, 132D kann anschaulich beschrieben werden als ein Umlegen (Öffnen) eines Hauptschalters, welche im Hostsystem sämtliche gemäß dem JTAG-Standard zugänglichen Debug-Systeme bzw. Funktionalitäten freigibt.
Solange ein solches Debugging vor einem Bereitstellen der Vorrichtung (einschließlich des SoC 100) an einen Nutzer erfolgt, also beispielsweise beim Hersteller, kann eine solche Gestaltung unproblematisch sein.
Sofern jedoch, wie oben geschildert, darauf abgezielt wird, die Vorrichtung bzw. das SoC 100 während eines Betriebs (also beim Nutzer) zu überwachen, um anomale Vorgänge zu erkennen, kann es problematisch sein, dass die Debug-Möglichkeit nicht nur Überwachungsfunktionen, sondern gleichzeitig auch z.B. die Möglichkeit, Breakpoints zu setzen, bereitstellt. Beispielsweise kann die Vorrichtung eine Motorsteuerung eines PKWs sein, und ein während einer Fahrt unkontrolliert mittels eines externen Debug-Zugriffs deaktivierte Software kann den Motor ausfallen lassen und damit eine für den Nutzer und/oder Dritte gefährliche Situation herbeiführen.
Dementsprechend kann es wünschenswert sein, ein System-on-Chip bereitzustellen, welches ein Freigeben unterschiedlicher Debug-Niveaus ermöglicht, von denen zumindest eines ein Überwachen der Vorrichtung bzw. des System-on-Chip während des Betriebs der Vorrichtung ermöglicht und gleichzeitig eine Betriebssicherheit der Vorrichtung sicherstellt.
In verschiedenen Ausführungsbeispielen wird eine Steuerung von Debug-Ressourcen mittels einer in einem System-on-Chip integrierten Hardware- und Softwareeinheit vorgenommen, welche ein Sonderrechte-Level eines Werkzeugs (z.B. eines Diagnosesystems) erkennt anhand eines Schlüssels, Passworts und/oder Zertifikats, welcher/s für eine Authentifizierung des Werkzeugs bereitgestellt wird. Einflussnahme/Wechselwirkung oder Beobachtung werden basierend auf dem Sonderrechte-Level erlaubt (bzw. untersagt). Beispielsweise kann ein vorbestimmtes Sonderrechte-Level bedeuten, dass nur Aktivitäten einer bestimmten virtuellen Maschine nachverfolgt werden können. Das Nachverfolgen kann beispielsweise bei unterschiedlichen Beobachtungspunkten (z.B. Zeitpunkten oder Stellen in einem Programmablauf) ermöglicht sein bzw. werden.
In verschiedenen Ausführungsbeispielen werden ein System bzw. ein Verfahren bereitgestellt, auf eine sichere aber dennoch flexible Weise per Fernzugriff ein Steuerungssystem (z.B. ein Steuersystem einer Vorrichtung) zu überwachen. Das bereitgestellte System bzw. Verfahren ist ferner sehr robust und kostengünstig.
In verschiedenen Ausführungsbeispielen wird ein Hardware-Sicherheitsmodul des Steuerungssystems für das Überwachen verwendet, welches besonders geeignet ist, weil es eine sichere Umgebung darstellt und unabhängig von dem Rest des Systems ist (z.B. durch eigene Systemperipherie und Speicher). Auch manche grundlegenden betriebssicherheitsrelevanten Aspekte können bereits ohne weitere Modifikationen von dem Security-Subsystem erfüllt sein.
Außerdem kann es möglich sein, dass das Hardware Security Module in vielen Fällen durch die typischen Security-Aufgaben nicht vollständig ausgelastet ist. Dies kann insbesondere während einer Entwicklunsphase der Fall sein. Denn während der Entwicklung kann es möglich sein, dass die Security-Funktion gar nicht oder lediglich in sehr beschränktem Umfang benötigt wird. Dementsprechend kann die Diagnosefunktion, insbesondere der Kommunikationspfad, vorteilhaft ohne zusätzliche teure Hardware bereitgestellt werden.
Außerdem ist das HSM ein unabhängiges Subsystem, was bedeutet, dass es die Kommunikation mit dem Diagnosesystem aufrechterhalten, selbst wenn das (normale Mehrfachkern-)Steuerungssystem angehalten ist bzw. wird.
In verschiedenen Ausführungsbeispielen wird ein System-on-Chip bereitgestellt. Das System-on-Chip kann einen Steuer-Schaltkreis mit einer Mehrzahl von Steuer-Schaltkreisbereichen aufweisen, wobei der Steuer-Schaltkreis eingerichtet ist zum Steuern einer Vorrichtung, einen Security-Schaltkreis, der einen gesondert gesicherten Schlüsselspeicher und mindestens einen Hardwarebeschleuniger für kryptographische Operationen aufweist, wobei der Security-Schaltkreis eingerichtet ist, wahlweise nur einen Lesezugriff oder einen Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche zu ermöglichen, wobei der Security-Schaltkreis ferner eingerichtet ist, mittels des Schlüsselspeichers und des mindestens einen Hardwarebeschleunigers einen Kommunikationspfad zur gesicherten Kommunikation mit einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem bereitzustellen, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat zu treffen und den Lesezugriff oder den Lese- und Schreibzugriff auszuführen.
Der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises kann so gestaltet sein, dass damit mindestens eine vom Diagnosesystem mittels des Kommunikationspfads an den Security-Schaltkreis übermittelte Diagnoseanweisung ausführbar ist.
Der Security-Schaltkreis kann mittels einer Software zum Ausführen der gesicherten Kommunikation eingerichtet sein.
Der Security-Schaltkreis kann eine CPU oder eine virtuelle Maschine aufweisen, welche eingerichtet ist, die Software auszuführen.
Die Software kann einen Software-Kommunikationsstapel aufweisen, z.B. einen Ethernet Software-Kommunikationsstapel.
Die CPU oder die virtuelle Maschine kann eingerichtet sein, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises zu unterstützen. Damit kann ermöglicht werden, dem Diagnosesystem weniger bzw. andere Zugriffsmöglichkeiten bereitzustellen als diejenigen, über welche die CPU bzw. die virtuelle Maschine prinzipiell verfügt.
Der Kommunikationspfad kann in verschiedenen Ausführungsbeispielen ein Netzwerk aufweisen. In verschiedenen Ausführungsbeispielen kann das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweisen.
Der mindestens eine ausgewählte Bereich des Steuer-Schaltkreises kann in verschiedenen Ausführungsbeispielen eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweisen, und der Security-Schaltkreis kann eingerichtet sein, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises zu treffen.
Anders ausgedrückt kann auf einen ersten Teil (z.B. keinen, einen oder mehrere) der ausgewählten Bereiche des Steuer-Schaltkreises ein (nur-)Lesezugriff ermöglicht sein, und gleichzeitig kann auf einen zweiten, vom ersten verschiedenen Teil (z.B. keinen, einen oder mehrere) der ausgewählten Bereiche des Steuer-Schaltkreises ein Lese- und Schreibzugriff ermöglicht sein.
In verschiedenen Ausführungsbeispielen kann der Security-Schaltkreis eingerichtet sein, bei einer fehlgeschlagenen Authentifizierung weder der Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen.
Gegebenenfalls kann der Security-Schaltkreis ferner eingerichtet sein, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen, beispielsweise in der Vorrichtung.
In verschiedenen Ausführungsbeispielen kann der Security-Schaltkreis eingerichtet sein, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen. Der zusätzliche Parameter kann beispielsweise eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betreffen.
Die Berücksichtigung der Relevanz des Lese- bzw. Lese-/Schreibzugriffs für die Betriebssicherheit der Vorrichtung kann bedeuten, dass der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff (oder auch dem kompletten Untersagen des Zugriffs) klar zu unterscheiden zwischen einer Debug-Anweisung, welche kritisch sein kann für eine Betriebssicherheit (z.B. „Anhalten/Stoppen“, „Pausieren“ usw.) und anderen Debug-Anweisungen, welche lediglich eine überwachende Funktion haben (z.B. zählen, nachverfolgen usw.). Dabei können üblicherweise die betriebssicherheitskritischen Anweisungen einen Schreibzugriff erfordern, während für die überwachenden Funktionen üblicherweise ein reiner Lesezugriff ausreichend sein kann. In manchen Fällen, beispielsweise bei einem Auslesen eines (FIFO-) Speichers, welcher durch das Auslesen automatisch überschrieben wird, kann gegebenenfalls auch der reine Lesezugriff als betriebssicherheitskritisch einzustufen sein.
Die Berücksichtigung des Betriebszustands der Vorrichtung kann bedeuten, dass der Security-Schaltkreis eingerichtet sein kann, den Lese- und Schreibzugriff (oder auch einen betriebssicherheitskritischen Lesezugriff), auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff (oder auch einen betriebssicherheitskritischen Lesezugriff) auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
Der erste vorbestimmte Betriebszustand kann ein „aktiv“-Betriebszustand sein, mit anderen Worten ein Betriebszustand, in welchem die Vorrichtung aktiv bzw. in Betrieb ist.
Der erste vorbestimmte Betriebszustand kann ein „inaktiv“-Betriebszustand sein, mit anderen Worten ein Betriebszustand, in welchem die Vorrichtung inaktiv bzw. nicht in Betrieb oder in einem Ruhe-/Pausenzustand ist.
Die Berücksichtigung des Zeitpunkts der Bereitstellung des Zertifikats kann es ermöglichen, Zertifikate mit einer begrenzten Gültigkeitsdauer bereitzustellen.
Der mindestens eine ausgewählte Bereich kann eine virtuelle Maschine und/oder eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises sein oder aufweisen.
Das System-on-Chip kann eingerichtet sein, den Kommunikationspfad infolge einer Anweisung des Diagnosesystems, des Security-Schaltkreises und/oder des Steuerschaltkreises zu schließen. Das System-on-Chip kann ferner eingerichtet sein, nach dem Schließen des Kommunikationspfads einen Neustart auszuführen.
Ausführungsbeispiele der Erfindung sind in den Figuren dargestellt und werden im Folgenden näher erläutert.
Es zeigen

1A eine schematische Übersicht eines System-on-Chip gemäß dem Stand der Technik und eine damit verbundene externe Debug-Vorrichtung;
1B und 1C zeigen jeweils eine schematische Darstellung eines Hostsystems des System-on-Chip aus 1A;
2A und 2B jeweils eine schematische Übersicht eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen; und
3 ein Flussdiagramm eines Verfahrens zum Betreiben eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen.

In der folgenden ausführlichen Beschreibung wird auf die beigefügten Zeichnungen Bezug genommen, die Teil dieser bilden und in denen zur Veranschaulichung spezifische Ausführungsformen gezeigt sind, in denen die Erfindung ausgeübt werden kann. In dieser Hinsicht wird Richtungsterminologie wie etwa „oben“, „unten“, „vorne“, „hinten“, „vorderes“, „hinteres“, usw. mit Bezug auf die Orientierung der beschriebenen Figur(en) verwendet. Da Komponenten von Ausführungsformen in einer Anzahl verschiedener Orientierungen positioniert werden können, dient die Richtungsterminologie zur Veranschaulichung und ist auf keinerlei Weise einschränkend. Es versteht sich, dass andere Ausführungsformen benutzt und strukturelle oder logische Änderungen vorgenommen werden können, ohne von dem Schutzumfang der vorliegenden Erfindung abzuweichen. Es versteht sich, dass die Merkmale der hierin beschriebenen verschiedenen beispielhaften Ausführungsformen miteinander kombiniert werden können, sofern nicht spezifisch anders angegeben. Die folgende ausführliche Beschreibung ist deshalb nicht in einschränkendem Sinne aufzufassen, und der Schutzumfang der vorliegenden Erfindung wird durch die angefügten Ansprüche definiert.
Im Rahmen dieser Beschreibung werden die Begriffe „verbunden“, „angeschlossen“ sowie „gekoppelt“ verwendet zum Beschreiben sowohl einer direkten als auch einer indirekten Verbindung, eines direkten oder indirekten Anschlusses sowie einer direkten oder indirekten Kopplung. In den Figuren werden identische oder ähnliche Elemente mit identischen Bezugszeichen versehen, soweit dies zweckmäßig ist.
2A und 2B zeigen jeweils eine schematische Übersicht eines System-on-Chip 200 gemäß verschiedenen Ausführungsbeispielen.
Wie in 2A dargestellt ist, kann das System-on-Chip 200 einen Steuer-Schaltkreis 102 mit einer Mehrzahl von Steuer-Schaltkreisbereichen 128, 130 aufweisen. Die Mehrzahl von Steuer-Schaltkreisbereichen kann beispielsweise eine CPU 128 oder eine sonstige Ressource 130 des Steuer-Schaltkreises 102 aufweisen, z.B. einen Interconnect 140, einen Speicher 142 oder andere Ressourcen wie z.B. eine virtuelle Maschine, eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises sein oder aufweisen. (siehe dazu die dahingehend ähnlichen Steuer-Schaltkreise 102 aus 1B bzw. 1C). Jeder der Steuer-Schaltkreisbereiche kann beispielsweise durch seinen Adressbereich identifizierbar sein.
Der Steuer-Schaltkreis 102 kann eingerichtet sein zum Steuern einer Vorrichtung (nicht dargestellt). Die Vorrichtung kann im Wesentlichen jede beliebige typischerweise mittels eines Steuer-Schaltkreises 102 gesteuerte oder geregelte Vorrichtung sein, beispielsweise ein Motor eines Fahrzeugs oder einer Maschine, ein medizinisches Gerät, ein Kassensystem oder ähnliches.
Das System-on-Chip 200 kann ferner einen Security-Schaltkreis (auch als Kryptographie-Sicherheitsschaltkreis oder kurz als Sicherheitsschaltkreis bezeichnet) 220 aufweisen. Der Security-Schaltkreis 220 kann beispielsweise als Hardware-Sicherheitsmodul (HSM) 220 gebildet sein.
Hier bezieht sich der Begriff „sicher“ auf Informationssicherheit und nicht funktionale Sicherheit.
Ein HSM ist eine logisch, machmal auch physikalisch separierte Hardware-Einheit, die eine effiziente und sichere Ausführung von kryptographischen Operationen und Sicherheits-Anwendungen gewährleistet.
Der Security-Schaltkreis 220 kann eingerichtet sein, dem Steuer-Schaltkreis (daten-)sicherheitsrelevante Funktionen bereitzustellen, welche beispielsweise beim Betreiben der Vorrichtung erforderlich sein können. Die sicherheitsrelevanten Funktionen können beispielsweise ein Erzeugen von Zufallszahlen, Schlüsseln und PINs und/oder ein Ver- und Entschlüsseln von Daten aufweisen.
Zum Ausführen der sicherheitsrelevanten Funktionen kann der Security-Schaltkreis 220 zusätzlich zu einem Prozessor 118 (einer CPU, hier auch als Security-CPU bezeichnet) einen gesondert gesicherten Schlüsselspeicher 144 (zum Speichern von kryptographischen Schlüsseln) und einen Hardwarebeschleuniger 146 für kryptographische Operationen aufweisen (z.B. für Hash-Funktionen und/oder für symmetrische und/oder asymmetrische Kryptographie).
Der Security-Schaltkreis 220 kann ferner über einen gesonderten Lese-/Schreibzugriff zu dedizierten Ressourcen verfügen, beispielsweise zu CPUs und/oder Speichern im Steuer-Schaltkreis 102.
In verschiedenen Ausführungsbeisielen kann der Security-Schaltkreis 220 ferner mit Mechanismen zum Schutz gegen Seitenkanalangriffe ausgerüstet sein. Sicherheitsstandards (wie FIPS 140-1 oder Common Criteria) geben Kriterien für die Zertifizierung von HSMs vor.
Aktuelle Anwendungsfälle für die HSM im Automotive-Umfeld sind „secure boot“, sichere Datenkommunikation (über CAN, Ethernet und LIN) und der Speicherschutz (für die IP-Sicherung).
Wie oben ausgeführt kann es wünschenswert oder nötig sein, den Steuer-Schaltkreis 102 und/oder die davon gesteuerte Vorrichtung zu Überwachen, beispielsweise im Feld.
Zu dem Zweck kann ein Diagnosesystem 104 bereitgestellt sein oder werden.
Zum Bereitstellen eines (sicheren) Kommunikationspfads zwischen dem Diagnosesystem 104 und dem System-on-Chip 200, der eine (im informationstechnischen Sinn) sichere Kommunikation zwischen dem System-on-Chip 200 (insbesondere dem Security-Schaltkreis 220) und dem Diagnosesystem 104 ermöglicht, kann von dem Diagnosesystem 104 dem Security-Schaltkreis 220 ein Zugangsberechtigungsnachweis übermittelt werden.
Der Security-Schaltkreis 220 kann eingerichtet sein, mittels des Schlüsselspeichers 144 und des Hardwarebeschleunigers 146 den Zugangsberechtigungsnachweis zu authentifizieren und daraufhin den (sicheren) Kommunikationspfad zur gesicherten Kommunikation mit dem außerhalb des Security-Schaltkreises 220 (und ggf. auch außerhalb des System-on-Chip 200) angeordneten Diagnosesystem 104 bereitzustellen.
Der Security-Schaltkreis 220 kann ferner eingerichtet sein, den Zugangsberechtigungsnachweis dahingehend auszuwerten, dass der Zugangsberechtigungsnachweis eine Auswahl zwischen verschiedenen Zugriffsmöglichkeiten auf die Steuer-Schaltkreisbereiche 128, 130 des Steuer-Schaltkreises 102 ermöglicht.
Beispielsweise kann der Security-Schaltkreis 220 eingerichtet sein, auf jeden der Steuer-Schaltkreisbereiche 128, 130 entweder (nur) einen Lesezugriff oder einen Lese- und Schreibzugriff zu ermöglichen, oder aber einen Zugriff zu unterbinden.
Das mittels im Schlüsselspeicher 144 gespeicherter Informationen (und ggf. unter Zuhilfenahme des Hardwarebeschleunigers 146) authentifizierten Zugangsberechtigungsnachweises kann, z.B. mittels der Security-CPU 118, mit im Security-Schaltkreis 220 hinterlegten Zuordnungen von Zugangsberechtigungsnachweisen zu Zugriffsberechtigungen abgeglichen werden.
Der Security-Schaltkreis 220 kann eingerichtet sein, basierend auf der zugeordneten Zugriffsberechtigung den Lesezugriff oder den Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich 128, 130 des Steuer-Schaltkreises 102 zu ermöglichen, oder aber einen Zugriff zu unterbinden.
Der Security-Schaltkreis 220 kann eingerichtet sein, den Lesezugriff oder den Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich 128, 130 des Steuer-Schaltkreises 102 auszuführen.
Der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich 128, 130 des Steuer-Schaltkreises 102 kann so gestaltet sein, dass damit mindestens eine vom Diagnosesystem 104 mittels des Kommunikationspfads an den Security-Schaltkreis 220 übermittelte Diagnoseanweisung ausführbar ist.
Das bedeutet, dass im Unterschied zum im Zusammenhang mit 1A bis 1C erläuterten System-on-Chip 100, bei welchem nach einem Öffnen des „Schalters“ 126 die Diagnose- oder Debug-Anweisungen und Informationen direkt zwischen dem Diagnosesystem 104 und dem Hostsystem 102 ausgetauscht werden, beim System-on-Chip 200 gemäß verschiedenen Ausführungsbeispielen der Diagnosesystem seine Überwachungs- und/oder Debug-Anweisungen an den Security-Schaltkreis 220 übermittelt und diese von dem Security-Schaltkreis 220 an den Steuer-Schaltkreis 102 übermittelt werden unter Berücksichtigung der Lese- bzw. Lese- und Schreibberechtigung für jeden von der Diagnoseanweisung betroffenen Steuer-Schaltkreisbereich 128, 130.
Der Security-Schaltkreis 220 kann mittels einer Software zum Ausführen der gesicherten Kommunikation mit dem Diagnosesystem 104 und/oder zu einem Bereitstellen der Diagnoseanweisung an den Steuer-Schaltkreis 102 eingerichtet sein. Die Software kann beispielsweise jeweils ein Software-Paket aufweisen zum Ausführen der gesicherten Kommunikation mit dem Diagnosesystem 104 bzw. zum Bereitstellen der Diagnoseanweisung an den Steuer-Schaltkreis 102.
In verschiedenen Ausführungsbeispielen kann die CPU 118 des Security-Schaltkreises 220 oder eine virtuelle Maschine eingerichtet sein, die Software auszuführen.
Die (Kommunikations-)Software kann beispielsweise einen Software-Kommunikationsstapel aufweisen, z.B. einen Ethernet Software-Kommunikationsstapel.
Die CPU 118 oder die virtuelle Maschine kann eingerichtet sein, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich 128, 130 des Steuer-Schaltkreises 102 zu unterstützen. Damit kann ermöglicht werden, dem Diagnosesystem weniger bzw. andere Zugriffsmöglichkeiten bereitzustellen als diejenigen, über welche die CPU 118 bzw. die virtuelle Maschine prinzipiell verfügt.
Das bedeutet, dass der Security-Schaltkreis 220 bzw. die CPU (oder die virtuelle Maschine) prinzipiell eingerichtet sein kann, auf jeden der ausgewählten Bereiche 128, 130 des Steuer-Schaltkreises 102 mittels eines Schreibzugriffs zuzugreifen, dass jedoch die Mehrzahl von Master Tags bereitgestellt ist, um die Zugriffsart auf einzelne oder alle der ausgewählten Bereiche 128, 130 des Steuer-Schaltkreises 102 zu beschränken, z.B. auf nur Lesezugriff oder als ein Zugriffsverbot.
Wie bereits beschrieben erfolgt die Überprüfung der Security Berechtigung von durch das Diagnosesystem 104 angeforderten Zugriffen durch den Security-Schaltkreis 220. Durch die Master Tags kann für die daraus resultierenden Zugriffe auf den Steuer-Schaltkreis 102 im Steuer-Schaltkreis selbst die Safety Berechtigung überprüft werden, und der Steuer-Schaltkreis 102 kann sich damit gegen kritische Zugriffe schützen. Das ist notwendig, da esnicht ausgeschlossen werden kann, dass der Security-Schaltkreis 220 durch einen Hardware- oder Softwarefehler einen unerlaubten Zugriff macht, der kritische Folgen hat.
Der Security-Schaltkreis 220 kann eingerichtet sein, zum Ermöglichen eines Lesezugriffs für einen vorbestimmten Master Tag in einem so genannten Access Enable Register an einer dem Master Tag zugeordneten Stelle einen Wert einzutragen, welcher einem Lesezugriffsrecht entspricht.
Analog dazu kann der Security-Schaltkreis 220 eingerichtet sein, zum Ermöglichen eines Lese- und Schreibzugriffs für einen vorbestimmten weiteren Master Tag in dem Access Enable Register an einer dem weiteren Master Tag zugeordneten Stelle einen Wert einzutragen, welcher einem Lese- und Schreibzugriffsrecht entspricht.
In verschiedenen Ausführungsbeispielen kann diese Zugriffssteuerung mittels Überschreibens des Access Enable Register wiederum dahingehend abgesichert sein, dass das Überschreiben nur für einen Master zulässig ist, welcher mittels seiner Master Tag dahingehend ausgewiesen ist, dass er nicht nur den informationstechnischen Sicherheitsanforderungen genügt, sondern außerdem auch die Betriebssicherheit der Vorrichtung sicherstellt. Eine entsprechende Information kann in verschiedenen Ausführungsbeispielen beispielsweise als Seiten- oder Inband-Information im Bus-System übertragen werden. Diese Ausführungsbeispiele sind zwar einfache in der Gestaltung/Umsetzung, aber relativ teuer, weil der Master (bzw. der entsprechenden Software) sowohl hohe (z.B. die höchsten) Safety- als auch hohe (z.B. die höchsten) Security-Anforderungen erfüllen muss.
In verschiedenen Ausführungsbeispielen kann stattdessen eine Safety-CPU des Steuerschaltkreises 102 (z.B. kann die CPU 128 oder eine weitere CPU als Safety-CPU eingerichtet sein) so konfiguriert sein, dass sie in einer Initialisierungsphase die Zugriffsberechtigungen verriegelt (festschreibt), z.B. als eine Zuordnung von Master Tag(s) zu Ressource(n) 128, 130, auf welche sie zum Zugriff berechtigt ist/sind. Der Security-Schaltkreis 118 kann eingerichtet sein, die Zugriffsberechtigung bei den für ihn relevanten Modulen zu überprüfen.
Beide Gestaltungen ermöglichen es, ein System-on-Chip mit einer Verriegelung bereitzustellen, die sowohl die Betriebssicherheit (Safety) als auch die Datenicherheit (Security) gewährleistet.
Der Kommunikationspfad zum Diagnosesystem kann in verschiedenen Ausführungsbeispielen ein Netzwerk aufweisen. In verschiedenen Ausführungsbeispielen kann das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweisen.
Der mindestens eine ausgewählte Bereich 128, 130 des Steuer-Schaltkreises 102 kann in verschiedenen Ausführungsbeispielen eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweisen.
Der Security-Schaltkreis 220 kann eingerichtet sein, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen 128, 130 des Steuer-Schaltkreises 102 zu treffen.
Anders ausgedrückt kann auf einen ersten Teil (z.B. keinen, einen oder mehrere) der ausgewählten Bereiche 128, 130 des Steuer-Schaltkreises 102 ein (nur-)Lesezugriff ermöglicht bzw. werden, und gleichzeitig kann auf einen zweiten, vom ersten verschiedenen Teil (z.B. keinen, einen oder mehrere) der ausgewählten Bereiche 128, 130 des Steuer-Schaltkreises 102 ein Lese- und Schreibzugriff ermöglicht sein bzw. werden.
In verschiedenen Ausführungsbeispielen kann der Security-Schaltkreis 220 eingerichtet sein, bei einer fehlgeschlagenen Authentifizierung weder den Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen. Gegebenenfalls kann der Security-Schaltkreis 220 ferner eingerichtet sein, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen, beispielsweise in der Vorrichtung.
In verschiedenen Ausführungsbeispielen kann der Security-Schaltkreis 220 eingerichtet sein, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen. Der zusätzliche Parameter kann beispielsweise eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betreffen.
Die Berücksichtigung der Relevanz des Lese- bzw. Lese-/Schreibzugriffs für die Betriebssicherheit der Vorrichtung kann bedeuten, dass der Security-Schaltkreis 220 eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff (oder auch dem kompletten Untersagen des Zugriffs) klar zu unterscheiden zwischen einer Debug-Anweisung, welche kritisch sein kann für eine Betriebssicherheit (z.B. „Anhalten/Stoppen“, „Pausieren“ usw.) und anderen Debug-Anweisungen, welche lediglich eine überwachende Funktion haben (z.B. zählen, nachverfolgen usw.). Dabei können üblicherweise die betriebssicherheitskritischen Anweisungen einen Schreibzugriff erfordern, während für die überwachenden Funktionen üblicherweise ein reiner Lesezugriff ausreichend sein kann. In manchen Fällen, beispielsweise bei einem Auslesen eines Speichers (z.B. einer der Speicher 130), welcher nach dem Auslesen automatisch überschrieben wird, kann gegebenenfalls auch der reine Lesezugriff als betriebssicherheitskritisch einzustufen sein.
Die Berücksichtigung des Betriebszustands der Vorrichtung kann bedeuten, dass der Security-Schaltkreis 220 eingerichtet sein kann, den Lese- und Schreibzugriff (oder auch einen betriebssicherheitskritischen Lesezugriff), auf alle Bereiche des Steuer-Schaltkreises 102 oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises 102 vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff (oder auch einen betriebssicherheitskritischen Lesezugriff) auf auf alle Bereiche 128, 130 des Steuer-Schaltkreises 102 oder zumindest auf einen oder mehrere der ausgewählten Bereiche 128, 130 des Steuer-Schaltkreises 102 zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
Der erste vorbestimmte Betriebszustand kann ein „aktiv“-Betriebszustand sein, mit anderen Worten ein Betriebszustand, in welchem die Vorrichtung aktiv bzw. in Betrieb ist, beispielsweise ein laufender Motor, ein diagnostisches medizinisches Gerät während des Betriebs o.ä.
Der erste vorbestimmte Betriebszustand kann ein „inaktiv“-Betriebszustand sein, mit anderen Worten ein Betriebszustand, in welchem die Vorrichtung inaktiv bzw. nicht in Betrieb oder in einem Ruhe-/Pausenzustand ist, beispielsweise ein KFZ, welches zur Reparatur in einer Werkstatt steht oder ähnliches.
Anhand der oben beschriebenen Kriterien können für das System-on-Chip 200 verschiedene Diagnosemodi erzeugt werden.
Beispielsweise kann ein so genannter „Safe-enabled“ Modus bereitgestellt werden, bei welchem die Zugriffsberechtigungen so eingestellt sind (nur Leseberechtigungen, oder sogar nur solche Leseberechtigungen, bei welchen ein Überschreiben nach dem Lesen ausgeschlossen ist), dass lediglich ein Monitoring von Zuständen des Steuer-Schaltkreises 102 bzw. der Vorrichtung möglich ist.
Lediglich ein so genanntes on-chip Trace System (Teil eines Diagnoseschaltkreises (Debug- und Trace-Systems DTS) 290) muss durch Schreibzugriffe konfiguriert werden, falls es in diesem Modus verwendet wird. In diesem Fall kann, z.B. unter Verwendung der Master-Tags, eine Konfiguration der zugriffsberechtigten Master derart eingestellt sein, dass das on-chip Trace-System nur durch den Security-Schaltkreis 220 konfigurierbar ist. Dadurch kann sichergestellt sein bzw. werden, dass das DTS 290 nicht durch Schadsoftware genutzt werden kann, die z.B. auf einer der CPUs 128 läuft, um mit dem Trace System den Steuer-Schaltkreis 102, und insbesondere die Software und Daten, zu analysieren.
Ein solcher Modus könnte beispielsweise während des Betriebs der Vorrichtung eingestellt sein bzw. werden. Dabei kann ein Zugriff beispielsweise mittels einer Cloud für eine sichere („safe und secure“) Ferndiagnose genutzt werden.
Als weiteres Beispiel kann ein so genannter „Privilegierter Debug-Modus“ bereitgestellt werden, bei welchem nur ausgewählten Berechtigten zusätzlich zur Leseberechtigung auch eine Schreibberechtigung zugewiesen sein kann. Damit kann zusätzlich zum Monitoring von Zuständen des Steuer-Schaltkreises 102 bzw. der Vorrichtung beispielsweise durch einzelne Zugriffsberechtigte auch ein Debug ermöglicht sein bzw. werden. Ein solcher Modus könnte beispielsweise während eines Testbetriebs der Vorrichtung eingestellt sein bzw. werden. Mit diesem oder einem ähnlichen Modus kann beispielsweise ein sicheres (hauptsächlich informationstechnisch sicheres) Fern-Debugging ermöglicht werden, beispielsweie bei einem direkten Zugriff auf ein Netzwerk der Vorrichtung (z.B. ein KFZ-Netzwerk).
Während oder nach einer Herstellung des SoC 200 und/oder seinem Verbinden mit der Vorrichtung kann es sinnvoll oder nötig sein, die Zugriffsberechtigungen nicht zu beschränken. Bei einem solchen „Setup“- oder „Installationsmodus“ kann ein im Wesentlichen unbeschränkter Lese- und Schreibzugriff auf den Steuer-Schaltkreis 102 ermöglicht sein.
Die Berücksichtigung des Zeitpunkts der Bereitstellung des Zertifikats kann es ermöglichen, Zertifikate mit einer begrenzten Gültigkeitsdauer bereitzustellen, beispielsweise um für eine begrenzte Dauer nach der Herstellung oder nach einer Wartung/Reparatur Informationen abgreifen zu können.
Das System-on-Chip 200 kann eingerichtet sein, den Kommunikationspfad infolge einer Anweisung des Diagnosesystems 104, des Security-Schaltkreises 220 und/oder des Steuerschaltkreises 102 zu schließen. Das System-on-Chip 200 kann ferner eingerichtet sein, nach dem Schließen des Kommunikationspfads einen Neustart auszuführen.
Das in 2B dargestellte System-on-Chip 200 gemäß verschiedenen Ausführungsbeispielen dient einer Veranschaulichtung dessen, dass der Security-Schaltkreis 220 auf den gesamten Chip zugreifen kann und den sicheren Kommunikationspfad bereitstellt, nämlich beispielsweise mittels einer Kommunikations-(COM-)Peripherie 140, z.B. über Ethernet. Das bedeutet, dass das nicht dargestellte Diagnosesystem 104 von außerhalb des SoC 200 in 2B mit der COM-Peripherie verbunden wäre, anders ausgedrückt, dass die CPU in der Lage ist, jegliche Kommunikations-(COM-)Peripherie 140, z.B. das Ethernet, zu nutzen, um mit dem externen Host des Diagnosesystemes 104 als Analysewekzeug zu kommunizieren.
Ferner ist veranschaulicht, dass der Security-Schaltkreis 220 das System (z.B. Software, z.B. auf der CPU bereitgestellt oder als Teil einer virtuellen Maschine) für die Diagnose des Steuer-Schaltkreises 102 bereitstellt. Der DiagnoseSchaltkreis 290 ist hier als DTS bezeichnet. Auch wenn in 2B spezielle Verbindungen zwischen dem Security-Schaltkreis 220 und der Kommunikations-(COM-)Peripherie 140 einerseits bzw. dem DTS 290 andererseits dargestellt sind, können diese Datenverbindungen auch mittels herkömmlicher on-Chip-Busse oder Netzwerke bereitgestellt werden.
In diesem Fall muss sichergestellt sein bzw. werden, dass der Diagnoseschaltkreis (DTS) 290 nicht durch Schadsoftware genutzt werden kann, die z.B. auf einer der CPUs 128 läuft. Die Konfiguration der zugriffsberechtigten Master muss also erlauben, diese auf alle aus Security-Sicht vertrauenswürdigen Master einzuschränken.
Dieses Trace System darf dann nur duch den Security-Schaltkreis konfigurierbar sein. Ansonsten könnte eine Schadsoftware, die auf irgendeiner der CPUs 128 läuft, dazu verwendet werden um mit dem Trace System den Steuer-Schaltkreis, und insbesondere die Software und Daten zu analysieren.
Zusammenfassend wird ein System bereitgestellt, bei welchem eine Software auf einer Security-CPU oder einer Security virtuellen Maschine läuft, welche mit einer externen Tool-Software über ein Netzwerk kommuniziert und Diagnose- und Debug-Hardware-Ressourcen gemäß Anweisungen von der externen Tool-Software steuert. Dabei kann die Kommunikation hinsichtlich ihrer Datensicherheit gesichert sein, also z.B. authentifiziert und/oder verschlüsselt.
Die Software kann in verschiedenen Ausführungsbeispielen eingerichtet sein, Daten (z.B. Überwachungs-/Nachverfolgungsdaten) hoch- und/oder runterzuladen, Breakpoints zu setzen, ein Überwachungssystem zu konfigurieren.
In verschiedenen Ausführungsbeispielen können unterschiedliche Berechtigungslevel vorab vereinbart werden und dann entsprechend dem Berechtigungslevel (z.B. mittels des Security-Schaltkreises 220) ein Umfang erlaubter Handlungen beschränkt sein oder werden.
Ein je nach Berechtigungslevel einstellbarer Umfang erlaubter Handlungen kann, wie z.B. oben beschrieben, dazu genutzt werden, klar zu trennen zwischen betriebssicherheitsrelevanten Debug-Handlungen (Anhalten, Pausieren usw.) und anderen Debug-Handlungen (Zählen, Nachverfolgen usw.).
In verschiedenen Ausführungsbeispielen kann mittels des System-on-chip ein Nachverfolgungssystem bereitgestellt werden, welches es ermöglicht, einen Umfang von Handlungen und Nachverfolgungen auf einem virtuelle-Maschine-Level zu beschränken. Das kann beispielsweise bedeuten, dass nur der Programm- und/oder Datentrace für eine bestimmte virtuelle Maschine möglich ist.
In verschiedenen Ausführungsbeispielen kann ein zur Authentifizierung genutzter Schlüssel für das Zertifikat statisch oder dynamisch geändert werden (z.B. entsprechend einem gemeinsam vereinbarten Schlüssel-Verteilungs-Protokoll).
Dadurch, dass die Diagnoseanweisungen dem Steuer-Schaltkreis mittels der Security-CPU 118 des Security-Schaltkreises 220 bereitgestellt werden, wird auf der einen Seite keine extra für diesen Zweck bereitgestellte CPU benötigt. Auf der anderen Seite ist die Security-CPU 118 aber unabhängig von den CPUs 228 des Steuer-Schaltkreises 102, so dass beim Debuggen gegebenenfalls alle CPUs 128 angehalten werden können, ohne dass dadurch die Diagnose-Software ausfällt.
3 zeigt ein Flussdiagramm 300 eines Verfahrens zum Betreiben eines System-on-Chip gemäß verschiedenen Ausführungsbeispielen.
Das Verfahren weist auf ein Steuern einer Vorrichtung mittels eines Steuer-Schaltkreises mit einer Mehrzahl von Steuer-Schaltkreisbereichen (bei 310), ein Bereitstellen eines Kommunikationspfads zur gesicherten Kommunikation zwischen einem Security-Schaltkreis und einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem, wobei der Security-Schaltkreis einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist und eingerichtet ist, den Kommunikationspfad für die gesicherte Kommunikation mittels des Schlüsselspeichers und des Hardwarebeschleunigers bereitzustellen (bei 320), ein Entscheiden, ob dem mindestens einen ausgewählten Bereich des Steuer-Schaltkreises ein Lesezugriff oder ein Lese- und Schreibzugriff gewährbar ist in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat (bei 330), ein Ermöglichen von wahlweise nur dem Lesezugriff oder dem Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche durch den Security-Schaltkreis (bei 340), und ein Ausführen des Lesezugriffs oder des Lese- und Schreibzugriffs (bei 350).
Im Folgenden werden zusammenfassend einige Ausführungsbeispiele angegeben.

Ausführungsbeispiel 1 ist ein System-on-Chip. Das System-on-Chip kann einen Steuer-Schaltkreis mit einer Mehrzahl von Steuer-Schaltkreisbereichen aufweisen, wobei der Steuer-Schaltkreis eingerichtet ist zum Steuern einer Vorrichtung, einen Security-Schaltkreis, der einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist, wobei der Security-Schaltkreis eingerichtet ist, wahlweise nur einen Lesezugriff oder einen Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche zu ermöglichen, wobei der Security-Schaltkreis ferner eingerichtet ist, mittels des Schlüsselspeichers und des Hardwarebeschleunigers einen Kommunikationspfad zur gesicherten Kommunikation mit einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem bereitzustellen, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat zu treffen und den Lesezugriff oder den Lese- und Schreibzugriff auszuführen.
Ausführungsbeispiel 2 ist ein System-on-Chip gemäß Ausführungsbeispiel 1, wobei der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises so gestaltet ist, dass damit mindestens eine vom Diagnosesystem mittels des Kommunikationspfads an den Security-Schaltkreis übermittelte Diagnoseanweisung ausführbar ist.
Ausführungsbeispiel 3 ist ein System-on-Chip gemäß Ausführungsbeispiel 2, wobei der Security-Schaltkreis mittels einer Software zum Ausführen der gesicherten Kommunikation und/oder zu einem Bereitstellen der Diagnoseanweisung an den Steuer-Schaltkreis eingerichtet ist.
Ausführungsbeispiel 4 ist ein System-on-Chip gemäß Ausführungsbeispiel 3, wobei der Security-Schaltkreis eine CPU oder eine virtuelle Maschine aufweist, welche eingerichtet ist, die Software auszuführen.
Ausführungsbeispiel 5 ist ein System-on-Chip gemäß Ausführungsbeispiel 3 oder 4, wobei die Software einen Software-Kommunikationsstapel aufweist.
Ausführungsbeispiel 6 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 3 bis 5, wobei die Software einen Ethernet Software-Kommunikationsstapel aufweist.
Ausführungsbeispiel 7 ist ein System-on-Chip gemäß einem der Ausführungsbeispiele 4 bis 6, wobei die CPU oder die virtuelle Maschine eingerichtet ist, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises zu unterstützen, wobei der ausgewählte Bereich des Steuer-Schaltkreises eingerichtet ist, den Zugriff anhand des Master Tags zu verwehren oder zu ermöglichen.
Ausführungsbeispiel 8 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Kommunikationspfad ein Netzwerk aufweist.
Ausführungsbeispiel 9 ist ein System-on-Chip gemäß Ausführungsbeispiel 8, wobei das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweist.
Ausführungsbeispiel 10 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der mindestens eine ausgewählten Bereich des Steuer-Schaltkreises eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweist, und wobei der Security-Schaltkreis eingerichtet ist, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises zu treffen.
Ausführungsbeispiel 11 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis ferner eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung weder den Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen.
Ausführungsbeispiel 12 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen.
Ausführungsbeispiel 13 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen.
Ausführungsbeispiel 14 ist ein System-on-Chip gemäß Ausführungsbeispiel 13, wobei der zusätzliche Parameter eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betrifft.
Ausführungsbeispiel 15 ist ein System-on-Chip gemäß Ausführungsbeispiel 14, wobei die Berücksichtigung des Betriebszustands der Vorrichtung bedeutet, dass der Security-Schaltkreis eingerichtet ist, zumindest den Lese- und Schreibzugriff auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff auf auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
Ausführungsbeispiel 16 ist ein System-on-Chip gemäß Ausführungsbeispiel 15, wobei der erste Betriebszustand ein „aktiv und funktional sicher“-Betriebszustand ist.
Ausführungsbeispiel 17 ist ein System-on-Chip gemäß Ausführungsbeispiel 15, wobei der erste Betriebszustand ein „aktiv mit eingeschränkter/ohne funktionale Sicherheit“-Betriebszustand ist.
Ausführungsbeispiel 18 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff zu unterscheiden zwischen einem betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff und einem lediglich überwachenden, nicht betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff.
Ausführungsbeispiel 19 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der mindestens eine ausgewählte Bereich eine virtuelle Maschine und/oder eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises aufweist.
Ausführungsbeispiel 20 ist ein System-on-Chip gemäß Ausführungsbeispiel 19, wobei die Diagnosehardware und/oder Debughardware so konfigurierbar ist, dass sie nur durch den Security-Schaltkreis benutzbar ist.
Ausführungsbeispiel 21 ist ein System-on-Chip gemäß einem der vorhergehenden Ausführungsbeispiele, welches ferner eingerichtet ist, den Kommunikationspfad infolge einer Anweisung des Diagnosesystems, des Security-Schaltkreises und/oder des Steuerschaltkreises zu schließen.
Ausführungsbeispiel 22 ist ein Verfahren zum Betreiben eines System-on-Chip. Das Verfahren weist ein Steuern einer Vorrichtung mittels eines Steuer-Schaltkreises mit einer Mehrzahl von Steuer-Schaltkreisbereichen auf, ein Bereitstellen eines Kommunikationspfads zur gesicherten Kommunikation zwischen einem Security-Schaltkreis und einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem, wobei der Security-Schaltkreis einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist und eingerichtet ist, den Kommunikationspfad für die gesicherte Kommunikation mittels des Schlüsselspeichers und des Hardwarebeschleunigers bereitzustellen, ein Entscheiden, ob dem mindestens einen ausgewählten Bereich des Steuer-Schaltkreises ein Lesezugriff oder ein Lese- und Schreibzugriff gewährbar ist in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat, ein Ermöglichen von wahlweise nur dem Lesezugriff oder dem Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche durch den Security-Schaltkreis, und ein Ausführen des Lesezugriffs oder des Lese- und Schreibzugriffs.
Ausführungsbeispiel 23 ist ein Verfahren gemäß Ausführungsbeispiel 22, wobei der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises so gestaltet ist, dass damit mindestens eine vom Diagnosesystem mittels des Kommunikationspfads an den Security-Schaltkreis übermittelte Diagnoseanweisung ausführbar ist.
Ausführungsbeispiel 24 ist ein Verfahren gemäß Ausführungsbeispiel 22 oder 23, wobei der Security-Schaltkreis mittels einer Software zum Ausführen der gesicherten Kommunikation eingerichtet ist.
Ausführungsbeispiel 25 ist ein Verfahren gemäß Ausführungsbeispiel 24, wobei der Security-Schaltkreis eine CPU oder eine virtuelle Maschine aufweist, welche eingerichtet ist, die Software auszuführen.
Ausführungsbeispiel 26 ist ein Verfahren gemäß Ausführungsbeispiel 24 oder 25, wobei die Software einen Software-Kommunikationsstapel aufweist.
Ausführungsbeispiel 27 ist ein Verfahren gemäß einem der Ausführungsbeispiele 24 bis 26, wobei die Software einen Ethernet Software-Kommunikationsstapel aufweist.
Ausführungsbeispiel 28 ist ein Verfahren gemäß einem der Ausführungsbeispiele 25 bis 27, wobei die CPU oder die virtuelle Maschine eingerichtet ist, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises zu unterstützen, wobei der ausgewählte Bereich des Steuer-Schaltkreises eingerichtet ist, den Zugriff anhand des Master Tags zu verwehren oder zu ermöglichen.
Ausführungsbeispiel 29 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Kommunikationspfad ein Netzwerk aufweist.
Ausführungsbeispiel 30 ist ein Verfahren gemäß Ausführungsbeispiel 29, wobei das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweist.
Ausführungsbeispiel 31 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der mindestens eine ausgewählten Bereich des Steuer-Schaltkreises eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweist, und wobei der Security-Schaltkreis eingerichtet ist, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises zu treffen.
Ausführungsbeispiel 32 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis ferner eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung weder der Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen.
Ausführungsbeispiel 33 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen.
Ausführungsbeispiel 34 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen.
Ausführungsbeispiel 35 ist ein Verfahren gemäß Ausführungsbeispiel 34, wobei der zusätzliche Parameter eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betrifft.
Ausführungsbeispiel 36 ist ein Verfahren gemäß Ausführungsbeispiel 35, wobei die Berücksichtigung des Betriebszustands der Vorrichtung bedeutet, dass der Security-Schaltkreis eingerichtet ist, zumindest den Lese- und Schreibzugriff auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff auf auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
Ausführungsbeispiel 37 ist ein Verfahren gemäß Ausführungsbeispiel 36, wobei der erste Betriebszustand ein „aktiv und funktional sicher“-Betriebszustand ist.
Ausführungsbeispiel 38 ist ein Verfahren gemäß Ausführungsbeispiel 36, wobei der erste Betriebszustand ein „aktiv mit eingeschränkter/ohne funktionale Sicherheit“-Betriebszustand ist.
Ausführungsbeispiel 39 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff zu unterscheiden zwischen einem betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff und einem lediglich überwachenden, nicht betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff.
Ausführungsbeispiel 40 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, wobei der mindestens eine ausgewählte Bereich eine virtuelle Maschine und/oder eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises aufweist, wobei der ausgewählte Bereich des Steuer-Schaltkreises eingerichtet ist, den Zugriff anhand des Master Tags zu verwehren oder zu ermöglichen.
Ausführungsbeispiel 41 ist ein Verfahren gemäß einem der vorhergehenden Ausführungsbeispiele, welches ferner ein Schließen des Kommunikationspfads infolge einer Anweisung des Diagnosesystems, des Security-Schaltkreises und/oder des Steuerschaltkreises aufweist.

Claims

System-on-Chip, aufweisend: • einen Steuer-Schaltkreis mit einer Mehrzahl von Steuer-Schaltkreisbereichen, wobei der Steuer-Schaltkreis eingerichtet ist zum Steuern einer Vorrichtung; • einen Security-Schaltkreis, der einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist, • wobei der Security-Schaltkreis eingerichtet ist, wahlweise nur einen Lesezugriff oder einen Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche zu ermöglichen; • wobei der Security-Schaltkreis ferner eingerichtet ist, mittels des Schlüsselspeichers und des Hardwarebeschleunigers einen Kommunikationspfad zur gesicherten Kommunikation mit einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem bereitzustellen, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat zu treffen und den Lesezugriff oder den Lese- und Schreibzugriff auszuführen.
System-on-Chip gemäß Anspruch 1, wobei der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises so gestaltet ist, dass damit mindestens eine vom Diagnosesystem mittels des Kommunikationspfads an den Security-Schaltkreis übermittelte Diagnoseanweisung ausführbar ist.
System-on-Chip gemäß Anspruch 2, wobei der Security-Schaltkreis mittels einer Software zum Ausführen der gesicherten Kommunikation und/oder zu einem Bereitstellen der Diagnoseanweisung an den Steuer-Schaltkreis eingerichtet ist.
System-on-Chip gemäß Anspruch 3, wobei der Security-Schaltkreis eine CPU oder eine virtuelle Maschine aufweist, welche eingerichtet ist, die Software auszuführen.
System-on-Chip gemäß Anspruch 3 oder 4, wobei die Software einen Software-Kommunikationsstapel aufweist.
System-on-Chip gemäß einem der Ansprüche 3 bis 5, wobei die Software einen Ethernet Software-Kommunikationsstapel aufweist.
System-on-Chip gemäß einem der Ansprüche 4 bis 6, wobei die CPU oder die virtuelle Maschine eingerichtet ist, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises zu unterstützen, wobei der ausgewählte Bereich des Steuer-Schaltkreises eingerichtet ist, den Zugriff anhand des Master Tags zu verwehren oder zu ermöglichen.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der Kommunikationspfad ein Netzwerk aufweist.
System-on-Chip gemäß Anspruch 8, wobei das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweist.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der mindestens eine ausgewählten Bereich des Steuer-Schaltkreises eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweist, und wobei der Security-Schaltkreis eingerichtet ist, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises zu treffen.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis ferner eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung weder den Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen.
System-on-Chip gemäß Anspruch 13, wobei der zusätzliche Parameter eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betrifft.
System-on-Chip gemäß Anspruch 14, wobei die Berücksichtigung des Betriebszustands der Vorrichtung bedeutet, dass der Security-Schaltkreis eingerichtet ist, zumindest den Lese- und Schreibzugriff auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff auf auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
System-on-Chip gemäß Anspruch 15, wobei der erste Betriebszustand ein „aktiv und funktional sicher“-Betriebszustand ist.
System-on-Chip gemäß Anspruch 15, wobei der erste Betriebszustand ein „aktiv mit eingeschränkter/ohne funktionale Sicherheit“-Betriebszustand ist.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff zu unterscheiden zwischen einem betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff und einem lediglich überwachenden, nicht betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, wobei der mindestens eine ausgewählte Bereich eine virtuelle Maschine und/oder eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises aufweist.
System-on-Chip gemäß Anspruch 19, wobei die Diagnosehardware und/oder Debughardware so konfigurierbar ist, dass sie nur durch den Security-Schaltkreis benutzbar ist.
System-on-Chip gemäß einem der vorhergehenden Ansprüche, ferner eingerichtet, den Kommunikationspfad infolge einer Anweisung des Diagnosesystems, des Security-Schaltkreises und/oder des Steuerschaltkreises zu schließen.
Verfahren zum Betreiben eines System-on-Chip, aufweisend: • Steuern einer Vorrichtung mittels eines Steuer-Schaltkreises mit einer Mehrzahl von Steuer-Schaltkreisbereichen; • Bereitstellen eines Kommunikationspfads zur gesicherten Kommunikation zwischen einem Security-Schaltkreis und einem außerhalb des Security-Schaltkreises angeordneten Diagnosesystem, wobei der Security-Schaltkreis einen gesondert gesicherten Schlüsselspeicher und einen Hardwarebeschleuniger für kryptographische Operationen aufweist und eingerichtet ist, den Kommunikationspfad für die gesicherte Kommunikation mittels des Schlüsselspeichers und des Hardwarebeschleunigers bereitzustellen; • Entscheiden, ob dem mindestens einen ausgewählten Bereich des Steuer-Schaltkreises ein Lesezugriff oder ein Lese- und Schreibzugriff gewährbar ist in Abhängigkeit von einem dem Security-Schaltkreis bereitgestellten und mittels im Schlüsselspeicher gespeicherter Informationen authentifizierten Zertifikat; • Ermöglichen von wahlweise nur dem Lesezugriff oder dem Lese- und Schreibzugriff auf mindestens einen der Steuer-Schaltkreisbereiche durch den Security-Schaltkreis; und • Ausführen des Lesezugriffs oder des Lese- und Schreibzugriffs.
Verfahren gemäß Anspruch 23, wobei der Lese- bzw. der Lese- und Schreibzugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises so gestaltet ist, dass damit mindestens eine vom Diagnosesystem mittels des Kommunikationspfads an den Security-Schaltkreis übermittelte Diagnoseanweisung ausführbar ist.
Verfahren gemäß Anspruch 22 oder 23, wobei der Security-Schaltkreis mittels einer Software zum Ausführen der gesicherten Kommunikation eingerichtet ist.
Verfahren gemäß Anspruch 24, wobei der Security-Schaltkreis eine CPU oder eine virtuelle Maschine aufweist, welche eingerichtet ist, die Software auszuführen.
Verfahren gemäß Anspruch 24 oder 25, wobei die Software einen Software-Kommunikationsstapel aufweist.
Verfahren gemäß einem der Ansprüche 24 bis 26, wobei die Software einen Ethernet Software-Kommunikationsstapel aufweist.
Verfahren gemäß einem der Ansprüche 25 bis 27, wobei die CPU oder die virtuelle Maschine eingerichtet ist, eine Mehrzahl von Master Tags für einen Zugriff auf den mindestens einen ausgewählten Bereich des Steuer-Schaltkreises zu unterstützen, wobei der ausgewählte Bereich des Steuer-Schaltkreises eingerichtet ist, den Zugriff anhand des Master Tags zu verwehren oder zu ermöglichen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Kommunikationspfad ein Netzwerk aufweist.
Verfahren gemäß Anspruch 29, wobei das Netzwerk zumindest teilweise eine kabellose Datenübertragung aufweist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der mindestens eine ausgewählten Bereich des Steuer-Schaltkreises eine Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises aufweist, und wobei der Security-Schaltkreis eingerichtet ist, die Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff gesondert für jeden der Mehrzahl von ausgewählten Bereichen des Steuer-Schaltkreises zu treffen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis ferner eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung weder der Lesezugriff noch der Lese- und Schreibzugriff zu ermöglichen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei einer fehlgeschlagenen Authentifizierung einen Alarm auszulösen.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff mindestens einen zusätzlichen Parameter zu berücksichtigen.
Verfahren gemäß Anspruch 34, wobei der zusätzliche Parameter eine Relevanz des Lese- bzw. Lese-/Schreibzugriffs für eine Betriebssicherheit der Vorrichtung, einen Betriebszustand der Vorrichtung und/oder einen Zeitpunkt der Bereitstellung des Zertifikats betrifft.
Verfahren gemäß Anspruch 35, wobei die Berücksichtigung des Betriebszustands der Vorrichtung bedeutet, dass der Security-Schaltkreis eingerichtet ist, zumindest den Lese- und Schreibzugriff auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises vollständig zu untersagen, wenn die Vorrichtung in einem ersten vorbestimmten Betriebszustand ist, und/oder Lese- und Schreibzugriff auf auf alle Bereiche des Steuer-Schaltkreises oder zumindest auf einen oder mehrere der ausgewählten Bereiche des Steuer-Schaltkreises zu ermöglichen, wenn die Vorrichtung in einem zweiten vorbestimmten Betriebszustand ist.
Verfahren gemäß Anspruch 36, wobei der erste Betriebszustand ein „aktiv und funktional sicher“-Betriebszustand ist.
Verfahren gemäß Anspruch 36, wobei der erste Betriebszustand ein „aktiv mit eingeschränkter/ohne funktionale Sicherheit“-Betriebszustand ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der Security-Schaltkreis eingerichtet ist, bei der Auswahl zwischen dem Lesezugriff und dem Lese- und Schreibzugriff zu unterscheiden zwischen einem betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff und einem lediglich überwachenden, nicht betriebssicherheitsrelevanten Lesezugriff bzw. Lese- und Schreibzugriff.
Verfahren gemäß einem der vorhergehenden Ansprüche, wobei der mindestens eine ausgewählte Bereich eine virtuelle Maschine und/oder eine Diagnosehardware und/oder eine Debughardware des Steuer-Schaltkreises aufweist.
Verfahren gemäß Anspruch 40, wobei die Diagnosehardware und/oder Debughardware so konfigurierbar ist, dass sie nur durch den Security-Schaltkreis benutzbar ist.
Verfahren gemäß einem der vorhergehenden Ansprüche, ferner aufweisend: Schließen des Kommunikationspfads infolge einer Anweisung des Diagnosesystems, des Security-Schaltkreises und/oder des Steuerschaltkreises.