EP1616232A1 - Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte - Google Patents

Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte

Info

Publication number
EP1616232A1
EP1616232A1 EP04717070A EP04717070A EP1616232A1 EP 1616232 A1 EP1616232 A1 EP 1616232A1 EP 04717070 A EP04717070 A EP 04717070A EP 04717070 A EP04717070 A EP 04717070A EP 1616232 A1 EP1616232 A1 EP 1616232A1
Authority
EP
European Patent Office
Prior art keywords
application program
authentication code
hmac
flashware
hash value
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04717070A
Other languages
English (en)
French (fr)
Inventor
Heiko Kober
Jutta Schneider
Michael Sorg
Eva Wieser
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
DaimlerChrysler AG
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 DaimlerChrysler AG filed Critical DaimlerChrysler AG
Publication of EP1616232A1 publication Critical patent/EP1616232A1/de
Withdrawn legal-status Critical Current

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
    • G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
    • 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes

Definitions

  • the invention relates to a security concept for the download process of software in a control unit.
  • control units are used for control in various areas of technology today.
  • these control units are often connected to each other via a bus system and there are usually possibilities to access this bus from the outside and to communicate with the individual control units.
  • the functionality of the control units is determined by application programs.
  • application programs have mostly been stored in a non-programmable memory, preferably in the control unit. This means that the software cannot be easily manipulated. For example, the complete replacement of a memory module with another memory module can be recognized and reacted to accordingly.
  • flash-programmable control devices in the vehicle increases the risk that unauthorized manipulation of the application programs and thus of the way the control devices work. Measures must therefore be taken to prevent unauthorized overwriting of application programs in the control units.
  • a typical download process of an application program, a so-called flashware is disclosed in patent specification DE 195 06 957 C2.
  • an application program, a so-called flashware is stored in a non-volatile, electrically erasable and programmable memory, known in the art as flash EPROM memory or, briefly, known as flash.
  • flash EPROM memory non-volatile, electrically erasable and programmable memory
  • an initialization routine is stored in the boot area in the electrically erasable and programmable read / write memory (flash).
  • the initialization routine additionally contains a so-called reload routine.
  • This reload routine is activated via a system interface using a special command. After activation, the reload routine first saves the new application program in a buffer. A cyclic block backup procedure is used to check whether the storage of the new application program was incorrect or not. If the new application program has been correctly transferred and buffered, the user program to be exchanged is initiated and executed. For this purpose, the old application program in the erasable and programmable read / write memory (flash) is overwritten with the new application program.
  • This programming or copying process into the flash can also be checked by means of a cyclic block backup method.
  • the check using a cyclic block backup procedure only allows a check to what extent the program was copied correctly.
  • a check for data integrity and authenticity is not possible with cyclic block backup procedures.
  • An unauthorized program or an unauthorized flashware cannot be recognized with cyclic block protection procedures.
  • Encryption and digital signature processes are familiar with the Internet, particularly for home banking and home shopping applications.
  • the basis of all encryption methods common today is the so-called public key encryption.
  • These encryption algorithms work with a secret and a public key, in which the public key may be publicly known, whereas the secret key may only be known to an authorized body, for example a trust center.
  • Such cryptographic algorithms are e.g. B. Rivest, Shamir and Adleman (RSA algorithm), data encryption algorithm (DEA algorithm) or the like.
  • the secret or public key can be used to generate a digital signature for an electronic document, similar to a handwritten signature. Only the owner of the secret or public key can create a valid signature. The authenticity of the document can then be checked by verifying the signature using the associated public or secret key.
  • the secret key is sometimes referred to as a private key.
  • the electronic signature has become known as the signature process. Electronic signature is about ensuring that a message is certain to come from a particular sender and that this message has not been tampered with during transmission.
  • the sender of the information encrypts a message with its own private key, which can be read with the sender's public key.
  • a message that can be read with a public key can only come from the sender, because only the sender has the appropriate private key.
  • the rule here is that you can only encrypt with the private key, while you can only decrypt or read with the public key. So there are messages that can only be written by one person but can be read by anyone with the public key.
  • the sender calculates a kind of summary or cross-sum of the message, the so-called hash code.
  • the calculation rule is such that it is almost impossible to change the message without changing the hash code at the same time.
  • the sender then encrypts the hash code with its private key. That is the electronic signature.
  • the signature is therefore different for each message, only the length of the signature is always the same, regardless of the length of the message. This is the property of the hash codes, which are always the same length.
  • the recipient decrypts the signature using the sender's public key and receives the hash code determined by the sender.
  • the recipient can determine the hash code of the original message and compare it with the hash code that was sent by the sender. If both hash codes match, it is ensured that the message really comes from the one sender and that it has not been tampered with in the transmission path.
  • the aforementioned signature mechanism is based on the RSA public key method for decoding and the RIPEMD-160 hash function for calculating the hash code.
  • the solution is achieved with a simplified, symmetrical, cryptographic procedure.
  • This procedure is based on an authentication code.
  • This authentication code is calculated in a secure area, a so-called trust center, by concatenating the application program, the so-called flashware, with a secret data string and calculating a hash value by the concatenated application program.
  • This hash value is calculated both via the application program and via the secret data string.
  • This hash value is the authentication code for the application program to be checked.
  • the authentication code is checked in the microprocessor system or in the control unit in which the application program is to be used. For this purpose, a second, identical, secret data string is stored in the microprocessor system or the control device.
  • the unencrypted application program and the authentication code are first transmitted to the microprocessor system or the control device.
  • the unencrypted application program is then concatenated in the microprocessor system or in the control device with the second identical, secret data string.
  • a hash value is calculated from this concatenated application program in the microprocessor system or in the control unit. If the calculated hash value and the transmitted authentication code match, the transmitted application program or the transmitted flashware is considered authentic and may be stored in the flash memory and used in the control unit or in the microprocessor system.
  • the hash value is then calculated using the application program concatenated on both sides.
  • the unencrypted application program is concatenated in the microprocessor system or in the control unit with the second, secret data string stored in the control unit, also concatenated on both sides, and a hash value is formed in the control unit or in the microprocessor system via the concatenated application program. If the hash value calculated in the control device or microprocessor system matches the transmitted authentication code, the transmitted application program is considered authentic.
  • the concatenation on both sides has the advantage of improved protection against unauthorized manipulation of the application software.
  • a hash value is calculated by the unilaterally concatenated application program.
  • the concatenation can be at the beginning or end of the program.
  • This first hash value HMAC1 is in turn concatenated on one side with the secret data string. Concatenation can take place on either side of the first hash value.
  • a second hash value HMAC is then calculated for the calculation of an authentication code over the entire structure of the data string and the first hash value HMAC1.
  • Flashware and authentication code can be transmitted together on the same distribution channel or the authentication code can be transmitted by the application program on separate distribution channels. In the case of separate transmission, it is advantageous to distribute the flashware or the application program on hardware storage media. Compact discs, EPROMs or memory cards can be used as preferred storage media.
  • the new application program is preferably provided with an identifier, a so-called flag. This identifier distinguishes the application program as the respectively valid application program.
  • control units are able to calculate the public key algorithms, since some of them do not support floating point arithmetic or cannot provide enough memory space to be able to perform the required encryption calculations.
  • at least 1024 bytes should currently be selected as the key length. Since many control units in motor vehicles only have a memory area of 4 KB, the key alone would occupy a large part of the memory.
  • the invention manages here without encryption algorithms. The only calculation method that is used is hash value calculation. With the aid of the symmetrical, cryptographic method according to the invention, those control devices can also be equipped with an authenticity check for which the public key method cannot be used.
  • the method according to the invention is a so-called message authentication code method, which is based on the calculation of a hash value. It is therefore not a signature process.
  • a signature process requires that the recipient of a message is unable to reproduce the supplied signature.
  • a signature process is not required because the receiving control device does not independently form the message authentication code for a message.
  • the control device only checks a given secret data string for a given message.
  • the hash value calculation is required to secure the transmission path. According to the invention, only the hash value of a message authentication code is transmitted and not the secret data string.
  • the hash value method proposed according to the invention is considerably more runtime and memory space efficient than encryption and decryption methods, such as e.g. B. the public key algorithms.
  • Flashware meta information can be included in the authentication code. Flashware meta information is e.g. B. the location of the flashware, the identification number of the flashware, the identification number of the control unit or the vehicle identification number. This flashware meta information is integrated into the secret data string. The hash value formation via the flashware and the secret data string ensures that the flashware meta information on the transmission path is also secured against manipulation.
  • the flashware download process in the various control units can be selected with this authentication code by including the flashware meta information in the authentication code. Since different control units have different identification numbers and the storage locations for the flashware in the different control device is different, a control device-specific authentication code results in each case even with the same flashware according to the inventive method.
  • FIG. 1 schematically shows a download process of a flashware from a data memory into the control unit of a motor vehicle
  • FIG. 2 shows a download process for flashware, in which the flashware and the authentication code arrive in the control unit of a motor vehicle on separate distribution channels;
  • FIG. 3 shows a flowchart for the calculation of an authentication code for the download process according to FIG. 1;
  • FIG. 4 shows a more complex flowchart for the calculation of an authentication code for the download process according to FIG. 1;
  • Fig. 5 is a flowchart for calculating a Authentifi- z istscodes for the download process according to ' Figure 2;
  • FIG. 6 shows a more complex flow chart for the calculation of an authentication code for the download process according to FIG. 2;
  • FIG. 7 shows a block diagram of a microprocessor system or of a control device with a flash memory, into which an application program can be downloaded using the method according to the invention.
  • FIG. 1 shows one possibility of a download process in which the invention is used.
  • the application programs or the flashware are collected in a data memory 1.
  • the individual application programs or application RAM are Packets 2 transferred to a so-called trust center 3.
  • the application programs are identified with an authentication code.
  • the processes in the trust center itself are explained in more detail below in connection with FIGS. 3 to 6.
  • the unencrypted flashware together with the authentication code HMAC is transferred from the trust center to an external system interface 4.
  • the system interface itself can consist of a diagnostic connection in the motor vehicle. As a rule, however, the system interface will be formed by the diagnostic system in the motor vehicle workshops.
  • the usual data communication paths can be used for the transmission from the trust center to the system interface, in particular landline connections, internet connections and also mobile radio connections.
  • the download process of the transmitted program package or the transmitted flashware and the authentication code HMAC into a control unit of a motor vehicle is initiated by the system interface.
  • the system interface sends a special command to the control unit in the motor vehicle, with which the flash memory in the motor vehicle is prepared for the download process.
  • the programming of the new application program into the flash memory is explained in more detail below in connection with FIG. 7.
  • the transmitted authentication code HMAC is checked in the control unit of the motor vehicle and, if the check is successful, the flashware which is also transmitted is programmed into the flash memory of the control unit.
  • FIG. 2 shows another possibility of a download process according to the invention.
  • the application programs are collected in a data memory 1.
  • the application programs, the so-called flashware are then transferred to a trust center as program packages 2.
  • An authentication code is generated in the trust center 3 for the flashware.
  • the calculation of the authentication code is explained in more detail below in connection with FIGS. 5 and 6.
  • only one authentication code HMAC is transmitted from the trust center to the system interface 4 in the download process described here.
  • the application program itself is transmitted via a separate distribution channel.
  • the flashware is preferably recorded on compact discs, memory cards, EPROMs or other hardware-related storage means 6 and transferred to the control unit 5 of the motor vehicle using a suitable reading device 7.
  • the suitable reading device 7 in the motor vehicle can be formed by an infotainment system such as is used today in vehicles, in particular by a CD-ROM drive or a DVD drive.
  • the download process is initiated in the vehicle by a special command from the system interface 4.
  • the system interface 4 has access to the data buses of the vehicle electrical system in the motor vehicle.
  • the system interface can be formed in the simplest case by a diagnostic connection in the motor vehicle.
  • the system interface is preferably the diagnostic system in the motor vehicle workshop.
  • the verification of the authentication code described above applies regardless of the choice of transmission path for the flashware.
  • the authentication procedure for downloading the flashware from CD-Rom or DVD is the same as for downloading the flashware directly from a central system using wireless or wired data transmission.
  • a hash value is calculated.
  • a test value a so-called print, of fixed length, can be generated for data of any length. This imprint is called the hash value.
  • the hash function and hash value have the following properties:
  • the hash value is easy to calculate.
  • the hash function can only be used for data or data records with a maximum bit length of 2 64 - 1. In the case of shorter data records, the data records are padded with zeros until the length of the padded data record has an integer multiple of 512 bits. The padded data record is then divided into blocks that are at least 512 bits long. Applying the hash function to the 512-bit blocks ultimately results in a 160-bit hash value.
  • the hash function can be applied to any data record, especially flashware.
  • FIG. 3 shows a flowchart for calculating an authentication code within a secure area 3, which is referred to below as the trust center.
  • Secret identifications or identifications in the form of data strings are managed in digital form in the trust center in a separate, secured area, preferably a separate, secured data memory 8.
  • the flashware for which an authentication code is to be calculated is first concatenated with a data string at both ends of the application program. This means that a digital data string from the memory 8 of the trust center is attached to the digital data record of the application program at the beginning and at the end.
  • a hash value is calculated for the flashware that is concatenated on both sides. This hash value now contains all information about the flashware and the secret data string.
  • this hash value is suitable as an authentication code HMAC for the authenticity and the data integrity of the flashware.
  • the authentication code HMAC is added to the unencrypted application program, the so-called flashware and transmitted from the trust center to the system interface for further transmission into the motor vehicle.
  • FIG. 4 shows a more complex process for calculating an authentication code in a trust center.
  • the flashware is first concatenated on one side with a secret data string. The concatenation can take place either at the beginning or at the end of the data record of the flashware.
  • a first hash value calculation is carried out using the concatenated flashware.
  • a first hash value HMAC1 is obtained.
  • This first hash value HMAC1 is in turn concatenated on one side with a secret data string from the memory 8.
  • concatenation can take place at the beginning or at the end of the first hash value.
  • a second hash value calculation is carried out using the entire structure comprising the secret data string and the first hash value. The result of this last hash value calculation gives the authentication code HMAC.
  • Unencrypted original flashware is then added to the authentication code and transmitted to the system interface.
  • the exemplary embodiment in FIG. 4 is suitable for a download process in accordance with FIG. 1.
  • FIG. 5 shows a flow chart for calculating an authentication code within a trust center for use in the download process according to FIG. 2.
  • the unencrypted original flashware is concatenated on both sides with a secret data string.
  • a hash value calculation is carried out for the flashware that is concatenated on both sides.
  • the result of this hash value calculation is the authentication code HMAC.
  • only the authentication code is transmitted to the system interface in the exemplary embodiment in FIG.
  • the distribution the original and unencrypted flashware is carried out on separate distribution channels.
  • the flashware is preferably transmitted on hardware storage elements and read into the motor vehicle (for more information, see FIG. 2).
  • FIG. 6 shows a further exemplary embodiment of a more complex calculation of an authentication code, as is used in connection with the download process according to FIG. 2.
  • the unencrypted flashware is first concatenated on one side with a secret data string in the trust center.
  • the concatenation can take place both at the beginning and at the end of the data record of the flashware.
  • a hash value calculation is carried out using the concatenated flashware.
  • the result is a first hash value HMAC1.
  • This first hash value HMAC1 is in turn concatenated on one side with a secret data string from the memory 8.
  • concatenation can take place at the beginning or at the end of the first hash value.
  • a second hash value calculation is carried out over the entire structure of the secret data string and the first hash value.
  • the result of this last hash value calculation gives the authentication code HMAC.
  • This authentication code is transmitted to the system interface.
  • only the authentication code is transmitted to the system interface in the exemplary embodiment in FIG.
  • the unencrypted original software is read into the motor vehicle analogously to FIG. 2 via storage media, preferably compact discs.
  • a typical control unit also as an electronic ronic control unit ECU, contains a computing unit, a so-called microprocessor CPU, which is connected to various memories or memory sectors via a processor bus PBUS. Via an interface, the control unit can either be addressed from the outside or communicate with other units connected to the interface.
  • the memory of the control unit consists of a boot sector, a flash memory and a RAM.
  • the flash memory flash is an electrically erasable and programmable memory, for example an EEPROM.
  • the operating system of the microprocessor, a so-called flash boot loader, and the RIPEMD-160 algorithm for the hash function are stored in the boot sector.
  • a secret data string is stored in the control unit in a memory or memory area that is particularly protected from external access.
  • This particularly protected data area 9 can also be arranged in the boot area.
  • Another possibility is to design this specially protected data memory 9 in the form of a memory card which cannot be overwritten and is protected against unauthorized reading, or in the form of a so-called crypto processor which deletes its contents when an unauthorized access is attempted.
  • These measures or this configuration of the specially protected memory area 9 ensures that the data string stored therein is kept secret.
  • Which data strings are programmed into the specially protected data area 9 must be coordinated with the data strings for calculating the authentication codes in the trust center.
  • the data string in the control unit must match the data string that was used to calculate the authentication code.
  • the application programs are stored in the flash of the control unit and can be updated as flashware.
  • An overwriting of already stored user programs with new flashware basically takes place in the following way.
  • the control device is prepared for a download process and for a flash process using a special software command that is transmitted from an external system interface via the interface of the control device.
  • the so-called Flash Boot Loader is activated with the software command.
  • the Flash Boot Loader is essentially a reload routine with which application programs are written into the flash memory of the control unit.
  • the new flashware and the transmitted authentication code are first temporarily stored in the main memory of the control unit.
  • the cached flashware and the cached authentication code are checked for authenticity and data integrity in the microprocessor of the control unit.
  • This check is carried out in such a way that the same process steps that were used to generate the transmitted authentication code are carried out in the microprocessor with the unencrypted software and the secret data string stored in the control device.
  • the process steps that were carried out in the trust center in order to generate the authentication code are thus repeated in the microprocessor of the control device.
  • Has z For example, if the authentication code is generated according to the exemplary embodiment in FIG. 3, the temporarily stored flashware is concatenated on both sides with the secret data string stored in the control unit in the microprocessor of the control unit.
  • the RIPEMD-160 algorithm is used to calculate the hash value of the flashware that is concatenated on both sides.
  • the result of this hash value calculation in the control unit is compared with the transmitted identification code HMAC. If both hash values are identical, the flashware temporarily stored in the working memory is considered to be authentic and integer.
  • Has the authentication 3, 4, 5 or 6 the concatenations of the temporarily stored flashware with the secret data string stored in the control unit and the hash code must be checked in the control unit or in the microprocessor of the control unit. Value calculations of the concatenated flashware are carried out in the manner in which they were carried out in the trust center in order to generate the transmitted authentication code.
  • the flash boot loader After a successful check of the newly downloaded and cached flashware, the flash boot loader writes the new cached flashware into the flash memory of the control unit.
  • the copying process from the main memory into the flash memory can also be checked for completeness using a cyclic block backup method. If the authenticity check and the copying process were error-free, a so-called flag is set for the flashware now in flash.
  • This flag identifies the application program now in flash as the valid application program to be used.
  • the flag can be set, for example, as shown in FIG. 7, for example in the flash memory itself, preferably the flash memory is designed as an EEPROM.
  • the control unit can now go into the application and will use the application programs marked with a valid flag.
  • the flash boot loader is preferably activated by the diagnostic system in a workshop.
  • the diagnostic system of the workshop forms the system interface 4.
  • unencrypted flashware and authentication code can be buffered together by the system interface via the interface in the main memory of the control device.
  • the authentication code is temporarily stored in the main memory of the control unit via the system interface, while the unencrypted flashware is temporarily stored in the main memory of the control unit via a further reading device, preferably a CD-ROM drive or a chip card reader.
  • the reload routine of the Flash Boot Loader must therefore download the required data records from different IT systems, if necessary.
  • communication in the motor vehicle takes place via the motor vehicle internal data buses.
  • a data bus that is widely used in motor vehicles today is the so-called CAN bus.
  • the existing flash memory is deleted.
  • the new flashware is downloaded and programmed.
  • the downloaded flashware is then verified, i.e. checked for transmission errors.
  • the authenticity check is then carried out as in the previous exemplary embodiments.
  • the downloaded flashware is identified and activated by setting a flag in the form of a status bit.
  • Direct downloading without buffering the flashware has the additional advantage of "end-to-end” protection, since write errors are also recognized during the download process.
  • the flashware can be supplemented with so-called meta information.
  • This flashware meta information is in particular a vehicle identification number, a control unit number or a special storage location for the flashware.
  • the Flashware meta information e.g. B. Select the location for the new flashware to be downloaded. Because the flashware meta information is included in the calculation of the authentication code, there is also protection against manipulation of this flashware meta information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

