EP1629379A2 - Laden eines ausführbaren programms in einen tragbaren datenträger - Google Patents
Laden eines ausführbaren programms in einen tragbaren datenträgerInfo
- Publication number
- EP1629379A2 EP1629379A2 EP04739254A EP04739254A EP1629379A2 EP 1629379 A2 EP1629379 A2 EP 1629379A2 EP 04739254 A EP04739254 A EP 04739254A EP 04739254 A EP04739254 A EP 04739254A EP 1629379 A2 EP1629379 A2 EP 1629379A2
- Authority
- EP
- European Patent Office
- Prior art keywords
- file
- access right
- data carrier
- loading
- loading process
- 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
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; 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 OR CALCULATING; 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
- 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.
- 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 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
- 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.
- 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".
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
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.
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 |
| PCT/EP2004/005365 WO2004104916A2 (de) | 2003-05-20 | 2004-05-18 | Laden eines ausführbaren programms in einen tragbaren datenträger |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| EP1629379A2 true EP1629379A2 (de) | 2006-03-01 |
Family
ID=33461832
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| EP04739254A Ceased EP1629379A2 (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) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1834911B (zh) * | 2005-03-14 | 2010-04-28 | 华为技术有限公司 | 实现程序加载运行的方法 |
| CN101833464A (zh) * | 2010-04-16 | 2010-09-15 | 深圳市五巨科技有限公司 | 一种移动终端分段加载应用程序的方法及装置 |
| DE102012008147A1 (de) * | 2012-04-24 | 2013-10-24 | Tobias Volk | Anordnung zur Organisation von Daten auf einem RFID- Transponder |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6856993B1 (en) * | 2000-03-30 | 2005-02-15 | Microsoft Corporation | Transactional file system |
| US7299463B2 (en) * | 2001-09-28 | 2007-11-20 | Intel Corporation | Method for atomically updating a plurality of files |
-
2003
- 2003-05-20 DE DE2003123033 patent/DE10323033A1/de not_active Ceased
-
2004
- 2004-05-18 EP EP04739254A patent/EP1629379A2/de not_active Ceased
- 2004-05-18 WO PCT/EP2004/005365 patent/WO2004104916A2/de not_active Ceased
Non-Patent Citations (1)
| Title |
|---|
| See references of WO2004104916A3 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2004104916A2 (de) | 2004-12-02 |
| DE10323033A1 (de) | 2004-12-23 |
| WO2004104916A3 (de) | 2005-05-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| DE69717063T2 (de) | Verfahren und System zur sicheren Datenverarbeitung | |
| 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 | |
| EP1611510A2 (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 | |
| 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 | |
| WO2004104916A2 (de) | Laden eines ausführbaren programms in einen tragbaren datenträger | |
| EP2652665B1 (de) | Portabler datenträger mit fehlbedienungszähler | |
| EP3224756B1 (de) | Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten | |
| EP3308278B1 (de) | Verfahren zum aktualisieren von personalisierungsdaten | |
| EP2394232A2 (de) | Vorrichtung und verfahren zum verhindern von unautorisierter verwendung und/oder manipulation von software | |
| EP3329415B1 (de) | Chipkarte mit hauptapplikation und persistenzapplikation erlaubt hauptapplikationupdate ohne die benutzerdaten im persistenzapplikation zu ändern | |
| EP1308842B1 (de) | Verfahren und Vorrichtung zur Verwaltung eines Datenspeichers | |
| DE10247794B4 (de) | Verwalten eines Fehlversuchszählers in einem tragbaren Datenträger | |
| DE10328238B4 (de) | Verfahren zum Laden von Chipkarten mit Initialisierungs- und/oder Personalisierungsdaten | |
| EP2573677B1 (de) | Datenaustausch zwischen Applikationen | |
| DE102004058882A1 (de) | Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode | |
| EP1492008A2 (de) | Behandlung eines Fehlerereignisses bei der Installation eines Anwendungsprogramms in einem tragbaren Datenträger | |
| DE102024000178A1 (de) | Verfahren zum Aktualisieren einer Softwarekomponente auf einem Mikrocontroller, Aktualisierungssystem und Fahrzeug | |
| EP4659100A1 (de) | Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul | |
| EP3271825B1 (de) | Verfahren zum speichern von nutzerdaten in einem dokument | |
| EP4517570A1 (de) | Verfahren und system zum überprüfen der integrität einer regelwerksdatenbank | |
| EP1306759A2 (de) | Programmausführung bei einer Chipkarte | |
| WO2005104018A2 (de) | Verwalten eines dateisystems in einem tragbaren datenträger |
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: 20051220 |
|
| AK | Designated contracting states |
Kind code of ref document: A2 Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PL PT RO SE SI SK TR |
|
| DAX | Request for extension of the european patent (deleted) | ||
| 17Q | First examination report despatched |
Effective date: 20080207 |
|
| 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: 20120409 |