DE102021001919A1 - Verfahren zum sicheren Verteilen eines Softwareupdates - Google Patents

Abstract

Die Erfindung betrifft Verfahren zum sicheren Verteilen eines Softwareupdates für Steuergeräte in einem Fahrzeug an eine Vielzahl von Empfängern (4), mit einer post-quanten resistenten Authentifizierung. Die Erfindung ist dadurch gekennzeichnet, dass der Ersteller (1) oder ein Verteiler (2) das Softwareupdate oder einen mittels einer Hashfunktion (HASH) erstellten Hashwert des Softwareupdates authentizitätsgeschützt an einen Authentifizierer (3) überträgt.In einer ersten Variante überträgt dann der Verteiler (2) das Softwareupdate ohne Authentifizierung an die Empfänger (4), wonach jeder der Empfänger (4) seine Identität (IDi) und die Identität (SwID) des empfangenen Softwareupdates an den Authentifizierer (3) sendet, welcher mit Hilfe eines mit dem jeweiligen Empfänger (4) individuell geteilten Schlüssels (AuthKeyIDiAUTH) einen individualisierten Authentifizierungsstempel (AuthStSwIDIDi) erstellt und zurücksendet.In einer zweiten Variante erstellt der Authentifizierer (3) einen vollständigen Authentifizierungsdatensatz, in dem er sukzessive für alle in Frage kommenden Empfängeridentitäten (IDi) mit Hilfe eines mit dem jeweiligen Empfänger (4) individuell geteilten Schlüssels (AuthKeyIDiAUTH) einen individualisierten Authentifizierungsstempel (AuthStSwIDIDi) für das Softwareupdate erstellt und zu dem Authentifizierungsdatensatz hinzufügt, bis dieser vollständig ist, wonach der Authentifizierer(3) den Authentifizierungsdatensatz an den Verteiler (2) überträgt, welcher aus dem vollständigen Authentifizierungsdatensatz und dem Softwareupdate ein Softwareupdatepaket erstellt und dieses an die Empfänger (4) verteilt.Danach ist es in beiden Varianten vorgesehen, dass der Empfänger (4) die nötigen Daten seinerseits berechnet und mit den empfangenen (Anteilen der) Daten vergleicht, wobei im Falle der Übereinstimmung das Softwareupdate installiert oder ansonsten verworfen wird.

Description

