Installing an operating system in a processor device, in particular a safety module

Abstract

The invention relates to a method for installing an operating system in a processor device, which operating system comprises a plurality of two or more sets of operating-system functionalities, or for installing parts of such an operating system, the method comprising the following steps: - loading the operating system, or the parts of the operating system, in the processor device; and - installing the loaded operating system, or the loaded parts of the operating system, in the processor device; characterised in that a) the operating system, or the parts of the operating system, is / are loaded in the form of at least one or more mutually separate operating-system modules, wherein the operating-system module or the operating-system module in question b) contains a code which is configured to install a set of operating-system functionalities in the processor device, which set corresponds to the operating-system module, and c) allows for the separate installation of only that set of operating-system functionalities that corresponds to the operating-system module in question, in particular without further sets of operating-system functions being installed.

Description

[0001] Installing an operating system in a processor device, in particular a security module

[0002] Field of the invention

[0003] 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.

[0004] State of the art

[0005] Security modules, namely secure processor devices with limited computing resources, in the form of chip card products have been known for a long time. Such chip card products include SIM cards or UICCs (UICC = Universal Integrated Circuit Card) in the telecommunications sector, payment transaction chip cards in the payment transaction sector, health card chip cards and health professional card chip cards in the healthcare sector, and electronic identity cards with chips and electronic passports with chips in the identity sector. Other security modules include inlays for electronic passports and chip cards with a chip and interface (contact and / or contactless), as well as other precursors for chip cards. Operating a chip card product requires a chip card product reader with which the chip card product can be removably coupled, either with contact or contactless.

[0006] Security modules (secure processor devices with limited computing resources) are increasingly gaining ground. These modules are functionally equivalent to the chip card products listed above and others without having a chip card product body. They are embedded or soldered into a chip of a mobile device, or implemented as secure software within a mobile device. Such security modules are permanently coupled to the mobile device and cannot be removed, or cannot be easily removed. Examples of security modules that are functionally equivalent to chip card products without being chip cards are embedded UICCs (eUlCCs) in the telecommunications sector, integrated UICCs (iUICCs) integrated into a chip of a mobile device, and software-emulated SIM cards, known as eSIMs.In the payment sector, there are payment transaction solutions that are security modules without a chip card body, for example, in a secure element within a mobile device or in an eUICC or iUICC. In the identity sector, there are security modules that do not require a chip card body or a comparable physical body, for example, virtual electronic ID cards and virtual electronic passports that are provided in a secure element within a mobile device.

[0007] Every operational security module (secure processor device with limited computing resources) has an operating system that provides basic functionality of the security module. Basic functionality includes operational functionality such as memory management, including writing data to and reading data from the security module's memory. Basic functionality also includes functionality for data exchange with external units, for example, with a mobile radio-capable device in which the security module is operated, or with a local or remote server. Data exchange functionality includes, 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.

[0008] Operating systems for security modules are known in both Java Card code and native code. Traditionally, to equip a security module with an operating system, the operating system is loaded into the security module as a whole and installed there. To do this, the complete operating system is provided outside the security module in a suitable format so that the operating system can be loaded into the security module as a whole and installed there, for example, in the form of an installation package for the complete operating system.

[0009] Part of creating security modules for the operating system is incorporating cryptographic algorithms into the operating system. This involves creating an operating system framework and one or more cryptographic algorithms separately as source code, and then incorporating the source code of the one or more cryptographic algorithms into the source code of the operating system framework. Similarly, libraries can be created separately from the operating system framework and then incorporated into the operating system framework.

[0010] If changes, such as updates and / or bug fixes, are subsequently made to the operating system, a completely modified version of the operating system is created outside the security module, in which the changes, such as updates and / or code patches to implement bug fixes, are implemented, and the modified operating system is loaded into the security module as a whole and installed there, in a similar way to how the original operating system was loaded and installed.

[0011] When changes are made to the operating system for the security module, only small parts of the operating system may be affected, while other parts remain unchanged from the version of the operating system already present in the security module. Nevertheless, the entire operating system must be reloaded and installed. This can result in a very large amount of data to be loaded and installed compared to the changes implemented. This makes implementing the changes to the operating system inefficient and slow.

