DE102004058882A1

DE102004058882A1 - Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode

Info

Publication number: DE102004058882A1
Application number: DE102004058882A
Authority: DE
Inventors: Ulrich Kolzenburg; Stephan Dr. Spitz; Wolfgang Effing
Original assignee: Giesecke and Devrient GmbH
Current assignee: Giesecke and Devrient GmbH
Priority date: 2004-12-06
Filing date: 2004-12-06
Publication date: 2006-06-08
Also published as: JP2013041598A; EP1839136A1; CN101073054A; US20090044172A1; CN101073054B; WO2006061141A1; US8332834B2; JP2008523480A

Abstract

Bei einem Verfahren zum Erzeugen von Programmcode (24, 30) in einem Ladeformat für einen tragbaren Datenträger (12) wird eine Pseudobibliothek (20) verwendet, die sich von einer auf dem Datenträger (12) befindlichen Bibliothek (38) dergestalt unterscheidet, daß zumindest manche Interna der auf dem Datenträger befindlichen Bibliothek (38) in der Pseudobibliothek (12) fehlen oder verborgen oder verschleiert sind. Bei einem Verfahren zum Bereitstellen von ausführbarem Programmcode (40) in dem tragbaren Datenträger (12) wird der Programmcode (24, 30) im Ladeformat gegenüber der auf dem Datenträger (12) befindlichen Bibliothek (38) gebunden. Eine Vorrichtung (10, 12) und ein Computerprogrammprodukt weisen entsprechende Merkmale auf. Durch die Erfindung wird eine sichere und vertraulichkeitswahrende Technik geschaffen, die das Erzeugen von Programmcode (24, 30) in einem Ladeformat für einen tragbaren Datenträger (12) und das Bereitstellen von ausführbarem Programmcode (40) in dem tragbaren Datenträger (12) gestattet.

Description

Die Erfindung betrifft allgemein das Gebiet der tragbaren Datenträger und der Erstellung von Software für solche Datenträger. Insbesondere betrifft die Erfindung das Gebiet, Programmcode für einen tragbaren Datenträger zu erzeugen, den Programmcode in den Datenträger zu laden und den Programmcode zur Ausführung durch einen Prozessor des Datenträgers bereitzustellen. Tragbare Datenträger im Sinne des vorliegenden Dokuments können als Chipkarten (Smart Cards) oder als kompakte Chipmodule und in manchen Ausführungsformen der Erfindung auch als ressourcenbeschränkte Systeme in anderen Bauformen ausgestaltet sein.

Im Zuge der stetigen technischen Entwicklung sind tragbare Datenträger in den letzten Jahren immer leistungsfähiger geworden. Dies betrifft sowohl die von der Hardware zur Verfügung gestellte Rechenleistung und den Speicherplatz als auch die vom Betriebssystem bereitgestellten Funktionen. Moderne tragbare Datenträger weisen eine Funktionalität zum Nachladen von Programmcode – also zum Laden von Programmcode während des Betriebs des Datenträgers – auf. Datenträger, in die Anwendungsprogramme nachgeladen werden können, sind schon seit einiger Zeit bekannt. Gegenwärtig befinden sich jedoch auch Datenträger in der Entwicklung, die ein Nachladen von Teilen des Betriebssystems, z.B. von Treibern, Bibliotheken oder Funktionsmodulen, erlauben. Es ist zu erwarten, daß sich diese Nachlademöglichkeit in Zukunft zu einem wichtigen Bestandteil flexibler Betriebssysteme für tragbare Datenträger entwickeln wird.

Allgemein sind bei tragbaren Datenträgern die Aspekte der Sicherheit und des Ausspähungsschutzes wichtige Faktoren, weil tragbare Datenträger häufig für sicherheitskritische Anwendungen eingesetzt werden und durch eine unbefugte Verwendung oder eine Ausspähung hoher Schaden entstehen könnte. Insbesondere besteht bei Datenträgern, die das Nachladen von Programmcode erlauben, das Problem, möglichst keine Interna des Datenträgers preiszugeben. Insbesondere soll vermieden werden, daß der externe Entwickler des nachzuladenden Programmcodes Information über den internen Aufbau und interne Programmstrukturen des Datenträgers benötigt oder ermitteln kann. So sollen beispielsweise plattformabhängige Funktionen des Datenträgers möglichst verborgen bleiben, auch wenn der nachzuladende Programmcode diese Funktionen letztendlich nutzt.

