Terminal and system for implementing secure electronic transactions

ES 2 173 740 T3

DESCRIPTION

Terminal and system for carrying out electronic transactions with a security guarantee.

The present invention relates to a terminal and a system for carrying out electronic transactions with a security guarantee.

Public networks for the transmission of numerical data, such as the Internet, are undergoing considerable development. However, one of the obstacles that currently limit the realization of electronic transactions with security guarantees in this type of network resides in the insufficiency of the security mechanisms associated with such transactions, an insufficiency that is translated by a lack of trust of the users. and network operators.

In the sense of the present application:

- an electronic transaction designates an exchange of information, through a public network for the transmission of numerical data or telecommunications, either between two or more users, either between a user and a service provider,

- a function is a process carried out with the aim of providing a service to a user,

- an application designates a coherent set of services and functions,

- The application software expression designates the software or software necessary to perform the functions related to a specific application,

- A transaction with a security guarantee is a transaction for which certain security measures have been taken, that is, the authentication of the entities participating in the transaction, the integrity, confidentiality, authenticity, and eventually the non-repudiation of the exchanges and operations carried out within the framework of the operation.

Many applications require that the electronic transactions carried out are carried out with a security guarantee. It is, for example, the control of access to computer or similar resources, the bank at home (consultation, movements of bank accounts, etc ... through the telephone network or the Internet), electronic commerce (purchase of goods or services through a public network), email, electronic purse, etc ...

These applications, as well as others, that require transactions under security guarantees are well known to specialists in the field and are not described in detail here.

According to their nature, the security guarantee of these applications requires the realization of one or more security services, such as:

- Authentication, which makes it possible to guarantee the identity of an entity (a person or a system);

- access control, which confers protection against the unauthorized use or manipulation of resources;

- confidentiality, which prevents the disclosure of data to unauthorized entities;

- data integrity, which ensures that data has not been modified, deleted or replaced without authorization;

- non-repudiation, which ensures that a participant in a data exchange could not subsequently deny the existence of this exchange.

The combination of two existing techniques allows considering the realization of these security services, thus offering a sufficient level of security to carry out electronic transactions.

Is about:

- cryptography with a public key and a private key, since this allows to guarantee non-repudiation and facilitates the management of the keys;

- The integrated circuit card (or “smart card”) since it is inexpensive, easy to use and safe thanks to specific microprocessors equipped with material and software protections, which make it possible to prevent reading and writing access to its memories.

Integrated circuit cards offer the following services:

* Authentication of the card holder or user: this operation allows the bearer to be authenticated using a confidential code and allows the card to subsequently affect the performance of operations such as the execution of algorithms, the reading of secret keys, the reading and / or or the writing of data on the card, which may also be subject to other security conditions;

^* the protection of the data and functions stored in the integrated circuit card. Access to the card can be subject to prior authentication by the electronic entity requesting access. This external authentication is generally done in challenge / response mode. In this case, the entity has a secret parameter, hereinafter referred to as equally secret, which allows it to calculate, based on a challenge issued by the card, a response that will prove the card that was in possession of the secret;

^* execution of cryptographic algorithms using a secret parameter memorized in the card (encryption, message authentication, signature);

^* internal authentication. This service allows an application to authenticate the card. This service is the reverse of an external authentication. The card generates a response based on a challenge received and a secret registered on the card.

ES 2 173 740 T3

The services offered by the integrated circuit card are performed upon receipt of so-called elementary requests, causing the execution of the elementary request to send elementary responses. These elementary requests refer, for example, to cryptographic calculations, reading or writing of secret data or not, user interventions (use of their personal confidential PIN code, validation of a transaction after signing), information returns to the user ( presentation of the messages to sign, for example).

Certain cards offer the possibility of verifying the integrity, the origin, even the confidentiality of the requests transmitted to the card. These services are based on authentication and request encryption techniques.

The current use of integrated circuit cards (or microcircuit cards) offers a very high degree of security, since transactions are essentially carried out through private networks and automated ticket dispensing terminals, point of sale terminals, for example. ) that are under the control of an entity that guarantees the security of the entire system.

In such applications, users or possible fraudsters do not have access to the application software, nor to the material and software security mechanisms that the terminals are equipped with.

On the contrary, the realization of transactions with security guarantee by integrated circuit cards in a public network supposes that users have at their disposal a card reader terminal module, since these micro-circuit cards are not equipped with a source. own electric power and its realization requires a reader capable of feeding them and establishing communication with the user and / or external electronic means.

Currently, to carry out a transaction in a public network, the user has a terminal, which can be a particular product, a personal computer or a personal computer coupled to a circuit card integrated by a card reader.

In all cases, the transaction system available to the user was generally made up of:

- an application service provider that can be, for example, an Internet navigator, a messaging software, a home banking software (“Home banking”),

- a high-level security service provider that allows the execution of the low-level cryptographic mechanisms required by the application.

The application service provider issues requests for high-level security services to guarantee the security of the transactions carried out.

In the event that the application is implanted in the user's personal computer, the cryptographic services to which we refer are, for example, those defined by the RSA Laboratories Company in its standard "PKCS 11: Cryptographic Token Interface Standard", or also in the cryptographic services offered by Microsoft's Windows NT operating system, in particular those offered by the “Cryto API” application program interface (API).

When the user does not have an integrated circuit card reader, the cryptographic services are performed only in a software way.

When the user wants to improve security, he uses a transparent type integrated circuit card reader connected to his computer. A transparent type card reader is in fact an interface box between the computer and the integrated circuit card that allows the transmission of elementary requests from the computer, coming from the cryptographic service provider, to the card, and the elementary responses of the card to the computer. A user can, using this terminal, (made up of his terminal-computer module + reader - coupled to his card) carry out electronic transactions (electronic commerce for example).

It is well understood that user access to such a terminal creates potential risks from a security point of view.

The risks that occur will be all the greater if the applications are decentralized. And vice versa, applications could be decentralized to the extent that risks are regulated on the terminal side. Thus, for example, applications of the purse type can be considered, in which transactions (debit from the buyer's card / credit from the merchant's card) are carried out from card to card, without the need for a consolidation of transactions at the same level. from a central server.

The result of the foregoing is that a terminal could potentially contain a set of information, including software, on whose confidentiality and integrity the security of the application rested. As an example, we can cite secret keys used for the authentication of the terminal module with respect to the card, or for data encryption between a server and the card reader terminal module. However, a fraudster can take advantage of having a terminal at his disposal to analyze its operation and access confidential information and software.

It is also necessary to bear in mind that the applications to which we refer, such as commerce or e-mail, are carried out most of the time through the Internet. It is well known by experts that a personal computer or PC connected to the Internet is very vulnerable to virus-type software, which can be installed and executed on the user's PC without their not even knowing it and without leaving an access fossil to your computer that you can enter. The totally invisible aspect of this type of threat represents the real danger that currently limits the development of operational applications using the Internet. The same comments can be made with respect to e-commerce applications considered from cable television networks.

ES 2 173 740 T3 using decoders or "set-top boxes" connected to the television set and comprising one or two chip or electronic card readers.

The risks at the system level are then:

- Attack on the integrity of the cryptographic service provider and the application service provider to modify the behavior of the terminal module: by way of example, the terminal module is modified to capture the information linked to the card, record the information obtained and then communicate them to a fake server. This attack can be carried out behind the back of the legitimate user (substitution of the user's terminal module or use of a modified terminal module). This attack can then become generalized in the form of the spread of counterfeit terminal modules;

- Attack on the confidentiality of the provider of cryptographic services, to obtain the cryptographic keys that it manipulates, keys that, for example, will be recorded on the hard disk of a computer.

- Attack on other cards, based on an ability to be able to authenticate with these cards, using the secrets discovered by an attack on the confidentiality of the service provider.

- Attack on the integrity and confidentiality of communications between the different entities (application service providers, cryptographic service providers, integrated circuit card reader, integrated circuit card, server) allowing breaking the chain of trust established between them elements. For example:

1- decryption of communications between server and terminals;

2- inserting a third software between the application service provider and the cryptographic service provider, to break the chain of trust between these two software, or they will replace the application software with a third software in order to make the service provider security executes security requests with an object different from the application object known to the user.

- Attack on servers (in the case of an application in connected mode): connection of a counterfeit terminal with respect to a server, emulating a terminal module-integrated circuit card pair, to obtain advantages.

Thus, an attack on the chain of trust between the cryptographic service provider and the application service provider, within the framework of an application that requires the signature of an electronic transaction using an integrated circuit card, will be illustrated below. The development of the transaction is as follows:

- Stage 1: verification of the user's personal confidential code (PIN), which he enters through a keyboard associated with his terminal module, the code entered being transmitted to the card for verification by the latter.

- Stage 2: authentication of the terminal module. The latter sends a “challenge request” request. (A challenge is a random or pseudo-random number). The integrated circuit card generates the challenge and transmits it to the terminal module. The terminal module sends the card an "external authentication" request accompanied by a response consisting of the challenge encrypted by a key held by the terminal module. The integrated circuit card then verifies the received response.

- Stage 3: if stages 1 and 2 have been carried out satisfactorily, the integrated circuit card is ready to receive and execute the signature request, that is, an encryption request, by means of a private key registered in the card, the result of a control operation carried out on the transaction object of the user. After this encryption, the card issues, destined for the terminal module, the signature constituted by the result of the control operation ("hash") thus encrypted.

If the integrity of the application software (application service provider and its cryptographic service provider) is not assured, a fraudster does not need to know the keys and secret codes to hack into the operating system: It is enough to implant in the terminal module, for example in the personal computer to which an integrated circuit card reader is connected, a virus-type software that, in step 3, confuses the authentic data to sign and sends to the card falsified data. As stages 1 and 2 have been developed in a satisfactory manner, the card will then sign the falsified data on the basis of the PIN that the user himself has entered and you will believe that the card will authorize its own data.

The preceding example shows the need to protect not only the confidential information used within the framework of an operation, but also the integrity of the transaction, that is, the integrity of the behavior of each entity involved in the transaction, as well as the integrity of the transaction. overall behavior of the software, ensuring that the chain of trust established between the different entities does not break.

The attack risks mentioned are currently covered in part by terminals - integrated circuit card readers that integrate

ES 2 173 740 T3 security modules (SAM, analogous to an integrated circuit card) which are used in particular within the framework of coin purse applications. The reader is then personalized by a SAM, and attributed to a merchant, the cards being read by the customers. This SAM contains secret information and is capable of executing algorithms that use this secret information. But it does not contain means that allow in particular to regulate communications with the user, with the integrated circuit card and / or with external electronic means, and therefore the security guarantee of the transaction is not established.

It is also known from document WO 95/04328 a terminal module comprising user interface means and interface means with external electronic means (hereinafter referred to as external interface means), comprising an interface with a microcircuit card . The microprocessor of the terminal module comprises data recording means (ROM, EEPROM, RAM). The data recorded in permanent memory (ROM) includes, among others, an operating system, external component managers that regulate the interfaces and peripherals, and an interpreter capable of interpreting modules-programs written in a specific language. The module programs are recorded in semi-permanent EEPROM memory and can be loaded into temporary RAM memory to be executed by the microprocessor at the time of activation of an appropriate interface by the user. The module programs, corresponding to the applications of the terminal module, are downloaded into the EEPROM memory of the microprocessor or on a microcircuit card from an external server.

The terminal module of document WO95 / 04328 can work:

- in stand-alone terminal module mode, the microprocessor of the terminal module executing a module-program stored in an internal memory, without resorting to an integrated circuit card;

- in autonomous terminal mode, in which a module-program registered on a card is executed;

- in terminal mode with extension or connection, in which the microprocessor of the terminal module or that of the card executes a module-program and a communication is established by telephone, a modem or a direct connection with a service provider or a server;

- in the transparent memory card reader mode, in which instructions received by a serial connection are transmitted directly to the card and vice versa.

The terminal described in document WO 95/04328 does not deal with the security problems referred to in the invention, since it does not describe how to secure a transaction by guaranteeing the integrity of the overall behavior of the software that executes the transaction. It does not describe in particular means that allow the execution of high-level requests issued by the application, nor how to guarantee the origin, integrity and confidentiality of these means.

The present invention aims to provide a terminal for the realization of guaranteed electronic transactions, of the type that comprises a personal security device such as an integrated circuit card or other device that fulfills the same functions, and a terminal module equipped with means of interface with personal security device, such as an integrated circuit card reader, and offering by its software and / or material architecture and the security mechanisms that include an improved level of security, compatible with the fact that the terminal can be placed under the control of the users, (as opposed to the terminals regulated by operators) .

A second object of the invention is to ensure this same level of security while allowing the integration, in the course of use, of new functions or applications, or the evolution of existing functions or applications without resorting to a multitude different terminal modules or the change of terminal modules in the course of evolutions.

To this end, the evolution is aimed at a terminal for the realization, by a user, of electronic transactions with guaranteed security, in relation to at least one application implanted in an electronic unit, said terminal comprising:

- a terminal module that has at least:

- some first interface means with said application to receive requests related to said transactions,

- a second interface means with said user,

- a third means of interface with a personal security device,

- first data processing means comprising at least first software means for regulating said interface means, and

- a personal security device comprising at least a second data processing means with guaranteed security, having at least a second logistical means for executing elementary requests and a means for executing cryptographic calculations, characterized in that:

- said terminal was adapted to receive the aforementioned requests from said application implanted on said electronic unit in the form of high-level requests independent of said personal security device,

- at least one of said terminal module and said personal security device comprises:

ES 2 173 740 T3

- at least one reprogrammable memory for registering at least one filter software, which will translate these high-level requests into at least:

(i) an elementary request or a sequence of elementary requests executable by said second software of said second data processing means, or (ii) a sequence of data exchange between said terminal module and said user through said seconds interface means, this data exchange being executed by said first software means of said first data processing means,

- means of protection of the mentioned software-filter to prevent any reading and / or modification of said software by an unauthorized person, and

- at least one of said first and second data processing means comprises a data processing device for executing said software-filter.

The invention that is defined allows to achieve the security objectives required to carry out electronic transactions, thanks to the fact that it describes a filter or “firewall” between the outside world, that is, the applications themselves, and the security and peripheral means. corresponding, Through a logical interface that allows the definition of the format of the high-level requests issued by the applications and a translation software that ensures the processing of these requests.

Preferably, the terminal according to the invention comprises one or more of the following characteristics, optionally combined:

- said device for executing the software filter comprises first means of identification and / or authentication of said application implanted in said unit or of the origin of said requests issued by said application;

- said data processing device for the execution of said software-filter comprises means for verifying the integrity of the data received from said application;

- the aforementioned data processing device for the execution of said software-filter comprises centralized means for controlling the conditions of use of the services of the personal security device, depending on the aforementioned application and / or said user;

- The aforementioned data processing device for the execution of said software-filter comprises:

- means for arranging the guaranteed loading of said software-filter in said programmable memory, through one of said first or third interface means, from an entity external to said module, and

- first access control means to not allow said loading of said software-filter except in response to at least one previously defined condition;

- the terminal comprises second means for authenticating said first data processing means by said second data processing means;

- the terminal comprises third means for authenticating said second data processing means by said first data processing means;

- the terminal comprises a first communication channel between said first and second data processing means and first security means of said first communication channel;

- the terminal comprises fourth means for authenticating said terminal module by said user, independently of said card;

- said fourth means of authentication comprise means of calculation, by said first data processing means, and of presentation to said user, through said second interface means, of a keyword known to the said user and calculated on the basis of at least one first secret parameter registered in said first data processing means;

- the terminal comprises fifth means for joint authentication of said terminal module and said card by said user;

- said fifth means of authentication comprise means of calculating, by said device for executing said software, and presenting them to said user, through said second interface means, of a keyword known by said user and calculated on the base of at least a second and a third secret parameter registered respectively in said first and second data processing means.

According to a first form of embodiment of the invention, the terminal module was constituted by a personal computer and said programmable memory was constituted by the disk of said computer, the aforementioned software-filter is executed in the personal computer or in a second form of execution, said programmable memory is implanted in a guaranteed server connected to the personal computer, running on said server

ES 2 guaranteed the part of the software-filter that must be protected.

According to a second embodiment of the invention, the terminal module is a device, such as a dedicated integrated circuit card reader, in which case said personal security device is an integrated circuit card or a personal computer. This form of embodiment differs from the preferred one by the fact that said programmable memory is integrated into a microprocessor with guaranteed security, the said software filter being executed on said microprocessor with guaranteed security. The specific terminal module can eventually be portable.

According to the execution modalities of this second embodiment of the invention, the programmable memory for loading and registering the software-filter can be arranged in the personal security device or in the terminal module.

In this last case:

- the terminal module can comprise a single microprocessor for the execution of the software-filter and the regulation of the interfaces, or two microprocessors that respectively fulfill one and the other of these two functions;

- Preferably, said software-filter comprises at least one secret parameter and said second data processing means comprise second conditional access control means to not allow the execution of said cryptographic calculations, in response to elementary requests generated by said software-filter plus that if at least one second previously defined condition is fulfilled, depending on said secret parameter.

According to other characteristics of the invention, when the terminal module comprises two microprocessors for the execution of the software-filter and the regulation of the interfaces:

- the terminal comprises a second communication channel between said first software means for regulating the interface means and said second microprocessor and second means of guaranteed security of said second communication channel;

- said second security means comprise means of encryption and decryption, by the indicated first software means for regulating the interface means and said second microprocessor, of the data transmitted by said second communication channel, on the basis of at least a fifth secret parameter memorized in said first and second data processing means;

- the aforementioned second security means comprise first physical means of protection of said second communication channel against intrusions.

740 T3 12

We will now describe different forms of realization with reference to the attached drawings, in particular forms of realization in which the software-filter is loaded and executed in the terminal to guarantee at the same time its origin, its confidentiality and its integrity, and this software can also authenticate the origin of the requests that are sent to it, if trust in the interfaces with the user, that is, the screen and the keyboard, cannot be guaranteed.

- Figure 1 is a diagram that illustrates the functional architecture of a system for the performance of operations with guaranteed security by means of a terminal according to the invention;

Figure 2A presents a first embodiment of the invention, where the terminal is a personal computer coupled to a circuit card integrated by a reader device, the application itself being able to be implanted in the personal computer or in a remote server;

- Figure 2B describes the functional architecture of a variant of execution of the first embodiment of the invention, in which the personal computer that serves as a terminal is connected to a security server in which the software-filter has been implemented ;

- Figure 3 presents a transaction system carried out thanks to a terminal according to a second embodiment of the invention, which can be a dedicated product connected as peripherals to a personal computer or directly to a server or built around a personal computer ;

FIG. 4A is a general diagram of the material architecture of the electronic circuits of a first embodiment of the terminal of FIG. 3;

figure 4B is a block diagram illustrating a first configuration of the software architecture of the terminal of figure 4A;

FIG. 4C is a functional diagram similar to that of FIG. 4B showing a second configuration of the software architecture of the terminal of FIG. 4A;

FIG. 5 is a general diagram of the material architecture of the electronic circuits of a second embodiment of the autonomous terminal of FIG. 3;

FIG. 6 is a general diagram of the material architecture of the electronic circuits of a third form of execution of the autonomous terminal of FIG. 3;

figure 7 is a diagram illustrating the ordinary software architecture of a micro-circuit card;

ES 2 173 740 T3

- Figure 8A is a diagram illustrating the software architecture of a transaction system that comprises the terminal of the figure

4A;

figure 8B is a diagram illustrating the software architecture of a transaction system comprising the terminal of figure 6;

Figure 9 is a diagram illustrating the realization of an electronic commerce application by means of a system according to the invention; Y

FIG. 10 is a flow chart illustrating the process of downloading a program in a reprogrammable memory of the terminal module of FIG. 4A or 5, or of a micro-circuit card connected to it.

With reference to figure 1, we will say that a system for carrying out transactions with guaranteed security comprises a terminal module 1 for reading an integrated circuit card 31 or equivalent. Terminal module 1 comprises a filter F made up of a software module that processes high-level requests issued by application service providers FAp external to terminal module 1, by means of a F-APl logical interface, and user interfaces such as a screen signaling 4 and a keyboard that allow the reading and the introduction of data by a user. It also includes a reader or communication interface 6 with a micro-circuit card or any equivalent personal security device for the user, such as token, “JavaRing” (product of the SUN Company), “iButton” (product of the Dallas Semiconductor Corporation), software token (soft token), as well as communication interfaces with at least one FAp application service provider that can, for example, be implanted in a personal computer PC and / or in a Sap server, then the data exchange is carried out through a data transmission or telecommunications network R.

The terminal module 1 can be a private terminal or be integrated in a personal computer of the PC type, or in a computer-NC terminal dedicated to network applications (Network Computer) or also in a cable television network decoder ( Set Top Box).

The terminal module 1 can optionally be used in stand-alone mode, for example to read information, such as the content of an electronic purse, contained in a memory of the card 31.

To carry out transactions with security guarantees, terminal module 1 can be used in connection mode with a SAP server or in non-connected mode, then the FAp application is executed locally, for example on the personal computer PC: such is the case, for For example, when a user must sign an email or a transaction that will be sent to a recipient. Such operation does not imply connection with an application server at the time card 31 is used.

In connected mode, as represented in figure 3, in the case of a dedicated terminal module 1, this can be connected to the Sap server in which the FAp application has been implemented through the PC computer and a network R such as Internet, or through the R telephone network through a MO modem or a DTMF connection with a CT telephone combination. Certain transactions, such as the reloading of an electronic purse on the card 31, may require a bidirectional exchange of data with the server Sap and are therefore more ergonomic in connected mode.

Carrying out a transaction with guaranteed security, with a terminal module 1 and a card 31 implies that high-level logical requests (for example, signature requests, authentication requests, etc ... that must be processed in such a way as to satisfy the security objectives required of the application program) are transmitted from the application program implemented, for example, on the SAP server (connected mode) or on the PC or NC personal computer available to the user (non-connected mode , for example e-mail signature), to the filter F that carried out the regulation of the security means. This filter F carried out the processing of these requests by means of a translation software, making sure that the application or any other virus-type software cannot have direct access to the cryptographic functions of the integrated circuit card 31. The process of the high-level requests includes the translation of these requests into an elementary request or a sequence of elementary requests that are executed by the personal security device. High-level requests are made independently of the material and / or software configuration of the personal security device, that is, they are not made directly based on the personal security device.

The high-level requests contain information specifically related to the process that will be executed by the software-filter. Following a simple example, a high-level request can comprise a simple elementary request to transmit to the personal security device, for example an APDU (“Application Protocol Data Unit”), in the case of a microcircuit card linked to an authentication MAC code. of message that allowed the software-filter F to verify the origin and integrity of this request before sending the elementary request to the personal security device. Following a more complex example, such as a document signature request, the high-level request was transformed by the F filter into a sequence of elementary requests sent to the personal security device and eventually to the user interface. Thus, according to this definition and given that they contain specific information that must be decoded by filter F independently of the personal security device, high-level requests are considered independent of the personal security device.

The F filter responds to the intended security objectives since the translation software

ES 2 173 740 T3 which comprises verifies the identity of the application by issuing the requests for services (or directly the origin of the requests) and is implemented in a way that guarantees the integrity and confidentiality of the operations and elementary data applied to respond to the requests for services.

A translation software is a software configured for a type of micro-circuit card and translates a high-level request received from an application software into an elementary request or a sequence of elementary requests executable by the microcircuit cards and / or a sequence of data exchanges with the user.

High-level requests are a list of requests used by application programs to resort to the security services necessary to identify and authenticate the person carrying out the transaction and guarantee the origin, integrity, and eventually non-repudiation of the transaction. A high-level request from an application (located on a server or on the PC or NC personal computer) can be characterized by one or more of the following points:

- It is independent of the basic means (cryptographic means for example) used to satisfy your request and contains specific information that must be processed by filter F. Reciprocally, several applications can use the same security service provider, then resorting to the same F-API logical interface that defines these requests;

- the request process allows the transaction to be securely linked to the user who carried out the transaction using at least one secret parameter, fixed or variable, registered on the user's integrated circuit card;

- possibly includes information or several pieces of information that allow the software-filter F to verify its origin and integrity. Authentication can be done by means of a code of the "Message Authentication Code or MAC" type or of the "electronic signature" type associated with the request.

- In the event that the transaction is not received by the user in the terminal module itself, the request eventually contains the necessary information to allow the user to verify, if desired and if the terminal module supports this option, the essential data of the transaction.

The logical interface F-API that allows the exchange of high-level security requests between applications and the F filter translation software can be standardized to be common to different application programs. Thus, the “signature” type request can be used by an electronic messenger or by a purchasing software. It is thus possible to change the application while keeping the security service provider or reciprocally replace the security service provider without modifying the application.

In order to guarantee the integrity of the chain of trust between the application and the card, the translation software-filter F identifies and even authenticates the origin and integrity of the requests it receives. Different methods can be considered to identify the application that issues the requests:

- An identification code can be integrated in the request itself and later verified by the software-filter from the information that it contains or that may be registered on the integrated circuit card;

- The same object can be achieved by comparing the result of a control operation by the software-filter on the application software, issuing the request with a result previously registered on the card, for example. This last solution is particularly adapted in the event that the application is implanted in the user's PC;

- Authentication can also be carried out by associating a “MAC” type code to the request, calculated from the content of the request and a secret key shared between the application and the filter software. An equivalent principle can be used with a signature of the request calculated with the same information and a private key known by the application, verifying the signature with the corresponding public key known by the software-filter.

Figure 2A describes a first embodiment in which the terminal module 1 is a personal computer PC 102, the connection being made with the integrated circuit card 31 by means of a reader 6 connected or integrated in the computer PC 102. The computer staff 102 comprises input to output interfaces 102a with the reader 6 and the Sap server. According to the nature of the reader connected to the PC, the interface elements with the user can be the keyboard and the screen of the PC itself, or a keyboard and / or an LCD type indicator, for example, implanted on the reader. In this embodiment, the filter F is implanted and executed on the computer PC 102. The filter F t, therefore, the translation software it contains, can then be recorded on the hard disk HD 102b of the personal computer 102. To be executed by the calculation unit or microprocessor 102c of the PC, the software-filter is then loaded into the live RAM memory 102d of the personal computer 102.

The hard disk of a PC computer is difficult to protect, so the F-filter software or at least the sensitive part of this software can be encrypted. For this, it can be broken down into at least two modules: a loading / decryption module Fcd and a second module corresponding to the encrypted software-filter itself, Fchi. The first module allows the loading of the second module in memory

ES 2 173 740 T3

RAM, its decryption and then the launch of its execution. With reference to Figure 2A, we will say that the software module decrypted and loaded in RAM is called Fdec.

The use of a programming language such as Java, due to security mechanisms intrinsic to the language itself, makes it possible to reinforce the protection of the software.

Another method of verifying the integrity of the software-filter is to have the second module signed by an authority that guarantees the content of the software-filter by means of a private key kept secret by this authority. The first charging module then carried out, simultaneously with the decryption operation, a control operation on the second module and verifies the signature of this module by means of the public key associated with the private key of the authority.

The set of operations described in the preceding paragraphs implies the use of keys on which the security of the application rests. These keys can be hidden in the charging module, registered in the reader 6 or registered in the integrated circuit card 31 itself. Another possible way of carrying out is to implant the decryption and integrity verification module in the reader 6.

The object of the invention is to make sure that a hacker cannot use a user's integrated circuit card without him knowing it, for example by modifying the software-filter that regulates the card or the application software, or implanting a virus software that short-circuits the application or the filter-software placed in position. The form of implementation that is described and its variants respond to these risks, allowing the verification:

- the integrity of the software-filter and

- the origin and integrity of the orders sent to the card through reader 6, authenticating them by means of a MAC-type code, for example. MAC verification can be done by reader 6 or card 31. Equivalent protection could be obtained by encrypting the dialogue between the software filter and reader 6. A virus software that tried to short-circuit the filter-software would therefore send unauthenticated or incorrectly encrypted orders to reader 6 or card 31; consequently, these orders will be rejected by the reader or the card, preventing the virus from achieving its goals. So that a fraudster cannot determine the keys used on a terminal, analyzing the operation of another terminal, the keys used by different terminals should be diversified.

The encryption and signature mechanisms that can be considered to respond to the need for protection of the software-filter are well known to experts and are based on the existing cryptographic techniques exposed, for example, in the work of Bruce Schneier entitled "Applied Cryptography , Protocols, Algorithms, and Source Code in C ”published by John Wiley and Sons,

Inc., 1994, and thus not described in detail here.

The implantation of the software-filter in a personal computer PC does not guarantee the same degree of security as an implantation in a particular terminal that can offer additional material security mechanisms, as described in the other forms of realization presented later, providing These mechanisms provide a fossil protection for the filter software and the secrets it contains.

In FIG. 2B an embodiment variant of the embodiment of FIG. 2A is shown. This variant uses the flexibility and ease of connecting a personal computer to a network. This connection allows in effect the transfer of a part of the software-filter, and in particular of the secrets, to a server with guaranteed security Ssec.

In the case of FIG. 2B, the software-filter is decomposed into two software modules, an F-PC module implanted in the personal computer PC 102 and an F-SE module implanted in a security server Ssec. The programmable memory to which we have referred before and which registers the software-filter, is therefore implemented in this variant of execution on the server with guaranteed security Ssec, that is to say, out of the reach of unauthorized users. Likewise, the software-filter, or at least the sensitive part of the software-filter F-SE that requires protection, is executed on the Ssec security server.

The F-PC software module implanted in the personal computer PC 102 is connected by a security channel CS to the security server Ssec. This security channel is in fact an encrypted communication channel that allows a protected data exchange between the two software-filter modules F-PC and F-SE and eventually a reciprocal authentication of the two modules F-PC and F-SE. This security channel can, for example, be based on well-known communication protocols such as SSL.

The establishment of this CS security channel therefore allows the first F-PC filter software module to transmit to the second F-SE filter software module, the requests received from the FAp application through the F-API logical interface, as well as the information linked to the identification of the application that issues these requests. This second F-SE software module, after having verified the information related to the application and, depending on the application and possibly the user's rights, translated these requests into a series of orders for the electronic card 31 and to control data exchanges with the user. These orders created by the FSE module are then sent to the first F-PC module, which leads them to the corresponding element: the PC itself, with regard to requests for control of exchanges with the user or the card of Integrated circuit. In order for the control orders of the exchanges with the user to be executed on the PC, the PC should include a software module, called an interpreter. This interpreting software allows the signaling of messages on the screen

ES 2 173 740 T3 and the insertion of information by the user on the keyboard 5. This interpreting software module will be described in greater detail with respect to Figures 4B and 4C.

This second form of execution is based on the mechanisms described with respect to the first form of execution of figure 2A with regard to the identification of the application (control or signature for example) and the protection of the orders sent to the card. (Adding a MAC message authentication type code, for example). On the contrary, it offers a higher degree of security since the F-SE filter software module that ensures the translation of the high-level requests received from the Fap application runs in a surrounding environment of guaranteed security. Within the context of the invention, it is said that the Ssec server presents guaranteed security if it is not accessible physically as well as logically, that is, through a network connection, to unauthorized persons.

This second form of execution of figure 2B is well suited to applications carried out in a closed or private surrounding environment regulated by a central authority, since it requires a protected server whose administration must be centralized. This second mode of execution also offers the possibility of defining a centralized access policy to the cryptographic services offered by the integrated circuit card. This access policy can be based on the applications that the card's services require and on the users themselves. It allows, for example, in the case of a company that has distributed integrated circuit cards to its employees or customers that allow them to sign emails as well as banking operations, to ensure that only authorized users can sign: This mechanism can be applied using the CS security channel. In each signature request issued by one of the applications considered valid by the company (the electronic messenger and the banking transaction software), the F-SE software module will make a request for user authentication. This request can, for example, be made by sending a random number, challenge or challenge through the security channel CS to card 31. After use by the user of his confidential code, the integrated circuit card will calculate a password or dynamic key encrypting the challenge by means of a secret key that it contains. The command will then be transmitted through the CS channel to the F-SE software module. The F-SE software module, which knows the user and therefore the secret key contained in his card, will compare the received password with the expected password. This mechanism, known as challenge-response mode authentication, allows the F-SE software module to validate the identity of the user. This therefore allows the company that has sent the integrated circuit cards to the users to ensure that only the users authorized up to now can, for example, sign bank transactions.

The Ssec server, thanks to the means with guaranteed and centralized security that it represents, allows not only a security implementation of the F-SE software-filter but also the possibility of installing a centralized control policy of the use of the security services offered. by the integrated circuit board. The Ssec server allows the establishment of a centralized policy since the same server can be related to a plurality of the F-PC software modules implanted in the personal computers of a plurality of users. The Ssec server thus allows the definition and centralized control of the conditions of use of the security services offered by the cards sent to the different users, depending on the profile of the application that requires the services and rights of said users. The establishment of this centralized policy therefore implies registering the necessary information on the server, that is, the rights of the users to use such security service in relation to such application.

This second form of execution of figure 2B, well adapted to private environments, is, on the other hand, hardly applicable to open applications in which the possibility of installing a central security server Ssec cannot be considered.

Figure 3 represents a terminal module that uses functional architecture principles similar to those of Figure 2B in a different embodiment, which does not need a centralized server. The terminal module according to the second embodiment of figure 3 presents a very high degree of security, which thus allows it to directly ensure the local protection of the software-filter F.

In the case of figure 3, the terminal module 1 is presented in the form of a box, portable or not, one face of which presents the signaling screen 4 and the keyboard 5 and in which electronic circuits have been implanted, preferably in such a way that they are inaccessible from the outside. The box 1 contains the reader 6 and has a reception opening for the microcircuit card 31 in the reader 6. The embodiment described with reference to Figures 3, 4A, 4B and 4C should not be considered as limited to a particular terminal. The description that follows can be perfectly applied to a terminal built around a personal computer of the PC or NC type.

According to a first embodiment, illustrated in figure 4A, of this second form of embodiment of the terminal module of figure 3, the electroanic circuits of the terminal module 1 are arranged around a standard type microcontroller 2 and a microprocessor 3 safety devices, linked together by a connection and permanently implanted in the box of the module 1. As a variant, the microprocessor 3 can be plugged into the module 1 by means of a connector 41 shown in broken lines in FIG. 4A. A generic form of execution based on a micro-regulator of the normal type is described here. In a particular embodiment that will be described later, the micro-regulator 2 may in fact be a PC 102 of the type shown in Figure 2B.

ES 2 173 740 T3

The normal micro-controller 2 comprises a processing unit 2a, a temporary memory (RAM) 2b, and a permanent memory (ROM) 2c. It is preferably a "monochip" microprocessor whose program is hidden in the permanent memory 2c and which integrates in the same integrated circuit some means of management or control of standard interfaces, the processing unit 2a and the temporary memories 2b and permanent 2c .

The interfaces or peripherals regulated by the micro-regulator 2 comprise in particular the screen 4 for signaling data, for example by liquid crystals, the keyboard 5 for entering data by a user, the microcircuit card reader 6, an interface 7 external connection, for example the RS232 or PCM-CIA type, an infrared connection interface 8, and a DTMF device 9 for data transmission over a telephonic line.

The components of module 1 also comprise a clock 10 and a power supply 11 for the different circuits and components of module 1. The power supply 11 can be made up of batteries or a battery if module 1 is portable and autonomous. .

The task of the standard micro-regulator 2 is to regulate the environment, that is, to regulate the interfaces 4-9 and the clock 10, as well as the power supply 11 to selectively supply the safety microprocessor 3 with electrical energy in the case of a standalone module 1.

The normal micro-controller 2 requires only little computing power, little temporary memory (RAM) and no semi-permanent memory (EPROM or EEPROM). The micro-regulator 2 was write protected due to the fact that its programs (interface control and, as described later, interpreter, clock and power supply management, etc ...) are hidden in permanent memory 2c. As we will see later, the normal micro-regulator 2 can also contain one or more secret parameters, on the basis of which it can be authenticated by the security microprocessor of the terminal module and / or of an integrated circuit card. These secrets must therefore be protected in reading and writing. It will preferably be registered in the temporary memory (RAM) of a "monochip" microprocessor that is not accessible in writing or writing from the outside. The normal-type microcontroller 2 can also be provided with complementary security functions, for example to prevent fraud such as the signaling of data different from that coming from the microprocessor 3.

It is therefore a low-cost micro-regulator with low electricity consumption, which is particularly suited to a portable product. This micro-regulator can be, for example, of the type MSM 63180 from the OKI Company.

Preferably, two clocks are provided at 10: a low frequency clock 10a, for example with a frequency of 32.368 KHz and a high frequency clock 10b, which can be from 1 MHz to 12 MHz for example. The micro-regulator 2 activates the connection of its system clock on one or the other of these two clocks.

The slow clock 10a regulates a timing device 2d of the micro-controller 2 in rhythm with a period of 0.5 s to realize a real time clock in the module 1. The processing unit 2a can also work using the slow clock 10a for functions that do not require calculation speed: in this case, the system clock of micro-controller 2 remains connected to the slow clock 10a and the fast clock 10b stops. This form of operation makes it possible to limit the electrical consumption of the module 1, which is advantageous if it is portable and powered by an electrical battery.

The read and write security micro-processor 3 comprises a central unit 3a and temporary memories (RAM) 3b and permanent (ROM) 3c, as well as a semi-permanent electrically reprogrammable memory (EEPROM or Flash RAM for example) 3d for the registration, among others, of the application programs of module 1.

This security microprocessor 3 is of the type used in microcircuit cards and has a limited number of inputs and outputs, its internal collectors being inaccessible from the outside. Due to its manufacture, it integrates other security mechanisms typical of this type of microprocessor and well known to specialists in the field, such as security matrix, memory interference, clock frequency control, reset control (RESET). , etc...

Thanks to the fact that the microprocessor 3 has a 3d semi-permanent memory, it is possible to load in oil from the outside, for example from a server or from a microcircuit card, one or more application programs. It is thus possible, depending on the needs, to evolve the application or applications (access control, financial and / or commercial transactions, electronic purses, etc ...) for which module 1 is intended. It is also possible, if the dimension of the 3d semi-permanent memory allows it, to implement new applications in the course of its use.

According to the version chosen, the security microprocessor 3 can ensure the calculation of cryptographic functions that require important calculations carried out in asymmetric algorithms of the RSA or DSA type, or else use more simple algorithms, for example of the DES type.

The security microprocessor 3 can be, for example:

- a SIEMENS SLE44C160S microprocessor, non-cryptographic, equipped with 14 Ko of ROM memory and 16 Ko of EEPROM memory;

- a cryptographic SGS THOMSON ST16CF54A microprocessor equipped with 16 Ko of ROM memory, 4 Ko of EEPROM memory and 480 bytes of RAM memory;

- a PHILIPPS P83C858 cryptographic microprocessor equipped with 20 Ko of ROM memory and 8 Ko of EEPROM memory.

ES 2 173 740 T3

The security microprocessor 3 was connected, on the one hand by connection 12 to the standard microcontroller 2, and on the other hand, by connections 13 and 14, to the external interface 7 and to the microcircuit card reader 6 through switches- interface adapters 15 and 16 respectively. The switch-adapters 15 and 16 are actuated by the normal micro-regulator 2 through the connections 17 and 18 respectively.

The normal micro-controller 2 comprises an interpretation program or interpreter 20 (fig. 4B and 4C) registered in ROM memory 2c and which allows it to execute orders generated by the translation software of the high-level requests that are part of the program. or application programs, as described below. This interpreter 20 thus allows the application program or programs registered in the security microprocessor 3 to regulate interfaces 4-9 through connection 12. However, the application program or programs can be located and executed elsewhere than the read and write security microprocessor 13, for example on a microcircuit card 31 inserted in the interface 6, such as an adapted card to support remote loading mechanisms and application execution, as described in the NF EN 726-3 standard entitled “Integrated circuit cards and terminals for telecommunications. Pa rte 3: Specifications independent card applications. "

The application programs can also, depending on the security standards to which they are subjected, be distributed among these different locations.

The functional diagram of figure 4B illustrates a first configuration of the software architecture of module 1 of figure 4A, in which all the application programs A1, A2, ... An and the security functions (condensation calculation , symmetric cryptographic algorithms such as DES, triple DES, or asymmetric such as those proposed by RSA) is applied to the security microprocessor 3.

The applications named above and named after the description A1, A2, ... An comprise as a monym the filters F1, F2, ... Fn, and therefore in particular the software for the translation of the requests issued by the provider or the application service providers FAp that are part of the main application 54 (figure 8A).

The standard micro-regulator 2 regulates the environment through different management programs or interface managers, namely:

- a manager 21 of the reader or interface 6 of the microcircuit card;

- a manager 22 of the serial connection interface 7;

- a manager 23 of the keyboard 5;

- a manager 24 of the infrared connection interface 8;

- a manager 25 of the flagger 4;

- a manager 26 of the clock 10 and of the power supply 11;

- a manager 27 of the DTMF interface 9;

- a manager 28 of other interfaces, in the hypothesis that model 1 comprises one or more interfaces other than those represented in figure 2.

Thus, the security microprocessor 3 can regulate the interfaces by means of commands that will be interpreted by the interpreter 20 and executed by the standard micro-controller 2 through the managers 21-28.

Figure 4C illustrates a second software configuration of module 1 of figure 4A in which one or more applications Ax and one or more cryptographic functions Sx are registered in a reprogrammable memory 30a of a security microprocessor 30 of a microcircuit card 31. When the card 31 is inserted into the reader 6, the microprocessor 30 executes the applications Ax and the cryptographic functions Sx, while other applications and security functions may remain and put into operation by the security microprocessor 3 of the module 1. For example, the microprocessor 30 of the card 31 can ensure an electronic signature function in the hypothesis that the security microprocessor 3 does not integrate a particular computational processor (cryptoprocessor). Reciprocally, if the security microprocessor 3 integrates a cryptoprocessor, it is equally possible that an application present on the microcircuit card 31 uses cryptographic commands of the module 1, which will be executed by the security microprocessor 3.

In this second configuration, which is identical to that of FIG. 4B, the interpreter 20 performs the same mission with respect to the microprocessor 30 as that which it fulfills with respect to the security microprocessor 3. The module 1 can also execute different applications according to the type of microcircuit card 31 inserted in reader 6, for example:

- an authentication of the user within the framework of a bank transaction (account consultation, funds transfer, etc ...) carried out by a telephone line through the DTMF interface 9;

- a query of the balance of an electronic purse, or the charge of this purse, from the module 1, when a microcircuit card 31 that fulfills the function of a purse is inserted into the reader 6. Furthermore, module 1 allows regulating several different coin cards: bank coin holders, specific coin holders for a community, for example;

- reading of a medical record on a medical card;

- reading of loyalty points on a card in which loyalty points have been attributed to a consumer based on purchases made, their participation in customer loyalty operations, etc ...

ES 2 173 740 T3

The form of execution described above in Figure 4A as well as the software configurations presented in Figures 4B and 4C are applied, in an analogous way, to a terminal built around an ordinary PC also equipped with the security microprocessor 3. In this form of execution, the micro-regulator 2 corresponds to the PC 102 as shown in figure 2A, the processing unit 2a corresponds to the microprocessor 102c of the PC, and the RAM 2b and permanent memories 2c correspond respectively to the memory RAM 102d and hard disk 102b. Likewise, the inputs / outputs 102a of the PC correspond to the interface modules 7, 8 and 12 of Figure 4A. The connection between the security microprocessor 3 and the PC 102 can be a serial or parallel connection, or a connection to the PC's internal bus, of the PCMCIA type, or a direct connection to the PC motherboard. As a variant, the security microprocessor 3 can be integrated in a fixed or removable way, through the connector 41, to the keyboard of the PC.

In this case, the interpreting software module 20, as well as the peripheral management software modules 21 to 28 are implanted and executed on the PC. The functional architecture of this form of execution is equivalent to that presented in figure 2B, ensuring the interpreter module 20 is implanted in the PC with the same mission as the interpreter module l in figure 2B: it executes the exchange control commands with the user received from the software-filter F, implanted for his part with security guarantee in the microprocessor 3 (figure 4B) or in the integrated circuit card 30 (figure 4C).

The diagram in Figure 5 illustrates a second embodiment of the second embodiment of the invention, in which the electronic circuits of the terminal module 1 are arranged around a single micro-regulator 29 instead of the micro-controller 2 and the microprocessor. 3, being able to offer the same type of physical and logical protection as the microprocessors designed for integrated circuit cards. This micro-regulator regulates all the interface means 4-9 of the terminal module. It comprises a processing unit 29a, a temporary memory (RAM) 29b, a permanent memory (ROM) 29c and a semi-permanent memory (EEPROM) 29d that allows the registration of the translation software. The processing unit 29a corresponds to a time to the data processing unit 2a that allows the control of the interfaces and to the processing unit 3a that allows the execution of the translation software. As before, the terminal module 1 can be established around a personal computer PC 102 to which a safety micro-regulator 29 would be connected on the internal bus, directly regulating the signaling screen 4 and the keyboard 5 of the PC.

In a variant of realization, the memory in which the translation software for high-level requests is registered, volatile memory of the RAM type with a backup or semi-permanent power supply (EEPROM or Flash RAM), can be external to the micro-controller 29. In this case, the translation software may be encrypted and signed, or protected by a MAC type code (“Message Authentication Code”) to ensure both its integrity and confidentiality. The software is read by the micro-regulator 29, decrypted and then executed.

According to a third embodiment, represented in figure 6, of the second embodiment of the invention, the terminal module 101 was devoid of a security microprocessor 3. In this figure 6, the same reference numbers have been preserved as in Figure 4A to designate the same elements. The microcontroller 2 regulates the interface 6 and the adapter switch 15 to allow the connection of the safety microprocessor 130 of a programmable microcircuit card 131 present in the interface 6 with the external connection interface 7. In this case, the set of applications A and the cryptographic functions C are stored in a semi-permanent memory 130a (EEPROM or Flash RAM) of the security microprocessor

130 of the programmable microcircuit card

131 and they are used by the latter as can be seen in figure 4C in relation to the Ax applications and the Cx cryptographic functions.

In the examples described, in order to achieve greater simplification, the microprocessor 30, 130 of the integrated circuit card, as well as the security microprocessor 3 eventually implanted in the terminal module comprise a single communication point. This implies that in these examples, the exchanges between the different entities, that is, the electronic unit 154 (figure 8) that contains the main application, the security microprocessor 3 and the microprocessor 30, 130 of the integrated circuit card are made through through micro-regulator 2 or 29 of the terminal module. These descriptions should not be construed as limiting; Other embodiments can be considered within the framework of the present invention. Indeed, the currently available integrated circuit card security microprocessors, usable for the card itself (microprocessor 30, 130) or in the terminal module (microprocessor 3), can have two communication points. Different forms of realization can therefore be easily considered to maximize communication flows with this type of microprocessor. In the case of Figure 4C, for example, one of the through points of the integrated circuit board 31 can be dedicated to the control of the user interface and thus be connected to the micro-regulator 2, with the other through point connected the main application to the electronic unit by means of an appropriate interface adaptation.

According to an important characteristic of the invention, a filter-software is implanted in the reprogrammable EEPROM memory associated with the security microprocessor 3 or 29 of the terminal module 1 and / or the security microprocessor 30, 130 of the card 31, 131. This software-filter translates, in a known way, the high-level requests from the SAP server or the personal computer PC into sequences of elementary orders executable by these microprocessors (orders that are defined in particular by the part

ES 2 173 740 T3 of the ISO 7816-4 standard). Furthermore, according to the invention, this software-filter translates these high-level requests into sequences of data exchanges between the terminal module 1, 101 and a user through interface means such as the flag 4 and the keyboard 5.

This solution offers the advantage of considerably reducing the data throughput exchanged between the terminal module 1, 101 and the SAP server or the PC, but it requires a security implementation of the production software to prevent the instructions sent to the card from being modified. microcircuit.

This software-filter is an integral part of the part of the application software implanted in the terminal module 1 and / or the card 31, 131 and can therefore be loaded remotely.

Figure 7 illustrates the conventional software architecture of a microcircuit card ("smart card").

The different layers of software have been represented by a block 43 that comprises a software layer 44 "communication protocol" that allows orders to be received. These commands are decoded by a software layer 45 "APDU command interpretation" (APDU: "Application Protocol Data Unit" whose mission is to direct the commands towards process modules that can be:

- a software 46 for security file management services;

- a software 47 for cryptographic services;

- one or other application software 48.

The process modules 46, 47, 48 are supported by basic services offered by the operating system 49 of the microcircuit card.

Figure 8A represents the software architecture of a system for carrying out security operations that uses terminal modules 1 equipped with a security microprocessor 3, according to the embodiment of the invention of Figure 4A.

Block 51 designates the software executed by the security microprocessor 3 of the terminal module 1, block 52 the software executed by the micro-regulator 2 or PC 102 of the terminal module 1, and block 53 the software executed by the microprocessor 30 of a microcircuit card 31, and block 54 the main application software or application service provider, implemented in the SAP server or a personal computer PC.

Block 51 is similar to block 43 of figure 7, that is, the security microprocessor 3 has an architecture similar to that of an integrated circuit card. Block 51 comprises:

- a communication protocol software 60,

- a system of exploitation 61,

- a block 62 representing the part of the application software implanted in the terminal module 1, this part of the application software being essentially constituted by said software-filter. Different software modules of this type, corresponding to different applications, can coexist within the security microprocessor 3;

- optionally, a software 63 that makes it possible to ensure the authentication of the normal type micro-controller 2 by the security microprocessor 3 and the authentication of the security microprocessor 3 of the terminal module 1 by the microprocessor 30 of the card 31,

- a security file management software 64,

- a software 65 of cryptographic services.

Block 52 comprises:

- a communication protocol software 70;

- a command interpreter 71 corresponding to the software 20 of Figures 4B and 4C;

- an authentication software 72 that allows, in connection with the software 63, the authentication of the normal microcontroller 2 by the security microprocessor 3 of the terminal module 1;

- some software 73 for managing the internal resources of micro-regulator 2;

- some software 74 for controlling the interfaces with the user (managers 23 and 25 of screen 4 and keyboard 5);

- some 75 software to control communication interfaces 7, 8 and 9 (managers 22,

24, 27).

Finally we will say that block 53 is similar to block 43, but does not include, in the example shown in figure 8A application or filter software. Understands:

- a communication protocol software 80,

- A software 81 for the interpretation of orders

APDU,

- a software 82 for security file management services (PIN control for example),

- A software 83 for cryptographic services (symmetric cryptographic calculations regarding secret or asymmetric keys, public keys and private keys, etc ...) that allows, among other things, to ensure, in connection with the software 63, the authentication of the microprocessor security 3 of terminal module 1 by microprocessor 30 of card 31,

- the operating system 84 of the microprocessor 30 of the card 31.

The communication protocol 60, 70, 80 allows to regulate the data exchanges between:

ES 2 173 740 T3

- the microprocessor 30 of the card 31 and the micro-regulator of normal type 2 or PC 102 of the terminal module 1;

- the safety microprocessor 3 and the micro-regulator 2 of the terminal module 1;

- the security microprocessor 3 of the terminal module 1 and the microprocessor 30 of the card 31.

Figure 8B is a view similar to that of figure 8A, which illustrates the software architecture of the system in the event that the terminal module 101 does not include the security microprocessor 3, according to the third mode of execution of the second mode of embodiment of the invention of figure 6.

In figure 8B, block 152 designates the software executed by the micro-controller 2 of the terminal module 101, block 153, the software executed by the microprocessor 130 of a programmable microcircuit card 131, and block 154 the main software of application implanted in the SAP server or a personal computer PC.

Block 152 comprises the same software 70, 71 and 73 to 75 as block 52 of figure 8A, and a block 76 which is an authentication software of the normal type micro-controller 2 of the terminal module 101 with respect to the microprocessor 130 of card 131.

Block 153 related to the microprocessor 130 of the card 131 comprises the software 62 and 80 to 84 of the blocks 51 and 53 of figure 8A, as well as a software 77 that allows, in connection with the software 76, to ensure the authentication of the micro-controller of normal type 2 of the terminal module 101 with respect to the microprocessor 130 of the card 131.

Unlike an ordinary system, in the security transaction system according to the invention, the software-filter 62 that translates the high-level requests of the application into elementary orders executable by a microcircuit card is implanted close to the user with guarantee. security, that is, either in terminal module 1 (for applications A1, A2 ... An of the execution forms of figures 4A-4C and 5), either in a card 31, 131 with semi-permanent memory usable with terminal module 1, 101 (for Ax applications of the embodiment of figure 4C and for all applications of the embodiment of figure 6).

In addition to its function of managing a microcircuit card, this software-filter 62 regulates interactions with the user, that is, the data exchange sequences between a user and the terminal module that are required within the framework of an application, exchanges that take place through the interface means, that is, the screen 4 and the keyboard 5. It should be noted that the invention is not limited to the use of a screen and a keyboard as interfaces with the user and that any other type of interface, for example vocal, that presents the required ergonomics could be suitable.

Thanks to the security implantation of the software-filter 62 in the security microprocessor 3 or 29 of the terminal module 1 or the microprocessor 30, 130 of the micro-circuit card 31, 131, the security of the operations is guaranteed. Indeed, the keys and rules necessary to access files on the microcircuit card 31, 131 are contained in the translation software 62 and are therefore inaccessible to third parties.

The functions fulfilled by the software-filter 62 will appear as illustrated below, on the example of an application corresponding to electronic commerce, the application uses the following entities:

- a buyer

- a comerciant

- a bank.

The merchant has a Sap electronic commerce server (Web server) accessible from the Internet. Buyers are equipped with:

- a PC that allows access to the Sap e-commerce server, and thanks to which the buyer can consult a catalog of goods,

- an integrated circuit card 31 supplied by the bank and whose microprocessor 30 contains a private key, but does not have cryptographic capabilities that allow a signature to be carried out,

- a terminal module 1 according to the embodiment of figure 4A, equipped with a standard micro-regulator 2, a security microprocessor 3 that has cryptographic capabilities that allow the signing of a message, a keyboard 5, a signalizer 4, an integrated circuit card interface 6 and a serial interface 7 for connection to a PC.

The operating principles are as follows: the transaction is signed by terminal module 1 by means of a private key that the card 31 has. This private key is protected by a confidential carrier code (PIN) that the buyer must keep in a medium. security, therefore in terminal 1, and by a previous authentication of terminal 1 by card 31 using a secret key Kauth. Furthermore, the private key is transmitted in an encrypted manner (by a Kchif key) to establish a communication channel with guaranteed security between the microprocessor 30 of the integrated circuit card 31 and the security microprocessor 3 of the terminal 1.

Figure 9 illustrates the exchanges between the different entities:

to. the buyer places his order on the PC computer,

b. the PC computer prepares the transaction to be signed by the buyer (reference, item, price) and requests the signature of this transaction from terminal module 1,

ES 2 173 740 T3

c. the terminal module verifies the origin of the signature request and then requests the use of the PIN code by signaling a message "PIN use" on its flag 4,

d. the buyer uses his carrier code (PIN code) on keypad 5 of terminal module 1,

and. PIN was sent by terminal module 1 to card 31 for verification. As this verification is positive, it causes the fulfillment of one of two conditions of access to the reading of the private key,

F. terminal module 1 signals the transaction in its signalizer 4,

g. the buyer gives his consent by pressing a "validation" key on the keyboard 5 of the terminal module 1,

h. the terminal module 1 submits an external authentication request to the card 31. This external authentication allows the security microprocessor 3 of the terminal module 1 to authenticate with respect to the microprocessor 30 of the card 31 and lift the second key access protection private. This authentication is carried out in the form of a challenge / response based on a Kauth secret, shared by terminal module 1 and card 31,

i. terminal module 1 sends a private key read request to card 31,

j. Once all the access conditions have been met, card 31 accepts the read request and forwards the private key, encrypted with a secret key, Kchif, shared by card 31 and terminal module 1,

k. Terminal module 1 decrypts the private key, signs the transaction using the private key, destroys the private key, disconnects from card 31 and sends the subscribed transaction to the PC that transmits it to the server S.

This example can easily be transposed to an electronic transaction carried out without a PC, connecting directly the terminal module 1 to a Sap server through a modem connection (figure 3), the buyer inserting the order (reference, product) in the terminal module 1.

It should be noted that the authentication of the security microprocessor 3 by the card can also be carried out through the private key reading order, associating a MAC authentication code (Message Authentification Code) calculated by means of a secret key.

This example shows that the software-filter 62 makes it possible to translate a high-level request "transaction signature request" into a multitude of elementary requests addressed to the different interfaces of terminal module 1, namely: interface 6 with the circuit card integrated 31, the pointer interface 4, the keyboard interface

5, the connection interface to the PC or the SAP server.

Such a translation software-filter has a screen mission, as a filter between the outside world, that is, the applications, and the peripherals that it regulates.

It improves the security offered, due to the fact that:

1. imposes a sequence on the elemental orders sent. For example, in the case illustrated above, it requires that the transaction be validated by the user before being signed;

two. It only has the secret parameters that allow the generation and authentication of these elementary orders. Thus, it only has the authentication and encryption keys that allow the private key to be read and decrypted.

When the software-filter has been executed in the security microprocessor 3 of the terminal module 1, these properties make it possible to impose an access policy to the card 31, a policy that is not always completely imposed by the card itself, or to extend the capabilities of a card (signature capacity delegated to the terminal module, use in a context not foreseen in its initial deployment).

The advantages offered in terms of security by the execution of the software-filter in the security microprocessor of the terminal module or in that of the integrated circuit card are not possible except because the software is executed within a security environment that allows what:

- the secrets contained by the software-filter are not accessible due to being memorized within the security microprocessor 3, 29, 30 or 130,

- The confidentiality and integrity of the software-filter are preserved, since this software is memorized in the security microprocessor 3, 29, 30 or 130.

In the event that the terminal module 1 is a customized product, which has its own interfaces, signaling device 4 and keyboard 5, the security objective was achieved thanks to the fact that the software that regulates data exchanges with the user does not It can be modified, since it is permanently registered in the permanent memory 2c of the micro-regulator 2 or with a security guarantee in the micro-regulator 29. The user can also confidently validate the content of his transaction using the flag 4 and the keyboard 5, making optional the need to verify the identity of the application or the origin and integrity of the requests.

Other mechanisms can further improve the security level of the chain of trust between the security micro-processor of the integrated circuit card, the eventual security microprocessor of the terminal module, the standard micro-controller or the PC of the terminal module and the user. These mechanisms are the following:

ES 2

A) remote loading, security, of the filter software;

B) authentication of the standard micro-regulator by the security micro-processor or, which is equivalent but was better adapted in the case of a terminal execution mode around a PC, authentication of the interpreting software module l (20) by the software-filter F (62), and / or establishment of a security communication channel between these two microprocessors or the software and F,