[0012] Changes to the operating system can include updates, bug fixes, or adaptations to changed use cases. A changed use case can also be due, for example, to an operating system created for a first customer being used by a second customer who, while essentially using the same use case as the first customer, requires different detailed solutions for certain aspects of the operating system. This allows the operating system created for the first customer to be reused, albeit with minor changes or adaptations.

[0013] Operating systems commonly require certification for security modules. To obtain certification, the operating system must undergo systematic testing by an accredited certification body and pass the tests. Changes to the operating system typically require recertification of the entire operating system. 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.

[0014] A specific scenario for a change to the operating system is the replacement of an implementation of a cryptographic algorithm integrated into the operating system, for example, with an updated or bug-fixed implementation of the same algorithm, or with a different, e.g., more recent, algorithm. For example, an implementation of the Advanced Encryption Standard AES, in which weaknesses have been discovered, could be replaced with a modified implementation of AES. According to another example, the Data Encryption Standard DES could be replaced with the newer AES. Traditionally, 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, i.e.the source code of the entire modified operating system, including the source code of the new or modified cryptographic algorithm and the source code of the operating system framework, re-certified and loaded into the security module and installed in the security module.

[0015] 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 would allow the installation and modification, especially a subsequent update, of the operating system to be achieved more quickly and with fewer resources.

[0016] 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 the desired performance characteristics of the operating system and the predetermined operating capacity and available memory capacity of the computer system, parts of the modular operating system are selectively installed to best achieve the desired performance characteristics while maintaining the operating capacity and available memory capacity. To achieve this, only the required modules, or those permissible in view of the operating capacity to be maintained and the memory capacity to be left free, are assembled by an operating system tailor, and the resulting operating system is installed.

[0017] Prior art document US6292941B1 discloses a method for installing and customizing an operating system on a local computer, wherein a customized operating system is set up 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.

[0018] 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 subsequent update, of the operating system to be achieved more quickly and with less resource expenditure.

[0019] The object is achieved by a method according to claim 1. Advantageous embodiments of the invention are specified in the dependent claims.

[0020] The core idea of ​​the invention is to use a modular installation solution to reduce the installation to be carried out in a targeted manner to the 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.

[0021] The inventive method according to claim 1 is specifically intended 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 the parts of the operating system, into the processor device; - installing the loaded operating system, or the loaded parts of the operating system, in the processor device.The method is characterized in that a) the loading of the operating system, or the parts of the operating system, takes place as loading of at least one or more separate operating system modules, wherein the respective operating system module: b) contains code which is configured 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.

[0022] The provision of separate operating system modules, each containing code configured 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 operating system functionalities for installation and then install them. Other operating system functionalities that are not currently being 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 significantly 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 a first installation of an operating system or parts thereof, or at a change or update of an already installed operating system or parts of such an operating system, or at a change of an operating system in the form of a change to parts of an operating system that are already installed, or at a change in the form of an extension of an installed operating system with parts of the operating system that are not yet present.

[0023] Therefore, according to claim 1, a method is provided in which the installation and modification, especially a later update, of the operating system can be achieved more quickly and with less resource expenditure.

[0024] 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.

[0025] A further advantage of the invention is that, due to the possibility of loading and installing individual, separate operating system modules and thus operating system functionalities in isolation from one another, it is possible to evaluate the individual, separate operating system modules and thus operating system functionalities separately 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 is changed, then by appropriately separating or isolating the operating system modules from one another, it can be achieved that only this operating system module and the associated operating system functionality needs to be recertified. The certification of the unchanged operating system modules and thus operating system functionalities 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 include contexts, security domains, and sandbox mechanisms.

[0026] Optionally, different operating system modules are arranged in different security domains, in particular Global Platform security domains, and are executed in the different security domains.

