WO2005003936A1 - Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten - Google Patents

Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten Download PDF

Info

Publication number
WO2005003936A1
WO2005003936A1 PCT/EP2004/006776 EP2004006776W WO2005003936A1 WO 2005003936 A1 WO2005003936 A1 WO 2005003936A1 EP 2004006776 W EP2004006776 W EP 2004006776W WO 2005003936 A1 WO2005003936 A1 WO 2005003936A1
Authority
WO
WIPO (PCT)
Prior art keywords
authentication
software
terminal
software package
attachment
Prior art date
Application number
PCT/EP2004/006776
Other languages
English (en)
French (fr)
Inventor
Burkhard Kuhls
Harry Knechtel
Marco Hofmann
Original Assignee
Bayerische Motoren Werke Aktiengesellschaft
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from DE10354107A external-priority patent/DE10354107A1/de
Application filed by Bayerische Motoren Werke Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to EP04740198A priority Critical patent/EP1642185A1/de
Priority to JP2006518025A priority patent/JP2007527044A/ja
Publication of WO2005003936A1 publication Critical patent/WO2005003936A1/de
Priority to US11/324,219 priority patent/US7748043B2/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates

Definitions

  • the invention relates to a method for authenticating a software package provided by a software provider, which contains a software component that can be loaded into a terminal, the software component being provided with an authentication attachment, which is checked to carry out an authenticity check in the terminal, a higher-level one Authentication point is provided, which carries out authenticating measures on the software package in order to increase security.
  • Such a method is known for example from DE 101 40 721 A1 for the provision of software for use by a control unit of a vehicle.
  • the basic task of such authentication methods is to ensure that no unauthorized and / or harmful software components are loaded into a software-controlled end device.
  • This problem is particularly explosive in the motor vehicle sector, since modern motor vehicles are equipped with a large number of software-controlled control devices, the correct function of which is a prerequisite for the safe operation of the motor vehicle. Loading unauthorized software can pose a significant security risk.
  • many of the performance and / or comfort features of modern motor vehicles are software-based today. This means that vehicles are equipped with hardware suitable for a high level of performance and / or comfort, but this is controlled individually by software, if required, at the customer's request.
  • the corresponding software can either be loaded individually into the corresponding control units or pre-installed software can be activated individually, for example by loading so-called activation codes. Unauthorized loading and / or activation of software can result in considerable economic losses for vehicle manufacturers if this is done without paying the planned fees.
  • the industrial and social structure based on the division of labor requires many essential tasks to be outsourced to suppliers, workshops, etc., so that an authentication system is required that, on the one hand, has strict control over the implementation of software in end devices. lasts, but on the other hand enables the necessary flexibility for customer-friendly service management.
  • a software signature point in particular the software manufacturer
  • the software components to be loaded e.g. Program codes and / or activation codes are signed with a private key for them and the software thus signed is forwarded to a higher-level authentication point, the so-called trust center located at the vehicle manufacturer, for example.
  • the signature of the software provider is then checked in the trust center and the signature is "authenticated”.
  • the "authentication” is carried out in the form of attaching a trust center certificate which, in addition to one with a private key of the trust center created signature preferably contains the public key of the software provider and one or more validity restrictions for the software component.
  • the trust center signature is then first checked using a public key of the trust center stored in the terminal device, then with the help of the transmitted public key of the software provider, its signature is checked and, if necessary, encrypted areas of the software package are decrypted and finally installed the software component taking into account the validity limits transmitted with the trust center certificate.
  • the measures carried out by the higher-level authentication center provide the software package with the software package after successful verification of the software package provided by the software provider and, in addition to the software component, comprising a first authentication appendix comprise at least one second authentication attachment instead of the first authentication attachment.
  • the respective end devices are released from the task, the authentication attachments, e.g. Signatures and / or certificates that the software provider must interpret and take into account.
  • the software providers instead of the "authentication" of software providers, which has been customary up to now, the software providers have replaced them according to the invention with authentication attachments issued centrally, for example by the trust center.
  • the end devices therefore only have to use the signature used by the trust center and / or certification procedures and can be correspondingly simpler than before, but at the same time there is no security gap since the central authentication attachment is only assigned after the authentication attachments of the software providers have been checked. This also offers the possibility of short-term changes the authorization of individual software providers to respond to the provision of software.
  • the terms "replace” and "in place of” an authentication attachment refer to functional replacement. Preferably, but not necessarily, this is also accompanied by a physical replacement of the corresponding data in the software package.
  • the object of the invention is also achieved in that the overall system is set up such that when the software component is loaded into the terminal, only the authentication attachments of the trust center are taken into account and the authentication attachments of the software provider that have already been checked by the trust center are ignored.
  • the method according to the invention offers the possibility of the software package being checked by the higher-level authentication point a check of the current authorization of the software provider to provide software components. In an advantageous development of the method according to the invention, this option is actually implemented.
  • the method according to the invention according to the PKI concept (public key infrastructure).
  • PKI concept public key infrastructure
  • the first authentication attachment of the software package provided by the software provider is at least partially encrypted with a private key for this private key and can be decrypted with a public key known to the higher-level authentication point.
  • the public key of the software provider can be transmitted as part of a certificate to the higher-level authentication center or can be brought to the attention of this in another way, so that a simple signing of the software provider is sufficient instead of a certificate.
  • the at least one second authentication attachment can be at least partially encrypted by the higher-level authentication point with a private key for these and decrypted with a public key known in the terminal ,
  • the public key can be transmitted as part of a certificate.
  • the basic idea of the method according to the invention allows a high degree of flexibility.
  • it can be provided, for example, that the software package is successively provided with several authentication attachments by the higher-level authentication point, an authentication attachment with which the software package was provided at an earlier point in time for carrying out an authenticity check before a subsequent one Provide the software package with 005/003936
  • an authentication attachment is used. This allows, for example, a system of signing and "authentication", which can be of two or more stages, within the higher-level authentication center.
  • an authentication attachment attached by the higher-level authentication point contains data relating to a restriction of the functionality of the software component concerned.
  • this option is actually implemented.
  • the functionality or validity restrictions can relate to the activation of certain applications and, if applicable, version statuses of the respective applications.
  • individualizations are made to the vehicle (e.g. via the chassis number) or certain vehicle types or to one or more control units or control unit types (e.g. via a control unit number), to individual people (e.g. integrated via an individualized chip card in the vehicle key, for example) or via a GSM Card possible in the car phone.
  • Temporary validity restrictions can also be implemented.
  • the software components to be loaded into the terminal can contain, for example, program codes and / or activation codes for program codes installed in the terminal.
  • control device is preferably a control device of a motor vehicle, the term “control device” meaning both control devices in the actual sense for controlling certain vehicle components and further comfort equipment such as navigation or information systems.
  • FIG. 1 shows a block diagram of an authentication infrastructure for performing the method according to the invention.
  • FIG. 1 shows an infrastructure as is suitable for carrying out an embodiment of the method according to the invention in an application for the management of software, which is intended in particular for the operation of control units in motor vehicles (FZG).
  • FZG motor vehicles
  • the central point of the infrastructure is the so-called Trust Center (TC) 10, which is usually under the direct control of a vehicle manufacturer.
  • the TC 10 exchanges information with external software providers.
  • This can be, for example, external software signature points (X- SWSS) 11 act, which is usually located at an external software manufacturer who, for example, generates software (SW) in the form of program instructions for control units.
  • SW software
  • 1 also shows the possibility that it is an external activation code point (X-FSCS) 12, via which activation codes (FSC) are provided for software that is already installed in a control unit of a vehicle but is deactivated.
  • X-FSCS external activation code point
  • FSC activation codes
  • the general term “software component” used here includes both FSC and program instructions as well as further software that can be loaded into a terminal.
  • the software components are signed by the external providers, for example by generating a signature and / or a certificate.
  • These and similar signing results are generally referred to here as “authentication attachments” since they are suitable for having the origin and integrity of the software treated in this way checked during an authenticity check. According to their origin from an external provider, they are labeled "XZ" in FIG. 1.
  • the authentication attachments are checked according to the prior art by the TC 10 and, if the check is successful, are confirmed by attaching a further signature and / or a further certificate
  • Software components signed and "authenticated” in this way are then loaded into a control unit of a vehicle, with both the authentication attachments of the TC 10 and those of the X-SWSS 11 or X-FSCS 12 having to be checked, each using the method specifically required for this.
  • X-SWSS 11 and X-FSCS 12 deliver software packages 13 and 14, each consisting of SW or FSC and authentication attachment XZ, to internal software signature points (l-SWSS) 15 or internal activation codes (l-FSCS) 16.
  • the internal positions I-SWSS 15 and I-FSCS 16 are preferably solely under the control of the vehicle manufacturer, and are in particular part of a hierarchically structured vehicle trust center FZG-TC 17.
  • the internal bodies l-SWSS 15 and l-FSCS 16 now check the authentication attachments XZ of the external bodies X-SWSS 11 and X-FSCS 12 and preferably carry out a comparison with an internal database in which, for example, information about the current authorization of the external bodies 11 and 12 for the provision of Software components are stored. If the check is successful, the external authentication attachments XZ are replaced by internal authentication attachments IZ. This is preferably done by physically replacing the corresponding memory contents.
  • modified software packages 18 and 19 which, in addition to SW or FSC, contain an internal authentication attachment IZ, which is checked when the software component is loaded into the control unit of the vehicle FZG and / or repeatedly during operation of the control unit.
  • the internal authentication attachments IZ can additionally contain information about validity restrictions of the software components.
  • control device used only has to be compatible with the authentication methods used by the internal bodies instead of having to be able to process the authentication methods used by the external bodies as before.
  • the method according to the invention particularly preferably runs automatically, the software components to be signed / certified being sent online to an internal server which carries out an authentication check and further distributes the re-signed / re-certified software packages, e.g. at workshops, production sites, online centers etc. for transfer to the control devices intended for this purpose.

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, weicher zur Durchführung einer Authentizitätsprüfung in dem Endgerät überprüft wird, wobei eine übergeordnete Authentisierungsstelle vorgesehen ist, weiche 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

Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
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 Authentisie- rungsstelle 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 be- kannt. Grundlegende Aufgabe solcher Authentifikationsverfahren ist es, sicherzustellen, dass keine unberechtigten und / 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 kor- rekte 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 Fahrzeug- herstellern 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 Authentifikationssystem 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 Au- thentifikationsverfahren 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 An- spruch 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 Au- thentifikationsanhä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 Authentifika- tionsanhangs 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 we- nigstens 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 Spei- cherbereichs 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 vor- teilhaften Weiterbildung etwa vorgesehen sein, dass das Softwarepaket von der übergeordneten Authentisierungsstelle nacheinander mit mehreren Authentifika- tionsanhä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 005/003936
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än- kungen 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ültigkeitsbe- schrä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 bool- sche 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:
Figur 1 ein Blockdiagramm einer Authentifikations-Infrastruktur zur Durchführung des erfindungsgemäßen Verfahrens.
In Figur 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 Fig. 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 Fig. 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 Fig. 1 durch solide Pfeile dargestellt. Danach liefern X-SWSS 11 bzw. X-FSCS 12 Softwarepakete 13 bzw. 14 , jeweils be- stehend aus SW bzw. FSC und Authentifikationsanhang XZ an interne Softwaresignaturstellen (l-SWSS) 15 bzw. interne Freischaltcodestellen (l-FSCS) 16. Die internen Stellen l-SWSS 15 und l-FSCS 16 stehen vorzugsweise allein unter Kontrolle des Fahrzeugherstellers, sind insbesondere Teil eines hierarchisch strukturierten Fahrzeug-Trust-Centers FZG-TC 17.
Die internen Stellen l-SWSS 15 und l-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 inter- nen 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üs- sen, 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 inter- nen 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

