DE10354107A1

DE10354107A1 - Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten

Info

Publication number: DE10354107A1
Application number: DE10354107A
Authority: DE
Inventors: Burkhard Kuhls; Harry Knechtel; Marco Hofmann
Original assignee: Bayerische Motoren Werke AG
Current assignee: Bayerische Motoren Werke AG
Priority date: 2003-07-04
Filing date: 2003-11-19
Publication date: 2005-01-20
Also published as: CN1816787A; CN100365533C

Abstract

Die Erfindung bezieht sich auf ein Verfahren zur Authentifikation eines von einem Software-Bereitsteller bereitgestellten Softwarepaketes, welche eine in ein Endgerät ladbare Softwarekomponente enthält, wobei die Softwarekomponente mit einem Authentifikationsanhang versehen wird, welcher zur Durchführung einer Authentizitätsprüfung in dem Endgerät überprüft wird, wobei eine übergeordnete Authentisierungsstelle vorgesehen ist, welche zur Erhöhung der Sicherheit authentisierende Maßnahmen an dem Softwarepaket durchführt. Die Erfindung zeichnet sich dadurch aus, dass die von der übergeordneten Authentisierungsstelle (15, 16) durchgeführten Maßnahmen nach erfolgreicher Prüfung des von dem Software-Bereitsteller (11, 12) bereitgestellten und neben der Softwarekomponente (SW, FSC) einen ersten Authentifikationsanhang (XZ) umfassenden Softwarepaketes (13, 14) das Versehen des Softwarepaketes (13, 14; 18, 19) mit wenigstens einem zweiten Authentifikationsanhang (IZ) an Stelle des ersten Authentifikationsanhangs (XZ) umfassen.

Description

Die Erfindung bezieht sich auf ein Verfahren zur Authentifikation eines von einem Software-Bereitsteller bereitgestellten Softwarepaketes, welche eine in ein Endgerät ladbare Softwarekomponente enthält, wobei die Softwarekomponente mit einem Authentifikationsanhang versehen wird, welcher zur Durchführung einer Authentizitätsprüfung in dem Endgerät überprüft wird, wobei eine übergeordnete Authentisierungsstelle vorgesehen ist, welche zur Erhöhung der Sicherheit authentisierende Maßnahmen an dem Softwarepaket durchführt.

Ein derartiges Verfahren ist beispielsweise aus DE 101 40 721 A1 für die Bereitstellung von Software zur Verwendung durch ein Steuergerät eines Fahrzeuges bekannt. Grundlegende Aufgabe solcher Authentifikationsverfahren ist es, sicherzustellen, dass keine unberechtigten und 1 oder schädlichen Softwarekomponenten in ein softwaregesteuertes Endgerät geladen werden. Diese Problematik ist insbesondere im Kraftfahrzeugbereich von hoher Brisant, da moderne Kraftfahrzeuge mit einer Vielzahl von softwaregesteuerten Steuergeräten ausgestattet sind, deren korrekte Funktion Vorraussetzung für einen sicheren Betrieb des Kraftfahrzeugs ist. Das Laden unautorisierter Software kann hierbei ein erhebliches Sicherheitsrisiko darstellen. Zudem sind heutzutage viele Leistungs- und / oder Komfortmerkmale moderner Kraftfahrzeuge softwarebasiert. D.h., Fahrzeuge werden mit einer für eine hohe Leistungs- und / oder Komfortstufe geeigneten Hardware ausgestattet, diese jedoch individuell nach Kundenwunsch gegebenenfalls kostenpflichtig durch Software angesteuert. Die entsprechende Software kann dabei entweder individuell in entsprechende Steuergeräte geladen werden oder bereits vorinstallierte Software individuell, z.B. durch Laden sogenannter Freischaltcodes, aktiviert werden. Durch unberechtigtes Laden und / oder Freischalten von Software können den Fahrzeugherstellern erhebliche wirtschaftliche Verluste entstehen, wenn dies ohne Zahlung der vorgesehenen Gebühren erfolgt. Andererseits erfordert die arbeitsteilige Industrie- und Gesellschaftsstruktur die Auslagerung vieler wesentlicher Aufgaben an Zulieferer, Werkstätten etc., sodass ein Authentifkationssystem erforderlich ist, das einerseits strikte Kontrolle über die Implementation von Software in Endgeräten ge währt, andererseits aber die notwendige Flexibilität für ein kundenfreundliches Servicemanagement ermöglicht.

