EP1839136A1 - Erzeugen von programmcode in einem ladeformat und bereitstellen von ausf]hrbarem programmcode - Google Patents

Erzeugen von programmcode in einem ladeformat und bereitstellen von ausf]hrbarem programmcode

Info

Publication number
EP1839136A1
EP1839136A1 EP05818331A EP05818331A EP1839136A1 EP 1839136 A1 EP1839136 A1 EP 1839136A1 EP 05818331 A EP05818331 A EP 05818331A EP 05818331 A EP05818331 A EP 05818331A EP 1839136 A1 EP1839136 A1 EP 1839136A1
Authority
EP
European Patent Office
Prior art keywords
program code
library
data carrier
format
binding
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
EP05818331A
Other languages
English (en)
French (fr)
Inventor
Ulrich Kolzenburg
Stephan Spitz
Wolfgang Effing
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Giesecke and Devrient GmbH
Original Assignee
Giesecke and Devrient GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke and Devrient GmbH filed Critical Giesecke and Devrient GmbH
Publication of EP1839136A1 publication Critical patent/EP1839136A1/de
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/54—Link editing before load time

Definitions

  • the invention relates generally to the field of portable data carriers and the creation of software for such data carriers.
  • the invention relates to the field of generating program code for a portable data carrier, loading the program code into the data carrier and providing the program code for execution by a processor of the data carrier.
  • Portable data carriers in the sense of the present document can be designed as smart cards or as compact chip modules and in some embodiments of the invention as resource-limited systems in other designs.
  • aspects of security and spy protection are important factors in portable data carriers, because portable data carriers are often used for safety-critical applications and could be damaged by unauthorized use or spying.
  • the reloading of Program code allows to reveal the problem, if possible, no internals of the disk.
  • the external developer of the program code to be reloaded may require or determine information about the internal structure and internal program structures of the data carrier. For example, platform-dependent functions of the data carrier should remain as concealed as possible, even if the program code to be reloaded finally uses these functions.
  • the invention has the object to solve the problem just mentioned in whole or in part.
  • the invention seeks to provide a secure and privacy-preserving technique that permits the generation of program code in a portable media loading format and the provision of executable program code in the portable data carrier.
  • the invention is based on the basic idea of providing only a pseudo-library outside the data carrier, which differs from a library on the data carrier in such a way that at least some internals of the library located on the data carrier are missing or hidden or obfuscated in the pseudo-library.
  • An external programmer needs only the pseudo-library - and possibly the associated documentation - to be made accessible. In this way, information from which third parties may may draw unwanted inferences on internals of the data carrier, kept secret.
  • the invention enables a secure development of reloadable program code also by third parties, for example by independent software companies or industrial users of data carriers.
  • Binding (linking) of the program code in the object code format to the dummy library is at least partially accomplished.
  • the program code in the load format can still have symbolic information, as they are usually contained in the object code format.
  • a program code completely linked to the pseudo-library is generated in the load format.
  • Another binding process takes place on the data carrier, which in preferred embodiments is designed as a dynamic binding process.
  • This binding process can take place in different embodiments at the time of loading or at runtime or partly for loading and partly at runtime.
  • the binding process carried out on the data medium takes place opposite the confidential library located on the data carrier.
  • the binding performed outside of the volume is a virtual binding to virtual functions of the dummy library. Accordingly, in some embodiments within the volume, virtual function calls in the program code may be replaced in the load format by actual function calls of the library located on the volume.
  • the program code in the loading format contains jump tables or look-up tables. points that are filled only when binding on the disk with referring to the real library entries.
  • virtual function calls are resolved in the library located on the disk. This can be done at loading time or at runtime or partly for loading and partly at runtime.
  • the pseudo-library provides a call interface that is different than the call interface of the on-disk library.
  • the invocation interface provided by the pseudo-library may be a virtual invocation interface.
  • authentication data are created in preferred embodiments and checked when loading the program code.
  • flexible and automatic recognition of the reloaded program code by the operating system and / or application programs of the data carrier is made possible in that the functions provided by the program code are entered in a management unit of the data carrier.
  • the generated and loaded into the disk program code may be, for example, an application program or a kernel module.
  • the program code is native program code.
  • a native program code is to be considered here in particular binary code, by the processor of the disk without an intermediate interpretation and executable without a virtual machine.
  • the computer program product according to the invention has program instructions in order to implement the method according to the invention or program instructions which have been generated by the method according to the invention.
  • a computer program product may be a physical medium, e.g. a semiconductor memory or a floppy disk or a CD-ROM.
  • the computer program product may also be a non-physical medium, e.g. a signal transmitted over a computer network.
  • the computer program product may include software for a program development system or a portable data carrier or may be used in connection with the manufacture or initialization or personalization or operation of a portable data carrier.
  • the device according to the invention can be a program development system or a portable data carrier.
  • the computer program product and / or the device have features which correspond to the features mentioned in the present description and / or the features mentioned in the dependent method claims.
  • FIG. 1 is a conceptual representation of the data structures and data processing stages in a program development system and a data carrier according to an embodiment of the invention
  • FIG. 2 is a flowchart of a method for generating program code in a load format executed in the program development system of FIG. 1;
  • FIG. 3 is a flow chart of a method for providing executable code executed in the data carrier of FIG. 1;
  • Fig. 4 is an exemplary illustration of the relationship between a disk-based library and a dummy library.
  • a program development system 10 and a portable data carrier 12 are shown schematically.
  • the program development system 10 may be configured as a custom personal computer or workstation with appropriate software.
  • the data carrier 12 is a chip card or a chip module with hardware known per se.
  • the data carrier 12 contains a single-chip microcontroller with a processor, a plurality of memory fields configured in different technologies, and an interface circuit for wired or wireless communication.
  • the generation of the program code is based on a source text 14, which is translated by a compiler 16 into a corresponding program code 18 in object code format.
  • a dummy library 20 is available, which will be discussed in more detail later.
  • a linker 22 generates at least partially bound (linked) program code 24 from the program code 18 present in the object code format and the dummy library 20 in a loading format.
  • an authentication generator 26 is used, the authentication data 28 - for example, a suitable test sum of the program code 24 - generated.
  • the program code 30 in the loading format saved by the authentication data 28 forms the result of the development process carried out with the aid of the program development system 10. This program code 30 is stored for later use.
  • the program code 30 may be loaded during operation of the data carrier 12 therein.
  • the charging process can take place, for example, at the end customer or in connection with the production or initialization or personalization of the data carrier 12.
  • the program code 30 is present in the program development system 10 or an initialization or personalization device or an end customer terminal and is transmitted to the data carrier 12.
  • the data carrier 12 is in operation. This is understood to mean that the program code 30 is actively processed and changed during the loading process by the processor of the data carrier 12.
  • Fig. 1 is indicated by a dashed arrow that the secure program code 30 in the loading format - optionally via one of the above-mentioned intermediate stations - is taken over by a loader 32 in the disk 12.
  • An authentication verifier 34 ensures that the program code 30 is unadulterated and has been provided with the authentication data 28 by an authorized authority. If the test is successful, the program code 24 in the loading format is bound by a linker 36 with respect to a library 38 stored in the data carrier 12. This process of dynamic linking will be discussed in more detail below.
  • the linker 36 generates executable program code 40 that is now ready for execution by the processor of the volume 12.
  • the executable program code 40 is an application program (application) for the data carrier 12.
  • the executable program code 40 is a kernel module of the data carrier 12, ie, a part of the operating system, a driver, or a library .
  • the kernel module can, for example, provide a driver for memory management or a crypto library or functionalities for communication with various interfaces, eg USB, wireless, TCP / IP.
  • the functions of the executable program code 40 are provided to the operating system of the data carrier 12 and the application programs stored on the data carrier 12. In some embodiments, a flexible recognition of the loaded functionality takes place here.
  • the executable program code 40 - in particular if it is a kernel module - provides a previously specified interface.
  • This administrative unit can be, for example, a registration file (registry) or another data structure of the data carrier 12.
  • FIG. 2 again illustrates the method sequence in the program development system 10.
  • the program code 18 is generated in object code format.
  • Step 52 involves binding the program code 18 to the dummy library 20 to obtain the unprotected program code 24 in the loading format.
  • the authentication data 28 and the secure program code 30 are created in the loading format.
  • the flowchart shown in FIG. 3 summarizes the method steps carried out in the data carrier 12.
  • step 60 Upon reading in of the saved program code 30 in step 56 and the authentication check in step 58, in step 60 the binding of the program code 24 to the library 38 stored in the data carrier 12 is completed to obtain the executable program code 40.
  • the executable program code 40 is provided for execution in step 62 and optionally entered in the management unit of the data carrier 12.
  • the pseudo-library 20 differs from the library 38 stored in the data carrier 12 in particular in that the pseudo-library 20 does not contain the actual functions of the library 38 stored on the data carrier 12, but only functions which are referred to herein as "virtual functions".
  • the binding process outside the data carrier 12 thus takes place virtually, ie against virtual functions of the dummy library 20 instead of the actual functions of the library 38 contained in the data carrier 12.
  • a link against a virtual call interface of the dummy library 20 takes place against the real call interface of the library 38 in the disk 12 instead.
  • the relationship just described between the pseudo library 20 and the library 38 contained in the data carrier 12 is illustrated in Fig. 4 as an example.
  • the pseudo library 20 provides a virtual invocation interface with, for example, the functions VirtFuncl, VirtFunc2 and VirtFunc3 prepared. Only on the Disk 12 is the call interface of the library 38 with the actual functions of the disk 12 deposited.
  • the actual call interface of the library 38 contained in the volume 12 triggers the virtual function calls and provides, for example, the internal functions Funcl, Func2, Func3 and Func4.
  • the binding of the program code 18 in step 52 by the linker 22 is against the dummy library 20, which provides only the calling interface.
  • the actual resolution of the references does not take place until the data carrier 12 is in step 60.
  • the virtual functions VirtFuncl-VirtFunc3 are replaced by the actual functions Funcl-Func4. This is illustrated in Fig. 4 by the dashed arrows.
  • the program code executed on the data carrier 12 can use platform-dependent and / or confidential functions.
  • the implementation of the external functions known to the program developer in the data carrier 12 need not be disclosed in the platform-dependent functions. This measure brings about a significant increase in the security of the data carrier 12, even if it allows a loading of native program code - eg application programs and drivers.
  • the details of the above description are intended to serve as examples of possible embodiments of the present invention. Further modifications, in particular with regard to the binding processes 52, 60 executed outside of the data carrier 12 and in the data carrier 12 and the respective contents of the dummy library 20 and the library 38 located in the data carrier 12, are possible and obvious to the person skilled in the art.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Devices For Executing Special Programs (AREA)

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 Daten­träger (12) wird der Programmcode (24, 30) im Ladeformat gegenüber der auf dem Datenträger (12) befindlichen Bibliothek (38) gebunden. Eine Vor­richtung (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 Bereit­stellen von ausführbarem Programmcode (40) in dem tragbaren Datenträger (12) gestattet.

Description

Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
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 bereit- zustellen. 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 ver- traulichen, 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 Aufruf Schnittstelle bereit, die sich von der Aufruf schnittsteile der auf dem Datenträger befindlichen Bibliothek unterscheidet. Insbesondere kann die von der Pseudobibliothek bereitgestellte Aufruf Schnittstelle 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 Programmbefeh- Ie 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:
Fig. 1 eine konzeptionelle Darstellung der Datenstrukturen und Datenverarbeitungsstufen in einem Programmentwicklungssystem und einem Datenträger gemäß einem Ausführungsbeispiel der Erfindung, Fig. 2 ein Flußdiagramm eines in dem Programmentwicklungssystem von Fig. 1 ausgeführten Verfahrens zum Erzeugen von Programmcode in einem Ladeformat,
Fig. 3 ein Flußdiagramm eines in dem Datenträger von Fig. 1 ausgeführten Verfahrens zum Bereitstellen von ausführbarem Programmcode, und
Fig. 4 eine beispielhafte Darstellung der Beziehung zwischen einer auf dem Datenträger befindlichen Bibliothek und einer Pseudobibliothek.
In Fig. 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 Fig. 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 Pseudobib- liothek 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üf summe des Programmcodes 24 - generiert. Der durch die Authentisierungsdaten 28 gesicherte Pro- grammcode 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 Initialisie- rungs- 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 Fig. 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üh- rungsbeispiel 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 er- folgt 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 Verwaltungs- einheit 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.
Fig. 2 veranschaulicht nochmals den Verfahrensablauf im Programment- wicklungssystem 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 Authen- tisierungsdaten 28 und der gesicherte Programmcode 30 im Ladeformat erstellt. Das in Fig. 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 fqlgt 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 Fig. 4 an einem Beispiel" veranschaulicht. Die Pseudobibliothek 20 stellt eine virtuelle Aufruf- Schnittstelle mit beispielsweise den Funktionen VirtFuncl, 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 Funcl, 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 VirtFuncl - VirtFunc3 durch die tatsächlichen Funktionen Funcl - Func4 ersetzt. Dies ist in Fig. 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 Funk- tionen 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

P a t e n t a n s p r ü c h e
1. 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 Daten- trä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.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das Binden ein virtuelles Binden gegenüber virtuellen Funktionen der Pseudobibliothek (20) ist.
3. 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.
4. 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 Pseu- dobibliothek (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.
5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß das Binden ein dynamisches Binden ist.
6. 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.
7. 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über- prüfung zur Ausführung bereitgestellt wird.
8. 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.
9. 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.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, daß die Pseudobibliothek (20) eine Aufrufschnittstelle bereitstellt, die sich von einer Aufruf Schnittstelle der auf dem Datenträger befindlichen Bibliothek (38) unterscheidet.
11. Verfahren nach Anspruch 10, dadurch gekennzeichnet, daß die von der Pseudobibliothek (20) bereitgestellte Aufrufschnittstelle eine virtuelle Aufrufschnittstelle ist.
12. 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.
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekenn- zeichnet, daß der Programmcode (24, 30, 40) ein Anwendungsprogramm ist.
14. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, daß der Programmcode (24, 30, 40) ein Kernel-Modul ist.
15. Verfahren nach einem der Ansprüche 1 bis 14, dadurch gekennzeichnet, daß der Programmcode (24, 30, 40) nativer Programmcode ist.
,
16. 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.
17. Computerprogrammprodukt, das eine Vielzahl von Programm- befehlen 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.
18. Computerprogrammprodukt mit Programmcode (24, 30, 40), der durch ein Verfahren nach einem der Ansprüche 1 bis 15 erzeugt worden ist.
EP05818331A 2004-12-06 2005-12-01 Erzeugen von programmcode in einem ladeformat und bereitstellen von ausf]hrbarem programmcode Ceased EP1839136A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102004058882A DE102004058882A1 (de) 2004-12-06 2004-12-06 Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
PCT/EP2005/012854 WO2006061141A1 (de) 2004-12-06 2005-12-01 Erzeugen von programmcode in einem ladeformat und bereitstellen von ausführbarem programmcode

Publications (1)

Publication Number Publication Date
EP1839136A1 true EP1839136A1 (de) 2007-10-03

Family

ID=35788755

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05818331A Ceased EP1839136A1 (de) 2004-12-06 2005-12-01 Erzeugen von programmcode in einem ladeformat und bereitstellen von ausf]hrbarem programmcode