• Die Erfindung betrifft ein Verfahren zum sicheren Verteilen eines durch einen Ersteller erstellten Softwareupdates für Steuergeräte in Fahrzeugen, nach der in den Oberbegriffen von Anspruch 1 und 2 näher definierten Art.
• Im Allgemeinen ist es so, dass moderne Fahrzeuge, und hier insbesondere Personenkraftwagen und Nutzfahrzeuge, Teil eines großen Fahrzeug-Ökosystems sind. Ein zentraler Teil dieses Ökosystems ist dabei das sogenannte Backend. Dies ist ein fahrzeugexterner Server, welcher meist von dem Fahrzeughersteller betrieben wird. Die Fahrzeuge sind über das Internet mit diesem fahrzeugexternen Server verbunden. Die Kommunikation zwischen diesem Backend und den Fahrzeugen wird dabei typischerweise über kryptografische Verfahren abgesichert, um einerseits die Privatsphäre des Fahrzeugnutzers zu wahren und um andererseits keinen externen Eingriff in den Datenverkehr zu ermöglichen, welcher insbesondere bei der Übertragung von Daten, welche die Fahrzeugsteuerung betreffen, von Hackern genutzt werden könnte, um die Fahrzeuge anzugreifen und wichtige Funktionen zu manipulieren.
• Gängige Praxis ist dabei der Einsatz von asymmetrischen Schlüsseln bzw. auf asymmetrischer Kryptografie basierenden Verfahren. Diese werden typischerweise in Form des sogenannten TLS (Transport Layer Security), manchmal auch des IPSec (Internet Protocol Security) eingesetzt, die ihrerseits herkömmliche asymmetrische Verfahren, wie z.B. das auf Primzahlenzerlegung basierende RSA oder ECC (Elliptic Curve Cryptography) nutzen.
• Die typischerweise eingesetzten asymmetrischen kryptografischen Verfahren wie beispielsweise, ECC oder RSA haben dabei den Vorteil, dass sie nach heutigem Stand eine relativ sichere Absicherung bei minimiertem Aufwand bieten. All diese Verfahren beruhen dabei jedoch auf kryptografischen Algorithmen, deren Sicherheit als nicht robust gegenüber Quantencomputern angesehen wird. Quantencomputer sind durch die Art, mit der sie rechnen in der Lage asymmetrische kryptografische Verfahren zu knacken und abgesicherte Daten zu entschlüsseln. Die für die Kommunikation zwischen Fahrzeug und Backend typischerweise eingesetzten Verfahren zur kryptografischen Absicherung, also insbesondere zur Verschlüsselung und/oder Authentifizierung, sind dann nicht mehr sicher. Diese sogenannte Post-Quanten-Bedrohung war bisher eine eher theoretische Bedrohung, da Quantencomputer noch als reine Forschungsinstrumente galten und nur mit sehr hohem finanziellem Aufwand zu realisieren waren. In den vergangenen Jahren hat sich die Entwicklung von Quantencomputer jedoch deutlich beschleunigt. Eine sichere Prognose, dass ausreichend leistungsfähige Quantencomputern in den kommenden zehn Jahren am Markt nicht kommerziell verfügbar sein werden, lässt sich daher aus heutiger Sicht nicht mehr treffen.
• Fahrzeuge, welche heute auf den Markt kommen, werden in der Regel 10 bis 15 Jahre auf den Straßen unterwegs sein. Dies bedeutet, dass die Post-Quanten-Bedrohung, also die potenzielle Möglichkeit durch zu einem späteren Zeitpunkt leicht oder insbesondere einfach verfügbare Quantencomputer die herkömmliche kryptografische Absicherung einfach zu knacken, bereits für heute auszuliefernde Fahrzeuge relevant ist. Die Kommunikation einer Kommunikationsvorrichtung des Fahrzeugs mit dem externen Server, welche über heute meist auf RSA oder ECC basierende kryptografische Protokolle abgesichert ist, wäre also mit dem Eintreten dieser Post-Quanten-Bedrohung nicht mehr sicher, sodass eine sichere Kommunikation aus heutiger Sicht nicht über die gesamte zu erwartende Betriebsdauer der Fahrzeuge gewährleistet werden kann.
• Um der Post- Quanten-Bedrohung gerecht zu werden, wird allgemein seit einigen Jahren an asymmetrischen Algorithmen geforscht, die resistent gegen die Post-Quanten-Bedrohung sind. Es handelt sich dabei um die gängigerweise als Post-Quantum-Cryptography oder PQC bezeichneten Ansätze. Diese sind jedoch noch nicht sehr ausgereift, sodass sie sich heute noch nicht dazu eignen, die herkömmlichen Verfahren zu ersetzen. Damit können also heutige Fahrzeuge noch nicht mit post-quanten-fähigen kryptografischen Absicherungsverfahren konzipiert werden, da derartige Techniken noch nicht so weit ausgereift sind, dass eine abschließende Beurteilung der zu erwartenden Sicherheit möglich ist. Außerdem gibt es bisher keine Standardisierung und die Ansätze haben einen hohen Ressourcenbedarf. Ein vorauseilender Umstieg auf solche quantencomputerresistente kryptografische Verfahren ist also zum jetzigen Zeitpunkt weder sinnvoll noch einfach möglich. Gäbe es bereits ein als ausreichend sicher angesehenes standardisiertes PQC-Verfahren, so wäre auch ein solches nicht sinnvoll in die heutigen Kommunikationsvorrichtungen von Fahrzeugen zu implementieren, da ein höherer Kostenaufwand und ein hoher Ressourcenverbrauch der Wirtschaftlichkeit im aktuellen Fahrzeug-Ökosystem entgegenstehen.
• Ferner ist es so, dass symmetrische Verfahren wie beispielsweise AES (Advanced Encryption Standard) oder Hash-Verfahren wie beispielsweise SHA-512 (Secure Hash Algorithm) oder auch symmetrische Authentifizierungsverfahren wie beispielsweise HMAC (Hashed Message Authentication Code) nach heutigem Kenntnisstand von der Post-Quanten-Bedrohung nicht fundamental betroffen sind. Nach heutigem Kenntnisstand wäre die Sicherheit dieser Verfahren durch das Eintreten der Post-Quanten-Bedrohung zwar halbiert, sodass beispielsweise ein 128 Bit-Schlüssel nach Verfügbarkeit von Quantencomputern noch eine 64-Bit Sicherheit liefert. Eine solche Schwächung lässt sich jedoch relativ einfach durch erhöhte Schlüssellängen ausgleichen.
• Dies spielt insbesondere auch bei der Verteilung von Softwareupdates an Fahrzeugsteuergeräte eine Rolle, somit wäre es vorteilhaft, bereits heute eine post-quanten-resistente Implementierung einer Software-Update-Funktion im Fahrzeug vorzusehen.
• Ein typischer Software-Update-Vorgang kann als fünfgeteilt angesehen werden.
1. 1. Im ersten Schritt wird das zu installierende Softwarepaket von einem Ersteller erstellt, also die Software erzeugt und zu einem authentifizierbaren und übertragbaren Softwarepaket zusammengesetzt.
2. 2. Im zweiten Schritt wird das Softwarepaket von einem Authentifizierer mit einem Authentifizierungsstempel versehen, typischerweise asymmetrisch digital signiert, anschließend werden das Softwarepaket und der Authentifizierungsstempel zu einem Software-Update-Paket (SWU-Paket) zusammengesetzt, also SWU-Paket = (Softwarepaket, Authentifizierungsstempel).
3. 3. Im dritten Schritt wird das SWU-Paket an den oder die jeweiligen Empfänger, also bspw. sich im Feld befindliche Fahrzeuge, übermittelt.
4. 4. Im vierten Schritt wird die Authentizität des empfangenen Softwarepaketes anhand des empfangenen Authentifizierungsstempels vom Empfänger geprüft.
5. 5. Abhängig vom Ergebnis der Authentizitätsprüfung wird im fünften Schritt das empfangene Softwarepaket installiert oder verworfen.
• Des Weiteren können drei typische Szenarien für den für das SWU-Paket genutzten Übertragungsweg unterschieden werden.
• • Klassisch in der Werkstatt. Das Software-Update wird direkt am Fahrzeug mit Hilfe eines Software-Update-Gerätes durchgeführt. Dabei befindet sich das zu installierende SWU-Paket auf diesem SWU-Gerät oder lokal auf einem Rechner in der Werkstatt und ist an diese zuvor verteilt worden, bspw. auf einem physikalisch zugestellten Datenträger, oder wurde von dieser von einem zentralen SWU-Server heruntergeladen.
• • Over-the-Air (OTA-SWU). Das SWU-Paket wird von einem zentralen SWU-Server über die Fahrzeug-Internetverbindung heruntergeladen und auf den jeweiligen Steuergeräten installiert.
• • Zu Hause. Das Fahrzeug erhält das SWU-Paket von einem Datenträger, den der Kunde an das Fahrzeug anschließt, oder lädt es sich über das Heim-WLAN-Netzwerk des Kunden vom zentralen SWU-Server selbst direkt herunter.
• Um für Steuergeräte einer Fahrzeugflotte effizient einen Software-Update durchführen zu können, ist es insbesondere vorteilhaft, wenn an alle Fahrzeuge und über alle vorgesehenen Übertragungskanäle (bspw. Over-the-Air (OTA), in der Werkstatt, über WLAN in der Kundengarage etc.) das gleiche SWU-Paket verteilt/übertragen wird, m.a.W., dass dieses SWU-Paket für die einzelnen Fahrzeuge und/oder die einzelnen Übertragungskanäle nicht „individualisiert“ werden muss, also nicht an das einzelne Fahrzeug und/oder den einzelnen Übertragungskanal angepasst, bspw. dafür speziell übersetzt bzw. erzeugt und/oder speziell authentifiziert, bspw. jeweils mit einem anderen fahrzeugindividuellen Schlüssel, etc., werden muss. Insbesondere in Situationen, in denen die einzelnen Schritte des oben skizzierten Software-Update-Vorgangs zeitlich stark voneinander entkoppelt sind und von den einzelnen Akteuren unabhängig voneinander durchgeführt werden, bei denen insb. der Empfänger während der Authentizitätsprüfung keine Online-Verbindung zum Aussteller des Authentifizierungsstempels, dem Authentifizierer, hat, bspw. im Offline-Werksstatt-Szenario, kann das ein großer Vorteil sein. Ein weiterer Vorteil des Verzichts auf Individualisierung ist, dass der Authentifizierer die potentiellen Empfänger, deren Anzahl etc., nicht kennen muss. Er bestätigt lediglich die Authentizität des Softwarepaketes und überlässt es den einzelnen Empfängern, ob sie es verwenden oder nicht.
• Aus dem Verzicht auf die Individualisierung folgt u.a., dass bei der Erstellung des neuen SWU-Paketes auf die Verschlüsselung des Softwarepakets in der Regel verzichtet wird bzw. verzichtet werden muss, denn zum einen müsste dabei der gleiche Inhalt (das gleiche Softwarepaket) und zum anderen das gleiche für die Entschlüsselung des verschlüsselten Softwarepakets zu nutzende Geheimnis an sehr viele zum Teil potentiell unsichere oder nicht vertrauenswürdige Teilnehmer verteilt werden, so dass nicht davon ausgegangen werden kann, dass sowohl das (allen Teilnehmern gleichermaßen bekannte) Geheimnis als auch das (für alle Teilnehmer gleiche) Softwarepaket selbst durch eine Verschlüsselung wirkungsvoll geschützt werden könnten. Damit können bei einer klassischen nicht-individualisierten Vorgehensweise keine vertraulichen Informationen im Rahmen des Software-Updates an die Empfänger verteilt werden.
• Der Authentifizierung des Softwarepakets kommt hingegen eine sehr große unverzichtbare Bedeutung zu, denn der Empfänger der potentiell über unsichere Übertragungskanäle verteilten neuen Software muss sicher sein, dass diese von einer dafür vorgesehenen vertrauenswürdigen Quelle stammt, bevor er diese neue Software in seinem System installiert. Auf konventionellen asymmetrischen Verfahren wie bspw. RSA oder ECC basierende digitale Signaturen eignen sich hervorragend zur Durchführung eines effizienten authentifizierten Software-Updates in einer Fahrzeugflotte. Dabei werden die zu authentifizierenden Daten, in unserem Fall das Softwarepaket, mit dem privaten Schlüssel des Erstellers des Softwarepakets PrivKeyErsteller, der nur dem Ersteller selbst bekannt ist, digital signiert. Davor oder parallel dazu wird der zum für die Signaturerstellung genutzten privaten Schlüssel des Erstellers PrivKeyErsteller korrespondierende öffentliche Schlüssels des Erstellers PubKeyErsteller an jeden potentiellen Empfänger des neuen Softwarepakets, also bspw. an jede potentiell betroffene ECU, integritätsgeschützt, bspw. in Form eines digitalen Zertifikats, bspw. bei der Herstellung der ECU, übermittelt, wobei der öffentliche Schlüssel nicht geheim gehalten werden muss und frei verteilt werden kann. Nach Empfang der neuen Software in Form des aus dem neuen Softwarepaket und dessen Signatur bestehenden SWU-Pakets überprüft jeder Empfänger die Authentizität des Softwarepakets mit dem zuvor an ihn übermittelten öffentlichen Schlüssel des Erstellers PubKeyErsteller. Passen die im SWU-Paket enthaltenen Softwarepaket und Signatur zueinander, so darf das Softwarepaket installiert werden. Passen das Softwarepaket und die Signatur nicht zueinander, so darf keine Installation vorgenommen werden.
• Leider können auf konventionellen asymmetrischen Verfahren basierende digitale Signaturen nach dem Eintreten der Post-Quanten-Bedrohung nicht mehr sicher genutzt werden, insbesondere auch nicht zur Bildung digitaler Signaturen zur Absicherung des Software-Updates. Will man also bereits heute in den Fahrzeug-Steuergeräten einen post-quanten-resistentem Schutz für ein sicheres Software-Update implementieren, so muss auf post-quanten-resistente Authentifizierungsverfahren wie hashbasierte digitale Signaturen (Merkle-Signaturen) oder auf symmetrische kryptographische Verfahren mit ausreichender Schlüssellänger zurückgegriffen werden. In diesem Zusammenhang kann auf die nicht vorveröffentlichte deutsche Anmeldung mit dem Aktenzeichen 10 2020 001 199.3 der Anmelderin hingewiesen werden. Ferner beschäftigt sich die DE 10 2020 003 739 A1 detailliert mit der Thematik.
• Die Verwendung hashbasierter Signaturen ist naheliegend und wird bspw. in „Post Quantum Software Updates“, Gazdag, Friedl, Loebenberger, in Informatik 2019, Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2019, Seiten 459 bis 472, vorgeschlagen. Da hashbasierte digitale Signaturen nach heutigen Erkenntnissen post-quanten-resistent sind und auf die gleiche Weise wie konventionelle bspw. auf RSA bzw. ECC basierende digitale Signaturen verwendet werden können, besitzen sie alle der oben aufgeführten Vorteile konventioneller digitaler Signierverfahren. Die größten Nachteile hashbasierter digitaler Signierverfahren im Kontext des Software-Updates im Fahrzeugumfeld sind die begrenzte Anzahl von Nachrichten, die mit dem gleichen öffentlichen Schlüssel überprüft werden können, und die relativ lange Signatur. Diese Nachteile sind jedoch signifikant. Mit den immer größere Verbreitung findenden Over-the-Air-Software-Updates (OTA-SWU) nimmt die Größe der zu aktualisierenden Softwarepakete ab und die Anzahl durchgeführter Software-Updates und damit die Anzahl vom Empfänger durchzuführender Authentizitätsprüfungen zu. Dieser Trend wird in Zukunft noch signifikant durch die neuen agilen Softwareentwicklungsmodelle, die derzeit verstärkt im automobilen Umfeld Einsatz finden und es zum Ziel haben, die Fahrzeugsoftware schnell und flexibel an die neuen Kundenbedürfnisse anpassen zu können, verstärkt. Dem steht die begrenzte Anzahl von Datensätzen, die bei hashbasierten Signierverfahren mit dem gleichen öffentlichen Schlüssel überprüft werden können, entgegen. Außerdem vergrößern lange Signaturen hashbasierter Verfahren nicht nur die Größe der beim OTA-SWU einzeln zu übertragenden SWU-Pakete, sondern führen auch zu einem größeren Speicherbedarf bei sehr kleinen ECUs. Da bei einem OTA-SWU die SWU-Pakete einzeln zu jedem einzelnen Empfänger übertragen werden müssen, sind die dabei entstehenden Übertragungskosten proportional zur Größe des SWU-Paketes. Somit wirkt sich der Verzicht auf die Individualisierung m Falle eines OTA-SWU zwar positiv bei der Generierung des SWU-Paketes, die nur einmalig zu erfolgen hat, aus; er hat jedoch keine positive Auswirkung auf die Übertragung der einzelnen SWU-Pakete; ist der nicht-individualisierte Authentifizierungsstempel dabei größer als der individualisierte Authentifizierungsstempel, so wirkt sich die Nicht-Individualisierung sogar nachteilig auf die Übertragungskosten aus.
• Auf symmetrischer Kryptographie basierende Authentifizierungsverfahren wie bspw. HMAC sind zwar, wie in der oben genannten nicht vorveröffentlichten deutschen Anmeldung mit dem Aktenzeichen 10 2020 001 199.3 und der DE 10 2020 003 739 A1 beschrieben, bei ausreichender Schlüssellänge post-quanten-resistent, eignen sich jedoch viel schlechter zur Durchführung eines nicht-individualisierten authentifizierten Software-Updates. Das hat damit zu tun, dass bei symmetrischer Authentifizierung für die Erzeugung des Authentifizierungstempels, bspw. eines MAC, und für dessen Überprüfung der gleiche (geheime) geteilte Schlüssel SharedKey verwendet wird. Damit ist eine auf eine konventionelle Weise durchgeführte Authentifizierung, indem zuerst die benötigten Schlüssel (hier bspw. SharedKey) unter den Partnern verteilt bzw. unter ihnen ausgehandelt werden und anschließend diese Schlüssel für die Erzeugung und die anschließende Überprüfung des Authentifizierungsstempels genutzt werden, nur bei höchstens zwei Teilnehmern, also einem Ersteller und höchstens einem Empfänger, sicher möglich. Denn bereits bei zwei Empfängern würden sich drei Parteien (der Ersteller und die zwei Empfänger) den einen geheimen Schlüssel SharedKey teilen. Damit könnte ein Empfänger nie sicher sein, wer das an ihn übermittelte Softwarepaket authentifiziert hat, ob der (vertrauenswürdige) Ersteller oder der (ggf. nicht vertrauenswürdige) andere Empfänger.
• Die Aufgabe der hier vorliegenden Erfindung besteht deshalb darin ein verbessertes Verfahren zum Verteilen von Softwareupdates anzugeben, welches die oben genannten Nachteile vermeidet und post-quanten-resistent ist.
• Erfindungsgemäß wird diese Aufgabe durch das Verfahren in den Ansprüchen 1 und 2 gleichermaßen gelöst. Vorteilhafte Ausgestaltungen und Weiterbildungen ergeben sich aus den hiervon abhängigen Unteransprüchen.
• Es wird vorgeschlagen, zur Absicherung des Software-Updates ein symmetrisches individualisiertes, also empfänger-individuelle Authentifizierungsstempel erzeugendes, Authentifizierungsverfahren mit ausreichender Schlüssellänge, bspw. HMAC auf Basis SHA-512, einzusetzen. Dabei wird davon ausgegangen, dass, um miteinander post-quanten-resistent kommunizieren zu können, die Teilnehmer des Fahrzeug-Ökosystems, insb. auch die Empfänger der SWU-Pakete, mit individuellen nur mit dem Authentifizierer geteilten Geheimnissen bzw. Schlüsseln ausgestattet sind, bspw. wie in der nicht vorveröffentlichten deutschen Anmeldung mit dem Aktenzeichen 10 2020 001 199.3 der Anmelderin und der DE 10 2020 003 739 A1 beschrieben.
• Dabei müssen die individuellen symmetrischen Schlüssel beim Empfänger lesegeschützt, am besten in einem Hardware Security Modul (HSM), abgelegt werden. Die sichere Ablage individueller Geheimnisse in Fahrzeug-Steuergeräten war noch vor wenigen Jahren eine kaum zu erfüllende teure Anforderung, was wiederum einer der Gründe für die starke Favorisierung asymmetrischer digitaler Signierverfahren, die für die Prüfung der Authentizität eines Softwarepaketes lediglich den nicht-vertraulichen öffentlichen Schlüssel des Authentifizierers benötigen, war. Vor mehr als zwanzig Jahren, als die ersten Software-Update-Prozesse für Fahrzeugflotten etabliert worden sind, war eine derartige Individualisierung der Fahrzeug-Steuergeräte, von den Schließsystemen abgesehen, nahezu ausgeschlossen. Inzwischen hat sich die Situation stark verändert, die Nutzung eines HSM in zumindest großen und mittelgroßen Fahrzeug-Steuergeräten ist Stand der Technik, die Individualisierung von Fahrzeug-Steuergeräten auch, so steht einer effizienten sicheren Ausstattung eines Fahrzeug-Steuergerätes mit individuellem geheimem symmetrischem Schlüsselmaterial nichts im Wege.
• Um für eine Fahrzeugflotte ein effizientes Software-Update-Verfahren mit symmetrischer Authentifizierung umzusetzen, wird ein System aus einem zentralen Ersteller, einem zentralen Verteiler, einem zentralen Authentifizierer und beliebig vielen Empfängern vorgeschlagen, wobei die drei zentralen Rollen in einem oder mehreren Systemen in einem Backend zusammengefasst sein können.
• Bei einem initialen Provisioning werden alle Empfänger und der Authentifizierer mit der Implementierung einer kryptographisch sicheren insbesondere kollisionsresistenten Hashfunktion HASH, bspw. SHA-512, und mindestens eines gemeinsamen sicheren post-quanten-resistenten symmetrischen Authentifizierungsverfahrens AUTH, bspw. HMAC auf Basis SHA-512, ausgestattet. Des Weiteren wird jeder Empfänger ID_i auf eine sichere weise mit einem mit dem Authentifizierer geteilten individuellen symmetrischen Schlüssel ausreichender Länge (bspw. 256 Bit) für AUTH (authKEY_IDi ^Auth) ausgestattet. Beides kann wie bspw. in der nicht vorveröffentlichten deutschen Anmeldung mit dem Aktenzeichen 10 2020 001 199.3 der Anmelderin und der DE 10 2020 003 739 A1 beschrieben vorgenommen werden.
• Die erfindungsgemäße Lösung gemäß Anspruch 1 sieht es dann vor, dass der Ersteller oder ein Verteiler, dem der Ersteller das Softwareupdate authentifiziert übertragen hat, das Softwareupdate oder einen mittels einer Hashfunktion erstellten Hashwert des Softwareupdates authentizitätsgeschützt an einen Authentifizierer überträgt. Der Verteiler verteilt dann das Softwareupdate ohne Authentifizierung und für alle Empfänger identisch an diese, was den Vorgang sehr einfach und effizient macht.
• Jeder der Empfänger übermittelt dann seine Identität und die des empfangenen Softwareupdates an den Authentifizierer. Dieser prüft ob ihm ein Hashwert des Softwareupdates vorliegt oder, wenn nur das Softwareupdate als solches vorliegt, erstellt er diesen aus dem Softwareupdate mittels der Hashfunktion. Der Authentifizierer hat aufgrund des oben beschriebenen Provisionings jeweils einen mit jedem der Empfänger geteilten individuellen Schlüssels. So dass er also für jeden der Empfänger über einen anderen nur mit diesem geteilten Schlüssel verfügt. Diesen kann er nun für jeden der Empfänger und damit für jede der Anfragen einzeln nutzen, um einen individualisierten Authentifizierungsstempel zu erstellten und an den anfragenden Empfänger zu übertragen.
• Nach dem Empfang des individualisierten Authentifizierungsstempels berechnet der Empfänger mit der Hashfunktion den Hash des Softwareupdates und den individualisierten Authentifizierungsstempel mit Hilfe des mit dem Authentifizierer exklusiv geteilten Schlüssels und vergleicht den vom Authentifizierer empfangenen Authentifizierungsstempel mit dem berechneten Authentifizierungsstempel, wobei im Falle der Übereinstimmung das Softwareupdate installiert oder ansonsten verworfen wird.
• Eine alternative Lösung desselben Problems unter Verwendung der selben Mittel mit einem geringfügig anderen Ablauf schlägt Anspruch 3 vor. Der Unterschied besteht hier darin, dass der Authentifizierer einen vollständigen Authentifizierungsdatensatz erstellt, indem er sukzessive für alle in Frage kommenden Empfängeridentitäten mit Hilfe eines mit dem jeweiligen Empfänger individuell geteilten Schlüssels einen individualisierten Authentifizierungsstempel für das Softwareupdate erstellt und zu dem Authentifizierungsdatensatz hinzufügt, bis dieser vollständig ist. Der vollständige Authentifizierungsdatensatz wird von ihm dann authentifiziert an den Verteiler übertragen, welcher aus dem vollständigen Authentifizierungsdatensatz und dem Softwareupdate ein Softwareupdatepaket erstellt und dieses an die Empfänger verteilt. Der bevorzugte Weg kann hierbei die Verteilung des relativ großen Softwareupdatepakets über Werkstätten sein.
• Der weitere Ablauf ist dann im Wesentlichen derselbe wie oben beschreiben, wo die für den Vergleich herangezogenen übermittelten Daten nicht vom Authentifizierer stammen, sondern Teil des Softwareupdatepakets waren, in dem sich der Empfänger dann seinen Authentifizierungsstempel aus dem vollständigen Authentifizierungsdatensatz ausliest, um ihn mit den eigenen, bevorzugt lokal durchgeführten Berechnungen zu vergleichen.
• Beide genannten Lösungen ermöglichen folgende Vorteile:
• - Das Verfahren erlaubt eine sichere und praktikable Durchführung eines SoftwareUpdates in einem Fahrzeug-Ökosystem, wobei ausschließlich etablierte symmetrische auf geteilten Schlüsseln basierende kryptographische Verfahren eingesetzt werden.
  • o Damit kann beim Software-Update komplett auf asymmetrische Kryptographie verzichtet werden.
  • o Damit wird das Software-Update post-quanten-resistent abgesichert.
