DE102024001630B3

DE102024001630B3 - Verfahren zur Validierung einer Signatur

Info

Publication number: DE102024001630B3
Application number: DE102024001630.9A
Authority: DE
Inventors: Viktor Friesen
Original assignee: Mercedes Benz Group AG
Current assignee: Mercedes Benz Group AG
Priority date: 2024-05-21
Filing date: 2024-05-21
Publication date: 2025-07-10
Anticipated expiration: 2044-05-22
Also published as: WO2025242353A1

Abstract

Die Erfindung betrifft ein Verfahren zur Validierung einer Signatur (Sig) wenigstens einer signierenden Instanz (SI) für ein System (Sys), für welches die Signatur (Sig) bestimmt ist, wobei die signierende Instanz (SI) mit einem asymmetrischen Schlüsselpaar (SIPub, SIPriv) zum Erstellen der Signatur (Sig) von zu signierenden Daten (Dat) ausgestattet ist. Die Erfindung ist dadurch gekennzeichnet, dass wenigstens eine Prüfinstanz (PI, BPI, FPI) etabliert wird, welche mit allen notwendigen Mitteln ausgestattet ist, die für eine Prüfung von von der wenigstens einen signierenden Instanz (SI) erzeugten Signaturen (Sig) notwendig sind, wobei zur Durchführung der Prüfung die zu prüfende Signatur (Sig) zusammen mit den signierten Daten (Dat) von dem System (Sys), für welches die Signatur (Sig) bestimmt ist, an die Prüfinstanz (PI. BPI, FPI) übermittelt wird, wonach die Prüfinstanz (PI, BPI, FPI) die Prüfung der Signatur (Sig) durchführt, und wonach das Ergebnis (Erg) der Prüfung an das anfragende System (Sys) übermittelt wird.

Description

