WO2023083500A1 - Verfahren, fahrzeugkomponente und computerprogramm zum einräumen einer berechtigung zum ausführen eines computerprogramms durch eine fahrzeugkomponente eines fahrzeugs - Google Patents

Verfahren, fahrzeugkomponente und computerprogramm zum einräumen einer berechtigung zum ausführen eines computerprogramms durch eine fahrzeugkomponente eines fahrzeugs Download PDF

Info

Publication number
WO2023083500A1
WO2023083500A1 PCT/EP2022/064614 EP2022064614W WO2023083500A1 WO 2023083500 A1 WO2023083500 A1 WO 2023083500A1 EP 2022064614 W EP2022064614 W EP 2022064614W WO 2023083500 A1 WO2023083500 A1 WO 2023083500A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
computer program
vehicle component
identification information
key
Prior art date
Application number
PCT/EP2022/064614
Other languages
English (en)
French (fr)
Inventor
Sebastian HILD
Elmar SCHOCH
Richard Wimmer
Maximilian Raith
Michael Gruffke
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
Application filed by Bayerische Motoren Werke Aktiengesellschaft filed Critical Bayerische Motoren Werke Aktiengesellschaft
Priority to CN202280068930.3A priority Critical patent/CN118103841A/zh
Publication of WO2023083500A1 publication Critical patent/WO2023083500A1/de

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/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • 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/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/73—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information by creating or determining hardware identification, e.g. serial numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/84—Vehicles

