WO2002008897A1

WO2002008897A1 - Protocol for message exchange between applications implanted on an onboard system, and corresponding onboard system

Info

Publication number: WO2002008897A1
Application number: PCT/FR2001/002364
Authority: WO
Inventors: Christoph Siegelin; Alain Boudou
Original assignee: Cp8_Technologies
Priority date: 2000-07-24
Filing date: 2001-07-20
Publication date: 2002-01-31
Also published as: FR2812101A1

Abstract

The invention concerns a protocol for message exchange between applications implanted on an onboard system equipped with an operating system (OS), and the corresponding onboard system. It consists in at least transmitting (1000) a request call from the master application to the operating system, request including a specific input/output command addressed to the slave application, deactivating the master application and activating the slave application (1001), transmitting (1002) to the activated slave application the input/output command from the operating system (OS), executing (1003) at the activated slave application the input/output command, returning (1004) from the slave application, a reply to the operating system. The invention is useful for secure management of applications implanted on multiple application smart cards.

Description

PROTOCOL FOR EXCHANGING MESSAGES BETWEEN APPLICATIONS IMPLANTED ON AN ON-BOARD SYSTEM, AND ON-BOARD SYSTEM

CORRESPONDING

Current on-board systems, or portable objects, in particular microprocessor cards, also referred to as smart cards, tend to fulfill increasingly complex functions, due, in particular, to the implementation of multiple application programs, these smart cards being designated by • "mul ti -application" cards. These multiple implantations are made possible, on the one hand, by the miniaturization of electronic circuits, fineness of etching of silicon, and consequently, correlative increase in the memory capacity of smart cards, and, on the other hand, by increase in the computing power of central processing units. A structural layout of a memory card is shown in FIG. Referring to FIG. 1 a, it is recalled that the portable object, constituted by a microprocessor card and referenced 10, comprises, in a conventional manner, input / output circuits, denoted I / O and referenced 12, making it possible to communicate with a terminal such as a bank transaction terminal for example, information processing resources, referenced 14, constituted by a microcontroller, these information processing resources being connected to the input / output circuits 12. In addition, a non-volatile memory 18 is provided, which consists of a programmable memory 18 _a and a memory of ROM type, or read-only type memory 18 _b . These two memories are connected to the microprocessor 14. Finally, a memory of the working memory type, RAM memory, bearing the reference 16, is also connected to the microprocessor 14. The aforementioned connections are understood to be a connection by BUS of conventional type.

An operating system OS is provided, which can be installed in non-volatile memory 18. Finally, and in certain cases only, the portable multi-application object can comprise, as shown in FIG. 1 a, an encryption calculation unit. / decryption S, bearing the reference 20, itself connected to the microprocessor 14. The structural elements of the portable multi-application object, object of the present invention, will not be described in more detail because they correspond to elements known from the state of the art.

In a variant, the microprocessor is replaced - or at least supplemented - by logic circuits implanted in a semiconductor chip. Indeed, such circuits are capable of carrying out calculations, in particular of authentication and signature, thanks to wired, and not microprogrammed, electronics. They can in particular be of the ASIC type (from the English "Application Specifies Integrated Circuit").

In a known architecture of a multi-application smart card, as represented in FIG. 1b, several independent applications coexist on the same card, in the non-volatile memory area thereof. this. This type of architecture usually includes the OS operating system and the applications designated by Appli and Appl ₂ in the above-mentioned figure. Optionally, the aforementioned architecture can include a virtual machine, such as a dedicated JAVA (registered trademark) virtual machine, also called JCVM.

The operating system OS is nothing other than a generic program which provides intercommunication services to the installed applications, services such as the management of input / output messages exchanged with a terminal for using the card, such as such as a payment terminal or the like, as well as access to the memory fitted to the on-board system. The management of input / output messages is normally carried out according to the APDU protocol for Application Protocol Da ta Uni t, defined by standard ISO 7816. In the context of this protocol, it is recalled that the read / write invitation command comes from outside the on-board system, that is to say from the aforementioned use terminal. The different fields of an APDU command are represented in FIG. Ld, these fields designating: CLA: instruction class INS: instruction code Pi, P ₂ : instruction parameters