Die Erfindung betrifft ein Verfahren zur Validierung einer Signatur wenigstens einer signierenden Instanz für ein System, welches das Ergebnis der Prüfung der Signatur benötigt, wobei die signierende Instanz mit einem asymmetrischen Schlüsselpaar zum Erstellen der Signatur von Daten ausgestattet ist.
In unserer zunehmend digitalisierten Welt spielt die Sicherheit in der Informationstechnologie (IT-Security) eine immer wichtigere Rolle. Viele Systeme kommunizieren nämlich über Netzwerke miteinander, wobei eine sichere Kommunikation für alle Arten von vernetzten Systemen relevant ist. Dazu gehört es im Wesentlichen, dass Kommunikationspartner Möglichkeiten benötigen, um sicherzustellen, dass sie mit derjenigen Instanz kommunizieren mit der sie kommunizieren möchten und nicht mit einer, die nur vorgibt die „Richtige“ zu sein, bzw. das Daten von derjenigen Instanz stammen, von der Sie stammen sollen und eben nicht von einem Dritten in das Netzwerk eingeschleust werden. In diesem Zusammengang kommen Signaturen zum Einsatz, die typischerweise mit einem geheimen Teil eines Schlüsselpaars über Daten erzeugt werden und vom Kommunikationspartner mit dem öffentlichen Teil desselben Schlüsselpaars geprüft werden können.
Dies spielt nicht nur, vor allem aber auch auf dem Gebiet der CarlT-Security, also der Sicherheit bei kommunizierenden Fahrzeugsystemen, eine entscheidende Rolle, da solche Systeme bzw. Steuergeräte häufig auch für sicherheitsrelevante Funktionen in den Fahrzeugen zuständig sind. Moderne Fahrzeuge sind nämlich typischerweise Teil eines großen Fahrzeug-Ökosystems. Insbesondere gehören die in den Fahrzeugen verbauten Steuergeräte zu diesem Fahrzeug-Ökosystem. Ein weiterer zentraler Teil dieses Ökosystems ist das sog. Backend, ein (i.d.R. OEM-eigener) fahrzeugexterner Server, mit dem die Fahrzeuge per Internet verbunden sind. Die Kommunikation zwischen einzelnen Steuergeräten innerhalb eines Fahrzeugs ist dabei oft integritätsgeschützt, bspw. mit dem von AUTOSAR standardisierten Verfahren SecOC (Secure Onboard Communication). Die Kommunikation zwischen Fahrzeug-Steuergeräten und anderen Teilnehmern des Fahrzeug-Ökosystems, insbesondere dem Backend, wird derzeit mit Hilfe von bekannten Standardverfahren abgesichert (meist TLS, manchmal IPSec). In manchen Situationen, beispielsweise für manche Dienste und Anwendungen, reicht der durch standardisierte Verfahren gewährleistete Basisschutz nicht aus, in diesen Fällen werden zusätzliche Sicherheitsmechanismen eingesetzt.
Ein wichtiger Bestandteil vieler solcher im Fahrzeug-Ökosystem eingesetzten Security-Mechanismen sind digitale Signaturen. Digitale Signaturen basieren auf asymmetrischer Kryptographie (bspw. RSA, ECC). Bei asymmetrischer Kryptographie werden jeweils aus einem öffentlichen Schlüssel und einem privaten Schlüssel bestehende Schlüsselpaare eingesetzt. Dabei wird jede Instanz, die Daten signieren soll, die hier „signierende Instanz“ genannt wird, mit einem solchen individuellen Schlüsselpaar ausgestattet, wobei der private Schlüssel nur dieser signierenden Instanz bekannt sein soll und der öffentliche Schlüssel an alle Instanzen verteilt wird, die von der signierenden Instanz erzeugte Signaturen prüfen können sollen, hier „prüfende Instanzen“ genannt. Idealerweise wird das Schlüsselpaar von der signierenden Instanz selbst erzeugt, anschließend wird der private Schlüssel in dieser signierenden Instanz lesegeschützt abgelegt und verlässt sie nicht mehr, wobei der öffentliche Schlüssel an die prüfenden Instanzen manipulationsgeschützt verteilt und dort manipulationsgeschützt abgelegt wird. Für das Signieren von Daten werden von der signierenden Instanz diese Daten und der eigene private Schlüssel benötigt. Das Ergebnis des Signierens von bestimmten Daten mit einem bestimmten privaten Schlüssel ist eine sogenannte digitale Signatur. Für das Prüfen der Korrektheit einer Signatur werden von der prüfenden Instanz der öffentliche Schlüssel der signierenden Instanz, die Signatur und die signierten Daten benötigt. Das Ergebnis der Prüfung ist dann ein Wahrheitswert TRUE, FALSE. Dabei ist das Prüfen der Korrektheit einer Signatur gleichbedeutend mit der Prüfung der Integrität der signierten Daten.
Für die Signaturprüfung benötigt eine prüfende Instanz also, außer der Signatur und den Daten, eine Implementierung des zum beim Signieren verwendeten Signierverfahren passenden Signaturprüfungsverfahrens und den zum beim Signieren verwendeten privaten Schlüssel passenden öffentlichen Schlüssel.
Zu einem Fahrzeug-Ökosysteme können sowohl große Server als auch kleine leistungsschwache Steuergeräte gehören, Fahrzeug-Ökosysteme sind also ausgesprochen heterogen, das bedeutet insbesondere, dass sich die Teilnehmer des Ökosystems in Bezug auf ihre Leistungsfähigkeit (Rechenleistung, Speicher etc.) stark unterscheiden können. Je nach verwendetem Verfahren können Operationen mit asymmetrischen Schlüsseln vergleichsweise ressourcenintensiv, sowohl die Rechenleistung als auch den Speicher betreffend, sein. Das kann insbesondere sowohl für das Signieren, also das Erzeugen digitaler Signaturen, als auch für das Prüfen digitaler Signaturen zutreffen. Eine Folge davon ist, dass viele Steuergeräte, insbesondere leistungsschwache Steuergeräte, nicht „alle denkbaren“ Signaturprüfungsverfahren effizient implementieren können und sich auf einige wenige Signaturprüfungsverfahren, häufig auf ein einziges Signaturprüfungsverfahren, beschränken müssen. In manchen Steuergeräten können gar keine Signaturprüfungsverfahren implementiert werden, in so einem Fall muss der Integritätsschutz ausschließlich mit Hilfe symmetrischer Verfahren sichergestellt werden. Gleichzeitig müssen die Teilnehmer des Fahrzeug-Ökosystems oft von außerhalb des eigenen Fahrzeug-Ökosystems liegenden signierenden Instanzen erzeugte Signaturen prüfen können, was ein Problem ist, da der Fahrzeughersteller in diesem Fall keinen oder nur geringen Einfluss darauf hat, welches Signierverfahren die außerhalb liegende signierende Instanz verwendet.
Wie oben bereits erwähnt, wird zum Prüfen der Signatur der öffentliche Schlüssel der signierenden Instanz benötigt, der an die prüfende Instanz manipulationssicher übermittelt und dort manipulationssicher abgelegt werden muss. Beides erfordert gewisse Fähigkeiten des Steuergerätes, die insbesondere bei leistungsschwachen Steuergeräten nicht immer gegeben sind.
Da die Lebensdauer der Fahrzeuge und damit der verbauten Steuergeräte mehrere Jahrzehnte betragen kann, kann es in dieser Zeit, bspw. aus Security-Sicht, vorteilhaft bzw. sogar notwendig werden, von einer bestimmten signierenden Instanz für das Signieren von Daten ein anderes Signierverfahren und/oder ein anderes asymmetrisches Schlüsselpaar zu verwenden. Bspw. kann es von bestimmten Behörden, bspw. dem Bundesamt für Sicherheit in der Informationstechnik (BSI), empfohlen sein, ab einem bestimmten Zeitpunkt ein bestimmtes kryptographisches Verfahren oder eine bestimmte Schlüssellänge nicht mehr zu verwenden. Sollen die Vorgaben dieser Behörde eingehalten werden, ist man gezwungen, den Wechsel rechtzeitig zu vollziehen und ein neues den Vorgaben entsprechendes Signierverfahren und/oder Schlüsselpaar zu nutzen. Ein Umstieg auf ein neues Signierverfahren und/oder neues Schlüsselpaar bei der signierenden Instanz kann auch notwendig sein, weil bspw. das ursprünglich genutzte Signierverfahren und/oder die ursprünglich genutzte Schlüssellänge nicht mehr dem Stand der Technik entsprechen und allgemein als nicht sicher genug angesehen werden.
Die Nutzung eines anderen Signierverfahrens und/oder eines anderen privaten Schlüssels durch die signierende Instanz hat zur Folge, dass jede prüfende Instanz ebenfalls Anpassungen vornehmen muss, indem ein zum neuen Signierverfahren passendes Signaturprüfungsverfahren implementiert werden muss und/oder die prüfende Instanz mit dem neuen zum beim Signieren verwendeten privaten Schlüssel passenden öffentlichen Schlüssel der signierenden Instanz ausgestattet werden muss. Diese Anpassungen erfordern ebenfalls gewisse Fähigkeiten des Steuergerätes, die insbesondere bei leistungsschwachen Steuergeräten nicht immer gegeben sind.
Zusammenfasend kann man sagen, dass die Prüfung von Signaturen gewisse Herausforderungen an insbesondere leistungsschwache Teilnehmer stellt und nicht alle Teilnehmer diese Funktion, insbesondere in der gebotenen Vielfalt und Flexibilität, effizient umsetzen können. Dies gilt z.B. in einem Fahrzeug-Ökosystems nun vor allem für die oben bereits angesprochenen Steuergeräte.
Aus dem Stand der Technik, z.B. aus der WO 2014/199 128 A1 , sind Ansätze bekannt, bei denen Geräte das Signieren von Daten, also die Erstellung einer Signatur, an eine andere mächtigere Instanz delegieren. Vgl. z.B. auch „Proxy Signatures for Delegating Signing Operation" https://dl.acm.org/doi/pdf/10.1145/238168.238185 (abgerufen am 20.3.2024) oder „A Secure Proxy Signature Scheme with Delegation by Warrant" https://sic.ici.ro/wp-content/uploads/2011/12/SIC_2011-4-Art5.pdf (abgerufen am 20.3.2024)
Zum weiteren Stand der Technik kann auf die US 2022 / 0 069 602 A1 verweisen werden. Diese beschreibt einen verschlüsselten Authentifizierung eines Nutzers an einer Ladesäule. Dabei wird die Berechtigung über einen zentralen Mobilitätsdienstleister angefragt und von diesen dann geprüft und bei positiver Prüfung bestätigt.
Die Aufgabe der hier vorliegenden Erfindung besteht nun darin, ein Verfahren zur Validierung einer Signatur wenigstens einer signierenden Instanz für ein System, welches die Signatur prüfen muss, anzugeben, welches dahingehend verbessert ist, dass die Flexibilität bei der Verwendung der Signatur erhöht wird, und dass es vor allem auch leistungsschwachen Systemen bzw. Geräten - im oben beschriebenen Sinn - eine zuverlässige Signaturprüfung ermöglicht.
Erfindungsgemäß wird diese Aufgabe durch ein Verfahren mit den Merkmalen im Anspruch 1 und hier insbesondere im kennzeichnenden Teil des Anspruchs 1 gelöst.
Weitere vorteilhafte Ausgestaltungen und Weiterbildungen des Verfahrens sind in den hiervon abhängigen Unteransprüchen angegeben.
Das erfindungsgemäße Verfahren schlägt also vor, dass neben der mit einem Signierverfahren und einem passenden asymmetrischen Schlüsselpaar ausgestatteten signierenden Instanz, welche Signaturen für ein dieses Schlüsselpaar nutzendes Ökosystem erstellt, mindestens eine Prüfinstanz vorhanden ist. Damit gibt es in dem Ökosystem, in dem Signaturprüfungen vorgenommen werden, also die wenigstens eine Prüfinstanz, die in der Lage ist, die Korrektheit der von der signierenden Instanz ausgestellten Signaturen zu prüfen. Diese Tatsache wird nun von einem an einer Prüfung einer Signatur interessierten System, hier anfragendes System genannt, ausgenutzt werden, indem es die Signatur nicht selbst mittels des öffentlichen Schlüssels der signierenden Instanz prüft sondern diese Aufgabe an die Prüfinstanz delegiert. Die Prüfinstanz prüft die Signatur und übermittelt dem anfragenden System das Ergebnis der Prüfung, z.B. einen Wahrheitswert wie z.B. TRUE oder FALSE. Damit kann auch ein vergleichsweise leistungsschwaches System mit wenig Rechen- und/oder Speicherkapazität ein zuverlässige Prüfungsresultat erhalten.
Durch die Delegierung der Signaturprüfung an eine Prüfinstanz muss in dem anfragenden System kein Signaturprüfungsverfahren zum Prüfen von von der signierenden Instanz erzeugten Signaturen umgesetzt sein, insbesondere muss das System keinen öffentlichen Schlüssel der signierenden Instanz manipulationsgeschützt hinterlegen und nutzen. Dies spart einerseits Kapazitäten in dem System ein und andererseits kann die signierende Instanz dadurch in Abstimmung mit der Prüfinstanz nun unabhängig von den anfragenden Systemen mit geringem Aufwand für den Signiervorgang immer die sichersten dem Stand der Technik entsprechenden Signierverfahren und Schlüssellängen nutzen, ohne dabei die anfragenden Systeme, die die Signatur prüfen möchten, anpassen zu müssen. Dies ermöglicht einen echten Sicherheitsvorteil und erlaubt es auch bei langlebigen Systemen, wie z.B. Fahrzeugsteuergeräten, für diese die neuste Technik einzusetzen, ohne in dem System selbst auf sicherem Weg neue Prüfverfahren und/oder Schlüssel installieren zu müssen. Dies ist vor allem bei einer großen Anzahl von in Feld befindlichen Geräten, insbesondere wenn diese auch noch aus unterschiedlichen Gerätegenerationen stammen, ein entscheidender Vorteil.
Gemäß der Erfindung ist es vorsehen, dass im Rahmen der Übermittlung des Ergebnisses durch die Prüfinstanz an das anfragende System diesem auch zumindest Teile der der durchgeführten Prüfung zugrundeliegenden Anfrage übermittelt werden.
Bevorzugt können die zurückübermittelten Teile der Anfrage das geprüfte Daten-Signatur-Paar umfassen.
In diesem Fall kann es dann sogar die Anfrage des Systems an die Prüfinstanz ungeschützt erfolgen. Die Antwort der Prüfinstanz inklusive des Ergebnisses der Prüfung erfolgt dann integritätsgeschützt und/oder authentifiziert und enthält, wie vorher ausgeführt zumindest Teile der der Prüfung zugrundeliegenden Anfrage. Nach erhalt der Antwort kann so das System prüfen, ob die im Rahmen der Übermittlung des Ergebnisses mit übermittelten Teile der Anfrage zu der gestellten Anfrage passen.
Eine vorteilhafte Ausgestaltung des Verfahrens sieht es dabei ferner vor, die Prüfinstanz zumindest mit einem Signaturprüfungsverfahren zur Prüfung mit Hilfe des Signierverfahrens von der signierenden Instanz erzeugter Signaturen und mit dem öffentlichen Schlüssel der signierenden Instanz auszustatten.
Die Prüfinstanz kann dabei auch die Prüfung von mit verschiedenen privaten Schlüsseln erzeugten Signaturen, insbesondere von von verschiedenen signierenden Instanzen erzeugten Signaturen, vornehmen. Dazu muss die Prüfinstanz die korrespondierenden Signaturprüfungsverfahren implementiert haben und mit den dazugehörigen öffentlichen Schlüsseln der signierenden Instanzen ausgestattet sein. Um eine sinnvolle Signaturprüfung durchführen lassen zu können, muss der Prüfinstanz, zusätzlich zu den signierten Daten und zur Signatur, mitgeteilt werden, welches Signierverfahren und welcher private Schlüssel beim Signiervorgang genutzt worden ist. Dazu müssen die potentiell nutzbaren Schlüsselpaare eindeutige Bezeichner erhalten, mit deren Hilfe sie identifiziert werden können. Der eindeutige Bezeichner des beim Signiervorgang genutzten privaten Schlüssels muss dann dem anfragenden System zusammen mit der Signatur mitgeteilt werden, das anfragende System wiederum übermittelt diesen Bezeichner dann samt den signierten Daten und der Signatur bei einer Anfrage an die Prüfinstanz. Falls das beim Signieren verwendete Signierverfahren aus den anderen übermittelten Daten, bspw. der Signatur oder dem eindeutigen Bezeichner des öffentlichen Schlüssels, nicht eindeutige hervorgeht, muss diese Information ebenfalls an die Prüfinstanz mit übermittelt werden.
Die Sicherheit des anfragenden Systems kann signifikant vom Wissen, ob die zu prüfende Signatur korrekt ist, also von der Korrektheit der durch die Prüfinstanz durchgeführten Prüfung der an diese übermittelten Signatur, abhängen. Damit ein Angreifer die an die Prüfinstanz gestellte Anfrage, also bspw. das übermittelte Daten-Signatur-Paar, nicht unbemerkt manipulieren, bspw. austauschen, kann, ist es hilfreich, die Anfrage an die Prüfinstanz integritätsgeschützt zu übermitteln. Dementsprechend ist es gemäß einer sehr vorteilhafter Weiterbildung des Verfahrens gemäß der Erfindung vorgesehen, dass die Anfrage des Systems an die Prüfinstanz inklusive des zu prüfenden Daten-Signatur-Paares integritätsgeschützt und/oder authentifiziert erfolgt.
Auf der anderen Seite ist es auch wichtig, dass ein Angreifer das Ergebnis der von der Prüfinstanz durchgeführten Prüfung auf dem Weg von der Prüfinstanz zum anfragenden System nicht unbemerkt verfälschen bzw. manipulieren kann. Eine weitere sehr günstige Ausgestaltung sieht es daher vor, dass die Antwort der Prüfinstanz an das anfragende System inklusive des Ergebnisses der Prüfung integritätsgeschützt und/oder authentifiziert erfolgt.
Sowohl bei der Anfrage als auch bei der Antwort können dabei zur Sicherstellung der Integrität bzw. der Authentizität bekannte asymmetrische Verfahren, bspw. digitale Signaturen, oder symmetrische Verfahren, bspw. Message Authentication Codes (MAC), genutzt werden.
Dabei kann es vorteilhaft sein, in die Mitteilung des Ergebnisses der Prüfung an das anfragende System Sys nicht nur das binäre Ergebnis der Prüfung an sich (TRUE/FALSE) sondern auch die komplette Anfrage oder Teile der Anfrage, also bspw. das geprüfte Daten-Signatur-Paar, aufzunehmen. Wird dieses umfassende Ergebnis an das anfragende System integritätsgeschützt übermittelt, kann auf die integritätsgeschützte Übermittlung der Anfrage an die Prüfinstanz verzichtet werden, denn anhand des ihm mitgeteilten die der Signaturprüfung zugrundeliegende Anfrage, insbesondere das geprüfte Daten-Signatur-Paar, enthaltenden Ergebnisses, kann das anfragende System feststellen, ob das mitgeteilte Ergebnis aus der Prüfung der ursprünglich gestellten Anfrage resultiert, indem es die in der ursprünglichen Anfrage enthaltenen Daten mit den Daten aus der in dem integritätsgeschützten Ergebnis enthaltenen Anfrage, bspw. dem geprüften Daten-Signatur-Paar vergleicht. Der Verzicht auf die integritätsgeschützte Übermittlung der Anfrage kann die Implementierung des anfragenden Systems signifikant vereinfachen, denn eine integritätsgeschützte Übermittlung verlangt meist nach einem im Sender, in diesem Fall dem anfragenden Systems, lesegeschützt abgelegten Geheimnis, bspw. einem privaten Schlüssel, worauf im Falle des Verzichts auf den Integritätsschutz verzichtet werden kann.
Damit das anfragende System sich auf das von der Prüfinstanz mitgeteilte Ergebnis der Prüfung der Signatur verlassen kann, muss das anfragende System der Prüfinstanz vertrauen. Es sollte sich gemäß einer sehr vorteilhaften Ausgestaltung des Verfahrens bei der Prüfinstanz also aus Sicht des anfragenden Systems um eine vertrauenswürdige Instanz handeln.
Wie oben bereits mehrfach erwähnt, kann das Verfahren besonders vorteilhaft in einem Fahrzeug-Ökosystem zum Einsatz kommen. Dabei ist es dann vorgesehen, dass die Systeme als Steuergeräte in einem Fahrzeugumfeld ausgebildet sind, welches neben den Steuergeräten der einzelnen Fahrzeuge zumindest einen fahrzeugexternen Server, das oben bereits genannte Backend, umfasst, welcher in einer Kommunikationsverbindung mit den Fahrzeugen und zumindest einigen ihrer Steuergeräte steht.
In einer solchen Anwendung kann es vorteilhaft und vorgesehen sein, dass die Prüfinstanz als Fahrzeug-Prüfinstanz in einem speziellen, dafür vorgesehenen Steuergerät beispielsweise als Teil bzw. Modul dieses Steuergerätes des jeweiligen Fahrzeugs ausgebildet ist. Die Prüfung kann dann den anderen im selben Fahrzeug verbauten Steuergeräten oder auch den anderen Teilsystemen/Modulen desselben Steuergerätes angeboten werden. Zur Übermittlung der Anfragen und zur Mitteilung der Ergebnisse können die Fahrzeugbusse genutzt werden, was den Vorteil einer schnellen Beantwortung der Anfragen, also einer schnellen Durchführung der Signaturprüfung, hat. Ebenso können fahrzeuginterne Integritätssicherungsmechanismen, insb. Basis-Integritätssicherungsmechanismen wie bspw. SecOC, zum Integritätsschutz der Anfragen und/oder der Ergebnisse direkt genutzt werden. Ein Steuergerät, insbesondere ein speziell für die Signaturprüfung konzipiertes Steuergerät oder Modul eines Steuergerätes, kann entsprechend dieser Aufgabe hin optimiert ausgelegt werden, so dass also die ansonsten bei Steuergeräten häufig auftretenden Kapazitätsproblem hier keine Rolle spielen.
In einer alternativen oder besonders bevorzugt auch ergänzenden Ausprägung des erfindungsgemäßen Verfahrens kann die Prüfung von Signaturen auch von einem fahrzeugexternen Server (Backend) oder einem Teilsystem desselben realisiert werden, was den Vorteil hat, dass das Backend im Vergleich zu einem Steuergerät über viel größere Ressourcen und eine viel höhere Flexibilität verfügt, was insbesondere eine größere Anzahl angebotener Signaturprüfungsverfahren und/oder genutzter Schlüssellängen sowie bei Bedarf eine schnellere und einfachere Aufnahme weiterer Signaturprüfungsverfahren und/oder genutzter Schlüssellängen ermöglicht.
Diese beiden Ansätze lassen sich vorteilhaft kombinieren, indem sowohl im Fahrzeug als auch im Backend eine Prüfinstanz eingerichtet wird und die Signaturprüfung je nach Fall von der einen oder der anderen Prüfinstanz durchgeführt wird, wodurch die Vorteile beider Arten von Prüfinstanzen genutzt werden können.
Dafür kann es nun vorgesehen sein, dass das System seine Anfrage inklusive des zu prüfenden Daten-Signatur-Paares an die Fahrzeug-Prüfinstanz übermittelt, welche die Prüfung vornimmt oder die Anfrage inklusive des zu prüfenden Daten-Signatur-Paares zur Prüfung an die Backend-Prüfinstanz weiterleitet, welche die Prüfung vornimmt und das Ergebnis der Prüfung an die Fahrzeug-Prüfinstanz übermittelt.
Dem System bzw. Steuergerät steht damit als Ansprechpartner immer die Fahrzeug-Prüfinstanz zur Verfügung. Die Kommunikation zwischen diesen beiden Partnern ist also einfach effizient und geschützt innerhalb des Fahrzeugs möglich. Die Fahrzeug-Prüfinstanz prüft nach dem Empfang der Anfrage, ob es die angefragte Prüfung selbst durchführen kann, insbesondere, ob es das benötigte Signaturprüfungsverfahren implementiert hat und im Besitz des benötigten öffentlichen Schlüssels der signierenden Instanz ist. Ist das der Fall, prüft die Fahrzeug-Prüfinstanz, ob es effizienter ist, die Prüfung selbst durchzuführen oder diese an die Backend-Prüfinstanz zu delegieren. Ist das nicht der Fall, wird die Prüfung sofort an die Backend-Prüfinstanz delegiert. Dabei tritt die Fahrzeug-Prüfinstanz gegenüber der Backend-Prüfinstanz als ein anfragendes System auf. Wird die Prüfung von der Fahrzeug-Prüfinstanz durchgeführt, tritt die oben beschriebene Situation mit einem anfragenden System und einer Prüfinstanz auf. Wird die Prüfung von der Backend-Prüfinstanz durchgeführt, so empfängt die Fahrzeug-Prüfinstanz die Anfrage von dem anfragenden System und leitet diese Anfrage dann ihrerseits als „anfragendes System“ an die Backend-Prüfinstanz weiter.
Bezüglich des Ergebnisses gibt es nun verschiedene Möglichkeiten. So kann es in einer ersten Variante vorgesehen werden, dass die Fahrzeug-Prüfinstanz das Ergebnis zusammen mit einer Information darüber, welche der Instanzen die Prüfung vorgenommen hat, an das anfragende System übermittelt. Dabei kann es gemäß einer sehr vorteilhaften Ausgestaltung auch vorgesehen werden, dass für die Anfrage und die Übermittlung des Ergebnisses zwischen dem System und der Backend-Prüfinstanz ein Ende-zu-Ende-Integritätsschutz aufgebaut wird. Die Fahrzeug-Prüfinstanz bleibt damit zwar in der Übermittlungskette, ohne jedoch eine Möglichkeit zum Eingriff in den Datenverkehr zu erlangen.
Ferner kann es gemäß einer sehr günstigen Weiterbildung vorgesehen werden, dass das anfragende System vorgibt, welche der Instanzen die Prüfung vornehmen soll. Das System bzw. Steuergerät behält sich hier also die Auswahl der Prüfinstanz vor.
Gemäß einem anderen Ansatz könnte es aber auch vorgesehen werden, dass die Fahrzeug-Prüfinstanz das Ergebnis immer in ihrem eigenen Namen an das anfragende System übermittelt. Dieses hat also keinerlei Kenntnis darüber, ob die Fahrzeug-Prüfinstanz oder die Backend-Prüfinstanz die Signatur geprüft hat. In dieser Ausprägung der Kombination aus einer Fahrzeug-Prüfinstanz und einer Backend-Prüfinstanz müssen das anfragendes System und die Backend-Prüfinstanz nichts voneinander wissen, das anfragende System stellt alle Anfragen an die Fahrzeug-Prüfinstanz, die auch alle Ergebnisse zurückliefert. Werden Integritätsschutzverfahren genutzt, so muss die Integrität der empfangenen Anfrage bzw. des empfangenen Ergebnisses von der Fahrzeug-Prüfinstanz jeweils geprüft und danach bei der Weiterleitung der Anfrage bzw. des Ergebnisses an den jeweiligen Empfänger mit dem zwischen der Fahrzeug-Prüfinstanz und dem Empfänger genutzten Integritätsschutzverfahren neu geschützt, bspw. mit einer Signatur oder einem Message Authentication Code, versehen werden. Dadurch wird bei dieser Ausprägung insbesondere kein Ende-zu-Ende-Integritätsschutz sichergestellt.
Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich auch aus den restlichen abhängigen Unteransprüchen und werden anhand der Ausführungsbeispiele deutlich, welche nachfolgenden unter Bezugnahme auf die Figuren näher beschreiben werden.
Dabei zeigen:

1 eine Abbildung eines Schemas einer ersten Ausgestaltung des erfindungsgemäßen Verfahrens;
2 eine Abbildung eines Schemas einer ersten Ausgestaltung des erfindungsgemäßen Verfahrens mit mehreren signierenden Instanzen;
3 eine Abbildung eines Schemas mit einer beispielhaften fahrzeugbezogenen Implementierung von zwei Prüfinstanzen in einer ersten Ausgestaltung des erfindungsgemäßen Verfahrens; und
4 eine Abbildung eines Schemas mit einer beispielhaften fahrzeugbezogenen Implementierung von zwei Prüfinstanzen in einer zweiten Ausgestaltung des erfindungsgemäßen Verfahrens.

Die Darstellung in 1 zeigt eine mögliche Ausprägung des Verfahrens, bei der eine von der signierenden Instanz SI für Daten Dat erzeugte Signatur Sig von einem System Sys an eine Prüfinstanz PI übermittelt wird und dort mit Hilfe eines von der Prüfinstanz PI implementierten dedizierten Dienstes geprüft wird. Der gestrichelte Pfeil und die Wolke symbolisieren, dass die Daten Dat und die Signatur Sig entkoppelt vom eigentlichen Prüfungsvorgang und voneinander aber vor dem Prüfungsvorgang an das anfragende System Sys übermittelt werden. Da die Signatur Sig von der signierenden Instanz SI erzeugt wird, hat sie ihren Ursprung in der signierenden Instanz SI. Die zu signierenden Daten Dat müssen hingegen nicht notwendigerweise von der signierenden Instanz SI stammen, sie können von einer beliebigen Stelle im Ökosystem an das anfragende System Sys übermittelt werden.
Werden mehr als eine signierende Instanz SI genutzt, dann sähe das Schema, für das Beispiel von zwei signierenden Instanzen SI1 und SI2 so aus, wie analog zur Darstellung in 1 in 2 dargestellt. Bei zwei dasselbe Signierverfahren Sign verwendenden signierenden Instanzen SI1, SI2 mit jeweils zwei und einem Schlüsselpaar sowie einem anfragenden System Sys ergibt sich folgende Ausprägung. Man beachte, dass die Prüfinstanz PI drei öffentliche Schlüssel vorhalten muss, um alle von den signierenden Instanzen SI1, SI2 erzeugten Signaturen prüfen zu können. Die eindeutigen Bezeichner der Schlüssel ergeben sich aus der Identität der signierenden Instanz SI1, SI2 und der laufenden Nummer des Schlüsselpaares innerhalb der jeweiligen signierenden Instanz SI1, SI2.
3 zeigt eine erste beispielhafte Implementierung der Kombination aus einer Fahrzeug-Prüfinstanz FPI und einer Backend-Prüfinstanz BPI. Dabei werden die Daten bei der Übermittlung von einem Kommunikationspartner zum anderen integritätsgeschützt, wobei die Kommunikation zwischen dem anfragenden System Sys und der Fahrzeug-Prüfinstanz FPI mit Hilfe symmetrischer Message Authentication Codes geschützt wird und die Kommunikation zwischen der Fahrzeug-Prüfinstanz FPI und der Backend-Prüfinstanz BPI mit Hilfe asymmetrischer digitaler Signaturen geschützt wird. Dabei werden im Einzelnen folgende Schritte durchgeführt.