Die Erfindung hat die Aufgabe, das gerade genannte Problem ganz oder zum Teil zu lösen. Insbesondere soll durch die Erfindung eine sichere und vertraulichkeitswahrende Technik geschaffen werden, die das Erzeugen von Programmcode in einem Ladeformat für einen tragbaren Datenträger und das Bereitstellen von ausführbarem Programmcode in dem tragbaren Datenträger gestattet.

Erfindungsgemäß wird diese Aufgabe ganz oder zum Teil gelöst durch ein Verfahren mit den Merkmalen von Anspruch 1 bzw. Anspruch 4, eine Vorrichtung mit den Merkmalen von Anspruch 16 und ein Computerprogrammprodukt mit den Merkmalen von Anspruch 17 bzw. Anspruch 18. Die abhängigen Ansprüche definieren bevorzugte Ausgestaltungen der Erfindung.

Die Erfindung geht von der Grundüberlegung aus, außerhalb des Datenträgers lediglich eine Pseudobibliothek bereitzustellen, die sich von einer auf dem Datenträger befindlichen Bibliothek dergestalt unterscheidet, daß zumindest manche Interna der auf dem Datenträger befindlichen Bibliothek in der Pseudobibliothek fehlen oder verborgen oder verschleiert sind. Einem externen Programmentwickler braucht nur die Pseudobibliothek – und gegebenenfalls die zugehörige Dokumentation – zugänglich gemacht zu werden. Auf diese Weise können Informationen, aus denen Dritte mögli cherweise unerwünschte Rückschlüsse auf Interna des Datenträgers ziehen könnten, geheim gehalten werden. Damit ermöglicht die Erfindung eine sichere Entwicklung von nachladbarem Programmcode auch durch Dritte, beispielsweise durch unabhängige Softwarehäuser oder industrielle Nutzer von Datenträgern.

Das Binden (Linken) des Programmcodes in dem Objektcode-Format gegenüber der Pseudobibliothek erfolgt zumindest teilweise. Insbesondere heißt dies, daß in manchen Ausgestaltungen der Erfindung der Programmcode in dem Ladeformat noch symbolische Informationen, wie sie üblicherweise im Objektcode-Format enthalten sind, aufweisen kann. In anderen Ausgestaltungen wird dagegen ein vollständig gegenüber der Pseudobibliothek gelinkter Programmcode in dem Ladeformat erzeugt.

Auf dem Datenträger erfolgt ein weiterer Bindevorgang, der in bevorzugten Ausführungsformen als dynamischer Bindevorgang ausgestaltet ist. Dieser Bindevorgang kann in unterschiedlichen Ausführungsformen zur Ladezeit oder zur Laufzeit oder teils zur Lade- und teils zur Laufzeit stattfinden. Der auf dem Datenträger ausgeführte Bindevorgang erfolgt gegenüber der vertraulichen, auf dem Datenträger befindlichen Bibliothek.

In bevorzugten Ausgestaltungen ist das außerhalb des Datenträgers ausgeführte Binden ein virtuelles Binden gegenüber virtuellen Funktionen der Pseudobibliothek. Entsprechend können in manchen Ausführungsformen innerhalb des Datenträgers virtuelle Funktionsaufrufe in dem Programmcode im Ladeformat durch tatsächliche Funktionsaufrufe der auf dem Datenträger befindlichen Bibliothek ersetzt werden.