Patentansprüche
1. Verfahren zur Authentifikation eines von einem Software-Bereitsteller bereit- gestellten 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 authenti- sierende 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.
2. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekenn- zeichnet, 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.
3. 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, öffent- liehen Schlüssel entschlüsselbar ist.
4. 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.
5. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass das Softwarepaket von der übergeordneten Authentisierungs- stelle 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.
6. 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 Authentisie- rungsstelle durchgeführt wird.
7. 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.
8. 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.
PCT/EP2004/006776 2003-07-04 2004-06-22 Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten WO2005003936A1 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP04740198A EP1642185A1 (de) 2003-07-04 2004-06-22 Verfahren zur authentifikation von einer insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponente
JP2006518025A JP2007527044A (ja) 2003-07-04 2004-06-22 特に自動車の制御装置内にロード可能なソフトウェアコンポーネントを認証するための方法
US11/324,219 US7748043B2 (en) 2003-07-04 2006-01-04 Method for authenticating, in particular, software components that can be loaded into a control unit of a motor vehicle

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
DE10330439 2003-07-04
DE10330439.8 2003-07-04
DE10354107.1 2003-11-19
DE10354107A DE10354107A1 (de) 2003-07-04 2003-11-19 Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/324,219 Continuation US7748043B2 (en) 2003-07-04 2006-01-04 Method for authenticating, in particular, software components that can be loaded into a control unit of a motor vehicle