[0027] Optionally, the operating system module (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 via controlled interface mechanisms. If the processor device is Java or Java Card-based, a Shareable Interface Object or Entry Point Object, for example, can be provided as the controlled interface mechanism.

[0028] The operating system or parts of the operating system can be installed either separately by installing the loaded separate operating system modules. Alternatively, the operating system or parts of the operating system can be installed together by installing the loaded separate operating system modules. For some operating system modules, the installation can be performed separately by installing the loaded separate operating system modules, and for some operating system modules, the installation can be performed together by installing the loaded separate operating system modules.

[0029] Different scenarios for installing an operating system or parts of an operating system can involve different numbers of operating system modules and / or different portions of the operating system—in the Maxima IFA II, the entire operating system. If several operating system modules are loaded for installation at once, they can be installed individually or in blocks, meaning the modularity no longer affects the installation process. Which installation approach is advantageous in each individual case can depend on various circumstances.

[0030] Optionally, separate operating system modules are available:

[0031] - at least one trusted loader 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; and

[0032] - additionally one or more functional operating system modules.

[0033] According to the embodiment described here, 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.

[0034] The Trusted Loader is optionally not a functional operating system module itself, but is exclusively configured 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.

[0035] Optionally, in addition to the functionality to load further operating system modules, 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 instructions in the processor device, including receiving instructions, executing instructions, creating instructions, and issuing instructions. Alternatively, these basic

[0036] Functionalities provided by separate operating system modules.

[0037] Optionally, one or more of the following are provided as functional operating system modules:

[0038] - a basic functionality module, the installation of which installs one or more basic functionalities of the operating system in the processor device;

[0039] - a cryptographic algorithm module, the installation of which installs an implementation of a cryptographic algorithm in the processor device;

[0040] - a library module, the installation of which installs a library in the processor device;

[0041] - a protocol module, the installation of which installs an implementation of a protocol for communication between the processor device and units located outside the processor device;

[0042] - an updated version of one of the preceding functional operating system modules, which is loaded into and installed in the processor device as a replacement or supplement for a version of the same functional operating system module already installed in the processor device.

[0043] The cryptographic algorithm can be, for example, a symmetric or asymmetric algorithm, such as DES, AES, 3DES, RSA, or another algorithm.

[0044] The protocol can optionally be a transmission protocol for chip cards or similar chip-based products, such as ISO / IEC 7816 T=0 or T=1, ISO / IEC 14443, near field communication (NFC), single wire protocol (SWP), or Password Authenticated Connection Establishment (PACE) for machine-readable travel documents. The protocol can also optionally be a transmission protocol for payment transactions, telecommunications, or identity / passport applications.

[0045] Optionally, one or more of the following is or are provided as basic functionality:

[0046] - Memory management of memory units of the processor device;

[0047] - Reading and / or writing data, including programs, in memory units of the processor device;

[0048] - Processing of instructions in the processor device, including receiving instructions, executing instructions, creating instructions and issuing instructions.

[0049] Optionally, the operating system module is designed as a Java Card cap file according to the Java Card specification.

[0050] The operating system module can contain either Java Card code or native code, or both Java Card code and native code. In particular, a Java Card CAP file can contain both Java code and native code.

[0051] An operating system module can optionally be loaded by loading a service into the processor device into which the operating system module is integrated. A service for an operating system module is understood to be an instance, in particular program code, which is set up to execute the service, e.g. the program code. Execution of the service (e.g. program code) loaded into the processor device installs the operating system functionality in the processor device. The operating system can optionally be 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 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 into the processor device. Even in this embodiment, the Java Card CAP file can contain native code in addition to Java code.

[0052] Optionally, 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.

[0053] Optionally, in embodiments that use a Java Card applet, an application identifier (AID) is assigned to the Java Card applet. 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. In this case, the Java Card applet is called and executed using the application identifier (AID) entered in the registry. Optionally, the Java Card applet is also called using a unified resource identifier string (URI) 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.

[0054] Optionally, different services are available for different operating systems.

[0055] Modules are executed in different contexts that are isolated from one another. The contexts are optionally isolated, in particular by means of a microprocessor unit (MPU) and / or a memory management unit (MPU). Interaction or communication between different services is optionally only possible via a controlled interface mechanism, in particular a Shareable Interface Object and / or an Entry Point Object.

[0056] Context isolation is particularly advantageous in the context of processor device certification. Context isolation can, in particular, help reduce the effort required for re-certification when changes are made to the operating system.

[0057] Optionally, the isolation of the contexts is designed in such a way that, according to applicable certification regulations for the processor device, it is sufficient 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 recertified.

[0058] Optionally, each operating system module is certified separately. This allows for 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 modified, to retain the existing certification for the unchanged components of the operating system, and only the modified operating system components (module(s), functionality(s)) need to be recertified.

[0059] Certification provides for different hierarchical levels of certification. The higher the certification level, the more stringent the testing requirements. 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 uncertified for the higher levels.

[0060] The higher the certification level, the wider the range of possible applications of a certified processor device. Therefore, the highest possible level of certification is desirable. On the other hand, a high level of certification requires a high level of measures, particularly security measures, that must be implemented in the processor device to pass the certification test. These measures can include, for example, program routines to defend against side-channel attacks, hacker attacks, and the like, such as masking, encryption, obfuscation, redundancies, and others. Equipping the processor device accordingly requires time-consuming and costly development work. Furthermore, these measures increase the complexity of the product, which can lead to errors if implemented carelessly.In addition, 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 sufficient for the specific application.

[0061] The Trusted Loader loads other operating system modules into the processor device. Thus, the Trusted Loader influences each operating system module loaded by it. Accordingly, an operating system module loaded by the Trusted Loader can have a maximum certification level equal to the level achieved (passed) by the Trusted Loader, even if the operating system module outside the processor device has achieved (passed) certification at a higher level. Optionally, if a Trusted Loader is provided, the Trusted Loader has the highest certification level relative to other operating system modules, or at least no lower certification level. This ensures that the level of other operating system modules that can be subsequently loaded by the Trusted Loader is always maintained and never degraded.

[0062] In a similar way to operating system modules, additional application modules can be loaded into the processor device for installing applications. Optionally, 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.

[0063] Optionally, 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.

[0064] Optionally, the processor device includes:

[0065] - at least one processor unit for processing data including programs,

[0066] - at least one storage unit comprising one or more memories for storing data including programs,

[0067] - at least one interface unit for exchanging data, including programs, with units located outside the processor device.

[0068] Short the

[0069] In the following, the invention is explained in more detail using exemplary embodiments and with reference to the drawing, in which: 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, according to embodiments of the invention;

[0070] 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;

[0071] Fig. 3 shows an operating system module designed as a service, according to embodiments of the invention.

[0072] Detailed description of implementation examples

[0073] Fig. 1 shows a schematic representation of a modular 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.

[0074] Part 1-1 of Fig. 1 shows the processor device in a first state of installation 1-1, in which only a Trusted Loader TL is installed in the processor device. In this case, the Trusted Loader TL already includes the first basic functionalities (BOS) of the operating system. Alternatively, the basic functionalities (BOS) of the operating system could also be loaded into the processor device by the Trusted Loader TL.

[0075] Partial Figure 1-2 of Figure 1 shows the processor device in a second state of installation 1-2, in which, 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, (...) OSMn and a library from a library module LIBM1 are installed in the processor device. For this purpose, the two operating system modules 0SM1, OSMn and the library module LIBM1 have been loaded into the processor device, the modules OSM1, OSMn, LIB2 have been executed in the processor device, and thereby the various operating system functionalities and the library have been installed in the processor device.

[0076] Part 1-3 of Fig. 1 shows the processor device in a third state of the installation 1-3, in which, in addition to the modules and functionalities shown in part 1-2, a further library from a further library module LIB2 and two applications from two application modules APM1, APM2 have been installed in the processor device. In addition, operating system functionalities that had been installed from the first operating system module OS1 have been uninstalled and / or deleted.

[0077] Fig. 2 shows a schematic representation of a processor device containing an arrangement of multiple Java-based (more precisely, Java Card-specific) operating system modules to be executed in mutually isolated contexts, 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 Base OS operating system 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 when each service is executed, it executes in its own isolated context.

[0078] Each service contains a CAP file as payload data according to the Java Card specification, which contains the code to be installed. In the embodiment shown in Fig. 2, the CAP file contains both Java code and native code. The first of the three services, the BOS Service, is an operating system module for installing additional basic operating system functionality.

[0079] A second of the three services, Service 1, is an operating system module for installing a cryptographic algorithm in the processor device.

[0080] 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.

[0081] Other similar services can be loaded into the processor device and executed therein, for example to install a payment transaction application or a wallet application in the processor device.

[0082] Fig. 3 shows an operating system module designed as a service and 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 further 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 orThe Java code is structured in a JavaCard-typical manner and contains 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.

Claims

Patent claims 1. A method for installing, in a processor device, an operating system comprising a plurality of two or more operating system functionalities, or parts of such an operating system, the method comprising the steps of: - loading the operating system, or parts of the operating system, into the processor device; - Installing the loaded operating system, or the loaded parts of the operating system, in the processor device; characterized in that a) the loading of the operating system, or the parts of the operating system, takes place as loading of 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.