Es sind ferner Ausgestaltungen der Erfindung vorgesehen, bei denen der Programmcode im Ladeformat Sprungtabellen oder Verweistabellen auf weist, die erst beim Binden auf dem Datenträger mit auf die reale Bibliothek verweisenden Einträgen gefüllt werden. Insbesondere – aber nicht nur – in solchen Ausgestaltungen kann vorgesehen sein, daß in der auf dem Datenträger befindlichen Bibliothek virtuelle Funktionsaufrufe aufgelöst werden. Dies kann zur Ladezeit oder zur Laufzeit oder teils zur Lade- und teils zur Laufzeit erfolgen.

In bevorzugten Ausgestaltungen der Erfindung stellt die Pseudobibliothek eine Aufrufschnittstelle bereit, die sich von der Aufrufschnittstelle der auf dem Datenträger befindlichen Bibliothek unterscheidet. Insbesondere kann die von der Pseudobibliothek bereitgestellte Aufrufschnittstelle eine virtuelle Aufrufschnittstelle sein.

Um eine hohe Sicherheit gegen eine Verfälschung des Programmcodes und gegen ein unerwünschtes Nachladen von unautorisiertem Programmcode zu erhalten, werden in bevorzugten Ausgestaltungen Authentisierungsdaten erstellt und beim Laden des Programmcodes überprüft.

In bevorzugten Ausführungsformen wird eine flexible und automatische Erkennung des nachgeladenen Programmcodes durch das Betriebssystem und/oder Anwendungsprogramme des Datenträgers dadurch ermöglicht, daß die von dem Programmcode bereitgestellten Funktionen in einer Verwaltungseinheit des Datenträgers eingetragen werden.

Der erzeugte und in den Datenträger geladene Programmcode kann beispielsweise ein Anwendungsprogramm oder ein Kernel-Modul sein. In bevorzugten Ausgestaltungen ist vorgesehen, daß der Programmcode nativer Programmcode ist. Als nativer Programmcode soll hier insbesondere Binärcode angesehen werden, der von dem Prozessor des Datenträgers ohne eine zwischengeschaltete Interpretierung und ohne eine virtuelle Maschine ausführbar ist.

Das erfindungsgemäße Computerprogrammprodukt weist Programmbefehle auf, um das erfindungsgemäße Verfahren zu implementieren, oder Programmbefehle, die durch das erfindungsgemäße Verfahren erzeugt worden sind. Ein derartiges Computerprogrammprodukt kann ein körperliches Medium sein, z.B. ein Halbleiterspeicher oder eine Diskette oder eine CD-ROM. Das Computerprogrammprodukt kann jedoch auch ein nicht-körperliches Medium sein, z.B. ein über ein Computernetzwerk übermitteltes Signal. Insbesondere kann das Computerprogrammprodukt Software für ein Programmentwicklungssystem oder einen tragbaren Datenträger enthalten oder im Zusammenhang mit der Herstellung oder Initialisierung oder Personalisierung oder dem Betrieb eines tragbaren Datenträgers verwendet werden.

Die erfindungsgemäße Vorrichtung kann insbesondere ein Programmentwicklungssystem oder ein tragbarer Datenträger sein. In bevorzugten Weiterbildungen weisen das Computerprogrammprodukt und/oder die Vorrichtung Merkmale auf, die den in der vorliegenden Beschreibung erwähnten und/oder den in den abhängigen Verfahrensansprüchen genannten Merkmalen entsprechen.