Bei dem bekannten Verfahren ist vorgesehen, dass eine Softwaresignaturstelle, insbesondere der Softwarehersteller, die zu ladenden Softwarekomponenten, z.B. Programmcodes und / oder Freischaltcodes mit einem für sie privaten Schlüssel signiert und die so signierte Software an eine übergeordnete Authentisierungsstelle, das zum Beispiel beim Fahrzeughersteller beheimatete sogenannte Trust-Center, weitergeleitet werden. In dem Trust-Center erfolgt dann eine Prüfung der Signatur des Software-Bereitstellers und eine „Beglaubigung" der Signatur. Die „Beglaubigung" erfolgt in Form des Anhängens eines Trust-Center-Zertifikates, welches neben einer mit einem privaten Schlüssel des Trust-Centers erstellten Signatur vorzugsweise den öffentlichen Schlüssel des Software-Bereitstellers sowie ein oder mehrere Gültigkeitsbeschränkungen für die Softwarekomponente enthält.

Beim Laden der Softwarekomponente wird dann zunächst mittels eines im Endgerät abgelegten öffentlichen Schlüssels des Trust-Centers die Trust-Center-Signatur geprüft, anschließend mit Hilfe des übermittelten öffentlichen Schlüssels des Software-Bereitstellers, dessen Signatur überprüft und gegebenenfalls verschlüsselte Bereiche des Softwarepaktes entschlüsselt und schließlich die Softwarekomponente unter Berücksichtigung der mit dem Trust-Center-Zertifikat übermittelten Gültigkeitsbeschränkungen installiert.

Dieses Verfahren hat den Nachteil, dass jedes Endgerät in der Lage sein muss, sowohl die Signaturen / Zertifikate des Trust-Centers als auch des Software-Bereitstellers zu verarbeiten. Bei der Vielzahl unterschiedlicher Endgeräte unterschiedlicher Hersteller und einer ebenfalls großen Vielzahl unterschiedlicher Software-Bereitsteller erfordert dies eine erhebliche Komplexität des Aufbaus jedes Endgerätes. Oder aber die technische Bindung an bestimmte Zulieferer, welche sich durch Schaffung eigener Normen dadurch ein faktisches Zuliefermonopol sichern können.

Es ist daher eine Aufgabe der vorliegenden Erfindung, ein gattungsgemäßes Authentifikationsverfahren derart weiterzubilden, dass ohne Sicherheitseinbußen die Flexibilität des Gesamtsystems erhöht und der Aufbau einzelner Systemkomponenten vereinfacht wird.

Diese Aufgabe wird in Verbindung mit den Merkmalen des Oberbegriffs von Anspruch 1 dadurch gelöst, dass die von der übergeordneten Authentisierungsstelle durchgeführten Maßnahmen nach erfolgreicher Prüfung des von dem Software-Bereitsteller bereitgestellten und neben der Softwarekomponente einen ersten Authentifikationsanhang umfassenden Softwarepaketes das Versehen des Softwarepaketes mit wenigstens einem zweiten Authentifikationsanhang an Stelle des ersten Authentifikationsanhangs umfassen. Dies bedeutet, dass die jeweiligen Endgeräte von der Aufgabe entbunden werden, die Authentifikationsanhänge, also z.B. Signaturen und / oder Zertifikate, der Software-Bereitsteller interpretieren und berücksichtigen zu müssen. Statt der bisher üblichen „Beglaubigung" von Zertifikaten, Signaturen, etc. der Software-Bereitsteller werden diese erfindungsgemäß durch zentral, z.B. von dem Trust-Center, vergebene Authentifikationsanhänge ersetzt. Die Endgeräte müssen daher nur noch mit dem von dem Trust-Center verwendeten Signatur und / oder Zertifizierungsverfahren kompatibel sein und können entsprechend einfacher aufgebaut sein als bisher. Gleichzeitig entsteht jedoch keine Sicherheitslücke, da die Vergabe des zentralen Authentifikationsanhangs erst nach Prüfung der Authentifikationsanhänge der Software-Bereitsteller durchgeführt wird. Dies bietet auch die Möglichkeit, kurzfristig auf Änderungen der Berechtigung einzelner Software-Bereitsteller zum Bereitstellen von Software zu reagieren.