C) protection of a secret by the standard micro-regulator,

D) mutual authentication and establishment of a communication channel with security guarantee between the security microprocessor of the integrated circuit card and the security microprocessor of the terminal module,

E) authentication of the terminal module and possibly the terminal module-card pair,

F) authentication of the microcircuit card by the terminal module.

A) Remote loading of the software-filter

The flow chart of figure 10 illustrates the process of remote loading of an application program (software-filter) in the security microprocessor 3 or 29 of module 1 or the security microprocessor 30, 130, of a present card 31, 131 in reader 6. This remote upload can be carried out from a SAP server through, for example, the personal computer PC and the external connection interface 7 or the infrared connection interface 8, or directly through a telephone connection using the DTMF connection interface 9 . Remote charging can also be carried out in the security microprocessor 3 or 29 (if the terminal module is equipped with it) from a microcircuit card inserted in the reader 6.

In step 32, the memory area 3d assigned to the application program to receive this empty and the microprocessor 3 is waiting for the application program to be loaded after a load request.

The following stage 33 corresponds to an authentication process by the microprocessor 3 of the entity that must remotely load the application program (Issuer). This authentication process can resort, for example, to encryption mechanisms well known to those skilled in this art, for example symmetric mechanisms with shared secret keys or asymmetric mechanisms of private key and public key.

