EP1922618A1 - Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger - Google Patents

Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger

Info

Publication number
EP1922618A1
EP1922618A1 EP06776465A EP06776465A EP1922618A1 EP 1922618 A1 EP1922618 A1 EP 1922618A1 EP 06776465 A EP06776465 A EP 06776465A EP 06776465 A EP06776465 A EP 06776465A EP 1922618 A1 EP1922618 A1 EP 1922618A1
Authority
EP
European Patent Office
Prior art keywords
command
sequence
operations
commands
portable data
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
EP06776465A
Other languages
English (en)
French (fr)
Inventor
Manfred Hockauf
Frank Schmalz
Torge Kuhn
Werner Ness
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.)
Giesecke and Devrient Mobile Security GmbH
Original Assignee
Giesecke and Devrient 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 Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP1922618A1 publication Critical patent/EP1922618A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the invention relates to a method for executing a sequence of similar commands in a portable data carrier. Furthermore, the invention relates to a portable data carrier.
  • a data connection to a terminal is usually established, via which the portable data carrier commands are transmitted for execution.
  • An example of such an application is the execution of transactions at a terminal of a point-of-sale or a credit institution with a chip card.
  • the personalization of the portable data carrier can also be carried out with the aid of commands which are transmitted to the portable data carrier by a personalization computer.
  • the portable data carrier in particular, is assigned the UPDATE BINARY command defined in the ISO / IEC 7816 standard, with the aid of which data can be written to the EEPROM memory of the portable data carrier.
  • the amount of data that can be transferred with a single UPDATE BINARY command is limited to 255 bytes.
  • the UPDATE BINARY command must therefore be transmitted and executed several times. Since an offset in the file to be described can be coded by means of 2 bytes (P1 and P2), blocks of 255 bytes of the larger amount of data can be successively written into the file one after the other. However, this has the consequence that a relatively long period of time is required for the writing process. A corresponding problem also exists with regard to a number of other types of commands.
  • command types such as the command PUT DATA 7
  • a linked chain of commands Common chaining for extended-length commands
  • Each command of the chain of commands transfers part of the data to be processed. After the receipt of the last data with the last command of a chain, the data of the individual commands of the chain which are hung together are processed as specified by the command type.
  • the invention has for its object to minimize the time required for a portable data carrier for the execution of a sequence of similar commands.
  • the method according to the invention serves to execute a sequence of a plurality of similar commands in a portable data carrier, an identical set of operations being provided for each of these commands.
  • the peculiarity of the method according to the invention is that the execution of operations of the set of operations not required for each command of the sequence is distributed over the sequence of commands such that each of these operations is executed at least once in total and at least one of these operations is executed at least one command is omitted.
  • the invention has the advantage that the sequence of commands can be executed very quickly by omitting one or more operations, the result being ultimately the same as if the complete set of operations were executed for each command. Differences arise only when the sequence of commands, for example because of an error, is not completely processed. The time savings are especially great when time-consuming operations are omitted.
  • a further advantage is that it is possible to carry out the method according to the invention with already existing commands and mechanisms, thus ensuring universal applicability of the method according to the invention.
  • the at least one operation of the set of operations in the execution of the sequence of commands is performed only once in total. With regard to this operation, the greatest possible time saving is realized.
  • the at least one operation is performed at the first or last command of the sequence.
  • at least one further command can be provided between the first and the last command of the sequence, in which a combination of operations deviating from the first and / or last command is executed.
  • several further commands can be provided, in which - A -
  • a further approach to saving processing time is to partially execute operations of a command which is still to be expected in the sequence of the command in advance if unused time is available in the period before the expected command.
  • An example of unused processing time could be a waiting time in the context of communication of the commands or a waiting time for the response of a component of the portable data carrier, such as the execution notification of a memory management unit (MMU) or a cryptographic unit.
  • Unused processing times may, for example, also be periods between sending a response to a command of a sequence and receiving the next command of the sequence.
  • At least one operation is preferably carried out which is reserved for the last command of the sequence in the event of a faultless pass. It can thereby be achieved that the necessary final measures are carried out even in the case of a fault, thereby ensuring the operability of the portable data carrier.
  • the commands are transmitted to the portable data carrier.
  • data is transmitted together with the commands, wherein the total amount of data transmitted with the sequence of commands is greater than that for the transmission with a command of the sequence maximum allowed amount of data.
  • the commands can be linked together for transmission by chaining.
  • the commands can be transmitted, for example, from a terminal to the portable data carrier.
  • the commands are each transmitted in the form of an APDU to the portable data carrier.
  • APDUs are widely used, so that the use of the method according to the invention in many existing systems is possible by the use of APDUs.
  • the commands may, in particular, be commands for writing data to a file of the portable data carrier.
  • defined values can be written to the file when an error occurs.
  • Time savings can be achieved by checking access conditions for writing to the file of the portable data carrier only at the first command of the sequence. Likewise, it saves time if only at the last command of the sequence a check code for the file of the portable data carrier is determined.
  • the sequence of commands can be carried out, for example, as part of a personalization of the portable data carrier. There occur on the one hand on high amounts of data. On the other hand, lead time is a significant cost factor for personalization.
  • the commands can each be the UPDATE BINARY command defined in the ISO / IEC 7816 standard.
  • the portable data carrier according to the invention has a processor unit and a memory.
  • a functionality for executing a sequence of a plurality of similar commands is implemented, for their execution in each case an identical sentence is provided by operations.
  • the peculiarity of the portable data carrier according to the invention is that the functionality distributes the execution of the operations over the sequence of commands such that each operation of the set of operations is performed at least once and at least one operation of the set of operations in the Execution of at least one command is omitted.
  • the portable data carrier according to the invention is designed as a chip card.
  • the portable data carrier is designed in each case as a chip card.
  • the invention is not limited to smart cards, but equally applies to other equipped with computing capacity portable media.
  • a portable data carrier in the sense of the invention is to be regarded as a computer system in which the resources, i. Memory resources and / or computing capacity (computing power) are limited, e.g. a chip card (smart card, microprocessor chip card) or a token or a chip module for installation in a chip card or in a token.
  • the portable data carrier has a body in which a CPU (a microprocessor) is arranged and which may have any standardized or non-standardized shape, for example the shape of a flat chip card without a standard or a standard such as e.g. ISO 7810 (e.g., ID-I, ID-00, ID-000) or volumetric token.
  • the portable data carrier may further have one or more arbitrary interfaces for contactless and / or contact communication with a reader or data processing system (e.g., personal computer, workstation, server).
  • Show it: 1 is a highly simplified block diagram for an embodiment of a system with a smart card and a terminal,
  • Fig. 2 shows the structure of an APDU
  • Fig. 3 shows the procedure of the invention in the processing of a sequence of commands.
  • the chip card 1 shows a greatly simplified block diagram for an exemplary embodiment of a system having a chip card 1 and a terminal 2.
  • the chip card 1 has a processor unit 3 which controls the functional sequences of the chip card 1 and is also referred to as a central processing unit, abbreviated CPU , Furthermore, the chip card 1 has an interface 4 for input and output of data, to which a contact pad 5 is connected.
  • the chip card 1 also has a memory 6, which consists of a non-volatile memory 7, a nonvolatile memory 8 and a volatile memory 9. Alternatively, another structure of the memory 6 is possible.
  • the processor unit 3 is connected to the interface 4, the non-volatile memory 7, the nonvolatile memory 8 and the volatile memory 9.
  • non-volatile memory 7 data is stored, which remain unchanged during the entire life of the chip card 1.
  • data is used in the following very general in the sense of any information, regardless of their content and it is, for example, programs, parameters, personal information, keys, etc. subsumed.
  • the operating system of the chip card 1 is stored in the non-volatile memory 7.
  • the volatile memory 9 serves as a main memory for the processor unit 3, so that secret data, for example, when performing calculations in the volatile memory 9 are cached. In the volatile memory 9, the memory contents are retained only as long as the chip card 1 is supplied with an operating voltage.
  • the nonvolatile memory 8 can be rewritten over and over again during the lifetime of the chip card 1. The respective memory content is maintained even if the chip card 1 is not supplied with the operating voltage.
  • the nonvolatile memory 8 for example, additions to the operating system, application software, keys, personal data, etc. are stored.
  • the device electronics 10 may have similar functional components, as shown for the chip card 1.
  • the contacting unit 11 serves for contact contacting of the contact field 5 of the chip card 1 in order to form a data connection between the terminal 2 and the chip card 1.
  • the terminal 2 may be, for example, a point-of-sale terminal or another terminal for carrying out transactions with the aid of the chip card 1.
  • the terminal 2 can be part of a personalization system with the aid of which a personalization of the chip card 1 is carried out. This case will be used as an example for the further description.
  • APDUs Application Protocol Data Units
  • ISO / IEC 7816 The structure of such APDU is shown in FIG.
  • Fig. 2 shows the structure of an APDU.
  • the APDU comprises a class byte CLA, an instruction byte INS, three parameter bytes P1, P2 and P3 and a data field DATA.
  • the class byte CLA can be used to identify applications and their specific instruction set or used to identify secure messaging.
  • the struction byte INS represents a coding of the one contained in the APDU
  • the data field DATA contains the data sent to the chip card 1, which are intended for processing with the command contained in the APDU.
  • the size of the data field DATA is limited, so that a plurality of APDUs are transmitted successively to the chip card 1 if the data to be transmitted exceeds the size of the data field DATA. In the case of a conventional chip card, this would lead in each case to a complete execution of the command with the data transmitted in each case in the data field DATA for each transmitted APDU. In other words, there would be several similar commands in each case
  • Fig. 3 shows the procedure according to the invention in the execution of a sequence of commands.
  • the illustrated sequence relates to the command UPDATE BINARY, which is transmitted, for example, as part of a personalization of the chip card 1 several times in succession from the terminal 2 to the chip card 1.
  • the process begins with a step Sl, in which an APDU is transmitted from the terminal 2 to the chip card 1.
  • the class byte CLA of the APDU has the value "IX" indicating that at least one more command follows, and the instruction byte INS has the value "D6".
  • This is the coding for the command UPDATE BINARY and therefore also in all other APDUS, which are transmitted in the context of the command sequence from the terminal 2 to the chip card 1, in identical form.
  • the Parameter Byte Pl indicates via a Short File Identifier SFI into which file should be written. Alternatively it is also possible to write to the currently selected file.
  • Pl indicates the high-order byte of the offset.
  • the parameter byte P2 indicates the least significant byte of the offset.
  • Pl and P2 indicate the high order and low order bytes of the offset.
  • the parameter byte P3 indicates the respective length Lc of the data field DATA for all APDUs of the command sequence.
  • the data to be written in are contained in the data field DATA for all APDUs of the command sequence.
  • Step S1 is followed by a step S2, in which the command transmitted with the APDU is executed by the chip card 1.
  • the corresponding file is selected. Furthermore, as part of the execution of the UPDATE BINARY command, the access conditions of the file and, if necessary, other conditions are checked. It also performs actions required by secure messaging. Furthermore, the transmitted data is written into the file, which is preferably applied in the nonvolatile memory 8 of the chip card 1, and a flag is set, which indicates that a sequence of UPDATE BINARY commands is executed in the manner according to the invention. This completes the execution of the command. This means that, for example, the update of the check sum of the file provided in a conventional execution of the UPDATE BINARY command is not performed. The checksum is also referred to as Error Detection Code, EDC for short.
  • EDC Error Detection Code
  • Step S2 is followed by a step S3, in which the chip card 1 informs the terminal 2 that the command has been executed.
  • the terminal 2 then transmits another APDU to the chip card 1 in a step S4.
  • This APDU differs from the APDU transmitted in step S1 only in that the parameter byte Pl definitively indicates the high-order byte of the offset and that the concrete values for the at step Sl designated content may differ.
  • the offset specified in the parameter Bytes Pl and P2 in a variant of Step S4 may have a different value than the offset indicated in Step S1.
  • the data length Lc given in the parameter byte P3 and the data contained in the data field DATA may be different in the steps S1 and S4.
  • the content of the class byte CLA and the instruction byte INS is in the However, steps S1 and S4 are identical, ie they are each the same command with possibly different parameters or data.
  • step S5 The UPDATE BINARY command transmitted in step S4 is executed in a subsequent step S5.
  • This embodiment deviates from the execution at step S2 in a manner that goes beyond what is caused by the mentioned differences in the parameters or data.
  • the access conditions of the file are not checked in step S5, but only a few necessary conditions for the execution of the command are checked.
  • step S6 a step S6 follows, in which the smart card 1 tells the terminal 2 that the command has been executed. It then follows a step S7, in which the terminal 2 of the chip card 1 another APDU with the command
  • command chaining which is also referred to as level 7 chaining
  • level 7 chaining it is possible to mark a defined sequence of commands, so that a command from the operating system of the chip card 1 as the first command of the sequence and another command as the last command of the sequence can be recognized.
  • the operating system is implemented in such a way that the processing steps intended for the complete execution of the command are distributed over the sequence of commands. This means that not all processing steps are performed on all commands.
  • processing steps which serve to ensure the operability can be postponed until the last command of the sequence. In case of premature termination of the sequence, the processing steps to ensure the operability are also performed.
  • no proprietary commands or proprietary mechanisms for linking commands are needed, but the commands and command chaining can be used according to the standard
  • ISO / IEC 7816 can be used.
  • the operating system is modified and extended in such a way that it can use the sequence information available in command chaining to logically combine several commands.
  • the error handling must be adjusted.
  • the command sequence is interrupted and the checksum EDC of the written file is updated. This is necessary, for example, if the parameter byte P1 is a short file identifier and the associated UPDATE BINARY command is not the first command in the sequence. The same applies if a command other than an UPDATE BINARY command is transmitted to the chip card 1, if the four lower-order bits of the CLA class byte change, if the command execution fails, or if secure messaging fails.
  • the file is populated with known content to ensure that all cells of the nonvolatile memory 8 are in a stable state and the checksum EDC is updated.
  • An existing roll-forward mechanism can be used for this.
  • the invention can be used not only in a sequence of several UPDATE BINARY commands, but also in sequences of other commands.