Lcf: length in bits of the data field Df: data field

Lef: maximum number of bits in the response data field. SWi, S ₂ : order status, order qualifier. The Appli or Appl _{2 applications} are specific programs which each perform a particular task or function, such as the functions of an SME electronic purse, system for access to pay-TV programs, or others.

For this purpose, the Appli or Appl _{2 applications} use the services of the operating system. The APDU commands, input / output commands, coming from the user terminal, are processed by the OS operating system and by the applications. All APDU commands are examined by the operating system, some being filtered and others being delivered to applications, according to a criterion of use.

In fact, to activate, that is to say to make functionally active, an application located on the card, the program installed on the user terminal sends to the card, inserted in the latter, a specific APDU command for selection, SELECT_APDU. The OS operating system examines this command and activates the corresponding application. Then all the commands that follow are directly delivered to the active application by the OS operating system. In FIG. 1b, the application Appl ₂ is represented as the active application by the double arrow illustrating the one-to-one mapping of the aforementioned active application and the OS operating system. This process and the above one-to-one correspondence link terminate when the OS operating system detects again a command for selecting another application, distinct from the active application, after which the operating system deactivates the active application and activates this other application. In some cases, in particular with a view to increasing the functionality of a plurality of applications installed on the same smart card, it is desirable that the active application can use another application, not active, installed on the menu. This is for example the case when an application for access to pay-TV programs, P_TV, must use an electronic purse application, PME, to make a payment. The application for access to pay-TV programs must then regain control, in order to conditionally manage access to the television program chosen by the user, depending on whether the aforementioned payment is valid or not.

Such an operating mode therefore requires that the application, active, can activate the other application, slave application, and that a shared communication channel (sharable interface in English language) is installed between the master application and the slave application. The figure shows, by way of example, the installation of such a communication channel. In a manner known as such, the activation of the slave application by the master application, as well as the installation of the shared communication channel, consists in establishing such a shared channel, or shared interface, from available memory on the card smart. A known solution corresponds to a shared JavaCard.2.1 interface. For a more detailed description of the shared interface JavaCard.2.1, one can usefully refer to the specifications: - JavaCard 2.1 runtime environment JCRE specification final revision 1.0 of February 24, 1999. Author: Sun Microsystems Incorporated Palo Alto California. USA. JavaCard 2.1 application programming interface final revision 1.0 of February 24, 1999. Author: Sun Microsystems Incorporated Palo Alto California. USA

The major drawback of the aforementioned solution consists in the fact that it requires an additional particular interface, consuming memory, between the master application and the slave application, the shared interface in the case of the JavaCard.2.1 specification. This shared interface is therefore distinct from the main interface of the applications installed with the OS operating system vis-à-vis the terminal, main interface constituted by the set of input / output commands, APDU commands, understood by each application. .

For this reason, a given existing application cannot be used as a slave application as long as it has not been modified in order to integrate the sharing interface. It is substantially the same with regard to the master application, and, consequently, the installation of a bidirectional shared interface in which two applications can also become master or slave respectively appears hypothetical. Indeed, modifying an existing application is the most often very expensive, or even difficult to carry out, especially when the application in question has already been subject to security certification, any modification rendering the security certificate obsolete. In addition, the application activation mechanisms are limited to a specific programming model, for example the JavaCard language, and do not however allow interactions or communication between applets, established in Java bytecode, and native applications, established in native code.

The object of the present invention is to remedy the drawbacks of shared interfaces of the prior art, by emulating a selection operation, between a master application and a slave application.

Consequently, the subject of the present invention is a protocol for exchanging messages between applications installed on an on-board system, via the main interface and input / output commands, APDU commands, managed by the system. OS.

Another object of the present invention is, also, the implementation of a message exchange protocol between applications installed on an embedded system, such as a smart card, in which the slave application is managed by the external input / output commands, the master application playing substantially the role of an external use terminal. Another object of the present invention is, also, the implementation of a message exchange protocol between applications installed on an embedded system, such as a smart card, in which any implanted application is likely to be selected as master application, this master application itself being able to enter into communication with any other separate application, thus constituting, with respect to this master application, a slave application.