Step 34 is a test to determine if the authentication process has been successful: if not, the message "access denied" is set on screen 4 (step 42) and the program returns to step 32; If so, the application program loading process begins in step 35.

Step 36 corresponds to the recording in the 3d EEPROM memory of the data frames transmitted by the entity that carried out the remote upload.

740 T3 34

Step 37 is a test to determine if remote charging has been completed: if not, the remote charging program returns to step 36 and continues remote charging; If so, in step 38 a verification of the integrity of the data received by the microprocessor 3 is carried out. For this purpose, a message authentication code (MAC) can be associated with the downloaded program to allow verifying not only its integrity, but also its origin. The MAC can be produced using a symmetric cryptography mechanism (DES in CBC chain mode). Verification of the origin and integrity can also be carried out by means of an asymmetric cryptography mechanism: a condensate of the downloaded software is signed by the issuer using its private key; the security microprocessor 3 then verifies the signature using the issuer's public key.

It should be noted that in this last example, the public key, in principle, does not need to remain confidential. However, the security provided by the microprocessor ensures the integrity of the software, preventing a fraudster from modifying the software to suppress the signature verification or simply replace the public key initially provided for a public key with respect to which they know the associated private key.

If after test 39 it is observed that the received data is correct, a flag is generated in step 40 indicating that the application program has been validated. Otherwise, the remote charging program returns to the initial stage 32.

