EP4659100A1 - Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul - Google Patents

Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul

Info

Publication number
EP4659100A1
EP4659100A1 EP24708670.5A EP24708670A EP4659100A1 EP 4659100 A1 EP4659100 A1 EP 4659100A1 EP 24708670 A EP24708670 A EP 24708670A EP 4659100 A1 EP4659100 A1 EP 4659100A1
Authority
EP
European Patent Office
Prior art keywords
operating system
processor device
module
modules
java card
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.)
Pending
Application number
EP24708670.5A
Other languages
English (en)
French (fr)
Inventor
Thomas Stocker
Steffen Steinmeier
Barbara Jager
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+Devrient Mobile Security Germany GmbH
Original Assignee
Giesecke+Devrient Mobile Security Germany GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Giesecke+Devrient Mobile Security Germany GmbH filed Critical Giesecke+Devrient Mobile Security Germany GmbH
Publication of EP4659100A1 publication Critical patent/EP4659100A1/de
Pending legal-status Critical Current

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
    • G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
    • G06F9/44526—Plug-ins; Add-ons
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation

Definitions

  • the invention relates to the installation of an operating system in a processor device, in particular a security module, namely a secure processor device with limited computing resources, as well as the updating of an installed operating system.
  • Security modules namely secure processor devices with limited computing resources, in the form of chip card products have been known for a long time.
  • Other known security modules include inlays for electronic passports and chip cards with chips and interfaces (contact and/or contactless).
  • a chip card product reader is required, with which the chip card product can be removably coupled in a contact or contactless manner.
  • Security modules are increasingly gaining ground, which functionally correspond to the chip card products listed above and other chip card products without having a chip card product body, and which are embedded or soldered into a chip of a mobile radio-capable terminal (mobile terminal), or are implemented as secure software within a mobile radio-capable terminal (mobile terminal).
  • Such security modules are firmly coupled to the mobile radio-capable terminal (mobile terminal) and cannot be removed from it or cannot be easily removed.
  • security modules that are functionally equivalent to chip card products without being chip cards are embedded UICCs (eUlCCs) and integrated UICCs (iUICCs) integrated into a chip in a mobile device, as well as SIM cards simulated in software, known as eSIMs.
  • security modules without a chip card body for example, in a secure element within a mobile device or in an eUlCC or iUICC, in the form of payment transaction solutions.
  • security modules without a chip card body or comparable physical body for example, in a secure element within a mobile device, such as virtual electronic identity cards and virtual electronic passports.
  • Every operational security module (secure processor device with limited computing resources) has an operating system that provides the basic functionalities of the security module.
  • the basic functionalities include operational functionalities such as memory management, including writing data to memory and reading data from memory in the security module.
  • the basic functionalities also include functionalities for exchanging data with external units, for example with a mobile radio-capable terminal in which the security module is operated, or with a local or remote server.
  • the functionalities for data exchange include, for example, implementations of transmission protocols for data exchange.
  • the basic functionalities also include functionalities for securing other functionalities, for example cryptographic algorithms, for example cryptographic algorithms for encrypting and/or decrypting data of any kind, or cryptographic algorithms for generating and/or verifying cryptographic signatures.
  • Operating systems for security modules are known in Java Card code as well as in native code.
  • the operating system is loaded as a whole into the security module and installed in the security module.
  • the complete operating system is provided outside the security module in a suitable form so that the operating system as a whole can be loaded into the security module and installed there, for example in the form of an installation package for the complete operating system.
  • Part of building the operating system security modules is building cryptographic algorithms into the operating system. This involves building an operating system framework and one or more cryptographic algorithms separately as source code, and then building the source codes of the one or more cryptographic algorithms into the source code of the operating system framework. Similarly, libraries can be built separately from the operating system framework and then built into the operating system framework.
  • Changes to the operating system can include, for example, updates or bug fixes or adaptations to changed use cases.
  • a changed use case can also be due to the fact that an operating system created for a first customer is also to be used for a second customer who, although in principle using the same use case as the first customer, wants different detailed solutions for partial aspects of the operating system. This means that the operating system created for the first customer can be reused, but with minor changes or adaptations.
  • a common requirement for operating systems for security modules is to certify the operating system. To achieve certification, the operating system must undergo systematic testing by an accredited certification body and pass the tests. If changes are made to the operating system, recertification of the entire operating system is usually required. Even if an operating system is to be used by two customers operating in the same industry, with only minor variations between the operating system versions for the two customers, both operating system versions may need to be fully certified alongside each other and independently.
  • a special scenario of a change to the operating system is the replacement of an implementation of a cryptographic algorithm integrated in the operating system, for example with an updated or bug-fixed implementation the same algorithm, or by a different, e.g. more recent, algorithm.
  • an implementation of the Advanced Encryption Standard AES in which weaknesses have been discovered could be replaced by a modified implementation of AES.
  • the Data Encryption Standard DES could be replaced by the newer AES.
  • this is done outside the security module by incorporating the source code of the new or modified cryptographic algorithm into the source code of the operating system framework to replace the previously existing source code of the cryptographic algorithm.
  • the modified operating system ie the source code of the entire modified operating system, comprising the source code of the new or modified cryptographic algorithm and the source code of the operating system framework, is then recertified and loaded into the security module and installed in the security module.
  • What would be desirable is a more efficient and flexible solution for installing and modifying, in particular updating, an operating system in a security module, which allows the installation and modification, especially a subsequent update, of the operating system to be achieved more quickly and with fewer resources.
  • Prior art document US8522234B2 discloses a computer-implemented method for tailoring the installation of a modular operating system in a computer system.
  • the modular operating system comprises a base module and a plurality of installable feature modules. Based on desired performance characteristics of the operating system and predetermined operating capacity and available storage capacity of the computer system, parts of the modular operating system are selectively installed in order to best achieve the desired performance characteristics while maintaining the operating capacity and available storage capacity. To achieve this, only the required or, in view of the operating capacity and available storage capacity to be maintained, The modules are assembled by an operating system tailor (“tailor") using the remaining storage capacity permitted and the operating system thus created is installed.
  • an operating system tailor tailor
  • Prior art document US6292941B1 discloses a method for installing and customizing an operating system on a local computer, wherein a customized operating system is established on the local computer by remotely customizing a standard operating system provided locally in a removable memory of the local computer, with a customization model provided by a remote management computer.
  • the invention is based on the object of creating a more efficient and flexible solution for installing and modifying, in particular updating, an operating system in a processor device, in particular a security module, which allows the installation and modification, especially a later update, of the operating system to be achieved more quickly and with less resource expenditure.
  • the core idea of the invention is to use a modular installation solution to specifically reduce an installation to be carried out to desired parts of the operating system, and to omit other parts of the operating system during installation or to provide them for other installation steps.
  • the inventive method according to claim 1 is provided in detail for installing an operating system, or parts of an operating system, in a processor device.
  • the operating system comprises a plurality of two or more operating system functionalities.
  • the method comprises the steps of: - loading the operating system, or parts of the operating system, into the processor device; - installing the loaded operating system, or parts of the operating system, in the processor device.
  • the method is characterized in that a) the loading of the operating system, or parts of the operating system, takes place by loading at least one or more separate operating system modules, wherein the respective operating system module: b) contains code which is set up to install an operating system functionality corresponding to the operating system module in the processor device; and c) enables a separate installation of only the operating system functionality corresponding to the respective operating system module, in particular without installing further operating system functionalities.
  • each of which contains code that is designed to install an operating system functionality corresponding to the operating system module in the processor device makes it possible to tailor and specifically provide only selected functionalities of the operating system for installation and then install them. Other operating system functionalities that are not currently to be installed, for example because they are not needed or remain unchanged, are not provided. Accordingly, the modular design of the code for installing the operating system or parts of the operating system allows the volume of data to be installed to be greatly reduced. The reduced data volume leads to a reduction in the time and computing resources required for installation. This applies equally regardless of whether the installation is aimed at an initial installation of an operating system or parts thereof, or at a change.
  • a further advantage of the invention is that, due to the smaller volume of data to be installed, the risk of data errors, data transmission errors when transferring the code to the processor device and installation errors when installing the code in the processor device can be reduced.
  • a further advantage of the invention is that, due to the possibility of loading and installing individual operating system modules and thus operating system functionalities in isolation from one another, it is possible to evaluate the individual operating system modules and thus operating system functionalities separately from one another and to have them certified by approved certification bodies, for example accredited testing laboratories. If only a specific operating system module and the associated operating system functionality are changed, a suitable separation or isolation of the operating system modules from one another can ensure that only this operating system module and the associated operating system functionality need to be re-certified. The certification of the operating system modules and thus operating system functionalities that remain unchanged remains unaffected.
  • Various measures are known for separating or isolating different executable program codes, which can also be applied to the operating system modules according to the invention as executable program codes. Examples of measures for separating codes are contexts, security domains and sandbox mechanisms.
  • different operating system modules are arranged in different security domains, in particular Global Platform security domains, and are executed in the different security domains.
  • the - or the respective - operating system module is further d) isolated from other operating system modules, so that access between the operating system module - or the respective operating system module - and other operating system modules is prevented, or is only possible at most by means of controlled interface mechanisms.
  • the processor device is Java or Java Card based, a Shareable Interface Object or Entry Point Object can be provided as a controlled interface mechanism, for example.
  • the operating system or parts of the operating system are optionally installed by installing the loaded separate operating system modules separately.
  • the operating system or parts of the operating system are optionally installed by installing the loaded separate operating system modules together.
  • the installation is optionally installed by installing the loaded separate operating system modules separately for some operating system modules, and the installation is optionally installed by installing the loaded separate operating system modules together for some operating system modules.
  • Different scenarios for installing an operating system or parts of an operating system may involve different numbers of operating system modules and/or different sized portions of the operating system, in Maxima Ifa II the entire operating system. If a number of operating system modules are loaded for installation at the same time, the installation of the multiple operating system modules can be carried out either individually or alternatively in a block, whereby the modularity no longer has an effect on the installation process. Which installation procedure is advantageous in individual cases can depend on different framework conditions.
  • At least one trusted loader which is configured to load further operating system modules into the processor device and to cause the further operating system modules to be installed in the processor device;
  • the Trusted Loader is optionally the first operating system module to be installed in the processor device and subsequently enables the loading and installation of further operating system modules in the processor device by the Trusted Loader.
  • the Trusted Loader is optionally not a functional operating system module itself, but is exclusively designed to load additional operating system modules into the processor device and to cause the additional operating system modules to be installed in the processor device.
  • the Trusted Loader already includes modules for basic functionalities of the operating system, such as: - memory management of memory units of the processor device; - reading and/or writing data, including programs, in memory units of the processor device; - processing of commands in the processor device, including receiving commands, executing commands, Creating commands and issuing commands.
  • modules for basic functionalities of the operating system such as: - memory management of memory units of the processor device; - reading and/or writing data, including programs, in memory units of the processor device; - processing of commands in the processor device, including receiving commands, executing commands, Creating commands and issuing commands.
  • these basic functionalities of the operating system such as: - memory management of memory units of the processor device; - reading and/or writing data, including programs, in memory units of the processor device; - processing of commands in the processor device, including receiving commands, executing commands, Creating commands and issuing commands.
  • a protocol module the installation of which implements a protocol for communication between the processor device and units located outside the processor device;
  • the cryptographic algorithm can be, for example, a symmetric or asymmetric algorithm, such as DES, AES, 3DES, RSA, or another algorithm.
  • the protocol can also optionally be a transmission protocol for payment transactions or telecommunications or identity/passport applications.
  • the operating system module is designed as a Java Card cap file according to the Java Card specification.
  • the operating system module can optionally contain Java Card code or native code or both Java Card code and native code.
  • a Java Card cap file can contain native code in addition to Java code.
  • an operating system module is loaded by loading a service in which the operating system module is integrated into the processor device.
  • a service for an operating system module for an operating system functionality is an instance, in particular a program code, which is set up to execute the service, e.g. the program code.
  • the service e.g. program code
  • the operating system functionality is installed in the processor device.
  • the operating system is designed at least partially or entirely as a Java Card-based operating system.
  • the service is designed as a Java Card applet and the operating system module is designed as a Java Card cap file.
  • the service is executed by calling the Java Card applet and executing it. This installs the operating system functionality corresponding to the Java Card cap file in the processor device.
  • the Java Card cap file can also contain native code in addition to Java code.
  • the Java Card applet through which the service is implemented is designed as a modified Java Card applet, which is modified in such a way that the modified Java Card applet cannot be called using the process() and select() commands with which a standard Java Card applet can be called, but only has and can be called via a controlled interface object, in particular a Shareable Interface Object or Entry Point Object.
  • the Java Card applet is assigned an application identifier, AID, whereby a registry is set up in the processor device into which the application identifier, AID, of the Java Card applet is entered when the applet is loaded into the processor device.
  • the Java Card applet is called and executed using the application identifier, AID, entered in the registry.
  • the Java Card applet is also called using a unified resource identifier string, URI string, that points to the service. If the URI string is called, the operating system functionality corresponding to the Java Card cap file is installed in the processor device.
  • Modules executed in different contexts that are isolated from each other.
  • the contexts are optionally isolated, in particular by means of a microprocessor device MPU and/or a memory management MPU.
  • interaction or communication between different services is only possible via a controlled interface mechanism, in particular a Shareable Interface Object and/or an Entry Point Object.
  • the isolation of the contexts is particularly advantageous in connection with the certification of the processor device.
  • the isolation of the contexts can in particular help to reduce the effort required for re-certification when changes are made to the operating system.
  • the isolation of the contexts is designed in such a way that it is sufficient, in accordance with the applicable certification regulations for the processor device, that when changes are made to an operating system module in a first context, the existing certifications of other operating system modules in other contexts that are isolated from the first context remain unaffected by the change. This ensures that only the changed operating system module and the associated operating system functionality need to be re-certified.
  • each operating system module is certified separately. This means that in a fully certified operating system in which only a single operating system module, or a group of individual operating system modules, and the associated operating system functionality(s) is/are changed, the existing certification for the unchanged components of the operating system can be retained, and only the changed operating system parts (module(s), functionality(s)) need to be re-certified.
  • Certification provides for different hierarchical levels of certification. The higher the level of certification, the more stringent the testing specifications. If a processor device has passed a certain level of certification, it is considered certified according to that level and all lower levels below it. Higher levels are considered not achieved and the processor device is considered not certified for the higher levels.
  • a high level of certification means a high level of effort in terms of measures, in particular security measures, which must be provided in the processor device in order to pass the certification test. Measures can include, for example, program routines to defend against side-channel attacks, hacker attacks and the like, such as masking, encryption, concealment, redundancies and others. Time-consuming and costly development work is required to equip the processor device accordingly. In addition, the complexity of the product increases with the measures, which can lead to the risk of errors if implemented carelessly. In addition, the tests for higher certification levels are more time-consuming and costly than tests for lower certification levels. Accordingly, the highest level of certification is not always sought, but typically only a certification level that is sufficient for the specific application.
  • the Trusted Loader loads other operating system modules into the processor device.
  • the Trusted Loader therefore influences every operating system module it loads. Accordingly, an operating system module loaded by the Trusted Loader can have a maximum level of certification that the Trusted Loader has achieved (passed), even if the operating system module outside the processor device has achieved (passed) certification at a higher level.
  • the trusted loader has the highest or at least no worse level of certification relative to other operating system modules. This means that the level of the other operating system modules that can be loaded by the trusted loader is always maintained and never worsened.
  • additional application modules can be loaded into the processor device for installing applications.
  • some operating system modules can contain application modules, and with such an operating system module, the application modules contained therein can also be loaded into the processor device and installed there.
  • a security module is provided as the processor device, i.e. a secure processor device with limited computing resources, in particular a chip card or a corresponding processor module without a card-shaped body.
  • the processor device includes:
  • At least one storage unit comprising one or more memories for storing data including programs
  • FIG. 1 is a schematic representation of a modular installation and modular extension of an operating system by sequential installation of several operating system modules, according to embodiments of the invention
  • Fig. 2 is a schematic representation of an arrangement of several Java-based operating system modules to be executed in mutually isolated contexts, according to embodiments of the invention
  • Fig. 3 shows an operating system module designed as a service, according to embodiments of the invention.
  • Fig. 1 shows a schematic representation of a module-by-module installation and modular extension of an operating system by sequential installation of several operating system modules in a processor device, according to embodiments of the invention.
  • Partial figure 1-1 of Fig. 1 shows the processor device in a first state of the installation 1-1, in which only one Trusted Loader TL is installed in the processor device.
  • the Trusted Loader TL already includes the first basic functionalities BOS of the operating system.
  • the basic functionalities BOS of the operating system could also be loaded into the processor device by the Trusted Loader TL.
  • Partial figure 1-2 of Fig. 1 shows the processor device in a second state of the installation 1-2, in which in the processor device, in addition to the Trusted Loader TL with the basic functionalities BOS of the operating system according to partial figure 1-1, various operating system functionalities from two (or more) operating system modules 0SM1, extended OSMn and a library from a library module LIBM1 (library module) are installed.
  • the two operating system modules 0SM1, OSMn and the library module LIBM1 are loaded into the processor device.
  • the modules OSM1, OSMn, LIB2 were executed in the processor device, and thereby the various operating system functionalities and the library were installed in the processor device.
  • Partial figure 1-3 of Fig. 1 shows the processor device in a third state of the installation 1-3, in which in the processor device, in addition to the modules and functionalities shown in partial figure 1-2, a further library from a further library module LIB2 and two applications from two application modules APM1, APM2 have been installed. In addition, operating system functionalities that had been installed from the first operating system module OS1 have been uninstalled and/or deleted.
  • Fig. 2 shows a schematic representation of a processor device in which an arrangement of several Java-based (more precisely Java Card-specific) operating system modules to be executed in mutually isolated contexts is contained, according to embodiments of the invention.
  • a trusted loader TL is contained in the processor device.
  • the trusted loader already contains basic functionalities of the operating system Base OS itself, or it has loaded the basic functionalities by loading one or more basic functionality modules and installed them in the processor device.
  • the processor device contains three services BOS Service, Service 1 and Service 2.
  • Each of the three services contains executable program code, the execution of which installs the payload content of the service in the processor device.
  • Each of the three services is isolated from the other two services by a context boundary L, so that each service, when executed, is executed in its own isolated context.
  • Each service contains a cap file as payload content in accordance with the Java Card specification, which contains the code to be installed.
  • the cap file contains both Java code and native code.
  • the first of the three services, BOS Service is an operating system module for installing additional basic functionalities of the operating system.
  • a second of the three services, Service 1 is an operating system module for installing a cryptographic algorithm in the processor device.
  • a third of the three services, Service 2 is an operating system module for installing an integrated subscriber identity module iUICC in the processor device.
  • Fig. 3 shows an operating system module designed as a service comprising a Java Card Cap File in a detailed view, according to embodiments of the invention.
  • the service contains a Java Card Cap File that contains Java code according to the Java Card specification.
  • the Java code is contained in one or more files, the Java source files, with the Java (Card)-specific name extension *.java.
  • the exemplary Cap File shown in Fig. 3 also contains a static resource component, by means of which native code and resources can be added to the Java Card Cap File.
  • the native code can be provided in one or more files.
  • Native code can be in *.bin or *.hex format, for example.
  • Native resources can be in *.txt or *.html format, for example.
  • the Cap File or Java Code is structured in a Java Card-typical manner and contains, for example, data elements such as headers, directories, one or more applets, import information, a constant pool, classes, and the like. Native code and resources can be added to the cap file as static resources using the Static Resource element.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung schafft ein Verfahren zum Installieren, in einer Prozessoreinrichtung, eines Betriebssystems, das eine Mehrzahl von zwei oder mehr Betriebssystem-Funktionalitäten umfasst, oder von Teilen eines solchen Betriebssystems, wobei das Verfahren die Schritte umfasst: - Laden des Betriebssystems, oder der Teile des Betriebssystems, in die Prozesso- reinrichtung; - Installieren des geladenen Betriebssystems, oder der geladenen Teile des Betriebssystems, in der Prozessoreinrichtung; dadurch gekennzeichnet, dass a) das Laden des Betriebssystems, oder der Teile des Betriebssystems, als Laden zumindest eines oder mehrerer voneinander getrennter Betriebssystem-Module erfolgt, wobei das oder das jeweilige Betriebssystem-Modul b) Code enthält, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren, und c) ein getrenntes Installieren nur der dem jeweiligen Betriebssystem-Modul entsprechenden Betriebssystem-Funktionalität ermöglicht, insbesondere ohne dass weitere Betriebssystem-Funktionalitäten installiert werden.