• - Durch das individuelle Authentifizieren des (kleinen) Hashwertes des Softwarepaketes und nicht des (um Größenordnungen größeren) Softwarepaketes selbst kann der bei der Generierung der SWU-Pakete durch die individualisierte Authentifizierung entstehende Mehraufwand signifikant reduziert werden.
• - Der zwischen einem Empfänger und dem Authentifizierer geteilte symmetrische Schlüssel kann sicher zur Authentifizierung beliebig vieler Softwarepakete verwendet werden, was ein Vorteil gegenüber hashbasierten digitalen Signierverfahren ist.
• - Durch die Aufteilung des Softwarepaketes in einen nicht-individualisierten und einen individualisierten Anteil lassen sich bestimmte Teile des Softwarepaketes empfänger-individuell gestalten, insb. lassen sich so vertrauliche Bereiche des Softwarepaketes empfänger-individuell verschlüsseln und damit vertraulichkeitsgeschützt zum Empfänger übertragen.
  • ◯ Insbesondere lässt sich auf diese Weise das von der neuen Software ggf. benötigte geheime empfänger-individuelle Schlüsselmaterial sicher zum Empfänger übermitteln.
• Für die zuerst genannte Lösung gemäß Anspruch 1 ergeben sich ferner die folgenden Vorteile:
• - Die im Vergleich zu hashbasierten digitalen Signaturen signifikant kürzeren symmetrischen Authentifizierungsstempel führen, insbesondere wegen der im OTA-SWU-Fall typischerweise relativ kurzen Softwarepakete, zu signifikant kürzeren SWU-Paketen.
• - Durch die mögliche getrennte Verteilung nicht-individualisierter Softwarepakete und individualisierter Authentifizierungsstempel kann der durch die individualisierte Authentifizierung entstehende Mehraufwand signifikant reduziert werden.
• Bei der zweiten genannten Lösung gemäß Anspruch 3 ergibt sich außerdem der folgende Vorteil:
• - Durch eine mit vertretbarem Aufwand mögliche Erstellung und Verteilung eines vollständigen Authentifizierungsdatensatzes kann ein Authentifizierungsvorgang bei Bedarf, insbesondere auch in einem Offline-Werksstatt-Szenario, auch ohne eine bestehende Kommunikationsverbindung zum Authentifizierer praktikabel durchgeführt werden.
• Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens ergeben sich aus den abhängigen Unteransprüchen und aus den Ausführungsbeispielen, welche nachfolgend unter Bezugnahme auf die Figur näher dargestellt sind.
• Die einzige beigefügte Figur zeigt dabei eine schematische Darstellung des Erfindungsgemäßen Verfahrens und seiner Voraussetzungen.
• Um für eine Fahrzeugflotte ein effizientes Software-Update-Verfahren mit symmetrischer Authentifizierung umzusetzen, wird ein System aus einem zentralen Ersteller 1, einem zentralen Verteiler 2, einem zentralen Authentifizierer 3 und beliebig vielen Empfängern 4 vorgeschlagen, wobei die drei zentralen Rollen in einem oder mehreren Systemen in einem Backend, z.B. dem Backend eines Fahrzeugherstellers, zusammengefasst sein können. Die Empfänger 4 sind dabei individuelle Fahrzeuge bzw. Fahrzeugsteuergeräte.
• Bei einem initialen Provisioning werden alle Empfänger und der Authentifizierer mit der Implementierung einer kryptographisch sicheren insbesondere kollisionsresistenten Hashfunktion HASH, bspw. SHA-512, und mindestens eines gemeinsamen sicheren post-quanten-resistenten symmetrischen Authentifizierungsverfahrens AUTH, bspw. HMAC auf Basis SHA-512, ausgestattet. Des Weiteren wird jeder Empfänger ID_i auf eine sichere weise mit einem mit dem Authentifizierer geteilten individuellen symmetrischen Schlüssel ausreichender Länge (bspw. 256 Bit) für AUTH (authKEY_IDi ^Auth) ausgestattet. Beides kann wie bspw. in der nicht vorveröffentlichten deutschen Anmeldung mit dem Aktenzeichen 10 2020 001 199.3 der Anmelderin und der DE 10 2020 003 739 A1 beschrieben vorgenommen werden.
• In einem ersten Ausführungsbeispiel 1 kann es vorgesehen sein, dass bei einem Software-Update-Vorgang von den einzelnen Akteuren folgende Aktionen vorgenommen werden:
1. 1. Der Ersteller 1 erstellt das von den Fahrzeugen zu installierende Softwareupdate Softwarepaket_SwID und übergibt es authentizitätsgeschützt an den Verteiler 2.
2. 2. Der Verteiler 2 oder alternativ der Ersteller 1 überträgt an den Authentifizierer 3 authentizitätsgeschützt das gesamte Softwareupdate oder alternativ den mit Hilfe der kryptographisch sicheren insbesondere kollisionsresistenten Hashfunktion HASH erzeugten Hashwert des Softwareupdates, also Hash_SwID := HASH(Softwarepaket_SwID).
3. 3. Der Verteiler 2 verteilt das für alle Empfänger 4 gleiche Softwareupdate Softwarepaket_SwID über diverse ihm zur Verfügung stehenden Übertragungskanäle (bspw. Over-the-Air (OTA), in der Werkstatt über WLAN bzw. einen Datenträger, bspw. einen USB-Datenträger, über WLAN in der privaten Garage etc.) an die jeweiligen Empfänger 4, ohne es mit einem Authentifizierungstempel zu versehen.
   1. a. Auf diese Weise kann eine effiziente Verteilung, wie z.B. eine Broadcast-Verteilung, des Softwareupdates erreicht werden.