Another object of the present invention is, finally, the implementation of a secure protocol for exchanging messages between applications installed on an embedded system provided with an operating system, such as a smart card, as well than that of any on-board system or corresponding smart card.

The message exchange protocol between applications installed on an on-board system provided with an operating system, object of the present invention, this operating system allowing, by input / output command, the exchange of messages from data and main interface command between a master application active among these applications, the other applications being inactive, and an external system via this main interface and input / output commands, is remarkable in that it consists at least in transmitting, from the master application, to the operating system, a call request from an inactive slave application, this call request comprising at least one input / output command specific intended for this slave application, to deactivate the master application and to activate this inactive slave application via the operating system, to transmit to the activated slave application the input / output command intended for this slave application , via the operating system, to execute at the level of this activated slave application the input / output command intended for this slave application, to return from this slave application an acknowledgment message and / or response, to the operating system.

The protocol, object of the invention, finds application in the management of all types of applications located in the non-volatile memory of an embedded system, such as a smart card, in particular.

It will be better understood on reading the description and on observing the drawings in which, in addition to FIGS. 1a to 1d relating to the prior art;

- Figure 2a shows, by way of illustration, a general flowchart representing the sequential implementation of the steps of the protocol, object of the present invention; FIG. 2b represents, by way of illustration, the path for the exchange of APDU commands by means of a main interface and of the operating system OS in the context of a multi-application card architecture, during implementation of the protocol object of the invention illustrated in FIG. 2a; - Figure 2c shows, by way of illustration, a successive implementation of the protocol object of the present invention between different applications installed in a multi-application card; - Figure 3a shows, by way of illustration, an advantageous variant implementation of the protocol object of the present invention in the case where the master application is not suspended but deactivated; FIG. 3b represents, by way of illustration, the path for exchanging commands, APDU commands and OS commands, by means of a main interface and of the operating system within the framework of a multi-application card architecture, during the implementation of the object of the invention protocol illustrated in Figure 3a;

- Figure 4a shows, by way of illustration, urxe ^~ -vax ± aτrte— de — mi-se — en — oeuvre-re — du— ro-toeoie — obj-et— e — 1-a present invention, in which a procedure for authenticating the request for calling the slave application and this slave application by the master application is introduced;

- Figure 4b shows, by way of illustration, a particular mode of implementation of the authentication procedure according to a variant distinct from that described in Figure 4a;

- Figure 5 shows, by way of illustration, the layout of a portable object or embedded system, such as a smart card, in accordance with the object of the present invention. A more detailed description of the message exchange protocol between applications installed on an on-board system, in accordance with the object of the present invention, will now be given in connection with FIGS. 2a, 2b and the following figures.

In general, it is recalled that an on-board system designates any computer system provided with an operating system, such as a smart card for example, a PCMCIA card or the like.

This operating system allows, by input / output commands, the exchange of data messages and main interface commands between a master application, active among these applications, the other applications being inactive, and an external system such that for example a terminal for using this on-board system by means of an input / output interface circuit such as the circuit 12 shown in FIG.

In general, it is considered that, in all of the applications installed in the on-board system, at each instant, none of the applications is active, when the on-board system or the smart card in question are not used, or , on the contrary, one of the applications is active when the on-board system is inserted in a user terminal, the other applications being considered inactive. It is understood in particular that the active or inactive nature of each application is managed by the operating system OS as a function of the use of the above-mentioned on-board system or smart card.

Consequently, the protocol which is the subject of the present invention will first of all be described in connection with FIGS. 2a and 2b in the case where the system multi-application embedded considered is used, that is to say inserted into a user terminal.

Referring to FIG. 2a, it is indicated that this on-board system being inserted in a user terminal, the user terminal addresses, via the operating system OS and of course the aforementioned main interface, a APDU type command for the attention of the master application, i.e. the application for which the user terminal is designed. Following the reception of this APDU command, referenced oi, the considered master application which has been activated performs the processing of this command in step o ₂ shown in FIG. 2a. The message exchange protocol between applications in accordance with the object of the present invention is then implemented in the following manner.

