EP1147467A1

EP1147467A1 - Method for loading applications in a multiapplication onplatform system equipped with data processing resources, corresponding executing system and method

Info

Publication number: EP1147467A1
Application number: EP00981423A
Authority: EP
Inventors: Christian Goire; Jean-Paul Billon
Original assignee: Bull CP8 SA
Current assignee: CP8 Technologies SA
Priority date: 1999-11-17
Filing date: 2000-11-17
Publication date: 2001-10-24
Also published as: FR2801118A1; AR034105A1; BR0007569A; JP2003515215A; JP3689368B2; WO2001037085A1; HK1042151B; FR2801118B1; US6983460B1; CN1341238A; CN1162775C; CA2360431A1; HK1042151A1

Abstract

The invention concerns a method for loading application in a multiapplication onplatform system, the corresponding onplatform system, and the method for executing an application of the onplatform system. The system for application loading on an onplatform system comprising a execution environment including a virtual machine comprising a language interpreter of the intermediate pseudocode type, application programming interfaces (API), from a station whereon the application source code is written, compiled in pseudocode, verified and converted is characterised in that the conversion comprises steps which consist in: producing a static linkage of a plurality of packages to be stored in the same name space on the onplatform system, called modules, and constituting an application programming interface module or a service module corresponding to an application, and consists in assigning an identifier to each module (MID), and a reference number to each class (NCI), to each method (NM) and to each attribute (NA). The reference to a method or an attribute in the pseudocode linked to a module is coded on three multiplets formed by an indicator signalling the reference to a class internal (II) or an external (IE) to the module, the class number (NCI) and either the method number (NM) or the attribute number (NA), a reference (IE) to an external class being systematically interpreted by the virtual machine as a reference to an application programming interface module.

Description

METHOD FOR LOADING APPLICATIONS IN A MULTI-APPLICATION ON-BOARD SYSTEM PROVIDED WITH DATA PROCESSING RESOURCES, SYSTEM, AND METHOD FOR EXECUTING THEREOF

The present invention relates to a method for loading applications into a multi-application embedded system provided with data processing resources, the corresponding embedded system, and the method for executing an application from a corresponding embedded system.

The present invention relates more particularly to the realization of firewalls between modules sharing the same memory space in systems embedded on portable multi-application objects using an intermediate pseudocode and an associated virtual machine.

The "Java" technology (registered trademark) introduced by the company

15 "Sun" is based on an object oriented programming language "Java" and an associated virtual machine. This technology was developed on stations or PC (Personal Computer), called hereinafter classic "Java" platform, having a CPU power and a significant memory of the order of mega byte or megabyte.

20 In recent years, the concepts of "Java" technology have been adopted and adapted to operate on systems embedded in portable objects, for example in the format of a credit card or SIM micromodule incorporating a microprocessor and commonly known as a smart card, or GSM (Global System for

25 Mobile Communication), PCMCIA cards or any other portable terminal. Thereafter we will use the term card to designate any of these portable objects. The programming of embedded systems, previously carried out in assembler, is now possible in an advanced language like "Java", and allows to facilitate and accelerate development

30 client applications. This new type of platform specific to the on-board systems of a portable object, hereinafter called the specific platform, constitutes a subset of the conventional platform. The differences result from the reduced environment of embedded systems. Conventionally, as shown in Figure 4a, a smart card (10) includes an input and output system (1 1) connected to the microprocessor (14), a volatile memory RAM (12) (Random Access Memory ) a non-volatile memory constituted by a ROM read only memory (13) (Read Only Memory) and a programmable non-volatile memory (15) constituted by a flash RAM or EEPROM (Electrically Erasable Programmable Read Only Memory). All of these elements are connected to the microprocessor by a link BUS. As an example, a smart card in the best of cases, using the new components currently existing, includes a ROM memory, an EEPROM memory of 32 kilobytes or kilo bytes, and a RAM memory of 2 Kilo Bytes.

In a classic "Java" system, an application is written on a station or PC. Its source code is compiled in an intermediate pseudocode, called "Java Byte Code" or byte code, which is independent of the machine code of the platform used. The application is then downloaded to the target platform or classic "Java" platform. The loaded application, consisting of a set of classes called client classes whose methods have been compiled in the pseudocode, relies on application programming interfaces or Interface for Application Programming or AP! (Application Programming Interface). Application programming interfaces make it possible to standardize the user interface, to control an editor, a keyboard or a printer for example. The virtual machine of a conventional platform includes a pseudocode verifier, a dynamic class loader, a pseudocode interpreter which allows translation into machine code and a security manager. The main difference between a classic virtual machine and a virtual machine of an embedded system, called virtual machine specific, is due to the fact that the virtual machine of an embedded system is broken down into two separate parts. According to FIG. 4b, the virtual machine comprises a part (30) outside the specific platform (40), called an off-platform virtual machine, comprising a converter (32), and a part (41) in the card constituting the specific platform (40), called on-board virtual machine (41) ("on-platform") including the pseudocode interpreter.