Weitere Merkmale, Aufgaben und Vorteile der Erfindung ergeben sich aus der folgenden Beschreibung eines Ausführungsbeispiels und mehrerer Ausführungsalternativen. In den schematischen Zeichnungen zeigen:
1 eine konzeptionelle Darstellung der Datenstrukturen und Datenverarbeitungsstufen in einem Programmentwicklungssystem und einem Datenträger gemäß einem Ausführungsbeispiel der Erfindung,
2 ein Flußdiagramm eines in dem Programmentwicklungssystem von 1 ausgeführten Verfahrens zum Erzeugen von Programmcode in einem Ladeformat,
3 ein Flußdiagramm eines in dem Datenträger von 1 ausgeführten Verfahrens zum Bereitstellen von ausführbarem Programmcode, und
4 eine beispielhafte Darstellung der Beziehung zwischen einer auf dem Datenträger befindlichen Bibliothek und einer Pseudobibliothek.
In 1 sind schematisch ein Programmentwicklungssystem 10 und ein tragbarer Datenträger 12 gezeigt. Das Programmentwicklungssystem 10 kann als üblicher persönlicher Computer oder Arbeitsplatzrechner mit geeigneter Software ausgestaltet sein. Der Datenträger 12 ist im vorliegenden Ausführungsbeispiel eine Chipkarte oder ein Chipmodul mit an sich bekannter Hardware. Insbesondere enthält der Datenträger 12 einen Ein-Chip-Mikrocontroller mit einem Prozessor, mehreren in unterschiedlichen Technologien ausgestalteten Speicherfeldern und einer Schnittstellenschaltung zur drahtgebundenen oder drahtlosen Kommunikation.
In dem in 1 gezeigten Ausführungsbeispiel geht die Erzeugung des Programmcodes von einem Quelltext 14 aus, der durch einen Compiler 16 in einen entsprechenden Programmcode 18 in einem Objektcode-Format übersetzt wird. In dem Programmentwicklungssystem 10 steht eine Pseudobibliothek 20 zur Verfügung, auf die später noch genauer eingegangen werden wird. Ein Linker 22 erzeugt aus dem im Objektcode-Format vorliegenden Programmcode 18 und der Pseudobibliothek 20 einen zumindest zum Teil gebundenen (gelinkten) Programmcode 24 in einem Ladeformat.
Um den Programmcode 24 gegen versehentliche oder böswillige Verfälschungen zu sichern, wird ein Authentisierungserzeuger 26 verwendet, der Authentisierungsdaten 28 – z.B. eine geeignete Prüfsumme des Programmcodes 24 – generiert. Der durch die Authentisierungsdaten 28 gesicherte Programmcode 30 im Ladeformat bildet das Ergebnis des mit Hilfe des Programmentwicklungssystems 10 ausgeführten Entwicklungsprozesses. Dieser Programmcode 30 wird zur späteren Verwendung gespeichert.
Der Programmcode 30 kann während des Betriebs des Datenträgers 12 in diesen geladen werden. Der Ladevorgang kann beispielsweise beim Endkunden oder im Zusammenhang mit der Herstellung oder Initialisierung oder Personalisierung des Datenträgers 12 erfolgen. Der Programmcode 30 liegt dabei in dem Programmentwicklungssystem 10 oder einer Initialisierungs- oder Personalisierungsvorrichtung oder einem Endkunden-Terminal vor und wird in den Datenträger 12 übertragen. Bei dem Ladevorgang ist der Datenträger 12 in Betrieb. Hierunter soll verstanden werden, daß der Programmcode 30 bei dem Ladevorgang durch den Prozessor des Datenträgers 12 aktiv verarbeitet und verändert wird.
In 1 ist durch einen gestrichelten Pfeil angedeutet; daß der gesicherte Programmcode 30 im Ladeformat – gegebenenfalls über eine der oben erwähnten Zwischenstationen – von einem Ladeprogramm 32 in den Datenträger 12 übernommen wird. Ein Authentisierungsprüfer 34 stellt sicher, daß der Programmcode 30 unverfälscht ist und von einer autorisierten Stelle mit den Authentisierungsdaten 28 versehen wurde. Bei bestandener Prüfung wird der Programmcode 24 im Ladeformat von einem Linker 36 gegenüber einer im Datenträger 12 gespeicherten Bibliothek 38 gebunden. Auf diesen Vorgang des dynamischen Linkens wird unten noch genauer eingegangen.
Der Linker 36 erzeugt ausführbaren Programmcode 40, der nun zur Ausführung durch den Prozessor des Datenträgers 12 bereitsteht. In manchen Ausgestaltungen ist der ausführbare Programmcode 40 ein Anwendungsprogramm (Applikation) für den Datenträger 12. Im hier beschriebenen Ausführungsbeispiel ist der ausführbare Programmcode 40 dagegen ein Kernel-Modul des Datenträgers 12, also z.B. ein Teil des Betriebssystems, ein Treiber oder eine Bibliothek. Das Kernel-Modul kann beispielsweise einen Treiber für die Speicherverwaltung oder eine Kryptobibliothek oder Funktionalitäten zur Kommunikation mit diversen Schnittstellen – z.B. USB, Wireless, TCP/IP – zur Verfügung stellen.
Die Funktionen des ausführbaren Programmcodes 40 werden dem Betriebssystem des Datenträgers 12 und den auf dem Datenträger 12 gespeicherten Anwendungsprogrammen bereitgestellt. In manchen Ausgestaltungen erfolgt hierbei eine flexible Erkennung der geladenen Funktionalität. Hierzu stellt der ausführbare Programmcode 40 – insbesondere, wenn er ein Kernel-Modul ist – eine vorher spezifizierte Schnittstelle zur Verfügung. Ferner ist in den hier beschriebenen Ausführungsbeispielen vorgesehen, den Programmcode 40 durch ein Registrierungsprogramm 42 in einer Verwaltungseinheit des Datenträgers 12 mit den bereitgestellten Funktionen einzutragen. Diese Verwaltungseinheit kann beispielsweise eine Registrierungsdatei (Registry) oder eine sonstige Datenstruktur des Datenträgers 12 sein.
2 veranschaulicht nochmals den Verfahrensablauf im Programmentwicklungssystem 10. In Schritt 50 wird der Programmcode 18 im Objektcode-Format erzeugt. Schritt 52 betrifft das Binden des Programmcodes 18 gegenüber der Pseudobibliothek 20, um den ungesicherten Programmcode 24 im Ladeformat zu erhalten. In Schritt 54 werden schließlich die Authentisierungsdaten 28 und der gesicherte Programmcode 30 im Ladeformat erstellt.
Das in 3 gezeigte Flußdiagramm faßt die im Datenträger 12 ausgeführten Verfahrensschritte zusammen. Auf das Einlesen des gesicherten Programmcodes 30 in Schritt 56 und die Authentisierungsüberprüfung in Schritt 58 folgt in Schritt 60 das Binden des Programmcodes 24 gegenüber der im Datenträger 12 gespeicherten Bibliothek 38, um den ausführbaren Programmcode 40 zu erhalten. Der ausführbare Programmcode 40 wird in Schritt 62 zur Ausführung bereitgestellt und gegebenenfalls in die Verwaltungseinheit des Datenträgers 12 eingetragen.
Wesentlicher Bestandteil der hier beschriebenen Ausführungsbeispiele sind die beiden Bindevorgänge in den Schritten 52 und 60. Bei dem ersten Bindevorgang in Schritt 52, der von dem Linker 22 ausgeführt wird, wird die Pseudobibliothek 20 (Dummy-Bibliothek) verwendet. Die Pseudobibliothek 20 unterscheidet sich von der im Datenträger 12 gespeicherten Bibliothek 38 insbesondere dadurch, daß die Pseudobibliothek 20 nicht die wirklichen Funktionen der auf dem Datenträger 12 gespeicherten Bibliothek 38 enthält, sondern lediglich Funktionen, die hier als "virtuelle Funktionen" bezeichnet werden.
Der Bindevorgang außerhalb des Datenträgers 12 erfolgt somit virtuell, d.h. gegen virtuelle Funktionen der Pseudobibliothek 20 statt gegen die tatsächlichen Funktionen der im Datenträger 12 enthaltenen Bibliothek 38. Mit anderen Worten findet ein Linken gegen eine virtuelle Aufrufschnittstelle der Pseudobibliothek 20 statt gegen die reale Aufrufschnittstelle der Bibliothek 38 im Datenträger 12 statt. Die Interna des Datenträgers 12, nämlich insbesondere die internen Funktionen und internen Funktionalitäten der Bibliothek 38, bleiben daher verborgen. Auch durch eine Analyse der Pseudobibliothek 20 könnten diese internen Funktionen und Funktionalitäten nicht ermittelt werden.
Die gerade beschriebene Beziehung zwischen der Pseudobibliothek 20 und der im Datenträger 12 enthaltenen Bibliothek 38 ist in 4 an einem Beispiel veranschaulicht. Die Pseudobibliothek 20 stellt eine virtuelle Aufrufschnittstelle mit beispielsweise den Funktionen VirtFunc1, VirtFunc2 und VirtFunc3 bereit. Erst auf dem Datenträger 12 ist die Aufrufschnittstelle der Bibliothek 38 mit den tatsächlichen Funktionen des Datenträgers 12 hinterlegt.
Die tatsächliche Aufrufschnittstelle der im Datenträger 12 enthaltenen Bibliothek 38 löst die virtuellen Funktionsaufrufe auf und stellt beispielsweise die internen Funktionen Func1, Func2, Func3 und Func4 bereit. Das Binden des Programmcodes 18 in Schritt 52 durch den Linker 22 erfolgt gegen die Pseudobibliothek 20, die nur die Aufrufschnittstelle zur Verfügung stellt. Das tatsächliche Auflösen der Referenzen erfolgt dagegen erst in Schritt 60 auf dem Datenträger 12. Bei diesem Vorgang werden die virtuellen Funktionen VirtFunc1 – VirtFunc3 durch die tatsächlichen Funktionen Func1 – Func4 ersetzt. Dies ist in 4 durch die gestrichelten Pfeile veranschaulicht.
Insgesamt wird somit erreicht, daß der auf dem Datenträger 12 ausgeführte Programmcode 40 plattformabhängige und/oder vertrauliche Funktionen nutzen kann. Durch die Verwendung der Pseudobibliothek 20 braucht aber die erst im Datenträger 12 erfolgende Umsetzung der dem Programmentwickler bekannten, externen Funktionen in die plattformabhängigen Funktionen nicht offengelegt zu werden. Diese Maßnahme bewirkt eine erhebliche Steigerung der Sicherheit des Datenträgers 12, auch wenn dieser ein Laden von nativem Programmcode – z.B. Anwendungsprogrammen und Treibern – gestattet.
Es versteht sich, daß die Einzelheiten der obigen Beschreibung nur als Beispiele für mögliche Ausgestaltungen der vorliegenden Erfindungen dienen sollen. Weitere Abwandlungen, insbesondere im Hinblick auf die außerhalb des Datenträgers 12 und im Datenträger 12 ausgeführten Bindevorgänge 52, 60 und die jeweiligen Inhalte der Pseudobibliothek 20 und der im Datenträger 12 befindlichen Bibliothek 38, sind möglich und für den Fachmann offensichtlich.