Publications (1)

Publication Number Publication Date
WO2005003936A1 true WO2005003936A1 (de) 2005-01-13

Family

ID=33566021

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/006776 WO2005003936A1 (de) 2003-07-04 2004-06-22 Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten

Country Status (5)

Country Link
US (1) US7748043B2 (de)
EP (1) EP1642185A1 (de)
JP (1) JP2007527044A (de)
KR (1) KR100974419B1 (de)
WO (1) WO2005003936A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018003281A1 (de) * 2018-04-23 2019-10-24 Daimler Ag Fahrzeugbetriebssystem

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8205217B2 (en) 2007-09-29 2012-06-19 Symantec Corporation Methods and systems for configuring a specific-use computing system limited to executing predetermined and pre-approved application programs
US8769373B2 (en) 2010-03-22 2014-07-01 Cleon L. Rogers, JR. Method of identifying and protecting the integrity of a set of source data
US10017067B2 (en) * 2012-08-09 2018-07-10 Technische Universitat Dortmund Method for ensuring functional reliability in electromobility by means of digital certificates
JP6197000B2 (ja) * 2015-07-03 2017-09-13 Kddi株式会社 システム、車両及びソフトウェア配布処理方法
DE102016202527A1 (de) 2016-02-18 2017-08-24 Robert Bosch Gmbh Recheneinheit für ein Kraftfahrzeug
JP6440334B2 (ja) * 2017-08-18 2018-12-19 Kddi株式会社 システム、車両及びソフトウェア配布処理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020023223A1 (en) * 2000-02-25 2002-02-21 Ernst Schmidt Authorization process using a certificate
US20020120856A1 (en) * 2000-02-25 2002-08-29 Ernst Schmidt Signature process
DE10140721A1 (de) * 2001-08-27 2003-03-20 Bayerische Motoren Werke Ag Verfahren zur Bereitstellung von Software zur Verwendung durch ein Steuergerät eines Fahrzeugs
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4685055A (en) * 1985-07-01 1987-08-04 Thomas Richard B Method and system for controlling use of protected software
US4868877A (en) * 1988-02-12 1989-09-19 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
EP0946019A1 (de) 1998-03-25 1999-09-29 CANAL+ Société Anonyme Authentifizierung von Daten in einem digitalen Übertragungssystem
JP3971890B2 (ja) * 2000-11-01 2007-09-05 日本電信電話株式会社 署名検証支援装置、署名検証支援方法、及び電子署名検証方法
SE0100474D0 (sv) 2001-02-14 2001-02-14 Ericsson Telefon Ab L M A security architecture
DE10131394A1 (de) 2001-06-28 2003-02-06 Daimler Chrysler Ag Verfahren zum Übertragen von Software-Modulen

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020023223A1 (en) * 2000-02-25 2002-02-21 Ernst Schmidt Authorization process using a certificate
US20020120856A1 (en) * 2000-02-25 2002-08-29 Ernst Schmidt Signature process
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels
DE10140721A1 (de) * 2001-08-27 2003-03-20 Bayerische Motoren Werke Ag Verfahren zur Bereitstellung von Software zur Verwendung durch ein Steuergerät eines Fahrzeugs

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ADAMS C ET AL: "Internet X.509 Public Key Infrastructure - Data Validation and Certification Server Protocols", REQUEST FOR COMMENTS, February 2001 (2001-02-01), XP002235347 *
MENEZES ET AL: "HANDBOOK OF APPLIED CRYPTOGRAPHY", HANDBOOK OF APPLIED CRYPTOGRAPHY, CRC PRESS SERIES ON DISCRETE MATHEMATICES AND ITS APPLICATIONS, BOCA RATON, FL, CRC PRESS, US, 1997, pages 559 - 561, XP002148724, ISBN: 0-8493-8523-7 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018003281A1 (de) * 2018-04-23 2019-10-24 Daimler Ag Fahrzeugbetriebssystem
DE102018003281B4 (de) * 2018-04-23 2019-12-05 Daimler Ag Fahrzeugbetriebssystem
US11926269B2 (en) 2018-04-23 2024-03-12 Mercedes-Benz Group AG Vehicle operating system