4. 4. Bevor der Empfänger 4 das empfangene Softwareupdate installiert, prüft er dessen Authentizität, indem folgende Schritte durchgeführt werden:
   1. a. Der Empfänger 4 sendet an den Authentifizierer 3 die eigene Identität ID_i und die eindeutige Identität des Softwareupdates SwID, wobei die Identität SwID für dieses Softwareupdate für alle Empfänger 4 gleich ist.
   2. b. Der Authentifizierer 3 identifiziert das zur empfangenen SwID gehörende Softwareupdate Softwarepaket_SwID und prüft, ob er dazu schon dessen Hashwert vorliegen hat. Wenn das nicht der Fall ist, erzeugt er mit Hilfe der kryptographisch sicheren post-quanten-resistenten und insbesondere kollisionsresistenten Hashfunktion HASH den Hashwert Hash_SwID des Softwareupdates SwID.
5. 5. Der Authentifizierer 3 erzeugt einen Authentifizierungsstempel AuthSt_SwID ^IDi für den Hashwert des Softwareupdates mit Hilfe des mit dem Empfänger 4 individuell geteilten Schlüssels authKEY_IDi ^Auth, also AuthSt_SwID ^IDi := AUTH(authKEY_IDi ^Auth, Softwarepaket_SwID)
   1. a. Der Authentifizierer 3 überträgt den individualisierten Authentifizierungsstempel AuthSt_SwID ^IDi an den Empfänger 4
   2. b. Nach Empfang des Authentifizierungsstempels berechnet der Empfänger 4 mit Hilfe der kryptographisch sicheren post-quanten-resistenten und insbesondere kollisionsresistenten Hashfunktion HASH seinerseits den Hashwert des empfangenen Softwareupdates mit der Identität SwID.
   3. c. Der Empfänger 4 berechnet den Authentifizierungsstempel für den Hashwert des Softwareupdates mit Hilfe des mit dem Authentifizierer 3 exklusiv geteilten Schlüssels authKEY_IDi ^Auth.
   4. d. Der Empfänger 4 vergleicht den empfangenen Authentifizierungsstempel mit dem berechneten Authentifizierungsstempel. Sind sie gleich, war die Authentifizierung des Softwareupdates SwID erfolgreich. Sind die ungleich, ist die Authentifizierung des Softwareupdates SwID fehlgeschlagen.