Thus, in the case of a specific platform, the source program (21) of the application is written, compiled in intermediate pseudocode by a compiler (22), and verified by a verifier (31) of intermediate pseudocode on a conventional station (20), then converted by the converter (32), placed on the same station (20) or another station. After a possible passage through a signer (34), the application is then downloaded to the volatile electrically programmable and possibly electrically erasable EEPROM (15) of the portable object or specific platform (40). This loading is carried out by a loader comprising a part off platform called downloader (33) and a part on the specific platform called charger (42). Contrary to what exists on a conventional platform for a station, the virtual machine (41) of a specific platform (40), placed in ROM memory with the operating system (48) (Operating System) may include an intermediate pseudocode verifier, which is too heavy to be stored and / or executed in the portable object. The specific platform (40) also does not contain a dynamic class loader. Indeed, for the field of application of the invention, on the virtual machine (30) off-platform, the verifier (31) verifies that the compiled classes are well formed and verifies the language violations specific to the description of the specific platform. The converter (32) does the work required for loading classes and resolving references. The converter performs the static link of the classes, it resolves the symbolic references to the classes, methods and attributes already present on the map. It distributes the store and create data structures to represent classes, create static or native methods and attributes and initialize static variables.

The execution environment of the specific platform (Runtime Environment or RE) includes the on-board virtual machine ("onplatform") (41) limited to an interpreter, an API platform and the so-called native methods (43) or associated statics. The API platform includes APIs (44) (Application Programming Interface) defining a set of classes, called system classes (45), and the calling conventions by which an application accesses the execution environment (RE). and static methods (43). The static methods (43) execute the memory allocation, input and output, and cryptographic services of the card.

The interpreter of the on-board virtual machine of the card (41) (on-platform), serves as a support for the "Java" language, and reads the intermediate pseudocode sequentially, instruction by instruction. Each standard instruction of this intermediate pseudocode is interpreted in the language of the microprocessor by the interpreter then executed by the microprocessor. In general, the standard instructions of the intermediate pseudocode make it possible to deal with advanced functions such as arithmetic processing and manipulation of objects. The concept of object concerns computer objects such as lists, data tables or the like. The so-called client classes (46) of the applications and the system classes (45) of the APIs are all loaded into the same memory space and are managed by means of a class table (47).

The virtual machine (41) is also responsible for managing the classes and objects and for enforcing the partitions or firewalls between the applications in order to allow secure sharing of the data, also called attributes, variables or fields. In the case of a portable object of the smart card type, an application of a specific platform can be activated directly by the execution environment (RE) when a selection Application Protocol Data Unit (APDU) issued by a service or terminal is received by the card.

In order to restrict access to data between parts of code sharing the same memory space, one of the classic methods on a classic platform is based on the explicit visibility restriction declared in the source code. According to FIG. 4c, the methods (NM1, NM2), respectively (NM3, NM4), and the attributes (NA1, NA2), respectively (NA3, NA4) are encapsulated in classes (NCI3), respectively (NCI2), which themselves are part of packages (Package 1), respectively (Package n) each grouping several classes. A class can be public such as (NCI1 or NCI2) or private such as (NCI3) in relation to a package, which implies, in the latter case, that only classes of the same package can access this class. The methods (example NM2) and the data (example NA1) of a class (NCI3) can be private compared to the class (NM2, NA1), which itself is private compared to the package (Package 1), or public with respect to the package (for example NM1, NA2) or to the class (for example NM4, NA4). This restriction of visibility makes it possible to obtain flexible access between the different sets of packages (Package 1, Package n) stored in the same namespace, but has some drawbacks. The classic or specific platform does not support the notion of subpackages badly. The client classes of a large application must be distributed between different sub-packages which only represent different packages for the virtual machine. To share the resources between these sub-packages, these resources are necessarily declared public, thus making them visible from any other package. This makes it difficult to clearly organize the package of different applications for large applications and to obtain firewalls between applications. In the case of the classic platform, on a station, the respect of the confidentiality of resources, as declared in the source programs, is based on dynamic verifications. To perform these dynamic checks, the virtual machine must have all the information concerning the access restriction declarations for each class, method or attribute, which cannot be possible in the case of the memory space available on the embedded virtual machine. (onplatform) using the intermediate pseudocode or pre-code byte of the off-platform virtual machine. In the case of a specific platform for a portable object, the access restrictions can be verified statically during compilation and can be verified again by the verifier of the non-platform part. It is indeed assumed that what is loaded on the specific platform of the portable object is correct, because no verification can be performed on the specific platform due to the loss of information during the conversion phase . In addition, there is no guarantee that a package cannot be extended or modified by new classes from foreign sources, which can destroy all security based on the use of private packages.

The second means provided by the virtual machine of a classic platform is the notion of separation of namespaces. With the dynamic linking scheme of a classic platform, the classes can be loaded, from directories of the local file system, called "ClassPath" previously declared as constituting the location of the system classes forming the API platform standard, or from other directories on the local file system or remote servers. The client classes of an application, outside of the "ClassPath", must be loaded by a specifically programmed class loader. This feature is particularly used for loading "Java" applications by "Java" enabled browsers. Thus, the applications coming from different sources, are loaded by loaders of different classes. For each locator, commonly called URL (Uniform Resource Locator), a specific instance of class "application class loader" is used. The external name of a class is the assembly <Package Name> + <Class Name>. When a class is loaded, it is stored in an internal class table, and a reference to the class loader used to load this class is added as a prefix to the package name of the class. The class name is then "Class Loader Reference> + <Package Name> + <Class Name". Thus classes declared as belonging to the same package but loaded by loaders of different classes are not perceived by the virtual machine as belonging to the same package.