Claims

Verfahren zum Erzeugen von Programmcode (24, 30) in einem Ladeformat, der dazu vorgesehen ist, während des Betriebs eines tragbaren Datenträgers (12) in diesen geladen und von einem Prozessor des Datenträgers (12) ausgeführt zu werden und bei der Ausführung Funktionen einer auf dem Datenträger (12) befindlichen Bibliothek (38) zu nutzen, mit den außerhalb des Datenträgers (12) ausgeführten Schritten: – Erzeugen von Programmcode (18) in einem Objektcode-Format, und – zumindest teilweises Binden des Programmcodes (18) in dem Objektcode-Format gegenüber einer Pseudobibliothek (20), um den Programmcode (24, 30) in dem Ladeformat zu erhalten, wobei sich die Pseudobibliothek (20) von der auf dem Datenträger (12) befindlichen Bibliothek (38) dergestalt unterscheidet, daß zumindest manche Interna der auf dem Datenträger (12) befindlichen Bibliothek (38) in der Pseudobibliothek (20) fehlen oder verborgen oder verschleiert sind.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Binden ein virtuelles Binden gegenüber virtuellen Funktionen der Pseudobibliothek (20) ist.
Verfahren nach Anspruch 1 oder Anspruch 2, dadurch gekennzeichnet, daß Authentisierungsdaten (28) erstellt werden, um den Programmcode (24, 30) im Ladeformat gegen Verfälschung zu sichern.
Verfahren zum Bereitstellen von ausführbarem Programmcode (40) in einem tragbaren Datenträger (12), wobei der ausführbare Programmcode (40) dazu eingerichtet ist, bei der Ausführung durch einen Prozessor des Datenträgers (12) Funktionen einer auf dem Datenträger (12) befindlichen Bibliothek (38) zu nutzen, mit den von dem Prozessor des Datenträgers (12) ausgeführten Schritten: – Laden von Programmcode (24, 30) in einem Ladeformat während des Betriebs des Datenträgers (12), wobei der Programmcode (24, 30) in dem Ladeformat zumindest teilweise gegenüber einer Pseudobibliothek (20) gebunden ist, die sich von der auf dem Datenträger (12) befindlichen Bibliothek (38) dergestalt unterscheidet, daß zumindest manche Interna der auf dem Datenträger (12) befindlichen Bibliothek (38) in der Pseudobibliothek fehlen oder verborgen oder verschleiert sind, und – Binden des Programmcodes (24, 30) in dem Ladeformat gegenüber der auf dem Datenträger (12) befindlichen Bibliothek (38), um den ausführbaren Programmcode (40) zu erhalten.
Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß das Binden ein dynamisches Binden ist.
Verfahren nach Anspruch 4 oder Anspruch 5, dadurch gekennzeichnet, daß bei dem Binden virtuelle Funktionsaufrufe in dem Programmcode (24, 30) im Ladeformat durch tatsächliche Funktionsaufrufe der auf dem Datenträger (12) befindlichen Bibliothek (38) ersetzt werden.
Verfahren nach einem der Ansprüche 4 bis 6, dadurch gekennzeichnet, daß der Programmcode (24, 30) im Ladeformat durch Authentisierungsdaten (28) gesichert ist, und daß der ausführbare Programmcode (40) erst nach erfolgreicher Authentisierungsüberprüfung zur Ausführung bereitgestellt wird.
Verfahren nach einem der Ansprüche 4 bis 7, dadurch gekennzeichnet, daß die von dem ausführbaren Programmcode (40) bereitgestellten Funktionen in einer Verwaltungseinheit des Datenträgers (12) eingetragen werden.
Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, daß der Programmcode (24, 30) im Ladeformat durch ein Verfahren nach einem der Ansprüche 1 bis 3 erzeugt worden ist.
Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Pseudobibliothek (20) eine Aufrufschnittstelle bereitstellt, die sich von einer Aufrufschnittstelle der auf dem Datenträger befindlichen Bibliothek (38) unterscheidet.
Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß die von der Pseudobibliothek (20) bereitgestellte Aufrufschnittstelle eine virtuelle Aufrufschnittstelle ist.
Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, daß in der auf dem Datenträger (12) befindlichen Bibliothek (38) virtuelle Funktionsaufrufe aufgelöst werden.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, daß der Programmcode (24, 30, 40) ein Anwendungsprogrammist.
Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, daß der Programmcode (24, 30, 40) ein Kernel-Modul ist.
Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, daß der Programmcode (24, 30, 40) nativer Programmcode ist.
Vorrichtung, insbesondere Programmentwicklungssystem (10) oder tragbarer Datenträger (12), die dazu eingerichtet ist, ein Verfahren nach einem der Ansprüche 1 bis 15 auszuführen.
Computerprogrammprodukt, das eine Vielzahl von Programmbefehlen zur Steuerung einer programmierbaren Vorrichtung, insbesondere eines Programmentwicklungssystems (10) oder eines tragbaren Datenträgers (12), aufweist, wobei die Programmbefehle dazu eingerichtet sind, die programmierbare Vorrichtung zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 15 zu veranlassen.
Computerprogrammprodukt mit Programmcode (24, 30, 40), der durch ein Verfahren nach einem der Ansprüche 1 bis 15 erzeugt worden ist.