Country Status (6)

Country Link
US (1) US8332834B2 (de)
EP (1) EP1839136A1 (de)
JP (2) JP2008523480A (de)
CN (1) CN101073054B (de)
DE (1) DE102004058882A1 (de)
WO (1) WO2006061141A1 (de)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8452981B1 (en) * 2006-03-01 2013-05-28 Nvidia Corporation Method for author verification and software authorization
US20120023483A1 (en) * 2010-07-20 2012-01-26 Dan Welchman System and method for use in indicating execution of application code
DE102012024250B4 (de) 2012-08-02 2023-04-13 Masktech International Gmbh Verfahren zur Bereitstellung von Chips mit hoher Kopierschutzfunktion, insbesondere für digitale Authentifizierungssysteme, wie Chipkarten oder dergleichen, sowie danach hergestellte Chips
CN109313427B (zh) * 2018-02-02 2021-12-03 深圳配天智能技术研究院有限公司 一种可编程逻辑芯片的保护电路及控制系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1335281A1 (de) * 2002-01-31 2003-08-13 Chess Embedded Technology B.V. System und Verfahren zum Laden von Programmkode in einem Gerät

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2143488C (en) * 1995-02-27 2000-01-11 Robert Paul Duncan Dynamic link libraries without linker or loader support
CA2171898C (en) * 1996-03-15 2000-02-01 Brian Ward Thomson Linker optimization for compiled object oriented programs
JPH09258969A (ja) * 1996-03-21 1997-10-03 Toshiba Corp プログラム開発装置及びプログラム開発方法
US6141698A (en) * 1997-01-29 2000-10-31 Network Commerce Inc. Method and system for injecting new code into existing application code
AU7957998A (en) * 1997-06-09 1999-01-25 Intertrust, Incorporated Obfuscation techniques for enhancing software security
CZ20003437A3 (cs) * 1998-03-23 2001-11-14 International Business Machines Corporation Java runtime systém s upravenou sdílenou oblastí konstant
DE19840029C1 (de) 1998-09-02 2000-04-20 Siemens Ag Verfahren zum Linken von in einen Arbeitsspeicher eines Prozessors nachgeladenen Programmodulen auf einer Chipkarte
GB9920676D0 (en) * 1999-09-01 1999-11-03 Tao Group Ltd Translating and executing object-oriented computer programs
GB9921720D0 (en) * 1999-09-14 1999-11-17 Tao Group Ltd Loading object-oriented computer programs
US20010047512A1 (en) * 2000-03-23 2001-11-29 Leland Szewerenko Method and system for linking multiple processors having shared memory
JP2002132364A (ja) * 2000-10-19 2002-05-10 Yutaka Iizuka プログラムを内部解析から保護する方法、コンピュータ読み取り可能な記録媒体及びプログラムの配布方法
CN1373418A (zh) * 2001-02-28 2002-10-09 无敌科技(西安)有限公司 抽换可携式执行文件格式文件资料的方法
BRPI0209761B1 (pt) * 2001-05-30 2018-04-03 Blackberry Limited Sistema de tempo de execução de dispositivo de comunicação móvel para executar uma aplicação, método de manusear um módulo ligado ao principal em um sistema alvo e produto de programa de computador
US7099663B2 (en) * 2001-05-31 2006-08-29 Qualcomm Inc. Safe application distribution and execution in a wireless environment
JP2003140758A (ja) * 2001-11-07 2003-05-16 Hitachi Ltd プログラム暗号化方法、復号化方法および実行方法
JP2003337629A (ja) * 2002-05-18 2003-11-28 Mitsuko Miyaji プログラム難読化方法及び装置
JP4115759B2 (ja) * 2002-07-01 2008-07-09 株式会社東芝 耐タンパプロセッサにおける共有ライブラリの使用方法およびそのプログラム

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1335281A1 (de) * 2002-01-31 2003-08-13 Chess Embedded Technology B.V. System und Verfahren zum Laden von Programmkode in einem Gerät

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
"Method stub", 17 September 2004 (2004-09-17), Retrieved from the Internet <URL:www.wikipedia.org> [retrieved on 20130129] *