When resolving a reference, the usual policy for class loaders is to search first in the system classes and in case of failure, to search among the class files present in the location where the loader can load the classes. According to this operating principle of the loader, an application cannot directly access the client classes of another application loaded by a loader of different classes. An application can access all the public resources of the public classes of ClassPath, but the classes of ClassPath cannot directly access the classes of an application although they can refer to instances of client classes of the application by converting them into a public type defined in the "Classpath". An application cannot extend or modify system class packages from Classpath or any other application loaded by loaders of different classes. The use of separation of namespaces by inserting a reference to the class loader in the name of the class, added to the full typing provided by the "Java" language, makes it possible to provide an efficient firewall between applications. The innate space name separation mechanism makes it easy to load new applications. Applications can exchange objects through the classes specifically programmed for this purpose and located in the "Classpath". An application can use an object coming from another application loaded by a different class loader, if this object can be changed to a public type defined in the "Classpath".

Unfortunately this name separation mechanism, based on a classic virtual machine and its dynamic link process cannot be performed on a specific platform. The dynamic link cannot be carried out by the virtual machine of a specific platform, this requiring a memory space allowing the storage of class files of a classic "Java" platform, having unresolved references. In a specific platform, the system classes of the APIs and the client classes of the applications are not isolated in particular namespaces.

The object of the present invention is to provide a solution providing the advantages of name separation in the context of embedded systems having a virtual machine in two parts, the static link diagram being performed by the off-platform part.

In the context of embedded systems, such as payment terminals, multi-application, it is necessary to have efficient firewalls between "Java" applications provided by different sources, such as different payment systems (Visa , Mastercard ...). It may be useful to allow flexible cooperation between applications from different sources. The on-board system must also be easily updated by downloading new applications or new utility modules or even updates without disturbing the applications already loaded.

A first object of the invention is to propose a loading method making it possible to obtain robust firewalls between the applications while allowing cooperation between the applications and the possibility of upgrading the applications or of loading other applications. This object is achieved by the fact that the method for loading applications on an embedded system according to the invention, comprising a execution environment including a virtual machine comprising an intermediate pseudocode-type language interpreter, application programming interfaces (API), from a station on which the application source code is written, compiled in pseudocode by a compiler, checked by a verifier, converted by a converter and loaded by a charger, is characterized in that

- the conversion includes the realization of the static link of a plurality of sets of packages intended to be stored in the same name space on the on-board system, called modules, by assigning an identifier to each module (MID), and a number of reference to each class, to each method and to each attribute encapsulated in the classes of the module,

- the reference to a method or an attribute, in the linked pseudocode of a module, being coded on three bytes constituted by an indicator indicating the reference to a class internal or external to the module, the number of the class and either the number of the method is the number of the attribute,

- the loaded modules are one or more application programming interface modules, called API module, comprising system classes or service modules each corresponding to an application, a reference to an external class being systematically interpreted by the virtual machine as a reference to an application programming interface module.

According to another particularity, the loading of the modules on the on-board system comprises memorizing on the one hand at least one table representing the modules, the number associated, by the linker between 0 and n, with a module constituting the index of said module in the table, and on the other hand of a table memorizing the association of the index of the representation table with the identifier (MID) of said module, said table and the table being in non-volatile programmable memory, an external reference to an external module in the pseudocode being interpreted by the interpreter of the virtual machine as constituting an access index to the module equivalent to that of the table of modules.

According to another particularity, the loading comprises the memorization, for each module, of a table of representation of its classes, comprising a reference to the index of its module and, for each class, a table of representation of the attributes and methods .

According to another particularity, the modules are referenced in a single array of modules, the system classes are contained in a single API module, any reference to an external class in the pseudocode different from n will be interpreted by the virtual machine as a reference to said module API.

According to another particularity, the classes being declared public, or in private package, the attributes and methods being declared protected, in private package or in private class, the numbering of the classes is carried out according to the order public classes then classes in private packages , the numbering of the attributes or methods is carried out by the converter according to the attribute attribute or method public, protected, in private package and in private class.

According to another particularity, the system classes are contained in several API modules which can be loaded separately, the loader maintains in the programmable non-volatile memory two tables for representing the modules and two corresponding MID / IMi association tables, one for the API modules. and the other for non-API modules, the loader loading the modules into one of the two arrays according to the nature of the module specified in the header thereof, any external reference of a module in the module array being interpreted as a reference to the API module index.

According to another particularity, the static connection of a module is carried out such that the reference to a class external to a non-API module in the intermediate pseudocode is an index in a table of the header of the module, each entry of which is an identifier (MID) of a referenced API module, the loading of said module on the target platform comprising the replacement of said reference by the number of the API module index obtained from the identifier (MID) of the association table of API modules.