This process of loading the application software, and therefore the filter-software, in the reprogrammable security memory (3d, 30a, 130a according to the form of implementation), includes mechanisms that allow confirming the origin and integrity of the received data. of the issuer of the software. This makes it possible to prevent the remote loading by a fraudster of a software-filter that could carry out transactions in the terminal module 1, 101 behind the user's back.

B) Authentication of the interpreting software module 1, 20, 71 by the software-filter F, 62 or, which is equivalent in the corresponding execution form, authentication of the standard micro-controller 2 by the security microprocessor, and / or establishment of a security communication channel between these two software or these two microprocessors

In order for a user to have total confidence in the terminal module through which he carried out transactions, it is necessary:

- authenticating the data transmitted from the interpreting software 20, 71 to the security microprocessor 3, 30 or 130 that executes the filter software;

- make sure that the data transmitted by the software-filter to be signaled through the interpreting software of the terminal module 1, 101 owned by the user cannot be more than by the user.

ES 2 173 740 T3

When the means for regulating the data exchanges with the user, that is, the interpreting software 20, 71, have been implanted in a fixed and non-modifiable way in the terminal module 1, 101, as for example in the ROM memory 2c of the micro-regulator standard 2, the authentication of the software module is equivalent to the authentication of the micro-regulator.

Likewise, when the software-filter has been implemented so that it cannot be modified by an unauthorized person, in a security process means such as the security microprocessor 3, the integrated circuit card or the security server Ssec, a Authentication carried out by these security means is equivalent to an authentication carried out by the software-filter itself.