1. Die zumindest mit einer Implementierung eines Signierverfahrens Sign und einem dazu passenden asymmetrischen Schlüsselpaar SIPub, SIPriv ausgestattete signierende Instanz SI
1. a. signiert die Daten Dat mit Hilfe des Signierverfahrens Sign und ihrem privaten Schlüssel SIPriv und erzeugt dabei die Signatur Sig,
2. b. übermittelt die signierten Daten Dat und die Signatur Sig an das anfragende System Sys
2. Das anfragende System Sys, das zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung eines Verfahrens zur Erzeugung eines Message Authentication Codes MAC und einem dazu passenden symmetrischen Schlüssel MKey, die es sich mit der Fahrzeug-Prüfinstanz FPI teilt und mit deren Hilfe die Kommunikation mit der Fahrzeug-Prüfinstanz FPI integritätsgeschützt wird, führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) folgende Schritte durch
  1. a. erzeugt mit Hilfe des Verfahrens zur Erzeugung eines Message Authentication Codes MAC und des symmetrischen Schlüssels MKey einen Message Authentication Code M1 für das empfangene Daten-Signatur-Paar (Dat, Sig),
  2. b. übermittelt das Daten-Signatur-Paar (Dat, Sig) und den erzeugten Message Authentication Code M1 an die Fahrzeug-Prüfinstanz FPI.