Another object of the invention is to propose a corresponding on-board system.

This object is achieved by the fact that the embedded system according to the invention, comprising a virtual machine and an API platform including application programming interfaces, a fixed non-volatile memory, a programmable or modifiable non-volatile memory, and a random access memory, is characterized in that the programmable non-volatile memory comprises at least one API module comprising system classes and service modules, at least one module representation table, in which the modules are indexed and a table associating the index of a module of the representation table with the identifier of said module, each module comprising a table of representation of the classes, in which the classes are indexed and in which each class presents a reference to the index of its module, each class comprising an array of attributes and methods representation, in which the attributes and methods are indexed, the reference to a e method or an attribute being coded on at least three bytes corresponding to a reference to a class internal or external to the module, a reference external to the module constituting the index of the API module in the module table, a class number corresponding to l 'index of the class in the module class representation table, and a method or attribute number corresponding to the index of the method or attribute in the method or attribute representation table of the class module.

According to another particular feature, the on-board system includes means for comparing the first byte of the three reference coding bytes to a method or to an attribute with a determined value n to decide whether it is an internal or external class. . According to another particular feature, the on-board system comprises a main module comprising the main program of the system.

According to another particularity, the classes are indexed according to the order public classes then classes in private packages, and the attributes or methods according to the order attribute or method public, protected, in private package and in private class.

According to another particular feature, the programmable non-volatile memory comprises several API modules comprising system classes, two modules representation tables, one for the API modules and the other for the non-API modules and the main module, and two MID / IMi association tables each corresponding to a module representation table.,

According to another particularity, the on-board system comprises an access manager class "Access manager" of an API module comprising a method making it possible to create an instance of a service module, via the main module, said class having protection prohibiting him from having more than one instance.

Another object of the invention is to propose a method for executing an application present on a multi-application embedded system. This object is achieved by the fact that the method for executing an application of a multi-application embedded system, comprising an execution environment including a virtual machine comprising a language interpreter of intermediate pseudocode type, and interfaces for Application programming (API), is characterized in that, during the execution of the intermediate pseudocode of a service module, corresponding to an application, referenced in a module table, the reference to a method or an attribute in the pseudocode, coded on at least three bytes corresponding to a reference to a class internal or external to the module, a class number and a method or attribute number, a reference external to the module is interpreted by the machine virtual as a reference to the index of an API module in the table of the API module (s).

According to another particular feature, on receipt of a request for execution of a service module having an identifier, the execution environment accesses the input class of a main module comprising the main program of the system, the main module installs an instance of a special class "Access Manager", of an API module, managing access to a service module and uses a method of this class allowing to create an instance of the input class of the module service requested, via an association table of the identifier to the index of the module in an array in which the module is referenced, the instance being returned by the method to the main program.

Other features and advantages of the present invention will appear more clearly on reading the description below made with reference to the accompanying drawings in which:

- Figure 1 shows schematically the different elements necessary for loading a portable object according to a first embodiment;

- Figure 2 shows schematically the different elements necessary for loading a portable object according to a second embodiment;

- Figure 3 shows the internal representation of a module;

- Figure 4a shows the conventional diagram of a smart card;

- Figure 4b shows the system necessary for the constitution of a virtual machine on board a smart card according to the prior art;

- Figure 4c shows the structure of the classes of an application. The method will be described, in conjunction with Figures 1 to 3, without limitation, in the case of the implementation of the invention in an on-board system, for example of a specific type consisting of a smart card or an object similar laptop. The designation byte code or byte code type program covers any pseudocode or intermediate program.

The portable object constitutes, for example, a smart card and has a structure similar to that described above with reference to FIGS. 4a and 4b, and in particular comprises a RAM, ROM and EEPROM memory. The specific platform (60) and a conventional station (80) are represented in FIG. 1. The specific platform (60) has in ROM, an execution environment (RE) comprising APIs (62) and a embedded virtual machine (61) ("onplatform"). The specific platform (60) is shown in FIG. 1, as comprising all of the ROM and EEPROM memories. It should be noted that the specific platform (60) more specifically designates the execution environment (RE) and the elements present in EEPROM memory. The portable object has an Operating System (63) in ROM. The APIs (62), present in ROM memory, constitute the basic APIs of the API platform, loaded with the on-board virtual machine for the operation thereof.

The non-portable part (90) of the virtual machine comprises an intermediate pseudocode verifier (91), a converter (92) and possibly a signer (94). The signer issues a signature to validate the passage through the verifier and the converter. This signature will be verified by the portable object at the time of loading. The loading into EEPROM of applications or new APIs to complete the basic APIs is carried out by a charger which can be composed of two parts, a part excluding portable object that can be installed in the virtual machine excluding portable object (90), called downloader (93), and a part on the specific platform, called loader (68).

