EP3204850A1 - Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb - Google Patents

Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb

Info

Publication number
EP3204850A1
EP3204850A1 EP15778904.1A EP15778904A EP3204850A1 EP 3204850 A1 EP3204850 A1 EP 3204850A1 EP 15778904 A EP15778904 A EP 15778904A EP 3204850 A1 EP3204850 A1 EP 3204850A1
Authority
EP
European Patent Office
Prior art keywords
chip card
smart card
operating system
program instructions
nvm
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.)
Pending
Application number
EP15778904.1A
Other languages
English (en)
French (fr)
Inventor
Steffen Scholze
Matthias SCHWAN
Frank Müller
Klaus-Dieter Wirth
Elke FILZHUTH
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.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
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 Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Publication of EP3204850A1 publication Critical patent/EP3204850A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1408—Protection against unauthorised use of memory or access to memory by using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14—Protection against unauthorised use of memory or access to memory
    • G06F12/1458—Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062—Securing storage systems
    • G06F3/0622—Securing storage systems in relation to access
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0632—Configuration or reconfiguration of storage systems by initialisation or re-initialisation of storage systems
    • 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
    • G06F8/654—Updates using techniques specially adapted for alterable solid state memories, e.g. for EEPROM or flash memories
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/40—Specific encoding of data in memory or cache
    • G06F2212/402—Encrypted data