2. The method according to claim 1, wherein the or the respective operating system module is further d) isolated from other operating system modules, so that access between the 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.

3. Method according to claim 1 or 2, wherein the installation of the operating system or parts of the operating system is carried out: - as separate installation of the loaded separate operating system modules; or - as a joint installation of the loaded separate operating system modules; or - for some operating system modules as separate installation of the loaded separate operating system modules, and for some operating system modules as joint installation of the loaded separate operating system modules.

4. Method according to one of claims 1 to 3, wherein the following are provided as separate operating system modules: - at least one Trusted Loader (TL) 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; and - additionally one or more functional operating system modules (BOS, OSM1, ... OSMn, LIBM21, LIBM2).

5. The method according to claim 4, wherein one or more of the following are provided as functional operating system modules: - a basic functionality module (BOS), the installation of which installs one or more basic functionalities of the operating system in the processor device; - a cryptographic algorithm module, the installation of which installs an implementation of a cryptographic algorithm in the processor device; - a library module (LIBM1, LIBM2), the installation of which installs a library in the processor device; - a protocol module, the installation of which installs an implementation of a protocol for communication between the processor device and units located outside the processor device; - an updated version of one of the preceding functional operating system modules, intended as a replacement or supplement for one already installed in the processor device installed version of the same functional operating system module is loaded into the processor device and installed in the processor device.