Abstract

Die Erfindung betrifft ein Verfahren zum Ausführen einer Folge von mehreren gleichartigen Kommandos in einem tragbaren Datenträger (1), wobei für eine Ausführung jedes einzelnen dieser Kommandos jeweils ein gleicher Satz von Operationen vorgesehen ist. Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass die Ausführung der Operationen so über die Folge von Kommandos verteilt wird, dass jede Operation des Satzes von Operationen insgesamt wenigstens einmal ausgeführt wird und wenigstens eine Operation des Satzes von Operationen bei der Ausführung wenigstens eines Kommandos ausgelassen wird.

Description

Verfahren zum Ausführen einer Folge von gleichartigen Kommandos in einem tragbaren Datenträger
Die Erfindung betrifft ein Verfahren zum Ausführen einer Folge von gleichartigen Kommandos in einem tragbaren Datenträger. Weiterhin betrifft die Erfindung einen tragbaren Datenträger.
Beim Einsatz eines tragbaren Datenträgers wird in der Regel eine Datenverbindung zu einem Endgerät aufgebaut, über die dem tragbaren Datenträger Kommandos zur Ausführung übermittelt werden. Ein Beispiel für einen derartigen Einsatz ist die Durchführung von Transaktionen an einem Terminal eines Point-of-Sale oder eines Kreditinstituts mit einer Chipkarte. In entsprechender Weise kann auch die Personalisierung des tragbaren Datenträgers mit Hilfe von Kommandos durchgeführt werden, die dem tragbaren Datenträger von einem Personalisierungsrechner übermittelt werden. Dabei wird dem tragbaren Datenträger insbesondere das in der Norm ISO/ IEC 7816 de- finierte Kommando UPDATE BINARY übermittelt, mit dessen Hilfe Daten in den EEPROM-Speicher des tragbaren Datenträgers geschrieben werden können. Allerdings ist die Datenmenge, die mit einem einzelnen Kommando UPDATE BINARY übertragen werden kann, auf 255 Byte begrenzt. Zum Einschreiben großer Datenmengen in den EEPROM-Speicher muss das Kommando UPDATE BINARY somit mehrfach übertragen und ausgeführt werden. Da ein Offset in der zu beschreibenden Datei mittels 2 Bytes (Pl und P2) kodiert werden kann, können schrittweise jeweils Blöcke von 255 Bytes der größeren Datenmenge hintereinander in die Datei geschrieben werden. Dies hat jedoch zur Folge, dass für den Einschreibvorgang eine relativ lange Zeitspanne benötigt wird. Eine entsprechende Problematik besteht auch bezüglich einer Reihe von weiteren Kommandotypen.
Für Kommandotypen, wie beispielsweise das Kommando PUT DATA7 ist es nötig, eine miteinander verknüpfte Kette von Kommandos zu verwenden (Command Chaining für Extended-Length-Kommandos), wenn mehr als 255 Bytes zum tragbaren Datenträger übertragen werden sollen. Gemäß ISO/ IEC 7816-4 zeigt das Bit 5 des CLA-Bytes des Kommandos an, ob das aktuelle Kommando das letzte oder einzige Kommando einer Kette (CLA- Byte mit Bit 5 = 0) oder nicht das letzte Kommando einer Kette ist (CLA-Byte mit Bit 5 = 1). Jedes Kommando der Kette von Kommandos überträgt einen Teil der zu bearbeitenden Daten. Nach dem Empfang der letzten Daten mit dem letzten Kommando einer Kette, werden die aneinander gehängten Daten der einzelnen Kommandos der Kette, wie durch den Kommandotyp vor- gegeben, verarbeitet.
Der Erfindung liegt die Aufgabe zugrunde, die Zeit, die ein tragbarer Datenträger für die Ausführung einer Folge von gleichartigen Kommandos benötigt, möglichst gering zu halten.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und mit einem tragbaren Datenträger gemäß Anspruch 20 gelöst.
Das erfindungsgemäße Verfahren dient der Ausführung einer Folge von mehreren gleichartigen Kommandos in einem tragbaren Datenträger, wobei für eine Ausführung jedes einzelnen dieser Kommandos jeweils ein gleicher Satz von Operationen vorgesehen ist. Die Besonderheit des erfindungsgemäßen Verfahrens besteht darin, dass die Ausführung von nicht für jedes Kommando der Folge notwendigen Operationen des Satzes von Operationen so über die Folge von Kommandos verteilt wird, dass jede dieser Operation insgesamt wenigstens einmal ausgeführt wird und wenigstens eine dieser Operationen bei der Ausführung wenigstens eines Kommandos ausgelassen wird. Die Erfindung hat den Vorteil, dass die Folge von Kommandos durch das Auslassen einer oder mehrerer Operationen sehr schnell abgearbeitet werden kann, wobei letztendlich das gleiche Ergebnis erzielt wird, wie wenn für jedes Kommando jeweils der komplette Satz von Operationen ausgeführt würde. Unterschiede ergeben sich lediglich dann, wenn die Folge von Kommandos, beispielsweise wegen eines Fehlers, nicht vollständig abgearbeitet wird. Die Zeitersparnis ist besonders groß, wenn zeitaufwendige Operationen ausgelassen werden. Ein weiterer Vorteil besteht darin, dass die Durchführung des erfindungsgemäßen Verfahrens mit bereits vorhandenen Kom- mandos und Mechanismen möglich ist und somit eine universelle Einsetz- barkeit des erfindungsgemäßen Verfahrens gewährleistet ist.
Insbesondere hängt es von der Position des Kommandos in der Folge ab, welche Operationen bei diesem Kommando ausgeführt werden. Ein derarti- ges Kriterium ist mit wenig Aufwand implementierbar. Besonders vorteilhaft ist es, wenn wenigstens eine Operation des Satzes von Operationen bei der Ausführung der Folge von Kommandos insgesamt nur einmal ausgeführt wird. Im Hinblick auf diese Operation ist dann der größtmögliche Zeitgewinn realisiert. Vorzugsweise wird die wenigstens eine Operation beim ers- ten oder beim letzten Kommando der Folge ausgeführt.
Im Rahmen des erfindungsgemäßen Verfahrens kann vorgesehen sein, dass beim ersten Kommando der Folge eine erste Kombination von Operationen und beim letzten Kommando der Folge eine davon abweichende zweite Kombination von Operationen ausgeführt wird. Weiterhin kann zwischen dem ersten und dem letzten Kommando der Folge wenigstens ein weiteres Kommando vorgesehen sein, bei dem eine vom ersten und/ oder vom letzten Kommando abweichende Kombination von Operationen ausgeführt wird. Insbesondere können mehrere weitere Kommandos vorgesehen sein, bei de- - A -
nen jeweils die gleiche Kombination von Operationen ausgeführt wird. Auf diese Weise können notwendige einleitende und abschließende Maßnahmen vorgenommen werden und dazwischen die Kommandos besonders effizient ausgeführt werden.
Ein weiterer Ansatz Verarbeitungszeit einzusparen ist es, Operationen eines in der Folge der Kommandos noch zu erwartenden Kommandos teilweise bereits vorab auszuführen, wenn in dem Zeitraum vor dem zu erwartenden Kommando ungenutzte Zeit zur Verfügung steht. Ein Beispiel für ungenutz- te Verarbeitungszeit könnte eine Wartezeit im Rahmen der Kommunikation der Kommandos sein oder eine Wartezeit auf die Antwort einer Komponente des tragbaren Datenträgers, wie beispielsweise die Vollzugsmeldung einer Speicherverwaltungseinheit (MMU) oder einer kryptographischen Einheit. Ungenutzte Verarbeitungszeiten können beispielsweise auch Zeiträume zwi- sehen dem Senden einer Antwort auf ein Kommando einer Folge und dem Empfangen des nächsten Kommandos der Folge sein.
Beim Auftreten eines Fehlers vor der Ausführung des letzten Kommandos der Folge wird vorzugsweise wenigstens eine Operation ausgeführt, die bei einem fehlerfreien Durchlauf dem letzten Kommando der Folge vorbehalten ist. Dadurch kann erreicht werden, dass auch bei einem Fehler die notwendigen abschließenden Maßnahmen durchgeführt werden und dadurch die Betriebsfähigkeit des tragbaren Datenträgers gesichert wird.
Bei einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens werden die Kommandos an den tragbaren Datenträger übermittelt. Insbesondere werden zusammen mit den Kommandos Daten übermittelt, wobei die insgesamt mit der Folge von Kommandos übermittelte Datenmenge größer ist als die für die Übermittlung mit einem Kommando der Folge maximal zulässige Datenmenge. Die Kommandos können für die Übermittlung durch Chaining miteinander verbunden werden. Die Kommandos können beispielsweise von einem Endgerät an den tragbaren Datenträger übermittelt werden. Vorzugsweise werden die Kommandos jeweils in Form einer APDU an den tragbaren Datenträger übermittelt. APDUs werden vielfältig eingesetzt, so dass durch die Verwendung von APDUs ein Einsatz des erfindungsgemäßen Verfahrens bei vielen bestehenden Systemen möglich ist.
Bei den Kommandos kann es sich insbesondere um Kommandos zum Schreiben von Daten in eine Datei des tragbaren Datenträgers handeln. Um einen Undefinierten Zustand zu vermeiden, können beim Auftreten eines Fehlers definierte Werte in die Datei geschrieben werden. Ein Zeitgewinn kann dadurch erreicht werden, dass lediglich beim ersten Kommando der Folge Zugriffsbedingungen zum Schreiben in die Datei des tragbaren Daten- trägers geprüft werden. Ebenso spart es Zeit, wenn lediglich beim letzten Kommando der Folge ein Prüfcode für die Datei des tragbaren Datenträgers ermittelt wird.
Die Folge von Kommandos kann beispielsweise im Rahmen einer Personali- sierung des tragbaren Datenträgers ausgeführt werden. Dort treten zum einen hohe Datenmengen auf. Zum anderen ist die Durchlaufzeit ein maßgeblicher Kostenfaktor für die Personalisierung. Bei den Kommandos kann es sich jeweils um das in der Norm ISO/ IEC 7816 definierte Kommando UPDATE BINARY handeln.
Der erfindungsgemäße tragbare Datenträger weist eine Prozessoreinheit und einen Speicher auf. Im erfindungsgemäßen tragbaren Datenträger ist eine Funktionalität zum Ausführen einer Folge von mehreren gleichartigen Kommandos implementiert, für deren Ausführung jeweils ein gleicher Satz von Operationen vorgesehen ist. Die Besonderheit des erfindungsgemäßen tragbare Datenträgers besteht darin, dass die Funktionalität eine Verteilung der Ausführung der Operationen über die Folge von Kommandos derart vornimmt, dass jede Operation des Satzes von Operationen insgesamt we- nigstens einmal ausgeführt wird und wenigstens eine Operation des Satzes von Operationen bei der Ausführung wenigstens eines Kommandos ausgelassen wird. Vorzugsweise ist der erfindungsgemäße tragbare Datenträger als eine Chipkarte ausgebildet.
Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten Ausführungsbeispiele erläutert, bei denen der tragbare Datenträger jeweils als eine Chipkarte ausgebildet ist. Die Erfindung ist allerdings nicht auf Chipkarten beschränkt, sondern bezieht sich gleichermaßen auch auf andere mit Rechenkapazität ausgestattete tragbare Datenträger. Dabei ist als ein tragbarer Datenträger im Sinn der Erfindung ein Rechnersystem anzusehen, bei dem die Ressourcen, d.h. Speicherressourcen und/ oder Rechenkapazität (Rechenleistung) begrenzt sind, z.B. eine Chipkarte (Smart Card, Mikroprozessor-Chipkarte) oder ein Token oder ein Chipmodul zum Einbau in eine Chipkarte oder in ein Token. Der tragbare Datenträger hat einen Körper, in dem eine CPU (ein Mikroprozessor) angeordnet ist und der jede beliebige standardisierte oder nicht standardisierte Gestalt haben kann, beispielsweise die Gestalt einer flachen Chipkarte ohne Norm oder nach einer Norm wie z.B. ISO 7810 (z.B. ID-I, ID-00, ID-000) oder die eines volumigen Tokens. Der tragbare Datenträger kann weiter eine oder mehrere beliebige Schnittstellen für kontaktlose und/ oder kontaktbehaftete Kommunikation mit einem Lesegerät oder Datenverarbeitungssystem (z.B. Personal Computer, Workstation, Server) haben.
Es zeigen: Fig. 1 ein stark vereinfachtes Blockschaltbild für ein Ausführungsbeispiel eines Systems mit einer Chipkarte und einem Endgerät,
Fig. 2 die Struktur einer APDU und
Fig. 3 die erfindungsgemäße Vorgehensweise bei der Abarbeitung einer Folge von Kommandos.
Fig. 1 zeigt ein stark vereinfachtes Blockschaltbild für ein Ausführungsbeispiel eines Systems mit einer Chipkarte 1 und einem Endgerät 2. Die Chipkarte 1 weist eine Prozessoreinheit 3 auf, welche die Funktionsabläufe der Chipkarte 1 steuert und auch als Central Processing Unit, abgekürzt CPU, bezeichnet wird. Weiterhin weist die Chipkarte 1 eine Schnittstelle 4 zur Ein- und Ausgabe von Daten auf, an die ein Kontaktfeld 5 angeschlossen ist. Beim dargestellten Ausführungsbeispiel weist die Chipkarte 1 zudem einen Speicher 6 auf, der aus einem Permanentspeicher 7, einem nichtflüchtigen Speicher 8 und einem flüchtigen Speicher 9 besteht. Alternativ dazu ist auch ein anderer Aufbau des Speichers 6 möglich. Die Prozessoreinheit 3 ist mit der Schnittstelle 4, dem Permanentspeicher 7, dem nichtflüchtigen Speicher 8 und dem flüchtigen Speicher 9 verbunden.
Im Permanentspeicher 7 sind Daten abgelegt, die während der gesamten Lebensdauer der Chipkarte 1 unverändert erhalten bleiben. Dabei wird der Begriff Daten im folgenden sehr allgemein im Sinne beliebiger Informationen unabhängig von deren Inhalt verwendet und es werden darunter beispielsweise Programme, Parameter, personenbezogene Angaben, Schlüssel usw. subsumiert. Insbesondere ist im Permanentspeicher 7 das Betriebssystem der Chipkarte 1 gespeichert. Der flüchtige Speicher 9 dient als Arbeitsspeicher für die Prozessoreinheit 3, so dass geheime Daten beispielsweise bei der Durchführung von Berechnungen im flüchtigen Speicher 9 zwischengespeichert werden. Im flüchtigen Speicher 9 bleibt der Speicherinhalt nur solange erhalten, wie die Chipkarte 1 mit einer Betriebspannung versorgt wird.
Der nichtflüchtige Speicher 8 kann während der Lebensdauer der Chipkarte 1 immer wieder neu beschrieben werden. Der jeweilige Speicherinhalt bleibt auch dann erhalten, wenn die Chipkarte 1 nicht mit der Betriebsspannung versorgt wird. Im nichtflüchtigen Speicher 8 sind beispielsweise Ergänzungen zum Betriebssystem, Anwendungssoftware, Schlüssel, personenbezogene Daten usw. abgelegt.
Vom Endgerät 2 sind lediglich eine Geräteelektronik 10 und eine an die Geräteelektronik 10 angeschlossene Kontaktiereinheit 11 dargestellt. Die Geräteelektronik 10 kann ähnliche Funktionskomponenten aufweisen, wie für die Chipkarte 1 dargestellt. Die Kontaktiereinheit 11 dient der berührenden Kon- taktierung des Kontaktfelds 5 der Chipkarte 1, um eine Datenverbindung zwischen dem Endgerät 2 und der Chipkarte 1 auszubilden. Beim Endgerät 2 kann es sich beispielsweise um ein Point-of-Sale Terminal oder um ein sonstiges Terminal zur Durchführung von Transaktionen mit Hilfe der Chipkarte 1 handeln. Ebenso kann das Endgerät 2 ein Bestandteil einer Personalisie- rungsanlage sein, mit deren Hilfe eine Personalisierung der Chipkarte 1 durchgeführt wird. Dieser Fall wird für die weitere Beschreibung beispielhaft herangezogen.
Über die Datenverbindung werden der Chipkarte 1 vom Endgerät 2 Kommandos zur Ausführung übermittelt. Diese Kommandos können insbeson- dere in Form von APDUs (Application Protocol Data Units) nach ISO/ IEC 7816 übermittelt werden. Die Struktur einer solchen APDU ist in Fig. 2 dargestellt.
Fig. 2 zeigt die Struktur einer APDU. Die APDU weist ein Class-Byte CLA, ein Instruction-Byte INS, drei Parameter-Bytes Pl, P2 und P3 sowie ein Datenfeld DATA auf. Das Class-Byte CLA kann beispielsweise dazu benutzt werden, Anwendungen und ihren spezifischen Befehlssatz zu kennzeichnen oder zur Kennzeichnung von Secure Messaging benutzt werden. Das In- struction-Byte INS stellt eine Kodierung des in der APDU enthaltenen
Kommandos dar, wobei das Kommando durch die Parameter-Bytes Pl, P2 und P3 näher spezifiziert wird. Das Datenfeld DATA enthält die zur Chipkarte 1 gesendeten Daten, die für eine Bearbeitung mit dem in der APDU enthaltenen Kommando vorgesehen sind. Die Größe des Datenfelds DATA ist begrenzt, so dass mehrere APDUs nacheinander an die Chipkarte 1 übermittelt werden, falls die zu übertragenden Daten die Größe des Datenfelds DATA überschreiten. Dies würde bei einer herkömmlichen Chipkarte pro übermittelter APDU jeweils zu einer vollständigen Ausführung des Kommandos mit den jeweils im Datenfeld DATA übermittelten Daten führen. Mit anderen Worten es würden mehrere gleichartige Kommandos jeweils in
Form einer APDU an die Chipkarte übertragen und nach jeder Übertragung eines Kommandos sämtliche für das Kommando vorgesehene Bearbeitungsschritte ausgeführt. Im Rahmen der Erfindung werden ebenfalls mehrere gleichartige Kommandos jeweils in Form einer APDU an die Chipkarte 1 übertragen. Allerdings führt die Chipkarte 1 nicht nach jeder Übertragung sämtliche für das Kommando vorgesehene Bearbeitungsschritte aus, sondern verteilt die Ausführung der Bearbeitungsschritte auf mehrere Übertragungen. Dies bedeutet, dass nach jeder Übertragung jeweils nur ein Teil der für das Kommando vorgesehenen Bearbeitungsschritte ausgeführt wird und somit die Mehrfachausführung von Bearbeitungsschritten, deren Ausführung nicht für jede Übertragung zwangsweise erforderlich ist, reduziert oder sogar vermieden werden kann. Dies führt zu einer schnelleren Abarbeitung der Folge von Kommandos durch die Chipkarte 1. Die diesbezügliche Vor- gehensweise wird anhand von Fig. 3 für das Kommando UPDATE BINARY näher erläutert.
Fig. 3 zeigt die erfindungsgemäße Vorgehensweise bei der Abarbeitung einer Folge von Kommandos. Der dargestellte Ablauf bezieht sich auf das Kom- mando UPDATE BINARY, das beispielsweise im Rahmen einer Personalisierung der Chipkarte 1 mehrmals hintereinander vom Endgerät 2 an die Chipkarte 1 übermittelt wird. Der Ablauf beginnt mit einem Schritt Sl, in dem eine APDU vom Endgerät 2 an die Chipkarte 1 übermittelt wird. Das Class- Byte CLA der APDU weist den Wert „IX" auf, der angibt, dass wenigstens ein weiteres Kommando folgt. Das Instruction-Byte INS weist den Wert „D6" auf. Dies ist die Kodierung für das Kommando UPDATE BINARY und somit auch in allen weiteren APDUS, die im Rahmen der Kommandofolge vom Endgerät 2 an die Chipkarte 1 übermittelt werden, in identischer Form vorhanden. Das Parameter Byte Pl gibt über einen Short File Identifier SFI an, in welche Datei geschrieben werden soll. Alternativ besteht auch die Möglichkeit, dass in die aktuell selektierte Datei geschrieben werden soll. In diesem Fall gibt Pl das höherwertige Byte des Offsets an. Das Parameter Byte P2 gibt das niederwertige Byte des Offsets an. Bei allen folgenden APDUs der Kommandofolge geben Pl und P2 das höherwertige und das niederwertige Byte des Offsets an. Das Parameter Byte P3 gibt bei allen APDUs der Kom- mandof olge die jeweilige Länge Lc des Datenfelds DATA an. Die jeweils einzuschreibenden Daten sind bei allen APDUs der Kommandofolge im Datenfeld DATA enthalten. An Schritt Sl schließt sich ein Schritt S2 an, in dem das mit der APDU übertragene Kommando von der Chipkarte 1 ausgeführt wird. Wenn das Parameter Byte Pl einen Short File Identifier enthält, wird die zugehörige Datei ausgewählt. Weiterhin werden im Rahmen der Ausführung des Kommandos UPDATE BINARY die Zugriffsbedingungen der Datei und gegebenenfalls weitere Bedingungen geprüft. Außerdem werden Maßnahmen durchgeführt, die im Rahmen des Secure Messaging erforderlich sind. Weiterhin werden die übermittelten Daten in die Datei geschrieben, die vorzugsweise im nichtflüchtigen Speicher 8 der Chipkarte 1 angelegt ist und es wird ein Flag ge- setzt, welches anzeigt, dass eine Folge von UPDATE BINARY Kommandos auf die erfindungsgemäße Weise abgearbeitet wird. Damit ist die Ausführung des Kommandos beendet. Dies bedeutet, dass beispielsweise die bei einer herkömmlichen Ausführung des Kommandos UPDATE BINARY vorgesehene Aktualisierung der Prüf summe der Datei nicht durchgeführt wird. Die Prüfsumme wird auch als Error Detection Code, kurz EDC, bezeichnet.
Auf Schritt S2 folgt ein Schritt S3, in dem die Chipkarte 1 dem Endgerät 2 mitteilt, dass das Kommando ausgeführt wurde. Daraufhin übermittelt das Endgerät 2 in einem Schritt S4 eine weitere APDU an die Chipkarte 1. Diese APDU unterscheidet sich von der in Schritt Sl übermittelten APDU lediglich darin, dass das Parameter Byte Pl definitiv das höherwertige Byte des Offsets angibt und dass die konkreten Werte für die bei Schritt Sl bezeichneten Inhalte abweichen können. Beispielsweise kann der bei einer Variante des Schritts S4 in den Parameter Bytes Pl und P2 angegebene Offset einen ande- ren Wert haben als der bei Schritt Sl angegebene Offset. Ebenso können die im Parameter Byte P3 angegebene Datenlänge Lc und die im Datenfeld DATA enthaltenen Daten in den Schritten Sl und S4 unterschiedlich sein. Der Inhalt des Class-Bytes CLA und des Instruction-By tes INS ist bei den Schritten Sl und S4 jedoch identisch, d. h. es handelt sich jeweils um das gleiche Kommando mit ggf. unterschiedlichen Parametern bzw. Daten.
Das im Schritt S4 übermittelte Kommando UPDATE BINARY wird in einem sich anschließenden Schritt S5 ausgeführt. Diese Ausführung weicht von der Ausführung bei Schritt S2 in einer Weise ab, die über das hinausgeht, was durch die genannten Unterschiede der Parameter bzw. Daten verursacht wird. So werden bei Schritt S5 die Zugriffsbedingungen der Datei nicht geprüft, sondern es werden nur einige notwendige Bedingungen für die Aus- führung des Kommandos geprüft. Zudem werden im Rahmen der Kommandoausführung lediglich die Maßnahmen für das Secure Messaging durchgeführt und die Daten in die Datei geschrieben. An Schritt S5 schließt sich ein Schritt S6 an, in dem die Chipkarte 1 dem Endgerät 2 mitteilt, dass das Kommando ausgeführt wurde. Es folgt dann ein Schritt S7, in dem das Endgerät 2 der Chipkarte 1 eine weitere APDU mit dem Kommando
UPDATE BINARY übermittelt. Zusätzlich zu den Unterschieden in den konkreten Werten für den Offset sowie der Länge und des Inhalts des Datenfelds DATA unterscheitet sich diese APDU von der im Schritt S4 übermittelten APDU darin, dass das Class-Byte CLA den Wert „OX" aufweist. Dieser Wert gibt an, dass in der Kommandofolge kein weiteres Kommando folgen wird. Die Ausführung des Kommandos UPDATE BINARY erfolgt in einem sich anschließenden Schritt S8. Bei der Ausführung werden analog zu Schritt S5 die Zugriffsbedingungen der Datei wiederum nicht geprüft, sondern lediglich einige notwendige Bedingungen. Weiterhin werden Maßnahmen für das Secure Messaging durchgeführt und die Daten in die Datei geschrieben. Anders als bei der Ausführung des Kommandos in den Schritten S2 und S5 wird beim Schritt S8 die Prüfsumme der Datei aktualisiert und es wird das in Schritt S2 gesetzte Flag wieder gelöscht. Auf Schritt S8 folgt ein Schritt S9, in dem die Chipkarte 1 dem. Endgerät 2 mitteilt, dass das Kommando ausgeführt wurde. Damit ist die Abarbeitung der Kommandofolge beendet.
Durch das vorstehend beschriebene Command Chaining, das auch als Level 7 Chaining bezeichnet wird, ist es möglich eine definierte Folge von Kommandos zu kennzeichnen, so dass ein Kommando vom Betriebssystem der Chipkarte 1 als erstes Kommando der Folge und ein weiteres Kommando als letztes Kommando der Folge erkannt werden kann. Zwischen dem ersten und dem letzten Kommando der Folge können beliebig viele Kommandos liegen. Das Betriebssystem wird so implementiert, dass die für die vollständige Ausführung des Kommandos vorgesehenen Bearbeitungsschritte über die Folge von Kommandos verteilt ausgeführt werden. Dies bedeutet, dass nicht alle Bearbeitungsschritte bei allen Kommandos ausgeführt werden. Insbesondere können Bearbeitungsschritte, welche dazu dienen, die Betriebs- fähigkeit zu sichern, bis zum letzten Kommando der Folge zurückgestellt werden. Bei einem vorzeitigen Abbruch der Folge werden die Bearbeitungsschritte zur Sicherstellung der Betriebsfähigkeit ebenfalls durchgeführt. Für diese Vorgehensweise werden keine proprietären Kommandos oder propriä- teren Mechanismen zur Verkettung von Kommandos benötigt, sondern es können die Kommandos und das Command Chaining gemäß der Norm
ISO/ IEC 7816 verwendet werden. Damit dies möglich ist, wird das Betriebssystem so modifiziert und erweitert, dass es die beim Command Chaining vorhandene Sequenzinformation zur logischen Zusammenfassung mehrerer Kommandos nutzen kann.
Insbesondere muss die Fehlerbehandlung angepasst werden. So wird in einer Reihe von Situationen die Kommandofolge unterbrochen und die Prüfsumme EDC der geschriebenen Datei aktualisiert. Dies ist beispielsweise dann erforderlich, wenn das Parameter-Byte Pl einen Short File Identifier aufweist und das zugehörige UPDATE BINARY Kommando nicht das erste Kommando der Folge ist. Gleiches gilt auch, wenn ein anderes Kommando als ein UPDATE BINARY Kommando an die Chipkarte 1 übermittelt wird, wenn sich die vier niederwertigen Bits des Class-Bytes CLA ändern, wenn die Kommandoausführung auf einen Fehler läuft oder wenn das Secure Messaging fehlschlägt.
Fällt die Stromzufuhr während der Kommandoausführung aus, dann wird die Datei mit einem bekannten Inhalt gefüllt, um sicherzugehen, dass alle Zellen des nichtflüchtigen Speichers 8 einen stabilen Zustand aufweisen und die Prüfsumme EDC wird aktualisiert. Hierfür kann ein bereits existierender Roll-Forward-Mechanismus verwendet werden.
Die Erfindung ist nicht nur bei einer Folge von mehreren UPDATE BINARY Kommandos, sondern auch bei Folgen von anderen Kommandos einsetzbar.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren in einem tragbaren Datenträger (1) zum Verarbeiten einer Folge von mehreren Kommandos eines Kommandotyps, wobei für eine Verarbeitung von Kommandos des Kommandotyps das Ausführen eines Satzes von Operationen vorgesehen ist,
Ausführen von ersten Operationen aus dem Satz von Operationen, die jeweils für die Verarbeitung eines einzelnen Kommandos aus der Folge notwendig sind, spätestens bei der Verarbeitung des einzelnen Kommandos, gekennzeichnet durch
Ausführen zweiter Operationen aus dem Satz von Operationen, die nicht bei der Verarbeitung jedes einzelnen Kommandos aus der Folge notwendig sind, so über die Folge von Kommandos verteilt, dass jede zweite Operation des Satzes von Operationen insgesamt wenigstens einmal ausgeführt wird und wenigstens eine der zweiten Operationen bei der Verarbeitung wenigstens eines Kommandos ausgelassen wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass es von der Position des Kommandos in der Folge abhängt, welche zweite Opera- tionen bei diesem Kommando ausgeführt werden.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass es von dem Kommandotyp des Kommandos in der Folge abhängt, welche zweite Operationen bei diesem Kommando ausgeführt werden.
4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die zweiten Operationen des Satzes von Operationen bei der Ausführung der Folge von Kommandos insgesamt nur einmal ausgeführt werden.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass die zweite Operation beim ersten oder beim letzten Kommando der Folge ausgeführt wird.
6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem ersten Kommando der Folge eine erste Kombination von Operationen, bei einem zweiten Kommando der Folge eine zweite davon abweichende Kombination von Operationen und beim letzten Kommando der Folge eine weitere abweichende dritte Kombination von Operationen ausgeführt wird.
7. Verfahren nach einem der vorhergehenden Ansprüche, gekennzeichnet durch, Umschalten in einen Verarbeitungsmodus zur Optimie- rung der Kommando Verarbeitungszeit, wenn erkannt wird, dass ein
Kommando aus einer Folge von Kommandos zu verarbeiten ist.
8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die zweiten Operationen Prüfungsoperationen umfassen, die vorzugsweise der Sicherung der Integrität der Daten auf dem tragbaren Datenträger dienen, wie beispielsweise Zugriffsrechte prüfen oder Prüf summen berechnen, und/ oder die zweiten Operationen Sicherungsoperationen umfassen, die den ordnungsgemäßen Betrieb des tragbaren Datenträgers absichern.
9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass vorbereitend für die Verarbeitung eines noch zu erwartenden einzelnen Kommandos der Folge zumindest eine erste Operation des zu erwartenden einzelnen Kommandos vorab ausge- führt wird.
10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass beim Auftreten eines Fehlers vor der Ausführung des letzten Kommandos der Folge wenigstens eine Operation ausgeführt wird, die bei einem fehlerfreien Durchlauf dem letzten Kommando der Folge vorbehalten ist.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, dass zusam- men mit den Kommandos Daten übermittelt werden, wobei die insgesamt mit der Folge von Kommandos übermittelte Datenmenge größer ist als die für die Übermittlung mit einem Kommando der Folge maximal zulässige Datenmenge.
12. Verfahren nach einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass die Kommandos für die Übermittlung durch Verkettung (Chaining) miteinander verbunden werden.
13. Verfahren nach Anspruch 12, dadurch gekennzeichnet, dass der Kommandotyp die Übermittlung der übergroßen Datenmenge durch eine Folge von Kommandos des Kommandotyps auch ohne Verkettung gestattet.
14. Verfahren nach einem der Ansprüche 10 bis 13, dadurch gekenn- zeichnet, dass die Kommandos jeweils in Form einer APDU von einem Endgerät (2) an den tragbaren Datenträger (1) übermittelt werden.
15. Verfahren nach einem der vorhergehenden Ansprüche, dadurch ge- kennzeichnet, dass es sich bei den Kommandos um Kommandos zum Schreiben von Daten in eine Datei des tragbaren Datenträgers (1) handelt.
16. Verfahren nach Anspruch 15, dadurch gekennzeichnet, dass beim
Auftreten eines Fehlers definierte Werte in die Datei geschrieben werden.
17. Verfahren nach einem der Ansprüche 15 oder 16, dadurch gekenn- zeichnet, dass lediglich beim ersten Kommando der Folge Zugriffsbedingungen zum Schreiben in die Datei des tragbaren Datenträgers (1) geprüft werden.
18. Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekenn- zeichnet, dass lediglich beim letzten Kommando der Folge ein Prüfcode für die Datei des tragbaren Datenträgers (1) ermittelt wird.
19. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Folge von Kommandos im Rahmen einer Per- sonalisierung des tragbaren Datenträgers (1) ausgeführt wird.
20. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass es sich bei den Kommandos jeweils um das in der Norm ISO/ IEC 7816 definierte Kommando UPDATE BINARY han- delt.
21. Tragbarer Datenträger mit einer Prozessoreinheit (3) und einem Speicher (6), wobei im tragbaren Datenträger (1) eine Funktionalität zum Ausführen einer Folge von mehreren gleichartigen Kommandos imp- lementiert ist, für deren Ausführung jeweils ein gleicher Satz von O- perationen vorgesehen ist, dadurch gekennzeichnet, dass die Funktionalität eine Verteilung der Ausführung der Operationen über die Folge von Kommandos derart vornimmt, dass jede Operation des Sat- zes von Operationen insgesamt wenigstens einmal ausgeführt wird und wenigstens eine Operation des Satzes von Operationen bei der Ausführung wenigstens eines Kommandos ausgelassen wird.
22. Tragbarer Datenträger nach Anspruch 21, dadurch gekennzeichnet, dass er als eine Chipkarte ausgebildet ist.
EP06776465A 2005-08-01 2006-07-27 Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger Ceased EP1922618A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE200510036069 DE102005036069A1 (de) 2005-08-01 2005-08-01 Verfahren zum Ausführen einer Folge von gleichartigen Kommandos in einem tragbaren Datenträger
PCT/EP2006/007452 WO2007014699A1 (de) 2005-08-01 2006-07-27 Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger

Publications (1)

Publication Number Publication Date
EP1922618A1 true EP1922618A1 (de) 2008-05-21

Family

ID=37156046

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06776465A Ceased EP1922618A1 (de) 2005-08-01 2006-07-27 Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger

Country Status (3)

Country Link
EP (1) EP1922618A1 (de)
DE (1) DE102005036069A1 (de)
WO (1) WO2007014699A1 (de)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102007027935A1 (de) 2007-06-18 2008-12-24 Giesecke & Devrient Gmbh Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0559205A1 (de) * 1992-03-06 1993-09-08 Kabushiki Kaisha Toshiba Datenverarbeitungssystem

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0740225B2 (ja) * 1985-12-25 1995-05-01 日本電気株式会社 プログラムスキツプ動作制御方式
US5867699A (en) * 1996-07-25 1999-02-02 Unisys Corporation Instruction flow control for an instruction processor
US6880074B2 (en) * 2000-12-22 2005-04-12 International Business Machines Corporation In-line code suppression
US7065757B2 (en) * 2001-09-28 2006-06-20 Hewlett-Packard Development Company, L.P. Efficient compilation of family of related functions
US20030135848A1 (en) * 2001-12-21 2003-07-17 Hitachi, Ltd. Use of multiple procedure entry and/or exit points to improve instruction scheduling
US7783573B2 (en) * 2004-01-13 2010-08-24 Microsoft Corporation Performance optimized smartcard transaction management

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0559205A1 (de) * 1992-03-06 1993-09-08 Kabushiki Kaisha Toshiba Datenverarbeitungssystem

