EP1636700A1 - Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher - Google Patents

Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher

Info

Publication number
EP1636700A1
EP1636700A1 EP04730255A EP04730255A EP1636700A1 EP 1636700 A1 EP1636700 A1 EP 1636700A1 EP 04730255 A EP04730255 A EP 04730255A EP 04730255 A EP04730255 A EP 04730255A EP 1636700 A1 EP1636700 A1 EP 1636700A1
Authority
EP
European Patent Office
Prior art keywords
software
key
signature
boot sector
reloading
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.)
Ceased
Application number
EP04730255A
Other languages
English (en)
French (fr)
Inventor
Burkhard Kuhls
Thomas Kalverkamp
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.)
Bayerische Motoren Werke AG
Original Assignee
Bayerische Motoren Werke 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
Priority claimed from DE10357032A external-priority patent/DE10357032A1/de
Application filed by Bayerische Motoren Werke AG filed Critical Bayerische Motoren Werke AG
Publication of EP1636700A1 publication Critical patent/EP1636700A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time

Definitions

  • the invention relates to a method for reloading update software into a writable memory area in the boot sector of a programmable control device of a vehicle.
  • DE 100 00 8974 A1 discloses a method for reloading software into a writable memory area of a programmable control device of a vehicle, the software to be imported being transferred to the control device using a public key method using a first key of a complementary key pair is signed against tampering and the signed software to be imported after its transmission into the control device is checked for its authenticity by using a second key of the key pair.
  • the signature process is used to prevent software from being reloaded into the control unit in an uncontrolled manner.
  • this method presupposes that a security mechanism is present in the control unit, which carries out the aforementioned check of the signed software to be imported. To provide effective security, this security mechanism itself must be protected against unauthorized interference.
  • said security mechanism is usually embedded in the boot sector of the control device and the boot sector is generally protected against subsequent software changes.
  • the boot sector can be embedded in a changeable non-volatile, for example flashable, memory chip. Then the boat sector must be secured in another way against unauthorized access.
  • the object of the present invention is to provide a method for reloading update software into a writable memory area of a boot second.
  • Provide gate of a programmable control device of a vehicle that overcomes the disadvantages mentioned, in particular makes it possible to also be able to update security device-side security mechanisms in the boot area in a secure manner.
  • a method which comprises the following steps: providing a reloading software which can be loaded into a writable memory area of the programmable control device located outside the boot sector and which is capable of installing the update software in the writable memory area in the control device to control the boot sector, loading the reloading software and the update software into the writable storage area located outside the boot sector, executing the reloading software in the control unit for installing the update software in the writable storage area of the boot sector.
  • the basic idea of the present invention is to design the boot area by known mechanisms in such a way that it cannot be accessed directly, but only by means of a reloading software provided for this purpose.
  • the execution of the reloading software by means of which the actual installation of the update software in the boot area is controlled, can then be made dependent on suitable security criteria, from which particularly preferred subject matter of the dependent claims.
  • the reloading software can only be executed in compliance with the security mechanisms already present in the control unit for reloading applications into the control unit.
  • the reloading software can also be used to introduce new security mechanisms into the control unit that update or supplement the security mechanisms present in the control unit. Reloading the update software can thus be secured by newly introduced security mechanisms.
  • Reloading and update software can in principle be loaded separately into the control unit; however, it is usually cheaper if the update software is included in the reloading software, as this is the complexity in advance of the reloading process increases without complicating the actual reloading process and thus increases the level of security of the overall concept without reducing the user-friendliness.
  • a particularly favorable variant of the method according to the invention is characterized in that a signature method is applied to at least part of the reloading software and / or the update software, the software signing using a first signature key before it is transferred to the control unit and after it has been transferred to the control unit is checked for authenticity by means of a second signature key stored in the control unit.
  • a signature method is applied to at least part of the reloading software and / or the update software, the software signing using a first signature key before it is transferred to the control unit and after it has been transferred to the control unit is checked for authenticity by means of a second signature key stored in the control unit.
  • the second signature key is preferably stored in the writable memory area of the boot sector. This enables a secure and internal control unit test. After successful signature verification, the signature key can itself be the subject of the update of the boot area.
  • An asymmetrical signature method can be used for signing and signature verification, the first and second signature keys forming a complementary key pair.
  • Such an asymmetrical process is, for example, the so-called public key process.
  • a symmetrical signature method is used, the first and the second signature key being identical.
  • the reloading software and / or the update software are encrypted by means of an encryption key before being transferred to the control unit and by decoding software after being transferred to the control unit by means of a decision stored in the control unit encryption key is decrypted.
  • This is particularly advantageous if the actual information to be used in the boot area, ie the update software or its essential parts, belong to the encrypted software part. In this way it can be ensured that unauthorized persons cannot obtain knowledge of the new data, which is particularly important if, for example, a key stored in the boot area is to be exchanged or updated.
  • the decryption key is stored in the writable memory area of the boot sector. This enables a secure and internal control unit test. After successful decryption, the decryption key can itself be the subject of the update of the boot area.
  • an asymmetrical encryption method can be used, the encryption key and the decryption key forming a complementary key pair.
  • a symmetrical encryption method is used, the encryption key and the decryption key being identical.
  • the decryption software is advantageously contained in the reloading software and is loaded into the control unit together with this and possibly the update software.
  • the advantage lies in the increase in the degree of complexity of the overall system and thus in the increase in security, without the user friendliness or the device complexity having to be increased.
  • the same key is used for signing and encryption or for signature verification and decryption, ie only one key in the symmetrical case and only one in the asymmetrical case complementary key pair.
  • different key pairs of identical or complementary keys are used for the signature method and for encryption and decryption.
  • the method according to the invention makes it possible to update data in the boot area, which can also include keys for special security mechanisms stored there, in a secure manner. Control units affected by "bit tilting" in the boat sector can also be refreshed by reloading memory contents that have been lost.
  • FIG. 1 a schematic representation of a programmable control unit with its memory assignments a) before the method according to the invention is carried out, b) after the method according to the invention has been carried out,
  • FIG. 2 a schematic representation of the method steps of an exemplary embodiment of the method according to the invention
  • FIG. 3 a schematic representation of process steps following the process steps from FIG. 2.
  • the exchange of an existing crypto key in the boot sector is described below as an example.
  • the term crypto key refers here to digital keys used for signing / signature verification as well as for encryption / decryption.
  • the new key should not be transmitted in plain text, but rather only in encrypted form, and the reloading software should also be protected against falsification by means of a signature process.
  • a symmetrical method is used in the exemplary embodiment shown.
  • the same symmetrical key is used in the exemplary embodiment shown for the signature / signature check and the encryption / decryption.
  • Figure 1 shows a schematic drawing of a programmable control unit 1 with memory assignments according to the embodiment.
  • Figure 1a relates to the state before the method according to the invention is carried out: the control device comprises a writable memory area 10 and a writable boot sector area 20.
  • a memory program 10 stores a control program 11 which controls the original functions of the control device when the vehicle is operating.
  • the boot sector area 20 there is a crypto key 21. This is to be replaced by a crypto key 22, the memory area 10 again containing the control program 11 after the method (FIG. 1b) has been completed.
  • FIG. 2 shows process steps for the secure insertion of the new crypto key 22 in a schematic drawing.
  • signed reloading software 123 is generated by assembling the components and then signing.
  • the crypto key 22 i.e. the essential part of the update software
  • the key used here is to be selected such that a key 21 suitable for decryption is present in the control unit 1.
  • the crypto key 21 is also used for this and the encrypted update software 111 is thus generated.
  • another key could be used for asymmetrical encryption instead of the key 21, for which a suitable complementary key is present in the control unit.
  • the encryption of the update software is used to secure the reloading process against unauthorized read access and to prevent future unauthorized write interventions. However, it is not a mandatory feature of the present invention.
  • the encrypted update software 111 is signed to secure it against falsification.
  • this is done together with an application 121.
  • the application 121 contains decryption software 122 suitable for decrypting the update software 111 in order to enable decryption in the control unit. If decryption software is already available in the control unit, it can be used and reloading of decryption software can be dispensed with.
  • the key used to calculate the signature is in turn selected so that a key suitable for signature verification is present in the control unit. In the exemplary embodiment shown, in which a symmetrical method is selected, signature calculation and signature verification are carried out using the same key 21.
  • asymmetrical procedure is only effective if the key used for this can be kept secret.
  • an asymmetrical method for example a public key method, can also be used.
  • the key used to calculate the signature must be selected so that a key suitable for signature verification is present in the control unit. If, for example, key 21 is used to check the signature of an asymmetrical method, the signature calculation in method step 120 would be carried out with a key that is complementary to key 21.
  • a second main step 200 the control unit is loaded with the reloading software 123.
  • the control unit is first stored in the memory area 10, replacing the control program 11 in the example shown. It is not absolutely necessary to overwrite previously existing data in order to carry out the method according to the invention, but in practice it is a frequently occurring necessity: programmable control units are generally designed for the operationally necessary applications with regard to the available memory size for cost reasons, and storage provision for Reloading software 123 does not take place. In order to be able to load these to carry out the method according to the invention, in practice, data which is already available usually has to be overwritten due to the limited storage space available.
  • step 220 This is followed by a signature check in step 220, in the example shown using the key 21. Possible alternatives have already been pointed out in the commentary on step 120.
  • the control unit rejects the reloaded software so that it cannot be operated in the control unit. In particular then no changes have been made in the boat sector, and the control unit is protected against unauthorized interference. Alternatively, only a user warning could be triggered. If, on the other hand, the signature check is positive, the encrypted update software 111 and the reloading software 121 are executable in the memory area 10 of the control unit.
  • a security mechanism other than a signature check can also be used to secure the second main step 200, for example a certificate-based method or an encryption method.
  • hedging can also be dispensed with entirely. In this case, however, the software to be reloaded is not protected against unauthorized interventions.
  • the transfer of reloading software and update software into the control unit can also comprise separate steps. This is particularly useful if, in an installation step that is to be carried out first, a safety mechanism is introduced and activated in the control device, which serves to secure a step to be carried out later.
  • the new key 22 is stored in the place of the old key 21 by executing the reloading software 121, 122.
  • the decryption software 122 contained in the reloading software 121 is used to restore the new key in plain text form 22, which was previously only transmitted in encrypted form 111, and in the subsequent sub-step 320 in the boot sector 20 it is stored in the place of the previous key 21 ,
  • step 400 the software to be reloaded, including control program 11, is prepared for this purpose.
  • step 400 consists of Significant in the signing of the control program 11. Changes to the security mechanisms in the boot sector that have been made in the previous procedural steps must be taken into account. If, for example, in addition to or instead of exchanging the keys 21, 22, there was a change in the security mechanism, for example changes in the key length or the replacement of a symmetrical signature method by an asymmetrical signature method or a certificate-based method, the software to be reloaded would have to be oriented to this new security mechanism ,
  • a symmetrical method is maintained and key 22 is used for the signature calculation in step 400.
  • key 22 is used for the signature calculation in step 400.
  • another key present in the control unit can also be used.
  • control device is loaded with the control software 11, taking into account the update of the security mechanisms in the boot sector of the control device.
  • it is transmitted in a signed form and stored in memory area 10 in step 510, specifically in place of the reloading software 121.
  • the imported software in the example shown a signature check, is now carried out using the key 22. Possible alternatives were already pointed out in the comment to step 400.
  • the control software 11 is now executable in the memory area 10 of the control device. Overall, the target state shown in FIG. 1b has been reached. If the required good result was not achieved during the signature check, this would indicate that the target state shown in FIG. 1b has been missed, i.e. either the boot sector was not successfully updated or an undesired data change occurred when the control software 11 was reintroduced.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung bezieht sich auf ein Verfahren zum Nachladen einer Updatesoftware (22) in einen beschreibbaren Speicherbereich (20) eines Bootsektor eines programmierbaren Steuergerätes (1) eines Fahrzeugs, umfassend die folgenden Schritte: Bereitstellen einer in einen ausserhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10) des programmierbaren Steuergerätes (1) ladbaren Nachladesoftware (121, 122, 123), die in der Lage ist, im Steuergerät (1) die Installation der Updatesoftware (22) in den beschreibbaren Speicherbereich (20) des Bootsektor zu steuern, Laden der Nachladesoftware (121, 122, 123) und der Updatesoftware (22) in den ausserhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10), Ausführen der Nachladesoftware (121, 122, 123) im Steuergerät zur Installation der Update-Software (22) in den beschreibbaren Speicherbereich (20) des Bootsektors.