Definitions

  • Embodiments of the present invention relate to a method, to a vehicle component and to a computer program for granting authorization for executing a computer program by a vehicle component of a vehicle, and to a vehicle with a corresponding vehicle component.
  • Modern vehicles have a large number of different vehicle components, with computer programs being executable on some vehicle components.
  • vehicles have an infotainment and navigation system whose functionality is provided by software.
  • vehicle components such as an e-call system (electronic call system) are also implemented at least by a processor on which a computer program is executed.
  • e-call system electronic call system
  • the manufacturer of the vehicle has an interest in computer programs running on the vehicle being tested and approved by the manufacturer. Therefore, the vehicle manufacturer can endeavor to ensure the integrity and authenticity of the software on the vehicle's components. This is done using cryptographic measures. Examples of this are given in the documents DE 101 40 721 A1 and DE 103 54 107 A1.
  • Various aspects of the present invention are based on the knowledge that the development and test sequence for computer programs for a vehicle component can be improved in that, in addition to the cryptographic measures provided for series operation of the vehicle component, identification information and an additional test key are introduced into the vehicle component can become.
  • the additional test key is used to secure the execution of the computer program to be tested.
  • This additional test key is also linked cryptographically to the identification information, so that this test key can only be used in precisely this vehicle component.
  • the computer program to be executed is now cryptographically signed by the developer. This signature is now checked and declared valid if, on the one hand, it can be checked using the additional verification key and, on the other hand, it is based on the identification information. In this way, the developers of the supplier or the third party can be given the opportunity to test software on series components as independently as possible, without the safety of the series components as installed in other vehicles being impaired. After completion of the development process, the additional test key is removed again.
  • Example embodiments provide a method for granting authorization for a vehicle component of a vehicle to execute a computer program.
  • the method includes storing identification information on the vehicle component as part of a manufacturing process. The identification information is specific to the vehicle component.
  • the method also includes storing an additional test key in the vehicle component during a development process, which is linked to the identification information by a cryptographic signature.
  • the method further includes receiving the computer program for the vehicle component.
  • the computer program is cryptographically signed.
  • the method also includes running the computer program if the cryptographic signature of the computer program is valid after the test item with the test key introduced and is based on the identification information.
  • the method further includes removing the additional verification key after the development process is completed.
  • the verification key is used to avoid unduly taxing the vehicle manufacturer's cryptographic infrastructure during the development process.
  • the additional test key can be provided to enable the execution of computer programs in addition to a public key infrastructure (public key infrastructure) of a manufacturer of the vehicle.
  • the identification information is tied to the specific vehicle component. This property can now be used to limit the usability of the signed computer program to one vehicle component or a few vehicle components.
  • the cryptographic signature of the computer program can be specific to a single vehicle component or vehicle.
  • the computer program's cryptographic signature can be specific to a defined set of vehicle components or vehicles.
  • the respective identification information of one or more vehicle components is included in the signature of the computer program.
  • the computer program can be signed together with one or more items of identification information for one or more vehicle components or vehicles.
  • the aim of the method presented is to facilitate the development work of suppliers and third-party software manufacturers. At the same time, it should be noted that this functionality cannot be extended to any number of vehicle components.
  • the additional test key can therefore be signed by the vehicle manufacturer and thus linked to the identification information.
  • the cryptographic signature with which the additional test key is linked to the identification information can be generated by the manufacturer of the vehicle.
  • the cryptographic signature of the computer program can in turn be generated based on the identification information of the vehicle component or the vehicle by a manufacturer of the vehicle component or by a third party, i.e. expressly not by the vehicle manufacturer, so that the cryptographic infrastructure of the vehicle manufacturer does not have to be used if a new test version is transmitted to the vehicle component.
  • the additional aspects are integrated into the safety concept of the vehicle component. In this way, the cryptographic signature of the computer program, the additional test key and the identification information can be checked by a boot loader of the vehicle component. This can prevent the additional test key from also being used on other vehicle components.
  • Embodiments also create a program with a program code for performing the method described above when the program code is executed on a computer, a processor, a control module or a programmable hardware component.
  • Embodiments also create a vehicle component, comprising one or more processors and one or more memory devices, wherein the vehicle component is configured to perform the method described above.
  • Embodiments also create a vehicle comprising one or more of the vehicle components.
  • FIG. 1 shows a flow chart of an example of a method for granting an authorization for executing a computer program by a vehicle component of a vehicle
  • FIG. 2a shows a block diagram of an example of a vehicle component
  • FIG. 2b shows a schematic diagram of an example of a vehicle with one or more vehicle components.
  • Various exemplary embodiments of the present disclosure relate to cryptographic protection in order to be able to activate additional software on selected components in addition to the standard software.
  • software is developed which is to be tested on series hardware. This includes, for example, a computer program for accessing online music libraries, a computer program for linking vehicles and mobile devices, or a computer program for locating and querying charging stations.
  • this software should not be able to be used in an uncontrolled manner on customer vehicles.
  • the permitted software on customer vehicles should be kept to a minimum.
  • identical hardware should be used for development so that there is no deviation from the series.
  • the method also includes storing 110, as part of a manufacturing process, identification information on the vehicle component.
  • the identification information is specific to the vehicle component.
  • the method also includes storing 120 an additional test key in the vehicle component during a development process.
  • the additional verification key is linked to the identification information by a cryptographic signature.
  • the method further includes obtaining 130 the computer program for the vehicle component.
  • the computer program is cryptographically signed.
  • the method also includes executing 150 the computer program if the cryptographic signature of the computer program is valid after checking 140 with the check key that was introduced and is based on the identification information.
  • the method is executed, for example, by the vehicle component, for example by one or more processors Vehicle component, in connection with one or more memory devices and one or more interfaces of the vehicle component.
  • the present disclosure relates to a method, a vehicle component, and a computer program for granting authorization to run a computer program through a vehicle component of a vehicle.
  • the protection of the execution of computer programs (ie software) on vehicle components is based on a cryptographic infrastructure of the vehicle manufacturer, for example on a public key infrastructure (PKI, public key infrastructure) of the vehicle manufacturer.
  • Software that is to be executed on the vehicle components is signed by the vehicle manufacturer. This signature is then checked by the vehicle component, for example by a so-called bootloader (a system for initializing the software of the vehicle component when starting) of the vehicle component, and the software is enabled to run if the check is enabled.
  • a public key infrastructure a combination of a so-called private key and a so-called public key from the vehicle manufacturer is used. These two keys form what is known as a key pair, with the public key being derived from the private key.
  • the private key is a well-kept secret of the vehicle manufacturer, while the public key can be passed on.
  • the private key can now be used by the vehicle manufacturer to cryptographically sign the computer program.
  • the public key is stored on the vehicle component and can be used to check the signature of the computer program generated by the private key.
  • a so-called hash value (scrambling value) of the computer program is usually formed and the signature is created based on the hash value. If the hash value of the computer program corresponds to the hash value stored in the signature and the signature "matches" the vehicle manufacturer's public key, the computer program check is successful. This procedure is used in the series versions of the vehicle components in order to strictly secure the execution of the software.
  • the manufacturer of the vehicle component or a third-party manufacturer develops a computer program for the vehicle component, they would have to have the computer program signed by the vehicle manufacturer for each test version, which creates a great deal of effort for the vehicle manufacturer and can cause delays. This is where the present invention comes in.
  • another test key is now introduced into the vehicle component, which is based on identification information for the vehicle component and is therefore specific to the vehicle component.
  • the use of the software from development is released for selected components. This can be done using the existing public key infrastructure.
  • the vehicle component is activated with the help of two components: the identification information and the additional test key.
  • the method therefore includes storing 110, as part of a manufacturing process, identification information on the vehicle component and storing 120 the additional test key in the vehicle component during a development process. It becomes clear that this can happen at different times.
  • the identification information is already introduced during the manufacturing process, i.e. during the original production.
  • the identification information is unique, i.e. unique in both directions, so that a vehicle component (or a vehicle) is assigned exactly one piece of identification information and the identification information is assigned to exactly one vehicle component (or vehicle). In other words, a piece of identification information is assigned to precisely one vehicle component (or one vehicle).
  • the identification information can be, for example, a binary code or an alphanumeric code or expressed as such.
  • the identification information can be unchangeable.
  • the identification information can be incorporated in a read-only memory of the vehicle component, which cannot be changed after the end of the manufacturing process.
  • the additional test key is now introduced into the vehicle component based on the identification information.
  • the additional test key is generated based on the identification information, for example. This links the release of the vehicle component to the identification information via the signature/certificate.
  • a developer can read out the identification information of the vehicle component and transmit it to the vehicle manufacturer, who in turn can generate the additional test key based on the identification information together with the cryptographic signature.
  • the additional test key can be generated by the developer (or the supplier/third-party manufacturer) and then linked to the identification information via the cryptographic signature.
  • the cryptographic signature, with which the additional test key is linked to the identification information is generated by the manufacturer of the vehicle.
  • the cryptographic signature can also be generated using the vehicle manufacturer's private key.
  • the cryptographic signature can also be checked using the vehicle manufacturer's public key.
  • the additional test key is intended to enable the execution of computer programs in addition to a public key infrastructure of a manufacturer of the vehicle.
  • the additional test key is therefore introduced, for example, in addition to the vehicle manufacturer's public key.
  • the additional verification key is introduced in addition to another verification key, such as the vehicle manufacturer's public key, which is used to restrict the execution of computer programs in the production operation of the vehicle component.
  • the computer program is now obtained by the vehicle component, for example by uploading the computer program via a diagnostic interface of the vehicle component, or by retrieving the computer program from a platform for retrieving computer programs.
  • the computer program is cryptographically signed.
  • This signature is not generated by the vehicle manufacturer, for example, but is instead generated by the developer himself or by a supplier/third-party manufacturer's cryptographic infrastructure. This can happen, for example, if the additional test key comes from the developer, supplier or third-party manufacturer, and only the signature with which the test key is linked to the identification information comes from the vehicle manufacturer itself.
  • the developer can thus be allowed to use the signature for the To generate software independently by including the public key, i.e. the additional verification key, for this signature in the release.
  • the developer, supplier or third-party manufacturer can now generate the signature using the associated private key.
  • the cryptographic signature of the computer program can thus be generated by a manufacturer of the vehicle component or by a third party based on the identification information for the vehicle component or the vehicle. Alternatively, a signature can be omitted entirely, or the signature of the developer software must continue to be signed via the infrastructure for the series software.
  • the cryptographic signature of the computer program can be specific to a single vehicle component or a single vehicle, or the cryptographic signature of the computer program can be specific to a defined set of vehicle components or vehicles. This can be done in that the signature is based not only on a hash value of the computer program but also on one or more items of identification information, ie the signature is generated for a package made up of computer program and one or more items of identification information. In this way, multiple pieces of identification information can also appear be released once.
  • the computer program can be signed, for example, together with one or more items of identification information for one or more vehicle components or vehicles. This can be done by cryptographically signing a manifest with the hash value of the computer program and the one or more pieces of identification information. This then corresponds to the cryptographic signature of the computer program.
  • the method includes checking 140 the cryptographic signature with the introduced verification key, the checking comprising checking whether the cryptographic signature is based on the identification information.
  • three aspects are checked - a) whether the additional verification key introduced is linked to the identification information via a cryptographic signature, b) whether the cryptographic signature of the computer program is recognized as valid by the additional verification key, and c) whether the cryptographic signature of the computer program based on the identification information.
  • a security chain chain of trust
  • A) and c) prevent the computer program from being executable on any vehicle component on any vehicle component with an additional test key.
  • the hash value of the computer program (which is calculated locally) can be compared with the hash value stored in the manifest, and the identification information introduced can be compared with the one or more pieces of identification information that is or are included in the manifest.
  • the cryptographic signature of the computer program (test aspects b) and c)), the additional test key (test aspect a)) and the identification information (test aspect a)) can be checked 140 by a boot loader of the vehicle component.
  • the computer program is executed 150. This can be done within an execution environment provided by the vehicle component, for example alongside other computer programs. Alternatively, the computer program can be loaded as an image and run (alone).
  • the proposed method enables controlled release of the software from development for the vehicles/components with the selected identification information. Other processes can be used to ensure that these vehicles/IDs are not released for sale.
  • the additional test key is also removed.
  • the method may further include removing 160 the additional verification key after the development process is complete. This can be the case, for example, when the development process can actually be considered complete, for example, in the case of safety-critical software that is approved at a specific point in time. However, in many cases, such as in cases where third-party manufacturers are developing software for a vehicle's infotainment system, development is ongoing. The additional test key can remain on the vehicle component during the ongoing development process.
  • the development software i.e. the computer program
  • a manufacturer's PKI has signed a package consisting of unique identification information for the component and key for the developer's signature (i.e. the additional verification key).
  • the bootloader recognizes that the additional package of identification information and developer key is present and checks this signature.
  • the signature check was successful, the software is checked with the key for the developer signature. (3) If the test is successful, the control unit starts the development software.
  • FIG. 2a shows a block diagram of an example of a vehicle component 20.
  • vehicle component 20 can now be used, for example, to carry out the method presented in FIG.
  • the vehicle component includes one or more processors 24 and one or more storage devices 26.
  • the vehicle component further includes one or more interfaces 22.
  • the one or more processors 24 are coupled to the one or more storage devices 26 and the one or more interfaces 22.
  • the functionality of the vehicle component is provided, at least with respect to the above method, by the one or more processors 24 with the aid of the one or more storage devices 26 (for storing information such as the identification information, the additional verification key, the vehicle manufacturer's public key and the computer program) and the one or more interfaces (for exchanging information).
  • the vehicle component can be a computer-based vehicle component, for example, such as a computer-based control unit or a central computer unit (such as an infotainment system) of the vehicle.
  • the one or more interfaces 22 may correspond, for example, to one or more inputs and/or one or more outputs for receiving and/or transmitting information, such as in digital bit values, based on a code, within a module, between modules, or between modules of different ones entities.
  • the one or more processors 24 may correspond to any controller or processor or programmable hardware component.
  • the functionality of the one or more processors 24 can also be implemented as software that is programmed for a corresponding hardware component.
  • the one or more processors 24 can be implemented as programmable hardware with correspondingly adapted software. Any processors, such as digital signal processors (DSPs) can be used. Exemplary embodiments are not limited to a specific type of processor. Any processors or even multiple processors are conceivable for the implementation.
  • the one or more processors for example in interaction with a firmware/UEFI (Unified Extensible Firmware Interface, unified and extensible firmware interface), can be designed to provide a secure boot operation (secure initialization operation) in order to to load the computer program.
  • firmware/UEFI Unified Extensible Firmware Interface, unified and extensible firmware interface
  • the one or more storage devices 26 can be, for example, at least one element from the group of computer-readable storage medium, magnetic storage medium, optical storage medium, hard drive, flash memory, floppy disk, random access memory (also engl. Random Access Memory), programmable read only memory (PROM), erasable include programmable read only memory (EPROM), electronically erasable programmable read only memory (EEPROM), and network storage.
  • Vehicle components are discussed in the present disclosure. These are (computer-based) components that are used in vehicles. Correspondingly, exemplary embodiments also create a vehicle 200 comprising one or more vehicle components 20.
  • FIG. 2b shows a schematic diagram of an example of such a vehicle 200 with one or more vehicle components 20 as described in connection with FIGS. 1 to 2a were presented.
  • the vehicle 200 may correspond, for example, to a land vehicle, a watercraft, an aircraft, a rail vehicle, a road vehicle, a car, an all-terrain vehicle, an automobile, or a truck.
  • Examples may further include or relate to a (computer) program having program code for performing one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component.
  • steps, operations, or processes of various methods described above may also be performed by programmed computers, processors, or other programmable hardware components.
  • Examples may also cover program storage devices, such as digital data storage media, that are machine, processor, or computer readable and that encode or contain machine-executable, processor-executable, or computer-executable programs and instructions.
  • the program storage devices may include or be, for example, digital memory, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media.
  • FIG. 1 System-on-a-chip
  • a block, a device or a functional aspect of the device or the system can correspond to a feature, such as a method step, of the corresponding method.
  • aspects that are described in connection with a method are also considered a description of one corresponding block, element, property, or functional feature of a corresponding device or system.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren, auf eine Fahrzeugkomponente und auf ein Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs, und auf ein Fahrzeug mit einer entsprechenden Fahrzeugkomponente. Das Verfahren umfasst ein Hinterlegen, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente. Die Identifikationsinformation ist spezifisch für die Fahrzeugkomponente. Das Verfahren umfasst ferner ein Hinterlegen eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses, der an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt ist. Das Verfahren umfasst ferner ein Erhalten des Computerprogramms für die Fahrzeugkomponente. Das Computerprogramm ist kryptographisch signiert. Das Verfahren umfasst ferner ein Ausführen des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfung mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert.

Description

Verfahren, Fahrzeugkomponente und Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs
Beschreibung
Ausführungsbeispiele der vorliegenden Erfindung beziehen sich auf ein Verfahren, auf eine Fahrzeugkomponente und auf ein Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs, und auf ein Fahrzeug mit einer entsprechenden Fahrzeugkomponente.
Moderne Fahrzeuge verfügen über eine Vielzahl von verschiedenen Fahrzeugkomponenten, wobei auf manchen Fahrzeugkomponenten Computerprogramme ausführbar sind. Beispielsweise verfügen Fahrzeuge über ein Infotainment- und Navigationssystem, dessen Funktionalität durch Software bereitgestellt wird. Doch auch andere Fahrzeugkomponenten, wie etwa ein E-Call-System (Elektronisches Anrufsystem) wird zumindest durch einen Prozessor implementiert, auf dem ein Computerprogram ausgeführt wird. Im Sinne der Fahrsicherheit hat der Hersteller des Fahrzeugs jedoch ein Interesse daran, dass Computerprogramme, die auf dem Fahrzeug ausgeführt werden, getestet und durch den Hersteller freigegeben sind. Daher kann der Fahrzeughersteller sich darum bemühen, auf den Komponenten des Fahrzeugs die Integrität und Authentizität der Software sicherzustellen. Dies erfolgt durch kryptographische Maßnahmen. Beispiele hierfür sind in den Schriften DE 101 40 721 Al und DE 103 54 107 Al gegeben.
Im Entwicklungsprozess eines Fahrzeugs werden viele der Fahrzeugkomponenten von Zulieferern bereitgestellt. Diese stellen im Allgemeinen auch die dazugehörige Software bereit, nach Spezifikation der Fahrzeugherstellen. Zudem wird nach und nach auch Software von Dritthersteilem bereitgestellt, etwa Software zum Zugriff auf Online -Musikbibliotheken, Software zum Verknüpfen von Fahrzeugen und Mobilgeräten, oder Software zum Lokalisieren und Abfragen von Ladesäulen. Diese Zulieferer oder Dritthersteller benötigen Möglichkeiten, um die von Ihnen entwickelte Software auf den jeweiligen Fahrzeugkomponenten, oder direkt im Fahrzeug, zu testen, möglichst auf der Serienfassung der jeweiligen Fahrzeugkomponente. Um zu verhindern, dass Fahrzeugkomponenten ohne kryptographische Absicherung auf dem grauen Markt gehandelt werden, wird diese Software, genau wie die in den Serienfahrzeugen eingesetzte Software, durch den Fahrzeughersteller signiert und kann dann im Fahrzeug oder auf der Fahrzeugkomponente getestet werden. Dies erhöhte den Aufwand und die Anforderungen an das kryptographiebasierte Sicherheitssystem des Fahrzeugherstellers und stellt ein Nadelöhr und eine Fehlerquelle im Entwicklungsprozess dar.
Es besteht daher ein Bedarf daran, ein verbessertes Konzept zum Entwickeln und Testen von Computerprogrammen für Fahrzeugkomponenten eines Fahrzeugs bereitzustellen.
Diesem Bedarf tragen das Verfahren, die Fahrzeugkomponente sowie das Computerprogramm nach den unabhängigen Ansprüchen Rechnung.
Verschiedene Aspekte der vorliegenden Erfindung basieren auf der Erkenntnis, dass der Entwicklungs- und Testablauf für Computerprogramme für eine Fahrzeugkomponente dadurch verbessert werden kann, dass, zusätzlich zu den für den Serienbetrieb der Fahrzeugkomponente vorgesehenen kryptographischen Maßnahmen, eine Identifikationsinformation und ein zusätzlicher Prüfschlüssel in die Fahrzeugkomponente eingebracht werden können. Dabei wird der zusätzliche Prüfschlüssel genutzt, um die Ausführung des zu testenden Computerprogramms abzusichem. Dieser zusätzliche Prüfschlüssel ist zudem kryptographisch an die Identifikationsinformation geknüpft, so dass dieser Prüfschlüssel nur in genau dieser Fahrzeugkomponente verwendet werden kann. Das auszuführende Computerprogramm wird nun von dem Entwickler kryptographisch signiert. Diese Signatur wird nun geprüft und für gültig erklärt, falls sie einerseits mittels des zusätzlichen Prüfschlüssel geprüft werden kann und andererseits auf der Identifikationsinformation basiert. Somit kann den Entwicklern des Zulieferers oder des Dritthersteilem die Möglichkeit eingeräumt werden, möglichst eigenständig Software auf Serienkomponenten zu testen, ohne dass hierbei die Sicherheit der Serienkomponente, wie sie in anderen Fahrzeugen verbaut ist, beeinträchtigt wird. Nach Beendigung des Entwicklungsprozesses wird der zusätzliche Prüfschlüssel wieder entfernt.
Ausführungsbeispiele schaffen ein Verfahren zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs. Das Verfahren umfasst ein Hinterlegen, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente. Die Identifikationsinformation ist spezifisch für die Fahrzeugkomponente. Das Verfahren umfasst ferner ein Hinterlegen eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses, der an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt ist. Das Verfahren umfasst ferner ein Erhalten des Computerprogramms für die Fahrzeugkomponente. Das Computerprogramm ist kryptographisch signiert. Das Verfahren umfasst ferner ein Ausführen des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfling mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert. Optional umfasst das Verfahren ferner ein Entfernen des zusätzlichen Prüfschlüssels, nachdem der Entwicklungsprozess abgeschlossen ist. Durch das vorgeschlagene Verfahren kann den Entwicklern des Zulieferers oder des Dritthersteilem die Möglichkeit eingeräumt werden, möglichst eigenständig Software auf Serienkomponenten zu testen, ohne dass hierbei die Sicherheit der Serienkomponente, wie sie in anderen Fahrzeugen verbaut ist, beeinträchtigt wird.
Wie zuvor ausgefiihrt wird der Prüfschlüssel verwendet, um während des Entwicklungsprozesses die kryptographische Infrastruktur des Fahrzeugherstellers nicht über Gebühr zu beanspruchen. Beispielsweise kann der zusätzliche Prüfschlüssel dazu vorgesehen sein, die Ausführung von Computerprogrammen zusätzlich zu einer Public-Key-Infrastmktur (Öffentlicher Schlüssel- Infrastruktur) eines Herstellers des Fahrzeugs zu ermöglichen.
Die Identifikationsinformation ist an die spezifische Fahrzeugkomponente gebunden. Diese Eigenschaft kann nun genutzt werden, um die Verwendbarkeit des signierten Computerprogramms auf eine Fahrzeugkomponente oder wenige Fahrzeugkomponenten einzuschränken. So kann die kryptographische Signatur des Computerprogramms spezifisch für eine einzige Fahrzeugkomponente oder ein einziges Fahrzeug sein. Alternativ kann die kryptographische Signatur des Computerprogramms spezifisch für eine definierte Menge an Fahrzeugkomponenten oder Fahrzeugen sein.
Dies kann dadurch geschehen, dass die jeweilige Identifikationsinformation einer oder mehrerer Fahrzeugkomponenten Eingang in die Signatur das Computerprogramms findet. Beispielsweise kann das Computerprogramm zusammen mit ein oder mehreren Identifikationsinformationen ein oder mehrerer Fahrzeugkomponenten oder Fahrzeuge signiert sein.
Das vorgestellte Verfahren hat das Ziel, die Entwicklungsarbeit der Zulieferer und Dritthersteller von Software zu erleichtern. Gleichzeitig ist zu beachten, dass diese Funktionalität nicht auf eine beliebige Anzahl Fahrzeugkomponenten erweiterbar ist. Daher kann der zusätzliche Prüfschlüssel seinerseits von dem Fahrzeughersteller signiert und damit an die Identifikationsinformation gebunden werden. In anderen Worten kann die kryptographische Signatur, mit der der zusätzliche Prüfschlüssel an die Identifikationsinformation gekoppelt ist von dem Hersteller des Fahrzeugs generiert sein.
Die kryptographische Signatur des Computerprogramms wiederum kann basierend auf der Identifikationsinformation der Fahrzeugkomponente oder des Fahrzeugs durch einen Hersteller der Fahrzeugkomponente oder durch einen Dritten generiert sein, also ausdrücklich nicht durch den Fahrzeughersteller, so dass die Kryptographieinfrastruktur des Fahrzeugherstellers nicht in Anspruch genommen werden muss, wenn eine neue Testfassung in die Fahrzeugkomponente übermittelt wird. Die zusätzlichen Aspekte werden in das Sicherheitskonzept der Fahrzeugkomponente integriert. So kann kryptographische Signatur des Computerprogramms, der zusätzliche Prüfschlüssel und die Identifikationsinformation durch einen Bootloader der Fahrzeugkomponente geprüft werden. Somit kann verhindert werden, dass etwa der zusätzliche Prüfschlüssel auch auf anderen Fahrzeugkomponenten zum Einsatz kommt.
Ausführungsbeispiele schaffem ferner ein Programm mit einem Programmcode zum Durchführen des zuvor beschriebenen Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Ausführungsbeispiele schaffem ferner eine Fahrzeugkomponente, umfassend ein oder mehrere Prozessoren und ein oder mehrere Speichergeräte, wobei die Fahrzeugkomponente ausgebildet ist zum Ausführen des zuvor beschriebenen Verfahrens.
Ausführungsbeispiele schaffen ferner ein Fahrzeug, umfassend ein oder mehrere der F ahrzeugkomponenten .
Ausführungsbeispiele werden nachfolgend bezugnehmend auf die beiliegenden Figuren näher erläutert. Es zeigen:
Fig. 1 zeigt ein Flussdiagramm eines Beispiels eines Verfahrens zum Einräumen einer Berechtigung zum Ausfuhren eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs;
Fig. 2a zeigt ein Blockdiagramm eines Beispiels einer Fahrzeugkomponente; und
Fig. 2b zeigt ein schematisches Diagramm eines Beispiels eines Fahrzeugs mit ein oder mehreren F ahrzeugkomponenten .
Verschiedene Ausführungsbeispiele werden nun ausführlicher unter Bezugnahme auf die beiliegenden Zeichnungen beschrieben, in denen einige Ausführungsbeispiele dargestellt sind. In den Figuren können die Dickenabmessungen von Linien, Schichten und/oder Regionen um der Deutlichkeit Willen übertrieben dargestellt sein.
Verschiedene Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf eine kryptographische Absicherung, um neben der Serien-Software auf ausgewählten Komponenten zusätzliche Software freischalten zu können. Wie bereits zuvor ausgeführt wird im Rahmen der Entwicklung und Absicherung von Fahrzeugkomponenten oder der Entwicklung von Software durch Dritthersteller Software entwickelt, welche auf Serienhardware getestet werden soll. Dazu gehören beispielsweise ein Computerprogramm zum Zugriff auf Online -Musikbibliotheken, ein Computerprogramm zum Verknüpfen von Fahrzeugen und Mobilgeräten, oder ein Computerprogramm zum Lokalisieren und Abfragen von Ladesäulen. Diese Software soll aber gleichzeitig nicht unkontrolliert auf Kundenfahrzeugen verwendbar sein. Die erlaubte Software auf den Kundenfahrzeugen soll auf das Minimum beschränkt sein. Für die Entwicklung soll jedoch identische Hardware verwendet werden, um keine Abweichung von der Serie zu haben. Für diese Komponenten in der Entwicklung sollen die Restriktionen möglichst weit reduziert werden, sodass eine ungestörte Entwicklung und Absicherung möglich ist. Im Allgemeinen wird bei einer solche Absicherung direkt, oder über eine Chain-of-trust (Sicherheitskette) einer Public -Key-Infrastruktur vertraut. So wird für die Software-Integrität und - Authentizität auf Fahrzeugkomponenten werden Zertifikate und Signaturen verwendet. Die Korrektheit wird beispielsweise beim Installieren bzw. Starten der Software überprüft.
Einerseits könnte für die Entwicklung Spezialhardware verwendet werden, die gegenüber der serienmäßig genutzten Hardware ein unterschiedliches Sicherheitskonzept einsetzt. Jedoch ist die Produktion von Spezialhardware für die Entwicklung mit ausgeschaltetem Sicherheitsmechanismus zur Verifikation der Software aufwendig und birgt die Gefahr, dass diese Hardware auch für ungewollte Abnehmer produziert wird. Für die Entwicklung von Applikationen auf Mobilfunkgeräten werden beispielsweise Entwicklerprogramme genutzt, über die man sich freischalten lassen kann, um auf dedizierten Geräten eigene Software zu installieren.
Fig. 1 zeigt ein Flussdiagramm eines Beispiels eines (computerimplementierten) Verfahrens zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs. Das Verfahren umfasst ferner ein Hinterlegen 110, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente. Die Identifikationsinformation ist spezifisch für die Fahrzeugkomponente. Das Verfahren umfasst ferner ein Hinterlegen 120 eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses. Der zusätzliche Prüfschlüssel ist an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt. Das Verfahren umfasst ferner ein Erhalten 130 des Computerprogramms für die Fahrzeugkomponente. Das Computerprogramm ist kryptographisch signiert. Das Verfahren umfasst ferner ein Ausführen 150 des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfung 140 mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert. Das Verfahren wird beispielsweise von der Fahrzeugkomponente ausgeführt, etwa durch ein oder mehrere Prozessoren der Fahrzeugkomponente, in Verbindung mit ein oder mehreren Speichergeräten und ein oder mehreren Schnittstellen der Fahrzeugkomponente.
Die vorliegende Offenbarung bezieht sich auf ein Verfahren, eine Fahrzeugkomponente sowie auf ein Computerprogramm zum Einräumen einer Berechtigung zum Ausfuhren eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs.
Im Allgemeinen basiert die Absicherung der Ausführung von Computerprogrammen (also Software) auf Fahrzeugkomponenten auf einer Kryptographieinfrastruktur des Fahrzeugherstellers, etwa auf einer Public-Key-Infrastruktur (PKI, Öffentlicher-Schlüssel-Infrastruktur) des Fahrzeugherstellers. Software, die auf den Fahrzeugkomponenten ausgefiihrt werden soll, wird durch den Fahrzeughersteller signiert. Diese Signatur wird dann durch die Fahrzeugkomponente, etwa durch einen sogenannten Bootloader (eines Systems zum Initialisieren der Software der Fahrzeugkomponente beim Start) der Fahrzeugkomponente, geprüft, und die Ausführung der Software ermöglicht, falls die Prüfung ermöglicht ist. Wird eine Public-Key-Infrastruktur genutzt, kommt dabei eine Kombination aus einem sogenannten privaten Schlüssel und einem sogenannten öffentlichen Schlüssel des Fahrzeugherstellers zum Einsatz. Diese beiden Schlüssel bilden ein sogenanntes Schlüsselpaar, wobei der öffentliche Schlüssel aus dem privaten Schlüssel abgeleitet ist. Der private Schlüssel ist dabei ein wohlgehütetes Geheimnis des Fahrzeugherstellers, während der öffentliche Schlüssel weitergegeben werden kann. Der private Schlüssel kann nun durch den Fahrzeughersteller genutzt werden, um das Computerprogramm kryptographisch zu signieren. Der öffentliche Schlüssel wiederum wird auf der Fahrzeugkomponente hinterlegt und kann genutzt werden, um die durch den privaten Schlüssel erzeugte Signatur des Computerprogramms zu überprüfen. Dabei wird meist ein sogenannter Hashwert (Zerwürflungswert) des Computerprogramm gebildet und die Signatur basierend auf dem Hashwert erstellt. Entspricht der Hashwert des Computerprogramms dem Hashwert, der in der Signatur hinterlegt ist, und „passt“ die Signatur zum öffentlichen Schlüssel des Fahrzeugherstellers, ist die Prüfung des Computerprogramms erfolgreich. Dieses Vorgehen wird in den Serienversionen der Fahrzeugkomponenten eingesetzt, um die Ausführung der Software strikt abzusichem.
Entwickelt nun der Hersteller der Fahrzeugkomponente oder ein Dritthersteller ein Computerprogramm für die Fahrzeugkomponente, so müsste dieser, für jede Testversion, das Computerprogramm von dem Fahrzeughersteller signieren lassen, was einen hohen Aufwand bei dem Fahrzeughersteller erzeugt und Verzögerungen erzeugen kann. An dieser Stelle setzt die vorliegende Erfindung an. Zusätzlich zu der bereits genutzten Prüfinfrastruktur wird nun ein weiterer Prüfschlüssel in die Fahrzeugkomponente eingebracht, der auf einer Identifikationsinformation der Fahrzeugkomponente basiert und daher spezifisch für die Fahrzeugkomponente ist. Um für die Entwicklung und Absicherung auf den Serienkomponenten eine möglichst freie Entwicklung zu erlauben, wird hierdurch für ausgewählte Komponenten die Verwendung von der Software aus der Entwicklung freigeschaltet. Dieses kann über die existierende Public -Key-Infrastruktur erfolgen.
Die Freischaltung der Fahrzeugkomponente erfolgt mit Hilfe von zwei Komponenten: Der Identifikationsinformation und des zusätzlichen Prüfschlüssels. Daher umfasst das Verfahren das Hinterlegen 110, im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente und das Hinterlegen 120 des zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses. Hierbei wird deutlich, dass dies zu unterschiedlichen Zeitpunkten geschehen kann. So wird die Identifikationsinformation bereits während des Herstellungsprozesses, d.h., während der ursprünglichen Fertigung eingebracht. Die Identifikationsinformation ist eineindeutig, d.h., eindeutig in beide Richtungen, so dass einer Fahrzeugkomponente (oder einem Fahrzeug) genau eine Identifikationsinformation zugewiesen ist und die Identifikationsinformation genau einer Fahrzeugkomponente (oder einem Fahrzeug) zugewiesen ist. In anderen Worten ist eine Identifikationsinformation genau einer Fahrzeugkomponente (oder einem Fahrzeug) zugewiesen. Die Identifikationsinformation kann beispielsweise ein Binärkode oder ein Alphanumerischer Kode sein oder als solcher ausgedrückt sein. Zudem kann die Identifikationsinformation unveränderlich sein. Beispielsweise kann die Identifikationsinformation in einem Nur-Lese-Speicher der Fahrzeugkomponente eingebracht sein, der nach dem Ende des Herstellungsprozesses unveränderlich ist.
Der zusätzliche Prüfschlüssel wird nun basierend auf der Identifikationsinformation in die Fahrzeugkomponente eingebracht. Dazu wird der zusätzliche Prüfschlüssel beispielsweise basierend auf der Identifikationsinformation generiert. Hiermit wird die Freigabe der Fahrzeugkomponente, über die Signatur/das Zertifikat, an die Identifikationsinformation gekoppelt. Beispielsweise kann ein Entwickler die Identifikationsinformation der Fahrzeugkomponente auslesen, an den Fahrzeughersteller übermitteln, welcher wiederum den zusätzlichen Prüfschlüssel basierend auf der Identifikationsinformation zusammen mit der kryptographischen Signatur generieren kann. Alternativ kann die zusätzliche Prüfschlüssel durch den Entwickler (oder den Zulieferer/Dritthersteller) generiert werden, und anschließend über die kryptographische Signatur mit der Identifikationsinformation gekoppelt werden. In beiden Fällen ist die kryptographische Signatur, mit der der zusätzliche Prüfschlüssel an die Identifikationsinformation gekoppelt ist, von dem Hersteller des Fahrzeugs generiert. Dabei kann die kryptographische Signatur ebenfalls mit dem privaten Schlüssel des Fahrzeugherstellers generiert werden. Die kryptographische Signatur kann so ebenfalls mit dem öffentlichen Schlüssel des Fahrzeugherstellers geprüft werden. Der zusätzliche Prüfschlüssel ist dazu vorgesehen, die Ausführung von Computerprogrammen zusätzlich zu einer Public-Key-Infrastruktur eines Herstellers des Fahrzeugs zu ermöglichen. Daher wird der zusätzliche Prüfschlüssel beispielsweise zusätzlich zu dem öffentlichen Schlüssel des Fahrzeugherstellers eingebracht. Oder, genereller, wird der zusätzliche Prüfschlüssel zusätzlich zu einem weiteren Prüfschlüssel, wie dem öffentlichen Schlüssel des Fahrzeugherstellers, eingebracht, der genutzt wird, um die Ausführung von Computerprogrammen im Serienbetrieb der Fahrzeugkomponente zu beschränken.
Nun wird das Computerprogramm durch die Fahrzeugkomponente erhalten, etwa durch Aufspielen des Computerprogramms über eine Diagnoseschnittstelle der Fahrzeugkomponente, oder durch Abrufen des Computerprogramms aus einer Plattform zum Abrufen von Computerprogrammen. Das Computerprogramm ist kryptographisch signiert. Diese Signatur ist beispielsweise nicht von dem Fahrzeughersteller generiert, sondern wird stattdessen von dem Entwickler selbst, oder von einer Kryptographieinfrastruktur der Zulieferers/Drittherstellers generiert. Dies kann beispielsweise dann geschehen, wenn der zusätzliche Prüfschlüssel von dem Entwickler, Zulieferer oder Dritthersteller stammt, und lediglich die Signatur, mit der der Prüfschlüssel an die Identifikationsinformation gebunden ist, von dem Fahrzeughersteller selbst. So kann es dem Entwickler erlaubt werden die Signatur für die Software selbständig zu erzeugen indem der Öffentliche Schlüssel, d.h. der zusätzliche Prüfschlüssel, für diese Signatur in die Freigabe mit aufgenommen wird. Der Entwickler, Zulieferer oder Dritthersteller kann nun die Signatur mit Hilfe des dazugehörigen Privaten Schlüssels erzeugen. Somit kann die kryptographische Signatur des Computerprogramms basierend auf der Identifikationsinformation der Fahrzeugkomponente oder des Fahrzeugs durch einen Hersteller der Fahrzeugkomponente oder durch einen Dritten generiert sein. Alternativ kann der Zwang einer Signatur ganz entfallen oder die Signatur der Entwickler-Software muss weiter über die Infrastruktur für die Seriensoftware signiert werden.
Um zu verhindern, dass das so signierte Computerprogramm auf beliebigen Fahrzeugkomponenten mit zusätzlichem Prüfschlüssel verwendet werden kann (etwa auf allen Fahrzeugkomponenten, die von dem Zulieferer oder Dritthersteller mit einem zusätzlichen Prüfschlüssel ausgerüstet sind), kann nun die Ausführung mittels der Identifikationsinformation auf einzelne Identifikationsinformationen beschränkt werden. So kann beispielsweise die kryptographische Signatur des Computerprogramms spezifisch für eine einzige Fahrzeugkomponente oder ein einziges Fahrzeug sein, oder die kryptographische Signatur des Computerprogramms spezifisch für eine definierte Menge an Fahrzeugkomponenten oder Fahrzeugen sein. Dies kann dadurch geschehen, dass die Signatur, neben einem Hashwert des Computerprogramms auch auf ein oder mehreren Identifikationsinformationen basiert, d.h. die Signatur wird für ein Paket aus Computerprogramm und ein oder mehreren Identifikationsinformationen generiert. So können auch mehrere Identifikationsinformationen auf einmal freigegeben werden. Das Computerprogramm kann etwa zusammen mit ein oder mehreren Identifikationsinformationen ein oder mehrerer Fahrzeugkomponenten oder Fahrzeuge signiert sein. Dies kann dadurch geschehen, dass ein Manifest mit dem Hashwert des Computerprogramms und den ein oder mehreren Identifikationsinformationen kryptographisch signiert wird. Dies entspricht dann der kryptographischen Signierung des Computerprogramms.
Dies kann nun im Rahmen der Prüfung der kryptographischen Signatur überprüft werden. Das Verfahren umfasst das Prüfung 140 der kryptographischen Signatur mit dem eingebrachten Prüfschlüssel, wobei die Prüfung umfasst, zu überprüfen, ob die kryptographische Signatur auf der Identifikationsinformation basiert. Somit werden drei Aspekte geprüft - a) ob der eingebrachte zusätzliche Prüfschlüssel über eine kryptographische Signatur an die Identifikationsinformation gekoppelt ist, b) ob die kryptographische Signatur des Computerprogramms durch den zusätzlichen Prüfschlüssel als gültig erkannt wird, und c) ob die kryptographische Signatur des Computerprogramms auf der Identifikationsinformation basiert. Durch a) und b) wird eine Sicherheitskette (Chain of Trust) von dem Fahrzeughersteller bis zu dem signierten Computerprogramm aufgespannt. Durch a) und c) wird verhindert, dass das Computerprogramm auf beliebigen Fahrzeugkomponenten auf beliebigen Fahrzeugkomponenten mit zusätzlichem Prüfschlüssel ausführbar ist. Zur Prüfung von c) kann der Hashwert des Computerprogramms (der lokal berechnet wird) mit dem Hashwert, der im Manifest gespeichert ist, verglichen werden sowie die eingebrachte Identifikationsinformation mit den ein oder mehreren Identifikationsinformationen verglichen werden, die im Manifest umfasst ist oder sind. Beispielsweise kann die kryptographische Signatur des Computerprogramms (Prüfaspekte b) und c)), der zusätzliche Prüfschlüssel (Prüfaspekt a)) und die Identifikationsinformation (Prüfaspekt a)) durch einen Bootloader der Fahrzeugkomponente geprüft 140 werden.
Ist die Prüfung erfolgreich, so wird das Computerprogramm ausgeführt 150. Dies kann im Rahmen einer Ausführungsumgebung, die von der Fahrzeugkomponente bereitgestellt wird, etwa neben anderen Computerprogrammen, geschehen. Alternativ kann das Computerprogramm als Abbild (engl. Image) geladen und (alleinig) ausgeführt werden.
Das vorgeschlagene Verfahren ermöglicht eine kontrollierte Freigabe der Software aus der Entwicklung für die Fahrzeuge/Komponenten mit den ausgewählten Identifikationsinformationen. Es kann durch andere Prozesse sichergestellt werden, dass diese Fahrzeuge/IDs nicht in den freien Verkauf gelangen. Ist der Entwicklungsprozess abgeschlossen, wird auch der zusätzliche Prüfschlüssel wieder entfernt. Somit kann das Verfahren ferner ein Entfernen 160 des zusätzlichen Prüfschlüssels, nachdem der Entwicklungsprozess abgeschlossen ist, umfassen. Dies kann beispielsweise der Fall sein, wenn der Entwicklungsprozess tatsächlich als abgeschlossen gelten kann, etwa bei sicherheitskritischer Software, die zu einem bestimmten Zeitpunkt abgenommen wird. In vielen Fällen, etwa in Fällen, in denen Dritthersteller Software für ein Infotainmentsystem des Fahrzeugs entwickeln, schreitet die Entwicklung jedoch kontinuierlich fort. Hier kann während des Fortschreitenden Entwicklungsprozesses der zusätzliche Prüfschlüssel auf der Fahrzeugkomponente verweilen.
Im Folgenden wird Anhand von Beispielen kurz ausgeführt, inwiefern sich die Signaturprüfiing im „Normalfall“, d.h. ohne zusätzlichen Prüfschlüssel, von dem hiervorgestellten Konzept unterschiedet. Im Normalfall ist die Seriensoftware ist über eine kryptographische Signatur gesichert. Diese Signatur stammt beispielsweise aus einer PKI des Herstellers. Der Bootloader überprüft die Signatur und startet die Software nur wenn die Signatur stimmt.
Im vorgestellten Fall, d.h. im Fall, dass die Fahrzeugkomponente für die Entwicklung eingestellt wird, wird (la) die Entwicklungssoftware (d.h. das Computerprogramm) ist über die Signatur des Entwicklers signiert. (1b) Eine PKI des Hersteller hat ein Paket aus eineindeutiger Identifikationsinformation der Komponente und Schlüssel für Signatur des Entwicklers (also den zusätzlichen Prüfschlüssel) signiert. (2a) Der Bootloader erkennt, dass das zusätzliche Paket aus Identifikationsinformation und Entwicklerschlüssel vorhanden ist und prüft diese Signatur. (2b) Wenn die Signaturprüfung erfolgreich war, wird die Software mit dem Schüssel für die Entwicklersignatur geprüft. (3) Bei erfolgreicher Prüfung startet das Steuergerät die Entwicklungssoftware.
Fig. 2a zeigt ein Blockdiagramm eines Beispiels einer Fahrzeugkomponente 20. Diese Fahrzeugkomponente 20 kann nun beispielsweise genutzt werden, um das in Fig. 1 vorgestellte Verfahren auszuführen. Insbesondere umfasst die Fahrzeugkomponente ein oder mehrere Prozessoren 24 und ein oder mehrere Speichergeräte 26. Optional umfasst die Fahrzeugkomponente ferner ein oder mehrere Schnittstellen 22. Die ein oder mehreren Prozessoren 24 sind mit den ein oder mehreren Speichergeräten 26 und den ein oder mehreren Schnittstellen 22 gekoppelt. Die Funktionalität der Fahrzeugkomponente wird, zumindest in Bezug auf das obige Verfahren, von den ein oder mehreren Prozessoren 24 bereitgestellt, unter Zuhilfenahme der ein oder mehreren Speichergeräte 26 (zum Speichern von Informationen wie etwa der Identifikationsinformation, des zusätzlichen Prüfschlüssels, des öffentlichen Schlüssels des Fahrzeugherstellers und des Computerprogramms) und der ein oder mehreren Schnittstellen (zum Austausch von Informationen). Dabei kann die Fahrzeugkomponente beispielsweise eine computerbasierte Fahrzeugkomponente sein, etwa ein computerbasiertes Steuergerät oder eine zentrale Computereinheit (etwa ein Infotainmentsystem) des Fahrzeugs. Die ein oder mehreren Schnittstellen 22 können beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
Die ein oder mehreren Prozessoren 24 können einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen. Beispielsweise kann die Funktionalität der ein oder mehreren Prozessoren 24 auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 24 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung denkbar. Dabei können die ein oder mehreren Prozessoren, etwa im Zusammenspiel mit einer Firmware/UEFI (Unified Extensible Firmware Interface, Vereinheitliche und erweiterbare Firmware-Schnittstelle), dazu ausgebildet sein, eine Secure Boot-Operation (Sichere-Initialisierung-Operation) bereitzustellen, um das Computerprogramm zu laden.
Die ein oder mehreren Speichergeräte 26 können beispielsweise zumindest ein Element der Gruppe von computerlesbares Speichermedium, magnetisches Speichermedium, optisches Speichermedium, Festplatte, Flash-Speicher, Diskette, Zufallszugriffsspeicher (auch engl. Random Access Memory), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), Electronically Erasable Programmable Read Only Memory (EEPROM), und Netzwerkspeicher umfassen.
In der vorliegenden Offenbarung ist die Rede von Fahrzeugkomponenten. Diese sind (computerbasierte) Komponenten, die in Fahrzeugen zum Einsatz kommen. Entsprechend schaffen Ausführungsbeispiele auch ein Fahrzeug 200, umfassend ein oder mehrere Fahrzeugkomponenten 20. Fig. 2b zeigt ein schematisches Diagramm eines Beispiels eines solchen Fahrzeugs 200 mit ein oder mehreren Fahrzeugkomponenten 20, wie sie im Zusammenhang mit den Fign. 1 bis 2a vorgestellt wurden. Das Fahrzeug 200 kann beispielsweise einem Landfahrzeug, einem Wasserfahrzeug, einem Luftfahrzeug, einem Schienenfahrzeug, einem Straßenfahrzeug, einem Auto, einem Geländefahrzeug, einem Kraftfahrzeug, oder einem Lastkraftfahrzeug entsprechen.
Die Aspekte und Merkmale, die im Zusammenhang mit einem bestimmten der vorherigen Beispiele beschrieben sind, können auch mit einem oder mehreren der weiteren Beispiele kombiniert werden, um ein identisches oder ähnliches Merkmal dieses weiteren Beispiels zu ersetzen oder um das Merkmal in das weitere Beispiel zusätzlich einzuführen.
Beispiele können weiterhin ein (Computer-)Programm mit einem Programmcode zum Ausfuhren eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Programm auf einem Computer, einem Prozessor oder einer sonstigen programmierbaren Hardwarekomponente ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen der oben beschriebenen Verfahren können also auch durch programmierte Computer, Prozessoren oder sonstige programmierbare Hardwarekomponenten ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, beispielsweise Digitaldatenspeichermedien, abdecken, die maschinen-, prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme und Anweisungen codieren beziehungsweise enthalten. Die Programmspeichervorrichtungen können beispielsweise Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren, Steuereinheiten, (feld-)programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays), (feld-)programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), Grafikprozessoren (GPU = Graphics Processor Unit), anwendungsspezifische integrierte Schaltungen (ASIC = application-specific integrated circuit), integrierte Schaltungen (IC= Integrated Circuit) oder Ein-Chip-Systeme (SoC = System-on-a-Chip) abdecken, die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind.
Es versteht sich ferner, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, Prozesse, Operationen oder Funktionen nicht als zwingend in der beschriebenen Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht im Einzelfall explizit angegeben oder aus technischen Gründen zwingend erforderlich ist. Daher wird durch die vorhergehende Beschreibung die Durchführung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt. Ferner kann bei weiteren Beispielen ein einzelner Schritt, eine einzelne Funktion, ein einzelner Prozess oder eine einzelne Operation mehrere Teilschritte, -funktionen, - prozesse oder -Operationen einschließen und/oder in dieselben aufgebrochen werden.
Wenn einige Aspekte in den vorhergehenden Abschnitten im Zusammenhang mit einer Vorrichtung oder einem System beschrieben wurden, sind diese Aspekte auch als eine Beschreibung des entsprechenden Verfahrens zu verstehen. Dabei kann beispielsweise ein Block, eine Vorrichtung oder ein funktionaler Aspekt der Vorrichtung oder des Systems einem Merkmal, etwa einem Verfahrensschritt, des entsprechenden Verfahrens entsprechen. Entsprechend dazu sind Aspekte, die im Zusammenhang mit einem Verfahren beschrieben werden, auch als eine Beschreibung eines entsprechenden Blocks, eines entsprechenden Elements, einer Eigenschaft oder eines funktionalen Merkmals einer entsprechenden Vorrichtung oder eines entsprechenden Systems zu verstehen.
Die folgenden Ansprüche werden hiermit in die detaillierte Beschreibung aufgenommen, wobei jeder Anspruch als getrenntes Beispiel für sich stehen kann. Ferner ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen bezieht - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hiermit explizit vorgeschlagen, sofern nicht im Einzelfall angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt als abhängig von diesem anderen unabhängigen Anspruch definiert ist.
Bezugszeichenliste 0 Fahrzeugkomponente 2 Schnittstelle 4 Prozessor 6 Speichergerät 110 Hinterlegen einer Identifikationsinformation
120 Hinterlegen eines zusätzlichen Prüfschlüssels
130 Erhalten eines Computerprogramms
140 Prüfen einer kryptographischen Signatur des Computerprogramms
150 Ausführen des Computerprogramms 160 Entfernen des zusätzlichen Prüfschlüssels 00 Fahrzeug