Also Published As

Publication number Publication date
CN101073054B (zh) 2011-01-26
JP2013041598A (ja) 2013-02-28
US8332834B2 (en) 2012-12-11
CN101073054A (zh) 2007-11-14
WO2006061141A1 (de) 2006-06-15
US20090044172A1 (en) 2009-02-12
DE102004058882A1 (de) 2006-06-08
JP2008523480A (ja) 2008-07-03

Similar Documents

Publication Publication Date Title
DE102009013384B4 (de) System und Verfahren zur Bereitstellung einer sicheren Anwendungsfragmentierungsumgebung
DE60127310T2 (de) Vorrichtung zum schutz digitaler daten
DE202009019148U1 (de) Dateisystemzugriff für Web-Anwendungen und native Kodemodule
DE102012200613A1 (de) System und Verfahren zur Unterstützung von JIT in einem sicheren System und zufällig zugewiesenen Speicherbereichen
EP1798653B1 (de) Verfahren, Computerprogrammprodukt und Vorrichtung zum Schützen eines einen Funktionsblock aufweisenden Programms
DE102004057490B4 (de) Vorrichtung und Verfahren zum Verarbeiten eines Programmcodes
WO2023001773A1 (de) Absicherung eines einrichtevorgangs eines unterverzeichnisses und einer netzwerkschnittstelle für eine containerinstanz
WO2006061141A1 (de) Erzeugen von programmcode in einem ladeformat und bereitstellen von ausführbarem programmcode
DE102005046696B4 (de) Verfahren zum Erzeugen von geschütztem Programmcode und Verfahren zum Ausführen von Programmcode eines geschützten Computerprogramms sowie Computerprogrammprodukt
EP1801696B1 (de) Multithreading - fähige virtuelle Maschine
DE102020206039A1 (de) Erstellen einer Container-Instanz
CH712679B1 (de) Verfahren zur Maskierung und eindeutigen Signierung von Datenbank-Quellcodes.
EP1879128B1 (de) Abgesicherter Programmcode
EP1732001B1 (de) Validierung eines zur nativen Ausführung durch einen Prozessor vorgesehenen Programms auf einem Datenträger
DE102017214584A1 (de) Verfahren und Vorrichtung zum Schützen eines Gerätes
EP1318451B1 (de) Verfahren zum Ausführen eines Programms auf einem Computer
DE102017214591A1 (de) Verfahren und Vorrichtung zum Schützen eines Gerätes
DE102022112550A1 (de) Verfahren zum Anpassen einer Funktionalität einer Softwareapplikation an eine für die Ausführung der Funktionalität verfügbare Hardwareausstattung eines Kraftfahrzeugs sowie computerlesbares Speichermedium und Computersystem
EP2573677B1 (de) Datenaustausch zwischen Applikationen
DE102018202936A1 (de) Computerprogramm, insbesondere für ein Steuergerät eines Kraftfahrzeugs
EP1720096B1 (de) Verfahren zum Hinzufügen einer Funktionalität zu einem ausführbaren ersten Modul eines Programmpakets
DE102014113441A1 (de) Schutz vor Software-Komponenten mittels Verschlüsselung
AT524619A1 (de) Computerimplementiertes Verfahren zum autorisierten Ausführen einer Software, System zur Datenverarbeitung, Computerprogrammprodukt und computerlesbares Speichermedium
DE102018005102A1 (de) Adaptive Sicherheitsupdates für Applikationen
DE102010040259A1 (de) Transferverfahren zum kontrollierten Transfer von Daten zwischen Domänen und Verfahren zum Bereitstelleneines ausführbaren Transferprogrammcodes für ein Transferprogramm sowie eine entsprechende Transfervorrichtung und ein zugehöriges Sicherheitsmodul

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

AK Designated contracting states

Kind code of ref document: A1

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

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

Effective date: 20080502

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