Installation of operating system in processor device, in particular security module

Abstract

The invention relates to a method for installing an operating system or a part of an operating system in a processor device, the operating system comprising a plurality of two or more operating system functions, the method comprising the steps of:-loading the operating system or the part of the operating system into the processor device; installing the loaded operating system or part of the loaded operating system in the processor device; the method is characterized in that: a) the loading of the operating system or the part of the operating system is carried out as the loading of at least one or more operating system modules which are separated from one another, and the operating system module or the corresponding operating system module b) contains code; the code is provided for installing operating system functions corresponding to the operating system modules in the processor device, and c) enables only operating system functions corresponding to the respective operating system modules to be installed in a separate manner, in particular without other operating system functions.

Description

Technical Field

[0001] The present invention relates to the installation of an operating system in a processor device, in particular a security module, ie a secure processor device with limited computing resources, and to the updating of an installed operating system. Background Art

[0002] Security modules, i.e., secure processor devices with limited computing resources in the form of chip card products, have long been known. Examples of such chip card products include SIM cards or UICCs (Universal Integrated Circuit Cards) in the telecommunications field, payment chip cards in the payment service field, health chip cards and medical practitioner ID chip cards in the healthcare field, and electronic ID cards and electronic passports with chips in the identification field. Also known as security modules are embedded components with a chip and an interface (contact and / or contactless) for electronic passports, chip cards, and other chip card front-end products. Operating a chip card product requires a chip card reader to which the chip card product can be removably coupled, either contactlessly or contactlessly.

[0003] Security modules (secure processor devices with limited computing resources) are becoming increasingly common. These security modules functionally correspond to the chip cards and other chip products listed above, but lack physical chip card functionality. These modules are embedded or soldered into the chip of mobile devices (or mobile terminals), or implemented as secure software within these devices. These security modules are permanently coupled to the mobile terminal (or mobile terminal) and cannot or are difficult to remove from the terminal (or mobile terminal). Examples of security modules that are functionally equivalent to chip cards but are not chip cards include the embedded UICC (eUICC) in telecommunications, the integrated UICC (iUICC) integrated into the chip of a mobile terminal, and the so-called eSIM, a SIM card emulated by software. In the payment sector, security modules without physical chip cards exist, for example, in the form of secure elements (SEs) within mobile terminals, eUICCs, or payment solutions stored in iUICCs. In the field of identity recognition, a security module without a chip card entity or similar physical entity exists in the form of a virtual electronic identity card and a virtual electronic passport set in a security element in a mobile terminal device.

[0004] Each operational security module (a secure processor device with limited computing resources) has an operating system that provides the basic functions of the security module. These basic functions include operational functions, such as memory management, including writing data to and reading data from the security module's memory. These basic functions also include functions for exchanging data with external units, such as a mobile radio-enabled terminal device in which the security module is running, or with a local or remote server. The functions for exchanging data include, for example, implementing a transmission protocol for data exchange. These basic functions also include functions for ensuring the security of other functions, such as cryptographic algorithms, for example, for encrypting and / or decrypting any type of data, or for generating and / or verifying cryptographic signatures.

[0005] Operating systems for security modules are known in the form of Java Card code and in native code.

[0006] Conventionally, to equip a security module with an operating system, the operating system is loaded into the security module as a whole and installed therein. To this end, the complete operating system is provided outside the security module in a suitable form so that the operating system can be loaded into the security module as a whole and installed therein, for example, in the form of an installation package for the complete operating system.

[0007] Part of creating the security module's operating system involves installing cryptographic algorithms into the operating system. To do this, a basic operating system framework and one or more cryptographic algorithms are created as separate source code. The source code for the one or more cryptographic algorithms is then installed into the source code for the basic operating system framework. Similarly, libraries can be created separately from the basic operating system framework and then installed into the basic operating system framework.

[0008] If changes are later made to the operating system, such as updates and / or bug fixes, a complete modified version of the operating system is created outside the security module, the changes, such as updates and / or code patches for implementing bug fixes, are implemented in the complete modified version, and the modified operating system is loaded as a whole into the security module and installed there in a manner similar to the loading and installation of the original operating system.

[0009] When making changes to the operating system for a security module, only a small portion of the operating system may be affected, while the rest of the operating system remains unchanged relative to the version of the operating system already in the security module. However, the entire operating system must still be reloaded and installed. Therefore, the amount of data to be loaded and installed can be very expensive compared to the changes being made. Consequently, making changes to the operating system inefficient and slow.