Claims

Patentansprüche Ein Verfahren zum Einräumen einer Berechtigung zum Ausfuhren eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs, das Verfahren umfassend:
Hinterlegen (110), im Rahmen eines Herstellungsprozesses, einer Identifikationsinformation auf der Fahrzeugkomponente, wobei die Identifikationsinformation spezifisch für die Fahrzeugkomponente ist;
Hinterlegen (120) eines zusätzlichen Prüfschlüssels in die Fahrzeugkomponente während eines Entwicklungsprozesses, der an die Identifikationsinformation durch eine kryptografische Signatur gekoppelt ist;
Erhalten (130) des Computerprogramms für die Fahrzeugkomponente, wobei das Computerprogramm kryptographisch signiert ist; und
Ausfuhren (150) des Computerprogramms, falls die kryptographische Signatur des Computerprogramms nach Prüfung (140) mit dem eingebrachten Prüfschlüssel gültig ist und auf der Identifikationsinformation basiert. Das Verfahren gemäß Anspruch 1, ferner umfassend Entfernen (160) des zusätzlichen Prüfschlüssels, nachdem der Entwicklungsprozess abgeschlossen ist. Das Verfahren gemäß einem der Ansprüche 1 oder 2, wobei der zusätzliche Prüfschlüssel dazu vorgesehen ist, die Ausführung von Computerprogrammen zusätzlich zu einer Public- Key-Infrastruktur eines Herstellers des Fahrzeugs zu ermöglichen. Das Verfahren gemäß einem der Ansprüche 1 oder 2, wobei die kryptographische Signatur des Computerprogramms spezifisch für eine einzige Fahrzeugkomponente oder ein einziges Fahrzeug ist, oder wobei die kryptographische Signatur des Computerprogramms spezifisch für eine definierte Menge an Fahrzeugkomponenten oder Fahrzeugen ist. Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei das Computerprogramm zusammen mit ein oder mehreren Identifikationsinformationen ein oder mehrerer Fahrzeugkomponenten oder Fahrzeuge signiert ist. Das Verfahren gemäß einem der Ansprüche 1 bis 5, wobei die kryptographische Signatur, mit der der zusätzliche Prüfschlüssel an die Identifikationsinformation gekoppelt ist von dem Hersteller des Fahrzeugs generiert ist. Das Verfahren gemäß einem der Ansprüche 1 bis 6, wobei die kryptographische Signatur des Computerprogramms basierend auf der Identifikationsinformation der Fahrzeugkomponente oder des Fahrzeugs durch einen Hersteller der Fahrzeugkomponente oder durch einen Dritten generiert ist. Das Verfahren gemäß einem der Ansprüche 1 bis 7, wobei die kryptographische Signatur des Computerprogramms, der zusätzliche Prüfschlüssel und die Identifikationsinformation durch einen Bootloader der Fahrzeugkomponente geprüft (140) wird. Ein Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß einem der Ansprüche 1 bis 8, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird. Eine Fahrzeugkomponente (20), umfassend ein oder mehrere Prozessoren (24) und ein oder mehrere Speichergeräte (26), wobei die Fahrzeugkomponente ausgebildet ist zum Ausfuhren des Verfahrens gemäß einem der Ansprüche 1 bis 8.
PCT/EP2022/064614 2021-11-15 2022-05-30 Verfahren, fahrzeugkomponente und computerprogramm zum einräumen einer berechtigung zum ausführen eines computerprogramms durch eine fahrzeugkomponente eines fahrzeugs WO2023083500A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202280068930.3A CN118103841A (zh) 2021-11-15 2022-05-30 用于准许授权由交通工具的交通工具部件运行计算机程序的方法、交通工具部件和计算机程序

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021129670.6 2021-11-15
DE102021129670.6A DE102021129670A1 (de) 2021-11-15 2021-11-15 Verfahren, Fahrzeugkomponente und Computerprogramm zum Einräumen einer Berechtigung zum Ausführen eines Computerprogramms durch eine Fahrzeugkomponente eines Fahrzeugs