In the description that follows, we will describe the authentication mechanisms of the software means of regulating the interfaces or interpreting software 20, 71 by the software-filter.

Different solutions make it possible to meet these conditions.

A first solution consists of encrypting all the data exchanged between the interpreting software 20, 71 and the filter software.

A second solution consists in making the interpreting software 20, 71 authenticate by the filter software and / or establishing a security communication channel between these two software.

These two solutions necessarily imply that at least one secret parameter known by the software-filter F 62 is registered in the interpreting software 20, 71.

According to the second solution, the filter software F 62 authenticates the interpreting software 20, 71 following an ordinary authentication process, on the basis of information transmitted by the interpreting software 20, 71, and combined with the secret parameter. At the level of the interpreting software 20, 71, this authentication process is carried out by the software 72 (figure 8A) or the software 76 (figure 8B), according to the embodiment of the terminal module.

This authentication mechanism can also be applied to the messages exchanged between the two software to establish authentication codes of the messages that allow guaranteeing the origin and integrity of each transmitted message.

In the case of the execution modality described in Figure 4A, this solution requires, however, that, preferably, a physical protection of the connection between the two microprocessors be ensured to prevent a fraudster from reading the exchanged data and, in In particular, the personal identification code (PIN) of the card that the user can enter through the keyboard 5 to carry out transactions.