• Durch die potentielle Auftrennung des Softwareupdate-(SWU)-Paketes in das (für alle Empfänger 4 gleiche) Softwarepaket und den (empfänger-individualisierten) Authentifizierungsstempel und deren potentielle separate Übertragung zum Empfänger 4 können die beiden Verteilvorgänge (Verteilung des nicht-individualisierten Softwarepakets und Verteilung der individualisierten Authentifizierungsstempel) bei Bedarf getrennt vorgenommen und getrennt optimiert werden.
• - Die ressourcenintensive Generierung des Softwarepaketes muss vom Ersteller 1 nur einmal vorgenommen werden.
• - Der Aufwand für die Erzeugung des Authentifizierungsstempels, insbesondere eines symmetrischen MAC, hängt maßgeblich von der Größe der zu authentifizierenden Daten ab. Indem der Hashwert des gesamten potentiell mehrere hundert Megabyte oder sogar einige Gigabyte großen Softwarepaketes unabhängig von der potentiell sehr großen Anzahl der Empfänger 4 mit HASH nur einmal berechnet werden muss und pro Empfänger 4 anschließend nur kurze Datensätze (bspw. 512 Bit bei HASH = SHA-512) authentifiziert werden müssen, wird der Gesamtaufwand für die Berechnung der Authentifizierungsstempel für alle Empfänger 4, die aus Gründen der Verwendung individueller symmetrischer Schlüssel für jeden einzelnen Empfänger 4 getrennt berechnet werden müssen, erheblich gesenkt.
• - Indem das (für alle Empfänger 4 gleiche) Softwarepaket vom Verteiler 2 ohne den (individualisierten) Authentifizierungsstempel verteilt werden kann, kann dessen Verteilung effizient, ggf. im Broadcast-Modus, vorgenommen werden. Insbesondere muss der Verteiler 2 dabei keine empfänger-individualisierten Daten generieren, vorhalten bzw. versenden.
• - Der individualisierte von jedem einzelnen Empfänger 4 einzeln anzustoßende Authentifizierungsvorgang kann wegen der Kürze des zu authentifizierenden Datensatzes (Hashwert statt Softwarepaket) sehr effizient und schnell vom Authentifizierer 3 durchgeführt werden.
• - Bei den meisten Szenarien (insb. OTA-SWU, Online-Werksstatt-SWU, SWU beim Kunden über sein WLAN) existiert eine Onlineverbindung, die für das Abholen des individuellen Authentifizierungsstempels genutzt werden kann.
• - Bis auf den für die Erstellung und die Prüfung des Authentifizierungsstempels genutzten geteilten individuellen Schlüssel bedarf der Authentifizierungsvorgang keines weiteren Schutzes, insb. muss weder die Authentifizierungsanfrage des Empfängers 4 noch die Übertragung des Authentifizierungsstempels zum Empfänger 4 über einen geschützten Kanal vorgenommen werden.
• Das oben vorgestellte Verfahren, insbesondere der Authentifizierungsvorgang, setzt eine bidirektionale Kommunikationsverbindung zwischen einem Empfänger 4, der das neue Softwarepaket installieren soll, und dem Authentifizierer 3 voraus. Auch wenn diese Kommunikation keinen zeitlichen Anforderungen unterliegt und bspw. auch vollkommen asynchron über ungesicherte Email erfolgen kann, kann jedoch nicht davon ausgegangen werden, dass eine solche Verbindung zu jeder Zeit und an jedem Ort existiert. Es ist eine der großen Stärken der für die Authentifizierung der Softwarepakete asymmetrische digitale Signaturen nutzenden Software-Update-Verfahren, dass das gesamte SWU-Paket, also auch der Authentifizierungsstempel, nicht individualisiert werden muss und damit zur Überprüfung des Authentifizierungsstempels von allen Empfängern 4 der gleiche öffentliche Schlüssel des Erstellers 1 genutzt werden kann, wodurch wiederum der Bedarf einer Verbindung zur Zentrale wegfällt, wodurch insb. auch das Werkstatt-Szenario ohne Online-Verbindung gut realisiert werden kann.
• Dieser Nachteil des oben beschriebenen Verfahrens lässt sich zumindest zum Teil dadurch beheben, dass dem Authentifizierer 3 die Identitäten ID_i aller potentiellen Empfänger 4 spätestens mit der Hinterlegung der symmetrischen mit diesen Empfängern 4 exklusiv geteilten Schlüssel bekannt sind bzw. dabei bekanntgegeben werden und dieser präventiv einen vollständigen aus allen möglichen (ID_i, AuthSt_SwID ^IDi)-Paaren bestehenden Authentifizierungsdatensatz erstellt. Dabei stellt weder die Berechnung der individuellen Authentifizierungsstempel noch die Speicherung des vollständigen Authentifizierungsdatensatzes auf einem Datenträger oder dessen Übertragung über eine moderne Internetverbindung eine nennenswerte Herausforderung dar. Bei bspw. einer Länge des Authentifizierungsstempels von 512 Bit, was 64 Bytes entspricht, und der Verwendung von 36 Bytes für die Identität IDi werden pro Empfänger 4 100 Bytes benötigt. Bei einer Million betroffener Empfänger 4 würde die Größe des vollständigen Authentifizierungsdatensatzes 100 Megabyte betragen. Bei 10 Millionen Fahrzeugen wäre es ein Gigabyte. Ebenso wenig stellt die Berechnung von einer Million oder zehn Millionen symmetrischer MACs kurzer Datensätze eine Hürde dar. Dieser vollständige Authentifizierungsdatensatz enthält keine vertraulichen Informationen und kann anschließend jedermann zur Verfügung gestellt werden, bspw. an Werkstätten verteilt (Werkstatt-Szenario, insb. auch Offline-Werkstätten ohne Internetanbindung) oder zum freien Download angeboten werden. Ebenso kann er, ähnlichen der digitalen Signatur im asymmetrischen Fall, in bestimmten Fällen als Teil des SWU-Paketes an das Softwarepaket gehängt werden und damit, abgesehen von der ggf. stark angewachsenen Größe des SWU-Paketes, eine vollständig nicht-individualisierte Verteilung des kompletten nicht-individualisierten SWU-Paketes („vollständiges SWU-Paket“) insb. auch an Werkstätten erlauben.
• Da bei den beiden anderen Szenarien (OTA-SWU, Update in der privaten Garage per WLAN) das Softwarepakten nicht so groß ist und natürlicherweise Internet-Verbindungen bestehen, können in diesen Szenarien somit bevorzugt nicht-authentifizierte Softwareupdate verteilt und dann effizient über die Empfänger 4 beim Authentifizierer 3 authentifiziert werden.
• Bei Bedarf können auch semivollständige Authentifizierungsdatensätze bzw. semivollständige SWU-Pakete mit den Daten einer speziellen Teilmenge aller betroffenen Fahrzeuge bzw. Steuergeräte erstellt und verteilt werden, bspw. Authentifizierungsdatensätze mit den Authentifizierungsdaten einzelner Fahrzeugmodelle, einzelner Regionen oder Herstellungsjahre. Dadurch kann die Größe des verwendeten Authentifizierungsdatensatzes bzw. SWU-Paketes erheblich reduziert werden.
• In einem zweiten Ausführungsbeispiel kann es vorgesehen sein, dass bei einem Software-Update-Vorgang von den einzelnen Akteuren folgende Aktionen vorgenommen werden, wobei in dem Ausführungsbeispiel als Akteur eine „Werkstatt“ hinzukommt:
1. 1. Der Ersteller 1 erstellt das von den Fahrzeugen zu installierendes Softwarepaket SwID und übergibt es authentizitätsgeschützt an den Verteiler.
2. 2. Der Verteiler 2 überträgt an den Authentifizierer 3 authentizitätsgeschützt den mit Hilfe einer kryptographisch sicheren insbesondere kollisionsresistenten Hashfunktion HASH erzeugten Hashwert des Softwarepaketes SwID, also Hash_SwID := HASH(Softwarepaket_SwID).
3. 3. Der Authentifizierer 3 erstellt den vollständigen Authentifizierungsdatensatz, indem er sukzessive für jede in Frage kommende Empfänger-Identität IDi mit Hilfe des mit dem Empfänger 4 individuell geteilten Schlüssels authKEY_IDi ^Auth einen Authentifizierungsstempel AuthSt_SwID ^IDi für den Hashwert Hash_SwID des Softwarepaketes mit der Identität SwID erzeugt und überträgt den so erstellten vollständigen Authentifizierungsdatensatz an den Verteiler 2.
4. 4. Der Verteiler 2 bildet das aus dem Softwarepaket und dem vollständigen Authentifizierungsdatensatz bestehende (für alle Nutzer gleiche) vollständige SWU-Paket und verteilt dieses über diverse ihm zur Verfügung stehende Übertragungskanäle (bspw. über einen Internet-Download, über Email oder per Post oder Kurier auf einem Datenträger) an interessierte Nutzer, bspw. Werksstätten.
5. 5. Der Nutzer des den vollständigen Authentifizierungsdatensatz enthaltenden vollständigen SWU-Paketes speichert es lokal ab, bspw. auf seinem SWU-Gerät.
6. 6. Beim bei einem konkreten Empfänger 4 mit der Identität ID_i durchzuführenden Software-Update wird dieser mit dem SWU-Gerät der Werkstatt verbunden, dabei wird dem Empfänger 4 das zu installierende Softwarepaket und anhand der dem SWU-Gerät mitgeteilten Identität ID_i des Empfängers 4 der passende Authentifizierungsstempel AuthSt_SwID ^IDi übermittelt.
7. 7. Anschließend prüft der Empfänger 4 die Authentizität des Softwarepaketes, indem er die im ersten Ausführungsbeispiel aufgeführten Schritte durchführt.
• Wie oben dargestellt, hat die sichere Nutzung symmetrischer Authentifizierung die Individualisierung des Software-Update-Vorgangs zur Folge. Da der mit der Individualisierung verbundene Mehraufwand bei dem beschriebenen Verfahren nicht sinnvoll vermieden werden kann, kann die Individualisierung des Software-Update-Vorgangs ohne weiteren signifikanten Mehraufwand über die bisher beschriebene Bildung eines empfängerindividuellen Authentifizierungsstempels ausgebaut werden,
• Es wird daher vorgeschlagen, das Softwarepaket mit der Identität SwID in einen nicht-individualisierten Anteil Softwarepaket_SwID ^Shared und einen (für einen Empfänger 4 mit der Identität ID_i) individualisierten Anteil Softwarepaket_SwID ^IDi aufzuteilen, wobei zum individualisierten Anteil bspw. auch (empfänger-individuell) verschlüsselte Anteile gehören können. Auf diese Weise kann der nicht-individualisierte Anteil des Softwarepaketes einmal gehasht und anschließend dieser gleiche Hashwert für alle Empfänger 4 verwendet werden, wodurch beim SWU-Server Rechenzeit eingespart werden kann. Außerdem muss bei einer potentiellen Erstellung eines vollständigen SWU-Datensatzes dieser nicht-individualisierte Softwarepaket-Anteil nur einmal abgelegt werden, wodurch die Größe des vollständigen SWU-Datensatzes signifikant reduziert wird, da der nicht-individualisierte Anteil eines Softwarepaketes i.d.R. um Größenordnungen größer als dessen individualisierter Anteil ist.
• Dadurch ergibt sich folgende allgemeine Struktur eines für den Empfänger 4 mit der Identität ID_i individualisierten SWU-Paketes, wobei sowohl der nicht-individualisierte als auch der individualisierte Anteil leer, also nicht vorhanden, sein können und getrennt authentifiziert werden.
  ((Softwarepaket_SwID ^Shared, AuthSt_SwID ^Shared,IDi), (Softwarepaket_SwID ^IDi, AuthSt_SwID ^IDi,IDi))