Publications (1)

Publication Number Publication Date
WO2023083500A1 true WO2023083500A1 (de) 2023-05-19

Family

ID=82258328

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/064614 WO2023083500A1 (de) 2021-11-15 2022-05-30 Verfahren, fahrzeugkomponente und computerprogramm zum einräumen einer berechtigung zum ausführen eines computerprogramms durch eine fahrzeugkomponente eines fahrzeugs

Country Status (3)

Country Link
CN (1) CN118103841A (de)
DE (1) DE102021129670A1 (de)
WO (1) WO2023083500A1 (de)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
DE10354107A1 (de) 2003-07-04 2005-01-20 Bayerische Motoren Werke Ag Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
WO2008058748A1 (de) * 2006-11-17 2008-05-22 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Verfahren zur herstellung eines steuergeräts, steuergerät und arbeitsverfahren des steuergeräts mit kopierschutz
US20140075517A1 (en) * 2012-09-12 2014-03-13 GM Global Technology Operations LLC Authorization scheme to enable special privilege mode in a secure electronic control unit
US20170103209A1 (en) * 2015-10-12 2017-04-13 Microsoft Technology Licensing, Llc Trusted platforms using minimal hardware resources

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9916151B2 (en) 2015-08-25 2018-03-13 Ford Global Technologies, Llc Multiple-stage secure vehicle software updating
US11295017B2 (en) 2017-01-31 2022-04-05 Ford Global Technologies, Llc Over-the-air updates security
EP3696699B1 (de) 2019-02-13 2023-01-04 Siemens Aktiengesellschaft Sichere und flexible firmwareaktualisierung in elektronischen geräten

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
DE10354107A1 (de) 2003-07-04 2005-01-20 Bayerische Motoren Werke Ag Verfahren zur Authentifikation von insbesondere in ein Steuergerät eines Kraftfahrzeugs ladbaren Softwarekomponenten
WO2008058748A1 (de) * 2006-11-17 2008-05-22 Knorr-Bremse Systeme für Nutzfahrzeuge GmbH Verfahren zur herstellung eines steuergeräts, steuergerät und arbeitsverfahren des steuergeräts mit kopierschutz
US20140075517A1 (en) * 2012-09-12 2014-03-13 GM Global Technology Operations LLC Authorization scheme to enable special privilege mode in a secure electronic control unit
US20170103209A1 (en) * 2015-10-12 2017-04-13 Microsoft Technology Licensing, Llc Trusted platforms using minimal hardware resources

