FR2812101A1 - Protocol for exchange of messages between applications embedded in a multi-function smart card, uses transmission of calls from master application to cause operating system to load and execute slave application - Google Patents

Abstract

The message protocol operates between applications on a smart card. A call request holding input/output information for the slave is transmitted (1000) from the master application to the card operating system. The master is deactivated and the slave (1001) activated and transmitted (1002) to the operating system, which supervises execution (1003) of the slave, returning results to the master.

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 "multi-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 location

  of a memory card is shown in Figure la.

  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 18a and of a ROM type memory, or memory type of read-only access 18b. 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 OS is planned, which

  can be installed in non-volatile memory 18.

  Finally, and in certain cases only, the portable multi-application object can comprise, as represented in FIG. 1a, an encryption / decryption calculation unit 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 Specific 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 its non-volatile memory area

  this. This type of architecture usually includes the operating system OS and the applications designated by Appl1 and Appl2 in the above-mentioned figure. Optionally, the above architecture can include a virtual machine, such as a JAVA virtual machine

  (registered trademark), also called JCVM.

  The operating system OS is nothing other than a generic program which provides intercommunication services to the applications installed, 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 Data Unit, defined by the ISO 7816 standard. 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 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 P1, P2: instruction parameters Lcf: length in bits of the data field Df: field Lef data: maximum number of bits in the field

response data.

  SWI, SW2: order status, qualifier of

the command.

  The applications Appll or Appl2 are specific programs which each carry out a particular task or function, such as the functions of an electronic purse PME, system for access to pay television programs, or others. For this purpose, the Appll or Appl2 applications use the services of the operating system. APDU commands, input / output commands, from the user terminal, are processed by

  OS operating system and by applications.

  All APDU commands are reviewed by the operating system, some being filtered and others being delivered to applications, based on a

usage criteria.

  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, SELECTAPDU. The OS operating system examines this

  controls 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 Appl2 is represented as the active application by the double arrow illustrating the one-to-one mapping of the aforementioned active application and the operating system OS. This process and the aforementioned one-to-one correspondence link end when the OS operating system again detects a command to select another application, distinct from the active application, after which the operating system deactivates

  the application activates 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, PTV, must use an electronic wallet 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 active application be able to activate the other application, the slave application, and that a suitable shared communication channel (sharable interface in Anglo-Saxon language) be installed between

  the master application and the slave application.

  Figure lc 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 the available memory of the smart card. A known solution corresponds to an interface

  shared JavaCard. 2.1. For a more description

  detailed description of the shared JavaCard.2.1 interface, we 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 specification. . 1. This shared interface is therefore distinct from the main interface of the applications installed with the OS operating system vis-à-vis the terminal, the 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, the modification of an existing application is most often very expensive, or even difficult to carry out, in particular when the application considered has already been the subject of a security certification, any

  modification rendering the safety 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 OS operating system.

  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 the role of a user terminal

external.

  Another object of the present invention is, also, the implementation of a protocol for exchanging messages between applications installed on an embedded system, such as a smart card, in which any implanted application is capable of being selected as the master application, this master application itself being able to enter into communication with any other separate application, thus constituting vis-à-vis 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 everything

  embedded 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 of transmitting, from the master application, to the operating system, a call request from an inactive slave application, this call request comprising at least one specific input / output command intended for this slave application, to deactivate the master application and to activate this inactive slave application via the operating system, to be transmitted to the application e slave activated the input / output command intended for this slave application, via the operating system, to be executed at the level of this activated slave application the input / output command intended for this slave application, to return to from this slave application an acknowledgment and / or response message 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 a system.

  embedded, such as a smart card, in particular.

  It will be better understood on reading the

  description and observation of the drawings in

  which, in addition to Figures la to ld 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; - Figure 2b shows, by way of illustration, the path for the exchange of APDU commands by means of a main interface and of the operating system OS

  as part of a multi-card architecture

  application, during the implementation of the object of the invention protocol illustrated in Figure 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 of 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 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, an alternative implementation of the protocol object of the present invention, in which a procedure for authenticating the call request of the slave application and of 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 different from that described in Figure 4a; FIG. 5 represents, by way of illustration, the installation of a portable object or on-board system, such as a smart card, in accordance with the object of the

present invention.

  A more detailed description of the protocol

  exchange of messages between applications installed on it, an on-board system, in accordance with the object of the present invention, will now be given in conjunction with the

  Figures 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 circuit 12