[0010] Changes to the operating system can include, for example, updates or bug fixes, or adaptations to changed applications. Changed applications can also arise, for example, from the fact that an operating system created for a first customer is also to be used for a second customer, who, although using the same application in principle as the first, desires a different, detailed solution in terms of operating system details. Therefore, while the operating system created for the first customer can be reused, minor changes or adaptations may be necessary.

[0011] Operating systems used in security modules typically require certification. To achieve certification, an operating system must undergo systematic testing by an authorized certification body and pass these tests. Changes to the operating system typically require recertification of the entire operating system. Even if the operating system is intended for two customers operating in the same industry and only minor changes exist between the operating system versions used for the two customers, both versions may need to be fully certified in parallel and independently of each other.

[0012] A special scenario for operating system modifications involves replacing the implementation of an integrated cryptographic algorithm, for example, with an updated or bug-fixed implementation of the same algorithm, or with another algorithm, such as a newer one. For example, if a vulnerability is discovered in the Advanced Encryption Standard (AES) implementation, it can be replaced with a modified AES implementation. Another example is the Data Encryption Standard (DES) implementation, which can be replaced with the newer AES implementation. Traditionally, this involves installing the source code for the new or modified cryptographic algorithm into the source code for the operating system's base framework outside the security module, replacing the existing source code. Subsequently, the modified operating system, i.e., the entire modified operating system source code (including the source code for the new or modified cryptographic algorithm and the source code for the operating system's base framework), is recertified and loaded into and installed in the security module.

[0013] A more efficient and flexible solution for installing and changing, in particular updating, an operating system in a security module is desired, which solution enables the installation and changing, in particular the subsequent updating, of an operating system to be carried out faster and with less resource expenditure.

[0014] Prior art document US8522234B2 discloses a computer-implemented method for customizing and installing a modular operating system into a computer system. The modular operating system includes a base module and multiple installable feature modules. Based on the desired performance characteristics of the operating system and the preset operating capacity and available storage capacity of the computer system, portions of the modular operating system are selectively installed to achieve the desired performance characteristics as closely as possible while maintaining the operating capacity and available storage capacity. To achieve this, an operating system customization tool ("tailorer") is used to combine only the modules that are required or permitted based on the desired operating capacity and available storage capacity, and the resulting operating system is installed.

[0015] Document US6292941B1 in the prior art discloses a method for installing and adapting an operating system on a local computer, wherein the adapted operating system is configured on the local computer by remotely adapting a standard operating system provided locally in a removable memory of the local computer using an adaptation model, the adaptation model being provided by a remote management computer. Summary of the Invention

[0016] The technical problem to be solved by the present invention is to provide a more efficient and flexible solution for installing and changing, in particular updating, an operating system in a processor device, in particular a security module, which solution enables the installation and changing, in particular subsequent updating, of the operating system to be achieved more quickly and with less resource expenditure.

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

[0018] The core idea of ​​the present invention is to reduce the installation to be carried out specifically to the desired parts of the operating system by means of a modular installation solution and to omit other parts of the operating system during the installation process or to assign them to other installation steps.

[0019] The method according to the invention according to claim 1 is particularly provided 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 functions.

[0020] The method comprises the following steps:

[0021] - loading an operating system or parts of an operating system into a processor device;

[0022] - Installing the loaded operating system or a portion of the loaded operating system in the processor device.

[0023] The method is characterized in that:

[0024] a) the loading of the operating system or parts of the operating system is carried out as loading of at least one or more operating system modules that are separate from one another,

[0025] Among them, the operating system module or the corresponding operating system module

[0026] b) comprises code arranged to install operating system functionality corresponding to the operating system module in the processor device, and

[0027] c) enabling the installation of only the operating system functions corresponding to the respective operating system module in a separate manner, in particular without installing other operating system functions.

[0028] Separate operating system modules are provided, each containing code configured to install operating system functions corresponding to the operating system modules in a processor device, so that only the functions of the operating system selected for installation can be provided in a targeted, customized manner and then installed. Other operating system functions that do not currently need 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 part of the operating system can significantly reduce the amount of data that must be installed. The reduction in the amount of data reduces the time and computing resources required for installation. This applies equally whether the installation is for the first installation of an operating system or part of an operating system, for a change or update of an already installed operating system or part of such an operating system, for a change to the operating system in the form of a change to an already installed part of the operating system, or for a change in the form of an extension of an already installed operating system to a non-existent part of the operating system.