• Dabei steht im letzten Term das erste IDi für den für IDi individualisierten Anteil, das zweite IDi für den zu IDi gehörenden Schlüssel.
• Diese Struktur kann weiterhin optimiert werden, indem ein gemeinsamer Authentifizierungsstempel für beide Anteile des Softwarepaketes berechnet wird. Dabei ist es weiterhin sinnvoll, um im SWU-Server Rechenleistung zu sparen, einen separaten Hashwert für den nicht-individualisierten Anteil zu berechnen, und diesen Hashwert dann gemeinsam mit dem individualisierten Anteil des Softwarepaketes zu authentifizieren.
• Es wird des Weiteren vorgeschlagen, einen gemeinsamen Authentifizierungsstempel für beide Anteile des Softwarepaketes zu verwenden, indem er folgedermaßen berechnet wird: $$\begin{array}{l}{\text{AuthSt}}_{\text{SwID}}{}^{\text{IDI}}:=\\ \text{AUTH}\left({\text{authKEY}}_{\text{IDI}}{}^{\text{Auth}},\text{ HASH}\left({\text{Softwarepaket}}_{\text{SwID}}{}^{\text{Shared}}\right)\Vert \text{HASH}\left({\text{Softwarepaket}}_{\text{SwID}}{}^{\text{IDI}}\right)\right)\end{array}$$

  
• Alternativ kann auf das Hashen des individualisierten Anteils des Softwarepaketes vor der Bildung des Authentifizierungsstempels verzichtet werden, also $$\begin{array}{l}{\text{AuthSt}}_{\text{SwID}}{}^{\text{IDI}}:=\\ \text{AUTH}\left({\text{authKEY}}_{\text{IDI}}{}^{\text{Auth}},\text{ HASH}\left({\text{Softwarepaket}}_{\text{SwID}}{}^{\text{Shared}}\right)\Vert {\text{Softwarepaket}}_{\text{SwID}}{}^{\text{IDI}}\right)\end{array}$$

  
• Dadurch ergibt sich folgende allgemeine Struktur eines individualisierten SWU-Paketes, wobei sowohl der nicht-individualisierte als auch der individualisierte Anteil leer, also nicht vorhanden, sein können. $$\left({\text{Softwarepaket}}_{\text{SwID}}{}^{\text{Shared}},{\text{Softwarepaket}}_{\text{SwID}}{}^{\text{IDI}},{\text{AuthSt}}_{\text{SwID}}{}^{\text{IDI}}\right),$$

  

  wobei hier jeweils nur das IDi für den Schlüssel zu finden ist.
