WO2004104916A2 - Laden eines ausführbaren programms in einen tragbaren datenträger - Google Patents

Laden eines ausführbaren programms in einen tragbaren datenträger Download PDF

Info

Publication number
WO2004104916A2
WO2004104916A2 PCT/EP2004/005365 EP2004005365W WO2004104916A2 WO 2004104916 A2 WO2004104916 A2 WO 2004104916A2 EP 2004005365 W EP2004005365 W EP 2004005365W WO 2004104916 A2 WO2004104916 A2 WO 2004104916A2
Authority
WO
WIPO (PCT)
Prior art keywords
file
access right
data carrier
loading
loading process
Prior art date
Application number
PCT/EP2004/005365
Other languages
English (en)
French (fr)
Other versions
WO2004104916A3 (de
Inventor
Erich Englbrecht
Robert Hockauf
Thorsten Ulbricht
Rudolf Schubert
Original Assignee
Giesecke & 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 & Devrient Gmbh filed Critical Giesecke & Devrient Gmbh
Priority to EP04739254A priority Critical patent/EP1629379A2/de
Publication of WO2004104916A2 publication Critical patent/WO2004104916A2/de
Publication of WO2004104916A3 publication Critical patent/WO2004104916A3/de

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/445—Program loading or initiating
    • 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/46—Multiprogramming arrangements
    • G06F9/468—Specific access rights for resources, e.g. using capability register

Definitions

  • the invention relates generally to the technical field of loading an executable program into a file system of a portable data carrier, the file system supporting a plurality of different access rights settings.
  • a portable data carrier in the sense of the present document can in particular be a chip card (smart card) in different designs or a chip module.
  • Portable data carriers are being manufactured with more and more storage space and ever greater computing power.
  • An internal research project of Giesecke & Devrient GmbH is currently investigating the extent to which a UNIX®-like operating system can be implemented in a modern, portable data carrier.
  • an implementation of the operating system known under the Linux® brand is planned.
  • Portable data carriers with a functionality for loading executable program code during use of the data carrier are generally known. Such data carriers are described, for example, in Chapter 5.10 of the book “Handbuch der Chip None” by W. Rankl and W. Effing, Carl Hanser Verlag, 3rd edition, 1999, pages 252-281.
  • loading program code onto a data carrier that has a UNIX-like operating system appears to be less problematic because the operating system basically provides the required functions. Difficulties arise, in particular, from the fact that the power supply to the portable data carrier and the communication Connection to an external terminal can be interrupted or disrupted at any time. If a loading process is taking place at the time of the interruption or malfunction, the loaded program may be saved incompletely or incorrectly on the data carrier. If such a program were to be executed, this could at least result in undefined and possibly even behavior that compromises the security of the data carrier.
  • the invention is also intended to provide a possibility by which incompletely or incorrectly loaded programs can be easily recognized and deleted.
  • the invention is based on the basic idea of also using a functionality which is already present in the file system of the data carrier and with which different access rights to the files contained in the file system can be set to achieve the object of the invention. This results in an advantageous synergy because the load status of the program can be mapped in the file system with extremely little administration effort.
  • the executable program is stored as a file with a first access right setting in the file system during the loading process, and that the access right setting of this file is changed to a second access right setting after the loading process has been successfully completed.
  • the access right settings are selected “appropriately”, namely in such a way that the first access right setting allows writing to the file but not its execution, and that the second access right setting allows the file to be executed.
  • An incomplete loading process is preferably recognized by the fact that the file described during the loading process still has the first access right setting, although the loading process has already ended - obviously unsuccessfully. Such a check can be carried out, for example, each time the data carrier is started up after a power failure and / or every attempt to execute a program. Files identified as incomplete are then preferably deleted from the file system.
  • the data carrier preferably has a UNIX-like operating system.
  • the file systems usually used there include an adjustable read access right, an adjustable write access right and an adjustable execution right for each file. These rights can usually be set separately for the owner of the file, a user group associated with the file owner and all other users.
  • the invention is not restricted to operating and file systems which provide precisely this access right structure. A lot of- more the invention can be used with any operating and file system that allows different first and second access right settings for at least some files.
  • the invention can be used in all phases of the life cycle of the data carrier.
  • the invention is particularly preferably used for loading program code into a data carrier, the initialization and personalization of which have already been completed and which is in use by a user.
  • the loading of program code into the data carrier is often referred to as "reloading".
  • the computer program product according to the invention can be a physical medium with stored program instructions, for example a semiconductor memory or a floppy disk or a CD-ROM.
  • the computer program product can also be a non-physical medium, for example a signal transmitted over a computer network.
  • the computer program product can contain a loading program, which is introduced into it during the course of the manufacture or initialization or the personalization or application of a portable data carrier.
  • the data carrier and / or the computer program product have features which correspond to the features described above and / or to the features mentioned in the dependent method claims.
  • Fig. 1 is a block diagram with functional units of a data carrier according to an embodiment of the invention, which is connected to an external terminal, and
  • FIG. 2 shows a schematic illustration of a successfully completed loading process of a program into the data carrier from FIG. 1.
  • the data carrier 10 shown in FIG. 1 has a processor 12, a memory 14 and an interface circuit 16 for contactless or contact-based communication with an external terminal 18 on a single semiconductor chip.
  • the memory 14 is divided into several memory fields.
  • a working memory 20 configured as RAM
  • a read-only memory 22 configured as ROM
  • a non-volatile memory 24 configured as EEPROM are provided as memory fields.
  • the operating system 26 is a variant of the operating system known under the Linux brand, tailored to use in the data carrier 10.
  • the operating system 26 is adapted to the considerable resource limitation of the data carrier 10 with regard to computing power, storage space and peripheral devices.
  • the operating system 26 is also set up in the event of a sudden interruption in the power supply to the data carrier 10 and / or the Exclude communication connection to the external terminal 18 safety-critical operating states of the data carrier 10.
  • a file system 28 with a tree-like directory and file structure is created in the non-volatile memory 24.
  • a file of the file system 28 is shown by way of example in FIG. 1 with the reference symbol 30.
  • each file of file system 28 - e.g. file 30 - assigned access rights that indicate whether the file may be read and / or written and / or executed. These access rights are specified separately for an owner of the file, a user group assigned to the owner and for all other users.
  • a more detailed description of the access rights mentioned and other file attributes can be found on pages 15 and 16 of the book "Under Standing the Linux Kernel" already cited at the beginning.
  • the operating system 26 has an internal load program 32 which interacts with an external load program 34 of the terminal 18 in order to load an executable program 36 into the data carrier 10.
  • the internal load program 32 is a module of the operating system 26
  • the internal load program 32 can also be present in whole or in part as an application program in the file system 28 in alternative embodiments.
  • the program 36 to be loaded into the data carrier 10 can either be stored locally in the terminal 18 or transmitted to the terminal 18 from a background system (not shown in FIG. 1) to which the terminal 18 is connected.
  • the executable program 36 is in the format known under the name ELF (Executable and Linking Format), while in execution variants others or Additional file formats can be provided for the executable program 36.
  • the sequence of an error-free charging process is shown by way of example in FIG. 2, the time axis running from top to bottom in the illustration in FIG. 2.
  • the charging process is initiated either by the external charging program 34 or by the internal charging program 32.
  • the external loading program 34 and the internal loading program 32 exchange a request and a corresponding confirmation and, if appropriate, further administrative data.
  • the internal loading program 32 creates the initially empty file 30 in the file system 28 in the course of the initialization phase 42.
  • the file 30 is created here with a first access right setting 44, in which only one write access right 46 (“W” flag) is set.
  • a read access right 48 and an execution right 50 (“R” flag and "X” flag) are not set for the file 30.
  • the three access rights 46, 48, 50 can be assigned to the owner of the file 30 and / or a higher-level user group and / or all users.
  • a transmission phase 52 or 54 begins, in which the external loading program 34 transmits the program 36 to be loaded to the internal loading program 32.
  • this transmission can take place in a continuous data stream.
  • the exemplary illustration in FIG. 2 provides for the executable program 36 to be divided into several fragments of a predetermined size. These fragments are each sent to the internal loading program 32 in a partial step of the transmission phase 52 and 54, respectively, and are immediately written there into the file 30.
  • Suitable transfer Delivery protocols which may also have authentication, security, error detection and / or error correction functions, are well known as such.
  • the internal loading program 32 now checks whether the executable program 36 has actually been loaded completely and without errors. In the simplest case, this is always assumed if no error was found during the transmission phase 52, 54 according to the transmission protocol used. However, a further check preferably takes place in the final phase 56.
  • the length of the stored file 30 is compared with a length information transmitted by the external load program 34, or a checksum of the file 30 stored in the file system 28 is calculated and compared with a checksum transmitted by the external load program 34.
  • Suitable algorithms for checksum calculation are as such e.g. well known under the names CRC (Cyclic Redundancy Check) or MD5 (Message Digest 5) or SHA-1 (Secure Hash Algorithm 1).
  • the file 30 is set to a second access right setting 58.
  • the write access right 46 (“W” flag) is deleted in the second access right setting 58 and the read access right 48 (“R” flag) and the execution right 50 (“X” flag) are set.
  • the file 30 can now be run as an executable program under the control of the operating system 26. 36 grams are executed. The loading process is now successfully completed; In some configurations, a corresponding feedback from the internal charging program 32 to the external charging program 34 can take place.
  • the loading process can either be restarted or canceled.
  • the already written part of the file 30 is then preferably immediately deleted from the file system 28.
  • the data carrier 10 reboots after such a separation from the terminal 18 - and the associated failure of the supply voltage - it carries out a check on the file system 28. If a file created by a loading process - here, for example, the file 30 - is found, which still has the first access right setting 44, this is a sign that a loading process has been interrupted and the file is therefore incomplete or incorrect. The affected file is then deleted from the file system 28. Whether a file contained in the file system 28 basically represents an executable program can generally be determined by checking the first bytes of the file. For example, the first sixteen bytes of an executable program in the ELF format always default values, which are also referred to as "magic values".
  • the operating system 26 each time an attempt is made to execute a file - e.g. file 30 - which is not marked as executable by a set "X" flag, deletes this file.
  • the additional deletion of such files results in an ongoing cleanup of the file system 28 when an attempt is made to execute it.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Bei einem Verfahren zum Laden eines ausführbaren Programms (36) in ein Dateisystem (28) eines tragbaren Datenträgers, wobei das Dateisystem (28) eine Mehrzahl unterschiedlicher Zugriffsrechtseinstellungen (44, 58) für die im Dateisystem (28) angelegten Dateien (30) unterstützt, wird das ausführbare Programm (36) während des Ladevorgangs als Datei (30) mit einer ersten Zugriffsrechtseinstellung (44) im Dateisystem (28) gespeichert, und die Zugriffsrechtseinstellung (44, 58) dieser Datei (30) wird nach einem erfolgreichen Abschluss des Ladevorgangs auf eine zweite Zugriffsrechtseinstellung (58) geändert. Ein tragbarer Datenträger und ein Computerprogrammprodukt weisen entsprechende Merkmale auf. Durch die Erfindung kann die Ausführung unvollständig oder fehlerhaft in den Datenträger geladener Programme zuverlässig verhindert werden.

Description

Laden eines ausführbaren Programms in einen tragbaren Datenträger
Die Erfindung betrifft allgemein das technische Gebiet des Ladens eines aus- führbaren Programms in ein Dateisystem eines tragbaren Datenträgers, wobei das Dateisystem eine Mehrzahl unterschiedlicher Zugriffsrechtseinstellungen unterstützt. Ein tragbarer Datenträger im Sinne des vorliegenden Dokuments kann insbesondere eine Chipkarte (Smart Card) in unterschiedlichen Bauformen oder ein Chipmodul sein.
Tragbare Datenträger werden mit immer mehr Speicherplatz und immer größerer Rechenleistung hergestellt. In einem internen Forschungsprojekt der Giesecke & Devrient GmbH wird gegenwärtig untersucht, inwieweit ein UNIX®-artiges Betriebssystem in einem modernen tragbaren Datenträger implementiert werden kann. In diesem Zusammenhang ist insbesondere eine Implementierung des unter der Marke Linux® bekannten Betriebssystems vorgesehen. Das Buch "Understanding the Linux Kernel" von D. P. Bovet und M. Cesati, O'Reilly Verlag, 2. Auflage, Dezember 2002, enthält eine detaillierte technische Beschreibung dieses Betriebssystems.
Allgemein sind bereits tragbare Datenträger mit einer Funktionalität zum Laden von ausführbarem Programmcode während des Einsatzes des Datenträgers bekannt. Solche Datenträger sind beispielsweise in Kapitel 5.10 des Buches "Handbuch der Chipkarten" von W. Rankl und W. Effing, Carl Hanser Verlag, 3. Auflage, 1999, Seiten 252 - 281, beschrieben.
Das Laden von Programmcode in einen Datenträger, der ein UNIX-artiges Betriebssystem aufweist, erscheint auf den ersten Blick wenig problematisch, weil das Betriebssystem die benötigten Funktionen grundsätzlich bereitstellt. Schwierigkeiten ergeben sich jedoch insbesondere durch die Tatsache, daß die Stromversorgung des tragbaren Datenträgers und die Kommunikations- Verbindung mit einem externen Terminal jederzeit unterbrochen oder gestört werden können. Findet zum Zeitpunkt der Unterbrechung oder Störung gerade ein Ladevorgang statt, dann wird das geladene Programm möglicherweise unvollständig oder fehlerhaft im Datenträger gespeichert. Wenn ein solches Programm ausgeführt werden würde, könnte dies zumindest ein Undefiniertes und gegebenenfalls sogar ein die Sicherheit des Datenträgers kompromittierendes Verhalten zur Folge haben.
Es ist daher Aufgabe der Erfindung, einen Mechanismus bereitzustellen, durch den die Ausführung unvollständig oder fehlerhaft in den Datenträger geladener Programme zuverlässig verhindert werden kann. Vorzugsweise soll dieser Mechanismus nur geringen zusätzlichen Verwaltungsaufwand benötigen. In bevorzugten Ausgestaltungen soll die Erfindung ferner eine Möglichkeit bereitstellen, durch die unvollständig oder fehlerhaft geladene Programme leicht erkannt und gelöscht werden können.
Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren gemäß Anspruch 1, einen. tragbaren Datenträger gemäß Anspruch 8 und ein Computerprogrammprodukt gemäß Anspruch 9. Die abhängigen Ansprüche betreffen bevorzugte Ausgestaltungen der Erfindung.
Die Erfindung geht von der Grundüberlegung aus, eine im Dateisystem des Datenträgers bereits vorhandene Funktionalität, mit der unterschiedliche Zugriffsrechte auf die im Dateisystem enthaltenen Dateien eingestellt werden können, auch zur Lösung der erfindungsgemäßen Aufgabe zu nutzen. Es ergibt sich somit eine vorteilhafte Synergie, weil der Ladezustand des Programms mit äußerst geringem Verwaltungsaufwand im Dateisystem abgebildet werden kann. Erf indungsgemäß ist vorgesehen, daß das ausführbare Programm während des Ladevorgangs als Datei mit einer ersten Zugriffsrechtseinstellung im Dateisystem gespeichert wird, und daß die Zugriffsrechtseinstellung dieser Datei nach einem erfolgreichen Abschluß des Ladevorgangs auf eine zweite Zugriffsrechtseinstellung geändert wird. Grundsätzlich ist in diesem Zusammenhang nur erforderlich, daß sich die erste und die zweite Zugriffsrechtseinstellung voneinander unterscheiden. In bevorzugten Ausgestaltungen werden jedoch die Zugriffsrechtseinstellungen "passend" gewählt, nämlich derart, daß die erste Zugriffsrechtseinstellung das Schreiben in die Datei, nicht aber deren Ausführung gestattet, und daß die zweite Zugriffsrechtseinstellung die Ausführung der Datei gestattet.
Ein unvollständiger Ladevorgang wird vorzugsweise daran erkannt, daß die während des Ladevorgangs beschriebene Datei noch die erste Zugriff srechts- einstellung aufweist, obwohl der Ladevorgang bereits - offensichtlich erfolglos - beendet worden ist. Eine derartige Überprüfung kann beispielsweise bei jedem Hochfahren des Datenträgers nach einem Spannungsausfall und/ oder bei jedem Versuch der Ausführung eines Programms erfolgen. Als unvollständig erkannte Dateien werden dann vorzugsweise aus dem Datei- system gelöscht.
Wie eingangs bereits erwähnt, weist der Datenträger vorzugsweise ein UNIX-artiges Betriebssystem auf. Die dort üblicherweise verwendeten Dateisysteme umfassen für jede Datei ein einstellbares Lesezugriffsrecht, ein einstellbares Schreibzugriffsrecht und ein einstellbares Ausführungsrecht. Diese Rechte sind üblicherweise für den Eigentümer der Datei, eine mit dem Dateieigentümer assoziierte Benutzergruppe und alle anderen Benutzer getrennt einstellbar. Die Erfindung ist jedoch nicht auf Betriebs- und Dateisysteme beschränkt, die genau diese Zugriffsrechtsstruktur vorsehen. Viel- mehr kann die Erfindung bei jedem Betriebs- und Dateisystem eingesetzt werden, das unterschiedliche erste und zweite Zugriffsrechtseinstellungen für zumindest einige Dateien zuläßt.
Grundsätzlich kann die Erfindung in allen Phasen des Lebenszyklus des Datenträgers eingesetzt werden. Besonders bevorzugt dient die Erfindung jedoch zum Laden von Programmcode in einen Datenträger, dessen Initialisierung und Personalisierung bereits abgeschlossen sind und der sich bei einem Benutzer im Einsatz befindet. In diesem Fall wird das Laden von Programmcode in den Datenträger oft auch als "Nachladen" bezeichnet.
Das erfindungsgemäße Computerprogrammprodukt kann ein körperliches Medium mit gespeicherten Programmbefehlen sein, beispielsweise ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerpro- grammprodukt kann jedoch auch ein nicht-körperliches Medium sein, beispielsweise ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das Computerprogrammprodukt ein Ladeprogramm enthalten, das im Zuge der Herstellung oder der Initialisierung oder der Personalisierung oder der Anwendung eines tragbaren Datenträgers in diesen einge- bracht wird.
In bevorzugten Ausgestaltungen weisen der Datenträger und/ oder das Computerprogrammprodukt Merkmale auf, die den oben beschriebenen und/ oder den in den abhängigen Verfahrensansprüchen genannten Merk- malen entsprechen.
Weitere Merkmale, Vorteile und Aufgaben der Erfindung gehen aus der folgenden genauen Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen hervor. Es wird auf die schematischen Zeichnungen verwiesen, in denen zeigen:
Fig. 1 ein Blockdiagramm mit Funktionseinheiten eines Datenträgers nach einem Ausführungsbeispiel der Erfindung, der an ein externes Terminal angeschlossen ist, und
Fig. 2 eine schematische Darstellung eines erfolgreich abgeschlossenen Ladevorgangs eines Programms in den Datenträger von Fig. 1.
Der in Fig. 1 dargestellte Datenträger 10 weist auf einem einzigen Halbleiterchip einen Prozessor 12, einen Speicher 14 und eine Schnittstellenschaltung 16 zur kontaktlosen oder kontaktgebundenen Kommunikation mit einem externen Terminal 18 auf. Der Speicher 14 ist in mehrere Speicherfelder unterteilt. Im vorliegenden Ausführungsbeispiel sind als Speicherfelder ein als RAM ausgestalteter Arbeitsspeicher 20, ein als ROM ausgestalteter Festwertspeicher 22 und ein als EEPROM ausgestalteter, nicht-flüchtiger Speicher 24 vorgesehen.
Im Speicher 14 - und zwar teils im Festwertspeicher 22 und teils im nichtflüchtigen Speicher 24 - befindet sich Programmcode, der ein Betriebssystem 26 implementiert. Das Betriebssystem 26 ist im vorliegenden Ausführungsbeispiel eine auf den Einsatz im Datenträger 10 zugeschnittene Variante des unter der Marke Linux bekannten Betriebssystems. Insbesondere ist das Be- triebssystem 26 an die erhebliche Ressourcenbeschränkung des Datenträgers 10 im Hinblick auf Rechenleistung, Speicherplatz und Peripheriegeräte angepaßt. Das Betriebssystem 26 ist ferner dazu eingerichtet, bei einer plötzlichen Unterbrechung der Stromversorgung des Datenträgers 10 und/ oder der Kommunikationsverbindung zum externen Terminal 18 sicherheitskritische Betriebszustände des Datenträgers 10 auszuschließen.
Im nicht-flüchtigen Speicher 24 ist ein Dateisystem 28 mit einer baumartigen Verzeichnis- und Dateistruktur angelegt. Eine Datei des Dateisystems 28 ist in Fig. 1 beispielhaft mit dem Bezugszeichen 30 dargestellt. In der für Unix- Dateisysteme üblichen Weise sind jeder Datei des Dateisystems 28 - z.B. der Datei 30 - Zugriffsrechte zugeordnet, die angeben, ob die Datei gelesen und/ oder beschrieben und/oder ausgeführt werden darf. Diese Zugriffsrechte sind für einen Eigentümer der Datei, eine dem Eigentümer zugeordnete Benutzergruppe sowie für alle anderen Benutzer getrennt angegeben. Eine genauere Darstellung der genannten Zugriffsrechte und weiterer Dateiattribute findet sich auf den Seiten 15 und 16 des eingangs bereits zitierten Buches "Under Standing the Linux Kernel".
Das Betriebssystem 26 weist ein internes Ladeprogramm 32 auf, das mit einem externen Ladeprogramm 34 des Terminals 18 zusammenwirkt, um ein ausführbares Programm 36 in den Datenträger 10 zu laden. Statt der hier beispielhaft gezeigten Ausgestaltung, bei der das interne Ladeprogramm 32 ein Modul des Betriebssystems 26 ist, kann das interne Ladeprogramm 32 in Ausführungsalternativen auch ganz oder zum Teil als Anwendungsprogramm im Dateisystem 28 vorliegen.
Das in den Datenträger 10 zu ladende Programm 36 kann entweder lokal im Terminal 18 gespeichert sein oder von einem Hintergrundsystem (in Fig. 1 nicht gezeigt), an das das Terminal 18 angeschlossen ist, an das Terminal 18 übertragen werden. Im hier beschriebenen Beispiel liegt das ausführbare Programm 36 in dem unter dem Namen ELF (Executable and Linking Format) bekannten Format vor, während in Ausführungsvarianten andere oder zusätzliche Dateiformate für das ausführbare Programm 36 vorgesehen sein können.
Der Ablauf eines fehlerfreien Ladevorgangs ist in Fig. 2 beispielhaft gezeigt, wobei die Zeitachse in der Darstellung von Fig. 2 von oben nach unten verläuft. Der Ladevorgang wird entweder von dem externen Ladeprogramm 34 oder von dem internen Ladeprogramm 32 angestoßen. In einer anfänglichen Initialisierungsphase 40 bzw. 42 tauschen das externe Ladeprogramm 34 und das interne Ladeprogramm 32 eine Anforderung und eine entsprechende Be- stätigung sowie gegebenenfalls weitere Verwaltungsdaten aus.
Das interne Ladeprogramm 32 legt im Zuge der Initialisierungsphase 42 die anfangs noch leere Datei 30 im Dateisystem 28 an. Die Datei 30 wird hierbei mit einer ersten Zugriffsrechtseinstellung 44 angelegt, in der nur ein Schreib- zugriffsrecht 46 ("W"-Flag) gesetzt ist. Ein Lesezugriffsrecht 48 und ein Ausführungsrecht 50 ("R"-Flag und "X"-Flag) sind für die Datei 30 nicht gesetzt. In unterschiedlichen Ausführungsformen können die drei Zugriffsrechte 46, 48, 50 dem Eigentümer der Datei 30 und/ oder einer übergeordneten Benutzergruppe und/ oder allen Benutzern zugeordnet sein.
Im Anschluß an die Initialisierungsphase 40 bzw.42 beginnt eine Übertragungsphase 52 bzw. 54, in der das externe Ladeprogramm 34 das zu ladende Programm 36 an das interne Ladeprogramm 32 übermittelt. In manchen Ausgestaltungen kann diese Übertragung in einem stetigen Datenstrom erfolgen. In der beispielhaften Darstellung von Fig. 2 ist dagegen vorgesehen, das ausführbare Programm 36 in mehrere Fragmente einer vorgegebenen Größe zu unterteilen. Diese Fragmente werden in jeweils einem Teilschritt der Übertragungsphase 52 bzw. 54 an das interne Ladeprogramm 32 gesendet und dort sogleich in die Datei 30 eingeschrieben. Geeignete Übertra- gungsprotokolle, die gegebenenfalls auch Authentisierungs-, Sicherungs-, Fehlererkennungs- und/ oder Fehlerkorrekturfunktionen aufweisen können, sind als solche gut bekannt.
Bei einem fehlerfreien Ladevorgang ist das ausführbare Programm 36 am Ende der Übertragungsphase 52, 54 vollständig in den Datenträger 10 geladen und in die Datei 30 eingeschrieben worden. Die erste Zugriffsrechtseinstellung 44 wurde bislang nicht verändert.
In einer Abschlußphase 56 überprüft das interne Ladeprogramm 32 nun, ob das ausführbare Programm 36 tatsächlich vollständig und fehlerfrei geladen wurde. Im einfachsten Fall wird dies immer dann angenommen, wenn während der Übertragungsphase 52, 54 gemäß dem verwendeten Übertragungsprotokoll kein Fehler festgestellt wurde. Bevorzugt findet aber in der Ab- Schlußphase 56 eine weitere Überprüfung statt. Hierbei kann z.B. die Länge der gespeicherten Datei 30 mit einer vom externen Ladeprogramm 34 übermittelten Längenangabe verglichen werden, oder es wird eine Prüf summe der im Dateisystem 28 gespeicherten Datei 30 berechnet und mit einer vom externen Ladeprogramm 34 übermittelten Prüf summe verglichen. Geeignete Algorithmen zur Prüfsummeήberechnung sind als solche z.B. unter den Bezeichnungen CRC (Cyclic Redundancy Check) oder MD5 (Message Digest 5) oder SHA-1 (Secure Hash Algorithm 1) gut bekannt.
Wenn in der Abschlußphase 56 kein Ladefehler detektiert wurde, wird die Datei 30 auf eine zweite Zugriffsrechtseinstellung 58 gesetzt. Im vorliegenden Ausführungsbeispiel sind in der zweiten Zugriffsrechtseinstellung 58 das Schreibzugriffsrecht 46 ("W"-Flag) gelöscht und das Lesezugriffsrecht 48 ("R"-Flag) sowie das Ausführungsrecht 50 ("X"-Flag) gesetzt. Die Datei 30 kann nun unter Steuerung des Betriebssystems 26 als ausführbares Pro- gramm 36 ausgeführt werden. Der Ladevorgang ist damit erfolgreich abgeschlossen; in manchen Ausgestaltungen kann eine entsprechende Rückmeldung vom internen Ladeprogramm 32 an das externe Ladeprogramm 34 erfolgen.
Falls das interne Ladeprogramm 32 während der Übertragungsphase 54 oder der Abschlußphase 56 einen Ladefehler meldet, kann der Ladevorgang entweder neu gestartet oder abgebrochen werden. Der bereits geschriebene Teil der Datei 30 wird dann vorzugsweise sogleich aus dem Dateisystem 28 gelöscht.
Eine derartige sofortige Säuberung des Dateisystems 28 durch das interne Ladeprogramm 32 ist jedoch nicht möglich, wenn der Datenträger 10 während des Ladevorgangs plötzlich vom Terminal 18 getrennt wird. Dies kann entweder wegen einer Betriebsstörung oder aufgrund eines gezielten Angriffsversuchs geschehen.
Wenn der Datenträger 10 nach einer solchen Trennung vom Terminal 18 - und dem damit verbundenen Ausfall der Versorgungsspannung - wieder hochfährt, führt er eine Kontrolle des Dateisystems 28 aus. Wird dabei eine durch einen Ladevorgang angelegte Datei - hier z.B. die Datei 30 - gefunden, die noch die erste Zugriffsrechtseinstellung 44 aufweist, so ist dies ein Zeichen dafür, daß ein laufender Ladevorgang unterbrochen wurde und daher die Datei unvollständig oder fehlerhaft ist. Die betroffene Datei wird dann aus dem Dateisystem 28 gelöscht. Ob eine im Dateisystem 28 enthaltene Datei prinzipiell ein ausführbares Programm darstellt, kann in der Regel durch eine Überprüfung der ersten Bytes der Datei ermittelt werden. So weisen z.B. die ersten sechzehn Bytes eines ausführbaren Programms im ELF-Format stets vorgegebene Werte auf, die auch als "magische Werte" bezeichnet werden.
Alternativ oder zusätzlich zu der gerade beschriebenen Überprüfung des Dateisystems 28 bei jedem Hochfahren des Datenträgers 10 kann auch vorgesehen sein, daß das Betriebssystem 26 bei jedem Versuch der Ausführung einer Datei - z.B. der Datei 30 -, die nicht durch ein gesetztes "X"-Flag als ausführbar gekennzeichnet ist, diese Datei löscht. Im Vergleich zu der an sich bekannten Vorgehensweise, bei der das Betriebssystem 26 lediglich die Ausführung einer nicht mit einem Ausführungsrecht gekennzeichneten Datei verweigert, wird durch die zusätzliche Löschung derartiger Dateien bei einem Ausführungsversuch eine laufende Bereinigung des Dateisvstems 28 bewirkt.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Laden eines ausführbaren Programms (36) in ein Dateisystem (28) eines tragbaren Datenträgers (10), wobei das
Dateisystem (28) eine Mehrzahl unterschiedlicher Zugriffsrechtseinstellungen (44, 58) für die im Dateisystem (28) angelegten Dateien (30) unterstützt, dadurch gekennzeichnet, daß das ausführbare Programm (36) während des Ladevorgangs als Datei (30) mit einer ersten Zugriffsrechtseinstellung (44) im Dateisystem
(28) gespeichert wird, und daß die Zugriffsrechtseinstellung (44, 58) dieser Datei (30) nach einem erfolgreichen Abschluß des Ladevorgangs auf eine zweite Zugriffsrechtseinstellung (58) geändert wird.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß ein erfolglos beendeter Ladevorgang daran erkannt wird, daß die während des Ladevorgangs beschriebene Datei (30) nach Beendigung des Ladevorgangs noch die erste Zugriffsrechtseinstellung (44) aufweist, und daß diese Datei (30) dann aus dem Dateisystem
(28) gelöscht wird.
3. Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß die erste Zugriffsrechtseinstellung (44) das Schrei- ben in die Datei (30), nicht aber die Ausführung der Datei (30) gestattet.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die zweite Zugriffsrechtseinstellung (58) die Ausführung der Datei (30) gestattet.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß die Mehrzahl von Zugriffsrechtseinstellungen (44, 58) mindestens ein für jede Datei (30) einstellbares Lesezugriffsrecht (48), mindestens ein für jede Datei (30) einstellbares Schreibzugriffsrecht (46) und mindestens ein für jede Datei (30) einstell- bares Ausführungsrecht (50) umfaßt.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß im Zusammenhang mit der Feststellung, ob der Ladevorgang erfolgreich war, eine Prüfsummenberechnung ausgeführt wird.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß der Datenträger (10) ein UNIX-artiges Betriebssystem (26), insbesondere ein Linux-Betriebssystem aufweist.
8. Tragbarer Datenträger (10), insbesondere Chipkarte oder Chipmodul, mit einem Prozessor (12) und mindestens einem Speicher (14), wobei der Speicher (14) Programmbefehle enthält, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 7 veranlassen.
9. Computerprogrammprodukt, das maschinenlesbare Programmbefehle für einen Prozessor (12) eines tragbaren Datenträgers (10) aufweist, die den Prozessor (12) zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 7 veranlassen.
PCT/EP2004/005365 2003-05-20 2004-05-18 Laden eines ausführbaren programms in einen tragbaren datenträger WO2004104916A2 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04739254A EP1629379A2 (de) 2003-05-20 2004-05-18 Laden eines ausführbaren programms in einen tragbaren datenträger

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE2003123033 DE10323033A1 (de) 2003-05-20 2003-05-20 Laden eines ausführbaren Programms in einen tragbaren Datenträger
DE10323033.5 2003-05-20

Publications (2)

Publication Number Publication Date
WO2004104916A2 true WO2004104916A2 (de) 2004-12-02
WO2004104916A3 WO2004104916A3 (de) 2005-05-12

Family

ID=33461832

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/005365 WO2004104916A2 (de) 2003-05-20 2004-05-18 Laden eines ausführbaren programms in einen tragbaren datenträger

Country Status (3)

Country Link
EP (1) EP1629379A2 (de)
DE (1) DE10323033A1 (de)
WO (1) WO2004104916A2 (de)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1834911B (zh) * 2005-03-14 2010-04-28 华为技术有限公司 实现程序加载运行的方法
CN101833464A (zh) * 2010-04-16 2010-09-15 深圳市五巨科技有限公司 一种移动终端分段加载应用程序的方法及装置

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102012008147A1 (de) * 2012-04-24 2013-10-24 Tobias Volk Anordnung zur Organisation von Daten auf einem RFID- Transponder

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077908A2 (en) * 2000-03-30 2001-10-18 Microsoft Corporation Transactional file system
US20030066062A1 (en) * 2001-09-28 2003-04-03 Brannock Kirk D. Method for atomically updating a plurality of files

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001077908A2 (en) * 2000-03-30 2001-10-18 Microsoft Corporation Transactional file system
US20030066062A1 (en) * 2001-09-28 2003-04-03 Brannock Kirk D. Method for atomically updating a plurality of files

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"FTP directory listing"[Online] XP002314752 Gefunden im Internet: URL:ftp://ftp2.de.freebsd.org/pub/cygnus/b inutils/old-releases/> [gefunden am 2005-01-24] *
DAVID A WHEELER: "Secure Programming for Linux and Unix HOWTO, Chapter 7.10"[Online] 3. März 2003 (2003-03-03), XP002311653 Gefunden im Internet: URL:http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.pdf> [gefunden am 2004-12-20] *
FREE SOFTWARE FOUNDATION: "ChangeLog for binutils version 1.9"[Online] XP002314751 Gefunden im Internet: URL:http://ftp2.de.freebsd.org/pub/cygnus/binutils/old-releases/binutils-1.9.tar.bz2 > [gefunden am 2004-12-16] *
FREE SOFTWARE FOUNDATION: "Linker 'ld' for GNU, Version 1.9, ld.c"[Online] 17. April 1991 (1991-04-17), XP002311652 Gefunden im Internet: URL:http://ftp2.de.freebsd.org/pub/cygnus/binutils/old-releases/binutils-1.9.tar.bz2 > [gefunden am 2004-12-16] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1834911B (zh) * 2005-03-14 2010-04-28 华为技术有限公司 实现程序加载运行的方法
CN101833464A (zh) * 2010-04-16 2010-09-15 深圳市五巨科技有限公司 一种移动终端分段加载应用程序的方法及装置

Also Published As

Publication number Publication date
DE10323033A1 (de) 2004-12-23
WO2004104916A3 (de) 2005-05-12
EP1629379A2 (de) 2006-03-01

Similar Documents

Publication Publication Date Title
EP1611510B1 (de) Kontrollierte ausführung eines für eine virtuelle maschine vorgesehenen programms auf einem tragbaren datenträger
DE102009059939A1 (de) Verfahren zum Komprimieren von Bezeichnern
DE102013213314A1 (de) Hinterlegen mindestens eines berechenbaren Integritätsmesswertes in einem Speicherbereich eines Speichers
WO2016087652A1 (de) Verfahren zur datenverarbeitung zum ermitteln, ob bei einer ausführung eines programms ein fehler aufgetreten ist, und datenverarbeitungsanordnungen zum erzeugen von programm-code
DE60100363T2 (de) Sequenznummerierungsmechanismus zur sicherung der ausführungsordnungs-integrietät von untereinander abhängigen smart-card anwendungen
DE102007008651A1 (de) Chipkarte und Verfahren zur Freischaltung einer Chipkarten-Funktion
DE68922521T2 (de) Sekundärprozessorinitialisierungssystem.
EP3224756B1 (de) Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten
WO2004104916A2 (de) Laden eines ausführbaren programms in einen tragbaren datenträger
EP2652665B1 (de) Portabler datenträger mit fehlbedienungszähler
WO2010089083A2 (de) Vorrichtung und verfahren zum verhindern von unautorisierter verwendung und/oder manipulation von software
EP3308278B1 (de) Verfahren zum aktualisieren von personalisierungsdaten
WO2006061141A1 (de) Erzeugen von programmcode in einem ladeformat und bereitstellen von ausführbarem programmcode
WO2011085960A1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
EP1492008B1 (de) Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger
EP1308842B1 (de) Verfahren und Vorrichtung zur Verwaltung eines Datenspeichers
EP1591864A2 (de) Verfahren zum Schützen von Daten eines Datenträgers gegen DFA-Angriffe
DE69935317T2 (de) Verfahren zum unteilbaren verändern einer vielzahl von nicht flüchtigen speicherplätzen einer chipkarte, insbesondere eine karte ohne kontakt
DE10247794A1 (de) Verwalten eines Fehlversuchszählers in einem tragbaren Datenträger
DE10328238B4 (de) Verfahren zum Laden von Chipkarten mit Initialisierungs- und/oder Personalisierungsdaten
WO2005104018A2 (de) Verwalten eines dateisystems in einem tragbaren datenträger
DE102013014187A1 (de) Verfahren und Vorrichtung zur Übertragung einer Information
EP1638058A2 (de) Verifizierung eines Datenträgers vor der Installation eines Anwendungsprogramms
WO2000041097A1 (de) Verfahren zum erzeugen eines dateibezeichners durch anwendung einer hashfunktion auf den inhalt der datei
DE102018213045A1 (de) Verfahren, Steuervorrichtung, Computerprogramm und Computerprogrammprodukt zum Aktualisieren einer Software für eine Steuervorrichtung

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004739254

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004739254

Country of ref document: EP

DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)