According to a first embodiment, the specific platform (60) comprises two special modules, an API module (65) and a main module (66). The other modules are called service modules (67). Each module corresponds to a set of packages which will be stored in the same namespace. The API platform designates the basic APIs (62) and the set of system classes that define the API module (65) or module of the API platform. The main module includes the main class defining the main program. Each module, except the API module (65), has a unique, specific class, called "Entry Class", which constitutes the access point to the module. For the main module, this "Entry Class" is the main class (CP), the one that contains a static method called "main". For service modules, it is a class with only one constructor without parameters and implementing a special public interface, called "service" defined in the API platform. The loading of an application corresponds to the loading of a service module. Each module receives a specific identifier. Such an identifier, which is called MID, can for example be a number, a character string, or an array. For example, the identifier is a character string.

When loaded into the platform, by download mechanisms separate from the virtual machine of the specific platform, the modules are given a number, between 0 and n. Thus, according to this convention, n + 1 modules at most can be present on the specific platform. The module downloader (93) with the charger (68) maintains, when loading new service modules, a table (TRM) (69) of representation of the modules. The number associated with a module is the index (IM) of this module in the table. The loader (68) also maintains a table (70) associating the index (IM) with the identifier (MID) of each module. The API module systematically receives the number 0 for the IMo index, and the main module for the IMi index the number 1. The header of each module includes an indicator allowing the loader to determine the nature of the module, "main", "service" modules or "API" module. The charger (68) can only charge the modules authorized to reside on the portable object, i.e. only the modules having a signature known to the portable object. The charger (68) therefore comprises means of verifying the signature of a module received, of comparing it with the known signature of the portable object and in the event of a negative comparison of blocking the loading. Conventionally, as defined in the prior art cited above, the source program (81) of an application is written and then compiled by a compiler (82) and then verified by the verifier (91).

The static link, made in the converter (92) by a component called linker (linker) of the converter, will resolve symbolic references by assigning

- a number (NCI) for each class of a module,

- a number (NM) for each method in a class and

- a number (NA) for each attribute in a class.

Each of these numbers (NCI, NM, NA) is between 0 and n and can thus be represented on a byte or byte. For example, each of these numbers will be between 0 and 255 (n = 255). The reference to a method or an attribute of a class will thus be coded in the linked pseudocode of the methods of the module on two bytes or bytes. The pseudocode will contain these two bytes <NCI> for the class and <NA> for an attribute or <NM> for a method.

According to FIG. 3, the internal representation of an API module (65), of a main module (66) or of a service module (67), will contain a table (TRC) of class representation; the number (NCI) associated by the linker, outside the on-board system, with each class is the index (ICi) of the representation of this class in the table (TRC). Each class also has a reference to the index (IMi) of its module. Likewise, the representation of each class contains an array of method representations (TRMe) and an array of attribute representations (TRA) belonging to the class. The number (NM), associated by the linker, outside the on-board system, to each method is the index (IMi), of the representation of this method in the table (TRMe), and the number (NA), associated by the linker, outside the on-board system, with each attribute is the index (lAi), of the representation of this attribute in the table (TRA).

As an example, we want a module to be able to refer only to its own classes and to the system classes of the API platform, the system classes corresponding to the "ClassPath" classes of a classic platform. According to the invention, to allow the distinction between a reference to a class internal to the module and the reference to a system class (or external to the module), an internal (II) or external (IE) indicator is added to the reference to a method or attribute. The resolved reference is then coded on three bytes: <IE / II> <NCI> <NM> or <IE / II> <NCI> <NA>

According to a convention, for the value n of the first byte <IE / II> the value 255 according to our example, corresponds to an internal reference <ll> to the module and any other value for the first byte corresponds to an external reference < IE> to the module.

The linker of the converter (92) of the virtual machine excluding portable object (90), first connects the API module (65), which does not have external references <IE> in its pseudocode, and produces a layout or arrangement, corresponding to a plan of symbolic names of its classes and their methods and attributes. When linking the other modules, this layout will be used to establish external references to system classes of the API module (65).

According to our convention of bytes encoding references, there can be at most 256 (n + 1) classes in the API module and 256 classes in each additional module.

When running a service module, when the virtual machine (61) finds a reference to a <NM> method or an <NA> attribute in the pseudocode, knowing the class <NCI> where this reference is found , it can directly find the <IMi> index of the module concerned, which corresponds to the external (IE) or internal (II) reference. Any external reference <IE> in the pseudo code of a service module will be systematically interpreted by the virtual machine as a reference to the API module. A service module or the main module cannot refer to the classes of any other module except those of the API module. The system classes of this API module cannot refer to the classes of a service module or the main module. The internal reference to a class of a module, corresponding to the value n for the first byte, does not require any prior knowledge of the namespace that will be assigned to the module. The fact of not a priori defining a fixed namespace during the conversion phase makes it possible to speed up the resolution of the references and to determine the namespace of a module during the loading, after the conversion phase . The virtual machine, when interpreting a reference to an attribute or method in the pseudocode, uses the three indexes <IE / II><NCI><NM> or <IE / II><NCI><NA> in cascade. The memory space of the module being determined, the index <NCI> determines the desired entry in the table of classes (TRM) of the module, then the last index <NM> or <NA> gives the desired entry in the table methods (TRMe) or the attribute table (TRA).