• Die Aufteilung des Softwarepaketes in einen nicht-individualisierten und einen individualisierten Anteil ermöglicht des Weiteren bei Bedarf eine ohne nennenswerten Mehraufwand umzusetzende individualisierte Verschlüsselung von Teilen des individualisierten Anteils des Softwarepaketes. In diesem Fall müssten beide Seiten ein symmetrisches Verschlüsselungsverfahren ENCR implementiert haben und über das dazu passende Schlüsselmaterial verfügen, was bspw. nach dem in DE 10 2020 003 739 A1 beschriebenen Verfahren mit vertretbarem Aufwand erfolgen kann. Dabei könnten auch kombinierte AEAD-Verschlüsselungsverfahren wie bspw. AES-CCM oder AES-GCM, eingesetzt werden, bei denen in einem Schritt die Authentifizierung und die Verschlüsselung durchgeführt werden und für beide Operationen der gleiche Schlüssel genutzt wird (AEAD - authenticated encryption with associated data).
• Dabei sollte sinnvollerweise nach Möglichkeit nicht der gesamte individualisierte Anteil des Softwarepaketes verschlüsselt werden, was bei einer individuellen Verschlüsselung zu einer signifikanten Belastung des SWU-Servers und zu einem extremen Anwachsen der Größe eines vollständigen SWU-Paketes, das für jeden Empfänger 4 ein separates individualisiertes Softwarepaket enthalten müsste, führen könnte, sondern nur vertrauliche Anteile wie bspw. die Implementierungen verwendeter kryptographischer Primitive. Des Weiteren lassen sich so such empfänger-individuelle geheime Daten, wie bspw. empfänger-individuelle kryptographische Geheimnisse wie geheime oder private Schlüssel, sicher zum Empfänger 4 übermitteln. Wie oben angemerkt, sollte dabei beachtet werden, dass individuell verschlüsselte Daten, da sie Teil des individualisierten Anteils des Softwarepaketes werden, mehrfach erzeugt und mehrfach in einem vollständigen SWU-Paket vorgehalten werden müssten. Bei bspw. 100 Kilobyte individuell verschlüsselter Daten und 10 Millionen Empfängern würde der Anteil individualisierter verschlüsselter Daten in einem vollständigen SWU-Paket auf ein Terabyte ansteigen.
• ZITATE ENTHALTEN IN DER BESCHREIBUNG
• Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
• Zitierte Patentliteratur
• DE 102020003739 A1 [0014, 0016, 0019, 0022, 0034, 0050]
• DE 10 2020 001 199.3 [0022]