With reference to FIG. 2a, this protocol consists at least, in a step 1000, of transmitting from the master application to the operating system OS, a request for calling an inactive slave application, this request d call comprising a specific input / output command, called ADPU command, intended for the slave application considered.

The above-mentioned step 1000 is then followed by a step 1001, which consists, by means of the operating system OS, in deactivating the master application and in activating the slave application, inactive, by means of this same operating system. The deactivation operations, respectively activation of the master and slave applications are carried out in a conventional manner in accordance with ISO standard 7816 and, for this reason, will not be described in detail.

The above-mentioned step 1001 is then followed by a step 1002 consisting in transmitting to the activated slave application the input / output command, that is to say the APDU command intended for this slave application, via of the OS operating system.

Following reception of the APDU command by the slave application after execution of step 1002, this step is followed by a step 1003 of execution, at the level of the slave application considered activated, of the input command / output or ADPU command mentioned above intended for this same slave application. Step 1003 of processing the command received by the slave application in question is then followed by a return step, from this slave application, of an acknowledgment message and / or of a response message to the OS operating system. This step is denoted 1004 in FIG. 2a. Acknowledgment and response messages can be combined. Of course, it is understood that the protocol object of the present invention then allows a resumption of the operations carried out by the master application under the usual conditions to those defined by the execution of the main interface commands exchanged between the master application and the user terminal. By way of nonlimiting example, as shown in FIG. 2a, it is indicated that for this purpose, step 1004 can then be followed by a step 1005 according to which the operating system deactivates the slave application and reactivation, that is to say restoration, of the master application, to continue the exchange operations with the user terminal.

Step 1005 can then itself be followed by a step 1006 consisting in transmitting to the master application thus reactivated the response from the slave application so as to carry out the processing of this response at the level of the master application, as shown in step 1006. The aforementioned step 1006 can then be followed by a response step 1007, that is to say sending an APDU response, by the master application to the terminal d use, as a function of the results of the processing of the response of the slave application by the master application carried out in step 1006.

A more detailed description of the paths taken by the various exchanges of data messages and / or of commands exchanged during the implementation of the protocol object of the present invention will now be given in connection with FIG. 2b.

It is considered by way of nonlimiting example that the use terminal is an access terminal to a television receiver for example, comprising the equipment necessary to authorize or not the access to pay television broadcasts. The on-board system used consists, for example, of a smart card, in which two applications are installed, an electronic purse application PME and an application for accessing pay-TV programs, denoted P_TV. In general, this application manages conditional access to the broadcasting of the television program taking into account the valid payment made of the corresponding access rights. It is considered in particular that in this given example, the on-board system is inserted into the user terminal, that the master application upon insertion is the P_TV application and that the slave application is the PME application. Given these elements, the operations or steps oi and o ₂ are carried out by the exchange of APDU commands between the operating system, the master application P_TV and the terminal. The access paths taken are noted (1) in Figure 2b. Following the execution of steps θι and o ₂ , steps 1000 to 1004 are then carried out between the master application P_TV, the operating system OS and of course the SME slave application along the path (2). It is understood in particular that the exchanges of the aforementioned messages can, if necessary, be bidirectional on the path considered, as will be described later in the description. The aforementioned message exchange is then carried out by means of specific input / output commands, which constitute APDU commands. dedicated to applications and which, for this reason, are denoted APDU *.

Of course, steps 1005 and 1006 shown in Figure 2a are carried out via the path (2) as shown in Figure 2b. Finally, step 1007 is performed again via the path (1), that is to say by means of the implementation of conventional ADPU commands within the framework of the environment of the main interface. Regarding the implementation of the steps