Also Published As

Publication number Publication date
JP2007527044A (ja) 2007-09-20
US20060143474A1 (en) 2006-06-29
KR100974419B1 (ko) 2010-08-05
EP1642185A1 (de) 2006-04-05
KR20060034273A (ko) 2006-04-21
US7748043B2 (en) 2010-06-29

Similar Documents

Publication Publication Date Title
EP2689553B1 (de) Kraftwagen-steuergerät mit kryptographischer einrichtung
DE102012110499B4 (de) Sicherheitszugangsverfahren für elektronische Automobil-Steuergeräte
DE10008973B4 (de) Autorisierungsverfahren mit Zertifikat
EP1959606B1 (de) Sicherheitseinheit
DE102007022100B4 (de) Kraftfahrzeugsteuergerätedatenübertragungssystem und -verfahren
EP1999725A1 (de) Verfahren zum schutz eines beweglichen gutes, insbesondere eines fahrzeugs, gegen unberechtigte nutzung
WO2019034509A1 (de) Verfahren zum sicheren ersetzen eines bereits in ein gerät eingebrachten ersten herstellerzertifikats
WO2019175006A1 (de) Verfahren zum datenaustausch mit einem fahrzeugsteuergerät
WO2005116834A1 (de) Authentisierung von steuerge­räten in einem fahrzeug
EP1185026A2 (de) Verfahren zur Datenübertragung
WO2005003936A1 (de) Verfahren zur authentifikation von insbesondere in ein steuergerät eines kraftfahrzeugs ladbaren softwarekomponenten
DE102010021257A1 (de) Steckverbindungssystem zum geschützten Aubau einer Netzwerkverbindung
DE102011002713A1 (de) Verfahren und Vorrichtung zum Bereitstellen von kyptographischen Credentials für Steuergeräte eines Fahrzeugs
DE102007051440A1 (de) Verfahren und Vorrichtung zur Freischaltung von Software in einem Kraftfahrzeug
DE10354107A1 (de) Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
EP3078769A1 (de) Verfahren zur freigabe von maschinenfunktionen an einer spinnereimaschine
WO2005025128A1 (de) Verfahren zum signieren einer datenmenge in einem public-key-system sowie ein datenverarbeitungssystem zur durchführung des verfahrens
EP1455312B1 (de) Verfahren und Einrichtung zur Wartung von sicherheitsrelevanten Programmcode eines Kraftfahrzeuges
DE102009053230A1 (de) Verfahren zur Autorisierung eines externen Systems auf einem Steuergerät eines Fahrzeugs, insbesondere eines Kraftfahrzeugs
DE102018132979A1 (de) Abgesichertes und intelligentes Betreiben einer Ladeinfrastruktur
DE102004021145A1 (de) Verfahren und System zum drahtlosen Übertragen von Daten zwischen einer Datenverarbeitungseinrichtung eines Fahrzeugs und einer lokalen externen Datenverarbeitungseinrichtung
EP3693233B1 (de) Sicherheitsmodus bei ersetzten ecus
DE102018209757B3 (de) Schutz einer Fahrzeugkomponente
DE102004064292B3 (de) Verfahren und System zum drahtlosen Übertragen von Daten zwischen einer Datenverarbeitungseinrichtung eines Fahrzeugs und einer lokalen externen Datenverarbeitungseinrichtung
DE102015222099A1 (de) Verfahren und Steuergerät zum koordinierten Aktualisieren eines einfachen Moduls mit differentiellen Aktualisierungsdaten

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200480019079.7

Country of ref document: CN

AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004740198

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2006518025

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 11324219

Country of ref document: US

Ref document number: 1020067000204

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2004740198

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11324219

Country of ref document: US