3. Die Fahrzeug-Prüfinstanz FPI, die zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung eines Fahrzeug-Signierverfahrens SignF und einem dazu passenden asymmetrischen Schlüsselpaar FPIPub, FPIPriv
- - potentiell (in der 3 durch Fragezeichen markiert) einer Implementierung des Signaturprüfungsverfahrens Ver zur Prüfung mittels des von der signierenden Instanz SI genutzten Signierverfahrens Sign erzeugter Signaturen Sig und dem dazu passenden öffentlichen Schlüssel SIPub der signierenden Instanz SI
- - einer Implementierung des Verfahrens zur Erzeugung eines Message Authentication Codes MAC und dem dazu passenden symmetrischen Schlüssel MKey, die sie sich mit dem anfragenden System Sys teilt und mit deren Hilfe die Kommunikation mit dem anfragenden System Sys integritätsgeschützt wird
- - einer Implementierung eines Signaturprüfungsverfahrens VerB zur Prüfung mittels des in der Backend-Prüfinstanz BPI implementierten Backend-Signierverfahrens SignB erzeugter Signaturen S2 und dem dazu passenden öffentlichen Schlüssel BPIPub der Backend-Prüfinstanz BPI zur Sicherstellung des Integrität der von der Backend-Prüfinstanz BPI empfangener Daten führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) und des Message Authentication Codes M1 folgende Schritte durch
  1. a. prüft mit Hilfe der von dem Verfahren zur Erzeugung eines Message Authentication Codes MAC abgeleiteten Prüfungsfunktion für Message Authentication Codes CheckMAC, des hinterlegten symmetrischen Schlüssels MKey und des empfangenen Message Authentication Code M1 die Integrität des empfangenen Daten-Signatur-Paares (Dat, Sig). Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 3 nicht dargestellt).
  2. b. prüft, ob die Prüfung der im empfangenen Daten-Signatur-Paar (Dat, Sig) enthaltenen Signatur Sig lokal durchgeführt werden kann. Ist das nicht der Fall, wird mit Schritt 3.g weitergemacht.
  3. c. prüft, ob es effizient ist, die Signaturprüfung lokal durchzuführen. Ist das nicht der Fall, wird mit Schritt 3.g weitergemacht.
  4. d. berechnet das Ergebnis Erg der Signaturprüfung des Daten-Signatur-Paares (Dat, Sig) mit Hilfe des Signaturprüfungsverfahrens Ver und des öffentlichen Schlüssels SIPub der signierenden Instanz SI.
  5. e. erzeugt mit Hilfe des Verfahrens zur Erzeugung eines Message Authentication Codes MAC und des symmetrischen Schlüssels MKey einen Message Authentication Code M2 für das errechnete Ergebnis Erg.
  6. f. übermittelt das Ergebnis Erg und den erzeugten Message Authentication Code M2 an das anfragende System Sys. Anschließend wird zu Schritt 6a übergegangen.
  7. g. erzeugt die Signatur S1 des Daten-Signatur-Paares (Dat, Sig)n mit Hilfe des implementierten Fahrzeug-Signierverfahrens SignF und des eigenen privaten Schlüssels FPIPriv.
  8. h. übermittelt das Daten-Signatur-Paar (Dat, Sig) und die erzeugte Signatur S1 an die Backend-Prüfinstanz BPI.