Definitions

  • the invention relates to a method for loading executable program instructions into a chip card, which is in operative operation, and a corresponding chip card and an electronic system with a chip card terminal.
  • boot loader also referred to as a "boot loader”
  • the bootloader can send the smart card operating system to the appropriate memory address of the changeable non-volatile memory (also abbreviated to NVM of "non-volatile memory”).
  • the boot loader is located in the non-changeable fixed memory of the smart card (usually referred to as ROM, of "read only memory”), which usually also contains the program of the hardware test for the chip of the chip card, the boot loader in the ROM using a ROM Mask is introduced (compare Handbook of smart cards, Wolfgang Rankl, Wolfgang Effing, Carl Hanser Verlag Kunststoff, 2008, p. 493 at 13.5.1 and p. 622 at 14.3.3).
  • the bootloader is used in the prior art only for the initial loading of the smart card operating system in the NVM during production or initialization of the smart card in a secure environment use and is then disabled for the entire life of the smart card.
  • Changing or updating the smart card operating system or reloading executable program instructions into the NVM of the smart card by means of the bootloader in the ROM is not provided in the prior art (mostly for security reasons) since prior art boot loaders do not have sufficiently secure mechanisms for the smart card Incorporation of program instructions in the operative operation of the smart card operating system included and thus for example would no longer be sufficiently certified for government applications and / or the introduction of malicious software would allow.
  • the invention is the object of the invention to provide a method for loading executable program instructions in a smart card, which is in operative operation, without that the security of the smart card, as it is required, for example, for sovereign applications and / or payments , in question.
  • the object underlying the invention is achieved in each case with the features of the independent claims. Embodiments of the invention are indicated in the dependent claims.
  • the "effective operation" of a chip card is understood to mean the state of a chip card which has left a production environment after personalization, in particular the loading of the chip card operating system and other data, and which for example has already moved from the so-called first-use status to the used status for example DE 10 2007 041370 A1.
  • a “personalization system” here means a device of a chip card production to which chip card blanks are supplied in order to personalize them, in particular by initial loading of the chip card operating system by means of the bootloader of the chip card and storage of further personalization data , Image data, biometric data of the future owner of the smart card, such as fingerprint data or iris scan data, cryptographic keys and other sensitive data, that is, in particular attributes related to the owner, the publisher of the smart card or the smart card itself.
  • Embodiments of the invention are particularly advantageous because the loading of executable program instructions in the operative operation of the chip card is made possible, without thereby questioning the security of the chip card, as is essential in particular for governmental applications.
  • boot loader itself does not have to have an authentication function for authentication of the chip card terminal.
  • This has the particular advantage of being able to adapt the authentication function of the chip card operating system, for example, to the respective application and / or increased security requirements, for example by the executable program instructions to be reloaded updating the authentication function of the chip card operating system, for example for later chip card operating system updates.
  • this authentication function is variable and can change the circumstances or Security requirements are adjusted.
  • the executable program instructions are an update of the chip card control system, that is to say a so-called operating system update.
  • the executable program instructions replace or deactivate corresponding program instructions of the previously loaded chip card operating system.
  • the executable program instructions form an updated or alternative smart card operating system which overwrites the initially loaded smart card operating system or which is stored in the NVM in addition to the currently active smart card operating system.
  • this process can be carried out repeatedly within the useful life, for example the period of validity, of a chip card in order, for example, to carry out operating system updates at regular or irregular intervals.
  • the executable program instructions to be reloaded may implement a cryptographic protocol such that a higher level of security is ensured in the execution than the implementation by the existing and to be replaced program instructions allows.
  • the length of the keys used can be increased or another cryptographic method or another cryptographic algorithm can be defined.
  • Embodiments of the invention make it possible during this period of validity to perform one or more updates of the smart card operating system by reloading program instructions in order to take into account the current security requirements, the user does not need a new ID document, because on the one hand all data from the personalization of the On the other hand, the functional behavior of the smart card operating system meets the expectations of the respective readers.
  • the chip card is designed as a document, in particular as a value or security document, wherein the document has a secure memory area for storing at least one attribute and a communication interface for reading out the attribute, wherein the smart card operating system has a cryptographic function for performing a Cryptographic access log, the successful implementation of which is a necessary condition for an external read access to the attribute.
  • this cryptographic function is implemented by the same authentication function of the chip card operating system, which is thus used both for the authentication of the chip card terminal for reloading program instructions and for the authentication of a chip card terminal for reading out the attributes, for example in the case of border control.
  • the document is a paper-based and / or plastic-based document, such as an electronic identity document, in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, company card, health card or other ID document or a chip card, a means of payment, in particular a banknote, bank card or credit card, a bill of lading or other proof of entitlement, with an integrated data memory for storing the at least one attribute.
  • an electronic identity document in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, company card, health card or other ID document or a chip card
  • a means of payment in particular a banknote, bank card or credit card
  • a bill of lading or other proof of entitlement with an integrated data memory for storing the at least one attribute.
  • the loading of the executable program instructions from a smart card terminal having a mechanical feeder for inserting the smart card into the smart card terminal even if the smart card and the smart card terminal via a wireless interface, such as an RFID or have an NFC interface.
  • a wireless interface such as an RFID or have an NFC interface.
  • Figure 1 is a block diagram of an embodiment of an inventive
  • FIG. 2 shows a block diagram of an embodiment of an inventive device
  • FIG. 3 shows a flowchart of an embodiment of an inventive device
  • FIG. 1 shows a chip card 100 with a ROM 102 and a non-volative memory (NVM), for example an EEPROM, in particular a so-called flash EEPROM 104, which has a content that can be changed by a write operation.
  • NVM non-volative memory
  • the ROM 102 includes a boot loader 106 which has been inserted in the production of the chip including the ROM 102 by means of a so-called ROM mask.
  • the boot loader 106 includes an authentication function 108 for Authentication of a personalization system 1 10 to initially store the smart card operating system in the NVM can.
  • the authentification function 108 includes a symmetric key 12, which must also be stored in the personalization system 110 so that it can authenticate itself to the boot loader 106.
  • the key 1 12 may be wholly or partially stored in the ROM 102 and / or in whole or in part in the flash 104. The latter has the advantage that different keys can be used for authentication for the same ROM masks.
  • the boot loader 106 also has an interface function 1 14 for controlling an interface 1 16 of the chip card 100 for the communication and data transmission between reader and smart card.
  • the interface 16 can be a wireless interface, for example an NFC or RFID standard, in particular a contactless interface in accordance with ISO 14443, preferably with Very High Bit Rate (VHBR) support.
  • VHBR Very High Bit Rate
  • the boot loader 106 further has a memory function 118 which is used to access the NVM 104 with, for example, the required hardware functionalities for addressing, erasing, writing and / or reading changeable nonvolatile memory, optionally with the aid of a memory management unit (MMU). (see manual of chip cards, page 106 under 5.4.1 1).
  • MMU memory management unit
  • the boot loader 106 is adapted to process commands in the form of command APDUs, in particular according to ISO / IEC 7816-4.
  • the chip card 100 has a processor 126, wherein the processor 126 includes logic circuits which may be implemented in one or more discrete components or modules integrated on the same chip, and which serve, inter alia, for executing the boot loader 106.
  • the chip card 100 is initially a non-personalized or pre-personalized chip card blank without chip card operating system.
  • the initial loading of a smart card operating system 128 is done in a production environment that is specially secured by an access control system using the personalization tool 1 10. Due to the inherently secure production environment that is protected against access by the access control system to unauthorized third parties, the authentication function 108 of the authentication function 108 of FIG Bootloaders 106 a lower level of security can be selected, as for the recharging in active mode.
  • the key 1 12 is also stored in a memory 130 of the personalization system 1 10.
  • the personalization system 110 has an interface 132 corresponding to the interface 1 16 in order to communicate with the chip card 100.
  • the personalization system 110 initially sends an authentication command 134 to the smart card 100 in order to start the boot loader 106, that is to say its authentication function 108.
  • the personalization system 1 10 then sends, for example, the key 1 12 to the smart card 100.
  • the personalization system 1 10 By executing the authentication function 108 by the processor 126, it is then checked whether the key 1 12 received from the personalization tool 1 10 matches the key 1 12 of the authentication function 108 included in the ROM mask. If this is the case, the personalization system 1 10 is considered authenticated. In the next step, the personalization system 1 10 then sends a load command 136 to the smart card 100, reads the smart card operating system 128 from its memory 130 and transmits it to the smart card 100, from which the smart card operating system 128 by the memory function 1 18 of the boot loader 106 then into the NVM 104 is written.
  • the chip card operating system 128 with the key 1 12 is symmetrically encrypted, and the chip card operating system 128 is then decrypted by the authentication function 108. Since decryption is only possible if the encryption of the chip card operating system was carried out with the appropriate symmetric key, a separate authentication step can be dispensed with in this case since it is inherent to the decryption of the chip card operating system 128 by the boot loader.
  • the personalization system 110 After the loading of the chip card operating system 128 and possibly further personalization data has taken place and thus the chip card is prepared for active operation, the personalization system 110 sends a status command 138 in order to set the status of the chip card 100 set in the storage area 124 to the status "active operation" ,
  • the smart card operating system 128 further includes a program call 142 for starting the boot loader 106. Further, in the flash 104, addresses for calling the interface function 14 and the memory function 1 18 of the boot loader 106 for the smart card operating system 128 may be stored, so that the smart card operating system 128 performs these functions Bootloaders 106 can call in active mode and thus does not have to have such functions themselves, so that the resources of the smart card are used efficiently.
  • the authentication function 140 is selected to provide sufficiently strong authentication of a smart card terminal outside a secured access area as provided by a production environment.
  • the authentication function 140 implements the steps of a cryptographic protocol based on asymmetrical cryptographic key pairs, such as a challenge-response protocol, a Diffie-Hellman protocol, an extended access control system. Protocol (EAC) or a PACE protocol with so-called terminal authentication (TA) and Chip Authentication (CA), see Technical Guideline TR-031 10-2, Advanced Security Mechanisms for Machine Readable Travel Documents - Part 2, Version 2.1 1, March 20, 2012, Federal Office for Information Security.
  • EAC EAC
  • TA terminal authentication
  • CA Chip Authentication
  • the authentication function 140 may also include an authorization check and the definition of one or more parameters for establishing secure communication, such as a session key for establishing a secure messaging (SM) channel.
  • SM secure messaging
  • FIG. 2 shows the chip card 100 in operative operation, which has been personalized according to FIG.
  • executable program instructions for example, to update or replace the smart card operating system 128, that is, for a so-called operating system update, a smart card terminal 144 is used.
  • the chip card terminal 144 has an interface 146 corresponding to the interface 16 of the chip card 100.
  • this is a contactless interface, in particular according to ISO 14443 with support from VHBR.
  • the interface 146 is formed with a mechanical feeder to completely receive the smart card 100 in a housing of the smart card terminal 144, this mechanical feeder can be designed analogous to known bank terminals for the withdrawal of cash.
  • the smart card terminal 144 has a memory 148 in which executable program instructions 150 are stored, such as an operating system update for updating the smart card operating system 128. Further, the memory 148 includes program instructions 152 which implement those steps of a cryptographic protocol that concern the smart card terminal 144 and which are interoperable with the authentication function 140 of the smart card operating system 128. The smart card terminal 144 has a processor 154 for executing these program instructions 152. To perform the operating system update, you can do the following:
  • the user inserts the chip card 100 into the mechanical intake of the chip card terminal 144.
  • the smart card terminal 144 couples electrical energy into the smart card 100 via its interface 146. Since the status "active operation" is stored in the memory area 124, the smart card operating system 128 then starts and not the boot loader 106.
  • the smart card terminal sends a command 156 to the smart card 100 to start the operating system update.
  • the authentication function 140 of the operating system 128 is started so that the cryptographic protocol for verifying the authenticity of the chip card terminal 144 is carried out, for which purpose the chip card terminal 144 exchanges data with the chip card 100 in accordance with data 158.
  • the smart card terminal 144 sends a digital certificate by specifying its right to reload executable program instructions, that is, the operating system update in this case. Based on this certificate can be checked by the smart card operating system 128 by the smart card 100, whether the smart card terminal 144 for reloading the program instructions has the required authorization.
  • one or more parameters required for secure communication are determined, such as by a Diffie-Hellman key exchange or other method of, for example, specifying a symmetric session key.
  • the authentication function 140 then stores such a parameter, such as a symmetric session key 160, in the memory area 122.
  • the smart card operating system 128 may store further data in the memory area 122 to enable it Bootloader 106 to pass.
  • These may be, for example, data specifying to which addresses in the flash 104 the program instructions received from the smart card terminal 144 are to be stored and / or an updated start address 162 'from which the program execution upon injection of energy into the smart card 100 after successful and complete reloading of the program instructions.
  • the smart card operating system 128 then starts the program call 142 so that the boot loader 106 is started. As a result, the execution of the smart card operating system 128 is terminated at the same time.
  • the bootloader 106 then accesses the memory area 124 first. Since the memory card 124 stores the smart card 100 in the "active" state, in which the boot loader 106 normally can not start because it is disabled after personalization, the boot loader 106 subsequently accesses the address 120 in the Memory area 122, to read from there data indicating the possibly successful authentication and rights checking If there is such data and their testing was successful, the execution of the boot loader 106 is continued, otherwise aborted.
  • the boot loader 106 attempts to read from the address 120 the session key 160. Only if there is a session key 160 at the address 120 is the execution of the boot loader 106 continued.
  • a secured channel is then established, for example after a so-called secure Messaging method.
  • the previously agreed between the smart card 100 and the smart card terminal 144 session key 160 may be used.
  • the boot loader 106 may use the session key 160 to authenticate the smart card terminal 144, by the boot loader 106 checking whether the smart card terminal 144 has access to the correct session key 160, for example by means of a challenge-response method. Alternatively, such a separate check can be omitted since only one valid session key 160 allows reception of the program instructions 150. This check is therefore inherent to the transmission of the program instructions 150 over the secure channel.
  • the smart card terminal 144 then sends the operating system update with the program instructions 150, which may be encrypted with the session key 160, via the secure messaging channel to the boot loader 106, which decrypts the program instructions 150 and stores them in the flash 104. This can be done by completely or partially overwriting the initially loaded operating system 128 by the program instructions 150 or by additionally writing the program instructions 150 into the NVM 104.
  • the program instructions 150 may be transmitted either in plain text or in the form of data specifying the program instructions 150.
  • both the boot loader 106 and the smart card operating system 128 are certified, for example, in accordance with the Common Criteria with a sufficient level of security, which guarantees that they meet the security requirements, for example for sovereign documents.
  • the updated by the reloading of the program instructions 150 chip card operating system is certified accordingly, it being ensured that the recharging actually the corresponding certified updated smart card operating system is introduced into the smart card 100, as this by their turn certified components, ie the boot loader 106 , the initially inserted smart card operating system 128 and the smart card terminal 144, takes place.
  • Information for reloading itself that is, for example, the version of the chip card operating system 128 to which the reloading is to take place as well as the version of the chip card operating system 128 which is present after reloading,
  • Additional information such as a return address, into the smart card operating system 128 after reloading, an updated address 120, if not static, to the address and size of the memory area 122 for the boot loader 106 with specified data in the
  • boot loader 106 and / or proof of successful authentication for reloading, as well as configuration data for the accurate operation of boot loader 106.
  • the smart card operating system 128 may provide the boot loader 106 with further data and parameters via the memory area 122, the memory area 122 instead of the NVM 104 being stored in a RAM of the smart card 100 and / or a register of the processor 126 and / or another non-memory card.
  • volatile memory NVM
  • MMU volatile memory
  • the other data and / or parameters may be, for example: In addition to the executable program instructions 150 parameter values for their execution,
  • One or more memory addresses for the program instructions 150 in the NVM 104 for example, each of the program instructions 150 may be assigned a memory address in the NVM 104 to which the program instruction concerned is to be stored, or blocks of program instructions each to be written by an allocated memory address by the boot loader 106 may be combined,
  • the NVM 104 may store two different operating system versions of the smart card operating system 128, which address then identifies that of the two operating system versions that is actually to be executed.
  • the bootloader 106 may additionally have functions for calculating checksums of memory contents that may be CRC and / or hashed.
  • the boot loader may further comprise a function for setting the entry address of the smart card operating system 128, from which the program execution starts after the energy is coupled into the smart card in active operation.
  • This start address may be passed to the boot loader via the memory area 122 at its start by the smart card operating system 128, so that the boot loader may write the new start address in a predefined memory area, for example the NVM 104.
  • the boot loader 106 may be configured so that the components of the smart card operating system 128 to be updated are not overwritten, but instead bit-wise logical operations of current data of the smart card operating system 128 and the update provided by the smart card terminal 144, for example XOR, AND, OR or NOT operations.
  • the chip card 100 can have a secure memory area for storing at least one attribute and the interface 16 for reading out the attribute, the chip card operating system 128 or 128 'having a cryptographic function for carrying out a cryptographic access protocol, the successful execution of which is a necessary prerequisite for is an external read access to the attribute.
  • This cryptographic function can be provided by the authentication function 140, which thus also serves to authenticate a reader, e.g. for a border control.
  • FIG. 3 shows a flow chart of an embodiment of a method according to the invention.
  • step 200 the smart card 100 is inserted into the smart card terminal 144 and power is coupled into the smart card so that the operating system 128 starts from a predefined start address 162.
  • the start address 162 may be stored in a predefined nonvolatile memory area of the smart card 100 which is automatically accessed by the smart card 100 as soon as the power is coupled into the smart card to start execution of the smart card operating system 128 from this start address 162.
  • step 204 smart card 100 receives command 156 from smart card terminal 144 for reloading executable program instructions.
  • a cryptographic protocol for authenticating smart card terminal 144 and checking (step 208) whether smart card terminal 144 has the access rights necessary for reloading the program instructions is started, including data 158 between smart card terminal 144 and smart card 100 be exchanged to perform the cryptographic protocol in question. Further, due to the execution of the cryptographic protocol, a session key 160 is set, which is written by the smart card operating system 128 into the storage area 122. In addition, the smart card operating system may still write additional data before starting the boot loader in step 212 using program call 142.
  • This data may be, for example, data specifying to which addresses in the NVM 104 the program instructions 150 are to be written and / or an updated start address 162 'from which the execution of the program code stored in the NVM 104 , starting to take place.
  • the program instructions 150 include a new version of the smart card operating system 128, that is, the current version of the smart card operating system 128 'to be written in the NVM 104 behind the smart card operating system 128. Accordingly, the start address 162 must be updated to the start address 162 '(see Fig. 2) so that at the next boot, the program will start from this updated start address, thus executing the new version of the smart card operating system 128' instead of the previous version.
  • bootloader 1 12 After bootloader 1 12 is started by smart card operating system 128, it accesses memory area 122 and reads the data contained therein at step 214. Step 216 then establishes a secure channel between smart card 100 and smart card terminal 144, for example using the session key 160, and data is loaded from the smart card terminal 140 specifying the program instructions 150 at step 218.
  • These data may directly relate to the program instructions 150 themselves or, depending on the embodiment, to data from which these program instructions 150 can be derived by the smart card 100, for example by logically interpreting these data with the program instructions of the programmer Chip card operating system 128 are linked by the boot loader 106, so that the result of these logical operations, the updated program instructions 150 result.

Landscapes

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

Abstract

Die Erfindung betrifft ein Verfahren zum Laden von ausführbaren Programminstruktionen (150) in eine im Wirkbetrieb befindliche Chipkarte (100), wobei die Chipkarte zumindest ein ROM (102) und ein NVM (104) aufweist, wobei in dem ROM ein Bootloader (106) zum Laden eines Chipkartenbetriebssystems (128) von einer Personalisierungsanlage (110) in das NVM vor Aufnahme des Wirkbetriebs der Chipkarte gespeichert ist und in dem NVM das Chipkartenbetriebssystem (128) gespeichert ist, und wobei sich der Bootloader in dem Wirkbetrieb der Chipkarte in einem deaktivierten Zustand befindet, wobei der Bootloader in seinem deaktivierten Zustand ausschließlich durch das Chipkartenbetriebssystem (128, 128') startbar ist, wobei das Verfahren die folgenden Schritte aufweist: - Einkopplung von Energie in die Chipkarte (100) von einem Chipkartenterminal (144), -Start der Ausführung des in dem NVM gespeicherten Chipkartenbetriebssystems durch die Chipkarte, - Empfang eines Kommandos (156) von dem Chipkartenterminal zum Laden der ausführbaren Programminstruktionen durch das Chipkartenbetriebssystem, - Authentisierung des Chipkartenterminals gegenüber der Chipkarte durch das Chipkartenbetriebssystem, -Prüfung der Berechtigung des Chipkartenterminals zum Laden der ausführbaren Programminstruktionen durch das Chipkartenbetriebssystem, - Speicherung von Daten in einem vordefinierten Speicherbereich (122) des NVM, die eine erfolgreiche Durchführung der Authentisierung und der Prüfung anzeigen, durch das Chipkartenbetriebssystem, - Starten der Ausführung des Bootloaders durch das Chipkartenbetriebssystem und Abbruch der Ausführung des Chipkartenbetriebssystems nach dem Start des Bootloaders, - Lesen der Daten aus dem vordefinierten Speicherbereich durch den Bootloader, - Laden der Programminstruktionen von dem Chipkartenterminal in den NVM durch den Bootloader unter der Voraussetzung, dass die Daten in dem vordefinierten Speicherbereich die erfolgreiche Authentisierung und Prüfung anzeigen.

Description

Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
B e s c h r e i b u n g
Die Erfindung betrifft ein Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte, die sich im Wirkbetrieb befindet sowie eine entsprechende Chipkarte und ein elektronisches System mit einem Chipkartenterminal.
Aus dem Stand der Technik ist die Verwendung eines sogenannten Bootloaders, welcher auch als„Urlader" bezeichnet wird, bekannt, um das Chipkartenbetriebssystem in den änderbaren nichtflüchtigen Speicher (basierend auf z.B. EEPROM- oder Flash-EEPROM-Technologie) der Chipkarte zu laden. Mithilfe des Bootloaders kann das Chipkartenbetriebssystem an die entsprechende Speicheradresse des im änderbaren nichtflüchtigen Speicher (abgekürzt auch NVM von "non-volatile memo- ry") geladen werden.
Der Bootloader befindet sich im nicht-änderbaren festen Speicher der Chipkarte (üblicherweise als ROM bezeichnet, von "read only memory"), welches üblicherweise auch das Programm des Hardwaretests für den Chip der Chipkarte enthält, wobei der Bootloader in das ROM mithilfe einer ROM-Maske eingebracht wird (vergleiche hierzu Handbuch der Chipkarten, Wolfgang Rankl, Wolfgang Effing, Carl Hanser Verlag München, 2008, S. 493 unter 13.5.1 und S. 622 unter 14.3.3).
Der Bootloader findet im Stand der Technik lediglich für das initiale Laden des Chipkartenbetriebssystems in den NVM während der Produktion oder der Initialisierung der Chipkarte in einer sicheren Umgebung Verwendung und ist anschließend für die gesamte Lebensdauer der Chipkarte deaktiviert. Eine Änderung oder eine Aktualisierung des Chipkartenbetriebssystems oder ein Nachladen von ausführbaren Programminstruktionen in das NVM der Chipkarte mittels des Bootloader im ROM ist im Stand der Technik (zumeist aus Sicherheitsgründen) nicht vorgesehen, da Bootloader nach dem Stand der Technik nicht über hinreichend sichere Mechanismen für das Einbringen von Programminstruktionen im Wirkbetrieb des Chipkartenbetriebssystem enthalten und somit zum Beispiel für hoheitliche Anwendungen nicht mehr ausreichend zertifiziert wäre und/oder das Einbringen von Schad-Software ermöglicht würde.
Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte, die sich im Wirkbetrieb befindet, zu schaffen, ohne dass dies die Sicherheit der Chipkarte, so wie sie beispielsweise für hoheitliche Anwendungen und/oder im Zahlungsverkehr erforderlich ist, in Frage stellt.
Die der Erfindung zugrunde liegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche gelöst. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben. Unter dem„Wirkbetrieb" einer Chipkarte wird der Zustand einer Chipkarte verstanden, die eine Produktionsumgebung nach Personalisierung, insbesondere dem Laden des Chipkartenbetriebssystems und anderer Daten, verlassen hat, und die beispielsweise bereits von dem sogenannten Erstbenutzungsstatus in den Benutzt- Status übergegangen ist, vergleiche hierzu zum Beispiel DE 10 2007 041370 A1 .
Unter einer„Personalisierungsanlage" wird hier eine Vorrichtung einer Chipkartenproduktion verstanden, der Chipkartenrohlinge zugeführt werden, um diese zu personalisieren, indem insbesondere das initiale Laden des Chipkartenbetriebssystems mithilfe des Bootloaders der Chipkarte sowie das Speichern weiterer Personalisie- rungsdaten erfolgt. Zu diesen Personalisierungsdaten können textuelle Angaben, Bilddaten, biometrische Daten des zukünftigen Inhabers der Chipkarte, wie Fingerabdruckdaten oder Irisscandaten, kryptografische Schlüssel und andere schutzbedürftige Daten, das heißt insbesondere Attribute bezüglich des Inhabers, des Herausgebers der Chipkarte oder der Chipkarte selbst gehören.
Ausführungsformen der Erfindung sind besonders vorteilhaft, da das Laden von ausführbaren Programminstruktionen im Wirkbetrieb der Chipkarte ermöglicht wird, ohne hierdurch die Sicherheit der Chipkarte in Frage zu stellen, wie sie insbesondere für hoheitliche Anwendungen unerlässlich ist.
Von besonderem Vorteil ist dabei ferner, dass für das Laden der ausführbaren Programminstruktionen der im ROM befindlichen Bootloader der Chipkarte zum Einsatz kommt, ohne dass der Bootloader auf das im NVM befindliche Chipkartenbetriebssystem und die dafür nachzuladenden Programminstruktionen abgestimmt sein muss. Dies wird dadurch ermöglicht, dass das mittels des Bootloaders initial in das NVM geladene Chipkartenbetriebssystem eine Authentifizierungsfunktion aufweist, die zur Authentifizierung eines Chipkartenterminals dient, von welchem aus im Wirkbetrieb der Chipkarte das Laden der ausführbaren Programminstruktionen erfolgen soll. Nachdem diese Authentifizierung erfolgreich durchgeführt worden ist, schreibt das Chipkartenbetriebssystem entsprechende Daten in einen vordefinierten Speicherbereich. Erst anschließend startet das Chipkartenbet ebssystem den Bootloader, womit die Ausführung des Chipkartenbetriebssystems gleichzeitig endet. Der Bootloader greift dann auf den vordefinierten Speicherbereich zu, um zu prüfen, ob die vorhergehende Authentifizierung des Chipkartenterminals durch das Chipkartenbetriebssystem erfolgreich durchgeführt worden ist. Wenn dieser der Fall ist, kann anschließend dann das Laden der ausführbaren Programminstruktionen erfolgen.
Dies hat den besonderen Vorteil, dass der Bootloader selbst nicht eine Authentifizie- rungsfunktion zur Authentifizierung des Chipkartenterminals aufweisen muss. Dies hat den besonderen Vorzug der Flexibilität, die Authentifizierungsfunktion des Chipkartenbetriebssystems beispielsweise an die jeweilige Anwendung und/oder erhöhte Sicherheitsanforderungen anpassen zu können, beispielsweise indem die nachzuladenden ausführbaren Programminstruktionen eine Aktualisierung der Authentifizierungsfunktion des Chipkartenbetriebssystems zum Beispiel für spätere Chipkartenbetriebssystem-Updates beinhalten.
Dadurch, dass die Authentifizierung des Chipkartenterminals nicht durch den Bootloader selbst erfolgt, welcher ja unveränderbar im ROM hinterlegt ist, sondern dass diese Authentifizierungsfunktion in dem durch das Nachladen von ausführbaren Programminstruktionen veränderlichen Chipkartenbethebssystem implementiert ist, ist auch diese Authentifizierungsfunktion veränderlich und kann an veränderte Gegebenheiten oder Sicherheitsanforderungen angepasst werden.
Ein weiterer besonderer Vorteil ist hierbei, dass ein generischer Bootloader für verschiedene Chipkartenbetriebssysteme von unterschiedlichen Herstellern zum Einsatz kommen kann, da die spezifische Ausprägung der Authentifizierungsfunktion, die eine jeweilige Anwendung der Chipkarte erfordert, in dem jeweiligen Chipkartenbetriebssystem implementiert ist. Dadurch wird der Aufwand vermieden, je nach Anwendung und/oder Chipkartenbethebssystem einen darauf angepassten Bootloader mit jeweils einer eigenen ROM-Maske herstellen zu müssen, um das Nachladen im Wirkbetrieb für jedes Chipkartenbethebssystem separat zu ermöglichen. Nach Ausführungsformen der Erfindung handelt es sich bei den ausführbaren Progrannnninstruktionen um eine Aktualisierung des Chipkartenbethebssystems, das heißt ein sogenanntes Betriebssystem-Update. Durch die ausführbaren Programminstruktionen werden entsprechende Programminstruktionen des zuvor geladenen Chipkartenbetriebssystems ersetzt bzw. deaktiviert. Alternativ bilden die ausführbaren Programminstruktionen ein aktualisiertes oder alternatives Chipkartenbetriebssystem, welche das initial geladene Chipkartenbetriebssystem überschreiben oder welche zusätzlich zu dem derzeit aktiven Chipkartenbetriebssystem im NVM gespeichert werden. Je nach Ausführungsform kann dieser Vorgang innerhalb der Nutzungsdauer, z.B. der Gültigkeitsdauer, einer Chipkarte wiederholt durchgeführt werden, um z.B. in regelmäßigen oder unregelmäßigen Abständen Betriebssystem- Updates durchzuführen.
Die nachzuladenden ausführbaren Programminstruktionen können beispielsweise ein kryptografisches Protokoll derart implementieren, dass eine höhere Sicherheit bei der Ausführung gewährleistet ist, als es die Implementierung durch die vorhandenen und zu ersetzenden Programminstruktionen ermöglicht. Beispielsweise kann hierzu die Länge der verwendeten Schlüssel vergrößert werden oder es kann ein anderes kryptografisches Verfahren oder ein anderer kryptografischer Algorithmus definiert werden.
Dies ist besonders vorteilhaft für hoheitliche Ausweisdokumente, wie zum Beispiel elektronische Personalausweise oder Reisepässe, die im Allgemeinen eine relativ lange Gültigkeitsdauer von bis zu zehn Jahren haben. Ausführungsformen der Erfindung ermöglichen es, während dieser Gültigkeitsdauer ein oder mehrfach Updates des Chipkartenbetriebssystems durch das Nachladen von Programminstruktionen durchzuführen, um den jeweils aktuellen Sicherheitsanforderungen Rechnung zu tragen, wobei der Benutzer hierzu kein neues ID-Dokument benötigt, da einerseits sämtliche Daten aus der Personalisierung des ID-Dokumentes erhalten bleiben können und andererseits das funktionale Verhalten des Chipkartenbetriebssystems den Erwartungen der jeweiligen Lesegeräte entspricht. Nach Ausführungsformen der Erfindung ist die Chipkarte als Dokument ausgebildet, insbesondere als ein Wert- oder Sicherheitsdokument, wobei das Dokument einen gesicherten Speicherbereich zur Speicherung zumindest eines Attributs und eine Kommunikations-Schnittstelle zum Auslesen des Attributs aufweist, wobei das Chipkartenbetriebssystem eine kryptographische Funktion zur Durchführung eines kryptographischen Zugriffsprotokolls aufweist, dessen erfolgreiche Durchführung eine notwendige Voraussetzung für einen externen Lesezugriff auf das Attribut ist. Vorzugsweise wird diese kryptographische Funktion durch dieselbe Authentifizie- rungsfunktion des Chipkartenbetriebssystems implementiert, die somit sowohl für die Authentisierung des Chipkartenterminals für das Nachladen von Programminstruktionen als auch für die Authentisierung eines Chipkartenterminals zum Auslesen der Attribute beispielsweise bei einer Grenzkontrolle eingesetzt wird.
Nach Ausführungsformen der Erfindung handelt es sich bei dem Dokument um ein papierbasiertes und/oder kunststoffbasiertes Dokument, wie zum Beispiel ein elektronisches Ausweisdokument, insbesondere einen Reisepass, Personalausweis, Visum, Führerschein, Fahrzeugschein, Fahrzeugbrief, Firmenausweis, Gesundheitskarte oder ein anderes ID-Dokument oder eine Chipkarte, ein Zahlungsmittel, insbesondere eine Banknote, Bankkarte oder Kreditkarte, einen Frachtbrief oder einen sonstigen Berechtigungsnachweis, mit einem integrierten Datenspeicher zur Speicherung des zumindest einen Attributs.
Nach Ausführungsformen der Erfindung erfolgt das Laden der ausführbaren Programminstruktionen von einem Chipkartenterminal, das einen mechanischen Einzug zum Einzug der Chipkarte in das Chipkartenterminal aufweist, und zwar auch dann, wenn die Chipkarte und der Chipkartenterminal über eine drahtlose Schnittstelle, wie zum Beispiel eine RFID- oder eine NFC-Schnittstelle verfügen. Der Vorteil eines solchen mechanischen Einzugs ist nämlich, dass die Chipkarte während des Ladens der ausführbaren Programminstruktionen nicht aus dem Chipkartenterminal entnommen werden kann, sondern von dem Chipkartenterminal erst nach der er- folgreichen Beendigung des Ladens der ausführbaren Programminstruktionen wieder aus dem mechanischen Einzug herausgegeben und freigegeben wird.
Hierdurch wird vermieden, dass die Chipkarte während des Ladens der ausführbaren Programminstruktionen aus dem Chipkartenterminal entnommen werden kann, weil sonst die Chipkarte einen nicht definierten Betriebszustand haben könnte, welcher einerseits die Möglichkeit für einen Angriff böte und anderseits zum Ausfall des Chipkartenbetriebssystem führte.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen erläutert. Es zeigen:
Figur 1 ein Blockdiagramm einer Ausführungsform einer erfindungsgemäßen
Chipkarte in einer Produktionsumgebung,
Figur 2 ein Blockdiagramm einer Ausführungsform einer erfindungsgemäßen
Chipkarte im Wirkbetrieb,
Figur 3 ein Flussdiagramm einer Ausführungsform eines erfindungsgemäßen
Verfahrens.
Im Weiteren werden gleiche oder entsprechende Elemente der nachfolgenden Ausführungsformen jeweils mit identischen Bezugszeichen gekennzeichnet.
Die Figur 1 zeigt eine Chipkarte 100 mit einem ROM 102 und einem non-volative memory (NVM), beispielsweise einem EEPROM, insbesondere einem sogenannten Flash- EEPROM 104, welches einen durch eine Schreiboperation änderbaren Inhalt hat.
Das ROM 102 beinhaltet einen Bootloader 106, der bei der Produktion des Chips, der das ROM 102 beinhaltet, mithilfe einer sogenannten ROM-Maske eingebracht worden ist. Der Bootloader 106 beinhaltet eine Authentifizierungsfunktion 108 zur Authentifizierung einer Personalisierungsanlage 1 10, um initial das Chipkartenbetriebssystem in das NVM speichern zu können. Beispielsweise beinhaltet die Au- thentifizierungsfunktion 108 einen symmetrischen Schlüssel 1 12, der auch in der Personalisierungsanlage 1 10 gespeichert sein muss, damit sich diese gegenüber dem Bootloader 106 authentifizieren kann. Der Schlüssel 1 12 kann ganz oder teilweise in dem ROM 102 gespeichert sein und/oder ganz oder teilweise in dem Flash 104. Letzteres hat den Vorteil, dass für gleiche ROM-Masken unterschiedliche Schlüssel für die Authentisierung verwendet werden können.
Der Bootloader 106 hat ferner eine Schnittstellenfunktion 1 14 zur Ansteuerung einer Schnittstelle 1 16 der Chipkarte 100 für die Kommunikation und Datenübertragung zwischen Lesegerät und Chipkarte. Bei der Schnittstelle 1 16 kann es sich um eine drahtlose Schnittstelle, zum Beispiel nach einem NFC- oder RFID-Standard handeln, insbesondere eine kontaktlose Schnittstelle gemäß ISO 14443, vorzugsweise mit Unterstützung von Very High Bit Rate (VHBR).
Der Bootloader 106 hat ferner eine Speicherfunktion 1 18, die zum Zugriff auf das NVM 104 dient, mit beispielsweise den erforderlichen Hardwarefunktionalitäten für das Adressieren, Löschen, Schreiben und/oder Lesen von änderbarem nichtflüchtigem Speicher, gegebenenfalls mit Unterstützung einer Memory Management Unit (MMU) (vergleiche Handbuch der Chipkarten, Seite 106 unter 5.4.1 1 ).
Nach Ausführungsformen der Erfindung ist der Bootloader 106 zur Verarbeitung von Kommandos in der Form von Kommando-APDUs ausgebildet, insbesondere gemäß ISO/IEC 7816-4.
In dem Bootloader 106 ist ferner eine Adresse 120 beinhaltet, die einen vordefinierten Speicherbereich 122 im NVM 104 definiert, auf den der Bootloader 106 zugreifen kann, wenn sein in dem Speicherbereich 124 im NVM 104 gespeicherter Status den Wirkbetrieb der Chipkarte 100 und damit den aktivierten Zustand des Boot- loaders 106 anzeigt. Die Chipkarte 100 hat einen Prozessor 126, wobei der Prozessor 126 Logikschaltungen beinhaltet, die in ein oder mehreren diskreten Komponenten oder auf demselben Chip integrierten Modulen realisiert sein können, und welche unter anderem zur Ausführung des Bootloaders 106 dienen.
Bei der Chipkarte 100 handelt es sich zunächst um einen nicht personalisierten oder vorpersonalisierten Chipkartenrohling ohne Chipkartenbetriebssystem. Das initiale Laden eines Chipkartenbetriebssystems 128 erfolgt in einer Produktionsumgebung, die durch ein Zugangskontrollsystem besonders gesichert ist, mithilfe der Personalisierungsanlage 1 10. Aufgrund der inhärent sicheren Produktionsumgebung, die gegen den Zutritt von unautorisierten Dritten durch das Zugangskontrollsystem geschützt ist, kann für die Authentifizierungsfunktion 108 des Bootloaders 106 ein geringeres Sicherheitsniveau gewählt werden, als für das Nachladen im Wirkbetrieb.
Hierzu ist beispielsweise der Schlüssel 1 12 ebenfalls in einem Speicher 130 der Personalisierungsanlage 1 10 gespeichert. Die Personalisierungsanlage 1 10 verfügt über eine der Schnittstelle 1 16 entsprechende Schnittstelle 132, um mit der Chipkarte 100 zu kommunizieren. Beispielsweise sendet die Personalisierungsanlage 1 10 zunächst ein Authentifizierungskommando 134 an die Chipkarte 100, um den Bootloader 106, das heißt dessen Authentifizierungsfunktion 108, zu starten. Zur Authentifizierung sendet die Personalisierungsanlage 1 10 dann beispielsweise den Schlüssel 1 12 an die Chipkarte 100.
Durch Ausführung der Authentifizierungsfunktion 108 durch den Prozessor 126 wird dann geprüft, ob der von der Personalisierungsanlage 1 10 empfangene Schlüssel 1 12 mit dem Schlüssel 1 12 der Authentifizierungsfunktion 108, der in der ROM- Maske beinhaltet ist, übereinstimmt. Wenn dies der Fall ist, gilt die Personalisierungsanlage 1 10 als authentifiziert. Im nächsten Schritt sendet die Personalisierungsanlage 1 10 dann ein Ladekommando 136 an die Chipkarte 100, liest das Chipkartenbetriebssystem 128 aus seinem Speicher 130 und überträgt es an die Chipkarte 100, von der das Chipkartenbetriebssystem 128 durch die Speicherfunktion 1 18 des Bootloaders 106 dann in das NVM 104 geschrieben wird. Alternativ kann auch so vorgegangen werden, dass das Chipkartenbetriebssys- tem 128 mit dem Schlüssel 1 12 symmetrisch verschlüsselt ist, und das Chipkartenbetriebssystem 128 dann durch die Authentifizierungsfunktion 108 entschlüsselt wird. Da eine Entschlüsselung nur dann möglich ist, wenn die Verschlüsselung des Chipkartenbetriebssystems mit dem zutreffenden symmetrischen Schlüssel erfolgte, kann in diesem Fall auf einen separaten Authentifizierungsschritt verzichtet werden, da dieser der Entschlüsselung des Chipkartenbetriebssystems 128 durch den Boot- loader inhärent ist.
Nachdem das Laden des Chipkartenbetriebssystems 128 sowie gegebenenfalls weiterer Personalisierungsdaten erfolgt ist und somit die Chipkarte für den Wirkbetrieb vorbereitet ist, sendet die Personalisierungsanlage 1 10 ein Statuskommando 138, um den in dem Speicherbereich 124 gesetzten Status der Chipkarte 100 auf den Status„Wirkbetrieb" zu setzen.
Das Chipkartenbetriebssystem 128 beinhaltet ferner einen Programmaufruf 142 zum Starten des Bootloaders 106. Ferner können in dem Flash 104 Adressen zum Aufruf der Schnittstellenfunktion 1 14 und der Speicherfunktion 1 18 des Bootloaders 106 für das Chipkartenbetriebssystem 128 gespeichert sein, so dass das Chipkartenbetriebssystem 128 diese Funktionen des Bootloaders 106 im Wirkbetrieb aufrufen kann und damit nicht selbst über solche Funktionen verfügen muss, so dass die Resourcen der Chipkarte effizient genutzt werden.
Die Authentifizierungsfunktion 140 ist so gewählt, dass sie eine hinreichend starke Authentifizierung eines Chipkartenterminals außerhalb eines gesicherten Zugangsbereichs, wie sie eine Produktionsumgebung bietet, gewährleistet. Beispielsweise werden durch die Authentifizierungsfunktion 140 die die Chipkarte 1 10 betreffenden Schritte eines kryptografischen Protokolls, das auf asymmetrischen kryptografi- schen Schlüsselpaaren basiert, implementiert, wie zum Beispiel ein Challenge- Response-Protokoll, ein Diffie-Hellman-Protokoll, ein Extended Access Control- Protokoll (EAC) oder ein PACE-Protokoll mit sogenannter Terminal Authentication (TA) und Chip Authentication (CA), vergleiche Technical Guideline TR-031 10-2, Advanced Security Mechanisms for Machine Readable Travel Documents - Part 2, Version 2.1 1 , 20. März 2012, Bundesamt für Sicherheit in der Informationstechnik.
Neben der Authentifizierung kann die Authentifizierungsfunktion 140 auch eine Berechtigungsprüfung beinhalten sowie die Festlegung von einem oder mehreren Parametern zum Aufbau einer gesicherten Kommunikation, wie zum Beispiel eines Session-Schlüssels zum Aufbau eines Secure-Messaging (SM)-Kanals.
Die Figur 2 zeigt die im Wirkbetrieb befindliche Chipkarte 100, die gemäß Figur 1 personalisiert worden ist. Zum nachträglichen Laden von ausführbaren Programminstruktionen, beispielsweise um das Chipkartenbetriebssystem 128 zu aktualisieren oder durch ein anderes zu ersetzen, das heißt für einen sogenannten Betriebssystem-Update, wird ein Chipkartenterminal 144 verwendet.
Das Chipkartenterminal 144 hat eine der Schnittstelle 1 16 der Chipkarte 100 entsprechende Schnittstelle 146. Vorzugsweise handelt es sich hierbei um eine kontaktlose Schnittstelle, insbesondere gemäß ISO 14443 mit Unterstützung von VHBR. Vorzugsweise ist die Schnittstelle 146 mit einem mechanischen Einzug ausgebildet, um die Chipkarte 100 vollständig in ein Gehäuse des Chipkartenterminals 144 aufzunehmen, wobei dieser mechanische Einzug analog zu bekannten Bankterminals für das Abheben von Bargeld ausgebildet sein kann.
Das Chipkartenterminal 144 hat einen Speicher 148, in dem ausführbare Programminstruktionen 150 gespeichert sind, wie zum Beispiel ein Betriebssystem-Update zum Update des Chipkartenbetriebssystems 128. Ferner beinhaltet der Speicher 148 Programminstruktionen 152, durch die diejenigen Schritte eines kryptografi- schen Protokolls implementiert werden, die das Chipkartenterminal 144 betreffen und die mit der Authentifizierungsfunktion 140 des Chipkartenbetriebssystems 128 interoperabel sind. Das Chipkartenterminal 144 hat einen Prozessor 154 zur Ausführung dieser Programminstruktionen 152. Zur Durchführung des Betriebssystem-Updates kann wie folgt vorgegangen werden:
1 . Der Nutzer führt die Chipkarte 100 in den mechanischen Einzug des Chipkartenterminals 144 ein.
2. Das Chipkartenterminal 144 koppelt über seine Schnittstelle 146 elektrische Energie in die Chipkarte 100 ein. Da der Status„Wirkbetrieb" in dem Speicherbereich 124 gespeichert ist, startet daraufhin das Chipkartenbetriebssystem 128 und nicht der Bootloader 106.
3. Das Chipkartenterminal sendet ein Kommando 156 an die Chipkarte 100, um den Betriebssystem-Update zu starten. Hierdurch wird die Authentifizierungs- funktion 140 des Betriebssystems 128 gestartet, sodass das kryptografische Protokoll zur Prüfung der Authentizität des Chipkartenterminals 144 durchgeführt wird, wozu das Chipkartenterminal 144 entsprechend Daten 158 mit der Chipkarte 100 austauscht.
Vorzugsweise wird neben der Authentizität des Chipkartenterminals 144 auch dessen Recht für die Vornahme des Betriebssystem-Updates geprüft. Hierzu sendet das Chipkartenterminal 144 beispielsweise ein digitales Zertifikat, indem sein Recht für das Nachladen von ausführbaren Programminstruktionen, das heißt in diesem Fall dem Betriebssystem-Update, spezifiziert ist. Anhand dieses Zertifikats kann durch das Chipkartenbetriebssystem 128 seitens der Chipkarte 100 geprüft werden, ob das Chipkartenterminal 144 für das Nachladen der Programminstruktionen die erforderliche Berechtigung hat.
Durch Ausführung der Authentifizierungsfunktion 140 und der Programminstruktionen 152 werden ferner ein oder mehrere Parameter festgelegt, die für eine sichere Kommunikation erforderlich sind, wie zum Beispiel durch einen Diffie-Hellman Schlüsselaustausch oder ein anders Verfahren, mit dem beispielsweise ein symmetrischer Session Key festgelegt wird. Unter der Voraussetzung, dass die Authentifizierung und gegebenenfalls die Rechteprü- fung des Chipkartenterminals 144 erfolgreich durchgeführt worden sind, speichert dann die Authentifizierungsfunktion 140 einen solchen Parameter, wie zum Beispiel einen symmetrischen Session Key 160, in dem Speicherbereich 122. Zusätzlich können von dem Chipkartenbetriebssystem 128 weitere Daten in dem Speicherbereich 122 gespeichert werden, um diese dem Bootloader 106 zu übergeben. Dabei kann es sich beispielsweise um Daten handeln, die spezifizieren, auf weiche Adressen in dem Flash 104 die von dem Chipkartenterminal 144 empfangenen Programminstruktionen zu speichern sind und/oder eine aktualisierte Startadresse 162' von der aus die Programmausführung bei Einkopplung von Energie in die Chipkarte 100 nach dem erfolgreichen und vollständigen Nachladen der Programminstruktionen erfolgen soll.
4. Das Chipkartenbetriebssystem 128 startet dann den Programmaufruf 142, sodass der Bootloader 106 gestartet wird. Hierdurch wird gleichzeitig die Ausführung des Chipkartenbetriebssystems 128 beendet.
Der Bootloader 106 greift dann zunächst auf den Speicherbereich 124 zu. Da in dem Speicherbereich 124 gespeichert ist, dass sich die Chipkarte 100 in dem Status„Wirkbetrieb" befindet, in dem der Bootloader 106 normalerweise nicht starten darf, da er nach der Personalisierung deaktiviert wird, greift der Bootloader 106 anschließend auf die Adresse 120 in dem Speicherbereich 122 zu, um von dort Daten zu lesen, die die gegebenenfalls erfolgreiche Authentifizierung und Rechteprüfung anzeigen. Wenn dort solche Daten vorliegen und deren Prüfung erfolgreich war, wird die Durchführung des Bootloaders 106 fortgeführt, andernfalls abgebrochen.
Beispielsweise versucht der Bootloader 106 von der Adresse 120 den Session Key 160 zu lesen. Nur dann, wenn sich an der Adresse 120 ein Session Key 160 befindet, wird die Ausführung des Bootloaders 106 fortgesetzt.
Zwischen dem Bootloader 106 und dem Chipkartenterminal 144 wird dann ein gesicherter Kanal aufgebaut, beispielsweise nach einem sogenannten Secure- Messaging-Verfahren. Hierzu kann der zuvor zwischen der Chipkarte 100 und dem Chipkartenterminal 144 vereinbarte Session Key 160 verwendet werden.
Alternativ oder zusätzlich kann der Bootloader 106 den Session Key 160 verwenden, um den Chipkartenterminal 144 zu authentifizieren, indem der Bootloader 106 prüft, ob der Chipkartenterminal 144 Zugriff auf den korrekten Session Key 160 hat, beispielsweise mittels einem Challenge-Response Verfahren. Alternativ kann eine solche separate Prüfung entfallen, da nur ein valider Session Key 160 einen Empfang der Programminstruktionen 150 ermöglicht. Diese Prüfung ist daher der Übertragung der Programminstruktionen 150 über den gesicherten Kanal inhärent.
Das Chipkartenterminal 144 sendet dann das Betriebssystem-Update mit den Programminstruktionen 150, die gegebenenfalls mit dem Session Key 160 verschlüsselt sind, über den Secure-Messaging-Kanal an den Bootloader 106, der die Programminstruktionen 150 entschlüsselt und in dem Flash 104 speichert. Dies kann dadurch erfolgen, dass das initial geladenen Betriebssystems 128 durch die Programminstruktionen 150 ganz oder teilweise überschrieben wird oder dadurch, dass die Programminstruktionen 150 zusätzlich in das NVM 104 geschrieben werden. Die Programminstruktionen 150 können dabei entweder im Klartext oder in der Form von Daten, die die Programminstruktionen 150 spezifizieren, übertragen werden.
Beispielsweise sind sowohl der Bootloader 106 als auch das Chipkartenbetriebssystem 128 z.B. gemäß Common Criteria mit ausreichendem Sicherheitsniveau zertifiziert, womit garantiert ist, dass sie den Sicherheitsanforderungen zum Beispiel für hoheitliche Dokumente genügen. Ebenso ist auch das durch das Nachladen der Programminstruktionen 150 aktualisierte Chipkartenbetriebssystem entsprechend zertifiziert, wobei sichergestellt werden kann, dass durch das Nachladen tatsächlich das entsprechend zertifizierte aktualisierte Chipkartenbetriebssystem in der Chipkarte 100 eingebracht wird, da dies durch die ihrerseits zertifizierte Komponenten, das heißt den Bootloader 106, das initial eingebrachte Chipkartenbetriebssystem 128 und den Chipkartenterminal 144, erfolgt. Nach Ausführungsformen der Erfindung können im Zusammenhang mit der Authentifizierung des Chipkartenterminals 144 durch die Authentifizierungsfunktion 140 für den administrativen Zugriff auf die Chipkarte 100 zum Zwecke des Nachladens der Programminstruktionen 150 zusätzliche folgende Informationen von dem Chipkartenterminal 144 an die Chipkarte 100 übermittelt werden:
• administrative Rechte des Chipkartenterminals 144, das heißt beispielsweise, welche der Funktionen des Chipkartenbetriebssystems 128 ersetzt werden dürfen und welche Speicherbereiche des NVM 104 beschrieben werden dürfen,
• Informationen zum Nachladen selbst, das heißt beispielsweise die Version des Chipkartenbetriebssystems 128 zu der das Nachladen erfolgen soll sowie die Version des Chipkartenbetriebssystems 128, die nach dem Nachladen vorliegt,
• zusätzliche Informationen, wie zum Beispiel eine Rücksprungadresse, in das Chipkartenbetriebssystem 128 nach dem Nachladen, eine aktualisierte Adresse 120, wenn diese nicht statisch ist, um Adresse und Größe des Speicherbereichs 122 für den Bootloader 106 mit spezifizierten Daten im
NVM 104 oder alternativ in einem RAM der Chipkarte 1 10 anzugeben,
• und/oder einen Schlüssel und Algorithmus für das Secure Messaging
und/oder den Nachweis von erfolgreicher Authentisierung für das Nachladen sowie Konfigurationsdaten für die genaue Arbeitsweise des Bootloaders 106.
Nach Ausführungsformen der Erfindung kann das Chipkartenbetriebssystem 128 den Bootloader 106 über den Speicherbereich 122 weitere Daten und Parameter bereitstellen, wobei der Speicherbereich 122 anstelle des NVM 104 in einem RAM der Chipkarte 100 und/oder einem Register des Prozessors 126 und/oder einem anderen nicht-flüchtigen Speicher (Non Volatile Memory - NVM) und/oder der MMU realisiert sein kann. Bei den weiteren Daten und/oder Parametern kann es sich beispielsweise um Folgendes handeln: • zusätzlich zu den ausführbaren Programminstruktionen 150 Parameterwerte für deren Ausführung,
• ein oder mehrere Speicheradressen für die Programminstruktionen 150 in dem NVM 104; beispielsweise kann jeder der Programminstruktionen 150 eine Speicheradresse im NVM 104 zugeordnet sein, an der die betreffende Programminstruktion zu speichern ist oder es können Blöcke von Programminstruktionen zusammengefasst werden, die jeweils von einer zugeordneten Speicheradresse von dem Bootloader 106 zu schreiben sind,
• eine Adresse im NVM 104, von der ausgehend die im NVM 104 gespeicherten Programminstruktionen im Wirkbetrieb der Chipkarte 100 ausgeführt werden sollen. Beispielsweise können im NVM 104 zwei verschiedene Betriebssystemversionen des Chipkartenbetriebssystems 128 gespeichert sein, wobei diese Adresse dann diejenige der beiden Betriebssystemversionen identifiziert, die tatsächlich ausgeführt werden soll.
Der Bootloader 106 kann zusätzlich über Funktionen zum Berechnen von Prüfsummen über Speicherinhalte verfügen, die als CRC und/oder Hash-Funktion ausgeprägt sein können.
Der Bootloader kann ferner eine Funktion zum Setzen der Einsprungadresse des Chipkartenbetriebssystems 128 aufweisen, von der aus die Programmausführung nach Einkopplung der Energie in die Chipkarte im Wirkbetrieb startet. Diese Startadresse kann dem Bootloader über den Speicherbereich 122 bei dessen Start durch das Chipkartenbetriebssystem 128 übergeben werden, sodass der Bootloader die neue Startadresse in einem vordefinierten Speicherbereich, zum Beispiel des NVM 104, schreiben kann. Nach einer Ausführungsform der Erfindung kann der Bootloader 106 so ausgebildet sein, dass die zu aktualisierenden Bestandteile des Chipkartenbetriebssystems 128 nicht überschrieben werden, sondern stattdessen bitweise logische Operationen von aktuellen Daten des Chipkartenbetriebssystems 128 und dem von dem Chipkartenterminal 144 gelieferten Update durchgeführt werden, zum Beispiel XOR-, AND-, OR- oder NOT-Operationen.
Die Chipkarte 100 kann einen gesicherten Speicherbereich zur Speicherung zumindest eines Attributs und die Schnittstelle 1 16 zum Auslesen des Attributs aufweisen, wobei das Chipkartenbetriebssystem 128 bzw. 128' eine kryptographische Funktion zur Durchführung eines kryptographischen Zugriffsprotokolls aufweist, dessen er- folgreiche Durchführung eine notwendige Voraussetzung für einen externen Lese- zugriff auf das Attribut ist. Diese kryptographische Funktion kann durch die Authenti- fizieurungsfunktion 140 zur Verfügung gestellt werden, die somit auch zur Authentifizierung eines Lesegeräts dient, z.B. für eine Grenzkontrolle.
Die Figur 3 zeigt ein Flussdiagramm einer Ausführungsform eines erfindungsgemäßen Verfahrens.
In dem Schritt 200 wird die Chipkarte 100 in den Chipkartenterminal 144 eingeführt und Energie wird in die Chipkarte eingekoppelt, sodass das Betriebssystem 128 von einer vordefinierten Startadresse 162 aus startet. Die Startadresse 162 kann in einem vordefinierten nicht-flüchtigen Speicherbereich der Chipkarte 100 gespeichert sein, auf weichen von der Chipkarte 100 automatisch zugegriffen wird, sobald die Energie in die Chipkarte eingekoppelt wird, um die Ausführung des Chipkartenbetriebssystems 128 von dieser Startadresse 162 aus zu starten.
In dem Schritt 204 empfängt die Chipkarte 100 das Kommando 156 von dem Chipkartenterminal 144 für das Nachladen von ausführbaren Programminstruktionen.
Daraufhin wird in dem Schritt 206 ein kryptografisches Protokoll zur Authentifizierung des Chipkartenterminals 144 und zur Prüfung (Schritt 208), ob der Chipkartenterminal 144 die für das Nachladen der Programminstruktionen notwendigen Zugriffsrechte hat, gestartet, wozu die Daten 158 zwischen dem Chipkartenterminal 144 und der Chipkarte 100 ausgetauscht werden, um das betreffende kryptografi- sche Protokoll durchzuführen. Ferner wird aufgrund der Ausführung des kryptografischen Protokolls ein Session Key 160 vereinbart, der von dem Chipkartenbetriebssystem 128 in den Speicherbereich 122 geschrieben wird. Zusätzlich kann das Chipkartenbetriebssystem noch weitere Daten schreiben bevor es den Bootloader in dem Schritt 212 mithilfe des Programmaufrufs 142 startet.
Bei diesen Daten kann es sich zum Beispiel um Daten handeln, die spezifizieren, an welche Adressen im NVM 104 die Programminstruktionen 150 zu schreiben sind und/oder eine aktualisierte Startadresse 162', von der aus die Ausführung des Programmcodes, welcher im NVM 104 gespeichert ist, ausgehend erfolgen soll.
Beispielsweise beinhalten die Programminstruktionen 150 eine neue Version des Chipkartenbetriebssystems 128, das heißt die aktuelle Version des Chipkartenbetriebssystems 128', die im NVM 104 hinter das Chipkartenbetriebssystem 128 geschrieben werden soll. Dementsprechend muss die Startadresse 162 auf die Startadresse 162' (vgl. Fig. 2) aktualisiert werden, damit beim nächsten Startvorgang der Programmstart von dieser aktualisierten Startadresse aus erfolgt und somit die neue Version des Chipkartenbetriebssystems 128' anstelle der vorherigen Version ausgeführt wird.
Nach dem Start des Bootloaders 1 12 durch das Chipkartenbetriebssystem 128 greift dieser auf den Speicherbereich 122 zu und liest die darin beinhalteten Daten in dem Schritt 214. In dem Schritt 216 wird dann zwischen der Chipkarte 100 und dem Chipkartenterminal 144 ein sicherer Kanal aufgebaut, zum Beispiel mithilfe des Session Key 160, und es werden in dem Schritt 218 Daten von dem Chipkartenterminal 140 geladen, die die Programminstruktionen 150 spezifizieren.
Bei diesen Daten kann es sich unmittelbar um die Programminstruktionen 150 selbst handeln oder - je nach Ausführungsform - um Daten, aus denen diese Programminstruktionen 150 durch die Chipkarte 100 herleitbar sind, indem beispielsweise diese Daten durch logische Operationen mit den Programminstruktionen des Chipkartenbetriebssystems 128 durch den Bootloader 106 verknüpft werden, sodass sich als Ergebnis dieser logischen Operationen die aktualisierten Programminstruktionen 150 ergeben.
Bezugszeichenl iste
Chipkarte
ROM
NVM
Bootloader
Authentifizierungsfunktion
Personalisierungsanlage
Schlüssel
Schnittstellenfunktion
Schnittstelle
Speicherfunktion
Adresse
Speicherbereich
Speicherbereich
Prozessor
Chipkartenbetriebssystem
Chipkartenbetriebssystem
Speicher
Schnittstelle
Authentifizierungskommando
Ladekommando
Statuskommando
Authentifizierungsfunktion
Programmaufruf
Chipkartenterminal
Schnittstelle
Speicher
Programminstruktionen
Programminstruktionen
Prozessor Daten Session Key Startadresse Startadresse

Claims

P a t e n t a n s p r ü c h e
Verfahren zum Laden von ausführbaren Programminstruktionen (150) in eine im Wirkbetrieb befindliche Chipkarte (100), wobei die Chipkarte zumindest ein ROM (102) und ein NVM (104) aufweist, wobei in dem ROM ein Bootloader (106) zum Laden eines Chipkartenbetriebssystems (128) von einer Personalisierungsanlage (1 10) in das NVM vor Aufnahme des Wirkbetriebs der Chipkarte gespeichert ist und in dem NVM das Chipkartenbetriebssystem (128) gespeichert ist, und wobei sich der Bootloader in dem Wirkbetrieb der Chipkarte in einem deaktivierten Zustand befindet, wobei der Bootloader in seinem deaktivierten Zustand ausschließlich durch das Chipkartenbetriebssystem (128, 128') startbar ist, wobei das Verfahren die folgenden Schritte aufweist:
- Einkopplung von Energie in die Chipkarte (100) von einem Chipkartenterminal (144),
- Start der Ausführung des in dem NVM gespeicherten Chipkartenbetriebssystems durch die Chipkarte,
- Empfang eines Kommandos (156) von dem Chipkartenterminal zum Laden der ausführbaren Programminstruktionen durch das Chipkartenbetriebssystem,
- Authentisierung des Chipkartenterminals gegenüber der Chipkarte durch das Chipkartenbetriebssystem,
- Prüfung der Berechtigung des Chipkartenterminals zum Laden der ausführbaren Programminstruktionen durch das Chipkartenbetriebssystem,
- Speicherung von Daten in einem vordefinierten Speicherbereich (122) des NVM, die eine erfolgreiche Durchführung der Authentisierung und der Prüfung anzeigen, durch das Chipkartenbetriebssystem,
- Starten der Ausführung des Bootloaders durch das Chipkartenbetriebssystem und Abbruch der Ausführung des Chipkartenbetriebssystems nach dem Start des Bootloaders, - Lesen der Daten aus dem vordefinierten Speicherbereich durch den Boot- loader,
- Laden der Programminstruktionen von dem Chipkartenterminal in den NVM durch den Bootloader unter der Voraussetzung, dass die Daten in dem vordefinierten Speicherbereich die erfolgreiche Authentisierung und Prüfung anzeigen.
2. Verfahren nach Anspruch 1 , wobei die ausführbaren Programminstruktionen in das NVM geladen werden, um das in dem NVM gespeicherte Chipkartenbetriebssystem zu aktualisieren.
3. Verfahren nach Anspruch 1 , wobei durch die ausführbaren Programminstruktionen ein anderes Chipkartenbetriebssystem (128') gebildet wird, welches das in dem NVM gespeicherte Chipkartenbetriebssystem für den Wirkbetrieb ersetzt.
4. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem NVM um ein Flash-EEPROM handelt.
5. Verfahren nach einem der vorhergehenden Ansprüche, wobei zu den Daten ein oder mehrere Parameter (160) gehören, die bei der Authentisierung festgelegt werden und welche zum Aufbau eines geschützten Kanals zwischen der Chipkarte und dem Chipkartenterminal für das Laden der Programminstruktionen verwendet werden.
6. Verfahren nach Anspruch 5, wobei es sich bei dem Parameter um einen
symmetrischen Schlüssel (160) handelt, der von dem Chipkartenterminal und dem Bootloader für die Übertragung der Programminstruktionen über den geschützten Kanal genutzt wird, insbesondere indem die Programminstruktionen mit dem symmetrischen Schlüssel (160) verschlüsselt übertragen werden, und/oder wobei der symmetrischen Schlüssel von dem Bootloader zur Authentisierung des Chipkartenterminals verwendet wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Prüfung der Berechtigung anhand eines von dem Chipkartenterminal empfangenen Zertifikats erfolgt, in dem eine Berechtigung des Chipkartenterminals für das Laden der Programminstruktionen spezifiziert ist.
8. Verfahren nach einem der vorgehenden Ansprüche, wobei vor dem Wirkbetrieb der Bootloader mit Hilfe einer ROM-Maske in das ROM eingebracht wird und der Bootloader eine Authentifizierungsfunktion (108) zur Authentifizierung der Personalisierungsanlage aufweist, wobei die Authentisierung der Personalisierungsanlage gegenüber dem Bootloader Voraussetzung für das initiale Laden des Betriebssystems in das NVM durch den Bootloader ist, wobei der Bootloader nach dem initialen Laden des Betriebssystems von der Personalisierungsanlage in den deaktivierten Zustand gebracht wird.
9. Verfahren nach einem der vorgehenden Ansprüche, wobei durch das Laden der Programminstruktionen (150) eine Aktualisierung der Authentifizierungsfunktion (140) erfolgt.
10. Chipkarte mit einem ROM (102), in dem ein Bootloader (106) gespeichert ist, und mit einem NVM (104), in dem ein Chipkartenbetriebssystem (128) gespeichert ist, wobei der Bootloader in einem Wirkbetrieb der Chipkarte ausschließlich von dem Chipkartenbetriebssystem startbar ist, um das Laden von ausführbaren Programminstruktionen (150) in das NVM der Chipkarte in dem Wirkbetrieb zu ermöglichen.
1 1 . Chipkarte nach Anspruch 10, wobei der Bootloader eine erste Authentifizierungsfunktion (108) zur Authentifizierung einer Personalisierungsanlage (144) vor dem Wirkbetrieb aufweist, um das initiale Laden des Betriebssystems (128) in das NVM zu ermöglichen und wobei das Chipkartenbetriebssystem eine zweite Authentifizierungsfunktion (140) aufweist, um einen Chipkartenterminal (144) zu authentifizieren, um das Laden der ausführbaren Programminstruktionen in dem Wirkbetrieb der Chipkarte durch den Bootloader zu ermöglichen, wobei der Bootloader so ausgebildet ist, dass in dem Wirkbetrieb keine Authentifizierung des Chipkartenterminals durch seine erste Authentifizierungsfunktion erfolgt, sondern der Bootloader nach seinem Start durch das Chipkartenbetriebssystem auf einen vordefinierten Speicherbereich (122) des NVM zugreift, um von dort Daten zu lesen, die eine erfolgreiche Authentifizierung des Chipkartenterminals durch das Chipkartenbetriebssystem anzeigen.
12. Chipkarte nach Anspruch 10 oder 1 1 , wobei in dem NVM der Chipkarte erste und zweite Chipkartenbetriebssysteme (128, 128') gespeichert sind sowie eine Einsprungadresse (162') auf das zweite Chipkartenbetriebssystem, sodass bei der Einkopplung von Energie in die Chipkarte das zweite Chipkartenbetriebssystem gestartet wird.
13. Chipkarte nach Anspruch 10, 1 1 oder 12, wobei es sich um ein Dokument, insbesondere ein Wert- oder Sicherheitsdokument, handelt, wobei das Dokument einen gesicherten Speicherbereich in dem NVM zur Speicherung zumindest eines Attributs und die Kommunikations-Schnittstelle (1 16) zum Auslesen des Attributs aufweist, wobei das Chipkartenbetriebssystem eine kryptographische Funktion zur Durchführung eines kryptographischen Zu- griffsprotokolls aufweist, dessen erfolgreiche Durchführung eine notwendige Voraussetzung für einen externen Lesezugriff auf das Attribut ist.
14. Chipkarte nach Anspruch 13, wobei durch die zweite Authentifizierungsfunktion das kryptographische Zugriffsprotokoll seitens der Chipkarte (100) implementiert ist.
15. Chipkarte nach Anspruch 13 oder 14, wobei es sich bei dem Dokument, um ein papierbasiertes und/oder kunststoffbasiertes Dokument handelt, wie zum Beispiel ein elektronisches Ausweisdokument, insbesondere einen Reise- pass, Personalausweis, Visum, Führerschein, Fahrzeugschein, Fahrzeugbrief, Firmenausweis, Gesundheitskarte oder ein anderes ID-Dokument oder eine Chipkarte, ein Zahlungsmittel, insbesondere eine Banknote, Bankkarte oder Kreditkarte, einen Frachtbrief oder einen sonstigen Berechtigungsnach- weis, mit einem integrierten Datenspeicher zur Speicherung des zumindest einen Attributs.
16. Chipkarte nach einem der Ansprüche 10 bis 15, wobei in dem NVM Adressen zum Aufruf eine Schnittstellenfunktion (1 14) und einer Speicherfunktion (1 18) des Bootloaders (106) für das Chipkartenbetriebssystem (128, 128') gespeichert sind, so dass durch das Chipkartenbetriebssystem die Schnittstellenfunktion (1 14) und die Speicherfunktion (1 18) des Bootloaders 106 im Wirkbetrieb aufrufbar sind.
17. Elektronisches System mit einer Chipkarte (100) nach einem der vorhergehenden Ansprüche 10 bis 16 und mit einem Chipkartenterminal (144), wobei der Chipkartenterminal einen Speicher (130) zur Speicherung der ausführbaren Programminstruktionen (150) und einen Prozessor (154) zum Lesen der ausführbaren Programminstruktionen aus dem Speicher und zum Senden der ausführbaren Programminstruktionen über einen sicheren Kanal an die Chipkarte aufweist, um die ausführbaren Programminstruktionen in das NVM der Chipkarte zu laden, wobei der Chipkartenterminal Programminstruktionen (152) zur Durchführung derjenigen Schritte eines kryptografischen Protokolls aufweist, welches zusammen mit der zweiten Authentifizierungsfunktion
(140) des Chipkartenbetriebssystems ausführbar ist.
18. Elektronisches System nach Anspruch 17, wobei die Chipkarte und das
Chipkartenterminal jeweils über eine drahtlose Schnittstelle (128, 132) verfü- gen, über welche die Einkopplung von Energie in die Chipkarte von dem
Chipkartenterminal erfolgt sowie auch der Aufbau des sicheren Kanals.
19. Elektronisches System nach Anspruch 17 oder 18, wobei der Chipkartenterminal einen mechanischen Einzug zum Einzug der Chipkarte in das Chipkar- tenterminal aufweist, sodass die Chipkarte während des Ladens der ausführbaren Programminstruktionen in dem Chipkartenterminal verbleibt und erst nach Beendigung des Ladens von dem Chipkartenterminal wieder ausgegeben wird.
EP15778904.1A 2014-10-10 2015-10-01 Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb Pending EP3204850A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014220616.2A DE102014220616A1 (de) 2014-10-10 2014-10-10 Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
PCT/EP2015/072746 WO2016055358A1 (de) 2014-10-10 2015-10-01 Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb

Publications (1)

Publication Number Publication Date
EP3204850A1 true EP3204850A1 (de) 2017-08-16

Family

ID=54293223

Family Applications (1)

Application Number Title Priority Date Filing Date
EP15778904.1A Pending EP3204850A1 (de) 2014-10-10 2015-10-01 Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb

Country Status (4)

Country Link
US (1) US10360042B2 (de)
EP (1) EP3204850A1 (de)
DE (1) DE102014220616A1 (de)
WO (1) WO2016055358A1 (de)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016225360A1 (de) * 2016-12-16 2018-06-21 Bundesdruckerei Gmbh Nachladen kryptographischer Programminstruktionen
CN109426523B (zh) * 2017-08-18 2022-12-06 厦门雅迅网络股份有限公司 基于trustzone技术的双***启动方法及计算机可读存储介质
US10452565B2 (en) * 2018-01-12 2019-10-22 Sunasic Technologies, Inc. Secure electronic device
DE102018005284A1 (de) * 2018-07-03 2019-09-05 Giesecke+Devrient Mobile Security Gmbh Chip-Personalisierung eines eingebetteten Systems durch einen Dritten
FR3105854B1 (fr) * 2019-12-31 2024-07-19 Stmicroelectronics Rousset Sas Système embarqué
WO2021200926A1 (ja) * 2020-04-01 2021-10-07 パナソニックＩｐマネジメント株式会社 ストレージシステム
EP3958114B1 (de) 2020-08-19 2024-04-24 Giesecke+Devrient Mobile Security Germany GmbH Software-eignung
US11907409B2 (en) * 2021-09-29 2024-02-20 Dell Products L.P. Dynamic immutable security personalization for enterprise products
DE102021126509B4 (de) 2021-10-13 2023-05-17 Infineon Technologies Ag Tragbare Chipvorrichtung und Verfahren zum Ausführen eines Softwaremodul-Updates in einer tragbaren Chipvorrichtung
CN117251221B (zh) * 2023-11-16 2024-01-30 深圳市航顺芯片技术研发有限公司 微控制芯片及其管理方法、存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011111698A1 (de) * 2011-08-24 2013-02-28 Fujitsu Technology Solutions Intellectual Property Gmbh Verfahren zum Log-in an einem Computersystem sowie Computerprogramm zum Ablauf auf einem Computersystem
EP2590383A1 (de) * 2011-11-02 2013-05-08 Research In Motion Limited Mobile Kommunikationsvorrichtung mit sicheren Elementdatenverwaltungsfunktionen und zugehörige Verfahren
EP2634693A1 (de) * 2012-02-28 2013-09-04 MIMOON GmbH Verfahren und Vorrichtung zur Interaktion mit einer laufenden Software

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007041370B4 (de) 2007-08-30 2016-06-09 Bundesdruckerei Gmbh Chipkarte, elektronisches Gerät, Verfahren zur Herstellung einer Chipkarte und Verfahren zur Inbenutzungnahme einer Chipkarte
CN103843006B (zh) * 2011-09-30 2017-05-10 国际商业机器公司 用于向用户终端配备操作***的方法和设备
JP5689429B2 (ja) * 2012-02-27 2015-03-25 株式会社日立製作所 認証装置、および、認証方法
DE102012012509B4 (de) 2012-06-22 2021-02-04 Giesecke+Devrient Mobile Security Gmbh Verfahren und Vorrichtung zum Austausch des Betriebssystems eines ressourcenbeschränkten tragbaren Datenträgers
FR2993682B1 (fr) 2012-07-20 2014-08-22 Oberthur Technologies Mise a jour d'un systeme d'exploitation pour element securise
DE102012015573A1 (de) 2012-08-07 2014-02-13 Giesecke & Devrient Gmbh Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
US8894485B2 (en) * 2013-03-18 2014-11-25 Cadillac Jack, Inc. Electronic gaming system with ROM-based media validation

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011111698A1 (de) * 2011-08-24 2013-02-28 Fujitsu Technology Solutions Intellectual Property Gmbh Verfahren zum Log-in an einem Computersystem sowie Computerprogramm zum Ablauf auf einem Computersystem
EP2590383A1 (de) * 2011-11-02 2013-05-08 Research In Motion Limited Mobile Kommunikationsvorrichtung mit sicheren Elementdatenverwaltungsfunktionen und zugehörige Verfahren
EP2634693A1 (de) * 2012-02-28 2013-09-04 MIMOON GmbH Verfahren und Vorrichtung zur Interaktion mit einer laufenden Software

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
DE102014220616A1 (de) 2016-04-14
US20170277546A1 (en) 2017-09-28
WO2016055358A1 (de) 2016-04-14
US10360042B2 (en) 2019-07-23

Similar Documents

Publication Publication Date Title
WO2016055358A1 (de) Verfahren zum laden von ausführbaren programminstruktionen in eine chipkarte im wirkbetrieb
EP2864871B1 (de) Verfahren und vorrichtung zum austausch des betriebssystems eines ressourcenbeschränkten tragbaren datenträgers
DE102013013179A1 (de) Verfahren zum Betreiben eines Sicherheitselements
EP3754530B1 (de) Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten
EP3308278B1 (de) Verfahren zum aktualisieren von personalisierungsdaten
EP2987078B1 (de) Verfahren zum bereitstellen einer applikation auf einem sicherheitsmodul sowie ein solches sicherheitsmodul
EP3215977B1 (de) Verfahren zur änderung einer in einer chipkarte gespeicherten datenstruktur, signaturvorrichtung und elektronisches system
EP2169579B1 (de) Verfahren und Vorrichtung zum Zugriff auf ein maschinenlesbares Dokument
EP1634252B1 (de) Verfahren zum laden von tragbaren datenträgern mit daten
EP3175383B1 (de) Verfahren zur änderung der kontrolldaten einer chipkarte und chipkartensystem
EP3215957B1 (de) Chipkarte, chipkartensystem und verfahren zum zugriff auf eine chipkarte
DE102021126509B4 (de) Tragbare Chipvorrichtung und Verfahren zum Ausführen eines Softwaremodul-Updates in einer tragbaren Chipvorrichtung
EP2486551B1 (de) Personalisieren eines telekommunikationsmoduls
EP3329415B1 (de) Chipkarte mit hauptapplikation und persistenzapplikation erlaubt hauptapplikationupdate ohne die benutzerdaten im persistenzapplikation zu ändern
DE102007027935A1 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
EP1638058A2 (de) Verifizierung eines Datenträgers vor der Installation eines Anwendungsprogramms
DE102007028249A1 (de) Speicherung von Schlüsseln auf einer Chipkarte
DE10218796A1 (de) Verfahren zum Herstellen eines elektronischen Sicherheitsmoduls

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

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

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20170510

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20180327

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

Free format text: STATUS: EXAMINATION IS IN PROGRESS

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

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

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526