Non-Patent Citations (1)

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

Also Published As

Publication number Publication date
WO2007014699A1 (de) 2007-02-08
DE102005036069A1 (de) 2007-02-08

Similar Documents

Publication Publication Date Title
DE10020093A1 (de) Datenintegrität bei Smartcard-Transaktionen
DE3743639A1 (de) Ic-karte und system zur ueberpruefung ihrer funktionstuechtigkeit
DE10164415A1 (de) Verfahren und Anordnung zur Programmierung und Verifizierung von EEPROM-Pages sowie ein entsprechendes Computerprogrammprodukt und ein entsprechendes computerlesbares Speichermedium
DE19626337C2 (de) Verarbeitung langer Nachrichten in einer Prozessorkarte
WO2004086220A2 (de) Kontrollierte ausführung eines für eine virtuelle maschine vorgesehenen programms auf einem tragbaren datenträger
DE102005022019A1 (de) Sichere Verarbeitung von Daten
EP0935214B1 (de) Chipkarte mit integrierter Schaltung
DE4429969A1 (de) Verfahren für einen Programmpaketeaustausch in einem Mehrrechnersystem und Rechner dafür
DE69911174T2 (de) System und verfahren zur kontrolle des zugangs zu dem computercode in einer chipkarte
WO2007014699A1 (de) Verfahren zum ausführen einer folge von gleichartigen kommandos in einem tragbaren datenträger
EP1932122A2 (de) Verfahren zur initialisierung und/oder personalisierung eines tragbaren datenträgers
WO2001001338A1 (de) Verfahren zur datenübertragung und zur speicherverwaltung sowie datenträger
EP1543411B1 (de) Prozessor mit expliziter angabe über zu sichernde informationen bei unterprogrammsprüngen
EP1308842B1 (de) Verfahren und Vorrichtung zur Verwaltung eines Datenspeichers
WO1998041880A2 (de) Integrierte schaltung und verfahren zum testen der integrierten schaltung
EP1634252B1 (de) Verfahren zum laden von tragbaren datenträgern mit daten
EP0977160B1 (de) Verfahren und Datenverarbeitungsanordnung zum gesicherten Ausführen von Befehlen
DE69909118T2 (de) Vorrichtung und verfahren zur sicherung einer integrierten schaltung
EP2012280A2 (de) Tragbarer Datenträger und Verfahren zur Personalisierung eines tragbaren Datenträgers
EP4040324A1 (de) Chip-initialisierung mit betriebssystemladen
EP1968073B1 (de) Verfahren zum Einschreiben von Daten in einen Speicher eines tragbaren Datenträgers
WO2006133934A1 (de) Verfahren zum betreiben eines tragbaren datenträgers
DE19930144C1 (de) Verfahren zum Erkennen von fehlerhaften Speicherzugriffen in prozessorgesteuerten Einrichtungen
EP2659349B1 (de) Verfahren zum zurücksetzen eines dateisystems
WO2024074295A1 (de) Verfahren zum statischen allozieren und zuweisen von informationen zu speicherbereichen, informationstechnisches system und fahrzeug

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

AK Designated contracting states

Kind code of ref document: A1

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

RIN1 Information on inventor provided before grant (corrected)

Inventor name: NESS, WERNER

Inventor name: KUHN, TORGE

Inventor name: SCHMALZ, FRANK

Inventor name: HOCKAUF, MANFRED

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20161104

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

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GMBH

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