C) Protection of a secret parameter by the standard micro-regulator 2

The preceding description shows the need to register at least one secret parameter in the interpreting software. The form of execution of the terminal from a PC, in which the interpreter software is executed on the PC itself, offers therefore, due to the limited security of the

PC a limited degree of security, although sufficient, to prevent a virus from replacing the interpreter software. A higher degree of security is achieved by implementing the interpreting software in ROM 2c of the standard micro-regulator 2. To improve security, the secret parameter of the micro-regulator 2 could be registered in the temporary memory, and this at the time of manufacture of the product or, eventually, when the security microprocessor 3 is inserted if it is removable, or a card integrated circuit. The purpose of this operation is to establish trust between the two microprocessors. Every useful precaution must be taken in the course of this operation to ensure the authenticity of micro-regulator 2 (operation carried out in the factory, operation protected by transport codes, registered in the temporary memory of micro-regulator 2 at the factory. , and whose knowledge conditions the initialization operation of said secret parameter). In addition, ordinary intrusion detection mechanisms (contacts ...) were established to cause the erasure of the temporary memory in case of intrusion (power failure ...).

D) Mutual authentication and establishment of a security communication channel between the microprocessor of the integrated circuit card and the security microprocessor of the terminal module

This mutual authentication and the establishment of the security communication channel is carried out by applying mechanisms identical to those used between the standard micro-regulator 2 and the security microprocessor that executes the software-filter, as described in point B) .