Man beachte, dass sich die Begriffe „Ersetzen" und „an Stelle" eines Authentifikationsanhangs hier auf ein funktionales Ersetzen beziehen. Vorzugsweise, jedoch nicht notwendigerweise, geht damit auch ein physikalisches Ersetzen der entsprechenden Daten in dem Softwarepaket einher. Die erfindungsgemäße Aufgabe wird jedoch auch erfüllt, indem das Gesamtsystem so eingerichtet ist, dass beim Laden der Softwarekomponente in das Endgerät lediglich die Authentifikationsanhänge des Trust-Centers berücksichtigt und die von dem Trust-Center bereits geprüften Authentifikationsanhänge des Softwarebereitstellers ignoriert werden.

Wie bereits erwähnt, bietet das erfindungsgemäße Verfahren die Möglichkeit, dass die Prüfung des Softwarepaketes durch die übergeordnete Authentisierungsstelle eine Prüfung der aktuellen Berechtigung des Software-Bereitstellers zum Bereitstellen von Softwarekomponenten umfasst. Bei einer vorteilhaften Weiterbildung des erfindungsgemäßen Verfahren ist diese Option auch tatsächlich verwirklicht.

Besonders günstig ist es, das erfindungsgemäße Verfahren nach dem PKI-Konzept (public key infrastructure) aufzubauen. Hierzu kann etwa vorgesehen sein, dass der erste Authentifikationsanhang des von dem Software-Bereitsteller bereitgestellten Softwarepaketes wenigstens teilweise mit einem für diesen privaten Schlüssel verschlüsselt und mit einem der übergeordneten Authentisierungsstelle bekannten, öffentlichen Schlüssel entschlüsselbar ist. Dies entspricht der Signierung bzw. Zertifizierung nach dem bekannten PKI-Konzept. Der öffentliche Schlüssel des Software-Bereitstellers kann dabei im Rahmen eines Zertifikates an die übergeordnete Authentisierungsstelle übermittelt werden oder dieser auf anderem Wege zur Kenntnis gebracht werden, so dass statt eines Zertifikates eine einfache Signierung des Software-Bereitstellers ausreichend ist.

In konsequenter Weiterführung des PKI-Konzeptes kann bei einer Weiterbildung des erfindungsgemäßen Verfahren vorgesehen sein, dass der wenigstens eine zweite Authentifikationsanhang durch die übergeordnete Authentisierungsstelle wenigstens teilweise mit einem für diese privaten Schlüssel verschlüsselt und mit einem in dem Endgerät bekannten, öffentlichen Schlüssel entschlüsselbar ist. Auch hier kann, wenn keine Verschlüsselung aus Geheimhaltungsgründen vorliegt, der öffentliche Schlüssel im Rahmen eines Zertifikates übermittelt werden. Andererseits ist es auch möglich, den öffentlichen Schlüssel in einem nichtzugänglichen Speicherbereichs des Endgerätes, d.h. unter Geheimhaltung abzulegen.

Der Grundgedanke des erfindungsgemäßen Verfahrens lässt ein hohes Maß an Flexibilität zu. Insbesondere ist es möglich, innerhalb der übergeordneten Authentisierungsstelle eine Authentisierungs-Hierarchie zu schaffen. So kann bei einer vorteilhaften Weiterbildung etwa vorgesehen sein, dass das Softwarepaket von der übergeordneten Authentisierungsstelle nacheinander mit mehreren Authentifikationsanhängen versehen wird, wobei ein Authentifikationsanhang, mit dem das Softwarepaket zu einem früheren Zeitpunkt versehen wurde, zur Durchführung einer Authentizitätsprüfung vor einem nachfolgenden Versehen des Softwarepaketes mit einem Authentifikationsanhang verwendet wird. Dies lässt beispielsweise ein System der Signierung und „Beglaubigung", das zwei- oder mehrstufig ausgebildete sein kann, innerhalb der übergeordneten Authentisierungsstelle zu.