The API module includes a special class (64), called class "access manager" or "Access Manager", which includes a native method (getServiceInstance) whose role is to render an instance object of the input class of the module service request, from the module identifier (MID). This method uses the MID / lmi association table (70) to find out the index of the module requested in the module table (69) and then creates an instance of the input class for this module, which instance is returned by the method. According to the invention the class "Access Manager" (64) is protected by construction by a method consisting in prohibiting that this class has more than one instance. This method (getServiceInstance) belongs to the main program contained in the main module. The main module which will be activated first when using the portable object creates an instance and only one of the class "Access Manager", which allows you to use the getServiceInstance method, but prohibits any other service from creating another instance to use this method.

In operation, in the same way as on a classic platform, the execution environment (RE) accesses the input class (EC) of the main module and activates its input method (main). The main module, being the first activated, proceeds to the installation of an instance of the class "Access manager" before any other service does so, since to activate other services, the main module must already have such an instance of the access class. This simple device makes it possible to reproduce the protective effect linked to the concept of the namespace of a classic platform. The simple fact of loading a service module in the table of modules and that the presence in the pseudocode of any external reference is interpreted by the virtual machine as a reference to the API module, makes this module completely inaccessible directly by the other modules, creating thus a total firewall.

This first embodiment provides the advantages of a firewall provided by the separation of namespaces in the context of a virtual machine in two parts. However, this embodiment is not very flexible and has two drawbacks.

First, it prevents any modification or extension of the system classes with modules already preloaded. A classic "Java" architecture allows you to modify and extend the classes of the API platform without having an impact on the classes already compiled with additional modules. But in the embodiment described above, any modification of the system classes, even invisible for foreign modules, would modify the layout of the API platform and would require modifying the preloaded pseudocode of each module already linked with an earlier version of the arrangement and therefore the interpreter. Secondly, the prerequisite modules are supposed to be portable between the different platforms or on-board terminals, which imposes that each of these platforms must have the same layout as the API platform, which prohibits the use of any proprietary extension.

In order to partially remedy these drawbacks, a variant of the first embodiment consists in requiring that, in the numbering of the layout, the public classes come first before the classes in private package. In addition, public methods or public attributes come before those who are protected and those who are in private packages and in private classes. This allows you to freely add new public classes in the API module (65). FIG. 2 represents a second embodiment allowing the evolution of the API platform. The API platform is made up of several API modules (100) which can be loaded separately, instead of being made up of a single API module.

In this embodiment, the downloader (93) and the virtual machine share two tables of modules and two MID / index association tables instead of one of each, a table (101) and an association table (102 ) for API modules and a table (103) and an association table (104) for non-API modules, corresponding to the service module (67) and the main module (66). Each module has in its header an indicator indicating its "Service" or "API" nature allowing the loader to load the module in the table (101) of API modules or in the table (103) of non-API modules. This indicator is placed in the header of the module during the compilation phase by the converter. The firewall formed by the separation of the namespace is only present between non-API modules. Any external reference to a service module will be interpreted by the interpreter of the on-board virtual machine as an index to the table of the API module.

Non-API modules will be numbered from 0 to 255 at most, in the example where n = 255. 0 is for example the index of the main module (66). API modules (100) will be numbered from 0 to 254 at most, 0 being by example the index of a module called primary API, which contains all the native methods. In accordance with the convention described above, this allows at most 255 (n) different modules in the API platform. The reference to a method or attribute in the pseudocode is: "IE / II><NCI><NM / NA"

The value 255 (n) for the first byte (byte) will indicate, as in the first embodiment, an internal reference to the module. Each value other than 255 will indicate an external reference to a specific module (100) in the API module table of the API platform. After the connection has been made by the linker (92) off the platform, the pseudocode of a module comprises a header presenting a table of referenced modules used to link the current module. This table of referenced modules comprises at most 255 entries, each entry corresponding to the identifier (MID) of an API module (100). The first byte of an external reference in the pseudocode will then be an index in this table. When loading a non-API module (67, 66) on the platform, the index numbers associated with API modules (100) will be known and thus each first byte of an external reference will be replaced by the number index associated with the API module referred using the MID / IMi association table (102) of the API modules (100). This replacement is the only link operation performed on the specific platform, by the loader (68), the MID / IMi association table (102) being used only to perform this link operation.

As an example, suppose that in the pseudocode of a "TEST" service module, we have the reference to a method number 5 of the class number 7 of an API module whose identifier (MID) is " F00 ". Suppose further that "F00" is the identifier of the fourth external API module found referenced in the service module "TEST". The reference in the pseudocode is then constituted by the following three values: 3, 7, 5. The number 3 corresponds to the fourth index in the table of referenced modules present in the header of the module, coming at the head of the pseudocode, the value of this entry being the identifier (MID) "FOO". Suppose that when loading the API module "FOO, the internal index 34 has been assigned to it on the target platform in the association table (102) of the API modules. Then, the loader (68), at the using the association table (102) modifies the reference in the pseudocode of the "TEST" service module to become: 34, 7, 5.

When executing the pseudocode of a module, a reference external to the module is systematically interpreted by the virtual machine as an entry in the API module table. The modules in the non-API module table remain invisible to each other as well as to API modules. This simple device makes it possible to reproduce the protective effect linked to the concept of the namespace of a classic platform. The simple fact of loading a module into the non-API module table makes it completely inaccessible directly by the other modules, thus creating a total firewall.