4. Die Backend-Prüfinstanz BPI, die zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung eines Backend-Signierverfahrens SignB und einem dazu passenden asymmetrischen Schlüsselpaar BPIPub, BPIPriv,
- - einer Implementierung des Signaturprüfungsverfahrens Ver zur Prüfung mittels des von der signierenden Instanz SI genutzten Signierverfahrens Sign erzeugter Signaturen Sig und dem dazu passenden öffentlichen Schlüssel SIPub der signierenden Instanz SI,
- - einer Implementierung eines Signaturprüfungsverfahrens VerF zur Prüfung mittels des in der Fahrzeug-Prüfinstanz FPI implementierten Fahrzeug-Signierverfahrens SignF erzeugter Signaturen S1 und dem dazu passenden öffentlichen Schlüssel FPIPub der Fahrzeug-Prüfinstanz FPI zur Sicherstellung der Integrität der von der Fahrzeug-Prüfinstanz FPI empfangener Daten führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) und der Signatur S1 folgende Schritte durch
  1. a. prüft mit Hilfe des implementierten Signaturprüfungsverfahrens VerF, des hinterlegten öffentlichen Schlüssels FPIPub der Fahrzeug-Prüfinstanz FPI und der empfangenen Signatur S1 die Integrität des empfangenen Daten-Signatur-Paares (Dat, Sig). Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 3 nicht dargestellt).
  2. b. berechnet das Ergebnis Erg der Signaturprüfung des Daten-Signatur-Paares (Dat, Sig) mit Hilfe des Signaturprüfungsverfahrens Ver und des öffentlichen Schlüssels SIPub der signierenden Instanz SI.
  3. c. erzeugt die Signatur S2 des Ergebnisses Erg mit Hilfe des implementierten Signierverfahrens SignB und des eigenen privaten Schlüssels BPIPriv.
  4. d. übermittelt das Ergebnis Erg und die erzeugte Signatur S2 an die Fahrzeug-Prüfinstanz FPI.
5. Die Fahrzeug-Prüfinstanz FPI führt nach dem Empfang des Ergebnisses Erg und der Signatur S2 folgende Schritte durch
1. a. prüft mit Hilfe des implementierten Signaturprüfungsverfahrens VerB, des hinterlegten öffentlichen Schlüssels BPIPub der Backend-Prüfinstanz BPI und der empfangenen Signatur S2 die Integrität des empfangenen Ergebnisses Erg. Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 3 nicht dargestellt).
2. b. geht zu Schritt 3.e über.
6. Das anfragende System Sys führt nach dem Empfang des Ergebnisses Erg und des Message Authentication Codes M2 folgende Schritte durch
1. a. prüft mit Hilfe der von dem Verfahren zur Erzeugung eines Message Authentication Codes MAC abgeleiteten Prüfungsfunktion für Message Authentication Codes CheckMAC, des hinterlegten symmetrischen Schlüssels MKey und des empfangenen Message Authentication Code M2 die Integrität des empfangenen Ergebnisses Erg. Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 3 nicht dargestellt).
2. b. nutzt das übermittelte Ergebnis Erg.

Die anhand der 3 beschriebene Ausprägung hat den Vorteil, dass das anfragende System Sys auf allen Ebenen nur mit der Fahrzeug-Prüfinstanz FPI kommuniziert und damit insbesondere nur für diese Kommunikation Integritätsschutzverfahren bereithalten muss. Der Nachteil dieser ersten Ausprägung ist, dass beiden beteiligten Prüfinstanzen, also sowohl der Fahrzeug-Prüfinstanz FPI als auch der Backend-Prüfinstanz BPI, vertraut werden muss, insbesondere wird bei dieser Ausprägung zwischen der Backend-Prüfinstanz BPI und dem anfragenden System Sys kein Ende-zu-Ende-Integritätsschutz gewährleistet.
In einer alternativen Ausprägung der Kombination aus einer Fahrzeug-Prüfinstanz FPI und einer Backend-Prüfinstanz BPI, in der das anfragende System Sys sowohl die Fahrzeug-Prüfinstanz FPI als auch die Backend-Prüfinstanz BPI kennt, wird dieser Nachteil behoben. Wie oben auch stellt dabei das anfragende System Sys alle Anfragen an die Fahrzeug-Prüfinstanz FPI. Im Gegensatz zur ersten Ausprägung kann das anfragende System Sys jedoch im Rahmen der Anfrage angeben, ob es die Prüfung nach Möglichkeit von der Fahrzeug-Prüfinstanz FPI oder unbedingt von der Backend-Prüfinstanz BPI durchgeführt haben möchte. Des Weiteren kann dem anfragenden System Sys von der Fahrzeug-Prüfinstanz FPI im Rahmen der Ergebnismitteilung explizit angezeigt werden, welche Prüfinstanz die Prüfung durchgeführt und das Ergebnis Erg bestimmt hat. Des Weiteren kann zwischen dem anfragenden System Sys und der Backend-Prüfinstanz BPI ein Ende-zu-Ende-Integritätsschutz umgesetzt werden, wobei sowohl symmetrische als auch asymmetrische Integritätsschutzverfahren genutzt werden können. Ist so ein Ende-zu-Ende-Integritätsschutz gegeben und wird die Prüfung immer von der Backend-Prüfinstanz BPI durchgeführt, bspw. weil von dem anfragenden System Sys so gefordert, so dient die Fahrzeug-Prüfinstanz FPI in dieser Variante ausschließlich der Kommunikation zwischen dem anfragenden System Sys und der Backend-Prüfinstanz BPI, insbesondere muss bei dieser Variante das anfragende System Sys der Fahrzeug-Prüfinstanz FPI nicht vertrauen.
Die 4 zeigt eine beispielhafte Implementierung dieser zweiten Ausprägung. Dabei werden die jeweiligen Anfragen vom anfragenden System Sys an die Fahrzeug-Prüfinstanz FPI sowie von der Fahrzeug-Prüfinstanz FPI an die Backend-Prüfinstanz BPI, ungeschützt übermittelt. Die Übermittlung des Ergebnisses von der jeweiligen Prüfinstanz FPI bzw. BPI an das anfragende System Sys wird hingegen mit Hilfe digitaler Signaturen geschützt, wobei, wie weiter oben vorgeschlagen, neben des reinen Ergebnisses der Signaturprüfung Erg auch das geprüfte Daten-Signatur-Paar (Dat, Sig) sowie die Identität IdPI der die Signaturprüfung durchgeführten Prüfinstanz FPI bzw. BPI mitsigniert und mitübermittelt wird. Damit das anfragende System Sys nur ein Signaturprüfungsverfahren implementieren muss, wird von beiden Prüfinstanzen FPI und BPI dasselbe Signierverfahren SignFB genutzt. Dabei werden im Einzelnen folgende Schritte durchgeführt:

1. Die zumindest mit einer Implementierung eines Signierverfahrens Sign und einem dazu passenden asymmetrischen Schlüsselpaar SIPub, SIPriv ausgestattete signierende Instanz SI
1. a. signiert die Daten Dat mit Hilfe des Signierverfahrens Sign und ihrem privaten Schlüssel SIPriv und erzeugt dabei die Signatur Sig,
2. b. übermittelt die signierten Daten Dat und die Signatur Sig an das anfragende System Sys
2. Das anfragende System Sys, das zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung eines Signaturprüfungsverfahrens VerFB zur Prüfung mittels des in der Fahrzeug-Prüfinstanz FPI und in der Backend-Prüfinstanz BPI implementierten gemeinsamen Signierverfahrens SignFB erzeugter Signaturen S3 und S4 und den dazu passenden öffentlichen Schlüsseln FPIPub und BPIPub der Fahrzeug-Prüfinstanz FPI und der Backend-Prüfinstanz BPI zur Sicherstellung der Integrität der von der Fahrzeug-Prüfinstanz FPI und der von der Backend-Prüfinstanz BPI empfangenen Daten, führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) folgende Schritte durch
  1. a. übermittelt das Daten-Signatur-Paar (Dat, Sig) an die Fahrzeug-Prüfinstanz FPI.
3. Die Fahrzeug-Prüfinstanz FPI, die zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung des gemeinsamen Signierverfahrens SignFB und einem dazu passenden asymmetrischen Schlüsselpaar FPIPub, FPIPriv
- - potentiell, (in der 4 durch Fragezeichen markiert) einer Implementierung des Signaturprüfungsverfahrens Ver zur Prüfung mittels des von der signierenden Instanz SI genutzten Signierverfahrens Sign erzeugter Signaturen Sig und dem dazu passenden öffentlichen Schlüssel SIPub der signierenden Instanz SI, führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) folgende Schritte durch
  1. a. prüft, ob die Prüfung der im empfangenen Daten-Signatur-Paar (Dat, Sig) enthaltenen Signatur Sig lokal durchgeführt werden kann. Ist das nicht der Fall, wird mit Schritt 3.g weitergemacht.
  2. b. prüft, ob es effizient ist, die Signaturprüfung lokal durchzuführen. Ist das nicht der Fall, wird mit Schritt 3.g weitergemacht.
  3. c. berechnet das Ergebnis Erg der Signaturprüfung des Daten-Signatur-Paares (Dat, Sig) mit Hilfe des Signaturprüfungsverfahrens Ver und des öffentlichen Schlüssels der signierenden Instanz SIPub.
  4. d. weist dem zusammen mit dem Ergebnis Erg zu signierenden und zu übermittelnden Parameter IdPI die eigene Identität „FPI“ zu.
  5. e. erzeugt die gemeinsame Signatur S3 des Ergebnisses Erg der Signaturprüfung, des geprüften Daten-Signatur-Paares (Dat, Sig) und der Identität der Prüfinstanz IdPI mit Hilfe des implementierten gemeinsamen Signierverfahrens SignFB und des eigenen privaten Schlüssels FPIPriv.
  6. f. übermittelt das Ergebnis Erg, das geprüfte Daten-Signatur-Paar (Dat, Sig), die Identität der Prüfinstanz IdPI und die erzeugte Signatur S3 an das anfragende System Sys. Anschließend wird zu Schritt 6a übergegangen.
  7. g. übermittelt das Daten-Signatur-Paar (Dat, Sig) an die Backend-Prüfinstanz BPI.
4. Die Backend-Prüfinstanz BPI, die zumindest mit folgenden Mitteln ausgestattet ist
- - einer Implementierung des auch von der Fahrzeug-Prüfinstanz FPI genutzten gemeinsamen Signierverfahrens SignFB und einem dazu passenden asymmetrischen Schlüsselpaar BPIPub, BPIPriv,
- - einer Implementierung des Signaturprüfungsverfahrens Ver zur Prüfung mittels des von der signierenden Instanz SI genutzten Signierverfahrens Sign erzeugter Signaturen Sig und dem dazu passenden öffentlichen Schlüssel SIPub der signierenden Instanz SI, führt nach dem Empfang des Daten-Signatur-Paares (Dat, Sig) folgende Schritte durch
  1. a. berechnet das Ergebnis Erg der Signaturprüfung des Daten-Signatur-Paares (Dat, Sig) mit Hilfe des Signaturprüfungsverfahrens Ver und des öffentlichen Schlüssels der signierenden Instanz SIPub.
  2. b. weist dem zusammen mit dem Ergebnis Erg zu signierenden und zu übermittelnden Parameter IdPI die eigene Identität „BPI“ zu.
  3. c. erzeugt die gemeinsame Signatur S4 des Ergebnisses Erg der Signaturprüfung, des Daten-Signatur-Paares (Dat, Sig) und der Identität der Prüfinstanz IdPI mit Hilfe des implementierten Signierverfahrens SignFB und des eigenen privaten Schlüssels BPIPriv.
  4. d. übermittelt das Ergebnis Erg, das geprüfte Daten-Signatur-Paar (Dat, Sig), die Identität der Prüfinstanz IdPI und die erzeugte Signatur S4 an die Fahrzeug-Prüfinstanz FPI.
5. Die Fahrzeug-Prüfinstanz FPI führt nach dem Empfang des Ergebnisses Erg, des geprüften Daten-Signatur-Paares (Dat, Sig), der Identität der die Prüfung durchgeführten Prüfinstanz IdPI und der von der Backend-Prüfinstanz BPI erzeugten Signatur S4 folgende Schritte durch
1. a. übermittelt das Ergebnis Erg, das geprüfte Daten-Signatur-Paar (Dat, Sig), die Identität der Prüfinstanz IdPI und die erzeugte Signatur S4 an das anfragende System Sys.
6. Das anfragende System Sys führt nach dem Empfang des Ergebnisses Erg, des geprüften Daten-Signatur-Paares (Dat, Sig), der Identität der die Prüfung durchgeführten Prüfinstanz IdPI und der von der Prüfinstanz erzeugten Signatur S3 oder S4 folgende Schritte durch
1. a. prüft, ob das in der Anfrage enthaltene Daten-Signatur-Paar (Dat, Sig) mit dem mit dem Ergebnis Erg mitübermittelten geprüften Daten-Signatur-Paar (Dat, Sig) übereinstimmt. Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 4 nicht dargestellt).
2. b.
  - - falls die Signaturprüfung von der Fahrzeug-Prüfinstanz FPI durchgeführt worden ist, prüft mit Hilfe des implementierten gemeinsamen Signaturprüfungsverfahrens VerFB, des hinterlegten öffentlichen Schlüssels FPIPub der Fahrzeug-Prüfinstanz FPI und der empfangenen Signatur S3 die Integrität der empfangenen Daten, also des Ergebnisses Erg, des geprüften Daten-Signatur-Paares (Dat, Sig) und der Identität der die Prüfung durchgeführten Prüfinstanz IdPI. Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 4 nicht dargestellt).
  - - falls die Signaturprüfung von der Backend-Prüfinstanz BPI durchgeführt worden ist, prüft mit Hilfe des implementierten gemeinsamen Signaturprüfungsverfahrens VerFB, des hinterlegten öffentlichen Schlüssels BPIPub der Backend-Prüfinstanz BPI und der empfangenen Signatur S4 die Integrität der empfangenen Daten, also des Ergebnisses Erg, des geprüften Daten-Signatur-Paares (Dat, Sig) und der Identität der die Prüfung durchgeführten Prüfinstanz IdPI. Schlägt die Prüfung fehl, wird eine Ausnahmebehandlung eingeleitet (in der 4 nicht dargestellt).
  - - wurde die Identität einer unbekannten Prüfinstanz übermittelt, wird eine Ausnahmebehandlung eingeleitet (in der 4 nicht dargestellt).