shown in Figure la.

  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 according to the use of the

  on-board system or the aforementioned smart card.

  Consequently, the protocol which is the subject of the present invention will firstly be described in connection with FIGS. 2a and 2b in the case where the multi-application on-board system considered is used,

  that is to say inserted into a terminal of use.

  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 o1, the considered master application which has been activated performs the processing of this command in step o2 represented

in Figure 2a.

  The message exchange protocol between applications in accordance with the subject of this

  invention is then implemented in the following manner

  after. 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, of deactivating the master application and activating the slave application, inactive,

  through 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 aforementioned step 1001 is then followed by a step 1002 consisting in transmitting to the application

  slave activated the input / output command, i.e.

  say the APDU command intended for this slave application, via 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

answer 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, i.e. restoration, of the master application, to continue operations

  exchange 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 use terminal, according to the results of the processing. of the slave application response by

  the master application made in step 1006.

  A more detailed description of the paths

  borrowed by the different exchanges of data messages and / or commands exchanged during the implementation of the protocol which is the subject of the present invention,

  will now be given in connection with FIG. 2b.

  It is considered by way of nonlimiting example that the user terminal is a terminal for accessing a television receiver for example, comprising the equipment necessary to authorize or not the access to

  Pay TV shows.

  The on-board system used consists for example of a smart card in which are

  implemented two applications, a carrier application

  PME electronic money and an application for access to 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 of rights