The table (101) of API modules includes a specific module (105), called "API Access" module which includes a native method (getServiceInstance) in a class "access manager" or "Access Manager" whose role is to render an instance object of the input class of the requested service module. This method uses the MID / IMi association table (104) to find out the index of the service module requested in the table (103) of non-API modules and then creates an instance of the input class of this module which is returned by the method to the main program. The recommended security policy is to make the "Access Manager" class a protected class whose constructor and methods are declared protected. In addition, the "API Access" module (105) includes a protection consisting in prohibiting that the "Access Manager" class has more than one instance. This method is reserved for the main program contained in the main module (66). The main module which is activated first creates an instance of the Access manager module, which allows it to use the getServiceInstance method, but prohibits any other service from creating another instance to use this method. Thus the main module can create instances of services. Several methods can be used to obtain this protection consisting in prohibiting that the "Access manager" class has only one instance. The constructor of the class can for example block the request to create an instance when one already exists and throws a security exception. In operation, the execution environment (RE) accesses the input class of the main module (66) and activates its input method (main). The main module being the first activated, proceeds to the installation of an instance of the "Access Manager" class of the Access module before any other service does so.

In order to allow a service module to activate another service module, this strict security policy can be modified by adding to the "Access Manager" class of the API Access module (105) public classes allowing any module to make requests there. These requests will be processed and controlled by the single instance created by the main module. These public classes include a static method for obtaining the single instance. A module having access to the instance object of the "Access Manager" class will be able to activate another service module and use it, but it will not be able to directly reference its classes, methods or attributes without being spotted by the virtual machine , since any external reference in the pseudocode is an internal reference to the module or an external reference to an API module.

For a simple implementation of this solution, it is necessary not to have circular references among the API modules. Consequently, the transitive closure of the "refers to" relation must be a strict partial order on a set of modules. It is thus possible to conceive in the linker of the converter (92) a simple strategy for linking and producing the arrangement of the API modules by first treating the elements minimums not yet linked. It is possible to follow the same strategy based on a partial order for the download of API modules, so that when downloading an M module, all the modules to which it refers have already been downloaded and a number for them have been assigned. The assignment of the internal index on the target platform is done by the module loader (68) by assigning the index n-1 to the API of order n. An API module cannot refer to another API module with a higher index.

The use of this double array of modules (101, 103) and association table (102, 104) system makes it easy to replace a single API module with several API modules that can be loaded separately. The replacement of a single API module by several API modules makes it possible to extend the API platform with new modules, without modifying the assembly of modules already loaded, without changing the security offered by firewalls. Of course, these two embodiments are not compatible; the modules must be preloaded specifically for one or the other of the embodiments, the pseudocode relating to one of the embodiments not being portable on a platform implementing the other embodiment. In addition, the interpreter of the virtual machine differs from one embodiment to another. In the first embodiment, the virtual machine only manipulates a single table and an association table: the first byte of a reference will be interpreted by the virtual machine as an internal reference for any value equal to n and as a external reference to the single API module for any value other than n. In the second embodiment, the virtual machine manipulates two tables and two association tables: the first byte of a reference in the pseudocode will be interpreted by the virtual machine as an internal reference to the module for any value equal to n and any a value other than n will be taken directly as an index in the API module table. In both embodiments, the interpreter of the virtual machine comprises means for comparing the first byte of the three bytes of coding of a reference to a method or to an attribute. with a determined value n to decide whether it is an internal or external class of the module. The numbering of the API modules can be determined at the time of loading to definitively and very simply fix the external references in the pseudocode. The same mechanisms are used to handle both types of modules, although the way they are used and the security provided is quite different. Any module can freely access API modules since their classes are system classes. The use of the modular approach is used with service modules to provide a rigorous firewall to protect these modules from direct access.

The method according to the invention can be carried out on all types of portable object having low resources, such as for example, 16 KB of ROM memory, 8 KB of EEPROM memory and 256 k of RAM memory.

Other modifications within the reach of the skilled person are also part of the spirit of the invention.

Claims

1. Method for loading applications on an embedded system comprising an execution environment including a virtual machine comprising a language interpreter of intermediate pseudocode type, application programming interfaces (API), from a station on which the application source code is written, compiled in pseudocode by a compiler (82), checked by a verifier (91), converted by a converter (92), and loaded by a loader (93, 68), characterized in what - the conversion includes the realization of the static link of a plurality of sets of packages intended to be stored in the same namespace on the embedded system, called modules, by assigning an identifier to each module (MID), and a reference number for each class (NCI), for each method (NM) and for each attribute (NA) encapsulated in the classes of the module,

- the reference to a method or an attribute, in the linked pseudocode of a module, being coded on three bytes constituted by an indicator indicating the reference to an internal (II) or external (IE) class of the module, the number of the class (NCI) and either the method number (NM) or the attribute number (NA),

- the modules are one or more application programming interface modules comprising system classes or service modules each corresponding to an application, a reference (IE) to an external class being systematically interpreted by the virtual machine as a reference to an application programming interface module.