Die Erfindung betrifft ein vereinfachtes symmetrisches, kryptographisches Verfahren das auf möglichst allen Steuergeräten in heutigen Kraftfahrzeugen eingesetzt werden kann. Grundlage dieses Verfahrens ist ein Authentifizierungscode. Dieser Authentifizierungscode wird in einem gesicherten Bereich, einem sogenannten Trust-Center, berechnet, indem das Anwendungsprogramm, die sogenannte Flashware, mit einem geheimen Datenstring konkateniert wird und von dem konkatenierten Anwend ungsprogramm ein Hash-Wert berechnet wird. Dieser Hash-Wert wird hierbei sowohl über das Anwendungsprogramm als auch über den geheimen Datenstring berechnet. Dieser Hash-Wert ist der Authentifizierungscodes erfolgt in dem Mikroprozessorsystem oder in dem Steuergerät, in dem das Anwndungsprogramm eingesetzt weden so 11.

Description

Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
Die Erfindung betrifft ein Sicherheitskonzept für den Down loadprozess einer Software in einem Steuergerät .
Mit dem zunehmenden Anteil der Elektronik und der Kommunikationsmöglichkeiten im und mit einem Fahrzeug wachsen auch die Anforderungen, welche an die Sicherheit gestellt werden müssen. In den verschiedenen Bereichen der Technik werden heutzutage MikroController zur Steuerung eingesetzt. Diese Steuergeräte sind heutzutage oft über ein Bussystem miteinander verbunden und es gibt meist Möglichkeiten von außen auf diesen Bus zuzugreifen und mit den einzelnen Steuergeräten zu kommunizieren. Die Funktionsweise der Steuergeräte wird hierbei durch Anwendungsprogramme bestimmt. Diese Anwendungsprogramme sind bisher meist in einem nicht programmierbaren Speicher, bevorzugterweise im Steuergerät abgelegt. Dadurch ist eine Manipulation der Software nicht ohne weiteres zu realisieren. Beispielsweise kann der komplette Austausch eines Speicherbausteins gegen einen anderen Speicherbaustein erkannt und entsprechend darauf reagiert werden. Durch den zukünftigen Einsatz von programmierbaren, insbesondere sogenannten flashprogrammierbaren Steuergeräten im Fahrzeug, wird die Gefahr jedoch größer, dass unbefugte Manipulationen an den Anwendungsprogrammen und somit an der Arbeitsweise der Steuergeräte durchgeführt werden. Es müssen deshalb Maßnahmen getroffen werden, die ein unbefugtes Überschreiben von Anwendungsprogrammen in den Steuergeräten verhindern. Einen typischen Downloadprozess eines Anwendungsprogramms, einer sogenannten Flashware, offenbart die Patentschrift DE 195 06 957 C2. Bei diesem System wird ein Anwendungsprogramm, eine sogenannte Flashware, in einen nichtflüchtigen, elektrisch lösch- und programmierbaren Speicher, in der Fachwelt als Flash-EPROM-Speicher bekannt oder kurz als Flash bekannt, abgelegt. Hierzu ist im elektrisch lösch- und programmierbaren Schreiblesespeicher (Flash) eine Initialisierungsroutine im Boot-Bereich hinterlegt. Mit Hilfe dieser Initialisierungsroutine werden die Anwenderprogramme bei der Inbetriebnahme des Mikroprozessorsystems geladen und gestartet . Um ein bestehendes Anwendungsprogramm durch ein neues ersetzen zu können, enthält die Initialisierungsroutine zusätzlich eine sogenannte Nachladeroutine. Diese Nachladeroutine wird über eine Systemschnittstelle mittels eines besonderen Befehles aktiviert. Nach Aktivierung speichert die Nachladeroutine das neue Anwendungsprogramm zunächst in einem Zwischenspeicher ab. Mittels eines zyklischen Blocksicherungsverfahrens wird überprüft, ob die Abspeicherung des neuen Anwendungsprogramms fehlerhaft war oder nicht . Wurde das neue Abwendungsprogramm korrekt übertragen und zwischengespeichert, wird das Löschen des auszutauschenden Anwenderprogramms eingeleitet und durchgeführt. Hierzu wird das alte Anwendungsprogramm in dem lösch- und programmierbaren Schreiblesespeicher (Flash) mit dem neuen Anwendungsprogramm überschrieben. Auch dieser Programmier- bzw. Kopiervorgang in den Flash kann mittels eines zyklischen Blocksicherungsverfahrens überprüft werden. Die Überprüfung mittels zyklischen Blocksicherungsverfahrens erlaubt lediglich eine Überprüfung inwieweit das Programm korrekt kopiert wurde . Eine Überprüfung auf Datenintegrität und Authentizität ist mit zyklischen Blocksicherungsverfahren nicht möglich. Ein nicht autorisiertes Programm bzw. eine nicht autorisierte Flashware kann mit zyklischen Blocksicherungsverfahren nicht erkannt werden.
Andererseits kennt man aus dem Bereich des Internets, besonders für Homebanking- und Homeshopping-Anwendungen, Ver- Schlüsselungsverfahren und digitale Signaturverfahren. Die Basis aller heute verbreiteten Verschlüsselungsverfahren ist die sogenannte Public-Key-Verschlüsselung. Diese Verschlüsselungsalgorithmen arbeiten mit einem geheimen und einem öffentlichen Schlüssel, bei dem der öffentliche Schlüssel öffentlich bekannt sein darf, wogegen der geheime Schlüssel nur einer autorisierten Stelle, beispielsweise einem Trust-Center bekannt sein darf. Solche kryptographisehen Algorithmen sind z. B. Rivest, Shamir und Adleman (RSA-Algorithmus) , Data Enc- ryption Algorithmus (DEA-Algorithmus) oder dgl . Mit dem geheimen oder öffentlichen Schlüssel lässt sich - analog zur handschriftlichen Unterschrift - eine digitale Signatur zu einem elektronischen Dokument erzeugen. Nur der Besitzer des geheimen bzw. öffentlichen Schlüssels kann eine gültige Signatur erstellen. Die Echtheit des Dokuments kann dann über die Verifikation der Unterschrift mittels des zugehörigen öffentlichen bzw. geheimen Schlüssel geprüft werden. Der geheime Schlüssel wird manchmal auch als privater Schlüssel bezeichnet .
Als Signaturverfahren ist die elektronische Unterschrift bekannt geworden. Bei der elektronischen Unterschrift geht es darum sicherzustellen, dass eine Nachricht mit Sicherheit von einem bestimmten Absender kommt und dass diese Nachricht während der Übertragung nicht verfälscht wurde.
Hat der Sender erst einmal einen öffentlichen und einen privaten Schlüssel erzeugt, so ist folgendes Verfahren denkbar:
Der Sender der Informationen verschlüsselt mit seinem eigenen privaten Schlüssel eine Nachricht, die mit dem öffentlichen Schlüssel des Senders gelesen werden kann. Eine Nachricht, die mit öffentlichen Schlüssel gelesen werden kann, kann nur von dem Sender stammen, denn nur der Sender hat den passenden privaten Schlüssel. Hierbei gilt, dass man mit dem privaten Schlüssel nur verschlüsseln kann, während man mit dem öffentlichen Schlüssel nur entschlüsseln bzw. lesen kann. So ent- stehen also Nachrichten, die nur von einer Person geschrieben, aber von allen, die den öffentlichen Schlüssel haben, gelesen werden können.
Die Verschlüsselung der gesamten Nachricht ist mit den vorgenannten Verschlüsselungsverfahren relativ rechenzeitaufwendig und für den Zweck nur die Authentizität des Autors festzustellen nicht notwendig. Daher wird in der Praxis ein etwas anderes Verfahren verwendet :
■ Der Sender berechnet eine Art Zusammenfassung oder Quersumme der Nachricht, den sogenannten Hash-Code. Dabei ist die Berechnungsvorschrift so beschaffen, dass es nahezu unmöglich ist, die Nachricht zu verändern, ohne gleichzeitig den Hash-Code zu ändern.
■ Der Sender verschlüsselt dann den Hash-Code mit seinem privaten Schlüssel. Das ist die elektronische Unterschrift. Die Unterschrift ist also für jede Nachricht anders, nur die Länge der Unterschrift ist immer gleich, unabhängig von der Länge der Nachricht. Dies ist Eigenschaft der Hash-Codes, die immer die gleiche Länge haben.
■ Versandt wird dann die Nachricht mit der Unterschrift.
■ Der Empfänger entschlüsselt die Unterschrift mit dem öffentlichen Schlüssel des Senders und erhält den vom Sender ermittelten Hash-Code.
■ Nun kann der Empfänger selbst den Hash-Code der Original- nachricht ermitteln und mit dem Hash-Code, der vom Sender mitgeschickt wurde, vergleichen. Stimmen beide Hash-Codes überein, ist sichergestellt, dass die Nachricht wirklich von dem einen Sender stammt und dass sie auf dem Übertragungsweg nicht verfälscht wurde. Der vorgenannte Signaturmechanismus basiert hierbei für die Dechiffrierung auf dem Public-Key-Verfahren RSA und für die Berechnung des Hash-Codes auf der Hash-Funktion RIPEMD-160.
Durch Kombination von Verschlüsselung und elektronischer Unterschrift können schließlich Nachrichten versandt werden, die vor Verfälschung sicher und eindeutig einem Absender zuzuordnen sind.
Basierend auf den vorgenannten Verschlüsselungsverfahren und Signaturverfahren hat man in der deutschen Patentanmeldung DE 100 08 974 AI ein Signaturverfahren zur Sicherstellung der Datenintegrität einer Software für ein Steuergerät in einem Kraftfahrzeug vorgeschlagen. Bei diesem Verfahren wird der öffentliche Schlüssel in einem Speicherbereich des Steuergerätes hinterlegt. Die einzuspielende Software, die sogenannte Flashware, wird mit dem zweiten geheimen Schlüssel signiert. Zum Einspielen der signierten Software wird diese Flashware zunächst in einem Speicher des Steuergerätes abgelegt . Mit dem im Steuergerät selbst hinterlegten öffentlichen Schlüssel wird die Signatur der Flashware überprüft . Wenn die Überprüfung der elektronischen Signatur mit positivem Ergebnis verläuft, wird die zwischengespeicherte Flashware in einen elektrisch löschbaren und programmierbaren Speicher auf dem Steuergerät, den sogenannten Flash, eingelesen.
Zur Berechnung der Public-Key-Algorithmen sind nicht alle Steuergeräte in der Lage, da sie teilweise keine Gleitkommaarithmetik unterstützen oder nicht ausreichend Speicherplatz zur Verfügung stellen können. Um RSA sicher gestalten zu können, sollten als Schlüssellänge derzeit mindestens 1024 Byte gewählt werden. Die vorgenannten Signaturverfahren können deshalb in vielen, der heute in Fahrzeugen verwendeten Steuergeräten nicht eingesetzt werden.
Ausgehend von dem vorgenannten Stand der Technik ist es erfindungsgemäße Aufgabe, ein vereinfachtes Signaturverfahren anzugeben, das auf möglichst allen Steuergeräten in heutigen Kraftfahrzeugen eingesetzt werden kann.
Die erfindungsgemäße Lösung dieser Aufgabe gelingt mit einem Verfahren mit den Merkmalen der unabhängigen Ansprüche. Weitere vorteilhafte Ausgestaltungen der Erfindung sind in den Unteransprüchen und in der Beschreibung der Ausführungsbei- spiele enthalten.
Die Lösung gelingt mit einem vereinfachten symmetrischen, kryptographisehen Verfahren. Grundlage dieses Verfahrens ist ein Authentifizierungscode . Dieser Authentifizierungscode wird in einem gesicherten Bereich, einem sogenannten Trust- Center, berechnet, indem das Anwendungsprogramm, die sogenannte Flashware, mit einem geheimen Datenstring konkateniert wird und von dem konkatenierten Anwendungsprogramm ein Hash- Wert berechnet wird. Dieser Hash-Wert wird hierbei sowohl über das Anwendungsprogramm als auch über den geheimen Datenstring berechnet. Dieser Hash-Wert ist der Authentifizierungscode für das zu prüfende Anwendungsprogramm. Die Überprüfung des Authentifizierungscodes erfolgt in dem Mikroprozessorsystem oder in dem Steuergerät, in dem das Anwendungsprogramm eingesetzt werden soll. Hierzu ist in dem Mikroprozessorsystem oder dem Steuergerät ein zweiter, gleicher, geheimer Datenstring abgelegt. In das Mikroprozessorsystem bzw. in das Steuergerät wird zunächst das unverschlüsselte Anwendungsprogramm und der Authentifizierungscode übertragen. Dann wird im Mikroprozessorsystem bzw. im Steuergerät das unverschlüsselte Anwendungsprogramm mit dem zweiten gleichen, geheimen Datenstring konkateniert . Von diesem konkatenierten Anwendungsprogramm wird im Mikroprozessorsystem bzw. im Steuergerät ein Hash-Wert berechnet . Stimmen berechneter Hash- Wert und übertragener Authentifizierungscode überein, so gilt das übertragene Anwendungsprogramm bzw. die übertragene Flashware als authentisch und darf im Flashspeicher abgelegt werden und im Steuergerät bzw. im Mikroprozessorsystem angewandt werden. In einer Weiterbildung der Erfindung wird das Anwendungsprogramm mit dem geheimen Datenstring beidseitig sowohl am Programmanfang als auch am Programmende konkateniert. Die Hash-Wertberechnung erfolgt dann über das beidseitig konkatenierte Anwendungsprogramm. Zur Überprüfung des dermaßen gebildeten Authentifizierungscodes wird im Mikroprozessorsystem bzw. im Steuergerät das unverschlüsselt übertragene Anwendungsprogramm mit dem im Steuergerät abgelegten zweiten, geheimen Datenstring ebenfalls beidseitig konkateniert und über das beidseitig konkatenierte Anwendungsprogramm im Steuergerät bzw. im Mikroprozessorsystem ein Hash- Wert gebildet. Stimmt der im Steuergerät bzw. Mikroprozessorsystem berechnete Hash-Wert mit dem übertragenen Authentifi- zierungscode überein, so gilt das übertragene Anwendungsprogramm als authentisch. Die beidseitige Konkatenierung hat den Vorteil eines verbesserten Schutzes gegenüber unerlaubten Manipulationen der Anwendungssoftware.
Eine weitere Verbesserung gegenüber Manipulationen erhält man mit einer zweimaligen Berechnung eines Hash-Wertes. Bei dieser Ausführung der Erfindung wird das Anwendungsprogramm zunächst einseitig mit einem geheimen Datenstring konkateniert, dann wird von dem einseitig konkatenierten Anwendungsprogramm ein Hash-Wert berechnet . Die Konkatenierung kann hierbei am Programmanfang oder am Programmende sein. Dieser erste Hash- Wert HMAC1 wird wiederum einseitig mit dem geheimen Datenstring konkateniert. Die Konkatenierung kann hierbei auf jeder Seite des ersten Hashwerts erfolgen. In einem weiteren folgenden Schritt wird dann zur Berechnung eines Authentifi- zierungscodes schließlich ein zweiter Hash-Wert HMAC über das Gesamtgebilde aus Datenstring und erstem Hash-Wert HMAC1 berechnet. Zur Überprüfung des Authentifizierungscodes im Steuergerät bzw. im Mikroprozessorsystem müssen im Mikroprozessorsystem bzw. im Steuergerät die vorgenannten Berechnungs- schritte in gleicher Reihenfolge wiederholt werden. Stimmen der berechnete Hash-Wert mit dem übertragenen Authentifizierungscode überein, so gilt die übertragene AnwendungsSoftware als einwandfrei. Für den Downloadprozess von der Flashware selbst, gibt es verschiedene Möglichkeiten der Übertragung. Flashware und Authentifizierungscode können zusammen auf dem gleichen Vertriebsweg übertragen werden oder der Authentifizierungscode kann von dem Anwendungsprogramm auf getrennte Vertriebswege übertragen werden. Bei der getrennten Übertragung ist es vorteilhaft, die Flashware bzw. das Anwendungsprogramm auf hardwaremäßigen Speichermedien zu vertreiben. Als bevorzugte Speichermedien kommen Compactdiscs, EPROMs oder Speicherkarten in Frage .
Bei erfolgreicher Authen ifizierung des zu übertragenden Anwendungsprogramms in den Flashspeicher des Systems wird das neue Anwendungsprogramm vorzugsweise mit einer Kennung versehen, einem sogenannten Flag. Diese Kennung zeichnet das Anwendungsprogramm als das jeweils gültige Anwendungsprogramm aus .
Mit der Erfindung werden hauptsächlich folgende Vorteile erzielt :
Zur Berechnung der Public-Key-Algorithmen sind nicht alle Steuergeräte in der Lage, da sie teilweise keine Gleitkommaarithmetik unterstützen oder nicht ausreichend Speicherplatz zur Verfügung stellen können, um die erforderlichen Verschlüsselungsberechnungen durchführen zu können. Um die Pub- lic-Key-Algorithmen sicher zu gestalten, sollten als Schlüssellänge derzeit mindestens 1024 Byte gewählt werden. Da viele Steuergeräte in Kraftfahrzeugen lediglich einen Speicherbereich von 4 KByte haben, würde alleine schon der Schlüssel einen großen Teil des Speichers belegen. Die Erfindung kommt hier ohne Verschlüsselungsalgorithmen aus. Das einzige Berechnungsverfahren, das eingesetzt wird, ist die Hash- Wertberechnung . Mit Hilfe des erfindungsgemäßen symmetrischen, kryptographischen Verfahrens lassen sich auch diejenigen Steuergeräte mit einer Authentizitätsprüfung ausstatten, für die Public-Key-Verfahren nicht anwendbar sind. Das erfindungsgemäße Verfahren ist ein sogenanntes Message Authentication Code-Verfahren, das auf der Berechnung eines Hash-Wertes basiert. Es ist damit kein Signaturverfahren. Ein Signaturverfahren erfordert, dass der Empfänger einer Nachricht nicht in der Lage ist, die mitgelieferte Signatur nachzubilden. Für die Anwendung in eingebetteten Systemen, wie z. B. Steuergeräten, ist ein Signaturverfahren nicht erforderlich, da das empfangende Steuergerät den Message Authentication Code für eine Nachricht nicht selbstständig bildet . Das Steuergerät prüft lediglich einen gegebenen geheimen Datenstring für eine gegebene Nachricht. Die Hash-Wertberechnung ist erforderlich, um den Übertragungsweg abzusichern. Erfindungsgemäß wird nämlich lediglich der Hash-Wert eines Message Authentication Codes übertragen und nicht der geheime Datenstring. Das erfindungsgemäß vorgeschlagene Hash-Wertverfahren ist wesentlich laufzeit- und speicherplatzeffizienter als es Chiffrier- und Dechiffrierverfahren, wie z. B. die Public- Key-Algorithmen, sein können.
In den Authentifizierungscode können Flashware-Metainforma- tionen mit einbezogen werden. Flashware-Metainformationen sind z. B. der Speicherort der Flashware, die Identifikationsnummer der Flashware, die Identifikationsnummer des Steuergerätes oder die Fahrzeugidentifikationsnummer. Diese Flashware-Metainformation wird in den geheimen Datenstring integriert . Durch die Hash-Wertbildung über die Flashware und über den geheimen Datenstring ist damit sichergestellt, dass auch die Flashware-Metainformation auf dem Übertragungsweg gegenüber Manipulationen gesichert wird.
Kommt die gleiche Flashware auf mehreren Steuergeräten zum Einsatz, so kann durch Einbeziehung der Flashware-Metainformation in den Authentifizierungscode der Download-Vorgang der Flashware in die verschiedenen Steuergeräte mit diesem Authentifizierungscode selektiert werden. Da verschiedene Steuergeräte verschiedene Identifikationsnummern haben und auch die Speicherorte für die Flashware in den verschiedenen Steu- ergeräten unterschiedlich ist, ergibt sich selbst bei gleicher Flashware nach dem erfindungsgemäßen Verfahren jeweils ein steuergerätespezifischer Authentifizierungscode .
Ausführungsbeispiele der Erfindung werden im Folgenden anhand der Figuren näher erläutert .
Es zeigen:
Fig. 1 schematisch einen Downloadprozess einer Flashware von einem Datenspeicher bis in das Steuergerät eines Kraftfahrzeugs ;
Fig. 2 einen Downloadprozess für Flashware, bei dem die Flashware und der Authentifizierungscode auf getrennten Vertriebswegen in das Steuergerät eines Kraftfahrzeuges gelangen;
Fig. 3 ein AblaufSchema für die Berechnung eines Authentifi- zierungscodes für den Downloadprozess nach Figur 1 ;
Fig. 4 ein aufwendigeres AblaufSchema für die Berechnung eines Authentifizierungscodes für den Downloadprozess nach Figur 1 ;
Fig. 5 ein AblaufSchema für die Berechnung eines Authentifi- zierungscodes für den Downloadprozess nach' Figur 2 ;
Fig. 6 ein aufwendigeres Ablaufschema für die Berechnung eines Authentifizierungscodes für den Downloadprozess nach Figur 2 ;
Fig. 7 ein Blockdiagramm eines Mikroprozessorsystems oder eines Steuergerätes mit einem Flashspeicher, in den mit dem erfindungsgemäßen Verfahren ein Anwendungsprogramm heruntergeladen werden kann.
Figur 1 zeigt eine Möglichkeit eines Downloadprozesses, bei dem Erfindung eingesetzt wird. Nach Abschluss der Programmentwicklung werden die Anwendungsprogramme bzw. die Flashware in einem Datenspeicher 1 gesammelt. Auf gesichertem Wege werden die einzelnen Anwendungsprogramme bzw. Anwendungs-RAM- Pakete 2 in ein sogenanntes Trust-Center 3 überspielt. Im Trust-Center selbst, werden die Anwendungsprogramme mit einem Authentifizierungscode gekennzeichnet. Die Abläufe im Trust- Center selbst, werden weiter unten im Zusammenhang mit den Figuren 3 bis 6 näher erläutert. Vom Trust-Center aus, wird die unverschlüsselte Flashware zusammen mit dem Authentifi- zierungscode HMAC an eine externe Systemschnittstelle 4 übergeben. Die Systemschnittstelle selbst, kann im einfachsten Fall aus einem Diagnoseanschluss im Kraftfahrzeug bestehen. In der Regel wird jedoch die Systemschnittstelle durch das Diagnosesystem in den Kraftfahrzeugwerkstätten gebildet werden. Für die Übertragung vom Trust-Center zur Systemschnittstelle können hierbei die üblichen Datenkommunikationswege benutzt werden, das sind insbesondere Festnetzverbindungen, Internetverbindungen und auch Mobilfunkverbindungen. Von der Systemschnittstelle wird der Downloadprozess des übertragenen Programmpaketes bzw. der übertragenen Flashware und des Authentifizierungscodes HMAC in ein Steuergerät eines Kraftfahrzeuges veranlasst. Hierzu sendet die Systemschnittstelle an das Steuergerät im Kraftfahrzeug ein spezielles Kommando, mit dem der Flashspeicher im Kraftfahrzeug für den Downloadprozess vorbereitet wird. Das Einprogrammieren des neuen Anwendungsprogramms in den Flashspeicher wird weiter unten im Zusammenhang mit Figur 7 näher erläutert . Im Steuergerät des Kraftfahrzeugs wird der übertragene Authentifizierungscode HMAC überprüft und bei erfolgreicher Überprüfung wird die mitübertragene Flashware in den Flashspeicher des Steuergerätes einprogrammiert. Die Überprüfung des Authentifizierungscodes im Steuergerät des Kraftfahrzeuges erfolgt im Wesentlichen durch Wiederholen der Schritte, mit denen der Authenti- fizierungscode im Trust-Center erzeugt wurde. Nähere Erläuterungen zur Überprüfung des Authentifizierungscodes finden sich weiter unten in den Figurenbeschreibungen zu den Figuren 3 bis 6. Figur 2 zeigt eine andere Möglichkeit eines erfindungsgemäßen Downloadprozesses. Auch bei diesem Ausführungsbeispiel werden die Anwendungsprogramme in einem Datenspeicher 1 gesammelt . Sodann werden die Anwendungsprogramme, die sogenannte Flashware, als Programmpakete 2 an ein Trust-Center übergeben. In dem Trust-Center 3 wird für die Flashware ein Authentifizierungscode erzeugt. Die Berechnung des Authentifizierungscodes wird weiter unten im Zusammenhang mit den Figuren 5 und 6 näher erläutert. Im Unterschied zu dem Downloadprozess nach Figur 1 wird bei dem hier beschriebenen Downloadprozess lediglich ein Authentifizierungscode HMAC vom Trust-Center an die Systemschnittstelle 4 übertragen. Das Anwendungsprogramm selbst, die sogenannte Flashware, wird auf einem getrennten Vertriebsweg übermittelt . Vorzugsweise wird die Flashware auf Compactdiscs, Speicherkarten, EPROMs oder anderen hardwaremäßigen Speichermitteln 6 festgehalten und mit einem geeigneten Lesegerät 7 in das Steuergerät 5 des Kraftfahrzeuges übertragen. Insbesondere bei Compactdiscs kann das geeignete Lesegerät 7 im Kraftfahrzeug durch ein Infotainmentsystem, wie es heute in Fahrzeugen eingesetzt wird, insbesondere durch ein CD-ROM-Laufwerk oder ein DVD-Laufwerk gebildet sein. Auch bei dem Ausführungsbeispiel nach Figur 2 wird im Fahrzeug der Downloadprozess durch ein spezielles Kommando von der Systemschnittstelle 4 eingeleitet. Hierzu hat die Systemschnittstelle 4 Zugriff auf die Datenbusse des Bordnetzes im Kraftfahrzeug. Mit einem Softwarekommando von der Systemschnittstelle wird das Einlesen der Flashware vom Lesegerät 7 in das Steuergerät 5 gestartet . Zugleich wird mit dem Softwarekommando der Flashspeicher des Steuergerätes 5 zur Übernahme der Flashware vorbereitet. Die Überprüfung des Authentifizierungscodes HMAC im Steuergerät wird weiter unten in den Figurenbeschreibungen zu Figur 5 und 6 näher erläutert . Im Prinzip müssen zur Überprüfung des Authentifizierungscodes die Berechnungsschritte, die zur Erstellung des Authentifizierungscodes notwendig waren, in der gleichen Reihenfolge wie im Trust-Center im Steuergerät wiederholt werden. Auch bei diesem Ausführungsbeispiel kann die Systemschnittstelle im einfachsten Fall durch einen Diagnoseanschluss im Kraftfahrzeug gebildet sein. Bevorzugterweise ist jedoch die Systemschnittstelle das Diagnosesystem in der Kraftfahrzeugwerk-
Die zuvor beschriebene Überprüfung des Authentifizierungscodes gilt unabhängig von der Wahl des Übertragungsweges für die Flashware. Der Authentifizierungsablauf ist beim Herunterladen der Flashware von CD-Rom oder DVD, der gleiche wie beim direkten Herunterladen der Flashware von einem Zentral- System mittels drahtloser oder drahtgebundener Datenübertragung.
Allen Ausführungsbeispielen der Erfindung gemeinsam, ist die Berechnung eines Hash-Wertes. Mit Hilfe der Hash-Funktion, bekannt unter der Bezeichnung RIPEMD-160-Algorithmus, kann zu beliebig langen Daten ein Prüfwert, ein sogenannter Abdruck, fester Länge erzeugt werden. Dieser Abdruck wird als Hash- Wert bezeichnet. Hash-Funktion und Hash-Wert erfüllen dabei die folgenden Eigenschaften:
■ Der Hash-Wert ist leicht zu berechnen.
■ Es ist praktisch nicht möglich, bei gegebenem Hash-Wert einen Datensatz zu erzeugen, der diesen Hash-Wert liefert
(Einwegfunktion) . Zudem ist es schwer, eine Kollision, d. h. zwei Datensätze mit dem gleichen Hash-Wert zu finden
(Kollisionsresistenz) . ■ Die Hash-Funktion kann nur für Daten bzw. Datensätze, deren Bitlänge maximal 264 - 1 ist, angewandt werden. Bei kürzeren Datensätzen werden die Datensätze mit Nullen aufgefüllt, bis die Länge de aufgefüllten Datensatzes ein ganzzahliges Vielfaches von 512 Bit hat. Der aufgefüllte Datensatz wird dann in mindestens 512 Bit-lange Blöcke aufgeteilt. Die Anwendung der Hash-Funktion auf die 512 Bit langen Blöcke ergibt schließlich einen 160 Bit langen Hash-Wert. Die Hash-Funktion kann hierbei auf beliebige Datensätze angewandt werden, insbesondere auch auf Flashware .
Figur 3 zeigt ein AblaufSchema zur Berechnung eines Authenti- fizierungscodes innerhalb eines gesicherten Bereiches 3, der im Folgenden als Trust-Center bezeichnet wird. Im Trust- Center werden in einem gesonderten, gesicherten Bereich, vorzugsweise einem gesonderten, gesicherten Datenspeicher 8, geheime Kennungen bzw. Identifizierungen in Form von Daten- strings in digitaler Form verwaltet. Die Flashware, für die ein Authentifizierungscode berechnet werden soll, wird zunächst an beiden Enden des Anwendungsprogramms mit einem Datenstring konkateniert. Das heißt, den digitalen Datensatz des Anwendungsprogramms wird am Anfang und am Ende ein geheimer Datenstring aus dem Speicher 8 des Trust-Centers angehängt. Im nächsten Schritt wird für die beidseitig konkatenierte Flashware ein Hash-Wert berechnet . Dieser Hash-Wert beinhaltet nun sämtliche Informationen über die Flashware sowie über den geheimen Datenstring. Durch die zuvor erläuterten Eigenschaften der Hash-Funktion ist dieser Hash-Wert als Authentifizierungscode HMAC für die Authentizität und die Datenintegrität der Flashware geeignet. In dem nächsten Schritt wird der Authentifizierungscode HMAC dem unverschlüsselten Anwendungsprogramm, der sogenannten Flashware, hinzugefügt und vom Trust-Center an die Systemschnittstelle zur weiteren Übertragung in das Kraftfahrzeug übermittelt .
Figur 4 zeigt einen aufwendigeren Ablauf zur Berechnung eines Authentifizierungscodes in einem Trust-Center. Bei diesem Ausführungsbeispiel wird die Flashware zunächst einseitig mit einem geheimen Datenstring konkateniert. Die Konkatenierung kann hierbei sowohl am Anfang oder auch am Ende des Datensatzes der Flashware erfolgen. Über die einseitig konkatenierte Flashware wird eine erste Hash-Wertberechnung durchgeführt . Man erhält einen ersten Hash-Wert HMAC1. Dieser erste Hash- wert HMAC1 wird wiederum einseitig mit einem geheimen Datenstring aus dem Speicher 8 konkateniert . Auch hier kann die Konkatenierung am Anfang oder am Ende des ersten Hashwerts erfolgen. In einem weiteren Schritt wird über das Gesamtgebilde aus geheimen Datenstring und erstem Hashwert eine zweite Hash-Wertberechnung durchgeführt . Das Ergebnis dieser letzten Hash-Wertberechnung ergibt den Authentifizierungscode HMAC. Sodann wird unverschlüsselte Original-Flashware zu dem Authentifizierungscode hinzugefügt und an die Systemschnittstelle übertragen. Das Ausführungsbeispiel der Figur 4 ist geeignet für einen Downloadprozess nach Figur 1.
Figur 5 zeigt ein Ablaufschema zur Berechnung eines Authenti- fizierungscodes innerhalb eines Trust-Centers zur Verwendung in dem Downloadprozess nach Figur 2. Im Trust-Center wird die unverschlüsselte Original-Flashware beidseitig mit einem geheimen Datenstring konkateniert . Im nächsten Schritt wird für die beidseitig konkatenierte Flashware eine Hash- Wertberechnung durchgeführt . Das Ergebnis dieser Hash- Wertberechnung ist der Authentifizierungscode HMAC. Im Unterschied zu dem Ausführungsbeispiel der Figur 3 wird bei dem Ausführungsbeispiel der Figur 5 lediglich der Authentifizierungscode an die Systemschnittstelle übertragen. Der Vertrieb der Original- und unverschlüsselten Flashware erfolgt hierbei auf getrennten Vertriebswegen. Die Flashware wird hierbei vorzugsweise auf hardwaremäßigen Speicherelementen übermittelt und in das Kraftfahrzeug eingelesen (näheres hierzu siehe Figur 2) .
Figur 6 zeigt ein weiteres Ausführungsbeispiel einer aufwendigeren Berechnung eines Authentifizierungscodes, wie er im Zusammenhang mit dem Downloadprozess nach Figur 2 Verwendung findet. Bei diesem Ausführungsbeispiel wird in dem Trust- Center die unverschlüsselte Flashware zunächst mit einem geheimen Datenstring einseitig konkateniert . Die Konkatenierung kann hierbei sowohl am Anfang als auch am Ende des Datensatzes der Flashware erfolgen. Über die einseitig konkatenierte Flashware wird eine Hash-Wertberechnung durchgeführt . Das Ergebnis ist ein erster Hash-Wert HMAC1. Dieser erste Hashwert HMAC1 wird wiederum einseitig mit einem geheimen Datenstring aus dem Speicher 8 konkateniert. Auch hier kann die Konkatenierung am Anfang oder am Ende des ersten Hashwerts erfolgen. In einem weiteren Schritt wird über das Gesamtgebilde aus geheimen Datenstring und erstem Hashwert eine zweite Hash- Wertberechnung durchgeführt. Das Ergebnis dieser letzten Hash-Wertberechnung ergibt den Authentifizierungscode HMAC. Dieser Authentifizierungscode wird an die Systemschnittstelle übermittelt. Im Unterschied zu dem Ausführungsbeispiel der Figur 4 wird bei dem Ausführungsbeispiel der Figur 6 lediglich der Authentifizierungscode an die Systemschnittstelle ü- bermittelt . Die unverschlüsselte Originalsoftware wird hierbei analog zur Figur 2 über Speichermedien, vorzugsweise Compactdiscs, in das Kraftfahrzeug eingelesen.
Anhand von Figur 7 wird im Folgenden auf den Flashprozess im Steuergerät bzw. im Mikroprozessorsystem des Kraftfahrzeuges näher eingegangen. Ein typisches Steuergerät, auch als Elect- ronic Control Unit ECU bezeichnet, enthält eine Recheneinheit, einen sogenannten Mikroprozessor CPU, der über einen Prozessorbus PBUS mit verschiedenen Speichern bzw. Speichersektoren verbunden ist. Über ein Interface kann das Steuergerät entweder von außen angesprochen werden oder mit anderen, an das Interface angeschlossenen Einheiten kommunizieren. Der Speicher des Steuergerätes besteht aus einem Boot-Sektor, einem Flashspeicher und einem Arbeitsspeicher RAM. Der Flashspeicher Flash ist ein elektrisch lösch- und programmierbarer Speicher, beispielsweise ein EEPROM. Im Boot-Sektor ist das Betriebssystem des Mikroprozessors, ein sogenannter Flash Boot Loader, sowie der RIPEMD-160-Algorithmus für die Hash- Funktion abgelegt. In einem, von äußeren Zugriffen besonders geschützten Speicher bzw. Speicherbereich ist in dem Steuergerät ein geheimer Datenstring abgelegt. Dieser besonders geschützte Datenbereich 9 kann auch im Boot-Bereich angeordnet sein. Eine andere Möglichkeit ist die Ausbildung dieses besonders geschützten Datenspeichers 9 in Form einer nicht überschreibbaren und vor unbefugtem Auslesen geschützten Speicherkarte oder in Form eines sogenannten Kryptoprozes- sors, der seinen Inhalt bei dem Versuch eines unberechtigten Zugriffs löscht. Durch diese Maßnahmen bzw. durch diese Ausbildung des besonders geschützten Speicherbereiches 9 wird die Geheimhaltung des darin abgespeicherten Datenstrings gesichert. Welche Datenstrings in den besonders geschützten Datenbereich 9 einprogrammiert werden, muss mit den Datenstrings zur Berechnung der Authentifizierungscodes im Trust- Center koordiniert werden. Der Datenstring im Steuergerät muss mit dem Datenstring, der zur Grundlage der Berechnung des Authentifizierungscodes diente, übereinstimmen.
In dem Flash des Steuergerätes sind die Anwendungsprogramme hinterlegt, die als Flashware aktualisiert werden können. Eine Überschreibung, bereits hinterlegter Anwenderprogramme durch neue Flashware, erfolgt grundsätzlich auf folgende Weise. Mit einem speziellen Softwarekommando, das von einer externen Systemschnittstelle über das Interface des Steuergerätes übertragen wird, wird das Steuergerät für einen Downloadprozess und für einen Flashprozess vorbereitet. Mit dem Softwarekommando wird der sogenannte Flash Boot Loader aktiviert. Der Flash Boot Loader ist im Wesentlichen eine Nachladeroutine, mit der Anwendungsprogramme in den Flashspeicher des Steuergerätes geschrieben werden. Beim Downloadprozess wird die neue Flashware und der übertragene Authentifizierungscode zunächst im Arbeitsspeicher des Steuergerätes zwischengespeichert. Dann wird, mit Hilfe der Nachladeroutine des Flash Boot Loaders, im Mikroprozessor des Steuergerätes die Überprüfung der zwischengespeicherten Flashware und des zwischengespeicherten Authentifizierungscodes auf Authentizität und Datenintegrität durchgeführt . Diese Überprüfung erfolgt derart, dass in dem Mikroprozessor mit der unverschlüsselten Software und dem im Steuergerät abgelegten geheimen Datenstring die gleichen Verfahrensschritte durchgeführt werden, die angewandt wurden, um den übertragenen Authentifizierungscode zu erzeugen. Es werden also im Mikroprozessor des Steuergerätes diejenigen Verfahrensschritte wiederholt, die im Trust-Center durchgeführt wurden, um den Authentifizierungscode zu erzeugen. Wurde z. B. der Authentifizierungscode nach dem Ausführungsbeispiel der Figur 3 erzeugt, so wird nun im Mikroprozessor des Steuergeräts die zwischengespeicherte Flashware beidseitig mit dem im Steuergerät abgelegten geheimen Datenstring konkateniert . Von der beidseitig konkatenierten Flashware wird mit dem RIPEMD-160-Algorithmus eine Hash- Wertberechnung durchgeführt. Das Ergebnis dieser Hash- Wertberechnung im Steuergerät wird mit dem übertragenen Identifizierungscode HMAC verglichen. Sind beide Hash-Werte identisch, so gilt die im Arbeitsspeicher zwischengespeicherte Flashware als authentisch und integer. Wurde der Authentifi- zierungscode im Trust-Center nach einem der Ausführungsbei- spiele entsprechend Figuren 3, 4, 5 oder 6 ermittelt, so müssen zur Überprüfung im Steuergerät bzw. im Mikroprozessor des Steuergeräts die Konkatenierungen der zwischengespeicherten Flashware mit dem im Steuergerät abgelegten geheimen Datenstring sowie die Hash-Wertberechnungen der konkatenierten Flashware in derjenigen Weise durchgeführt werden, wie sie jeweils im Trust-Center durchgeführt wurden, um den übermittelten Authentifizierungscode zu erzeugen. Ein Vergleich des Mikroprozessor des Steuergerätes ermittelten Hash-Werts mit dem übertragenen Authentifizierungscode gibt bei Übereinstimmung der beiden Werte jeweils eine Aussage zur Datenintegrität und Authentizität der übertragenen und im Arbeitsspeicher zwischengespeicherten Flashware. Stimmen beide Wert überein, gilt die Flashware jeweils als unbedenklich.
Nach erfolgreicher Überprüfung, der neu heruntergeladenen und zwischengespeicherten Flashware, schreibt der Flash Boot Loader die neue zwischengespeicherte Flashware in den Flashspeicher des Steuergerätes ein. Der Kopiervorgang von dem Arbeitsspeicher in den Flashspeicher kann hierbei zusätzlich mit einem zyklischen Blocksicherungsverfahren auf Vollständigkeit hin überprüft werden. War die Authentizitätsprüfung und der Kopiervorgang fehlerfrei, so wird für die nun im Flash befindliche Flashware ein sogenanntes Flag gesetzt. Dieses Flag kennzeichnet das nunmehr im Flash befindliche Anwendungsprogramm als das gültig zu verwendende Anwendungsprogramm. Das Flag kann hierbei wie in Figur 7 beispielhaft dargestellt z.B. im Flashspeicher selbst gesetzt werden, vorzugsweise ist der Flashspeicher als EEPROM ausgebildet. Das Steuergerät kann nun in die Anwendung gehen und wird dabei die mit einem gültigen Flag gekennzeichneten Anwendungsprogramme verwenden. Die Aktivierung des Flash Boot Loaders erfolgt vorzugsweise durch das Diagnosesystem in einer Werkstatt. In diesem Fall bildet das Diagnosesystem der Werkstatt die Systemschnittstelle 4. Im Fall des Downloadprozesses nach Figur 1 können unverschlüsselte Flashware sowie Authentifizierungscode zusammen von der Systemschnittstelle über das Interface in den Arbeitsspeicher des Steuergerätes zwischengespeichert werden. Im Falle des Downloadprozesses nach Figur 2 wird der Authentifizierungscode über die Systemschnittstelle in den Arbeitsspeicher des Steuergerätes zwischengespeichert, während die unverschlüsselte Flashware über ein weiteres Lesegerät, vorzugsweise ein CD-ROM-Laufwerk bzw. ein Chipkartenlesegerät, in den Arbeitsspeicher des Steuergerätes zwischengespeichert wird. Bei dem Downloadprozess nach Figur 2 muss deshalb die Nachladeroutine des Flash Boot Loaders die benötigten Datensätze ggf. von unterschiedlichen EDV-Systemen herunterladen. In allen Fällen jedoch, erfolgt die Kommunikation im Kraftfahrzeug über die kraftfahrzeuginternen Datenbusse. Ein heutzutage weit verbreiteter Datenbus im Kraftfahrzeug ist der sogenannte CAN-Bus .
Nicht alle Steuergeräte in einem Kraf fahrzeug haben genügend Speicherplatz, um eine Zwischenspeicherung der Flashware durchführen zu können. Bei Steuergeräten, bei denen der vorhandene Speicherbereich nicht ausreicht, um die herunterzuladende Flashware zwischen zu speichern, wird der Downloadprozess deshalb wie folgt durchgeführt :
Zunächst wird der vorhandene Flash Speicher gelöscht . - Dann wird die neue Flashware heruntergeladen und einprogrammiert .
- Dann wird die heruntergeladenen Flashware verifiziert, das heißt auf Übertragungsfehler überprüft.
Dann wird die Authentizitätsprüfung wie in den vorhergehenden Ausführungsbeispielen durchgeführt.
- Nach positiver Authentizitätsprüfung wird die heruntergeladene Flashware durch setzen eines Flags in Form eines Statusbits gekennzeichnet und aktiviert.
- Die folgenden Anwendungen greifen dann auf die neue Flashware zu.
Das direkte Herunterladen ohne Zwischenspeicherung der Flashware hat den zusätzlichen Vorteil einer „end-to-end"- Absicherung, da beim Schreibprozess während des Downloadprozesses auch Schreibfehler erkannt werden.
Bei allen Ausführungsbeispielen der Erfindung kann die Flashware um sogenannte Metainformationen ergänzt werden. Diese Flashware-Metainformation ist insbesondere eine Fahrzeugidentifizierungsnummer, eine Steuergerätesachnummer oder ein spezieller Speicherort für die Flashware. Durch Einbeziehung der Flashware-Metainformation lässt sich z. B. der Speicherort für die neu zu herunterladende Flashware auswählen. Dadurch dass die Flashware-Metainformation in die Berechnung des Authentifizierungscodes mit einbezogen ist, besteht auch ein Schutz gegenüber Manipulationen dieser Flashware- Metainformation.