Wird ein derart hierarchisch strukturiertes Authentisierungskonzept verwendet, ist es vorteilhaft, wenn beim Laden der Softwarekomponente in das Endgerät und / oder bei Ausführung der Softwarekomponente in dem Endgerät eine Authentizitätsprüfung unter Verwendung mehrerer Authentifikationsanhänge der übergeordneten Authentisierungsstelle durchgeführt wird. Dies bedeutet, anders ausgedrückt, dass in dem Endgerät die mehrstufige Authentisierung schrittweise nachvollzogen bzw. überprüft werden kann, wobei jedoch als positive Wirkung der vorliegenden Erfindung nur Kompatibilität mit den von der übergeordneten Authentisierungsstelle verwendeten Signatur- bzw. Zertifizierungsverfahren erforderlich ist.

Wie oben bereits erwähnt, besteht die Möglichkeit, dass ein von der übergeordneten Authentisierungsstelle angehängter Authentifikationsanhang auf eine Beschränkung der Funktionalität der betroffenen Softwarekomponente bezogene Daten enthält. Bei einer vorteilhaften Ausgestaltung des erfindungsgemäßen Verfahrens ist diese Option auch tatsächlich implementiert. Die Funktionalitäts- oder Gültigkeitsbeschränkungen können die Freischaltung bestimmter Applikationen und gegebenenfalls Versionsstände der jeweiligen Applikationen betreffen. Weiter sind Individualisierungen auf das Fahrzeug (z.B. über die Fahrgestellnummer) oder bestimmte Fahrzeugtypen bzw. auf ein oder mehrere Steuergeräte oder Steuergerätetypen (z.B. über eine Steuergerätenummer), auf einzelne Personen (z.B. über eine individualisierte Chipkarte etwa im Fahrzeugschlüssel integriert) oder über eine GSM-Karte im Autotelefon möglich. Weiter können temporäre Gültigkeitsbeschränkungen eingebaut sein. Beispiele hierfür sind die begrenzte Gültigkeit für einen Zeitabschnitt, eine Betriebsstundenzahl, eine Kilometerleistung oder (applikationsspezifisch) eine bestimmte Anzahl von Funktionsaufrufen. Weiter können selektive Gültigkeitsbeschränkungen vorgesehen sein, d.h. applikationsspezifische Einschränkungen im Sinne einer Demoversion oder einer Version mit reduziertem Funktionsumfang. Schließlich besteht auch die Möglichkeit einer regionalen Gültigkeitsbeschränkung, die beispielsweise an den aktuellen Standort eines Fahrzeugs gekoppelt ist. Derartige Gültigkeits- bzw. Funktionalitätsbeschränkungen sind insbesondere wirksam, wenn eine Überprüfung der Gültigkeit durch das Endgerät nicht oder nicht nur beim erstmaligen Laden der Softwarekomponenten, sondern auch wiederholt während des späteren Betriebs durchgeführt werden. Dabei ist selbstverständliche eine boolsche Verknüpfung mehrerer Gültigkeitsbeschränkungen möglich.

Die in das Endgerät zu ladenden Softwarekomponenten können beispielsweise Programmcodes und / oder Freischaltcodes für im Endgerät installierte Programmcodes enthalten.

Das Endgerät, ist wie oben bereits angedeutet, vorzugsweise ein Steuergerät eines Kraftfahrzeuges, wobei unter dem Begriff „Steuergerät" sowohl Steuergeräte im eigentlichen Sinn zur Ansteuerung bestimmter Fahrzeugkomponenten gemeint sind, als auch weitere Komfortausstattungen, wie z.B. Navigations- oder Informationssysteme.