2. A method of loading applications on an on-board system according to claim 1, characterized in that the loading of the modules on the on-board system comprises storing on the one hand at least one table (69, 101, 103) of representation of the modules, the number (IMi) associated, by the linker between 0 and n, with a module constituting the index of said module in the table, and on the other hand of a table (70, 102, 104) memorizing the association of the index of the representation table with the identifier (MID) of said module, said table and the table being in non-volatile programmable memory, an external reference (IE) to an external module in the pseudocode being interpreted by the interpreter of the virtual machine as constituting an index of access to the module equivalent to that of the table of modules.

3. A method of loading applications on an on-board system according to claim 2, characterized in that the loading comprises memorizing, for each module, a representation table (TRC) of its classes, comprising a reference to the index of its module and, for each class, a representation table (TRA) of attributes and methods (TRMe).

4. A method for loading applications into an embedded system according to claim 2, characterized in that the modules are referenced in a single array of modules, the system classes are contained in a single API module, any reference to an external class in the pseudocode different from n will be interpreted by the virtual machine as a reference to said API module.

5. A method of loading applications into an embedded system according to claim 4, characterized in that the classes being declared public, or in private package, the attributes and methods being declared protected, in private package or in private class, the numbering classes are carried out according to the order public classes then classes in private packages, the numbering of the attributes or methods is carried out by the converter (92) according to the order attribute or method public, protected, in private package and in private class.

6. A method of loading applications onto an on-board system according to claim 2, characterized in that the system classes are contained in several API modules that can be loaded separately, the loader (68) maintains two programmable non-volatile memory module representation tables and two corresponding MID / lmi association tables, one for API modules and the other for non-API modules, the loader loading the modules into one of the two tables depending on the nature of the module specified in its header, any external reference to a module in the module table being interpreted as a reference to the index of the API module.

7. A method of loading applications onto an embedded system according to claim 6, characterized in that the static connection of a module is carried out so that the reference to a class external to a non-API module in the intermediate pseudocode is an index in a table of the header of the module, each entry of which is an identifier (MID) of a referenced API module, the loading of said module on the target platform comprising the replacement of said reference by the number of the API module index obtained from the MID / IMi association table (MID) identifier of the API modules.

8. Embedded system comprising a virtual machine and an API platform including application programming interfaces, a fixed non-volatile memory, a programmable or modifiable non-volatile memory, and a random access memory, characterized in that the non-volatile memory programmable includes at least one API module comprising system classes and service modules, at least one module representation table (TRM), in which the modules are indexed and a table (70, 104) associating the index (IM) a module of the representation table with the identifier (MID) of said module, each module comprising a table of representation of the classes (TRC), in which the classes are indexed and in which each class has a reference to the index ( IM) of its module, each class comprising a table of representation of attributes (TRA) and methods (TRMe), in which the attributes and methods are indexed, the reference to a met thode or an attribute being coded on at least three bytes (bytes) corresponding to a reference to a class internal (II) or external (IE) to the module, a reference external to the module constituting the API module index in the module table, a class number (NCI) corresponding to the class index in the module class representation table, and a method number (NM) or attribute (NA) corresponding to the index of the method or attribute in the representation table of methods or attributes of the module class.

9. On-board system according to claim 8, characterized in that it comprises means for comparing the first byte of the three reference coding bytes to a method or to an attribute with a determined value n to decide whether it is of an internal or external class.

10. Embedded system according to claim 8, characterized in that it comprises a main module comprising the main program of the system.

1 1. Embedded system according to claim 8, characterized in that the classes are indexed according to the order public classes then classes in private packages, and the attributes or methods according to the order attribute or method public, protected, in private package and in private class.

12. On-board system according to claim 11, characterized in that the programmable non-volatile memory comprises several API modules comprising system classes, two representation tables (101, 103) of the modules, one for the API modules and the other for non-API modules, and the main module, and two MID / IMi association tables (102, 104) each corresponding to a module representation table.

13. Embedded system according to claim 10, characterized in that it comprises an access manager class "Access manager" of an API module (105) comprising a method for creating an instance of a service module, by through the main module, said class having protection preventing it from having more than one instance.

14. Method for executing an application of a multi-application embedded system, comprising an execution environment including a virtual machine comprising an intermediate pseudocode type language interpreter, and application programming interfaces (API), characterized in that, during the execution of the intermediate pseudocode of a service module, corresponding to an application, referenced in a module array, the reference to a method or attribute in the pseudocode, coded on at least three bytes (bytes) corresponding to a reference to an internal (II) or external (IE) class of the module, a class number (NCI) and a method (NM) or attribute (NA) number, a reference external to the module is interpreted by the virtual machine as a reference to the index of an API module in the table of the API module (s).

15. Method for executing an application of an on-board multi-application system according to claim 14, characterized in that, on receipt of a request for execution of a service module having an identifier (MID), the execution environment accesses the input class of a main module comprising the main program of the system, the main module installs an instance of a special class "Access Manager" of an API module, managing access to a service module, and uses a method of this class making it possible to create an instance of the input class of the requested service module, by means of an association table of the identifier with the index of the module in an array in which the module is referenced, the instance being returned by the method to the main program.