Description

Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
Die Erfindung bezieht sich auf ein Verfahren zum Nachladen einer Updatesoftware in einen beschreibbaren Speicherbereich im Bootsektor eines programmierbaren Steuergeräts eines Fahrzeugs.
Aus DE 100 00 8974 A1 ist ein Verfahren zum Nachladen von Software in einen beschreibbaren Speicherbereich eines programmierbaren Steuergeräts eines Fahrzeugs bekannt, wobei die einzuspielende Software vor ihrer Übertragung in das Steuergerät mit Hilfe eines Public-Key-Verfahrens unter Verwendung eines ersten Schlüssels eines komplementären Schlüsselpaars gegen Verfälschung signiert wird und die signierte einzuspielende Software nach ihrer Übertragung in das Steuerge- rät durch dieses unter Verwendung eines zweiten Schlüssels des Schlüsselpaars auf ihre Unverfälschtheit hin überprüft wird.
Das Signaturverfahren dient dazu, zu verhindern, dass in das Steuergerät unkontrolliert Software nachgeladen werden kann. Dieses Verfahren setzt jedoch voraus, dass im Steuergerät ein Sicherheitsmechanismus vorhanden ist, der die genannte Überprüfung der signierten einzuspielenden Software durchführt. Um wirksame Sicherheit zu bieten, ist dieser Sicherheitsmechanismus selbst gegen unbefugte Eingriffe zu schützen.
Hierzu wird besagter Sicherheitsmechanismus üblicherweise in den Bootsektor des Steuergeräts eingebettet und der Bootsektor generell gegen nachträgliche Software- Änderungen geschützt.
Häufig geschieht dieses dadurch, dass der Bootsektor in einem nicht beschreibba- ren Speicherbereich (ROM) des Steuergeräts angesiedelt ist. Der Speicherinhalt kann nachträglich nicht mehr verändert werden und ist insoweit gegen unbefugte Eingriffe gesichert.
Dies hat den Nachteil, dass der Bootsektor auch für befugte Eingriffe unzugänglich ist. So können in einem solchen Steuergerät weder Programmierfehler behoben, noch Sicherheitsmechanismen aktualisiert oder eventuell bekannt gewordene Schlüssel ausgetauscht werden. Auch besteht keine Möglichkeit zur Wiederherstellung des Bootsektors nach Veränderungen, die durch unkontrollierte physikalische Einwirkungen oder Alterungseffekte ausgelöst wurden, so genanntes „Bit-Kippen". Somit ist zur Einspielung von Software in den Bootsektor eines solchen Steuergeräts das bekannte Verfahren nicht anwendbar.
Um diesen Nachteil zu überwinden, kann der Bootsektor in einem veränderbaren nicht-flüchtigen, beispielsweise flashbaren, Speicherbaustein eingebettet werden. Dann muss der Bootsektor jedoch auf andere Weise gegen unbefugte Eingriffe gesichert werden.
Hierfür bekannte Schutzmechanismen sind jedoch unbefriedigend. Beispielsweise ist aus US 005,937,063 A ein Verfahren bekannt, bei dem eine Boot-Up-Firmware, beispielsweise BIOS, gegen unautorisierten Eingriff dadurch geschützt wird, dass sie in einer gesicherten Boot-Vorrichtung eingebettet ist. Diese interagiert während des Bootens mit einem Host-Prozessor, wobei Boot-Up-Instruktionen ver- und entschlüsselt werden unter Verwendung eines geheimen Schlüssels, den die gesicher- te Boot-Vorrichtung und der Host-Prozessor gemeinsam nutzen. Jenes sehr komplexe Verfahren ist für Steuergeräte in einem Fahrzeug zu langwierig, kostenaufwendig und insgesamt ungeeignet. Außerdem bleibt die Aufgabenstellung ungelöst, den steuergeräteseitigen Sicherheitsmechanismus, etwa besagten geheimen Schlüssel, aktualisieren zu können.
Aus US 005,825,878 A ist ein anderes Verfahren bekannt, bei dem die Übertragung von Instruktionen und Daten in ein Steuergerät in verschlüsselter Form erfolgt und hierfür verwendete Sicherheitsmechanismen steuergeräteseitig wenigstens teilweise in einer physikalisch gesicherten Einheit eingebettet sind. Auch dort bleibt die Auf- gabenstellung ungelöst, den steuergeräteseitigen Sicherheitsmechanismus, etwa einen geheimen Schlüssel, aktualisieren zu können.
Die Aufgabe der vorliegenden Erfindung besteht darin, ein Verfahren zum Nachladen einer Updatesoftware in einen beschreibbaren Speicherbereich eines Bootsek- tor eines programmierbaren Steuergeräts eines Fahrzeugs bereitzustellen, das die genannten Nachteile überwindet, es insbesondere ermöglicht, auch steuergerätesei- tige Sicherheitsmechanismen im Bootbereich auf gesicherte Weise aktualisieren zu können.
Diese Aufgabe wird gemäß Anspruch 1 durch ein Verfahren gelöst, welches die folgenden Schritte umfasst: Bereitstellen einer in einen außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich des programmierbaren Steuergerätes ladbaren Nachladesoftware, die in der Lage ist, im Steuergerät die Installation der Updatesoftware in den beschreibbaren Speicherbereich des Bootsektor zu steuern, Laden der Nachladesoftware und der Updatesoftware in den außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich, Ausführen der Nachladesoftware im Steuergerät zur Installation der Update-Software in den beschreibbaren Speicherbereich des Bootsektors.
Die Grundidee der vorliegenden Erfindung besteht darin, den Bootbereich durch bekannte Mechanismen so zu gestalten, dass auf ihn nicht direkt, sondern nur mittels einer eigens hierfür vorgesehenen Nachladesoftware zugegriffen werden kann. Die Ausführung der Nachladesoftware, durch welche die eigentliche Installation der Updatesoftware im Bootbereich gesteuert wird, kann dann von geeigneten Sicherheitskriterien abhängig gemacht werden, von denen besonders bevorzugte Gegenstand der abhängigen Ansprüche sind.
Beispielsweise kann vorgesehen sein, dass die Ausführung der Nachladesoftware nur unter Beachtung bereits im Steuergerät vorhandener Sicherheitsmechanismen für das Nachladen von Applikationen in das Steuergerät ermöglicht wird. Andererseits können auch mit der Nachladesoftware neue Sicherheitsmechanismen in das Steuergerät eingebracht werden, die die im Steuergerät vorhandenen Sicherheitsmechanismen aktualisieren oder ergänzen. Damit kann das Nachladen der Update- Software durch neu eingeführte Sicherheitsmechanismen abgesichert werden.
Nachlade- und Updatesoftware könne grundsätzlich zwar getrennt voneinander in das Steuergerät geladen werden; meist ist es jedoch günstiger, wenn die Updatesoftware in der Nachladesoftware enthalten ist, da dies die Komplexität im Vorfeld des Nachladevorgangs erhöht ohne den eigentlichen Nachladevorgang zu erschweren und somit den Sicherheitsgrad des Gesamtkonzeptes steigert ohne die Anwenderfreundlichkeit zu reduzieren.
Eine besonders günstige Variante des erfindungsgemäßen Verfahrens zeichnet sich dadurch aus, dass wenigstens auf einen Teil der Nachladesoftware und/oder der Updatesoftware ein Signaturverfahren angewendet wird, wobei die Software vor ihrer Übertragung in das Steuergerät mittels eines ersten Signaturschlüssels signiert und nach ihrer Übertragung in das Steuergerät mittels eines zweiten, im Steuergerät abgelegten Signaturschlüssels, auf ihre Unverfälschtheit hin überprüft wird. Damit kann sichergestellt werden, dass nur vom Inhaber des ersten Signaturschlüssels genehmigte und nach Signierung nicht weiter modifizierte Nachladesoftware im Steuergerät ausgeführt werden kann. Bei Scheitern der Signaturprüfung kann beispielsweise die konkrete Ausführung der Nachladesoftware unterbunden werden; alternativ ist es jedoch auch möglich bereits das Laden der Nachladesoftware in das Steuergerät von einer erfolgreichen Signaturprüfung abhängig zu machen. Vorzugsweise ist der zweite Signaturschlüssel in dem beschreibbaren Speicherbereich des Bootsektors abgelegt. Damit wird eine gesicherte und Steuergeräteinterne Prüfung ermöglicht. Nach erfolgreicher Signaturprüfung kann der Signatur- Schlüssel auch selbst Gegenstand der Aktualisierung des Bootbereichs sein.
Zur Signierung und Signaturprüfung kann ein asymmetrisches Signaturverfahren angewendet werden, wobei der erste und der zweite Signaturschlüssel ein komplementäres Schlüsselpaar bilden. Ein derartiges asymmetrisches Verfahren ist bei- spielsweise das sog. Public-Key-Verfahren. Bei einer alternativen Variante des erfindungsgemäßen Verfahrens wird ein symmetrisches Signaturverfahren angewendet, wobei der erste und der zweite Signaturschlüssel identisch sind.
Zusätzlich oder alternativ zu dem oben erläuterten Signaturverfahren kann bei einer besonders vorteilhaften Weiterbildung des erfindungsgemäßen Verfahrensvorgesehen sein, dass wenigstens ein Teil der Nachladesoftware und/oder der Updatesoftware vor der Übertragung in das Steuergerät mittels eines Verschlüsselungsschlüssels verschlüsselt und nach der Übertragung in das Steuergerät von einer Entschlüsselungssoftware mittels eines in dem Steuergerät abgelegten Entschlüsse- lungsschlüssels entschlüsselt wird. Dies ist insbesondere günstig, wenn die eigentlichen, im Bootbereich einzusetzenden Informationen, d.h. die Updatesoftware bzw. deren wesentliche Anteile zu dem verschlüsselten Softwareteil gehören. Dadurch kann nämlich sichergestellt werden, dass Unbefugte keine Kenntnis von den neuen Daten erhalten können, was insbesondere Wichtig ist, wenn beispielsweise ein im Bootbereich abgelegter Schlüssel ausgetauscht oder aktualisiert werden soll.
Vergleichbar dem oben erläuterten Signaturverfahren wird bevorzugt, dass der Entschlüsselungsschlüssel in dem beschreibbaren Speicherbereich des Bootsektors abgelegt ist. Damit wird eine gesicherte und Steuergeräte-interne Prüfung ermöglicht. Nach erfolgreicher Entschlüsselung kann der Entschlüsselungsschlüssel auch selbst Gegenstand der Aktualisierung des Bootbereichs sein.
Ebenfalls vergleichbar dem oben erläuterten Signaturverfahren kann ein asymmetri- sches Verschlüsselungsverfahren angewendet werden, wobei der Verschlüsselungsschlüssel und der Entschlüsselungsschlüssel ein komplementäres Schlüsselpaar bilden. Alternativ kann auch vorgesehen sein, dass ein symmetrisches Verschlüsselungsverfahren angewendet wird, wobei der Verschlüsselungsschlüssel und der Entschlüsselungsschlüssel identisch sind.
Vorteilhafterweise ist die Entschlüsselungssoftware in der Nachladesoftware enthalten und wird gemeinsam mit dieser und ggf. der Updatesoftware in das Steuergerät geladen. Der Vorteil liegt in der Erhöhung des Komplexitätsgrades des Gesamtsystems und somit in der Steigerung der Sicherheit, ohne dass die Benutzerfreundlich- keit litte oder die Gerätekomplexität erhöht werden müsste.
Bei Systemen mit Signatur und Verschlüsselung wenigstens von Teilen der Nachlade- und/oder der Updatesoftware ist wird im einfachsten Fall für Signierung und Verschlüsselung bzw. für Signaturprüfung und Entschlüsselung derselbe Schlüssel verwendet, d.h. im symmetrischen Fall insgesamt nur ein Schlüssel und im asymmetrischen Fall nur ein komplementäres Schlüsselpaar. Alternativ kann jedoch auch vorgesehen sein, dass für das Signaturverfahren und für die Ver- und Entschlüsselung unterschiedliche Schlüsselpaare von identischen oder komplementären Schlüsseln verwendet werden. Durch das erfindungsgemäße Verfahren wird es möglich, Daten im Bootbereich, die z.B. auch dort hinterlegte Schlüssel für spezielle Sicherheitsmechanismen umfassen können, auf gesicherte Weise zu aktualisieren. Auch durch „Bit-Kippen" im Bootsek- tor beeinträchtigte Steuergeräte können durch Nachladen verloren gegangener Speicherinhalte wieder aufgefrischt werden.
Weitere Vorteile der Erfindung ergeben sich aus der nachfolgenden, speziellen Beschreibung sowie den Zeichnungen. Es zeigen:
Figur 1 : eine schematische Darstellung eines programmierbares Steuergerät mit seinen Speicherbelegungen a) vor Durchführung des erfindungsgemäßen Verfahrens, b) nach Durchführung des erfindungsgemäßen Verfahrens,
Figur 2: eine schematische Darstellung der Verfahrensschritte eines Ausführungsbeispiels des erfindungsgemäßen Verfahrens,
Figur 3: eine schematische Darstellung von sich an die Verfahrensschritte von Fig. 2 anschließenden Verfahrensschritten.
Beispielhaft wird nachstehend der Austausch eines im Bootsektor vorhandenen Kryptoschlüssels dargelegt. Die Bezeichnung Kryptoschlüssel bezieht sich hier sowohl auf zur Signierung/Signaturprüfung als auch zur Ver-/Entschlüsselung verwen- dete, digitale Schlüssel. In dem gewählten Ausführungsbeispiel soll der neue Schlüssel nicht im Klartext, sondern nur verschlüsselt in das Steuergerät übertragen und die Nachladesoftware außerdem mittels eines Signaturverfahrens gegen Verfälschungen geschützt werden. In beiden Fällen wird im gezeigten Ausführungsbeispiel ein symmetrisches Verfahren angewendet. Insbesondere wird in dem gezeig- ten Ausführungsbeispiel für die Signierung/Signaturprüfung und die Ver- /Entschlüsselung derselbe symmetrische Schlüssel verwendet.
Figur 1 zeigt in einer Schemazeichnung ein programmierbares Steuergerät 1 mit Speicherbelegungen entsprechend dem Ausführungsbeispiel. Figur 1a bezieht sich auf den Zustand vor Durchführung des erfindungsgemäßen Verfahrens: Das Steuergerät umfasst einen beschreibbaren Speicherbereich 10 und einen beschreibbaren Bootsektorbereich 20. Im Speicherbereich 10 ist ein Steuerprogramm 11 gespeichert, das die bei Betrieb des Fahrzeugs die originären Funktionen des Steuer- gerätes steuert. Im Bootsektorbereich 20 befindet sich ein Kryptoschlüssel 21. Dieser soll durch einen Kryptoschlüssels 22 ersetzt werden, wobei nach Abschluss des Verfahrens (Figur 1b) der Speicherbereich 10 wiederum das Steuerprogramm 11 enthalten soll.
Figur 2 zeigt in einer Schemazeichnung Verfahrensschritte zum gesicherten Einbringen des neuen Kryptoschlüssels 22.
In einem ersten Hauptschritt 100 wird eine signierte Nachladesoftware 123 durch zusammenstellen der Komponenten und anschließendes Signieren erzeugt. Hierzu wird in einem ersten Teilschritt 110 der Kryptoschlüssel 22 (d.h. der wesentliche Teil der Updatesoftware) verschlüsselt. Der hierbei verwendete Schlüssel ist so zu wählen, dass ein zur Entschlüsselung geeigneter Schlüssel 21 in dem Steuergerät 1 vorhanden ist. Im gezeigten Beispiel wird hierzu ebenfalls der Kryptoschlüssel 21 verwendet und damit die verschlüsselte Updatesoftware 111 erzeugt. Alternativ könnte zur asymmetrischen Verschlüsselung anstelle des Schlüssels 21 auch ein anderer Schlüssel verwendet werden, zu dem im Steuergerät ein geeigneter Komplementärschlüssel vorhanden ist. Die Verschlüsselung der Updatesoftware dient dazu, den Nachladevorgang gegen unbefugte lesende Zugriffe abzusichern und insoweit auch künftige unbefugte schreibende Eingriffe abzuwehren. Sie ist jedoch kein zwingendes Merkmal der vorliegenden Erfindung.
Im anschließenden Teilschritt 120 wird die verschlüsselte Updatesoftware 111 zur Absicherung gegen Verfälschung signiert. Dies geschieht im gezeigten Ausführungsbeispiel zusammen mit einer Applikation 121. Die Applikation 121 enthält eine zur Entschlüsselung der Updatesoftware 111 geeignete Entschlüsselungssoftware 122, um eine Entschlüsselung im Steuergerät zu ermöglichen. Liegt im Steuergerät bereits eine Entschlüsselungssoftware vor, so kann diese verwendet und auf das Nachladen einer Entschlüsselungssoftware verzichtet werden. Der zur Signaturberechnung verwendete Schlüssel ist wiederum so gewählt, dass ein zur Signaturprüfung geeigneter Schlüssel im Steuergerät vorhanden ist. Im gezeigten Ausführungsbeispiel, in dem ein symmetrisches Verfahren gewählt ist, werden Signaturberechnung und Signaturprüfung werden mit dem gleichen Schlüssel 21 durchgeführt. Der Sicherheitsschutz eines symmetrischen Verfahrens ist nur wirksam, wenn es gelingt, den dafür verwendeten Schlüssel geheimzuhalten. Anstelle eines symmetrischen Verfahrens kann auch ein asymmetrisches Verfahren, z.B. ein Public-Key-Verfahren, verwendet werden. Auch in einem asymmetrischen Verfahren ist der zur Signaturberechnung verwendete Schlüssel so zu wählen, dass ein zur Signaturprüfung geeigneter Schlüssel im Steuergerät vorhanden ist. Sollte beispielsweise Schlüssel 21 zur Signaturprüfung eines asymmetrischen Verfahrens verwendet werden, so wäre die Signaturberechnung in Verfahrensschritt 120 mit einem zu Schlüssel 21 komplementären Schlüssel durchzuführen.
In einem zweiten Hauptschritt 200 wird das Steuergerät mit der Nachladesoftware 123 beladen. Hierzu wird sie zunächst im Speicherbereich 10 gespeichert, wobei sie im gezeigten Beispiel an die Stelle des Steuerprogramms 11 tritt. Das Überschreiben bereits zuvor vorhandener Daten ist zur Durchführung des erfindungsgemäßen Verfahrens nicht zwingend erforderlich, stellt in der Praxis jedoch eine häufig auftre- tende Notwendigkeit dar: Programmierbare Steuergeräte werden hinsichtlich der verfügbaren Speichergröße in der Regel aus Kostengründen auf die betriebsnotwendigen Applikationen ausgelegt, eine Speichervorhaltung für Nachladesoftware 123 erfolgt nicht. Um diese zur Durchführung des erfindungsgemäßen Verfahrens laden zu können, müssen daher in der Praxis aufgrund begrenzt verfügbaren Spei- cherplatzes meist bereits vorhandene Daten überschrieben werden.
Im Anschluss hieran erfolgt in Schritt 220 eine Signaturprüfung, im gezeigten Beispiel unter Verwendung des Schlüssels 21. Auf mögliche Alternativen wurde bereits in der Kommentierung zu Schritt 120 hingewiesen.
Wird bei der Signaturprüfung nicht der erforderliche Gutbefund erzielt, d.h. eine unerwünschte Datenveränderung festgestellt, so wird eine vorher einstellbare Folge ausgelöst. Beispielsweise weist das Steuergerät die nachgeladene Software zurück, so dass diese nicht im Steuergerät betrieben werden kann. Insbesondere wird dann auch keine Veränderung im Bootsektor vorgenommen, und insoweit ist das Steuergerät gegen unbefugte Eingriffe geschützt. Alternativ könnte auch nur eine Nutzerwarnung ausgelöst werden. Verläuft dagegen die Signaturprüfung positiv, so liegen im Speicherbereich 10 des Steuergeräts die verschlüsselte Updatesoftware 111 sowie die Nachladesoftware 121 ausführbar vor.
Zur Absicherung des zweiten Hauptschritt 200 kann auch ein anderer Sicherheitsmechanismus als eine Signaturprüfung verwendet werden, beispielsweise ein Zerti- fikat-basiertes Verfahren oder ein Verschlüsselungsverfahren. In einfachster Form kann auf eine Absicherung auch völlig verzichtet werden. In diesem Fall ist allerdings die nachzuladene Software nicht gegen unauthorisierte Eingriffe geschützt.
Auch können in einer anderen Ausführungsform die Übertragung von Nachladesoftware und Updatesoftware in das Steuergerät separate Schritte umfassen. Dies ist insbesondere dann sinnvoll, wenn in einem zunächst auszuführenden Installationsschritt ein Sicherheitsmechanismus in das Steuergerät eingebracht und aktiviert wird, der der Absicherung eines später auszuführenden Schrittes dient.
In einem weiteren Hauptschritt 300 wird durch Ausführen der Nachladesoftware 121 , 122 der neue Schlüssel 22 an die Stelle des alten Schlüssels 21 abgelegt.
Hierzu wird zunächst in einem Teilschritt 310 durch Ausführen der in der Nachladesoftware 121 enthaltenen Entschlüsselungssoftware 122 der' bisher nur in verschlüsselter Form 111 übertragene neue Schlüssel in Klartextform 22 wiederherge- stellt und im anschließenden Teilschritt 320 im Bootsektor 20 an die Stelle des vorherigen Schlüssels 21 abgelegt.
Hiermit ist das hauptsächliche Ziel des gezeigten Beispiels, nämlich der Austausch der Schlüssel im Bootsektor bereits erreicht. Die anschließenden Verfahrensschritte betreffen die Wiederherstellung des Steuerprogramms 11 im Speicher 10 des Steuergeräts.
Im Hauptschritt 400 wird hierzu die nachzuladende Software einschließlich des Steuerprogramms 11 vorbereitet. Im vorliegenden Beispiel besteht Schritt 400 im wesentlichen in der Signierung des Steuerprogramms 11. Hierbei sind in den bisherigen Verfahrensschritten vorgenommene Veränderungen der Sicherheitsmechanismen im Bootsektor zu berücksichtigen. Erfolgte etwa zusätzlich oder anstelle des Tauschs der Schlüssel 21 , 22 eine Veränderung des Sicherheitsmechanismus, bei- spielsweise Veränderungen der Schlüssellänge oder der Ersatz eines symmetrischen Signaturverfahrens durch ein asymmetrisches Signaturverfahren oder ein Zertifikat-basiertes Verfahren, so wäre die nachzuladende Software auf diesen neuen Sicherheitsmechanismus auszurichten.
Im gezeigten Beispiel wird ein symmetrisches Verfahren beibehalten und zur Signaturberechnung in Schritt 400 Schlüssel 22 verwendet. Alternativ kann wie bereits zuvor auch ein weiterer im Steuergerät vorhandener Schlüssel verwendet werden.
In einem weiteren Hauptschritt 500 wird das Steuergerät mit der Steuersoftware 11 beladen, und zwar unter Berücksichtung der vorgenommenen Aktualisierung der Sicherheitsmechanismen im Bootsektor des Steuergeräts. Im vorliegenden Beispiel wird sie signiert übertragen und in Schritt 510 in Speicherbereich 10 gespeichert, und zwar an die Stelle der Nachladesoftware 121. In einem späteren Schritt 520 erfolgt eine Verifikation der eingespielten Software, im gezeigten Beispiel eine Sig- naturprüfung, nun unter Verwendung des Schlüssels 22. Auf mögliche Alternativen wurde bereits in der Kommentierung zu Schritt 400 hingewiesen.
Verläuft die Signaturprüfung positiv, so liegt im Speicherbereich 10 des Steuergeräts nun die Steuersoftware 11 ausführbar vor, Insgesamt ist der in Figur 1 b darge- stellte Zielzustand erreicht. Würde bei der Signaturprüfung der erforderliche Gutbefund nicht erzielt, so wäre dieses ein Hinweis darauf, dass der in Figur 1b dargestellte Zielzustand verfehlt wurde, d.h. entweder die Aktualisierung des Bootsektors nicht gelungen ist oder bei der Wiedereinbringung der Steuersoftware 11 eine unerwünschte Datenveränderung erfolgte.