E) Authentication of the terminal module

It is important to protect against any attack against the keyboard set 5, flagger 4, security microprocessor 3, with respect to, for example, attempting to counterfeit terminal module, replace a terminal module or a false terminal module in order to retrieve information set by the user. (spying on the keyboard), accessing the secrets of an integrated circuit card, making false signatures.

To do this, a mechanism may be added that allows the user to authenticate their terminal.

This objective is achieved through an automated personalization process.

Authentication of the terminal module only

Personalization can consist of calculating an easy-to-remember password word, generated and signaled by the terminal based on the secret parameters contained in the microprocessor or in the terminal's microprocessors, when the user enters a PIN. If the terminal has, for example, two microprocessors, the password is registered in the security microprocessor, encrypted by the PIN and a secret key X, and then it is transmitted to the micro-controller 2 for decryption with the key X also registered in micro-regulator 2 and the PIN entered by the user. This mechanism is intended to protect against the substitution of one of the two microprocessors.

The same principle can be applied to a card / terminal pair each time a tar19 is used.

ES 2 173 740 T3 microcircuit card with terminal module. Personalization may consist, for example, in the calculation, by means of the translation software, of a password word based on a secret information contained in the security microprocessor of the card and of one or more secret information contained in the terminal module. The same principle as described can be used to calculate the password word. This password word, generated on the first use of the terminal module in conjunction with the card and known by the user, is signaled on the screen 4 in the course of subsequent uses of the terminal module with the card. The user can thus verify it and thus have the assurance that the terminal in his possession, consisting of the terminal module coupled to the card, is perfectly authentic.

F) Authentication of the micro-circuit card by the terminal module

To further increase the security of the transaction system according to the invention, a conventional authentication process can be used to ensure authentication by the terminal module 1, 101 of the microcircuit card used. Such authentication process allows in particular to prevent the user's personal identification number (PIN), which you enter in module 1, 101 by keyboard 5 to execute a transaction with security guarantee, from being captured by a forged card that will have been replaced by action of a fraudster to the user's authentic card and that later will recover this fraudster to read the PIN on the forged card. Authentication can, for example, be carried out by a classic challenge / response mechanism by means of a shared secret between the card and the terminal module, using symmetric cryptography or, as previously described, by means of a private key. registered by the card that allows the encryption of the challenge by means of an asymmetric algorithm, the terminal module verifying the response by means of its public key.

The architecture of the transaction system as well as the security mechanisms that are described contain a very high security to the transactions carried out through the terminal module 1, 101.

This terminal module allows:

- thanks to the keyboard 5, the screen 4 and the protection of the data exchanged with the user, extend the nature of the services that are really guaranteed that a microcircuit card can provide;

- use the card in the context of a surrounding environment not guaranteed in security (personal computer PC capable of being affected by viruses or pirated programs), hermetically isolating it from this surrounding environment thanks to a software architecture and / or material that strictly regulates access to the card, that is, it regulates the orders sent to the cryptographic functions contained in the card.

The terminal module can have different shapes, such as:

- an integrated circuit card reader, connectable to a computer through different interfaces (PCMCIA ...) or not (connected to a server via modem);

- a computer (PC) whose user interfaces are made up of the PC screen and keyboard, and which includes an integrated circuit card reader. This PC will include some software and / or materials (such as a second security microprocessor, the standard micro-regulator being constituted by the PC) to ensure the integrity and confidentiality of the software-filter. By computer we mean a PC type computer, but also a PDA ("Personal Digital Assistant" or Assistant Numáerique Personnel);

- a keyboard, possibly provided with an LCD signaling screen, where a security microprocessor and an integrated circuit card interface are integrated;

- a telephone optionally equipped with a signaling device, in which a security microprocessor and an integrated circuit card interface are integrated;

- a cable TV network set-top box that integrates an integrated circuit card reader connected to a television set, the television set serving, a keyboard or possibly the remote control associated with the decoder or the televisions as means of interface with the user;

-more generally all equipment whose security can be guaranteed by integration of a security microprocessor in which a so-called sensitive application can be installed, or by integration of an integrated circuit card interface that allows the regulation of said equipment by an application transferred to an integrated circuit card.

The whole of the preceding description describes a terminal intended to be used with an integrated circuit card or "smart card". The card to which we refer is in fact an instrument that allows the realization of cryptographic and personalized functions in relation to a user by means of at least one secret. It is evident that the object of the invention is not limited to an instrument of a certain shape, such as that of the integrated circuit card. The invention also covers the application of personal security devices that can offer functions equivalent to those of an integrated circuit card, but presented in a different form, such as the products "Button", "Java Ring" or token ("token" ).