1005 and 1006 and of course then the implementation of step 1007, it is indicated that steps 1005 and 1006 can be implemented vis-à-vis, not only the initial master application Ai, which is restored in its active state, but also of another previously inactive application, A ₂ , A ₃ , which can be made active successively via the operating system OS. Thus, as shown in FIG. 2c, one or more other inactive applications A ₂ , A ₃ , distinct from the initial master application A and from the active slave application A ₄ ,. can be made active successively in order to carry out various data processing operations, the global response given by the last, the active slave application A ₄ then being transferred to the initial master application A ₃ and the corresponding successive global result, at the terminal d use in accordance with steps 1005, 1006 and 1007 above via the applications A ₂ Ai made successively active. It is understood in particular that the application Ai being selected as application master by the terminal by an APDU command, the operating system OS can then, at the request of the master application Ai, select the application A ₂ then, in turn, the applications A ₃ and A ₄ , and finally return successively to the master application Ai, via the applications A ₂ , A ₃ , the return to the master application Ai having been carried out by means of specific APDU commands denoted APDU *. The return of the overall result to the terminal is of course carried out by means of an APDU command.

A specific example of implementation of the APDU * commands, that is to say specific APDU commands, will now be given below in the description. In general, the master application chosen first calls on the services of the operating system OS to indicate its wish to call the slave application, the PME application previously mentioned in connection with FIG. 2b. The call request for the inactive slave application can then take the following form:

isoStatus = callS lava Application (AID, isoHeader, dataln, * dataOut) (1)

In the command constituting the aforementioned call request, AID designates the identifier of the slave application chosen in accordance with the provisions of standard ISO 7816, isoHeader and dataln contain the ADPU command that the master application wishes to send to the application slave and the argument * dataOut is a pointer to a memory area such that the RAM memory area 16 represented in FIG. 1a, the area in which the operating system OS is able to store the data of the response of the ADPU type provided by the slave application. The ISO status returned by the slave application is returned in the isoStatus variable.

Following the aforementioned call request, the OS operating system activates the slave application in the same way as if a selection by the user terminal had occurred by the path (2) shown in Figure 2b. the operating system OS transmits the APDU command to the slave application, the PME application shown in FIG. 2b above. The slave application executes the command, then returns to the OS operating system, the master application then being reactivated by the latter. The scenario can then be repeated to form a sequence where, where appropriate, a series of calls to master applications, respectively slave as shown in Figures 2c, with successive return of the final response to the terminal of use.

As regards the mode of implementation of the protocol, object of the present invention, as shown in FIGS. 2a, 2b and 2c, it is indicated that this mode of implementation corresponds to an alternative embodiment designated by parallel application / stacked. During the call request previously mentioned in the description and designated by callSlaveApplication, the master application is suspended until the return of the slave application. These operations correspond to steps 1001 and 1005 of the Figure 2a. Under these conditions, the parallel management of the applications results from the allocation of a calling function, respectively of a called function. The master application is given a calling function and the slave application is given a called function.

However, such an operating mode requires the implementation of a management system for concurrent multitasking applications, while the occupation of the RAM 16 is potentially significant.

An alternative implementation of the protocol object of the present invention may consist of a sequential implementation. In this alternative embodiment, the call to the callSlaveApplication command becomes effective only after the master application has ended by returning to the OS operating system. The operating system OS then activates the slave application and when it ends, the aforementioned operating system reactivates the master application by calling the latter on a launch point in memory specifically provided for this purpose.

In these conditions, the call to the slave application then takes the following form:

error = callSlaveApplication (AID, isoHeader, dataln). (2)

The isoStatus ISO status and the dataOut response data are then communicated by the operating system to the master application when the latter is reactivated, according to the APDU command: masterApplication.slaveCallBack (isoStatus, dataOut). (3)

The mode of implementation corresponding to sequential applications is simple to carry out and the occupancy of the RAM 16 is low. However, a specific launch point in memory must be provided in the master application and the transition between master application and slave application is slower, due to the necessary backups in non-volatile memory.

The process of implementing the protocol which is the subject of the present invention for the sequential applications described above is illustrated by the flow diagram of FIG. 3a.

In the aforementioned flow diagram, it is indicated that the same references naturally designate the same steps as in the case of FIG. 2a.