corresponding access points.

  We consider 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 SME application.

  Given these elements, the operations or steps ol and 02 are carried out by the exchange of APDU commands between the operating system, the PTV master application and the terminal. Paths

  Access borrowed are noted (1) in Figure 2b.

  Following the execution of steps ol and 02, steps 1000 to 1004 are then performed between the PTV master application, the OS operating system and of course the PME 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 well 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 the 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 in the

  framework of the main interface environment.

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

  of course achieved 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.

  Generally, the master application chosen first calls on the services of the OS operating system to indicate its wish to call the slave application, the PME application previously

  mentioned in connection with Figure 2b.

  The call request for the inactive slave application can then take the following form: isoStatus = callSlaveApplication (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 ISO 7816, isoHeader and dataIn contain the ADPU command that the master application wishes to send to the slave application and the * dataOut argument is a pointer to a memory area such as the RAM memory area 16 represented in FIG. 1 a, 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 o, if necessary, a series of calls to master applications, respectively slave as represented in FIGS. 2c, with successive return

  of the final response to the user terminal.

  As regards the mode of implementation of the protocol, object of the present invention, as represented in FIGS. 2a, 2b and 2c, it is indicated that this mode of implementation corresponds to an alternative embodiment designated by parallel application / stacked. When requesting an appeal previously

  mentioned in the description and designated by

  callSlaveApplication, the master application is suspended until the slave application returns. These operations correspond to steps 1001 and 1005 of FIG. 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

conferred a function called.

  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 which is the subject 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 this 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 ISO status isoStatus as well as the dataOut response data are then communicated by the system. operation with 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 occupation 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 backups required in

non-volatile memory.

  The process of implementing the protocol object of the present invention for the sequential applications described above is illustrated by

the flowchart of Figure 3a.

  In the aforementioned flowchart, it is indicated that the same references naturally designate the same

  steps as in the case of Figure 2a.

  However, and in a particularly advantageous manner, it is indicated that step 1000 is then constituted by a sub-step 1000a and a sub-step

  1000b, sub-step 1000a corresponding to a sub-

  step in which the master application saves its state in memory, while sub-step 1000b corresponds to the call by the master application of the OS operating system to send a command

  APDU to the slave application considered.

  Likewise, step 1005 is subdivided into two sub-steps, 1005a and 1005b, sub-step 1005a consisting in deactivation of the slave application by the OS operating system and in reactivation of the master application, this sub-step, as soon as the latter is reactivated, being followed by sub-step 1005b in which this master application restores its state from the RAM 16, state saved in sub-step 1000l a 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 represented 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 PME application or any application by which values

trustees 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 made up of steps A, B and C, i.e. steps 1000, 1001, 1002 of the figures

  2a or 3a previously introduced in the description,

  can advantageously include a procedure for authenticating the transaction between applications

master 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 inactive slave application by the master application, for example, as it will

described below.

  Upon authentication of the call request, true value of authentication, the transaction is

  continued. Otherwise it is interrupted.

  For this purpose, as shown in FIG. 4a, step 1000 of FIG. 2a or step 1000b of FIG. 3a can be followed by a step 10001 respectively 1000b1 of 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 FIG. 4b, of performing a signature operation, respectively verification of signature, of elements making it possible to authenticate the origin of the appeal request and thus secure the aforementioned transaction. For this purpose, as shown in FIG. 4b above, with each application installed on the on-board system, a private signature key, denoted KpRi, is associated with a public signature verification key, denoted Kpui, the index i designating an identifier of the implanted application considered. Thus, each application, master or slave, has a set of signature keys associated with it,

  signature verification respectively.

  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 APDU specific command type, APDU *, this value random to

the 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 KpRi, a signature value of the value random RV received by

the latter.

  The signature calculation operation then verifies the relationship: SG = fKPRi (RV)

  relationship contained in step B of Figure 4b.

  In the previous relation, SG represents the calculated signature value and fKPRi denotes the operation

  of calculation of signature of the random value RV.

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

  response 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 Kpui associated with the private key of the slave application author of the aforementioned signature value. The signature verification operation verifies the relationship: V (SG) = gru (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 which is the subject of the present invention is not limited to the procedure for authenticating the call request of the slave application inactive by the master application.

previously described.

  In particular, it is also possible to implement an authentication procedure for the call request from the master application, or if necessary, a logical combination of these authentication procedures. 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 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 processes of encryption / decryption, calculation and verification of signature or exchange of authentication values.

  A more detailed description of a system

  multi-application on-board device constituted in a nonlimiting manner by a smart card conforming to the object of the present invention, will now be given in

link with figure 5.

  In FIG. 5, the same elements as those represented in FIG. 1a bear the same references, the additional elements necessary for the implementation of the protocol object of the present invention having

only distinguished.

  Firstly, in order to allow the implementation of the protocol object of the present invention, the on-board system object of the invention as represented in FIG. 5 comprises, integrated into the operating system, a set of specific instructions for inputs / outputs, noted I * APDU comprising at least the APDU * instructions previously mentioned in the

  description and in particular a request for appeal, to

  from an active master application, from an inactive slave application, this call request corresponding for example to the command given according to the relation (1) or according to the relation (2) mentioned

  earlier in the description. In addition, a

  command for transmitting response data via the operating system OS to the master application at the time of reactivation thereof can be provided in the command set, according to the relation (3) previously mentioned in the

description.

  In addition, as shown in FIG. 5 above, the on-board system is advantageously provided with the 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 also comprises a set of private signature key and public signature verification key, the keys Kpri and Kpui, associated with each application installed in the embedded system . Only one secret key can, if

be provided.

  In order to secure transactions between applications as much as possible, not only the private keys associated with each application, but also the public keys associated with them, if necessary the secret keys, are stored in a non-volatile memory area with secure access from 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 ISO 7816.

  In the example described above of exchanges of messages between two applications, an application for accessing pay television programs and an electronic purse application,

  the P_TV application must prove to the carrier application

  electronic money his identity before, of course, the latter allows him any debit and direct debit transaction in the wallet

electronic, and vice versa.

  For the implementation of 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 for

  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 d '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 during

  receipt of the latter's request for appeal.

  We have thus described a message exchange protocol 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

  main interface commands.

  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, i.e. applications whose programming language or design are different, may

be activated.

  In addition, the reuse of the main interface and of 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 conventional on-board system.

  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 the embedded systems which are the subject of the present invention can be envisaged. In particular, master and slave applications can

  be simultaneously present in RAM 16 or not.

  The criterion of simultaneous presence or not of the master and slave applications is then only linked to a compromise between performance and memory resources

lively necessary.

  In addition, an optimization of the appeal request according to the relation (1) previously mentioned in the

  description can be made by separating the

  selection of the slave application, via the corresponding address variable AID, of the processing, that is to say input data dataIn and output data dataOut. Under these conditions, two calls to the OS operating system are then necessary, but this embodiment may prove to be more effective when the communication includes

multiple orders.

Claims (9)

  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 forward to this app   master 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, to the master application being given a calling function and to the slave application being given a called function; - assign competing applications a system   specific hierarchical management.   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 key cryptography.   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 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 from the master application, a random value and to transmit by means of an input / output command this random value to said slave application; - calculating from said private key, at said slave application, a signature value of said random value and transmitting to said master application an acknowledgment or response message containing said signature value; to carry out, at the level of said master application, 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 less: - 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. multi-application on-board 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 at each application, said sets of keys being stored in a non-volatile memory area at   secure access of said on-board system.