Description

Installieren eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul
Gebiet der Erfindung
Die Erfindung betrifft das Installieren eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul, nämlich einer sicheren Prozessoreinrichtung mit beschränkten Rechenressourcen, sowie das Aktualisieren eines installierten Betriebssystems.
Stand der Technik
Sicherheitsmodule, nämlich sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen, in Form von Chipkarten-Produkten sind seit langer Zeit bekannt. Als derartige Chipkarten-Produkte sind im Telekommunikationsbereich SIM-Karten oder UICCs (UICC = Universal Integrated Circuit Card), im Zahlungsverkehrsbereich Zahlungsverkehrschipkarten, im Gesundheitsbereich Gesundheitskarten-Chipkarten und Heilberufsausweis-Chipkarten, sowie im Identitätenbereich elektronische Personalausweise mit Chip und elektronische Reisepässe mit Chip als Sicherheitsmodule bekannt. Als Sicherheitsmodule sind weiter mit Chip und Schnittstelle (kontaktbehaftet oder/und kontaktlos) Inlays für elektronische Reisepässe und Chipkarten weitere Vorprodukte für Chipkarten bekannt. Zum Betrieb eines Chipkarten- Produktes ist ein Chipkarten-Produkt-Leser erforderlich, mit dem das Chipkarten- Produkt in entfernbarer Weise kontaktbehaftet oder kontaktlos gekoppelt werden kann.
Zunehmend fassen Sicherheitsmodule (sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen) Fuß, die funktionell den obenstehend aufgelisteten und weiteren Chipkarten-Produkten entsprechen, ohne einen Chipkarten-Produkt- Körper zu haben, und die in einen Chip eines mobilfunkfähigen Endgeräts (mobilen Endgeräts) eingebettet oder eingelötet sind, oder als gesicherte Software innerhalb eines mobilfunkfähigen Endgeräts (mobilen Endgeräts) verwirklicht sind. Derartige Sicherheitsmodule sind fest mit dem mobilfunkfähigen Endgerät (mobilen Endgerät) gekoppelt und nicht oder nicht ohne Weiteres aus diesem entfernbar. Beispiele für Sicherheitsmodule, die den Chipkarten-Produkten funktionell gleichgestellt sind, ohne Chipkarten zu sein, sind im Telekommunikationsbereich embedded UICCs, eUlCCs, und in einen Chip eines mobilen Endgeräts integrierte integrated UICCs, iUICCs, sowie in Software nachgebildete SIM-Karten, genannt eSIMs. Im Zahlungsverkehrsbereich gibt es als Sicherheitsmodule ohne Chipkartenkörper, beispielsweise, in einem Secure Element innerhalb eines mobilen Endgeräts oder in einem eUlCC oder in einem iUICC vorgehaltene Zahlungsverkehrslösungen. Im Identitätenbereich gibt es als Sicherheitsmodule ohne Chipkartenkörper oder vergleichbaren physischen Körper, beispielsweise, in einem Secure Element innerhalb eines mobilen Endgeräts vorgesehene virtuelle elektronische Personalausweise und virtuelle elektronische Reisepässe.
Jedes operationsfähige Sicherheitsmodul (sichere Prozessoreinrichtung mit beschränkten Rechenressourcen) besitzt ein Betriebssystem, das grundlegende Funktionalitäten des Sicherheitsmoduls zur Verfügung stellt. Zu den grundlegenden Funktionalitäten zählen operative Funktionalitäten wie beispielsweise Speicherverwaltung einschließlich Schreiben von Daten in Speicher und Auslesen von Daten aus Speichern des Sicherheitsmoduls. Zu den grundlegenden Funktionalitäten zählen weiter Funktionalitäten zum Datenaustausch mit externen Einheiten, beispielsweise mit einem mobilfunkfähigen Endgerät, in welchem das Sicherheitsmodul betrieben wird, oder mit einem lokalen oder entfernten Server. Zu den Funktionalitäten zum Datenaustausch zählen beispielsweise Implementierungen von Übertragungsprotokollen für den Datenaustausch. Zu den grundlegenden Funktionalitäten zählen weiter Funktionalitäten zur Absicherung anderer Funktionalitäten, beispielsweise kryptographische Algorithmen, beispielsweise kryptographische Algorithmen zur Verschlüsselung oder/und Entschlüsselung von Daten jeder Art, oder kryptographische Algorithmen zur Erzeugung oder/und Verifizierung kryptographischer Signaturen.
Betriebssysteme für Sicherheitsmodule sind in Java Card Code sowie in nativem Code bekannt. Herkömmlicherweise wird, um ein Sicherheitsmodul mit einem Betriebssystem auszustatten, das Betriebssystem als Ganzes in das Sicherheitsmodul geladen und im Sicherheitsmodul installiert. Hierzu wird außerhalb des Sicherheitsmodul das vollständige Betriebssystem in einer geeigneten Form bereitgestellt, so dass das Betriebssystem als Ganzes in das Sicherheitsmodul geladen und dort installiert werden kann, beispielsweise in Form eines Installationspakets für das vollständige Betriebssystem.
Ein Teil des Erstellens des Betriebssystems von Sicherheitsmodulen ist der Einbau kryptographischer Algorithmen in das Betriebssystem. Hierzu werden ein Betriebssystem-Grundgerüst und ein oder mehrere kryptographische Algorithmen separat als Source Code erstellt, und anschließend die Source Codes der ein oder mehreren kryptographischen Algorithmen in den Source Code des Betriebssystem-Grundge- rüsts eingebaut. Ähnlich können Bibliotheken (Libraries) getrennt vom Betriebssystem-Grundgerüst erstellt werden und anschließend in das Betriebssystem-Grundgerüst eingebaut werden.
Werden später Änderungen, beispielweise Aktualisierungen oder/und Fehlerbehebungen, am Betriebssystem durchgeführt, so wird außerhalb des Sicherheitsmoduls eine vollständige geänderte Version des Betriebssystems erstellt, in welcher die Änderungen, beispielweise Aktualisierungen oder/und Code-Patches zur Umsetzung von Fehlerbehebungen, verwirklicht sind, und das geänderte Betriebssystem als Ganzes in das Sicherheitsmodul geladen und dort installiert, in ähnlicher Weise wie das ursprüngliche Betriebssystem geladen und installiert worden ist.
Bei Änderungen am Betriebssystem für das Sicherheitsmodul sind unter Umständen nur geringe Anteile des Betriebssystems durch die Änderungen betroffen, und andere Anteile des Betriebssystems bleiben gegenüber der im Sicherheitsmodul be- reits vorhandenen Version des Betriebssystems unverändert. Dennoch muss das gesamte Betriebssystem neu geladen und installiert werden. Hierdurch kann der Aufwand an zu ladender und zu installierender Datenmenge sehr groß sein im Vergleich zu den durchgeführten Änderungen. Das Durchführen der Änderungen am Betriebssystem ist dadurch ineffizient und langsam.
Als Änderungen am Betriebssystem können beispielweise Aktualisierungen oder Fehlerbehebungen oder Anpassungen an geänderte Anwendungsfälle vorgesehen sein. Ein geänderter Anwendungsfall kann beispielsweise auch darauf zurückzuführen sein, dass ein für einen ersten Kunden erstelltes Betriebssystem auch für einen zweiten Kunden verwendet werden soll, der zwar vom Grundsatz her den gleichen Anwendungsfall wie der erste Kunde nutzt, jedoch unterschiedliche Detaillösungen für Teilaspekte des Betriebssystems wünscht. Hierdurch kann das für den ersten Kunden erstellte Betriebssystems zwar wiederverwendet werden, allerdings mit geringen Änderungen oder Anpassungen.
Verbreitet besteht für Betriebssysteme für Sicherheitsmodule die Notwendigkeit, das Betriebssystem zu zertifizieren. Damit das Betriebssystem die Zertifizierung erlangt, muss das Betriebssystem durch eine zugelassene Zertifizierungseinrichtung systematischen Tests unterzogen werden und die Tests bestehen. Werden Änderungen am Betriebssystem vorgenommen, ist in der Regel eine erneute Zertifizierung des gesamten Betriebssystems erforderlich. Selbst wenn ein Betriebssystem für zwei in derselben Branche aktive Kunden verwendet werden soll, mit nur geringfügigen Variationen zwischen den Betriebssystem-Versionen für die beiden Kunden, kann es sein, dass beide Betriebssystem-Versionen nebeneinander und unabhängig voneinander vollständig zertifiziert werden müssen.
Ein spezielles Szenario einer Änderung des Betriebssystems ist er Austausch einer im Betriebssystem integrierten Implementierung eines kryptographischen Algorithmus, beispielsweise durch eine aktualisierte oder fehlerbereinigte Implementierung desselben Algorithmus, oder durch einen anderen, z.B. aktuelleren, Algorithmus. Beispielsweise könnte eine Implementierung des Advanced Encryption Standard AES, bei der Schwächen entdeckt wurden, durch eine abgeänderte Implementierung des AES ersetzt werden. Gemäß einem anderen Beispiel könnte der Data Encryption Standard DES durch den neueren AES ersetzt werden. Herkömmlicherweise wird hierzu außerhalb des Sicherheitsmoduls der Source Code des neuen oder geänderten kryptographischen Algorithmus in den Source Code des Betriebssystem- Grundgerüsts eingebaut, um den zuvor vorhandenen Source Code des kryptographischen Algorithmus zu ersetzen. Anschließend wird das geänderte Betriebssystem, d.h. der Source-Code des gesamten geänderten Betriebssystems, umfassend den Source Code des neuen oder geänderten kryptographischen Algorithmus und den Source Code des Betriebssystem-Grundgerüsts, neu zertifiziert und in das Sicherheitsmodul geladen und im Sicherheitsmodul installiert.
Wünschenswert wäre eine effizientere und flexiblere Lösung zur Installierung und Änderung, insbesondere Aktualisierung, eines Betriebssystems in einem Sicherheitsmodul, die es erlaubt, die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand zu erreichen.
Das Dokument US8522234B2 aus dem Stand der Technik offenbart ein computerimplementiertes Verfahren zum Maßschneidern der Installation eines modularen Betriebssystems in ein Computersystem. Das modulare Betriebssystem umfasst ein Basismodul und eine Mehrzahl von installierbaren Merkmalsmodulen. Basierend auf gewünschten Performanz-Eigenschaften des Betriebssystems und vorbestimmter Betriebskapazität sowie verfügbarer Speicherkapazität des Computersystems werden Teile des modularen Betriebssystems selektiv installiert, um die gewünschten Performanz-Eigenschaften bei Beibehaltung der Betriebskapazität und verfügbaren Speicherkapazität bestmöglich zu erreichen. Um dies zu erreichen, werden nur die erforderlichen, bzw. angesichts der beizubehaltenden Betriebskapazität und frei zu bleibenden Speicherkapazität zulässigen, Module durch einen Betriebssystem-Maßschneider („tailorer") zusammengesetzt und das so erzeugte Betriebssystem installiert.
Das Dokument US6292941B1 aus dem Stand der Technik offenbart ein Verfahren zum Installieren und Anpassen eines Betriebssystems auf einem lokalen Computer, wobei ein angepasstes Betriebssystem auf dem lokalen Computer eingerichtet wird, indem ein lokal in einem entfernbaren Speicher des lokalen Computers bereitgestelltes Standard-Betriebssystem aus der Ferne angepasst wird, mit einem Anpassungsmodell, das von einem entfernten Verwaltungscomputer bereitgestellt wird.
Der Erfindung liegt die Aufgabe zu Grunde, eine effizientere und flexiblere Lösung zur Installierung und Änderung, insbesondere Aktualisierung, eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul, zu schaffen, die es erlaubt, die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand zu erreichen.
Die Aufgabe wird gelöst durch ein Verfahren nach Anspruch 1. Vorteilhafte Ausgestaltungen der Erfindung sind in den abhängigen Ansprüchen angegeben.
Der Kerngedanke der Erfindung besteht darin, durch eine modulare Installationslösung eine durchzuführende Installation zielgerichtet auf gewünschte Teile des Betriebssystems zu reduzieren, und andere Teile des Betriebssystems bei der Installation wegzulassen oder für andere Installationsschritte vorzusehen.
Das erfindungsgemäße Verfahren nach Anspruch 1 ist im Detail zum Installieren eines Betriebssystems, oder von Teilen eines Betriebssystems, in einer Prozessoreinrichtung vorgesehen. Das Betriebssystem umfasst eine Mehrzahl von zwei oder mehr Betriebssystem-Funktionalitäten. Das Verfahren umfasst Schritte: - Laden des Betriebssystems, oder der Teile des Betriebssystems, in die Prozessoreinrichtung; - Installieren des geladenen Betriebssystems, oder der geladenen Teile des Betriebssystems, in der Prozessoreinrichtung. Das Verfahren ist dadurch gekennzeichnet, dass a) das Laden des Betriebssystems, oder der Teile des Betriebssystems, als Laden zumindest eines oder mehrerer voneinander getrennter Betriebssystem-Module erfolgt, wobei das oder das jeweilige Betriebssystem-Modul: b) Code enthält, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren; und c) ein getrenntes Installieren nur der dem jeweiligen Betriebssystem-Modul entsprechenden Betriebssystem-Funktionalität ermöglicht, insbesondere ohne dass weitere Betriebssystem-Funktionalitäten installiert werden.
Das Vorsehen der voneinander getrennten Betriebssystem-Module, die jeweils Code enthalten, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren, ermöglicht es, maßgeschneidert und gezielt nur ausgewählte Funktionalitäten des Betriebssystems zur Installation bereitzustellen, und anschließend zu installieren. Andere Betriebssystem-Funktionalitäten, die gerade nicht zu installieren sind, beispielsweise weil sie nicht benötigt werden oder unverändert bleiben, werden nicht bereitgestellt. Entsprechend lässt sich durch die modulare Gestaltung des Codes zur Installation des Betriebssystems, oder der Teile des Betriebssystems, das zu installierende Datenvolumen stark reduzieren. Das reduzierte Datenvolumen führt zu einer Reduktion von Zeit und Rechenressourcen, die zur Installation erforderlich sind. Dies gilt gleichermaßen, unabhängig davon, ob die Installation auf eine Erstinstallation eines Betriebssystems oder von Teilen davon gerichtet ist, oder auf eine Ände- rung, oder Aktualisierung eines bereits installierten Betriebssystems, oder von Teilen eines solchen Betriebssystems, oder auf eine Änderung eines Betriebssystems in Form einer Änderung bereits installierter Teile eines Betriebssystems, oder auf eine Änderung in Form einer Erweiterung eines installierten Betriebssystems um noch nicht vorhandene Betriebssystemteile.
Daher ist gemäß Anspruch 1 ein Verfahren geschaffen, bei dem die Installation und Änderung, speziell eine spätere Aktualisierung, des Betriebssystems schneller und mit weniger Ressourcenaufwand erreichbar ist.
Ein weiterer Vorteil der Erfindung besteht darin, dass aufgrund des geringeren zu installierenden Datenvolumens das Risiko von Datenfehlern, Datenübertragungsfehlern bei der Übertragung des Codes in die Prozessoreinrichtung und Installationsfehlern bei der Installation des Codes in der Prozessoreinrichtung reduziert werden kann.
Ein weiterer Vorteil der Erfindung besteht darin, dass auf Grund der Möglichkeit, einzelne voneinander getrennte Betriebssystem-Module und damit Betriebssystem- Funktionalitäten, isoliert voneinander zu laden und zu installieren, die Möglichkeit eröffnet ist, die einzelnen voneinander getrennten Betriebssystem-Module und damit Betriebssystem-Funktionalitäten getrennt voneinander zu evaluieren und durch zugelassene Zertifizierungseinrichtungen, beispielsweise akkreditierte Prüflabore, zertifizieren zu lassen. Wird nur ein bestimmtes Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktionalität verändert, so kann durch eine geeignete Trennung oder Isolierung der Betriebssystem-Module voneinander erreicht werden, dass nur dieses Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktionalität neu zertifiziert werden muss. Die Zertifizierung der unverändert bleibenden Betriebssystem-Module und damit Betriebssystem-Funktionalitäten bleibt unberührt. Zur Trennung oder Isolierung von unterschiedlichen ausführbaren Programmcodes sind unterschiedliche Maßnahmen bekannt, die auch auf die erfindungsgemäßen Betriebssystem-Module, als ausführbaren Programmcodes, anwendbar sein können. Beispielhafte Maßnahmen zur Trennung von Codes sind Kontexte, Sicherheitsdomänen und Sandbox-Mechanismen.
Wahlweise sind unterschiedliche Betriebssystem-Module in unterschiedlichen Sicherheitsdomänen, insbesondere Global Platform Sicherheitsdomänen, angeordnet und werden in den unterschiedlichen Sicherheitsdomänen ausgeführt.
Wahlweise ist das - oder das jeweilige - Betriebssystem-Modul weiter d) von anderen Betriebssystem-Modulen isoliert, so dass ein Zugriff zwischen dem Betriebssystem-Modul - oder dem jeweiligen Betriebssystem-Modul - und anderen Betriebssystem-Modulen verhindert ist, oder nur höchstens mittels kontrollierter Schnittstellenmechanismen möglich ist. Im Fall dass die Prozessoreinrichtung Java oder Java Card basiert ist, kann als kontrollierter Schnittstellenmechanismus beispielsweise ein Shareable Interface Object oder Entry Point Object vorgesehen sein.
Das Installieren des Betriebssystems oder der Teile des Betriebssystems erfolgt wahlweise als getrenntes Installieren der geladenen getrennten Betriebssystem- Module. Alternativ erfolgt das Installieren des Betriebssystems oder der Teile des Betriebssystems als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module. Wahlweise erfolgt das Installieren für manche Betriebssystem-Module als getrenntes Installieren der geladenen getrennten Betriebssystem-Module, und für manche Betriebssystem-Module als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module.
Unterschiedliche Szenarien zur Installation eines Betriebssystems oder von Teilen eines Betriebssystems können ein unterschiedliche Anzahlen von Betriebssystem- Modulen, und/oder unterschiedlich große Anteile am Betriebssystem umfassen, im Maxima Ifa II das gesamte Betriebssystem. Wird eine Anzahl von mehreren Betriebssystem-Modulen auf einmal zur Installation geladen, kann die Installation der mehreren Betriebssystem-Module wahlweise einzeln erfolgen, oder alternativ im Block, wobei also in Bezug auf den Vorgang der Installation die Modularität nicht mehr wirkt. Welche Vorgehensweise bei der Installation im Einzelfall vorteilhaft ist, kann von unterschiedlichen Rahmenbedingungen abhängig sein.
Wahlweise sind als voneinander getrennte Betriebssystem-Module vorgesehen:
- zumindest ein Trusted Loader, der dazu eingerichtet ist, weitere Betriebssystem- Module in die Prozessoreinrichtung zu laden, und zu veranlassen, die weiteren Betriebssystem-Module in der Prozessoreinrichtung zu installieren; und
- zusätzlich ein oder mehrere funktionelle Betriebssystem-Module.
Der Trusted Loader ist gemäß der hier beschriebenen Ausführungsform wahlweise das erste Betriebssystem-Modul, das in der Prozessoreinrichtung installiert wird, und ermöglicht nachfolgend das Laden und die Installation weiterer Betriebssystem-Module in der Prozessoreinrichtung durch den Trusted Loader.
Der Trusted Loader ist wahlweise selbst kein funktionelles Betriebssystem-Modul, sondern exklusiv dazu eingerichtet ist, weitere Betriebssystem-Module in die Prozessoreinrichtung zu laden, und zu veranlassen, die weiteren Betriebssystem-Module in der Prozessoreinrichtung zu installieren.
Wahlweise umfasst der Trusted Loader, zusätzlich zur Funktionalität weiter Betriebssystem-Module zu laden, bereits Module für Basis-Funktionalitäten des Betriebssystems, wie: - Speicherverwaltung von Speichereinheiten der Prozessoreinrichtung; - Lesen oder/und Schreiben von Daten, einschließlich Programmen, in Speichereinheiten der Prozessoreinrichtung; - Bearbeiten vom Befehlen in der Prozessoreinrichtung, einschließlich Empfangen von Befehlen, Ausführen von Befehlen, Erstellen von Befehlen und Ausgeben von Befehlen. Alternativ werden diese Basis-
Funktionalitäten durch gesonderte Betriebssystem-Module bereitgestellt.
Wahlweise sind als funktionelle Betriebssystem-Module ein oder mehrere der folgenden vorgesehen:
- ein Basis-Funktionalitäten-Modul, durch dessen Installation ein oder mehrere Basis-Funktionalitäten des Betriebssystems in der Prozessoreinrichtung installiert werden;
- ein kryptographischer-Algorithmus-Modul, durch dessen Installation eine Implementierung eines kryptographischen Algorithmus in der Prozessoreinrichtung installiert wird;
- ein Library-Module, durch dessen Installation eine Library in der Prozessoreinrichtung installiert wird;
- ein Protokoll-Modul, durch dessen Installation eine Implementierung eines Protokolls zur Kommunikation der Prozessoreinrichtung mit außerhalb der Prozessoreinrichtung angeordneter Einheiten installiert wird;
- eine aktualisierte Version eines der vorangehenden funktionellen Betriebssystem- Module, die als Ersatz oder Ergänzung für eine bereits in der Prozessoreinrichtung installierte Version desselben funktionellen Betriebssystem-Moduls in die Prozessoreinrichtung geladen und in der Prozessoreinrichtung installiert wird.
Als kryptographischer Algorithmus kann beispielsweise ein symmetrischer oder asymmetrischer Algorithmus vorgesehen sein, wie DES, AES, 3DES, RSA, oder ein anderer Algorithmus.
Als Protokoll kann wahlweise ein Übertragungsprotokoll für Chipkarten oder ähnliche chipbasierte Produkte vorgesehen sein, wie ISO/IEC 7816 T=0 oder T=l, ISO/IEC 14443, near field communication NFC, single wire protocol SWP oder Password Authenticated Connection Establishment PACE für maschinenlesbare Reisedoku- mente. Als Protokoll kann außerdem wahlweise ein Übertragungsprotokoll für Zahlungsverkehrs- oder Telekommunikations- oder Identitäten/Reisepassanwendun- gen vorgesehen sein.
Wahlweise ist oder sind als Basis-Funktionalität eine oder mehrere der folgenden vorgesehen oder:
- Speicherverwaltung von Speichereinheiten der Prozessoreinrichtung;
- Lesen oder/und Schreiben von Daten, einschließlich Programmen, in Speichereinheiten der Prozessoreinrichtung;
- Bearbeiten vom Befehlen in der Prozessoreinrichtung, einschließlich Empfangen von Befehlen, Ausführen von Befehlen, Erstellen von Befehlen und Ausgeben von Befehlen.
Wahlweise ist das Betriebssystem-Modul als Java Card Cap-File gemäß der Java Card Spezifikation gestaltet.
Wahlweise ist in dem Betriebssystem-Modul Java Card Code oder nativer Code oder sowohl Java Card Code als auch nativer Code enthalten. Insbesondere kann in einem Java Card Cap-File neben Java Code zusätzlich nativer Code enthalten sein.
Wahlweise erfolgt das Laden eines Betriebssystem-Moduls, indem ein Service, in dem das Betriebssystem-Modul integriert ist, in die Prozessoreinrichtung geladen wird. Hierbei ist unter einem Service für ein Betriebssystem-Modul für eine Betriebssystem-Funktionalität eine Instanz, insbesondere ein Programmcode, zu verstehen, der dazu eingerichtet, dass der Service, also z.B. der Programmcode, ausgeführt wird. Durch die Ausführung des in die Prozessoreinrichtung geladenen Service (z.B. Programmcode) wird die im Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert. Wahlweise ist das Betriebssystem zumindest teilweise oder ganz als Java Card basiertes Betriebssystem gestaltet. Hierbei ist der Service als ein Java Card Applet gestaltet, und das Betriebssystem-Modul als Java Card Cap-File gestaltet. Der Service wird ausgeführt, indem das Java Card Applet aufgerufen und zur Ausführung gebracht wird. Hierdurch wird die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert. Auch bei dieser Ausführungsform kann in dem Java Card Cap-File neben Java Code zusätzlich nativer Code enthalten sein.
Wahlweise ist das Java Card Applet, durch welches der Service verwirklicht ist, als modifiziertes Java Card Applet gestaltet, welches dahingehend modifiziert ist, dass das modifizierte Java Card Applet durch die Befehle process() und select(), mit denen ein standardgemäßes Java Card Applet aufrufbar ist, nicht aufrufbar ist, sondern nur über ein kontrolliertes Schnittstellenobjekt, insbesondere ein Shareable Interface Object oder Entry Point Object, verfügt und aufrufbar ist.
Wahlweise ist bei Ausführungsformen, die ein Java Card Applet einsetzen, dem Java Card Applet ein Applikations-Identifikator, AID, zugeordnet, wobei in der Prozessoreinrichtung eine Registry eingerichtet ist, in welche der Applikations-Identifikator, AID, des Java Card Applet beim Laden des Applet in die Prozessoreinrichtung eingetragen wird. Das Java Card Applet wird in diesem Fall anhand des in der Registry eingetragenen Applikations-Identifikator, AID, aufgerufen und zur Ausführung gebracht. Wahlweise erfolgt der Aufruf des Java Card Applet weiter unter Verwendung eines auf den Service weisenden Unified Ressource Identifier Strings, URI- Strings. Wird der URI-String aufgerufen, so wird die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert.
Wahlweise werden unterschiedliche Services für unterschiedliche Betriebssystem-
Module in unterschiedlichen Kontexten ausgeführt, die voneinander isoliert sind. Die Kontexte sind wahlweise insbesondere mittels Einwirkens einer Mikroprozesso- reinrichtung MPU oder/und einer Speicherverwaltung MPU isoliert. Wahlweise ist eine Wechselwirkung oder Kommunikation zwischen unterschiedlichen Services nur über einen kontrollierten Schnittstellenmechanismus möglich, insbesondere ein Shareable Interface Object oder/und ein Entry Point Object.
Die Isolation der Kontexte ist vor allem in Zusammenhang der Zertifizierung der Prozessoreinrichtung vorteilhaft. Die Isolation der Kontexte kann insbesondere dazu beitragen, den Aufwand der Neu-Zertifizierung bei Änderungen am Betriebssystem zu verringern.
Wahlweise ist die Isolation der Kontexte derart gestaltet, dass sie entsprechend anzuwendender Zertifizierungsvorschriften für die Prozessoreinrichtung ausreichend ist, dass bei Änderungen an einem Betriebssystem-Modul in einem ersten Kontext, die bestehenden Zertifizierungen anderer Betriebssystem-Module in anderen Kontexten, die vom ersten Kontext isoliert sind, durch die Änderung unberührt bleiben. Hierdurch wird erreicht, dass nur das geänderte Betriebssystem-Modul und die damit verbundene Betriebssystem-Funktional neu zertifiziert werden muss.
Wahlweise ist jedes Betriebssystem-Modul getrennt zertifiziert. Hierdurch kann in einem vollständig zertifizierten Betriebssystem, in welchem nur ein einzelnes Betriebssystem-Modul, oder eine Gruppe von einzelnen Betriebssystem-Modulen, und die damit verbundene(n) Betriebssystem-Funktionalität(en) verändert wird (werden), die bestehende Zertifizierung für die unverändert gebliebenen Bestandteile des Betriebssystems erhalten bleiben, und nur die geänderten Betriebssystemteile (Modul(e), Funktionalität(en)) müssen neu zertifiziert werden.
In der Zertifizierung sind unterschiedliche hierarchisch gestufte Level von Zertifizierung vorgesehen. Je höher das Level der Zertifizierung, umso strenger sind die Prüf- vorgaben. Hat eine Prozessoreinrichtung ein gewisses Level der Zertifizierung bestanden, so gilt sie gemäß diesem Level und aller darunter liegenden niedrigeren Levels als zertifiziert. Höhere Levels gelten als nicht erreicht, und die Prozessoreinrichtung als für die höheren Levels nicht zertifiziert.
Je höher das Level der Zertifizierung, umso höher ist in der Regel das Spektrum an Einsatzmöglichkeiten einer zertifizierten Prozessoreinrichtung. Daher ist ein möglichst hohes Level von Zertifizierung erstrebenswert. Ein hohes Level von Zertifizierung bedeutet andererseits einen hohen Aufwand an Maßnahmen, insbesondere Sicherheitsmaßnahmen, die in der Prozessoreinrichtung vorgesehen werden müssen, um die Zertifizierungstest zu bestehen. Als Maßnahmen können beispielsweise Programmroutinen zur Abwehr von Seitenkanalangriffen, Hackerangriffen und Ähnliches vorgesehen sein, wie Maskierung, Verschlüsselung, Verschleierung, Redundanzen und weitere. Um die Prozessoreinrichtung entsprechend auszustatten sind zeit- und kostenaufwändige Entwicklungsarbeiten erforderlich. Zudem steigt mit den Maßnahmen die Komplexität des Produkts, was bei unsorgfältiger Implementierung wieder Fehlerrisiken nach sich ziehen kann. Zudem sind die Tests für höhere Zertifizierungslevels zeitaufwändiger und kostspieliger als Tests für niedrigere Zerti- fizierungslevels. Entsprechend wird nicht stets das höchste Level von Zertifizierung angestrebt, sondern typischerweise nur ein für den konkreten Anwendungszweck ausreichendes Zertifizierungslevel.
Durch den Trusted Loader werden andere Betriebssystem-Module in die Prozessoreinrichtung geladen. Somit nimmt der Trusted Loader Einfluss auf jedes durch ihn geladene Betriebssystem-Modul. Entsprechend kann ein durch den Trusted Loader geladenes Betriebssystem-Modul maximal das Level an Zertifizierung haben, welches der Trusted Loader erlangt (bestanden) hat, selbst wenn das Betriebssystem- Modul außerhalb der Prozessoreinrichtung eine Zertifizierung auf einem höheren Level erlangt (bestanden) hat. Wahlweise hat im Fall, dass ein Trusted Loader vorgesehen ist, der Trusted Loader relativ zu anderen Betriebssystem-Modulen das höchste oder zumindest kein schlechteres Level von Zertifizierung. Hierdurch wird das Level der anderen Betriebssystem-Module, die durch den Trusted Loader nachgeladen werden können, stets erhalten und niemals verschlechtert.
Auf analoge Weise wie die Betriebssystem-Module können in die Prozessoreinrichtung zusätzlich Applikations-Module zur Installation von Applikationen geladen werden. Wahlweise können in manchen Betriebssystem-Modulen Applikations-Module enthalten sein, und mit einem solchen Betriebssystem-Modul auch darin enthaltene Applikations-Module in die Prozessoreinrichtung geladen und dort installiert werden.
Wahlweise ist als Prozessoreinrichtung ein Sicherheitsmodul vorgesehen, also eine sichere Prozessoreinrichtungen mit beschränkten Rechenressourcen, insbesondere eine Chipkarte oder ein entsprechendes Prozessormodul ohne ein kartenförmigen Körper.
Wahlweise umfasst die Prozessoreinrichtung:
- mindestens eine Prozessoreinheit zur Verarbeitung von Daten einschließlich Programmen,
- mindestens eine Speichereinheit, umfassend ein oder mehrere Speicher, zum Speichern von Daten einschließlich Programmen,
- mindestens eine Schnittstelleneinheit zum Austausch von Daten einschließlich Programmen mit außerhalb der Prozessoreinrichtung angeordneten Einheiten.
Kurze der
Im Folgenden wird die Erfindung an Hand von Ausführungsbeispielen und unter Bezugnahme auf die Zeichnung näher erläutert, in der zeigen: Fig. 1 eine schematische Darstellung einer modulweisen Installation und modularen Erweiterung eines Betriebssystems durch sequentielle Installation mehrerer Betriebssystem-Module, gemäß Ausführungsformen der Erfindung;
Fig. 2 eine schematische Darstellung einer Anordnung von mehreren Java-basier- ten, in voneinander isolierten Kontexten auszuführenden Betriebssystem- Modulen, gemäß Ausführungsformen der Erfindung;
Fig. 3 ein als Service gestaltetes Betriebssystem-Modul, gemäß Ausführungsformen der Erfindung.
Detaillierte Beschreibung von Ausführungsbeispielen
Fig. 1 zeigt eine schematische Darstellung einer modulweisen Installation und modularen Erweiterung eines Betriebssystems durch sequentielle Installation mehrerer Betriebssystem-Module in einer Prozessoreinrichtung, gemäß Ausführungsformen der Erfindung.
Teil-Figur 1-1 von Fig. 1 zeigt die Prozessoreinrichtung in einem ersten Zustand der Installation 1-1, in welchem nur ein Trusted Loader TL in der Prozessoreinrichtung installiert ist. Der Trusted Loader TL umfasst in diesem Fall bereits erste Basis-Funktionalitäten BOS des Betriebssystems. Alternativ könnten die Basis-Funktionalitäten BOS des Betriebssystems auch erst durch den Trusted Loader TL in die Prozessoreinrichtung geladen werden.
Teil-Figur 1-2 von Fig. 1 zeigt die Prozessoreinrichtung in einem zweiten Zustand der Installation 1-2, in welchem in der Prozessoreinrichtung, zusätzlich zum Trusted Loader TL mit den die Basis-Funktionalitäten BOS des Betriebssystems gemäß Teilfigur 1-1, aus zwei (oder mehr) Betriebssystem-Modulen 0SM1, (...) OSMn diverse Betriebssystem-Funktionalitäten und aus einem Library-Modul LIBM1 (Bi bliothe- ken-Modul) eine Library installiert sind. Hierzu sind die zwei Betriebssystem-Module 0SM1, OSMn und das Library-Modul LIBM1 in die Prozessoreinrichtung gela- den worden, die Module OSM1, OSMn, LIB2 in der Prozessoreinrichtung zur Ausführung gebracht worden, und dadurch die diverse Betriebssystem-Funktionalitäten und die Library in der Prozessoreinrichtung installiert worden.
Teil-Figur 1-3 von Fig. 1 zeigt die Prozessoreinrichtung in einem dritten Zustand der Installation 1-3, in welchem in der Prozessoreinrichtung, zusätzlich zu den in Teilfigur 1-2 gezeigten Modulen und Funktionalitäten, eine weitere Library aus einem weiteren Library-Modul LIB2 und zwei Applikationen aus zwei Applikations-Modulen APM1, APM2 installiert worden sind. Zusätzlich sind Betriebssystem-Funktionalitäten, die aus dem ersten Betriebssystem-Modul OS1 installiert worden waren, deinstalliert oder/und gelöscht worden.
Fig. 2 zeigt eine schematische Darstellung einer Prozessoreinrichtung, in der eine Anordnung von mehreren Java-basierten (genauer Java Card spezifischen), in voneinander isolierten Kontexten auszuführenden Betriebssystem-Modulen enthalten ist, gemäß Ausführungsformen der Erfindung. In der Prozessoreinrichtung ist ein Trusted Loader TL enthalten. Der Trusted Loader enthält Basisfunktionalitäten des Betriebssystems Base OS bereits selbst, oder er hat die Basisfunktionalitäten durch Laden von ein oder mehreren Basis-Funktionalitäten-Modulen geladen und in der Prozessoreinrichtung installiert. Die Prozessoreinrichtung enthält drei Services BOS Service, Service 1 und Service 2. Jeder der drei Services enthält ausführbaren Programmcode, durch dessen Ausführung der Nutzdateninhalt des Service in der Prozessoreinrichtung installiert wird. Jeder der drei Services ist von den anderen beiden Services durch eine Kontextgrenze L isoliert, so dass jeder Service, wenn er ausgeführt wird, in seinem eigenen isolierten Kontext ausgeführt wird.
Jeder Service enthält als Nutzdateninhalt ein Cap-File gemäß der Java Card Spezifikation, in welchem der zu installierende Code enthalten ist. Das Cap-File enthält in der in Fig. 2 gezeigten Ausführungsform sowohl Java Code als auch nativen Code. Ein erster der drei Services BOS Service ist ein Betriebssystem-Modul zur Installation von weiteren Basis-Funktionalitäten des Betriebssystems.
Ein zweiter der drei Services Service 1 ist ein Betriebssystem-Modul zur Installation eines kryptographischen Algorithmus in der Prozessoreinrichtung.
Ein dritter der drei Services Service 2 ist ein Betriebssystem-Modul zur Installation eines integrierten Teilnehmeridentitätsmoduls iUICC in der Prozessoreinrichtung.
Weitere ähnliche Services können in die Prozessoreinrichtung geladen und darin zur Ausführung gebracht werden, beispielsweise um eine Zahlungsverkehrsapplikation oder eine Wallet-Applikation in der Prozessoreinrichtung zu installieren.
Fig. 3 zeigt ein als Service gestaltetes Betriebssystem-Modul umfassend ein Java Card Cap File in Detailansicht, gemäß Ausführungsformen der Erfindung. Der Service enthält ein Java Card Cap-File, das Java Code gemäß der Java Card Spezifikation enthält. Der Java Code ist in ein oder mehreren Files (Dateien), den Java Source Files (Dateien), mit der Java-(Card-)spezifischen Namensendung *.java enthalten. Das in Fig. 3 gezeigte beispielhafte Cap File enthält weiter eine Static Ressource Komponente, mittels welcher nativer Code und Ressourcen zum Java Card Cap-File hinzugefügt werden kann. Der native Code kann in ein oder mehreren Files (Dateien), vorgesehen sein. Nativer Code kann beispielsweise im *.bin oder *.hex Format vorliegen. Native Ressourcen können beispielsweise im *.txt oder *.html Format vorliegen. Das Cap-File bzw. der Java Code ist in Java-Card-typischer Weise strukturiert und enthält beispielsweise Datenelemente wie Header, Directory, ein oder mehrere Applets, Import-Informationen, einen Constant-Pool (Konstanten-Pool), Classes (Klassen), und dergleichen. Nativer Code und Ressourcen können mittels des Static Ressource Elements als statische Ressourcen zum Cap-File hinzugefügt werden.