Claims

Patentansprüche
1. Verfahren zum Nachladen einer Updatesoftware (22) in einen beschreibbaren Speicherbereich (20) eines Bootsektor eines programmierbaren Steuergerätes
(1) eines Fahrzeugs, umfassend die folgenden Schritte:
Bereitstellen einer in einen außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10) des programmierbaren Steuergerätes (1) ladbaren Nachladesoftware (121 , 122, 123), die in der Lage ist, im Steu- ergerät (1 ) die Installation der Updatesoftware (22) in den beschreibbaren
Speicherbereich (20) des Bootsektor zu steuern,
Laden der Nachladesoftware (121 , 122, 123) und der Updatesoftware (22) in den außerhalb des Bootsektors gelegenen, beschreibbaren Speicherbereich (10), • Ausführen der Nachladesoftware (121 , 122, 123) im Steuergerät zur Installation der Update-Software (22) in den beschreibbaren Speicherbereich (20) des Bootsektors.
2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass die Updatesoftware (22) in der Nachladesoftware (123) enthalten ist.
3. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass wenigstens auf einen Teil der Nachladesoftware (121 , 122, 123) und/oder der Updatesoftware (22) ein Signaturverfahren angewendet wird, wo- bei die Software (121 , 122, 123; 22) vor ihrer Übertragung in das Steuergerät
(1) mittels eines ersten Signaturschlüssels (21) signiert und nach ihrer Übertragung in das Steuergerät (1 ) mittels eines zweiten, im Steuergerät (1 ) abgelegten Signaturschlüssels (21), auf ihre Unverfälschtheit hin überprüft wird.
4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der zweite Signaturschlüssel (21 ) in dem beschreibbaren Speicherbereich des Bootsektors abgelegt ist.
5. Verfahren nach einem der Ansprüche 3 oder 4, dadurch gekennzeichnet, dass ein asymmetrisches Signaturverfahren angewendet wird, wobei der erste und der zweite Signaturschlüssel ein komplementäres Schlüsselpaar bilden.
6. Verfahren nach einem der Ansprüche 3 oder 4, dadurch gekennzeichnet, dass ein symmetrisches Signaturverfahren angewendet wird, wobei der erste und der zweite Signaturschlüssel (21) identisch sind.
7. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeich- net, dass wenigstens ein Teil der Nachladesoftware (121 , 122, 123) und/oder der Updatesoftware (22) vor der Übertragung in das Steuergerät mittels eines Verschlüsselungsschlüssels verschlüsselt und nach der Übertragung in das Steuergerät von einer Entschlüsselungssoftware (122) mittels eines in dem Steuergerät abgelegten Entschlüsselungsschlüssels entschlüsselt wird.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass der Entschlüsselungsschlüssel (21) in dem beschreibbaren Speicherbereich (20) des Bootsektors abgelegt ist.
9. Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass ein asymmetrisches Verschlüsselungsverfahren angewendet wird, wobei der Verschlüsselungsschlüssel und der Entschlüsselungsschlüssel ein komplementäres Schlüsselpaar bilden.
10. Verfahren nach einem der Ansprüche 7 oder 8, dadurch gekennzeichnet, dass ein symmetrisches Verschlüsselungsverfahren angewendet wird, wobei der Verschlüsselungsschlüssel (21) und der Entschlüsselungsschlüssel (21 ) identisch sind.
11. Verfahren nach einem der Ansprüche 7 bis 10, dadurch gekennzeichnet, dass die Entschlüsselungssoftware (122) in der Nachladesoftware (123) enthalten ist.
12. Verfahren nach einem der Ansprüche 7 bis 11, soweit rückbezogen auf einen der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass der erste Signaturschlüssel und der Verschlüsselungsschlüssel identisch sind und dass der zweite Signaturschlüssel und der Entschlüsselungsschlüssel identisch sind.
13. Verfahren nach einem der Ansprüche 7 bis 11 , soweit rückbezogen auf einen der Ansprüche 3 bis 6, dadurch gekennzeichnet, dass für das Signaturverfahren und für die Ver- und Entschlüsselung unterschiedliche Schlüsselpaare von identischen oder komplementären Schlüsseln verwendet werden.
14. Verwendung des Verfahrens nach einem der vorangehenden Ansprüche zum Austausch eines im Bootsektor (20) des Steuergerätes (1) abgelegten Schlüssels (21) durch einen neuen Schlüssel (22).
15. Verwendung des Verfahrens nach einem der vorangehenden Ansprüche zum Wiederherstellen von Speicherinhalten des Bootsektors (20) des Steuergerätes nach unkontrollierter physikalischer Veränderung („Bit-Kippen") oder zur nachträglichen Einführung, Erweiterung oder Aktualisieren von Software-basierten Sicherheitsmechanismen
EP04730255A 2003-06-24 2004-04-29 Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher Ceased EP1636700A1 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
DE10328529 2003-06-24
DE10357032A DE10357032A1 (de) 2003-06-24 2003-12-03 Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
PCT/EP2004/004664 WO2004114131A1 (de) 2003-06-24 2004-04-29 Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher

Publications (1)

Publication Number Publication Date
EP1636700A1 true EP1636700A1 (de) 2006-03-22

Family

ID=33542153

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04730255A Ceased EP1636700A1 (de) 2003-06-24 2004-04-29 Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher

Country Status (5)

Country Link
US (1) US7584350B2 (de)
EP (1) EP1636700A1 (de)
JP (1) JP2007507020A (de)
KR (1) KR20060008338A (de)
WO (1) WO2004114131A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050257206A1 (en) * 2004-05-14 2005-11-17 Semerdzhiev Krasimir P Pair-update mechanism for update module
US7937198B2 (en) * 2004-12-29 2011-05-03 Snap-On Incorporated Vehicle or engine diagnostic systems supporting fast boot and reprogramming
EP1860552A1 (de) * 2006-05-23 2007-11-28 Siemens Aktiengesellschaft Modifizieren eines Softwarestands einer Steuergerätesoftware für ein Steuergerät und Erkennen einer solchen Modifikation
US7860853B2 (en) * 2007-02-14 2010-12-28 Provilla, Inc. Document matching engine using asymmetric signature generation
DE102010040115A1 (de) * 2010-09-01 2012-03-01 Robert Bosch Gmbh Verfahren zum Bereitstellen von Informationen für ein Steuergerät
US9021246B2 (en) * 2011-10-28 2015-04-28 GM Global Technology Operations LLC Method to replace bootloader public key
KR101897605B1 (ko) * 2012-02-24 2018-09-12 삼성전자 주식회사 휴대 단말기의 무결성 보호 방법 및 장치
US9779247B2 (en) * 2015-05-29 2017-10-03 GM Global Technology Operations LLC Boot control systems and methods for vehicles
US10223294B2 (en) 2015-09-01 2019-03-05 Nxp Usa, Inc. Fast secure boot from embedded flash memory
US10705826B2 (en) * 2017-02-01 2020-07-07 Sumitomo Electric Industries, Ltd. Control apparatus, program updating method, and computer program
FI128506B (en) * 2019-01-28 2020-06-30 Elisa Oyj Automatic network deployment

Family Cites Families (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
IT1254937B (it) * 1991-05-06 1995-10-11 Aggiornamento dinamico di memoria non volatile in un sistema informatico
US5568641A (en) * 1995-01-18 1996-10-22 Hewlett-Packard Company Powerfail durable flash EEPROM upgrade
JP3292356B2 (ja) * 1995-02-27 2002-06-17 日本電信電話株式会社 暗号化情報の流通方法
US6092725A (en) * 1997-01-24 2000-07-25 Symbol Technologies, Inc. Statistical sampling security methodology for self-scanning checkout system
US6138236A (en) * 1996-07-01 2000-10-24 Sun Microsystems, Inc. Method and apparatus for firmware authentication
US7040541B2 (en) * 1996-09-05 2006-05-09 Symbol Technologies, Inc. Portable shopping and order fulfillment system
US6837436B2 (en) * 1996-09-05 2005-01-04 Symbol Technologies, Inc. Consumer interactive shopping system
JP3881069B2 (ja) * 1996-10-08 2007-02-14 株式会社デンソー 電子装置
US5844986A (en) * 1996-09-30 1998-12-01 Intel Corporation Secure BIOS
US5937063A (en) * 1996-09-30 1999-08-10 Intel Corporation Secure boot
DE19704531C1 (de) * 1997-02-06 1998-04-09 Siemens Ag Verfahren und Vorrichtung zum Laden einer Anwendungssoftware in einen programmierbaren Lesespeicher
US6409086B1 (en) * 1997-08-08 2002-06-25 Symbol Technolgies, Inc. Terminal locking system
US6266809B1 (en) * 1997-08-15 2001-07-24 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US6009524A (en) * 1997-08-29 1999-12-28 Compact Computer Corp Method for the secure remote flashing of a BIOS memory
DE19750365A1 (de) * 1997-11-14 1999-05-20 Bosch Gmbh Robert Verfahren zum Laden eines Programms und Datenverarbeitungsgerät
US6378072B1 (en) * 1998-02-03 2002-04-23 Compaq Computer Corporation Cryptographic system
JPH11259371A (ja) * 1998-03-12 1999-09-24 Denso Corp 電子制御装置及び電子制御装置のプログラム書き換え方法
US6640214B1 (en) * 1999-01-16 2003-10-28 Symbol Technologies, Inc. Portable electronic terminal and data processing system
US7010501B1 (en) * 1998-05-29 2006-03-07 Symbol Technologies, Inc. Personal shopping system
US6275931B1 (en) * 1998-06-22 2001-08-14 Elsag International N.V. Method and apparatus for upgrading firmware boot and main codes in a programmable memory
US6308265B1 (en) * 1998-09-30 2001-10-23 Phoenix Technologies Ltd. Protection of boot block code while allowing write accesses to the boot block
US7174457B1 (en) * 1999-03-10 2007-02-06 Microsoft Corporation System and method for authenticating an operating system to a central processing unit, providing the CPU/OS with secure storage, and authenticating the CPU/OS to a third party
IL129947A (en) * 1999-05-13 2003-06-24 Tadiran Telecom Business Syste Method and apparatus for downloading software into an embedded system
US20010030664A1 (en) * 1999-08-16 2001-10-18 Shulman Leo A. Method and apparatus for configuring icon interactivity
US6353398B1 (en) * 1999-10-22 2002-03-05 Himanshu S. Amin System for dynamically pushing information to a user utilizing global positioning system
US6581159B1 (en) * 1999-12-23 2003-06-17 Intel Corporation Secure method of updating bios by using a simply authenticated external module to further validate new firmware code
JP2001209543A (ja) * 2000-01-28 2001-08-03 Nec Ic Microcomput Syst Ltd フラッシュ・マイコンにおけるプログラム書き換え方法
DE10008973B4 (de) * 2000-02-25 2004-10-07 Bayerische Motoren Werke Ag Autorisierungsverfahren mit Zertifikat
DE10008974B4 (de) * 2000-02-25 2005-12-29 Bayerische Motoren Werke Ag Signaturverfahren
US7069452B1 (en) * 2000-07-12 2006-06-27 International Business Machines Corporation Methods, systems and computer program products for secure firmware updates
US6732267B1 (en) * 2000-09-11 2004-05-04 Dell Products L.P. System and method for performing remote BIOS updates
DE10112056A1 (de) * 2001-03-14 2002-09-26 Jungheinrich Ag Verfahren zur Änderung von Daten in einem nicht flüchtigen, elektrisch löschbaren Speicher
DE10131395B4 (de) * 2001-06-28 2006-08-17 Daimlerchrysler Ag Verfahren zum Übertragen von Software- Modulen
DE10141737C1 (de) * 2001-08-25 2003-04-03 Daimler Chrysler Ag Verfahren zur sicheren Datenübertragung innerhalb eines Verkehrsmittels
US7337309B2 (en) * 2003-03-24 2008-02-26 Intel Corporation Secure online BIOS update schemes

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004114131A1 *

Also Published As

Publication number Publication date
US7584350B2 (en) 2009-09-01
JP2007507020A (ja) 2007-03-22
US20070005948A1 (en) 2007-01-04
KR20060008338A (ko) 2006-01-26
WO2004114131A1 (de) 2004-12-29

Similar Documents

Publication Publication Date Title
DE60127310T2 (de) Vorrichtung zum schutz digitaler daten
DE102009041176B4 (de) Compiler-System und Verfahren zum Kompilieren eines Quellencodes zu einem verschlüsselten Maschinensprachcode
DE10318031A1 (de) Verfahren zur Sicherstellung der Integrität und Authentizität von Flashware für Steuergeräte
DE2937354A1 (de) Verfahren und einrichtung zur ueberwachung des gebrauchs eines programmierbaren rechners
DE19839680B4 (de) Verfahren und Vorrichtung zur Veränderung des Speicherinhalts von Steuergeräten
EP1636700A1 (de) Verfahren zum nachladen einer software in den bootsektor eines programmierbaren lesespeicher
DE102020003072B3 (de) Verfahren zur sicheren Nutzung von kryptografischem Material
WO2006120001A1 (de) Tragbarer datenträger mit sicherer datenverarbeitung
EP3811260B1 (de) Kryptografiemodul und betriebsverfahren hierfür
DE3705736A1 (de) Verfahren zum sichern von programmen und zur integritaetskontrolle gesicherter programme
EP1611517A2 (de) Programmgesteuerte einheit
DE10357032A1 (de) Verfahren zum Nachladen einer Software in den Bootsektor eines programmierbaren Lesespeicher
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
WO2010089083A2 (de) Vorrichtung und verfahren zum verhindern von unautorisierter verwendung und/oder manipulation von software
EP2524333B1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
EP1577734A2 (de) Verfahren zum sicheren Betrieb eines tragbaren Datenträgers
EP1318451B1 (de) Verfahren zum Ausführen eines Programms auf einem Computer
DE10215626B4 (de) Verfahren zur Änderung von Verschlüsselungsalgorithmen bei geschützter Software oder geschützten Daten
EP1904980A1 (de) Verfahren zum betreiben eines tragbaren datenträgers
DE102004047191A1 (de) Manipulationsgeschütztes Mikroprozessorsystem und Betriebsverfahren dafür
DE102014113441A1 (de) Schutz vor Software-Komponenten mittels Verschlüsselung
WO2024110546A1 (de) Verfahren zum verschlüsseln eines quelltextes, verfahren zum entschlüsseln eines quelltextes und entwicklungssystem
EP1611514A2 (de) Programmgesteuerte einheit
AT524619A1 (de) Computerimplementiertes Verfahren zum autorisierten Ausführen einer Software, System zur Datenverarbeitung, Computerprogrammprodukt und computerlesbares Speichermedium
DE10028265A1 (de) Vorrichtung und Verfahren zum Entschlüsseln eines verschlüsselten elektronischen Dokuments

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: 20051103

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): DE ES FR GB IT SE

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

Designated state(s): DE ES FR GB IT SE

17Q First examination report despatched

Effective date: 20060905

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE

APBT Appeal procedure closed

Free format text: ORIGINAL CODE: EPIDOSNNOA9E

REG Reference to a national code

Ref country code: DE

Ref legal event code: R003

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

Free format text: STATUS: THE APPLICATION HAS BEEN REFUSED

18R Application refused

Effective date: 20120916