However, and in a particularly advantageous manner, it is indicated that step 1000 is then constituted by a sub-step 1000 _a and a sub-step 1000 _b , the sub-step 1000 _a corresponding to a sub-step in which the application master saves its state in memory, while sub-step 1000 _b corresponds to the call by the master application of the OS operating system to send an APDU command to the slave application considered.

Likewise, step 1005 is subdivided into two sub-steps, 1005 _a and 1005 _b , sub-step 1005 _a consisting in deactivation of the slave application by the OS operating system and in a reactivation of the master application, this sub-step, upon reactivation of the latter, being followed by sub-step 1005 _b in which this master application restores its state from the RAM 16, state saved in the sub- step 1000 _previously cited.

In FIG. 3b, in addition to the paths (1) and (2) previously mentioned in FIG. 2b, there is shown an additional path (3), which corresponds to the operations for saving the state of the master application in random access memory. , respectively to restore the state of the master application from this RAM 16. These operations can be carried out using APDU commands existing in the environment of the main interface and, for this reason, the corresponding path is shown in dotted line.

While the exchange of messages between applications installed on the same embedded system, in accordance with the protocol object of the present invention, is of major interest and has the effect of increasing the functionality possibilities of these embedded systems, the uncontrolled exchange of these messages is likely to give rise to risks of abuse, in particular in the event of intrusion and identity theft, for example with a view to fraudulent use of one or other of the applications. This is particularly the case with regard to the fraudulent use of an application such as the SME application or any application by which. fiduciary values are processed. In order to reduce or eliminate the corresponding risk, and in accordance with a particularly remarkable aspect of the protocol object of the present invention, the transaction between the master application and the slave application, or, if necessary, between any master application and any application slave, transaction constituted by steps A, B and C, that is to say steps 1000, 1001, 1002 of FIGS. 2a or 3a previously introduced in the description, may advantageously include a procedure for authenticating the transaction between master application and slave application.

The procedure for authenticating the transaction between master application and slave application can be carried out, using at least one key and a cryptography system via an authentication procedure for the call request. of the slave application inactive by the master application, for example, as will be described below.

Upon authentication of the call request, the true value of the authentication, the transaction is continued. Otherwise it is interrupted.

For this purpose, as shown in Figure 4a, step 1000 of Figure 2a or step 1000 _b of Figure 3a may be followed by a step 1000ι 1000 _b respectively ι authentication of the call request of the slave application by the master application. A particular embodiment of the authentication step shown in FIG. 4a can consist, as shown in Figure 4b, to perform a signature operation, respectively signature verification, elements for authenticating the origin of the call request and thus secure the above transaction.

For this purpose, as shown in FIG. 4b above, with each application installed on the on-board system, a private signature key, denoted K _PRi , is associated with a public signature verification key, denoted K _Pui , the index i designating an identifier of the implanted application considered. Thus, each application, master or slave, is associated with a set of signature keys, respectively of signature verification. The authentication process then consists, at the level of the master application, in generating a random value, denoted RV, then in transmitting by means of an input / output command of the specific APDU command type, APDU *, this value random to slave application.

The aforementioned step A is then followed by a step B consisting in calculating, at the level of the slave application, from the private key associated with this slave application, the aforementioned private key K _PRi , a signature value of the RV random value received by the latter.

The signature calculation operation then verifies the relationship:

SG = f _K Ri (RV)

relationship contained in step B of Figure 4b. In the previous relation, SG represents the calculated signature value and fκp _R i denotes the signature calculation operation of the random value RV.

After calculating the aforementioned signature value, this value is transmitted to the master application by means of an acknowledgment or response message containing the aforementioned signature value.

Step B is then followed by a step C consisting in carrying out, at the level of the master application, a verification of the aforementioned signature value by means of the public key K _PU i associated with the private key of the slave application author of the aforementioned signature value. The signature verification operation verifies the relationship: V (SG) = g _KP ui (SG)

relation of step C of FIG. 4b.

Of course, the passage of the successive stages A, B, C includes the transmission of the activation process from the active application to the inactive application, these operations being denoted T and represented by a dashed line between the steps A, B and C above. These activation / deactivation operations of each application are known as such and, for this reason, will not be described in detail.