[0029] According to claim 1 , a method is therefore provided in which the installation and modification of the operating system, in particular subsequent updates, can be carried out more quickly and with less resource expenditure.

[0030] Another advantage of the present invention is that the risk of data errors, data transmission errors when transmitting the code to the processor device and installation errors when installing the code in the processor device can be reduced due to the smaller amount of data to be installed.

[0031] Another advantage of the present invention is that the possibility of loading and installing the individual operating system modules, and therefore the individual operating system functions, in an isolated manner opens up the possibility of evaluating the individual operating system modules, and therefore the individual operating system functions, in an isolated manner and certifying them by an authorized certification body, such as an accredited testing laboratory. If only a specific operating system module and its associated operating system functions are changed, it can be achieved by appropriately separating or isolating the operating system modules that only these operating system modules and their associated operating system functions need to be recertified. The certification of the remaining operating system modules, and therefore the remaining operating system functions, remains unchanged.

[0032] In order to separate or isolate different executable program codes, various measures are known, which can also be applied to the operating system module according to the present invention as executable program code. Exemplary measures for separating codes are contexts, security domains, and sandbox mechanisms.

[0033] Optionally, different operating system modules are arranged in different security domains, in particular a Global Platform security domain, and are executed in these different security domains.

[0034] Optionally, the operating system module or the corresponding operating system module is further d) isolated from other operating system modules, such that access between the operating system module or the corresponding operating system module and other operating system modules is prevented or, at most, is only permitted via a controlled interface mechanism. If the processor device is based on Java or Java Card, for example, a shareable interface object (SHAREIBLE INTERFACE OBJECT) or an entry point object (ENTRY POINTOBJECT) can be provided as the controlled interface mechanism.

[0035] Optionally, the operating system or portion of the operating system is installed as separate installations of the loaded separate operating system modules. Alternatively, the operating system or portion of the operating system is installed as a collective installation of the loaded separate operating system modules. Optionally, for some operating system modules, the installation is performed as separate installations of the loaded separate operating system modules, and for some operating system modules, the installation is performed as a collective installation of the loaded separate operating system modules.

[0036] Different scenarios for installing an operating system or operating system parts can include different numbers of operating system modules and / or different sizes of operating system portions, or in extreme cases, the entire operating system. If a certain number of operating system modules are loaded simultaneously for installation, the modules can be installed individually or, alternatively, in blocks. This means that modularity is no longer a factor in the installation process. Which approach is advantageous in a specific installation process may depend on various boundary conditions.

[0037] - at least one trusted loader, the trusted loader being configured to load the further operating system module into the processor device to cause the further operating system module to be installed in the processor device; and

[0038] - additionally one or more functional operating system modules,

[0039] Optionally, operating system modules are configured to be separate from each other.

[0040] According to the embodiments described herein, the trusted loader is optionally the first operating system module installed in the processor device, which first operating system module enables subsequent loading and installation of further operating system modules in the processor device by the trusted loader.

[0041] The trusted loader is optionally not itself a functional operating system module, but is specifically provided for loading further operating system modules into the processor device and for instigating the installation of these further operating system modules in the processor device.

[0042] Optionally, in addition to the functionality of loading additional operating system modules, the trusted loader may also include modules for basic operating system functions, such as: - memory management of the processor device's memory units; - reading and / or writing data, including programs, to the processor device's memory units; - processing instructions in the processor device, including receiving, executing, creating, and outputting instructions. Alternatively, these basic functions may be provided by separate operating system modules.

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

[0044] - a basic function module, by installing the basic function module, one or more basic functions of the operating system are installed in the processor device;

[0045] - an encryption algorithm module, by installing the encryption algorithm module, an implementation of the encryption algorithm is installed in the processor device;

[0046] - a library module, by installing the library module, installing the library in the processor device;

[0047] - a protocol module, by installing the protocol module, installing an implementation of a protocol for communication between the processor device and a unit arranged outside the processor device;

[0048] - an updated version of one of the aforementioned functional operating system modules, loading the updated version into the processor device and installing it in the processor device as a replacement for or in addition to a version of the same functional operating system module already installed in the processor device.

[0049] As encryption algorithm, for example, a symmetric or asymmetric algorithm such as DES, AES, 3DES, RSA or other algorithms may be provided.

[0050] As a protocol, a transmission protocol for chip cards or similar chip-based products can be optionally provided, 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. Furthermore, as a protocol, a transmission protocol for payment services, telecommunications, or identification / passport applications can be optionally provided.

[0051] Optionally, one or more of the following functions are set as basic functions:

[0052] - memory management of the memory units of the processor device;

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

[0054] - The processing of instructions in a processor device, including receiving instructions, executing instructions, creating instructions, and outputting instructions.

[0055] Optionally, the operating system module is designed as a Java Card Cap file compliant with the Java Card specification.

[0056] Optionally, the operating system module may include Java Card code or native code, or both Java Card code and native code. In particular, a Java Card Cap file may include native code in addition to Java code.

[0057] Optionally, the operating system module is loaded by loading a service into the processor device, into which the operating system module is integrated. Here, a service for an operating system module for an operating system function is understood to mean an instance of a program code, in particular a program code, configured to execute the service. By executing the service (e.g., program code) loaded into the processor device, the operating system function is installed in the processor device.

[0058] Optionally, the operating system is designed at least partially or completely as a Java Card-based operating system. Here, services are designed as Java Card applets, and operating system modules are designed as Java Card Cap files. Services are executed by calling and executing the Java Card applets. This installs operating system functions corresponding to the Java Card Cap files into the processor device. In this embodiment, the Java Card Cap files may contain native code in addition to Java code.

[0059] Optionally, the Java Card applet used to implement the service is designed as a modified Java Card applet, which is modified so that the modified Java Card applet cannot be called through the process() and select() instructions that can be used to call the standard Java Card applet, but can only be provided or called through a controlled interface object, in particular a shareable interface object or an entry point object.

[0060] Optionally, in an embodiment using a Java Card applet, the Java Card applet is assigned an application identifier (AID), and a registry is provided in the processor device. When the Java Card applet is loaded into the processor device, the Java Card applet's application identifier (AID) is recorded in the registry. In this case, the Java Card applet is invoked and executed based on the application identifier (AID) recorded in the registry. Optionally, the Java Card applet is further invoked using a uniform resource identifier (URI) string pointing to a service. When the URI string is invoked, an operating system function corresponding to the Java Card Cap file is installed in the processor device.

[0061] Optionally, different services for different operating system modules are executed in different, isolated contexts. Optionally, the contexts are isolated from each other, in particular by the function of the microprocessor unit MPU and / or the memory management MPU. Optionally, interaction or communication between different services can only occur via a controlled interface mechanism, in particular, a shareable interface object and / or entry point object.

[0062] Context isolation is advantageous in particular in conjunction with authentication of a processor device. Context isolation can particularly help reduce the overhead of re-authentication when an operating system is modified.

[0063] Optionally, the context separation is designed such that, depending on the authentication regulations to be applied for the processor device, when an operating system module is modified in a first context, the existing authentication of other operating system modules in other contexts separated from the first context is not affected by the modification. This ensures that only the modified operating system module and its associated operating system functions must be reauthenticated.

[0064] Optionally, each operating system module can be certified separately. This allows, in a fully certified operating system where only a single operating system module or a group of single operating system modules and their associated operating system functions are modified, the existing certification for the remaining components of the operating system can be retained, while only the modified operating system parts (modules, functions) must be recertified.

[0065] Certification is divided into different levels. The higher the certification level, the stricter the testing requirements. If a processor device passes a certain level of certification, it is considered certified for that level and all lower levels below it. Higher levels are considered not met, and the processor device is considered to have failed certification for the higher levels.

[0066] The higher the level of certification, the wider the range of possible uses of the certified processor device. Therefore, efforts are made to pass certification at the highest level possible. On the other hand, high-level certification means that the measures, especially security measures, that must be set up in the processor device in order to pass the certification test are expensive. As measures, for example, program routines such as masking, encryption, overwriting, redundancy, etc. can be set up to defend against side channel attacks, hacker attacks and similar attacks. In order to equip the processor device accordingly, time-consuming and costly development work is required. In addition, the complexity of the product increases with the measures, which may bring about the risk of errors when implemented carelessly. In addition, testing for higher certification levels takes longer and is more expensive than testing for lower certification levels. Accordingly, the highest level of certification is not always pursued, but usually only the certification level that is sufficient to meet the specific application purpose is pursued.

[0067] Other operating system modules are loaded into the processor device via the trusted loader. Therefore, the trusted loader has an impact on each operating system module loaded by it. Accordingly, an operating system module loaded via the trusted loader can have a maximum authentication level equal to the level of authentication achieved (passed) by the trusted loader, even if the operating system module has achieved (passed) a higher level of authentication outside the processor device.