Weitere Einzelheiten der Erfindung ergeben sich aus der nachstehenden, ausführlichen Beschreibung und der beigefügten Zeichnung, in der eine bevorzugte Ausführungsform der Erfindung beispielhaft veranschaulicht ist.
In der Zeichnung zeigt:
1 ein Blockdiagramm einer Authentifikations-Infrastruktur zur Durchführung des erfindungsgemäßen Verfahrens.
In 1 ist eine Infrastruktur dargestellt, wie sie zur Durchführung einer Ausführungsform des erfindungsgemäßen Verfahrens in einer Anwendung für das Management von Software, welche insbesondere für den Betrieb von Steuergeräten in Kraftfahrzeugen (FZG) vorgesehen ist, geeignet ist. Gestrichelt dargestellt sind die Informationswege bei Verfahren nach dem Stand der Technik.
Zentrale Stelle der Infrastruktur nach dem Stand der Technik ist das sog. Trust-Center (TC) 10, das üblicherweise unter direkter Kontrolle eines Fahrzeugherstellers steht. Das TC 10 steht im Informationsaustausch mit externen Software-Bereitstellern. Dabei kann es sich z.B. um externe Software-Signaturstellen (X- SWSS) 11 handeln, die üblicherweise bei einem externen Software-Hersteller beheimatet ist, welcher beispielsweise Software (SW) in Form von Programmanweisungen für Steuergeräte erzeugt. In 1 ebenfalls dargestellt ist die Möglichkeit, dass es sich um eine externe Freischaltcode-Stelle (X-FSCS) 12 handelt, über die Freischaltcodes (FSC) für bereits in einem Steuergerät eines Fahrzeugs installierte, jedoch deaktivierte Software bereitgestellt werden. Der allgemeine, hier verwendete Begriff der „Softwarekomponente" umfasst sowohl FSC als auch Programmanweisungen sowie weitere, in ein Endgerät ladbare Software. Nach dem Stand der Technik werden die Softwarekomponenten von den externen Bereitstellern signiert, etwa durch erzeugen einer Signatur und / oder eines Zertifikates. Diese und ähnliche Signierungsergebnisse werden hier allgemein als „Authentifikationsanhänge" bezeichnet, da sie geeignet sind, Herkunft und Unversehrtheit der so behandelten Software bei einer Authentizitätsprüfung überprüfen zu lassen. Gemäß Ihrer Herkunft von einem externen Bereitsteller sind sie in 1 mit „XZ" bezeichnet. Die Authentifikationsanhänge werden nach dem Stand der Technik von dem TC 10 geprüft und bei erfolgreicher Prüfung durch Anhängen einer weiteren Signatur und / oder eines weiteren Zertifikates bestätigt. Die so signierten und „beglaubigten" Softwarekomponenten werden dann in ein Steuergerät eines Fahrzeugs geladen, wobei sowohl die Authentifikationsanhänge des TC 10 als auch die der X-SWSS 11 oder X-FSCS 12 geprüft werden müssen – jeweils mit dem speziell hierfür notwendigen Verfahren.
Das erfindungsgemäße Verfahren ist in 1 durch solide Pfeile dargestellt. Danach liefern X-SWSS 11 bzw. X-FSCS 12 Softwarepakete 13 bzw. 14, jeweils bestehend aus SW bzw. FSC und Authentifikationsanhang XZ an interne Softwaresignaturstellen (1-SWSS) 15 bzw. interne Freischaltcodestellen (1-FSCS) 16. Die internen Stellen 1-SWSS 15 und 1-FSCS 16 stehen vorzugsweise allein unter Kontrolle des Fahrzeugherstellers, sind insbesondere Teil eines hierarchisch strukturierten Fahrzeug-Trust-Centers FZG-TC 17.
Die internen Stellen 1-SWSS 15 und 1-FSCS 16 prüfen nun die Authentifikationsanhänge XZ der externen Stellen X-SWSS 11 und X-FSCS 12 und führen vorzugsweise einen Abgleich mit einer internen Datenbank durch, in der die z.B. Informationen über die aktuelle Berechtigung der externen Stellen 11 und 12 zur Bereitstellung von Softwarekomponenten abgelegt sind. Die externen Authentifikationsanhänge XZ werden bei erfolgreicher Prüfung durch interne Authentifikationsanhänge IZ ersetzt. Dies erfolgt vorzugsweise durch physikalisches Ersetzen der entsprechenden Speicherinhalte.
Es ergeben sich modifizierte Softwarepakete 18 bzw. 19, die neben SW bzw. FSC einen internen Authentifikationsanhang IZ beinhalten, der beim Laden der Softwarekomponente in das Steuergerät des Fahrzeuges FZG und / oder wiederholt während des Betriebs des Steuergerätes geprüft wird. Insbesondere können die internen Authentifikationsanhänge IZ zusätzlich Informationen über Gültigkeitsbeschränkungen der Softwarekomponenten enthalten.
Auf diese Weise wird erreicht, dass die verwendeten Steuergerät nur mit den von den internen Stellen verwendeten Authentifikationsverfahren kompatibel sein müssen, anstatt, wie bislang, auch die von den externen Stellen verwendeten Authentifikationsverfahren verarbeiten können zu müssen.
Besonders bevorzugt läuft das erfindungsgemäße Verfahren automatisch ab, wobei die zu signierenden / zertifizierenden Softwarekomponenten online an einen internen Server geschickt werden, der eine Authentifizierungsprüfung durchführt und die re-signierten / re-zertifizierten Softwarepakete weiter verteilt, z.B. an Werkstätten, Produktionsstätten, Online-Center etc. zur Übertragung in die jeweils hierfür vorgesehenen Steuergeräte.
Selbstverständlich handelt es sich bei der hier beschriebenen Ausführungsform lediglich um ein spezielles, besonders vorteilhaftes Ausführungsbeispiel der vorliegenden Erfindung. Dem Fachmann stehen im Rahmen der Erfindung eine Vielzahl von Modifikationsmöglichkeiten zur Verfügung. Insbesondere die konkrete Struktur der internen Authentifikationsanhänge IZ, ihre ggf. hierarchische Erzeugung sowie ihre spezielle Interpretation in einem Steuergerät können Gegenstand vielfältiger Ausgestaltungen sein.