6. Method according to claim 5, wherein one or more of the following is or are provided as basic functionality: - 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 instructions in the processor device, including receiving instructions, executing instructions, creating instructions and issuing instructions.

7. The method according to any one of claims 1 to 6, wherein the operating system module is designed as a Java Card CAP file according to the Java Card specification.

8. The method according to any one of claims 1 to 7, wherein the operating system module contains Java Card code or native code or both Java Card code and native code.

9. A method according to any one of claims 1 to 8, wherein: - the loading of an operating system module takes place: as loading a service in which the operating system module is integrated into the processor device, wherein a service for an operating system module for an operating system functionality is arranged to be executed and thereby install the operating system functionality in the processor device; and - installing an operating system module by executing the loaded service in the processor device.

10. The method according to claim 9, wherein the operating system is designed at least partially or entirely as a Java Card based operating system, and wherein the service is a Java Card applet is designed and the operating system module is designed as a Java Card cap file, whereby the service is executed by calling and executing the Java Card applet, whereby the operating system functionality corresponding to the Java Card cap file is installed in the processor device.

11. The method according to claim 10, wherein the Java Card applet by 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 by the process() and select() commands with which a 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.

12. The method according to claim 10 or 11, wherein the Java Card applet is assigned an application identifier, AID, and wherein a registry is set up in the processor device, in which registry the application identifier, AID, of the Java Card applet is entered when the applet is loaded into the processor device, and wherein the Java Card applet is called and executed based on the application identifier, AID, entered in the registry - and optionally further using a URI string pointing to the service -, whereby the operating system functionality corresponding to the Java Card CAP file is installed in the processor device.

13. The method according to any one of claims 9 to 12, wherein different services for different operating system modules are executed in different contexts which are isolated from one another, in particular by means of a microprocessor device MPU and / or a memory management MPU, wherein 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.

14. The method according to any one of claims 1 to 13, wherein each operating system module is separately certified, wherein optionally in the case of claim 4 the trusted loader has the highest or at least no lower level of certification relative to other operating system modules.

15. Method according to one of claims 1 to 14, wherein a security module is provided as the processor device.

Images