DE102022128183B3 - Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug - Google Patents

Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug Download PDF

Info

Publication number
DE102022128183B3
DE102022128183B3 DE102022128183.3A DE102022128183A DE102022128183B3 DE 102022128183 B3 DE102022128183 B3 DE 102022128183B3 DE 102022128183 A DE102022128183 A DE 102022128183A DE 102022128183 B3 DE102022128183 B3 DE 102022128183B3
Authority
DE
Germany
Prior art keywords
execution
validation
program data
memory
data processing
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
DE102022128183.3A
Other languages
English (en)
Inventor
Christian Günter
Karsten Schmidt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Audi AG
Original Assignee
Audi AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Audi AG filed Critical Audi AG
Priority to DE102022128183.3A priority Critical patent/DE102022128183B3/de
Application granted granted Critical
Publication of DE102022128183B3 publication Critical patent/DE102022128183B3/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

Verfahren zum Starten einer Datenverarbeitungseinrichtung (1), wobei durch eine Prüfeinrichtung (2) der Datenverarbeitungseinrichtung (1) geprüft wird, ob wenigstens eine Validierungssoftwarekomponente (3) eine Prüfbedingung (4) erfüllt, deren Erfüllung von in einem Datenspeicher (5) der Datenverarbeitungseinrichtung (1) gespeicherten Prüfprogrammdaten (6) der Validierungssoftwarekomponente (3) abhängt, wobei ausschließlich bei Erfüllung der Prüfbedingung (4) die Prüfeinrichtung (2) ein Ausführen der Validierungssoftwarekomponente (3) oder einer jeweiligen der Validierungssoftwarekomponenten (3) durch wenigstens eine Ausführungseinrichtung (7, 8) der Datenverarbeitungseinrichtung (1) auslöst, wodurch durch die jeweilige Ausführungseinrichtung (7, 8) eine jeweilige Validierungsbedingung (9) ausgewertet wird, deren Erfüllung von in dem Datenspeicher (5) der Datenverarbeitungseinrichtung (1) gespeicherten Funktionsprogrammdaten (10-13) abhängt, wobei die jeweilige Ausführungseinrichtung (7, 8) wenigstens eine durch die Funktionsprogrammdaten (10-13) implementierte Funktion (17, 15) nur dann ausführt, wenn alle Validierungsbedingungen (9) oder zumindest jene Validierungsbedingung (9) oder Validierungsbedingungen (9), die jenen Teil der Funktionsprogrammdaten (10, 11, 12, 13) auswerten, der die jeweilige Funktion (14, 15) implementiert, erfüllt ist oder sind.