Claims

Verfahren zur Authentifikation eines von einem Software-Bereitsteller bereitgestellten Softwarepaketes, welche eine in ein Endgerät ladbare Softwarekomponente enthält, wobei die Softwarekomponente mit einem Authentifikationsanhang versehen wird, welcher zur Durchführung einer Authentizitätsprüfung in dem Endgerät überprüft wird, wobei eine übergeordnete Authentisierungsstelle vorgesehen ist, welche zur Erhöhung der Sicherheit authentisierende Maßnahmen an dem Softwarepaket durchführt, dadurch gekennzeichnet, dass die von der übergeordneten Authentisierungsstelle (15, 16) durchgeführten Maßnahmen nach erfolgreicher Prüfung des von dem Software-Bereitsteller (11, 12) bereitgestellten und neben der Softwarekomponente (SW, FSC) einen ersten Authentifikationsanhang (XZ) umfassenden Softwarepaketes (13, 14) das Versehen des Softwarepaketes (13, 14; 18, 19) mit wenigstens einem zweiten Authentifikationsanhang (IZ) an Stelle des ersten Authentifikationsanhangs (XZ) umfassen.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Prüfung des Softwarepaketes (13, 14) durch die übergeordnete Authentisierungsstelle (15, 16) eine Prüfung der aktuellen Berechtigung des Software-Bereitstellers (11, 12) zum Bereitstellen von Softwarekomponenten (SW, FSC) umfasst.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der erste Authentifikationsanhang (XZ) des von dem Software-Bereitsteller (11, 12) bereitgestellten Softwarepaketes (13, 14) wenigstens teilweise mit einem für diesen privaten Schlüssel verschlüsselt und mit einem der übergeordneten Authentisierungsstelle (15, 16) bekannten, öffentlichen Schlüssel entschlüsselbar ist.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass der wenigstens eine zweite Authentifikationsanhang (IZ) durch die übergeordnete Authentisierungsstelle (15, 16) wenigstens teilweise mit einem für diese privaten Schlüssel verschlüsselt und mit einem in dem Endgerät bekannten, öffentlichen Schlüssel entschlüsselbar ist.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Softwarepaket von der übergeordneten Authentisierungsstelle nacheinander mit mehreren Authentifikationsanhängen versehen wird, wobei ein Authentifikationsanhang, mit dem das Softwarepaket zu einem früheren Zeitpunkt versehen wurde, zur Durchführung einer Authentizitätsprüfung vor einem nachfolgenden Versehen des Softwarepaketes mit einem Authentifikationsanhang verwendet wird.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass beim Laden der Softwarekomponente in das Endgerät und / oder bei Ausführung der Softwarekomponente in dem Endgerät eine Authentizitätsprüfung unter Verwendung mehrerer Authentifikationsanhänge der übergeordneten Authentisierungsstelle durchgeführt wird.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass ein von der übergeordneten Authentisierungsstelle angehängter Authentifikationsanhang (IZ) auf eine Beschränkung der Funktionalität der betroffenen Softwarekomponente (SW, FSC) bezogene Daten enthält.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Softwarekomponenten Programmcodes (SW) und / oder Freischaltcodes (FSC) für im Endgerät installierte Programmcodes enthalten.
Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Endgerät ein Steuergerät eines Kraftfahrzeuges ist.