Of course, the authentication process implemented within the framework of the protocol object of the present invention is not limited to the procedure for authenticating the call request of the inactive slave application by the master application previously described. . In particular, it is also possible to implement an authentication procedure call request to the master application, or if appropriate, a logical combination of these procedures ¹ authentication. In such a case, however, although this authentication procedure or this combination of authentication procedures is not described, it is indicated that it is advantageous to use two pairs of keys. As regards the implementation of the authentication procedures from at least one cryptographic key, it is advantageously possible to use either an asymmetric cryptographic system with a public key and a private key, or a symmetric cryptographic system with a secret key. The cryptographic system used allows the implementation ^'of one of the encryption process / decryption, calculation and verification of signature or exchange values authentication. A more detailed description of an on-board multi-application system constituted in a nonlimiting manner by a smart card conforming to the object of the present invention will now be given in connection with FIG. 5. In FIG. 5, the same elements that those represented in FIG. 1a bear the same references, the additional elements necessary for implementing the protocol object of the present invention having been distinguished only. First, in order to allow the implementation of the protocol which is the subject of the present invention, the embedded system object of the invention as shown in FIG. 5 includes, integrated into the operating system, a set of specific input / output instructions, denoted I * _APD U comprising at least the APDU * instructions previously mentioned in the description and in particular a call request, from an active master application, from an inactive slave application, this call request corresponding for example to the command given according to relation (1) or according to relation (2 ) mentioned earlier in the description. In addition, a command for transmitting the response data via the OS operating system to the master application when the latter is reactivated can be provided in the command set, according to relation (3). previously mentioned in the description.

In addition, as shown in FIG. 5 above, the on-board system is advantageously provided with means of signature calculation and signature verification 20 previously mentioned in the description. In order to implement the protocol object of the present invention, each on-board system as shown in FIG. 5 further comprises a set of private signature key and public signature verification key, the keys Kp _r i and Kpui , associated with each application installed in the embedded system. Only one secret key can, if necessary, be provided. To secure transactions between applications as much as possible, not just private keys associated with each application, but also the public keys associated with the latter, where appropriate the secret keys, are stored in a non-volatile memory area with secure access of the on-board system. It is understood in particular that in order to carry out the operations of calculation of signature and verification of signature previously described, each application concerned naturally calls, via the operating system, to the aforementioned secure memory areas and, of course , to the signature calculation and verification circuits 20 according to the conventional processes for accessing this secure information, as defined in the ISO 7816 standard.

In the example described above of exchanges of messages between two applications, an application for accessing pay-TV programs and an electronic purse application, the P_TV application must prove to the electronic purse application his identity before, of course, the latter allows any debit and direct debit transaction in the electronic purse, and vice versa.

For the implementation of the authentication processes, that is to say of providing proof of identity, the private key and public key mechanisms can be used. Among these, a particular embodiment consists in using the RSA system, the slave application using the private key to sign the random value generated and transmitted by the master application and the master application then using the public key associated with the private key associated with the slave application to perform the aforementioned signature verification.

The implementation of the authentication process between two applications such as the aforementioned applications, then calls on APDU * commands which are strictly identical to those which are usually used for authentication between the smart card and the terminal. 'use. It is further indicated that the authentication process is not necessarily separated from the other commands. Indeed, it is also possible to sign all APDU * commands by adding an authentication code in the data field. Under these conditions, the receiver of the order, for example the electronic purse playing the role of slave application, can then ascertain the identity of the issuer of the order, the master application constituted by the P_TV application upon receipt of the latter's call request.

We have thus described a protocol for exchanging messages between applications installed on an embedded system and an embedded system allowing the implementation of such a particularly efficient protocol, insofar as the implementation of the latter does not require any knowledge of a private and specific external interface, the implementation of this exchange of messages being carried out only from the set of external APDU commands, that is to say from the commands of the main interface. In particular, under these conditions, and according to a particularly remarkable aspect of the implementation of the _. protocol object of the present invention, the slave application may not be modified. In addition, applications of a different nature, that is to say applications whose programming language or design are different, can be activated.