Also Published As

Publication number Publication date
CN118103841A (zh) 2024-05-28
DE102021129670A1 (de) 2023-05-17

Similar Documents

Publication Publication Date Title
DE102013108022A1 (de) Verfahren zum Aktivieren des Entwicklungsmodus eines gesicherten elektronischen Steuergeräts
DE102013108020A1 (de) Authentifizierungsschema zum Aktivieren eines Spezial-Privileg-Modus in einem gesicherten elektronischen Steuergerät
DE102012109619A1 (de) Verfahren zum Bereitstellen einer digitalen Signatur zum Sichern einer Flash-Programmierfunktion
DE102013108021A1 (de) Verfahren zum selektiven Software-Rollback
DE102012215729A1 (de) System und Verfahren zum Authentisieren mehrerer Dateien unter Verwendung einer getrennten digitalen Signatur
DE102013105042A1 (de) Sicheres Flashprogrammieren eines sekundären Prozessors
DE102015209108A1 (de) Verfahren und Entscheidungsgateway zum Autorisieren einer Funktion eines eingebetteten Steuergerätes
DE102008021030A1 (de) Verfahren zum Betreiben eines Fahrzeugs sowie entsprechende Vorrichtung und entsprechendes Fahrzeug
DE102013213314A1 (de) Hinterlegen mindestens eines berechenbaren Integritätsmesswertes in einem Speicherbereich eines Speichers
DE602004009639T2 (de) Verfahren oder Vorrichtung zur Authentifizierung digitaler Daten mittels eines Authentifizierungs-Plugins
DE102016210788A1 (de) Komponente zur Verarbeitung eines schützenswerten Datums und Verfahren zur Umsetzung einer Sicherheitsfunktion zum Schutz eines schützenswerten Datums in einer solchen Komponente
DE102018213615A1 (de) Kryptografiemodul und Betriebsverfahren hierfür
WO2023083500A1 (de) Verfahren, fahrzeugkomponente und computerprogramm zum einräumen einer berechtigung zum ausführen eines computerprogramms durch eine fahrzeugkomponente eines fahrzeugs
DE102016200413A1 (de) Mikrocomputer
DE102018211139A1 (de) Steuergerät sowie Verfahren zu dessen Betrieb
DE102021125750A1 (de) Recheneinheit für ein Fahrzeug und Verfahren und Computerprogramm für eine Recheneinheit für ein Fahrzeug
DE102008008969B4 (de) Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung
DE102009002898A1 (de) Verfahren zur Aktualisierung eines Steuergeräts eines Fahrzeugs
DE102018217969A1 (de) Recheneinrichtung und Betriebsverfahren hierfür
DE102022207941A1 (de) Verfahren zum Booten einer elektronischen Steuereinheit
EP3693233B1 (de) Sicherheitsmodus bei ersetzten ecus
DE102022004334A1 (de) Verfahren zum Installieren wenigstens eines Installationspakets auf wenigstens ein Steuergerät eines Kraftwagens
DE102010042574A1 (de) Verfahren zum Betreiben eines Mikrocontrollers für ein Automobil und Mikrocontroller
DE102009058754A1 (de) Verfahren zur Reprogrammierung eines oder mehrerer Steuergeräte eines Fahrzeugs und Steuergerät
DE102016007498A1 (de) Manipulationssichere Bereitstellung einer Funktionalität eines Assistenzsystems eines Kraftfahrzeugs

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22734144

Country of ref document: EP

Kind code of ref document: A1