3. c. nutzt das übermittelte Ergebnis Erg.

Claims

Verfahren zur Validierung einer Signatur (Sig) wenigstens einer signierenden Instanz (SI) für ein System (Sys), welches das Ergebnis der Prüfung der Signatur (Sig) benötigt, wobei die signierende Instanz (SI) mit einem asymmetrischen Schlüsselpaar (SIPub, SIPriv) zum Erstellen der Signatur (Sig) von zu signierenden Daten (Dat) ausgestattet ist, wobei wenigstens eine Prüfinstanz (PI, BPI, FPI) für eine Prüfung von von der wenigstens einen signierenden Instanz (SI) erzeugten Signaturen (Sig) etabliert wird, , wobei zur Durchführung der Prüfung die zu prüfende Signatur (Sig) zusammen mit den signierten Daten (Dat) von dem System (Sys), welches das Ergebnis der Prüfung der Signatur (Sig) benötigt, an die Prüfinstanz (Pl. BPI, FPI) übermittelt wird, wonach die Prüfinstanz (PI, BPI, FPI) die Prüfung der Signatur (Sig) durchführt, und wonach das Ergebnis (Erg) der Prüfung an das anfragende System (Sys) übermittelt wird dadurch gekennzeichnet, dass im Rahmen der Übermittlung des Ergebnisses (Erg) durch die Prüfinstanz (PI, BPI, FPI) an das anfragende System (Sys) diesem auch zumindest Teile der der durchgeführten Prüfung zugrundeliegenden Anfrage übermittelt werden.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Prüfinstanz (PI, BPI, FPI) zumindest mit einem Signaturprüfungsverfahren (Ver, VerB, VerF, VerFB) zur Prüfung mit Hilfe des Signierverfahrens (Sign) von der signierenden Instanz (SI) erzeugter Signaturen (Sig) und mit dem öffentlichen Schlüssel (SIPub) der signierenden Instanz (SI) ausgestattet ist.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass eine Anfrage des Systems (Sys) an die Prüfinstanz (PI, BPI, FPI) inklusive des zu prüfenden Daten-Signatur-Paares ((Dat, Sig)) integritätsgeschützt und/oder authentifiziert erfolgt.
Verfahren nach Anspruch 1, 2 oder 3, dadurch gekennzeichnet, dass eine Antwort der Prüfinstanz (PI, BPI, FPI) an das anfragende System (Sys) inklusive des Ergebnisses (Erg) der Prüfung integritätsgeschützt und/oder authentifiziert erfolgt.
Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass im Rahmen der Übermittlung des Ergebnisses (Erg) durch die Prüfinstanz (PI, BPI, FPI) an das anfragende System (Sys) diesem zumindest eine binäre Angabe (TRUE/FALSE) über das Prüfungsergebnis übermittelt wird.
Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass die zurückübermittelten Teile der Anfrage das geprüfte Daten-Signatur-Paar (Dat, Sig) umfassen.
Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass eine Anfrage des Systems (Sys) an die Prüfinstanz (PI, BPI, FPI) ungeschützt erfolgt, wobei eine Antwort der Prüfinstanz (PI, BPI, FPI) an das anfragende System (Sys) inklusive des Ergebnisses (Erg) der Prüfung integritätsgeschützt und/oder authentifiziert erfolgt, und wobei das System prüft, ob die im Rahmen der Übermittlung des Ergebnisses (Erg) mit übermittelten Teile der Anfrage zu der gestellten Anfrage passen.
Verfahren nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, dass als Prüfinstanz (PI, BPI, FPI) eine vertrauenswürdige Instanz verwendet wird
Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass die Systeme (Sys) als Steuergeräte in einem Fahrzeugumfeld ausgebildet sind.
Verfahren nach Anspruch 9, dadurch gekennzeichnet, dass die Prüfinstanz (PI) als mindestens eine Fahrzeug-Prüfinstanz (FPI) in einem Steuergerät des jeweiligen Fahrzeugs ausgebildet ist.
Verfahren nach einem der Ansprüche 9 oder 10, dadurch gekennzeichnet, dass das Fahrzeugumfeld neben den Steuergeräten der einzelnen Fahrzeuge zumindest einen fahrzeugexternen Server (Backend) umfasst, welcher in einer Kommunikationsverbindung mit den Fahrzeugen und zumindest einigen ihrer Steuergeräte steht.
Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass die Prüfinstanz (PI) als mindestens eine Backend-Prüfinstanz (BPI) in dem fahrzeugexternen Server ausgebildet ist.
Verfahren nach Anspruch 10 und 11, dadurch gekennzeichnet, dass mindestens eine Fahrzeug-Prüfinstanz (FPI) und mindesten eine Backend-Prüfinstanz (BPI) genutzt wird, wobei das System (Sys) seine Anfrage inklusive des zu prüfenden Daten-Signatur-Paares ((Dat, Sig)) an die Fahrzeug-Prüfinstanz (FPI) übermittelt, welche die Prüfung vornimmt oder die Anfrage inklusive des zu prüfenden Daten-Signatur-Paares ((Dat, Sig)) zur Prüfung an die Backend-Prüfinstanz (BPI) weiterleitet, welche die Prüfung vornimmt und das Ergebnis (Erg) der Prüfung an die Fahrzeug-Prüfinstanz (FPI) übermittelt.
Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass die Fahrzeug-Prüfinstanz (FPI) das Ergebnis (Erg) zusammen mit einer Information darüber, welche der Instanzen (FPI, BPI) die Prüfung vorgenommen hat, an das anfragende System (Sys) übermittelt.
Verfahren nach Anspruch 13 oder 14, dadurch gekennzeichnet, dass das Anfragende System (Sys) vorgibt, welche der Instanzen die Prüfung (FPI, BPI) vornehmen soll.
Verfahren nach Anspruch 13, 14 oder 15, dadurch gekennzeichnet, dass für die Anfrage und/oder die Übermittlung des Ergebnisses (Erg) zwischen dem anfragenden System (Sys) und der Backend-Prüfinstanz (BPI) ein Ende-zu-Ende-Integritätsschutz aufgebaut wird.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Fahrzeug-Prüfinstanz (FPI) das Ergebnis (Erg) in ihrem eigenen Namen an das anfragende System (Sys) übermittelt.