[0068] Optionally, when a trusted loader is provided, the trusted loader has the highest level or at least the same level of authentication relative to other operating system modules. Thus, the levels of other operating system modules that can be reloaded by the trusted loader are always maintained and will not decrease.

[0069] In a similar manner to the operating system module, an application module can be additionally loaded into the processor device to install the application. Some operating system modules can optionally include application modules, and such operating system modules can also be used to load the application modules included therein into the processor device and install them therein.

[0070] Optionally, a security module is provided as the processor device, ie a secure processor device with limited computing resources, in particular a chip card without a card-shaped entity or a corresponding processor module.

[0071] Optionally, the processor means comprises:

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

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

[0074] at least one interface unit for exchanging data, including programs, with units arranged outside the processor arrangement. BRIEF DESCRIPTION OF THE DRAWINGS

[0075] The present invention will be described in detail below based on embodiments and with reference to the accompanying drawings, in which:

[0076] Figure 1 A schematic diagram illustrating module-based installation and modular expansion of an operating system by sequentially installing multiple operating system modules according to an embodiment of the present invention is shown;

[0077] Figure 2 A schematic diagram illustrating an arrangement of multiple Java-based operating system modules executed in contexts isolated from each other according to an embodiment of the present invention;

[0078] Figure 3 An operating system module designed as a service according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0079] Figure 1 A schematic diagram shows module-based installation and modular expansion of an operating system by sequentially installing a plurality of operating system modules in a processor device according to an embodiment of the present invention.

[0080] Figure 1 Part Figure 1-1 The processor device is shown in a first installed state 1-1, in which only a trusted loader (Trusted Loader) TL is installed in the processor device. In this case, the trusted loader TL already includes the first basic functions of the operating system BOS. Alternatively, the basic functions of the operating system BOS can also be loaded into the processor device via the trusted loader TL.

[0081] Figure 1 Part Figure 1-2 The processor device is shown in a second state 1-2 of installation, in which the processor device is installed except for the parts according to the Figure 1-1 In addition to the basic operating system functions BOS, the trusted loader TL also installs various operating system functions from two (or more) operating system modules OSM1, (...) OSMn, and libraries from the library module LIBM1 (library module). To this end, the two operating system modules OSM1, OSMn and the library module LIBM1 are loaded into the processor device, causing the modules OSM1, OSMn, and LIB2 to execute in the processor device, thereby installing the various operating system functions and libraries in the processor device.

[0082] Figure 1 Part Figure 1-3 The processor device is shown in a third state 1-3 of installation, in which the processor device is installed except for the part Figure 1-2 In addition to the modules and functions shown in FIG, a further library is installed from a further library module LIB2 and two applications are installed from two application modules APM1, APM2. Additionally, the operating system functions installed from the first operating system module OS1 have been uninstalled and / or deleted.

[0083] Figure 2 A schematic diagram of a processor device according to an embodiment of the present invention is shown. The processor device includes an arrangement of multiple Java-based (more precisely, Java Card-specific) operating system modules, executed in isolated contexts. The processor device includes a trusted loader TL. The trusted loader already contains the basic operating system functions (Base OS) itself, or it loads the basic functions by loading one or more basic function modules and installs them in the processor device. The processor device includes three services: BOS Service, Service 1, and Service 2. Each of these three services contains executable program code, the execution of which installs the service's useful data content into the processor device. Each of these three services is isolated from the other two services by a context boundary L, so that when a service is executed, it executes in its own isolated context.

[0084] Each service contains a Cap file that complies with the Java Card specification as useful data content, and the Cap file contains the code to be installed. Figure 2 In the illustrated embodiment, the Cap file contains both Java code and native code.

[0085] The first of the three services, namely the BOS service, is an operating system module for installing other basic functions of the operating system.

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

[0087] The third of the three services, Service 2, is an operating system module for installing an integrated subscriber identity module iUICC in a processor device.

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

[0089] Figure 3 A detailed view shows an operating system module designed as a service according to an embodiment of the present invention. The module includes a Java Card Cap file. This service contains a Java Card Cap file, which contains Java code that conforms to the Java Card specification. The Java code is contained in one or more files, known as Java Source Files, which have the *.java file extension, which is specific to Java (Java Card). Figure 3 The exemplary Cap file shown also contains a static resource component (Static Resource Komponente), with the help of which native code and local resources can be added to the Java Card Cap file. The native code can be set in one or more Files. The native code can exist in *.bin or *.hex format, for example. Local resources can exist in *.txt or *.html format, for example. The Cap file or Java code is structured in a typical Java Card manner and contains, for example, data elements such as a header, a directory, one or more applets, import information, a constant pool, a class, etc. Native code and local resources can be added to the Cap file as static resources with the help of a static resource element (Static Resource Element).