In addition, the reuse of the main interface and the APDU commands allows the factoring of the code and therefore a reduction in the volume of codes necessary for the multiplication of the functions of any on-board system of conventional type.

Due to the reduction or elimination of the modifications introduced at the level of each application, the certification process of all the embedded systems and of the applications installed on the latter is then greatly simplified. Different variants of implementation of the protocol and embedded systems which are the subject of the present invention can be envisaged. In particular, the master and slave applications can be simultaneously present in RAM 16 or not. The criterion of whether or not the master and slave applications are present simultaneously is only linked to a compromise between performance and necessary RAM resources.

In addition, an optimization of the call request according to the relation (1) previously mentioned in the description can be carried out by separating the selection of the slave application, via the corresponding address variable AID, of the processing, that is to say input data dataln and output data dataOut. Under these conditions, two calls to the operating system OS are then necessary, but this embodiment may prove to be more effective when the communication comprises several commands.

Claims

1. Protocol for the exchange of messages between applications installed on an on-board system provided with an operating system, this operating system allowing, by input / output commands, the exchange of data messages and of commands of main interface between a master application active among these applications, the other applications being inactive, and an external system via an input / output interface, characterized in that it consists at least in: a) transmitting , from the master application, to the operating system, a call request from an inactive slave application, this call request comprising a specific input / output command intended for this slave application; b) deactivate the master application and activate this inactive slave application via the operating system; c) transmit to the activated slave application the input / output command intended for this slave application, via the operating system; d) execute at the level of this activated slave application the input / output command intended for this slave application; e) return from this slave application an acknowledgment and / or response message to the operating system.

2. Protocol according to claim 1, characterized in that it further consists, following step e), in: f) deactivating this slave application and reactivating the master application via the operating system and to transmit to this master application the response of the slave application.

3. Protocol according to claim 2, characterized in that said call request also includes an argument consisting of a pointer designating a memory area in which the operating system can store the response of this activated slave application, following the execution of the input / output command intended for the latter.

4. Protocol according to claim 1, characterized in that, for a parallel management of said applications, following step a) consisting in transmitting, from the master application, to the operating system, a request for call of an inactive slave application, this consists of: suspending the master application until the return to the operating system of the acknowledgment message from this slave application, the parallel management of said applications resulting from the allocation of a calling function respectively of a called function, the master application being given a calling function and the slave application being given a called function; give competing applications a specific hierarchical management system.

5. Protocol according to claim 1, characterized in that, with each application of the on-board system being associated with at least one cryptography key, the transaction between master application and slave application constituted by steps a), b) and c), comprises an authentication procedure for this transaction, using said cryptography key.

6. Protocol according to claim 1, characterized in that the transaction between the master application and the slave application, constituted by steps a), b) and c), further comprises a procedure for authenticating the request d call of the slave application inactive by the master application.

7. Protocol according to claim 6, characterized in that, with each application of the on-board system being associated with a private signature key and a public signature verification key, said authentication procedure consists at least of: generating, at the level of the master application, a random value and to transmit by means of an input / output command this random value to said slave application; to calculate from said private key, at said slave application, a signature value of said random value and to transmit to said master application a message acknowledgment or response containing said signature value; to proceed, at the level of said master application, to a verification of said signature value by means of said public key associated with said private key of said slave application, author of said signature value.

8. Embedded multi-application system comprising an operating system allowing, by input / output commands, the exchange of data messages and main interface commands between a master application active among these applications, the other applications being inactive, and an external system via an input / output interface, characterized in that it further comprises, integrated into said operating system, a set of specific input / output instructions comprising at minus: a call request from a master application, active, a slave application, inactive, an acknowledgment or response message from the slave application to the operating system.

9. on-board multi-application system according to claim 8, characterized in that this on-board system being provided with signature calculation means, this further comprises a set of private signature key and associated public key for verification of signature for each application, said sets of keys being stored in a non-volatile memory area with secure access to said on-board system.