Claims

Patentansprüche
Verfahren zum Laden von zumindest einem aktuellen Anwendungsprogramm (Flashware) , das in einem Programmspeicher (Flash) eines Mikroprozessorsystems (ECU) gespeichert wird, wobei an den Prozessorbus (PBUS)des Mikroprozessorsystems (ECU)
- mindestens ein Mikroprozessor (CPU) ,
- mindestens ein Programmspeicher mit einem Boot-Sektor, einem Flash Boot Loader, einem elektrisch löschbaren und programmierbaren Speicher (Flash) und einem Schreib-Lese- Speicher (RAM) , sowie mindestens eine Systemschnittstelle (Diagnose- Interface, Bordnetz-Interface) angeschlossen sind, und wobei
- für das Anwendungsprogramm (Flashware) ein Authentifi- zierungscode (HMAC) erstellt wird,
- der Authentifizierungscode (HMAC) und das aktuelle Anwendungsprogramm über die Systemschnittstelle eingelesen werden,
- und vor dem Aktivieren des eingelesenen aktuellen Anwendungsprogramms eine Überprüfung des an der Systemschnittstelle eingelesenen Authentifizierungscodes (HMAC) erfolgt, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode (HMAC) in einem gesicherten Bereich (Trust-Center) berechnet wird, indem das Anwendungsprogramm (Flashware) mit einem geheimen Datenstring (STRING) konkateniert wird und von dem konkate- nierten Anwendungsprogramm ein Hash-Wert berechnet wird, der als Authentifizierungscode (HMAC) an der Systemschnittstelle eingelesen wird, und dass im Mikroprozessorsystem ein zweiter, gleicher, geheimer Datenstring (STRING) abgelegt ist, mit dem das eingelesene Anwendungsprogramm (Flashware) im Mikroprozessorsystem konkateniert wird und von dem eingelesenen, konkatenierten Anwendungsprogramm im Mikroprozessor (CPU) ein Hash-Wert berechnet wird und mit dem übertragenen Authentifizierungscode (HMAC) verglichen wird.
Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm sowohl im gesicherten Bereich (Trust-Center) als auch bei der Authentizitätsprüfung im Mikroprozessor mit dem geheimen Datenstring am Programmanfang und am Programmende konkateniert und von dem beidseitig konkatenierten Anwendungsprogramm ein Hash-Wert berechnet wird, der als Authentifizierungscode (HMAC) an der Systemschnittstelle eingelesen wird.
Verfahren nach Anspruch 1, d a d u r c h g e k e n n z e i c h n e t ,
- dass das Anwendungsprogramm zunächst entweder am Pro- grammanfang oder am Programmende mit dem geheimen Datenstring (STRING) konkateniert wird,
- dass in einem folgenden Schritt von dem einseitig konkatenierten Anwendungsprogramm im gesicherten Bereich
(Trust-Center) ein erster Hash-Wert (HMAC1) berechnet wird,
- dass in einem weiteren folgenden Schritt der erste Hash-Wert (HMAC1) einseitig mit einem geheimen Datenstring (STRING) konkateniert wird,
- dass in einem weiteren folgenden Schritt von dem Gesamtgebilde aus erstem Hashwert (HMAC1) und geheimem Datenstring (STRING) ein zweiter Hash-Wert (HMAC) berechnet wird, der als Authentifizierungscode (HMAC) an der Sys- temschnittstelle eingelesen wird,
- und dass im Mikroprozessorsystem ein zweiter, gleicher, geheimer Datenstring (STRING) abgelegt ist, mit dem im Mikroprozessorsystem die im gesicherten Bereich (Trust- Center) durchgeführten Schritte mit dem ursprünglichen Anwendungsprogramm in gleicher Reihenfolge wiederholt werden,
- und der im Mikroprozessor berechnete Hash-Wert mit dem an der Systemschnittstelle eingelesenen Hash-Wert (HMAC) verglichen werden.
4. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode (HMAC) zusammen mit dem Anwendungsprogramm (Flashware) übermittelt wird.
5. Verfahren nach einem der Ansprüche 1 bis 3, d a d u r c. h g e k e n n z e i c h n e t , dass der Authentifizierungscode (HMAC) getrennt von dem Anwendungsprogramm (Flashware) übermittelt wird.
6. Verfahren nach Anspruch 5, d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm (Flashware) auf einem Speichermedium zwischengespeichert und mittels des Speichermediums vertrieben wird und der Authentifizierungscode (HMAC) mittels Datenübertragung vom gesicherten Bereich (Trust-Center) an die Systemschnittstelle übertragen wird.
7. Verfahren nach Anspruch 4 , d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm (Flashware) und der Authenti- fizierungscode (HMAC) mittels Datenübertragung vom gesicherten Bereich (Trust-Center) an die Systemschnittstelle übertragen werden.
8. Verfahren nach einem der Ansprüche 1 bis 7, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode über die Diagnoseschnittstelle (Diagnose Interface) in ein Steuergerät (ECU) eines Kraftfahrzeuges eingelesen wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, d a d u r c h g e k e n n z e i c h n e t , dass wenn ein eingelesener Authentifizierungscode (HMAC) und im Mikroprozessor berechneter Hash-Wert übereinstimmen, das zugehörige Anwendungsprogramm (Flashware) mit einer Kennung (Flag) als gültiges Anwendungsprogramm versehen wird.
10. Verfahren nach einem der Ansprüche 1 bis 9, d a d u r c h g e k e n n z e i c h n e t , dass in den Authentifizierungscode (HMAC) Flashware- Metainformation mit einbezogen wird.
11. Verfahren nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t , dass mit dem Authentifizierungscode (HMAC) der Downloadprozess des Anwendungsprogramms auf verschiedene Steuergeräte selektiert wird.
12. Verfahren zur Sicherstellung der Authentizität von Flashware für ein Steuergerät (ECU) eines Kraftfahrzeugs, indem in einem Programmspeicher (Flash) ein Anwendungsprogramm gespeichert ist, d a d u r c h g e k e n n z e i c h n e t , dass in einem gesicherten Bereich (Trust-Center) ein Authentifizierungscode (HMAC) berechnet wird, in dem das Anwendungsprogramm (Flashware) mit einem geheimen Datenstring (STRING) konkateniert wird und von dem konkatenierten Anwendungsprogramm ein Hash-Wert berechnet wird, der als Authentifizierungscode (HMAC) in das Steuergerät (ECU) eingelesen wird, und dass im Steuergerät (ECU) ein zweiter, gleicher, geheimer Datenstring (STRING) abgelegt ist, mit dem das eingelesene Anwendungsprogramm (Flashware) im Steuergerät konkateniert wird und von dem eingelesenen, konkatenierten Anwendungsprogramm im Steuergerät (ECU) ein Hash-Wert berechnet wird und mit dem übertragenen Authentifizierungscode (HMAC) verglichen wird.
13. Verfahren nach Anspruch 12, d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm sowohl im gesicherten Bereich (Trust-Center) als auch bei der Authentizitätsprüfung im Steuergerät (ECU) mit dem geheimen Datenstring am Programmanfang und am Programmende konkateniert und von dem beidseitig konkatenierten Anwendungsprogramm ein Hash- Wert berechnet wird, der als Authentifizierungscode (HMAC) an der Systemschnittstelle eingelesen wird.
14. Verfahren nach Anspruch 12, d a d u r c h g e k e n n z e i c h n e t ,
- dass das Anwendungsprogramm zunächst entweder am Pro- grammanfang oder am Programmende mit dem geheimen Datenstring (STRING) konkateniert wird,
- dass in einem folgenden Schritt von dem einseitig konkatenierten Anwendungsprogramm im gesicherten Bereich
(Trust-Center) ein erster Hash-Wert (HMAC1) berechnet wird,
- dass in einem weiteren folgenden Schritt der erste Hash-Wert (HMAC1) einseitig mit einem geheimen Datenstring (STRING) konkateniert wird,
- dass in einem weiteren folgenden Schritt von dem Gesamtgebilde aus erstem Hashwert (HMAC1) und geheimem Datenstring (STRING) ein zweiter Hash-Wert (HMAC) berechnet wird, der als Authentifizierungscode (HMAC) an der Systemschnittstelle eingelesen wird,
- und dass im Steuergerät (ECU) ein zweiter, gleicher, geheimer Datenstring (STRING) abgelegt ist, mit dem im Steuergerät (ECU) die im gesicherten Bereich (Trust- Center) durchgeführten Schritte mit dem ursprünglichen
Anwendungsprogramm in gleicher Reihenfolge wiederholt werden,
- und der im Steuergerät berechnete Hash-Wert mit dem an der Systemschnittstelle eingelesenen Hash-Wert (HMAC) verglichen werden.
15. Verfahren nach einem der Ansprüche 12 bis 14, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode (HMAC) zusammen mit dem Anwendungsprogramm (Flashware) übermittelt wird.
16. Verfahren nach einem der Ansprüche 12 bis 14, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode (HMAC) getrennt von dem Anwendungsprogramm (Flashware) übermittelt wird.
17. Verfahren nach Anspruch 16, d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm (Flashware) auf einem Speichermedium zwischengespeichert und mittels des Speichermediums vertrieben wird und der Authentifizierungscode (HMAC) mittels Datenübertragung vom gesicherten Bereich (Trust-Center) an die Systemschnittstelle übertragen wird.
18. Verfahren nach Anspruch 15, d a d u r c h g e k e n n z e i c h n e t , dass das Anwendungsprogramm (Flashware) und der Authenti- fizierungscode (HMAC) mittels Datenübertragung vom gesicherten Bereich (Trust-Center) an die Systemschnittstelle übertragen werden.
19. Verfahren nach einem der Ansprüche 12 bis 18, d a d u r c h g e k e n n z e i c h n e t , dass der Authentifizierungscode über die Diagnoseschnittstelle (Diagnose Interface) in ein Steuergerät (ECU) eines Kraftfahrzeuges eingelesen wird.
20. Verfahren nach einem der Ansprüche 12 bis 19, d a d u r c h g e k e n n z e i c h n e t , dass wenn ein eingelesener Authentifizierungscode (HMAC) und im Steuergerät berechneter Hash-Wert übereinstimmen, das zugehörige Anwendungsprogramm (Flashware) mit einer Kennung (Flag) als gültiges Anwendungsprogramm versehen wird.
21. Verfahren nach einem der Ansprüche 12 bis 20, d a d u r c h g e k e n n z e i c h n e t , dass in den Authentifizierungscode (HMAC) Flashware- Metainformation mit einbezogen wird.
22. Verfahren nach Anspruch 21, d a d u r c h g e k e n n z e i c h n e t , dass mit dem Authentifizierungscode (HMAC) der Downloadprozess des Anwendungsprogramms auf verschiedene Steuergeräte selektiert wird.
EP04717070A 2003-04-19 2004-03-04 Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte Withdrawn EP1616232A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10318031A DE10318031A1 (de) 2003-04-19 2003-04-19 Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
PCT/EP2004/002194 WO2004095238A1 (de) 2003-04-19 2004-03-04 Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte

Publications (1)

Publication Number Publication Date
EP1616232A1 true EP1616232A1 (de) 2006-01-18

Family

ID=33103521

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04717070A Withdrawn EP1616232A1 (de) 2003-04-19 2004-03-04 Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte

Country Status (5)

Country Link
US (1) US20070028115A1 (de)
EP (1) EP1616232A1 (de)
JP (1) JP2006524377A (de)
DE (1) DE10318031A1 (de)
WO (1) WO2004095238A1 (de)

Families Citing this family (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE388446T1 (de) * 2004-08-23 2008-03-15 Nokia Siemens Networks Gmbh Verfahren und anordnung zur vergebührung in einem peer-to-peer netzwerk
DE102006038428A1 (de) * 2006-08-17 2008-02-21 Bayerische Motoren Werke Ag Verfahren zur Programmierung eines Steuergerätes eines Kraftfahrzeugs
US20080101613A1 (en) * 2006-10-27 2008-05-01 Brunts Randall T Autonomous Field Reprogramming
DE102007049151B4 (de) * 2007-10-12 2014-05-28 Robert Bosch Gmbh Verfahren zur Durchführung einer automotiven Anwendung
DE102008008969B4 (de) * 2008-02-13 2022-07-14 Bayerische Motoren Werke Aktiengesellschaft Bordnetz-System eines Kraftfahrzeugs mit einer Authentifizierungs-Vorrichtung
DE102009045133A1 (de) 2009-09-29 2011-03-31 Robert Bosch Gmbh Verfahren zum Manipulationsschutz von Sensordaten und Sensor hierzu
KR101328167B1 (ko) * 2009-12-04 2013-11-13 한국전자통신연구원 차량의 소프트웨어 플랫폼 검증 방법 및 그 시스템
US8312137B1 (en) * 2010-01-04 2012-11-13 Google Inc. Live experiment framework
JP2012003679A (ja) * 2010-06-21 2012-01-05 Kyocera Mita Corp 画像形成装置用追加アプリケーションのセキュリティ確保方法、画像形成システム及び画像形成装置
WO2012043167A1 (ja) * 2010-09-27 2012-04-05 日本電気株式会社 情報処理システム、車両のチェック方法、及び、車両のチェックプログラム
DE102010038179B4 (de) * 2010-10-14 2013-10-24 Kobil Systems Gmbh Individuelle Aktualisierung von Computerprogrammen
DE102011109426A1 (de) 2011-08-04 2012-12-27 Daimler Ag Verfahren zur Erkennung von Datenänderungen in einem Steuergerät
JP6009290B2 (ja) * 2012-09-12 2016-10-19 株式会社ケーヒン 車両の電子制御装置
JP6181493B2 (ja) * 2013-09-20 2017-08-16 国立大学法人名古屋大学 書換検出システム、書換検出装置及び情報処理装置
CN104092725A (zh) * 2014-06-05 2014-10-08 潍柴动力股份有限公司 一种ecu刷写方法及客户端
JP6342281B2 (ja) * 2014-09-26 2018-06-13 国立大学法人名古屋大学 書換検出システム及び情報処理装置
CN104333576B (zh) * 2014-10-21 2019-03-19 普华基础软件股份有限公司 一种ecu升级装置及方法
US10402561B2 (en) * 2015-10-01 2019-09-03 Samsung Electronics Co., Ltd. Apparatus and method for protection of critical embedded system components via hardware-isolated secure element-based monitor
DE102016210786A1 (de) 2016-02-18 2017-08-24 Volkswagen Aktiengesellschaft Komponente zur Anbindung an einen Datenbus und Verfahren zur Umsetzung einer kryptografischen Funktionalität in einer solchen Komponente
KR101967755B1 (ko) * 2017-02-02 2019-04-10 주식회사 다산네트웍스 복사 플래시 사용 방지 기능을 구비한 ecu 부팅 시스템
US10491392B2 (en) * 2017-03-01 2019-11-26 Ford Global Technologies, Llc End-to-end vehicle secure ECU unlock in a semi-offline environment
ES2869256T3 (es) * 2017-10-23 2021-10-25 Siemens Ag Procedimiento y sistema de control para el control y/o la supervisión de dispositivos
DE102017222387A1 (de) * 2017-12-11 2019-06-13 Bayerische Motoren Werke Aktiengesellschaft Verfahren und System zum Autorisieren einer älteren Applikation eines Steuergeräts eines Fahrzeugs
US11030347B2 (en) 2019-03-14 2021-06-08 Hewlett Packard Enterprise Development Lp Protect computing device using hash based on power event
US11329983B2 (en) * 2019-03-25 2022-05-10 Micron Technology, Inc. Validating an electronic control unit of a vehicle
CN110109690B (zh) * 2019-07-02 2019-10-15 潍柴动力股份有限公司 一种ecu数据的刷写方法及系统
JP7234096B2 (ja) * 2019-11-01 2023-03-07 株式会社東芝 セキュリティ管理システム及びセキュリティ管理方法
DE102020200436A1 (de) * 2020-01-15 2021-07-15 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Erkennen einer Manipulation von Daten
JP7279668B2 (ja) * 2020-03-12 2023-05-23 トヨタ自動車株式会社 車載用制御装置
DE102021214183B3 (de) * 2021-12-13 2023-05-17 Continental Automotive Technologies GmbH Verfahren und Prozessorschaltung zum Absichern eines Codes gegen Manipulationen einer Anwendungssoftware, sowie Kraftfahrzeug-Steuergerät und Kraftfahrzeug mit einem solchen Steuergerät

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4315732C1 (de) * 1993-05-11 1994-06-01 Siemens Nixdorf Inf Syst Verfahren zum authentischen Booten und Testen der Integrität von Software auf PC-Architekturen
US6079021A (en) * 1997-06-02 2000-06-20 Digital Equipment Corporation Method and apparatus for strengthening passwords for protection of computer systems
US6272631B1 (en) * 1997-06-30 2001-08-07 Microsoft Corporation Protected storage of core data secrets
JP2001184472A (ja) * 1999-12-27 2001-07-06 Hitachi Ltd アプリケーションプログラムの供給方法、スマートカード、スクリプト供給方法、端末装置およびアプリケーションプログラムを有する記憶媒体
DE10008974B4 (de) * 2000-02-25 2005-12-29 Bayerische Motoren Werke Ag Signaturverfahren
US7562220B2 (en) * 2004-11-15 2009-07-14 Microsoft Corporation System and method for programming an isolated computing environment

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MENEZES A.J. ET AL, HANDBOOK OF APPLIED CRYPTOGRAPHY, CHAPT. 9, 1 October 1996 (1996-10-01), pages 321 - 383, XP001525009, ISBN: 978-0-8493-8523-0, Retrieved from the Internet <URL:http://www.cacr.math.uwaterloo.ca/hac/> *
See also references of WO2004095238A1 *

Also Published As

Publication number Publication date
US20070028115A1 (en) 2007-02-01
DE10318031A1 (de) 2004-11-04
WO2004095238A1 (de) 2004-11-04
JP2006524377A (ja) 2006-10-26

Similar Documents

Publication Publication Date Title
WO2004095238A1 (de) Verfahren zur sicherstellung der integrität und authentizität von flashware für steuergeräte
DE10008974B4 (de) Signaturverfahren
EP1127756B1 (de) Autorisierungsverfahren mit Zertifikat
DE102015209116A1 (de) Verfahren und Aktualisierungsgateway zum Aktualisieren eines eingebetteten Steuergerätes
EP3136285B1 (de) Verfahren und speichermodul für sicherheitsgeschützte schreibvorgänge und/oder lesevorgänge auf dem speichermodul
EP1883906B1 (de) Tragbarer datenträger mit sicherer datenverarbeitung
DE102012109617A1 (de) Verfahren zum Ersetzen eines öffentlichen Schlüssels eines Bootloaders
DE102016221108A1 (de) Verfahren zum Aktualisieren einer Software eines Steuergeräts eines Fahrzeugs
DE112020001061T5 (de) Verschlüsselte gang-programmierung
EP3337085B1 (de) Nachladen kryptographischer programminstruktionen
EP3552344B1 (de) Bidirektional verkettete blockchainstruktur
EP1273994A2 (de) Verfahren zum Schutz eines Mikrorechner-Systems gegen Manipulation von in einer Speicheranordnung des Mikrorechner-Systems gespeicherten Daten
DE102005031611B4 (de) Nachweis einer Veränderung der Daten eines Datensatzes
EP3811260B1 (de) Kryptografiemodul und betriebsverfahren hierfür
EP1661069B1 (de) Prozessorschaltung und verfahren zum zuordnen eines logikchips zu einem speicherchip
DE10316951A1 (de) Verfahren zur Überprüfung der Datenintegrität von Software in Steuergeräten
WO2004114131A1 (de) Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
DE102018211139A1 (de) Steuergerät sowie Verfahren zu dessen Betrieb
EP1482453A2 (de) Verfahren zum Laden von Daten in eine Speichereinrichtung
EP1529257B1 (de) Übernehmen eines datensatzes in eine recheneinheit
DE102021126509B4 (de) Tragbare Chipvorrichtung und Verfahren zum Ausführen eines Softwaremodul-Updates in einer tragbaren Chipvorrichtung
DE10215626B4 (de) Verfahren zur Änderung von Verschlüsselungsalgorithmen bei geschützter Software oder geschützten Daten
DE102020206066A1 (de) Aktualisierungsmodul für einen programmierbaren Digitalbaustein
EP4275138A1 (de) Verfahren zur überprüfung digitaler signaturen, fahrzeug-recheneinheit und fahrzeug
DE102022200544A1 (de) Verfahren zur abgesicherten Bereitstellung eines zu schützenden Computerpro-gramms in einer Recheneinheit

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20051006

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
RBV Designated contracting states (corrected)

Designated state(s): DE

RIN1 Information on inventor provided before grant (corrected)

Inventor name: WIESER, EVA

Inventor name: SORG, MICHAEL

Inventor name: SCHNEIDER, JUTTA

Inventor name: KOBER, HEIKO

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DAIMLERCHRYSLER AG

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: DAIMLER AG

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

17Q First examination report despatched

Effective date: 20120127

18W Application withdrawn

Effective date: 20120214