Claims

P a t e n t a n s p r ü c h e
1. Verfahren zum Installieren, in einer Prozessoreinrichtung, eines Betriebssystems, das eine Mehrzahl von zwei oder mehr Betriebssystem-Funktionalitäten umfasst, oder von Teilen eines solchen Betriebssystems, wobei das Verfahren die Schritte umfasst:
- Laden des Betriebssystems, oder der Teile des Betriebssystems, in die Prozessoreinrichtung;
- Installieren des geladenen Betriebssystems, oder der geladenen Teile des Betriebssystems, in der Prozessoreinrichtung; dadurch gekennzeichnet, dass a) das Laden des Betriebssystems, oder der Teile des Betriebssystems, als Laden zumindest eines oder mehrerer voneinander getrennter Betriebssystem-Module erfolgt, wobei das oder das jeweilige Betriebssystem-Modul b) Code enthält, der dazu eingerichtet ist, eine dem Betriebssystem-Modul entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren, und c) ein getrenntes Installieren nur der dem jeweiligen Betriebssystem-Modul entsprechenden Betriebssystem-Funktionalität ermöglicht, insbesondere ohne dass weitere Betriebssystem-Funktionalitäten installiert werden.
2. Verfahren nach Anspruch 1, wobei das oder das jeweilige Betriebssystem-Modul weiter d) von anderen Betriebssystem-Modulen isoliert ist, so dass ein Zugriff zwischen dem oder dem jeweiligen Betriebssystem-Modul und anderen Betriebssystem-Modulen verhindert ist, oder nur höchstens mittels kontrollierter Schnittstellenmechanismen möglich ist.
3. Verfahren nach Anspruch 1 oder 2, wobei das Installieren des Betriebssystems oder der Teile des Betriebssystems erfolgt:
- als getrenntes Installieren der geladenen getrennten Betriebssystem-Module; oder
- als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module; oder
- für manche Betriebssystem-Module als getrenntes Installieren der geladenen getrennten Betriebssystem-Module, und für manche Betriebssystem-Module als gemeinsames Installieren der geladenen getrennten Betriebssystem-Module.
4. Verfahren nach einem der Ansprüche 1 bis 3, wobei als voneinander getrennte Betriebssystem-Module vorgesehen sind:
- zumindest ein Trusted Loader (TL), der dazu eingerichtet ist, weitere Betriebssystem-Module in die Prozessoreinrichtung zu laden, und zu veranlassen, die weiteren Betriebssystem-Module in der Prozessoreinrichtung zu installieren; und
- zusätzlich ein oder mehrere funktionelle Betriebssystem-Module (BOS, OSM1, ... OSMn, LIBM21, LIBM2).
5. Verfahren nach Anspruch 4, wobei als funktionelle Betriebssystem-Module ein oder mehrere der folgenden vorgesehen sind:
- ein Basis-Funktionalitäten-Modul (BOS), durch dessen Installation ein oder mehrere Basis-Funktionalitäten des Betriebssystems in der Prozessoreinrichtung installiert werden;
- ein kryptographischer-Algorithmus-Modul, durch dessen Installation eine Implementierung eines kryptographischen Algorithmus in der Prozessoreinrichtung installiert wird;
- ein Library-Module (LIBM1, LIBM2), durch dessen Installation eine Library in der Prozessoreinrichtung installiert wird;
- ein Protokoll-Modul, durch dessen Installation eine Implementierung eines Protokolls zur Kommunikation der Prozessoreinrichtung mit außerhalb der Prozessoreinrichtung angeordneter Einheiten installiert wird;
- eine aktualisierte Version eines der vorangehenden funktionellen Betriebssystem- Module, die als Ersatz oder Ergänzung für eine bereits in der Prozessoreinrichtung installierte Version desselben funktionellen Betriebssystem-Moduls in die Prozessoreinrichtung geladen und in der Prozessoreinrichtung installiert wird.
6. Verfahren nach Anspruch 5, wobei als Basis-Funktionalität eine oder mehrere der folgenden vorgesehen ist oder sind:
- Speicherverwaltung von Speichereinheiten der Prozessoreinrichtung;
- Lesen oder/und Schreiben von Daten, einschließlich Programmen, in Speichereinheiten der Prozessoreinrichtung;
- Bearbeiten vom Befehlen in der Prozessoreinrichtung, einschließlich Empfangen von Befehlen, Ausführen von Befehlen, Erstellen von Befehlen und Ausgeben von Befehlen.
7. Verfahren nach einem der Ansprüche 1 bis 6, wobei das Betriebssystem-Modul als Java Card Cap-File gemäß der Java Card Spezifikation gestaltet ist.
8. Verfahren nach einem der Ansprüche 1 bis 7, wobei in dem Betriebssystem-Modul Java Card Code oder nativer Code oder sowohl Java Card Code als auch nativer Code enthalten ist.
9. Verfahren nach einem der Ansprüche 1 bis 8, wobei:
- das Laden eines Betriebssystem-Moduls erfolgt: als Laden eines Service, in dem das Betriebssystem-Modul integriert ist, in die Prozessoreinrichtung, wobei ein Service für ein Betriebssystem-Modul für eine Betriebssystem-Funktionalität dazu eingerichtet ist, ausgeführt zu werden und dadurch die Betriebssystem-Funktionalität in der Prozessoreinrichtung zu installieren; und
- das Installieren eines Betriebssystem-Moduls mittels Ausführen des geladenen Service in der Prozessoreinrichtung erfolgt.
10. Verfahren nach Anspruch 9, wobei das Betriebssystem zumindest teilweise oder ganz als Java Card basiertes Betriebssystem gestaltet ist, und wobei der Service als ein Java Card Applet gestaltet ist und das Betriebssystem-Module als Java Card Cap- File gestaltet ist, wobei der Service ausgeführt wird, indem das Java Card Applet aufgerufen und zur Ausführung gebracht wird, wodurch die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert wird.
11. Verfahren nach Anspruch 10, wobei das Java Card Applet, durch welches der Service verwirklicht ist, als modifiziertes Java Card Applet gestaltet ist, welches dahingehend modifiziert ist, dass das modifizierte Java Card Applet durch die Befehle process() und select(), mit denen ein Java Card Applet aufrufbar ist, nicht aufrufbar ist, sondern nur über ein kontrolliertes Schnittstellenobjekt, insbesondere ein Shareable Interface Object oder Entry Point Object, verfügt und aufrufbar ist.
12. Verfahren nach Anspruch 10 oder 11, wobei dem Java Card Applet ein Applikations-Identifikator, AID, zugeordnet ist, und wobei in der Prozessoreinrichtung eine Registry eingerichtet ist, in welche der Applikations-Identifikator, AID, des Java Card Applet beim Laden des Applet in die Prozessoreinrichtung eingetragen wird, und wobei das Java Card Applet anhand des in der Registry eingetragenen Applikations- Identifikator, AID, - und wahlweise weiter unter Verwendung eines auf den Service weisenden URI-Strings -, aufgerufen und zur Ausführung gebracht wird, wodurch die dem Java Card Cap-File entsprechende Betriebssystem-Funktionalität in der Prozessoreinrichtung installiert wird.
13. Verfahren nach einem der Ansprüche 9 bis 12, wobei unterschiedliche Services für unterschiedliche Betriebssystem-Module in unterschiedlichen Kontexten ausgeführt werden, die voneinander isoliert sind, insbesondere mittels Einwirkens einer Mikroprozessoreinrichtung MPU oder/und einer Speicherverwaltung MPU isoliert sind, wobei eine Wechselwirkung oder Kommunikation zwischen unterschiedlichen Services nur über einen kontrollierten Schnittstellenmechanismus, insbesondere ein Shareable Interface Object oder/und ein Entry Point Object, möglich ist.
14. Verfahren nach einem der Ansprüche 1 bis 13, wobei jedes Betriebssystem-Modul getrennt zertifiziert ist, wobei wahlweise im Fall von Anspruch 4 der Trusted Loader relativ zu anderen Betriebssystem-Modulen das höchste oder zumindest kein niedrigeres Level von Zertifizierung hat.
15. Verfahren nach einem der Ansprüche 1 bis 14, wobei als Prozessoreinrichtung ein Sicherheitsmodul vorgesehen ist.
EP24708670.5A 2023-01-30 2024-01-29 Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul Pending EP4659100A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023102191.5A DE102023102191A1 (de) 2023-01-30 2023-01-30 Installieren eines Betriebssystems in einer Prozessoreinrichtung, insbesondere einem Sicherheitsmodul
PCT/DE2024/100073 WO2024160320A1 (de) 2023-01-30 2024-01-29 Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul

Publications (1)

Publication Number Publication Date
EP4659100A1 true EP4659100A1 (de) 2025-12-10

Family

ID=90123324

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24708670.5A Pending EP4659100A1 (de) 2023-01-30 2024-01-29 Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul

Country Status (4)

Country Link
EP (1) EP4659100A1 (de)
CN (1) CN120548522A (de)
DE (1) DE102023102191A1 (de)
WO (1) WO2024160320A1 (de)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6292941B1 (en) 1996-04-30 2001-09-18 Sun Microsystems, Inc. Operating system installation
US8522234B2 (en) 2007-02-05 2013-08-27 Microsoft Corporation Tailoring an operating system to a computer system
DE102013013179A1 (de) * 2013-08-07 2015-02-12 Giesecke & Devrient Gmbh Verfahren zum Betreiben eines Sicherheitselements
DE102015214422A1 (de) * 2015-07-29 2017-02-02 Bundesdruckerei Gmbh Chipkarte mit Hauptapplikation und Persistenzapplikation
EP3416086A1 (de) * 2017-06-15 2018-12-19 Gemalto Sa Verfahren zur verwaltung einer instanz einer klasse

Also Published As

Publication number Publication date
WO2024160320A1 (de) 2024-08-08
CN120548522A (zh) 2025-08-26
DE102023102191A1 (de) 2024-08-01