Description

  • Die Erfindung betrifft ein Verfahren zum Starten einer Datenverarbeitungseinrichtung, wobei durch eine Prüfeinrichtung der Datenverarbeitungseinrichtung geprüft wird, ob wenigstens eine Validierungssoftwarekomponente eine Prüfbedingung erfüllt, deren Erfüllung von in einem Datenspeicher der Datenverarbeitungseinrichtung gespeicherten Prüfprogrammdaten der Validierungssoftwarekomponente abhängt. Daneben betrifft die Erfindung eine Datenverarbeitungseinrichtung und ein Kraftfahrzeug.
  • Insbesondere in Embedded-Anwendungen, beispielsweise im Kraftfahrzeugbereich, ist es häufig hochrelevant, die Integrität und Authentizität von ausgeführter Software sicherzustellen und diese beispielsweise vor Manipulationen durch Angreifer zu schützen. In einigen Fällen kann es hierzu ausreichen, entsprechende Softwarekomponenten in internen Speichern von Ausführungseinrichtungen, also beispielsweise in Steuereinrichtungen bzw. Host-Controllern, zu speichern.
  • Da jedoch häufig eine zusätzliche Sicherung gewünscht ist und zudem der Trend dazu geht, auf interne Speicher in Bauteilen, beispielsweise in Mikrocontrollern, die bestimmte Funktionalitäten implementieren sollen, zu verzichten bzw. zumindest zusätzlich externe Speicher, z. B. Flash-Speicher, zu verwenden, sind häufig weitere Ansätze zur Softwareabsicherung erforderlich.
  • Eine besonders robuste Art der Sicherstellung der Integrität und Authentizität von Software ist der sogenannte „Secure Boot“-Ansatz, bei dem jegliche Software vor der Ausführung zunächst durch einen Prüfalgorithmus geprüft wird. Beispiele für dieses Vorgehen sind beispielsweise aus den Druckschriften DE 602 23 418 T2 und DE 11 2007 000 363 T5 bekannt.
  • Nachteilig an der Prüfung der gesamten Software vor dem Starten der Datenverarbeitungseinrichtung ist jedoch, dass dies zu merklichen Startverzögerungen führen kann, die insbesondere im Embedded-Bereich bzw. bei einer Nutzung im Kraftfahrzeug von Nutzern als sehr störend empfunden werden. Erschwerend kommt hinzu, dass in Embedded-Anwendungen häufig nur eine relativ geringe Rechenleistung bereitsteht, um eine entsprechende Softwareprüfung durch vertrauenswürdige Komponenten durchzuführen. Hierdurch verlängert sich die Startzeit noch weiter.
  • Daher erfolgt im Kraftfahrzeug- bzw. Embedded-Bereich häufig ein Rückfall auf einen „Authenticated Boot“-Ansatz, bei dem die Software erst nach dem Starten geprüft wird. Da hierbei jedoch Software bereits ausgeführt wird, bevor Fehler oder Manipulationen entdeckt werden können, ist dieser Ansatz beispielsweise für Safety-relevante Anwendungen häufig nicht ohne weiteres nutzbar. Unter einer Safety-relevanten Anwendungen werden hierbei insbesondere Anwendungen verstanden, bei denen eine Fehlfunktion zu einer Gefährdung oder Schädigung von Personen führen kann. Entsprechende Anforderungen können beispielsweise durch ein Automotive-Safety-Integrity Level (ASIL) gemäß ISO 26262 vorgegeben sein.
  • Die Druckschrift US 2020 / 0 213 287 A1 betrifft die Sicherung von elektronischen Steuereinrichtungen in einem Kraftfahrzeug. Zum Starten eines System-on-a-Chip beziehungsweise einer jeweiligen elektronischen Steuereinrichtung wird zunächst ein primärer Bootloader aus einem ROM geladen, der einen sekundären Bootloader nachlädt und prüft, der wiederum einen universellen Bootloader nachlädt und prüft.
  • In dem Verfahren zum sicheren Starten einer Gerätesoftware gemäß der Druckschrift WO 2021 / 094 105 A1 werden eine Mehrzahl von aufeinanderfolgenden Softwaremodulen ausgeführt, indem jeweils ein vorangehendes Softwaremodul das nachfolgende Softwaremodul nachlädt und überprüft.
  • Der Wikipedia Artikel „Das U-Boot“ (https://en.wikipedia.org/w/index.php?title=Das_U-Boot&oldid=1109894053) betrifft den namensgleichen Bootloader und erläutert, dass zunächst ein sogenannter „Secodary Program Loader“ geladen werden kann, der den vollständigen Bootloader nachlädt.
  • Weitere mögliche Ausgestaltungen von Startvorgängen für Datenverarbeitungsvorrichtungen sind beispielsweise aus den Druckschriften US 2018 / 0 181 759 A1 , GB 2 595 509 A und DE 10 2017 100 116 A1 bekannt.
  • Der Erfindung liegt somit die Aufgabe zugrunde, die Integrität und Authentizität von durch eine Datenverarbeitungseinrichtung ausgeführter Software mit einer ähnlichen oder insbesondere mit der gleichen Robustheit wie bei einem „Secure-Boot“-Ansatz zu erreichen und hierbei dennoch die Startzeit des Systems zu reduzieren.
  • Diese Aufgabe wird erfindungsgemäß durch ein Verfahren der eingangs genannten Art gelöst, wobei ausschließlich bei Erfüllung der Prüfbedingung die Prüfeinrichtung ein Ausführen der Validierungssoftwarekomponente oder einer jeweiligen der Validierungssoftwarekomponenten durch wenigstens eine Ausführungseinrichtung der Datenverarbeitungseinrichtung auslöst, wodurch durch die jeweilige Ausführungseinrichtung eine jeweilige Validierungsbedingung ausgewertet wird, deren Erfüllung von in dem Datenspeicher der Datenverarbeitungseinrichtung gespeicherten Funktionsprogrammdaten abhängt, wobei die jeweilige Ausführungseinrichtung wenigstens eine durch die Funktionsprogrammdaten implementierte Funktion nur dann ausführt, wenn alle Validierungsbedingungen oder zumindest jene Validierungsbedingung oder Validierungsbedingungen, die jenen Teil der Funktionsprogrammdaten auswerten, der die jeweilige Funktion implementiert, erfüllt ist oder sind, wobei der Datenspeicher durch mehrere Teilspeicher gebildet ist, wobei ein erster der Teilspeicher der Prüfeinrichtung zugeordnet oder als Teil der Prüfeinrichtung ausgebildet ist und die Prüfprogrammdaten dauerhaft speichert, wobei den Ausführungseinrichtungen ein gemeinsamer oder ein jeweiliger zweiter der Teilspeicher zugeordnet ist, der einerseits durch die Ausführungseinrichtungen oder die jeweilige Ausführungseinrichtung lesbar ist und andererseits durch die Prüfeinrichtung beschreibbar ist, wobei der Schritt des Auslösens der Ausführung der oder der jeweiligen Validierungssoftwarekomponente das Kopieren der oder der jeweiligen Prüfprogrammdaten aus dem ersten Teilspeicher oder einem dritten Teilspeicher, in den die Prüfprogrammdaten vorangehend durch die Prüfeinrichtung kopiert wurden, in den oder den jeweiligen zweiten Teilspeicher umfasst.
  • Der Erfindung liegt die Idee zugrunde, wenigstens eine Ausführungseinrichtung zusätzlich zur Validierung von Funktionsprogrammdaten heranzuziehen, wobei durch die vorangehende Prüfung der Validierungssoftwarekomponente durch die Prüfeinrichtung sichergestellt werden kann, dass die Validierungssoftwarekomponente nicht fehlerhaft bzw. manipuliert ist. Die Prüfeinrichtung und die von dieser ausgeführten Software kann als Root-of-Trust betrachtet werden. Eine hinreichende Manipulationssicherheit der Prüfeinrichtung kann durch im Stand der Technik an sich bekannte Mittel zur Manipulationsabwehr, beispielsweise durch die Nutzung eines internen Datenspeichers in der Prüfeinrichtung, der nicht oder nur unter bestimmten Bedingungen erneut beschreibbar ist oder Ähnliches, erreicht werden.
  • Die Mitbenutzung der wenigstens einen Ausführungseinrichtung zur Programmdatenvalidierung ist insbesondere vorteilhaft, da in Embedded- bzw. Kraftfahrzeuganwendungen häufig Ausführeinrichtungen mit einer höheren Rechenleistung als die Prüfeinrichtung und/oder relativ viele Ausführeinrichtungen bereitstehen, so dass durch Mitbenutzung der Ausführungseinrichtungen zur Softwarevalidierung der Startprozess erheblich, beispielsweise um den Faktor 3 bis 10, beschleunigt werden kann. Durch das erfindungsgemäße Vorgehen kann somit die Startzeit einer Datenverarbeitungseinrichtung auch dann auf ein vertretbares Maß reduziert werden, wenn eine Prüfeinrichtung bzw. eine der Root-of-Trust zugeordnete Recheneinrichtung genutzt wird, die selbst relativ leistungsschwach ist, da diese im erfindungsgemäßen Verfahren primär nur die Validierungssoftwarekomponenten validieren muss, die typischerweise relativ kompakt sind und somit mit relativ geringer Rechenleistung validierbar sind.
  • Die Auswertung der Prüfbedingung kann beispielsweise durch einen Bootloader der Prüfeinrichtung bzw. eine durch diesen nachgeladene Softwarekomponente implementiert sein, der bzw. die unmittelbar nach dem Start der Datenverarbeitungseinrichtung, beispielsweise nach einem Zurücksetzen oder einer Unterbrechung der Stromversorgung, ausgeführt wird. Die wenigstens eine Ausführungseinrichtung kann nach dem Starten der Datenverarbeitungseinrichtung zunächst nicht betrieben werden und ein Betrieb der wenigstens einen Ausführungseinrichtung nach dem Starten kann unmittelbar mit dem Starten der Prüfsoftwarekomponente beginnen.
  • Der Datenspeicher kann insbesondere mehrere Teilspeicher umfassen, wobei insbesondere der Prüfeinrichtung und der jeweiligen Ausführungseinrichtung wenigstens ein jeweiliger Teilspeicher zugeordnet ist. Insbesondere können der Prüfeinrichtung und der jeweiligen Ausführungseinrichtung jeweils ein flüchtiger Teilspeicher, insbesondere ein RAM-Speicher bzw. Arbeitsspeicher, und ein stromlos datenerhaltender Teilspeicher, beispielsweise ein Flash-Speicher, ein EPROM oder Ähnliches, zugeordnet sein. In der Prüfeinrichtung und/oder der jeweiligen Ausführungsbeinrichtung kann jeweils wenigstens einer der Teilspeicher integriert sein, beispielsweise in einem Mikrocontroller, Mikroprozessor oder Ähnliches, der die entsprechende Komponente implementiert.
  • Die Ausführungseinrichtung ist separat von der Prüfeinrichtung ausgebildet, beispielsweise als separates Bauteil bzw. als separater Schaltungsabschnitt.
  • Sind der Prüfeinrichtung und der jeweiligen Ausführungseinrichtung bzw. allen Ausführungseinrichtungen gemeinsam separate Speicherbereiche bzw.
  • Teilspeicher zugeordnet, so sind die Prüfprogrammdaten vorzugsweise in einem der Prüfeinrichtung zugeordneten Teilspeicher bzw. Speicherbereich, der insbesondere in eine die Prüfeinrichtung implementierende Komponente integriert sein kann, gespeichert. Hierdurch kann die Manipulationssicherheit weiter erhöht werden. Nach Erfüllung der Prüfbedingung können die Prüfprogrammdaten in einen der jeweiligen Ausführungseinrichtung zugeordneten Teilspeicher bzw. Speicherbereich, beispielsweise in ein Arbeits-RAM der Ausführungseinrichtung, kopiert werden, um durch die Ausführungseinrichtung ausgeführt zu werden.
  • Die Prüfbedingung bzw. die Validierungsbedingung können die Integrität bzw. Authentizität der jeweiligen Programmdaten durch übliche Ansätze, beispielsweise durch die Bildung von Prüfsummen, die Berechnung eines Hashs oder Ähnliches, prüfen. Insbesondere kann ein kryptographischer Hash berechnet bzw. eine digitale Signatur geprüft werden, um auch gezielte Angriffe bzw. Manipulationen robust zu erkennen. Diverse Ansätze zur Signatur von Programmdaten und zur Prüfung entsprechender Signaturen sind im Stand der Technik an sich bekannt und sollen daher nicht detailliert erläutert werden. Rein beispielshaft kann ein kryptographischer Hashwert der Programmdaten berechnet und mit einem geheimen Schlüssel eines asymmetrischen Kryptographieverfahrens verschlüsselt werden. Zur Prüfung kann der entsprechende Wert durch den öffentlichen Schlüssel wieder entschlüsselt und mit dem erneut berechneten Hashwert verglichen werden.
  • Vorzugsweise umfasst die Datenverarbeitungseinrichtung mehrere Ausführungseinrichtungen, wobei die durch wenigstens zwei der Ausführungseinrichtungen ausgewerteten Validierungsbedingungen von voneinander unterschiedlichen Teilen der Funktionsprogrammdaten abhängen. Anders ausgedrückt können unterschiedliche Ausführungseinrichtungen unterschiedliche Speicherbereiche des Datenspeichers validieren. Insbesondere kann zwischen den durch die verschiedenen Ausführungseinrichtungen validierten Teilen der Funktionsprogrammdaten bzw. Speicherbereiche des Datenspeichers kein Überlapp existieren. Durch das beschriebene Vorgehen kann die Validierung der Funktionsprogrammdaten erheblich beschleunigt werden, da verschiedene Speicherbereiche bzw. Teile der Funktionsprogrammdaten parallel durch die verschiedenen Ausführungseinrichtungen validiert werden.
  • In einer vorteilhaften Ausgestaltung ist jeder der Ausführungseinrichtungen ein separater Speicherbereich bzw. Teilspeicher des Datenspeichers der Datenverarbeitungseinrichtung zugeordnet, der bei der Ausführung der Validierungssoftwarekomponente bzw. einer jeweiligen Validierungssoftwarekomponente auf der jeweiligen Ausführungseinrichtung geprüft wird und der insbesondere die Funktionsprogrammdaten aller durch die jeweiligen Ausführungseinrichtung implementierten Funktionen umfasst. Hierdurch kann eine Art Selbsttest der einzelnen Ausführungseinrichtungen implementiert werden, wodurch beispielsweise eine Kommunikationslast eines Kommunikationsbusses, an dem die verschiedenen Ausführungseinrichtungen mit jeweils zugeordneten Teilspeichern angeschlossen sind, reduziert werden, da ein Großteil der im Rahmen der Validierung erforderlichen Kommunikation zwischen der jeweiligen Ausführungseinrichtung und dem zugeordneten Teilspeicher erfolgt und so den Kommunikationsbus nicht belastet.
  • Andererseits kann es in einigen Anwendungsfällen auch vorteilhaft sein, wenn zumindest eine der Ausführungseinrichtungen Funktionsprogrammdaten prüft, die eine Funktion auf einer anderen Ausführungseinrichtung implementieren sollen. Dies kann beispielsweise vorteilhaft sein, wenn sich die verschiedenen Ausführungseinrichtungen deutlich in ihrer verfügbaren Rechenleistung unterscheiden bzw. wenn die durch die verschiedenen Ausführungseinrichtungen zu implementierten Funktionen deutlich unterschiedlich umfangreiche Funktionsprogrammdaten benötigen.
  • Es ist vorteilhaft, wenn alle Ausführungseinrichtungen voneinander unterschiedliche Teile der Funktionsprogrammdaten prüfen, um eine optimale Parallelisierung der Prüfung und somit eine minimale Starterzeit zu erreichen. Es kann jedoch auch gewünscht sein, zumindest Teile der Funktionsprogrammdaten redundant zu prüfen, so dass beispielsweise Teile der Funktionsprogrammdaten durch zwei oder mehr Ausführungseinrichtungen validiert werden können.
  • Vorzugsweise kann die Prüfeinrichtung das Ausführen der gleichen Validierungssoftwarekomponente durch mehrere oder alle der Ausführungseinrichtungen auslösen. Gegenüber der Nutzung einer separaten Validierungssoftwarekomponente für jede der Ausführungseinrichtungen wird hierdurch die Menge der zu prüfenden Prüfprogrammdaten reduziert, womit der erforderliche Rechenaufwand und somit auch die Startzeit der Datenverarbeitungseinrichtung reduziert werden können.
  • Besonders bevorzugt kann die Prüfeinrichtung das Ausführen der gleichen Validierungssoftwarekomponente durch mehrere oder alle der Ausführungseinrichtungen auslösen, wobei durch eine seitens der Prüfeinrichtung vorgegebene, voneinander unterschiedliche Parametrisierung dieser Validierungssoftwarekomponente auf den unterschiedlichen Ausführungseinrichtungen im Rahmen der jeweiligen Validierungsbedingung voneinander unterschiedliche Teile der Funktionsprogrammdaten ausgewertet werden können. Als Parameter können insbesondere eine Start- und/oder Endadresse eines zu prüfenden Blocks der Funktionsprogrammdaten angegeben werden. Ergänzend oder alternativ kann beispielsweise für eine direkte Prüfsummenprüfung auch die zu erreichende Prüfsumme angegeben werden. Erfolgt eine Signaturprüfung zur Validierung, so ist es beispielsweise auch möglich, den Schlüssel als einen der Parameter vorzugeben, wodurch beispielsweise durch entsprechende Parametrisierung auch Programmdaten geprüft werden können, die, beispielsweise durch unterschiedliche Hersteller, mit unterschiedlichen Schlüsseln signiert sind.
  • Der Datenspeicher ist erfindungsgemäß durch mehrere Teilspeicher gebildet, wobei ein erster der Teilspeicher der Prüfeinrichtung zugeordnet oder als Teil der Prüfeinrichtung ausgebildet ist und die Prüfprogrammdaten dauerhaft speichert, wobei den Ausführungseinrichtungen ein gemeinsamer oder ein jeweiliger der Teilspeicher zugeordnet ist, der einerseits durch die Ausführungseinrichtungen oder die jeweilige Ausführungseinrichtung lesbar ist und andererseits durch die Prüfeinrichtung beschreibbar ist, wobei der Schritt des Auslösens der Ausführung der oder der jeweiligen Validierungssoftwarekomponente das Kopieren der oder der jeweiligen Prüfprogrammdaten aus dem ersten Teilspeicher oder einem dritten Teilspeicher, in den die Prüfprogrammdaten vorangehend durch die Prüfeinrichtung kopiert wurden, in den oder den jeweiligen zweiten Teilspeicher umfasst.
  • Bei den Teilspeichern kann es sich hierbei insbesondere um physische Komponenten, also insbesondere um Speicherbausteine, handeln bzw. sie können in die jeweiligen Prüf- bzw. Ausführungseinrichtung integriert sein. Wird, wie obig erläutert, ein dritter Teilspeicher genutzt, kann es sich hierbei insbesondere um einen Arbeitsspeicher, insbesondere einen RAM-Speicher, der Prüfeinrichtung handeln. Es kann beispielsweise vorteilhaft sein, die Prüfprogrammdaten vor der Prüfung in einen solchen Arbeitsspeicher zu kopieren, da Daten häufig schneller aus einem solchen Arbeitsspeicher als beispielsweise aus einem Flash-Speicher oder Ähnlichem gelesen werden können.
  • Unter einem dauerhaften Speichern wird vorliegend ein Speichern verstanden, bei dem entsprechende Daten über eine Stromabschaltung bzw. ein Zurücksetzen der Datenverarbeitungseinrichtung hinweg gespeichert bleiben. Entsprechende Daten können insbesondere vor Verfahrensbeginn in dem Datenspeicher gespeichert sein. Ein dauerhaft speichernder Teilspeicher kann beispielsweise als Flash-Speicher, EPROM oder Ähnliches ausgebildet sein.
  • Der erste Teilspeicher kann insbesondere nicht oder zumindest nicht durch die Ausführungseinrichtungen beschreibbar sein. Der zweite Teilspeicher ist insbesondere durch die Ausführungseinrichtungen bzw. die jeweilige Ausführungseinrichtung beschreibbar und bildet insbesondere den Arbeitsspeicher.
  • Ein weiterer der Teilspeicher kann der oder der jeweiligen Ausführungseinrichtung zugeordnet sein oder als Teil der jeweiligen Ausführungseinrichtung ausgebildet sein und zumindest einen Teil der Funktionsprogrammdaten dauerhaft speichern. Die dort gespeicherten Funktionsprogrammdaten können vor der Ausführung der jeweiligen Funktion und/oder vor der Validierung insbesondere in den zweiten Teilspeicher kopiert werden, da Speicherzugriffe im Arbeitsspeicher, wie obig erläutert, häufig schneller sind als Speicherzugriffe auf einen dauerhaft speichernden Speicher.
  • Insbesondere speichert der jeweilige weitere Teilspeicher alle Funktionsprogrammdaten, die für die jeweiligen durch die jeweilige Ausführungseinrichtung implementierten Funktionen erforderlich sind. Der weitere Teilspeicher muss nicht notwendigerweise durch die Prüfeinrichtungen lesbar sein, da die Funktionsprogrammdaten im erfindungsgemäßen Verfahren durch die Ausführungseinrichtung selbst geprüft werden können, womit beispielsweise nur eine lokale Anbindung des weiteren Teilspeichers an die jeweilige Ausführungseinrichtung erforderlich ist.
  • Eine jeweilige durch die Funktionsprogrammdaten implementierte Funktion kann ein jeweiliger Bootloader für die Ausführungseinrichtung oder eine jeweilige der Ausführungseinrichtungen sein. Die Funktion eines Bootloaders ist an sich bekannt. Üblicherweise wird ein Bootloader unmittelbar nach dem Zurücksetzen bzw. Bestromen einer Ausführungseinrichtung als deren erste ausgeführte Funktion aufgerufen und lädt anschließend relevante Funktionsprogrammdaten nach bzw. startet die hierdurch implementierten Funktionen. Im erfindungsgemäßen Verfahren ist dem entsprechenden Bootloader jedoch das Ausführen der Validierungssoftwarekomponente vorgeschaltet, die anderen Funktionsprogrammdaten, insbesondere auch die Funktionsprogrammdaten des Bootloaders, zunächst validiert, so dass bereits für den Bootloader der einzelnen Ausführungseinrichtungen ein „Secure Boot“-Ansatz implementiert wird.
  • Die Prüfeinrichtung kann, insbesondere parallel zur Auswertung der jeweiligen Validierungsbedingung durch die jeweilige Ausführungseinrichtung, eine weitere Validierungsbedingung prüfen, deren Erfüllung von in dem Datenspeicher der Datenverarbeitungseinrichtung gespeicherten weiteren Funktionsprogrammdaten abhängt, wobei die Prüfeinrichtung wenigstens eine durch die weiteren Funktionsprogrammdaten implementierte Funktion der Prüfeinrichtung nur dann ausführt, wenn die weitere Validierungsbedingung erfüllt ist. Insbesondere können die weiteren Funktionsprogrammdaten Funktionen implementieren, die die Prüfeinrichtung nach dem Abschluss der anfänglichen Systemprüfung der Datenverarbeitungseinrichtung im normalen Betrieb implementieren soll. Dies können beispielsweise Funktionen zur Kommunikationsabsicherung bzw. zur Authentifizierung der Datenverarbeitungseinrichtung gegenüber externen Einrichtungen bzw. zur Prüfung der Authentifizierung externen Einrichtungen sein.
  • Die Datenverarbeitungseinrichtung kann eine Datenverarbeitungseinrichtung eines Kraftfahrzeugs sein, wobei einerseits ein Fahrbetrieb des Kraftfahrzeugs und/oder der Betrieb wenigstens eines Fahrerassistenzsystems erst nach Erfüllung der Validierungsbedingung oder der Validierungsbedingungen, und insbesondere erst nach Erfüllung der weiteren Validierungsbedingung, freigegeben werden. Dies ist beispielsweise dann relevant, wenn Teile der durch die Datenverarbeitungseinrichtung implementierten Funktionen in den Fahrbetrieb eingreifen bzw. im Rahmen des Fahrerassistenzsystems eine Safety-Relevanz aufweisen.
  • Ergänzend oder alternativ kann die Funktion oder wenigstens eine der Funktionen der Ausführungseinrichtung oder wenigstens einer der Ausführungseinrichtungen und/oder der Prüfeinrichtung in den Fahrbetrieb eingreifen und/oder eine Sicherheitsanforderungsstufe von zumindest ASIL A aufweisen. In diesem Fall ist es besonders wesentlich, entsprechende Funktionen erst dann auszuführen, wenn sie auch validiert sind, so dass der erfindungsgemäße Ansatz besonders vorteilhaft ist.
  • Die Prüfeinrichtung kann die oder die jeweilige Ausführungseinrichtung zum Ausführen der oder der jeweiligen Validierungssoftwarekomponente zurücksetzen. Hierdurch wird ein definierter Anfangszustand der Ausführungseinrichtung erreicht und es können weitere potentielle Manipulationsmöglichkeiten unterbunden werden.
  • Neben dem erfindungsgemäßen Verfahren betrifft die Erfindung eine Datenverarbeitungseinrichtung mit einem Datenspeicher, einer Prüfeinrichtung und wenigstens einer Ausführungseinrichtung, wobei die Prüfeinrichtung und die Ausführungseinrichtung zur Ausführung des erfindungsgemäßen Verfahrens eingerichtet sind.
  • Daneben betrifft die Erfindung ein Kraftfahrzeug, das eine erfindungsgemäße Datenverarbeitungseinrichtung umfasst.
  • Weitere Vorteile und Einzelheiten der Erfindung ergeben sich aus den folgenden Ausführungsbeispielen sowie den zugehörigen Zeichnungen. Hierbei zeigen schematisch:
    • 1 ein Ablaufdiagramm eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens zum Starten einer Datenverarbeitungseinrichtung,
    • 2 ein Ausführungsbeispiel eines erfindungsgemäßen Kraftfahrzeugs, das ein Ausführungsbeispiel einer erfindungsgemäßen Datenverarbeitungseinrichtung umfasst, und
    • 3 eine beispielhafte Belegung und Zusammensetzung des Datenspeichers in dem in 1 gezeigten Verfahren bzw. der in 2 gezeigten Datenverarbeitungseinrichtung.
  • 1 zeigt ein Ablaufdiagramm eines Verfahrens zum Starten einer Datenverarbeitungseinrichtung 1. Im Beispiel wird davon ausgegangen, dass es sich um die Datenverarbeitungseinrichtung 1 eines Kraftfahrzeugs 27 handelt, wie es beispielhaft in 2 dargestellt ist. Hierbei kann die Datenverarbeitungseinrichtung 1 beispielsweise dazu dienen, die in 1 gezeigten Funktionen 15 zu implementieren, die gewissen ASIL-Anforderungen genügen müssen. In diesem Fall ist eine Manipulationssicherheit der Funktionsprogrammdaten, die entsprechende Funktionen 15 implementieren, hochrelevant, weshalb es zweckmäßig ist, entsprechende Funktionsprogrammdaten vor der Nutzung entsprechender Funktionen, also beispielsweise vor Beginn des Fahrbetriebs des Kraftfahrzeugs 27, zu validieren.
  • Da eine solche Validierung, beispielsweise die Prüfung von Signaturen signierter Programmdaten, relativ rechenaufwendig ist, würde die Prüfung aller relevanten Funktionsprogrammdaten durch eine dedizierte Prüfeinrichtung 2, deren Manipulationssicherheit hinreichend sichergestellt ist und die als Root-of-Trust betrachtet werden kann, recht zeitaufwendig sein, was zu Verzögerungen des Fahrzeugstarts führen kann und somit zu Akzeptanzproblemen bei Nutzern.
  • In dem im Folgenden genauer erläuterten Verfahren wird es hingegen ermöglicht, Ausführungseinrichtungen 7, 8 der Datenverarbeitungseinrichtung zur Validierung von Funktionsprogrammdaten mitzuverwenden, wobei im Wesentlichen weiterhin die gleiche Manipulationssicherheit erreicht wird wie bei einer Überprüfung der gesamten Funktionsprogrammdaten durch die Prüfeinrichtung 2 selbst. In 2 sind aus Übersichtlichkeitsgründen nur zwei Ausführungseinrichtungen dargestellt. Wie bereits durch die Punkte zwischen den Ausführungseinrichtungen in 2 indiziert wird, sind jedoch auch mehr als zwei Ausführungseinrichtungen auf die beschriebene Weise nutzbar.
  • In Schritt S1 wird die Datenverarbeitungseinrichtung 1 gestartet bzw. zurückgesetzt. Das Verfahren beginnt somit beispielsweise dann, wenn ein Benutzer des Kraftfahrzeugs 27 dieses startet.
  • In Schritt S2 wird zunächst ausschließlich die Prüfeinrichtung 2 gestartet. Hierbei werden in üblicher Weise zunächst die Programmdaten 34 eines Bootloaders 33, die in einem nichtflüchtigen Teilspeicher 17 des Datenspeichers 5 der Datenverarbeitungseinrichtung 1 gespeichert sind, ausgeführt. Typischerweise werden die Programmdaten unmittelbar im Teilspeicher 17 ausgeführt. In einigen Fällen kann es aber auch zweckmäßig sein, Teile der Programmdaten zur Ausführung in einen als Arbeitsspeicher der Prüfeinrichtung 2 dienenden Teilspeicher 20 des Datenspeichers 5 zu laden. Während Bootloader üblicherweise nur durch eine Einrichtung selbst auszuführende Programmteile nachladen und diese vorzugsweise prüfen, dient der Bootloader 33 der Prüfeinrichtung 2 im beschriebenen Verfahren zusätzlich dazu, die Ausführungseinrichtungen 7, 8 zu initialisieren.
  • Zusätzlich zum Nachladen von durch die Prüfeinrichtung 2 später auszuführenden Programmdaten 36 und zum Prüfen dieser Programmdaten 36 wird somit durch den Bootloader 33 in Schritt S3 eine Prüfbedingung 4 ausgewertet, deren Erfüllung von in dem Datenspeicher 5 bzw. konkret in dem Teilspeicher 17 gespeicherten Prüfprogrammdaten 6 abhängt, die nicht durch die Prüfeinrichtung 2 selbst, sondern durch die Ausführeinrichtungen 7, 8 ausgeführt werden sollen.
  • Beispielsweise kann die Prüfbedingung 4 prüfen, ob eine Signatur der Prüfprogrammdaten 6 gültig ist. Ist dies nicht der Fall, so ist die Prüfbedingung 4 nicht erfüllt. Vorzugsweise ist die Prüfbedingung 4 auch dann nicht erfüllt, wenn eine Prüfung der Programmdaten 34 des Bootloaders 33 bzw. der später noch erläuterten Programmdaten 36 fehlschlägt, also beispielsweise, wenn diese keine gültige Signatur aufweisen.
  • Im Falle der Nichterfüllung der Prüfbedingung 4 endet das Verfahren in Schritt S13, beispielsweise indem ein Hinweis auf die Fehlfunktion über eine Hinweiseinrichtung 37 ausgegeben wird und, je nachdem welche Funktion 15 durch die Datenverarbeitungseinrichtung 1 implementiert wird, der Fahrbetrieb 28 vollständig unterbunden wird bzw. ein Fahrerassistenzsystem 29 abgeworfen bzw. degradiert wird.
  • Ist die Prüfbedingung 4 hingegen erfüllt, so bereitet die Prüfeinrichtung 2 in Schritt S4 ein Starten der Ausführungseinrichtungen 7, 8 vor, indem sie ein Kopieren 23 der Prüfprogrammdaten 6 in Teilspeicher 18, 19 des Datenspeichers 5 durchführt, wie es schematisch in 3 dargestellt ist. Die Teilspeicher 18, 19 sind durch die Prüfeinrichtung 2 zumindest beschreibbar und dienen als Arbeitsspeicher, der der jeweiligen Ausführungseinrichtung 7, 8 zugeordnet ist.
  • 3 zeigt beispielhaft eine Aufteilung des Datenspeichers 5 in mehrere Teilspeicher 17-22 sowie die Belegung dieser Teilspeicher. In 3 ist ein direktes Kopieren 23 der Prüfprogrammdaten 6 aus dem nichtflüchtigen Teilspeichern 17 dargestellt. Es kann jedoch vorteilhaft sein, die Prüfprogrammdaten 6 vorangehend bereits in einen Teilspeicher 20, der den Arbeitsspeicher der Prüfeinrichtung 2 bildet, zu kopieren und beispielsweise die Prüfbedingung auf die in den Teilspeicher 20 kopierten Daten anzuwenden, da Zugriffe auf einen solchen Arbeitsspeicher schneller sein können als Zugriffe auf nichtflüchtige Speicher. In diesem Fall ist es auch möglich, die Prüfprogrammdaten 6 aus dem Teilspeicher 20 in Teilspeicher 18, 19 zu kopieren.
  • Zusätzlich kann im Schritt S4 durch die Prüfeinrichtung 2 eine individuelle Parametrisierung der Prüfprogrammdaten 6 erfolgen, beispielsweise indem Parameterwerte in vorgegebene Speicherzellen der Teilspeicher 18, 19 geschrieben werden, so dass durch die Ausführungseinrichtungen 7, 8 beispielsweise unterschiedliche Speicherbereiche geprüft werden können oder für unterschiedliche Speicherbereiche im Rahmen einer Signaturprüfung unterschiedliche Schlüssel herangezogen werden können.
  • Alternativ zur Nutzung der gleichen Prüfprogrammdaten 6 in allen Ausführungseinrichtungen 7, 8 wäre es prinzipiell auch möglich, für verschiedene Ausführungseinrichtungen verschiedene Prüfprogrammdaten 6 zu nutzen, die vorangehend durch die Prüfeinrichtung 2 geprüft werden. Die Nutzung gemeinsamer, unter Umständen unterschiedlich parametrisierter, Prüfprogrammdaten 6 in den verschiedenen Ausführungseinrichtungen 7, 8 ist jedoch in der Regel vorteilhaft, da hierdurch der Umfang des durch die Prüfeinrichtung 2 zu prüfenden Programmcodes reduziert und somit das Starten der Datenverarbeitungseinrichtung 1 beschleunigt werden kann.
  • Die Prüfprogrammdaten 6 werden in den Teilspeichern 18, 19 an einer Adresse abgelegt, ab der eine Programmausführung bei dem in Schritt S5 durchgeführten Zurücksetzen der Ausführungseinrichtungen 7, 8 durch die Prüfeinrichtung 2 erfolgt. Dieses Zurücksetzen kann beispielsweise dadurch erfolgen, dass erst in Schritt S5 eine Bestromung der Ausführungseinrichtungen 7, 8 erfolgt und/oder es kann ein entsprechendes Rücksetzsignal gesendet werden. Somit wird in Schritt S5 eine durch die Prüfprogrammdaten 6 implementierte Validierungssoftwarekomponente 3 gestartet, wobei durch das unmittelbar vorangehende Zurücksetzen ein definierter Betriebszustand vorliegt, wodurch die Manipulationssicherheit weiter erhöht werden kann.
  • In Schritt S6 wird durch die jeweilige Ausführungseinrichtung 7, 8 bzw. die durch diese ausgeführte Validierungssoftwarekomponente 3 eine Validierungsbedingung 9 ausgewertet, deren Erfüllung Funktionsprogrammdaten 10-13 abhängt, die in dem Datenspeicher 5 bzw. im Beispiel in einem jeweiligen nichtflüchtigen Teilspeicher 21, 22, der der jeweiligen Ausführungseinrichtung 7, 8 zugeordnet ist, gespeichert sind. Beispielsweise können Prüfsummen, Signaturen der Programmdaten oder Ähnliches geprüft werden.
  • Ist die Validierungsbedingung 9 in einer der Ausführungseinrichtungen 7, 8 bzw. für bestimmte Teile der Funktionsprogrammdaten 10-13 nicht erfüllt, so wird das Verfahren unmittelbar mit dem bereits obig erläuterten Schritt S13 beendet. In alternativen Ausgestaltungen wäre es jedoch auch möglich, in Fällen, in denen nur Funktionsprogrammdaten bestimmter Funktionen eine jeweilige Validierungsbedingung nicht erfüllen, nur diese Funktionen abzuwerfen. Dies kann beispielsweise dann zweckmäßig sein, wenn mit dem erfolgreich validierten Funktionsumfang weiterhin ein Fahrbetrieb möglich ist, beispielsweise wenn nur Komfortfunktionen fehlerhaft bzw. kompromittiert sind.
  • Zumindest die Prüfung und insbesondere auch die später noch erläuterte Ausführung der Funktionsprogrammdaten 10-13 erfolgt vorzugsweise, während diese in den Teilspeichern 21, 22 gespeichert sind. In einigen Fällen kann es jedoch vorteilhaft sein, einen Teil der Funktionsprogrammdaten 10-13 vor ihrer Ausführung in einen jeweiligen Teilspeicher 18, 19 zu kopieren, der als Arbeitsspeicher der jeweiligen Ausführungseinrichtung 7, 8 dient.
  • Im erläuterten Beispiel wird der Einfachheit halber davon ausgegangen, dass jede Ausführungseinrichtung 7, 8 Funktionsprogrammdaten jener Funktionen prüft, die sie auch selbst ausführen soll. Es kann jedoch auch zweckmäßig sein, durch wenigstens eine der Ausführungseinrichtungen 7, 8 Funktionsprogrammdaten 10-13 wenigstens einer Funktion 14, 15 zu validieren, die durch eine andere der Ausführungseinrichtungen 7, 8 ausgeführt werden soll. Dies kann einerseits dazu dienen, durch redundante Prüfung eine Manipulationssicherheit weiter zu erhöhen. Andererseits kann ein solches Vorgehen zweckmäßig sein, wenn sich die Rechenleistungen der Ausführungseinrichtungen 7, 8 deutlich voneinander unterscheiden und/oder wenn durch die verschiedenen Ausführungseinrichtungen 7, 8 Funktionsprogrammdaten mit deutlich voneinander unterschiedlichem Umfang ausgeführt werden sollen. Durch eine möglichst gleichmäßige bzw. der Rechenleistung der Ausführungseinrichtungen 7, 8 angemessene Verteilung der Validierungsaufgaben auf die Ausführungseinrichtungen 7, 8 kann ein Systemstart in den genannten Fällen weiter beschleunigt werden.
  • Wurden alle Validierungsbedingungen 9 erfüllt, so wird in Schritt S7 in der jeweiligen Ausführungseinrichtung 7, 8 zunächst die Funktion 14 gestartet, die durch die Funktionsprogrammdaten 10, 12 implementiert ist. Bei der Funktion 14 handelt es sich um einen Bootloader für die jeweilige Ausführungseinrichtung 7, 8, der dazu dient, die weiteren Funktionsprogrammdaten 11, 13 nachzuladen bzw. in Schritt S8 entsprechende Funktionen 15 zu starten.
  • Die Funktionen 15 implementieren im Beispiel einen Abstandsassistenten, der über eine Sensorik 30 Abstände zu Vorfahrzeugen erfasst und durch Ansteuerung der Bremsen 31, 32 bzw. eines nicht gezeigten Antriebsstrangs die Geschwindigkeit des Kraftfahrzeugs 27 derart regelt, dass ein vorgegebener Mindestabstand zum Vorfahrzeug nicht unterschritten wird. Zusätzlich oder alternativ zu dieser Fahrerassistenzfunktion können durch die Datenverarbeitungseinrichtung 1 jedoch auch beliebige andere Fahrerassistenzsysteme und andere Funktionen des Kraftfahrzeugs, die insbesondere in den Fahrbetrieb eingreifen können, implementiert werden.
  • Soweit zumindest Teile der implementierten Funktionen für den Fahrbetrieb relevant sind bzw. insbesondere bestimmten ASIL-Anforderungen genügen müssen, ist eine Prüfung von Programmcode von implementierten Funktionen vor deren Ausführungen zweckmäßig bzw. sogar notwendig, so dass das erläuterte Vorgehen besonders vorteilhaft ist.
  • Typischerweise soll die Prüfeinrichtung 2 nicht nur zum Starten der Ausführungseinrichtungen 7, 8 dienen, sondern auch im normalen Betrieb der Datenverarbeitungseinrichtung 1 eine oder mehrere Funktionen 26 ausführen. Hierbei kann es sich beispielsweise um kryptographische Funktionen zur Kommunikationsabsicherung bzw. zur Authentifizierung von Komponenten handeln, jedoch auch um beliebige andere Aufgaben. Dies wird im erläuterten Verfahren durch die Schritte S9 bis S11 ermöglicht.
  • Im Schritt S9 wird zunächst durch den Bootloader 33 eine weitere Validierungssoftwarekomponente 35 auf der Prüfeinrichtung 2 gestartet, deren Programmdaten 36 vorzugsweise bereits in Schritt S3 im Rahmen der Prüfbedingung 4 geprüft wurden.
  • In Schritt S10 wird durch die weitere Validierungssoftwarekomponente 35 eine weitere Validierungsbedingung 24 ausgewertet, deren Erfüllung von in dem Datenspeicher 5 bzw. konkret im Teilspeicher 17 gespeicherten weiteren Funktionsprogrammdaten 25 abhängt, die die Funktion 26 implementieren. Wie bereits zur Validierungsbedingung 9 erläutert, kann zur Validierung beispielsweise eine Signatur der Programmdaten 25 geprüft werden oder Ähnliches.
  • Ist die weitere Validierungsbedingung nicht erfüllt, impliziert dies eine Beschädigung bzw. Manipulation der weiteren Funktionsprogrammdaten 25, womit das Verfahren in Schritt S13 endet. Falls die durch die Prüfeinrichtung 2 implementierte Funktion 26 nicht notwendig erforderlich für den Fahrbetrieb des Kraftfahrzeugs 27 sein sollte, wäre es alternativ auch möglich, die Funktion 26 abzuwerfen und einen Fahrbetrieb ohne diese Funktion zu ermöglichen.
  • Ist die weitere Validierungsbedingung 24 hingegen erfüllt, so werden in Schritt S11 die weiteren Funktionsprogrammdaten 25, insbesondere nach einem Kopieren in den Teilspeicher 20, durch die Prüfeinrichtung 2 ausgeführt und somit die Funktion 26 bereitgestellt.
  • Wurden sowohl alle Validierungsbedingungen 9 als auch die weitere Validierungsbedingung 24 erfüllt, kann nach dem Bereitstellen der Funktionen 15, 26 in Schritt S12 der normale Fahrbetrieb 28 des Kraftfahrzeugs 27 freigegeben werden bzw. die Nutzung wenigstens eines durch die Datenverarbeitungseinrichtung 1 implementierten Fahrerassistenzsystems 29 freigegeben werden.

Claims (10)

  1. Verfahren zum Starten einer Datenverarbeitungseinrichtung (1), wobei durch eine Prüfeinrichtung (2) der Datenverarbeitungseinrichtung (1) geprüft wird, ob wenigstens eine Validierungssoftwarekomponente (3) eine Prüfbedingung (4) erfüllt, deren Erfüllung von in einem Datenspeicher (5) der Datenverarbeitungseinrichtung (1) gespeicherten Prüfprogrammdaten (6) der Validierungssoftwarekomponente (3) abhängt, wobei ausschließlich bei Erfüllung der Prüfbedingung (4) die Prüfeinrichtung (2) ein Ausführen der Validierungssoftwarekomponente (3) oder einer jeweiligen der Validierungssoftwarekomponenten (3) durch wenigstens eine Ausführungseinrichtung (7, 8) der Datenverarbeitungseinrichtung (1) auslöst, wodurch durch die jeweilige Ausführungseinrichtung (7, 8) eine jeweilige Validierungsbedingung (9) ausgewertet wird, deren Erfüllung von in dem Datenspeicher (5) der Datenverarbeitungseinrichtung (1) gespeicherten Funktionsprogrammdaten (10-13) abhängt, wobei die jeweilige Ausführungseinrichtung (7, 8) wenigstens eine durch die Funktionsprogrammdaten (10-13) implementierte Funktion (17, 15) nur dann ausführt, wenn alle Validierungsbedingungen (9) oder zumindest jene Validierungsbedingung (9) oder Validierungsbedingungen (9), die jenen Teil der Funktionsprogrammdaten (10, 11, 12, 13) auswerten, der die jeweilige Funktion (14, 15) implementiert, erfüllt ist oder sind, wobei der Datenspeicher (5) durch mehrere Teilspeicher (17-22) gebildet ist, wobei ein erster der Teilspeicher (17) der Prüfeinrichtung (2) zugeordnet oder als Teil der Prüfeinrichtung (2) ausgebildet ist und die Prüfprogrammdaten (6) dauerhaft speichert, wobei den Ausführungseinrichtungen (7, 8) ein gemeinsamer oder ein jeweiliger zweiter der Teilspeicher (18, 19) zugeordnet ist, der einerseits durch die Ausführungseinrichtungen (7, 8) oder die jeweilige Ausführungseinrichtung (7, 8) lesbar ist und andererseits durch die Prüfeinrichtung (2) beschreibbar ist, wobei der Schritt des Auslösens der Ausführung der oder der jeweiligen Validierungssoftwarekomponente (3) das Kopieren (23) der oder der jeweiligen Prüfprogrammdaten (6) aus dem ersten Teilspeicher (17) oder einem dritten Teilspeicher (20), in den die Prüfprogrammdaten (6) vorangehend durch die Prüfeinrichtung (2) kopiert wurden, in den oder den jeweiligen zweiten Teilspeicher (18, 19) umfasst.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Datenverarbeitungseinrichtung (1) mehrere Ausführungseinrichtungen (7, 8) umfasst, wobei die durch wenigstens zwei der Ausführungseinrichtungen (7, 8) ausgewerteten Validierungsbedingungen (9) von voneinander unterschiedlichen Teilen der Funktionsprogrammdaten (10-13) abhängen.
  3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass die Prüfeinrichtung (2) das Ausführen der gleichen Validierungssoftwarekomponente (3) durch mehrere oder alle der Ausführungseinrichtungen (7, 8) auslöst, wobei durch eine seitens der Prüfeinrichtung (2) vorgegebene, voneinander unterschiedliche Parametrisierung (16) dieser Validierungssoftwarekomponenten (3) auf den unterschiedlichen Ausführungseinrichtungen (7, 8) im Rahmen der jeweiligen Validierungsbedingung (4) voneinander unterschiedliche Teile der Funktionsprogrammdaten (10-13) ausgewertet werden.
  4. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein weiterer der Teilspeicher (21, 22) der oder der jeweiligen Ausführungseinrichtung (7, 8) zugeordnet oder als Teil der jeweiligen Ausführungseinrichtung (7, 8) ausgebildet ist und zumindest einen Teil der Funktionsprogrammdaten (10-13) dauerhaft speichert.
  5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass eine jeweilige durch die Funktionsprogrammdaten (10, 12) implementierte Funktion (14) ein jeweiliger Bootloader für die Ausführungseinrichtung (7, 8) oder eine jeweilige der Ausführungseinrichtungen (7, 8) ist.
  6. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Prüfeinrichtung (2), insbesondere parallel zur Auswertung der jeweiligen Validierungsbedingung (9) durch die jeweilige Ausführungseinrichtung (7, 8), eine weitere Validierungsbedingung (24) prüft, deren Erfüllung von in dem Datenspeicher (5) der Datenverarbeitungseinrichtung (1) gespeicherten weiteren Funktionsprogrammdaten (25) abhängt, wobei die Prüfeinrichtung (2) wenigstens eine durch die weiteren Funktionsprogrammdaten (25) implementierte Funktion (26) der Prüfeinrichtung (2) nur dann ausführt, wenn die weitere Validierungsbedingung (24) erfüllt ist.
  7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Datenverarbeitungseinrichtung (1) eine Datenverarbeitungseinrichtung (1) eines Kraftfahrzeugs (27) ist, wobei einerseits ein Fahrbetrieb (28) des Kraftfahrzeugs (27) und/oder der Betrieb wenigstens eines Fahrerassistenzsystems (29) erst nach Erfüllung der Validierungsbedingung (9) oder der Validierungsbedingungen (9), und insbesondere erst nach Erfüllung der weiteren Validierungsbedingung (24), freigegeben werden, und/oder wobei andererseits die Funktion (14, 15, 26) oder wenigstens eine der Funktionen (14, 15, 26) der Ausführungseinrichtung (7, 8) oder wenigstens einer der Ausführungseinrichtungen (7, 8) und/oder der Prüfeinrichtung (2) in den Fahrbetrieb (28) eingreift und/oder eine Sicherheitsanforderungsstufe von zumindest ASIL A aufweist.
  8. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Prüfeinrichtung (2) die oder die jeweilige Ausführungseinrichtung (7, 8) zum Ausführen der oder der jeweiligen Validierungssoftwarekomponente (3) zurücksetzt.
  9. Datenverarbeitungseinrichtung mit einem Datenspeicher (5), einer Prüfeinrichtung (2) und wenigstens einer Ausführungseinrichtung (7, 8), dadurch gekennzeichnet, dass die Prüfeinrichtung (2) und die Ausführungseinrichtung (7, 8) zur Ausführung des Verfahrens nach einem der vorangehenden Ansprüche eingerichtet sind.
  10. Kraftfahrzeug, dadurch gekennzeichnet, dass es eine Datenverarbeitungseinrichtung (1) nach Anspruch 9 umfasst.
DE102022128183.3A 2022-10-25 2022-10-25 Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug Active DE102022128183B3 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102022128183.3A DE102022128183B3 (de) 2022-10-25 2022-10-25 Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102022128183.3A DE102022128183B3 (de) 2022-10-25 2022-10-25 Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug

Publications (1)

Publication Number Publication Date
DE102022128183B3 true DE102022128183B3 (de) 2023-12-07

Family

ID=88790367

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102022128183.3A Active DE102022128183B3 (de) 2022-10-25 2022-10-25 Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug

Country Status (1)

Country Link
DE (1) DE102022128183B3 (de)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60223418T2 (de) 2001-12-20 2008-09-04 Intel Corporation, Santa Clara Bootprozeß
DE112007000363T5 (de) 2006-02-15 2008-11-27 Intel Corporation, Santa Clara Verfahren zum Bereitstellen sicherer Firmware
US20180181759A1 (en) 2016-12-27 2018-06-28 Intel Corporation Distributed secure boot
DE102017100116A1 (de) 2017-01-04 2018-07-05 Connaught Electronics Ltd. Steuersystem für ein Kraftfahrzeug mit einem zentralen Steuergerät und mehreren weiteren Steuergeräten
US20200213287A1 (en) 2018-12-27 2020-07-02 Didi Research America, Llc Trusted platform protection in an autonomous vehicle
WO2021094105A1 (de) 2019-11-14 2021-05-20 Siemens Aktiengesellschaft Verfahren zum sicheren starten einer gerätesoftware, insbesondere eines betriebssystems, eines elektronischen gerätes
GB2595509A (en) 2020-05-29 2021-12-01 Continental Automotive Gmbh Computer secure boot method and system

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60223418T2 (de) 2001-12-20 2008-09-04 Intel Corporation, Santa Clara Bootprozeß
DE112007000363T5 (de) 2006-02-15 2008-11-27 Intel Corporation, Santa Clara Verfahren zum Bereitstellen sicherer Firmware
US20180181759A1 (en) 2016-12-27 2018-06-28 Intel Corporation Distributed secure boot
DE102017100116A1 (de) 2017-01-04 2018-07-05 Connaught Electronics Ltd. Steuersystem für ein Kraftfahrzeug mit einem zentralen Steuergerät und mehreren weiteren Steuergeräten
US20200213287A1 (en) 2018-12-27 2020-07-02 Didi Research America, Llc Trusted platform protection in an autonomous vehicle
WO2021094105A1 (de) 2019-11-14 2021-05-20 Siemens Aktiengesellschaft Verfahren zum sicheren starten einer gerätesoftware, insbesondere eines betriebssystems, eines elektronischen gerätes
GB2595509A (en) 2020-05-29 2021-12-01 Continental Automotive Gmbh Computer secure boot method and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Das U-Boot. In: Wikipedia, the free encyclopedia. Bearbeitungsstand: 12.09.2022. URL: https://en.wikipedia.org/w/index.php?title=Das_U-Boot&oldid=1109894053 [abgerufen am 05.05.2023]

Similar Documents

Publication Publication Date Title
EP3437012B1 (de) Verfahren, prozessor und gerät zur integritätsprüfung von nutzerdaten
DE112016002785T5 (de) Elektronische Steuereinheiten für Fahrzeuge
EP3811261B1 (de) Kryptografiemodul und betriebsverfahren hierfür
EP3369027A1 (de) Verfahren und sicherheitsmodul zum bereitstellen einer sicherheitsfunktion für ein gerät
DE102022128183B3 (de) Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug
DE102020117552A1 (de) Sichere hybrid-boot-systeme und sichere boot-verfahren für hybridsysteme
DE10131577A1 (de) Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation seines Programms
DE102018211139A1 (de) Steuergerät sowie Verfahren zu dessen Betrieb
EP3876123B1 (de) Anordnung und betriebsverfahren für einen sicheren hochfahrablauf einer elektronischen einrichtung
DE102022125619A1 (de) Verfahren zum Starten einer Datenverarbeitungseinrichtung, Datenverarbeitungseinrichtung und Kraftfahrzeug
DE102022202691A1 (de) Verfahren zur Durchführung einer abgesicherten Startsequenz einer Recheneinheit
DE102021212994B3 (de) Verfahren zur Erkennung von auf eine Manipulation hindeutenden Anomalien während eines sicheren Startvorgangs einer softwaregesteuerten Vorrichtung
EP3074862B1 (de) Verfahren für einen sicheren hochfahrablauf eines elektronischen systems
DE102019208129B4 (de) Elektronische Steuereinheit
DE102017202787A1 (de) Verfahren und Validierungseinheit zum Steuern des Ladens von in IT-Systemen, insbesondere Eingebetteten Systemen, benutzbaren Krypto-Schlüsseln, insbesondere "Key BLOBs"
DE102022202688A1 (de) Verfahren zur Validierung von Daten in einer Recheneinheit
WO2021123024A1 (de) Vorrichtung mit einer schnittstelle und verfahren zum betreiben einer vorrichtung mit einer schnittstelle
DE102020207861A1 (de) Verfahren zur Durchführung einer abgesicherten Startsequenz eines Steuergeräts
WO2024056443A1 (de) Verfahren zum überprüfen von daten in einer recheneinheit
DE102022130951A1 (de) Steuerungsanordnung umfassend ein Steuergerät mit Fehlersuchschnittstellen und Verfahren zum Betreiben eines Steuergeräts
WO2023057506A1 (de) Recheneinheit für ein fahrzeug und verfahren und computerprogramm für eine recheneinheit für ein fahrzeug
DE102019220450A1 (de) Vorrichtung mit einer Schnittstelle und Verfahren zum Betreiben einer Vorrichtung mit einer Schnittstelle
EP4322036A1 (de) Verfahren zum booten einer elektronischen steuereinheit
EP4261722A1 (de) Ausgeben einer gemeinsamen, kryptographisch geschützten gerätekonfigurationsinformation
DE102020207863A1 (de) Verfahren zur sicheren Aktualisierung von Steuergeräten

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: G06F0021550000

Ipc: G06F0021570000

R016 Response to examination communication
R018 Grant decision by examination section/examining division