Claims (10)

1. Verfahren zum sicheren Verteilen eines durch einen Ersteller (1) erstellten Softwareupdates für Steuergeräte in einem Fahrzeug an eine Vielzahl von Empfängern (4), mit einer post-quanten-resistenten Authentifizierung, dadurch gekennzeichnet, dass der Ersteller (1) oder ein Verteiler (2), dem der Ersteller (1) das Softwareupdate authentifiziert übertragen hat, das Softwareupdate oder einen mittels einer Hashfunktion (HASH) erstellten Hashwert des Softwareupdates authentizitätsgeschützt an einen Authentifizierer (3) überträgt; der Verteiler (2) das Softwareupdate ohne Authentifizierung an die Empfänger (4) übertragt, wonach jeder der Empfänger (4) seine Identität (ID_i) und die Identität (SwID) des empfangenen Softwareupdates an den Authentifizierer (3) sendet, welcher prüft ob ihm ein Hashwert des Softwareupdates vorliegt oder wenn nur das Softwareupdate vorliegt diesen Hashwert mit der Hashfunktion (HASH) erstellt und für den Hashwert mit Hilfe eines mit jedem Empfänger (4) individuell geteilten Schlüssels (AuthKey_IDi ^AUTH) einen individualisierten Authentifizierungsstempel (AuthSt_SwID ^IDi) erstellt und an den anfragenden Empfänger (4) überträgt; nach dem Empfang des individualisierten Authentifizierungsstempels (AuthSt_SwID ^IDi) berechnet der Empfänger (4) mit der Hashfunktion (HASH) den Hash des Softwareupdates und den individualisierten Authentifizierungsstempel (AuthSt_SwID ^IDi) mit Hilfe des mit dem Authentifizierer (3) exklusiv geteilten Schlüssels (AuthKey_IDi ^AUTH) und vergleicht den vom Authentifizierer (3) empfangenen Authentifizierungsstempel (AuthSt_SwID ^IDi) mit dem berechneten Authentifizierungsstempel (AuthSt_SwID ^IDi), wobei im Falle der Übereinstimmung das Softwareupdate installiert oder ansonsten verworfen wird.
2. Verfahren zum sicheren Verteilen von Softwareupdates gemäß Anspruch 1, dadurch gekennzeichnet, dass die von dem Authentifizierer (3) an den jeweiligen Empfänger (4) übermittelten Daten zumindest teilweise über ein symmetrisches Verschlüsselungsverfahren verschlüsselt werden.
3. Verfahren zum sicheren Verteilen eines durch einen Ersteller (1) erstellten Softwareupdates für Steuergeräte in einem Fahrzeug an eine Vielzahl von Empfängern (4), mit einer post-quanten-resistenten Authentifizierung, dadurch gekennzeichnet, dass der Ersteller (1) oder ein Verteiler (2), dem der Ersteller (1) das Softwareupdate authentifiziert übertragen hat, das Softwareupdate oder einen mittels einer Hashfunktion (HASH) erstellten Hashwert des Softwareupdates authentizitätsgeschützt an einen Authentifizierer (3) überträgt; der Authentifizierer (3) einen vollständigen Authentifizierungsdatensatz erstellt, indem er sukzessive für alle Empfängeridentitäten (ID_i) mit Hilfe eines mit dem jeweiligen Empfänger (4) individuell geteilten Schlüssels (AuthKey_IDi ^AUTH) einen individualisierten Authentifizierungsstempel (AuthSt_SwID ^IDi) für das Softwareupdate erstellt und dem Authentifizierungsdatensatz hinzufügt, bis dieser vollständig ist, wonach der Authentifizierer (3) den vollständigen Authentifizierungsdatensatz authentifiziert an den Verteiler (2) überträgt, welcher aus dem vollständigen Authentifizierungsdatensatz und dem Softwareupdate ein Softwareupdatepaket erstellt und dieses an die Empfänger (4) verteilt; nach dem Empfang des Softwareupdatepakets berrechnet der Empfänger (4) mit der Hashfunktion (HASH) den Hash des Softwareupdates und den individualisierten Authentifizierungsstempel (AuthSt_SwID ^IDi) mit Hilfe des mit dem Authentifizierer (3) exklusiv geteilten Schlüssels (AuthKey_IDi ^AUTH) und vergleicht den in dem vollständigen Authentifizierungsdatensatz des Softwareupdatepakets enthaltenen Authentifizierungsstempel (AuthSt_SwID ^IDi) mit dem berechneten Authentifizierungsstempel (AuthSt_SwID ^IDi), wobei im Falle der Übereinstimmung das Softwareupdate installiert oder ansonsten verworfen wird.
4. Verfahren zum sicheren Verteilen von Softwareupdates gemäß Anspruch 1 oder 3, dadurch gekennzeichnet, dass eine Aufteilung des Softwareupdatepaketes in einen für jeden der Empfänger (4) individualisierten und für alle Empfänger (4) gleichen nicht-individualisierten Anteil erfolgt, wobei die Verfahrensschritte für beide Anteile durchgeführt werden.
5. Verfahren zum sicheren Verteilen von Softwareupdates gemäß Anspruch 4, dadurch gekennzeichnet, dass für beide Anteile ein gemeinsamer Authentifizierungsstempel berechnet wird.
6. Verfahren zum sicheren Verteilen von Softwareupdates gemäß Anspruch 4 oder 5, dadurch gekennzeichnet, dass zumindest Teile des individualisierten Anteils über ein symmetrisches Verschlüsselungsverfahren verschlüsselt werden, bevor sie an den Verteiler (2) übermittelt werden.
7. Verfahren zum sicheren Verteilen von Softwareupdates gemäß Anspruch 4, 5 oder 6, dadurch gekennzeichnet, dass der individualisierte Anteil oder der nicht-individualisierte Anteil leer ist.
8. Verfahren zum sicheren Verteilen von Softwareupdates gemäß einem der Ansprüche 3 bis 7, dadurch gekennzeichnet, dass als Empfänger (4) für die der vollständige Authentifizierungsdatensatz erstellt wird eine ausgewählte Gruppe von möglichen Empfängern (4) verwendet wird.
9. Verfahren zum sicheren Verteilen von Softwareupdates gemäß einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass als Hashfunktion (HASH) eine kryptografisch sichere post-quanten-resistente und insbesondere kollisionsresistente Hashfunktion verwendet wird.
10. Verfahren zum sicheren Verteilen von Softwareupdates gemäß einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass der individuelle Schlüssel (AuthKey_IDi ^AUTH) jedes Empfängers (4) lokal in einem Hardware Security Modul (HSM) beim Empfänger (4) abgelegt ist.

Images