Similar Documents

Publication Publication Date Title
EP2692157B1 (de) Verfahren und vorrichtung zur aktualisierung einer datenträgerapplikation
DE60011615T2 (de) Techniken zum erlauben von zugang durch eine kontextsperre in einem kleinen gerät unter verwendung von globalen datenstrukturen
EP2691855B1 (de) Verfahren zum aktualisieren eines datenträgers
EP2111578A1 (de) Installieren eines patch in einem smartcard-modul
WO2010009789A1 (de) Laden und aktualisieren einer personalisierungsbedürftigen applikation
DE102014220616A1 (de) Verfahren zum Laden von ausführbaren Programminstruktionen in eine Chipkarte im Wirkbetrieb
DE102012015573A1 (de) Verfahren zum Aktivieren eines Betriebssystems in einem Sicherheitsmodul
EP2673731B1 (de) Verfahren zur programmierung eines mobilendgeräte-chips
EP2885907B1 (de) Verfahren zur installation von sicherheitsrelevanten anwendungen in einem sicherheitselement eines endgerät
WO2024160320A1 (de) Installieren eines betriebssystems in einer prozessoreinrichtung, insbesondere einem sicherheitsmodul
EP3224756B1 (de) Verfahren zum nachladen von software auf eine chipkarte durch einen nachladeautomaten
EP2191407A2 (de) Verfahren zum prüfen einer auf einer ersten einrichtung auszuführenden oder zu installierenden version eines softwareproduktes
EP3329415B1 (de) Chipkarte mit hauptapplikation und persistenzapplikation erlaubt hauptapplikationupdate ohne die benutzerdaten im persistenzapplikation zu ändern
EP2524333A1 (de) Verfahren zum bereitstellen eines sicheren zählers auf einem endgerät
DE102018009365A1 (de) Sicheres Element als aktualisierbares Trusted Platform Module
DE10328238B4 (de) Verfahren zum Laden von Chipkarten mit Initialisierungs- und/oder Personalisierungsdaten
WO2013178426A1 (de) Elektronisches zugangsschutzsystem, verfahren zum betrieb eines computersystems, chipkarte und firmwarekomponente
DE102004058882A1 (de) Erzeugen von Programmcode in einem Ladeformat und Bereitstellen von ausführbarem Programmcode
DE10323033A1 (de) Laden eines ausführbaren Programms in einen tragbaren Datenträger
WO2023051950A1 (de) Universal integrated chip card, uicc, zum verwalten von profilen, sowie verfahren
DE102008020343A1 (de) Portabler Datenträger
EP1714203A1 (de) System mit wenigstens einem computer und wenigstens einem tragbaren datenträger
DE102009019981A1 (de) Verfahren zum Schutz von auf einem tragbaren Datenträger gespeicherter Software und tragbarer Datenträger
DE102006051336A1 (de) Kompatibilitätsprüfung in einem portablen Datenträger

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

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

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250711

AK Designated contracting states

Kind code of ref document: A1

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)