Claims

1. A method for installing an operating system or a portion of said operating system in a processor device, said operating system comprising a plurality of two or more operating system functions, wherein: The method comprises the following steps: - loading an operating system or a portion of an operating system into said processor device; - installing the loaded operating system or a portion of the loaded operating system in said processor device; Its characteristics are: a) the loading of the operating system or parts of the operating system is carried out as loading of at least one or more operating system modules that are separate from one another, Wherein, the operating system module or the corresponding operating system module b) comprising code configured to install operating system functionality corresponding to an operating system module in the processor device, and c) enabling the installation of only the operating system functions corresponding to the respective operating system module in a separate manner, in particular without installing other operating system functions.

2. The method according to claim 1, in, The operating system module or the corresponding operating system module further d) Isolation 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 at most only possible via controlled interface mechanisms.

3. The method according to claim 1 or 2, wherein the installation of the operating system or a part of the operating system is performed by: - installation in a separate manner as a separate operating system module loaded; or - Co-installation as separate operating system modules loaded; or - For some operating system modules, installation as separate loaded operating system modules, and for some operating system modules, installation as a common loaded separate operating system modules.

4. The method according to any one of claims 1 to 3, wherein - at least one trusted loader (TL), which is configured to load a further operating system module into the processor device in order to cause the further operating system module to be installed in the processor device; and - additionally one or more functional operating system modules (BOS, OSM1, ... OSMn, LIBM21, LIBM2), Operating system modules that are set up to be separate from each other.

5. The method according to claim 4, wherein One or more of the following modules are set as functional operating system modules: - a basic function module (BOS), by installing the basic function module, one or more basic functions of an operating system are installed in the processor device; - an encryption algorithm module, by installing said encryption algorithm module, an implementation of an encryption algorithm is installed in said processor device; - library modules (LIBM1, LIBM2), by installing the library modules, a library is installed in the processor device; - a protocol module, by installing the protocol module, an implementation of a protocol for communication between the processor device and a unit arranged outside the processor device is installed; - an updated version of one of the aforementioned functional operating system modules, said updated version being loaded into said processor device and installed in said processor device as a replacement or supplement for a version of the same functional operating system module already installed in said processor device.

6. The method according to claim 5, wherein: One or more of the following features are set as basic features: - memory management of a memory unit of the processor device; - reading and / or writing of data, including programs, in a memory unit of the processor device; - Processing of instructions in said processor means, including receiving instructions, executing instructions, creating instructions and outputting 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 that complies with the JavaCard specification.

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

9. The method according to any one of claims 1 to 8, wherein: - the loading of the operating system module takes place in such a way that a service is loaded into the processor device, the operating system module being integrated into the service, wherein the service for the operating system module for the operating system function is provided for executing the service and thereby installing the operating system function 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 completely as a Java Card-based operating system, wherein services are designed as Java Card applets and operating system modules are designed as Java Card Cap files, wherein services are executed by calling and causing the Java Card applets to be executed, thereby installing operating system functions corresponding to the Java Card Cap files in the processor device.

11. The method according to claim 10, wherein: The Java Card applet used to implement the service is designed as a modified Java Card applet, which is modified so that it cannot be called through the process() and select() instructions that can be used to call the Java Card applet, but can only be provided or called through a controlled interface object, in particular a shareable interface object or an entry point object.

12. The method according to claim 10 or 11, wherein A Java Card applet is assigned an application identifier, i.e., AID, and a registry is provided in the processor device. When the Java Card applet is loaded into the processor device, the application identifier, i.e., AID, of the Java Card applet is recorded in the registry. The Java Card applet is selectively called and executed based on the application identifier, i.e., AID, recorded in the registry and further using a URI string pointing to a service, thereby installing an operating system function corresponding to the Java Card Cap file 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 that are isolated from each other, and the contexts are isolated from each other in particular by means of the action of the microprocessor device MPU and / or the memory management MPU, wherein interaction or communication between different services can only be carried out via controlled interface mechanisms, in particular shareable interface objects and / or entry point objects.

14. The method according to any one of claims 1 to 13, wherein Each operating system module is authenticated in a separate manner, wherein, optionally in the case of claim 4, the trusted loader has the highest level of authentication or at least not a lower level than the other operating system modules.

15. The method according to any one of claims 1 to 14, wherein The security module is provided as a processor device.

Images