HK1026762B - Terminal and system for implementing secure electronic transactions - Google Patents

Description

The present invention relates to a terminal and a system for the implementation of secure electronic transactions.

Public digital data networks, such as the Internet, are undergoing considerable development, but one of the current barriers to the implementation of secure electronic transactions on this type of network is the inadequacy of the security mechanisms associated with such transactions, which results in a lack of trust among users and network operators.

For the purposes of this application: an electronic transaction means an exchange of information, via a public digital data transmission or telecommunications network, between two or more users or between a user and a service provider,a function is processing carried out with the aim of providing a service to a user,an application means a coherent set of services and functions,application software means the software or software necessary to implement the functions of a given application,a secure transaction is a transaction for which certain security measures are taken, namely authentication of the entities participating in the transaction, integrity, confidentiality, authentication, and possibly the repudiation of transactions and exchanges carried out in the context of the transaction.

Many applications require that electronic transactions be secure, such as access control to computer resources or similar, home banking (consultation, bank account movements, etc. via the telephone network or the Internet), electronic commerce (purchase of goods or services via a public network), e-mail, e-wallet, etc.

These and other applications requiring secure transactions are well known to technical experts and are not described in detail here.

Depending on their nature, the security of these applications requires the implementation of one or more security services such as: Authentication, which ensures the identity of an entity (person or system);access control, which provides protection against unauthorised use or manipulation of resources;confidentiality, which prohibits data from being disclosed to unauthorised entities;data integrity, which ensures that data has not been altered, deleted or substituted for without authorisation;non-repudiation, which ensures that a participant in a data exchange cannot subsequently deny the existence of the data exchange.

The combination of two existing techniques allows for the implementation of these security services to be considered, thus providing a sufficient level of security for electronic transactions.

Err1:Expecting ',' delimiter: line 1 column 219 (char 218)

The following services are provided by the integrated circuit boards: * the authentication of the cardholder or user: this operation allows the cardholder to be authenticated by means of a confidential code and the card to subsequently accept the implementation of operations such as running algorithms, reading secret keys, reading and/or writing data to the card, which may also be subject to other security conditions;* the protection of data and functions stored on the card on an integrated circuit.This external authentication is usually done in challenge/response mode. In this case, the entity has a secret parameter, hereinafter also called secret, which allows it to calculate, based on a challenge issued by the card, a response that will prove to the card that it is in possession of the secret;* execution of cryptographic algorithms using a secret parameter stored in the card (encryption, message authentication, signature) * internal authentication. This service allows an application to authenticate the card. This service is the opposite of an external authentication.

The services offered by the integrated circuit board are implemented upon receipt of so-called elementary commands, the execution of the elementary command causing the sending of elementary responses. These elementary commands concern, for example, cryptographic calculations, reading or writing of secret or not, user interventions (entering his personal confidential PIN code, validation of a transaction after signature), feedback to the user (display of messages to sign, for example).

Some cards offer the possibility to verify the integrity, origin, or even confidentiality of orders sent to the card.

The current use of integrated circuit (or microcircuit) cards offers a very high degree of security because transactions are mainly carried out on private networks and terminals (e.g. ATMs, point of sale terminals) which are under the control of an entity that ensures the security of the entire system.

In such applications, users or potential fraudsters do not have access to the application software, nor to the hardware and software security mechanisms of the terminals.

On the other hand, the implementation of secure transactions with integrated circuit boards on a public network requires that users have at their disposal a card reader terminal module, since such microcircuit boards do not have a clean electrical power source and their implementation requires a reader capable of feeding them and establishing communication with the user and/or external electronic means.

Currently, to carry out a transaction on a public network, the user has a terminal, which can be a dedicated product, a personal computer, or a personal computer coupled to a circuit board with an integrated card reader.

Err1:Expecting ',' delimiter: line 1 column 308 (char 307)

The application service provider issues high-level security service requests to ensure the security of the transactions implemented.

Err1:Expecting ',' delimiter: line 1 column 274 (char 273)

Where the user does not have an integrated circuit card reader, cryptographic services shall be provided by software only.

When the user wants to improve security, they use a transparent type integrated circuit card reader connected to their computer. A transparent type integrated circuit card reader is actually an interface box between the computer and the integrated circuit board that allows for the transmission of basic computer commands from the cryptographic service provider to the card, and basic card responses to the computer. A user can, using this terminal, (consisting of his terminal module - computer + reader - coupled to his card) perform electronic transactions (e.g. e-commerce).

Of course, users' access to such a terminal creates potential security risks.

The risks involved will be the greater the more decentralised the applications will be. and vice versa, the more decentralised the applications will be, the more the terminal risks will be controlled. For example, wallet-type applications can be considered, in which transactions (debit from the buyer's card/credit from the merchant's card) will be card-to-card, without the need for consolidation of transactions at the level of a central server.

It follows from the above that a terminal may potentially contain a set of information, or even software, on the confidentiality and integrity of which the security of the application depends. Examples include secret keys used for authentication of the terminal module vis-à-vis 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 analyse its operation and access confidential information and software.

Err1:Expecting ',' delimiter: line 1 column 904 (char 903)

The systemic risks are then as follows: Attack on the integrity of the cryptographic service provider and the application service provider aimed at changing the behavior of the terminal module: for example, the terminal module is modified in such a way as to capture the card-related information, store the information obtained and then communicate it to a fake server. This attack can be carried out without the knowledge of the legitimate user (replacement of the user's terminal module or lending a modified terminal module). This attack can then be generalized in the form of the dissemination of counterfeit terminal modules; Attack on the privacy of the cryptographic service provider,An attack on other cards, based on the ability to authenticate oneself to these cards, thanks to the secrets discovered by an attack on the confidentiality of the service provider.An attack on the integrity and confidentiality of communications between different entities (application service providers, cryptographic service providers, integrated circuit reader, integrated card, server) that breaks the chain of trust established between these elements. 1 - decryption of communications between server and terminal;2 - insertion of third party software between the application service provider and the cryptographic service provider to break the chain of trust between these two software or substitution of application software by third party software to make the security service provider execute security requests for a purpose other than that of the application known to the user.Server attack (in the case of a connected application): connection of a counterfeit terminal to a server, emulation of a terminal module-ICU card pair to gain advantages.

Err1:Expecting ',' delimiter: line 1 column 692 (char 691)Err1:Expecting ',' delimiter: line 1 column 176 (char 175)Err1:Expecting ',' delimiter: line 1 column 178 (char 177)

If the integrity of the application software (application service provider and its cryptographic service provider) is not ensured, a fraudster does not need to know the secret keys and codes to hack into the transaction system: he simply implants in the terminal module, for example in the personal computer to which an integrated circuit card reader is connected, a virus-like software which, in step 3, hijacks the authentic data to be signed and steps up to the falsified data.

The above example shows the need to protect not only the confidential information implemented in a transaction, but also the integrity of the transaction, i.e. the integrity of the behaviour of each entity involved in the transaction, as well as the integrity of the overall behaviour of the software by ensuring that the chain of trust established between the different entities is not broken.

The above mentioned attack risks are currently partially covered by terminals - integrated circuit card readers incorporating security modules (SAM, similar to an integrated circuit card) which are used in wallet applications. The reader is then customized by a SAM, and assigned to a merchant, the cards read being those of customers. This SAM contains secret information and is likely to run algorithms using this secret information.

The terminal module includes data storage media (ROM, EEPROM, RAM). Data stored in permanent memory (ROM) includes, among other things, an operating system, external component managers controlling interfaces and peripherals, and a module interpreter capable of interpreting program modules written in a specific language. Program modules are stored in the semi-permanent EEPROM memory and can be temporarily loaded into the external memory to be activated by a microprocessor or remote controller in the memory module during the operation of the terminal, and applications are loaded from the EEPROM-compatible memory module into a remote memory server or RAM.

The terminal module of document WO95/04328 can operate: in terminal module standalone mode, the microprocessor of the terminal module executing a program module stored in internal memory, without using an integrated circuit board;in standalone terminal mode, in which a program module stored in a card is executed;in extended or connected terminal mode, in which the microprocessor of the terminal module or the card executes a program module and communication is established via telephone, modem or direct link to a service provider or server;in transparent memory card reader mode, in which instructions received by a serial link are transmitted directly to the card and vice versa.

The terminal described in WO 95/04328 does not address the security concerns of the invention insofar as it does not describe how to secure a transaction by ensuring the integrity of the overall behavior of the software executing the transaction, including means of executing high-level requests from the application, or how to ensure the origin, integrity and confidentiality of such means.

The present invention is intended to provide a terminal for the implementation of secure electronic transactions, of the type comprising a personal security device such as an integrated circuit board or other device performing the same functions, and a terminal module with means of interface with the personal security device, such as an integrated circuit board reader, and offering by its software and/or hardware architecture and the security mechanisms it incorporates, an enhanced level of security, consistent with the fact that the terminal can be placed under user control, (as opposed to operator controlled terminals).

A second purpose of the invention is to ensure the same level of safety while allowing the integration of new functions or applications in use, or the evolution of existing functions or applications without the use of a multitude of different terminal modules or the change of terminal modules during evolution.

For this purpose, the invention is intended to be a terminal for the implementation of secure electronic transactions by a user in connection with at least one application implemented on an electronic unit, comprising: a terminal module comprising at least one: the first means of interface with that application to receive requests for those transactions,the second means of interface with that user,the third means of interface with a personal security device,the first means of data processing including at least the first software means of controlling those means of interface,and a personal security device including at least the second secure data processing including at least the second software means of executing basic commands and the means of executing cryptographic calculations,characterised by: * the said terminal is adapted to receive such requests from said application installed on said electronic unit in the form of high-level queries independent of said personal security device*, at least one of said terminal module and said personal security device shall comprise: at least one reprogrammable storage memory of at least one filter software, translating those high-level queries into at least one of the following: (i) at least one elementary command or sequence of elementary commands executable by the said secondary software of the said secondary data processing means, or (ii) at least one sequence of data exchange between said terminal module and said user via said secondary interface means,the first and second data processing means include a data processing device for the execution of the first and second data processing means,

Err1:Expecting ',' delimiter: line 1 column 230 (char 229)

Preferably, the terminal of the invention shall have one or more of the following characteristics, possibly combined: the filter software execution device includes the first means of identifying and/or authenticating the application installed in the unit or the origin of the requests made by the application;the data processing device for the execution of the filter software includes means of verifying the integrity of the data received from the application;the data processing device for the execution of the filter software includes centralised means of controlling the conditions of use of the security personnel filter services, depending on the application and/or the user;the data processing device includes the execution of the filter software: means to command the secure loading of such filter software into that programmable memory,one of the first or third means of interface, from an entity external to the module, and the first means of access control to allow the said software to be loaded only in response to at least one predefined condition;the terminal includes second means of authentication of the said first means of data processing by the said second means of data processing;the terminal includes third means of authentication of the said second means of data processing by the said first means of data processing;the first terminal includes a communication channel between the said first and second means of data processing and the said first means of secure communication;the terminal includes a fourth means of authentication of the said user;through the said terminal,in addition to the card, the fourth means of authentication shall include means of calculating, by the first means of data processing, and presenting to the user, by the second means of interface, a password known to the user and calculated on the basis of at least one first secret parameter stored in the first means of data processing;the terminal shall include means of authenticating jointly the terminal and the module by the user;the fifth means of authentication shall include means of calculating, by the said software execution device, and presenting to the user, by the second means of interface;a password known to that user and calculated on the basis of at least a second and third secret parameters stored in those first and second data processing means respectively.

According to one embodiment of the invention, the terminal module consists of a personal computer and the programmable memory consists of the disk of that computer, the filter software is run on the personal computer or, in a second embodiment, the programmable memory is installed on a secure server connected to the personal computer, the part of the filter software to be protected being run on the secure server.

According to a second embodiment of the invention, the terminal module is a device, such as a dedicated integrated circuit board reader, in which case the said personal security device is an integrated circuit board, or a personal computer. This embodiment differs from the previous one in that the said programmable memory is embedded in a secure microprocessor, the said filter software being run in the said secure microprocessor. The dedicated terminal module may possibly be portable.

Depending on the modes of execution of this second embodiment of the invention, the programmable memory for loading and storing the filter software may be arranged in the personal safety device or terminal module.

In the latter case: the terminal module may contain a single microprocessor for the execution of the filter software and the control of the interfaces, or two microprocessors fulfilling one or both of these functions respectively.preferably, the filter software shall include at least one secret parameter and the second data processing means shall include second access control means conditional on not allowing the execution of the cryptographic calculations in response to elementary commands generated by the filter software, provided that at least one of the second predefined conditions is met, the function of the secret parameter is fulfilled.

According to other features of the invention, when the terminal module has two microprocessors for the execution of the filter software and the control of interfaces: the terminal comprises a second communication channel between the first software means of controlling the means of interface and the second microprocessor and the second means of securing the second communication channel;the second means of securing include means of encrypting and decrypting, by the first software means of controlling the means of interface and the second microprocessor, data transmitted on the second communication channel, on the basis of at least a fifth secret parameter stored in the first and second data processing means;the second means of securing include first physical means of protecting the second communication channel against intrusion.

Various embodiments of the invention will now be described by reference to the attached drawings, in particular embodiments in which the filter software is loaded and run in the terminal in such a way as to guarantee both its origin, confidentiality and integrity, this software being also able to authenticate the origin of the requests sent to it, if the confidence in the user interfaces, i.e. the screen and the keyboard, cannot be guaranteed. Figure 1 is a diagram illustrating the functional architecture of a system for implementing secure transactions by means of a terminal according to the invention; Figure 2A shows a first embodiment of the invention where the terminal is a personal computer coupled to a circuit board integrated by a reader,Figure 2B describes the functional architecture of a variant of the first embodiment of the invention, in which the terminal PC is connected to a security server on which the filter software is implanted; Figure 3 shows a transaction system implemented by a terminal in a second embodiment of the invention, which may be a dedicated product connected as a peripheral to a personal computer or directly to a server or built around a terminal block; Figure 4A is a configuration of the terminal hardware architecture similar to that of a second terminal hardware architecture; Figure 3A is a configuration of the terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture; Figure 4A is a diagram illustrating the second terminal hardware architecture of the second terminal hardware architecture; Figure 4A is a diagram of the second terminal architecture of the second terminal hardware architecture; Figure 4A is a diagram of the second terminal architecture of the second terminal hardware architecture of the terminal hardware architecture; Figure 4A is a diagram of the second terminal architecture of the electrical system; Figure 4A is a diagram of the second terminal architecture of the second terminal architecture of the terminal architecture of the terminal; Figure 4A is a diagram of the second terminal architecture of the terminal architecture of the terminal architecture of the terminal; Figure 4A is a diagram of the second terminal architecture of the second terminal architecture of the terminal; Figure 4A is a diagram of the second terminal architecture of the second terminal architecture of the terminal architecture of the terminal; Figure 4A is a diagram of the second terminal architecture of the second

Err1:Expecting ',' delimiter: line 1 column 793 (char 792)

Terminal 1 may be a dedicated terminal or be integrated into a PC-type personal computer, or into a network computer or set top box.

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

For the implementation of secure transactions, Terminal 1 can be used in connected mode with a SAP server or in offline mode, with the FAp application then running locally, e.g. on the PC: This is the case, for example, when a user needs to sign an e-mail or transactions to be sent to a recipient.

In connected mode, as shown in Figure 3 in the case of a dedicated terminal module 1, the terminal module can be connected to the Sap server on which the FAp application is implanted via the PC and an R network such as the Internet, or via the R telephone network via an MO modem or a DTMF link with a CT handset. Some transactions, such as the reloading of an e-wallet into the card 31, may require a two-way data exchange with the Sap server and are therefore more ergonomic in connected mode.

The implementation of a secure transaction with a terminal module 1 and a card 31 implies that high-level software requests (e.g. signature, authentication requests, etc. which must be processed in a way that satisfies the security objectives required by the application program) are transmitted from the application program deployed e.g. in the SAP server (connected mode) or in the PC or NC personal computer at the user's disposal (unconnected mode, e.g. e-mail signature), to the filter F providing the control of the security means.processing high-level requests includes the translation of these requests into a basic command or sequence of basic commands which are executed by the security personnel device. High-level requests are made independently of the hardware and/or software configuration of the security personnel device, i.e. they are not made directly for the security personnel device.

Err1:Expecting ',' delimiter: line 1 column 357 (char 356)

The F filter meets the security objectives insofar as the translation software it contains verifies the identity of the application issuing the service requests (or directly the origin of the requests) and is implemented in such a way as to guarantee the integrity and confidentiality of the basic operations and data implemented to respond to the service requests.

A translation software is software configured for a type of microcircuit board and translates a high-level request received from application software into a basic command or sequence of basic commands executable by the microcircuit boards and/or a sequence of data exchanges with the user.

High-level queries are a list of commands used by application programs to call on the security services necessary to identify and authenticate the person performing the transaction and to ensure the origin, integrity and possibly non-repudiation of the transaction. it is independent of the basic means (e.g. cryptographic means) used to satisfy its demand and contains specific information to be processed by the F filter.Err1:Expecting ',' delimiter: line 1 column 659 (char 658)where the transaction is not entered by the user on the terminal itself, the request may contain the information necessary to enable the user to verify, if he so desires and if the terminal supports this option, the essential transaction data.

Err1:Expecting ',' delimiter: line 1 column 307 (char 306)

To ensure the integrity of the chain of trust between the application and the map, the translation filter software F identifies, or even authenticates, the origin and integrity of the requests it receives. an identification code can be embedded in the query itself and then verified by the filter software from the information it contains or that can be stored in the integrated circuit board; the same purpose can be achieved by comparing the result of a hash operation performed by the filter software on the application software issuing the query with a result previously stored in the card for example.Err1:Expecting ',' delimiter: line 1 column 254 (char 253)

Figure 2A describes an early embodiment where terminal 1 is a PC 102, the connection to the integrated circuit board 31 is by means of a drive 6 connected or integrated to the PC 102. The PC 102 includes input/output interfaces 102a with drive 6 and the Sap server. Depending on the nature of the drive connected to the PC, the user interface elements may be the keyboard and screen of the PC itself, or a keyboard and/or LCD display such as implanted on the PC 102's filter. In this embodiment, the F filter is implanted and run on the PC 102. The F filter, and the computer translation software it contains, can then be stored on the hard disk of the PC 1022. To be loaded into the PC 102's hard drive or computer, the RAM is then run via the personal computer 102's microprocessor.

The hard disk of a PC 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 2 modules: a loading/decrypting module Fcd and a second module corresponding to the encrypted filter software itself, Fchi. The first module allows the loading of the second module into RAM, its decryption, and then the launch of its execution.

The use of a programming language such as Java, through security mechanisms inherent in the language itself, allows for greater protection of the software

Another method of verifying the integrity of the filter software is to have the second module signed by an authority that guarantees the content of the filter software using a private key kept secret by that authority. The first loading module then, simultaneously with the decryption operation, performs a hash operation on the second module and verifies the signature of this module using the public key associated with the authority's private key.

All the operations described in the previous paragraphs involve the use of keys on which the security of the application is based. These keys can be hidden in the loading module, stored in the drive 6, or stored in the integrated circuit board itself.

The purpose of the invention is to ensure that a hacker cannot use a user's integrated circuit board without their knowledge, for example by modifying the filter software that drives the card or application software, or by implanting a virus software that would short-circuit the application or filter software in place. The first is the ability to verify the integrity of the filter software and the origin and integrity of the commands sent to the card via the reader 6, for example by authenticating them using a MAC code.The MAC verification can be performed by the drive 6 or card 31.[citation needed] Equivalent protection could be obtained by encrypting the dialogue between the filter software and the drive 6. A virus software seeking to short-circuit the filter software would therefore send unauthenticated or incorrectly encrypted commands to the drive 6 or card 31; as a result, these commands would be rejected by the drive or card, preventing the virus from reaching its goals.

Err1:Expecting ',' delimiter: line 1 column 334 (char 333)

The implementation of the filter software in a PC does not guarantee the same level of security as implementation in a dedicated terminal which may provide additional physical security mechanisms as described in the other embodiments presented below, providing physical protection for the filter software and the secrets it contains.

A variant of the embodiment of Figure 2A is shown in Figure 2B. This variant takes advantage of the flexibility and ease of connecting a personal computer to a network, by allowing some of the filter software, and in particular the secrets, to be ported to a secure Ssec server.

In the case of Figure 2B, the filter software is broken down into two software modules, an F-PC module implanted on the PC 102 personal computer and an F-SE module implanted on a Ssec security server. The programmable memory to which it refers above and storing the filter software is therefore in this runtime variant implanted in the Ssec secure server, i.e. out of reach of unauthorized users.

The F-PC software module implanted on the PC 102 is connected by a secure CS channel to the Ssec security server. This secure channel is actually an encrypted communication channel allowing for a protected data exchange between the two filter software modules F-PC and F-SE and possibly mutual authentication of the two F-PC and F-SE modules. This secure channel may, for example, rely on well-known communication protocols such as SSL.

The establishment of this secure CS channel thus enables the first F-PC filter software module to transmit to the second F-SE filter software module the requests received from the FAp application via the F-API logic interface, as well as information related to the identification of the application issuing these requests. This second F-SE software module will then, after verifying the information relating to the application and, depending on the application and possibly the user's rights, translate these requests into a sequence of commands intended for the chip card 31 and the first control of data exchanges with the user. These commands encrypted by the F-SE module are then sent to the F-PC module which has integrated them into the same file: the controller for the control of exchanges with the card or the circuit board.In order for the user controls to be executed on the PC, the PC will need to have a software module I, the interpreter, which allows messages to be displayed on screen 4 and information to be entered by the user on the keyboard 5.

This second execution mode is based on the mechanisms described in the first execution mode of Figure 2A with respect to application identification (e.g. hashing or signing) and protection of commands sent to the card (e.g. addition of a MAC message authentication code). It offers a higher degree of security, however, in that the F-SE filter software module for the translation of high-level requests received from the Fap application is executed in a secure environment.

This second execution mode of Figure 2B is well suited to applications implemented in a closed or private environment controlled by a central authority, as it requires a protected server whose administration must be centralised. This second execution mode also provides the possibility of defining a centralized access policy to the cryptographic services offered by the integrated circuit board. This access policy can be based on the applications requesting the services of the card and on the users themselves.ensure that only authorised users can sign: this mechanism can be implemented via the secure CS channel. For each signature request made by any of the applications considered valid by the company (e-mail and banking 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 via the secure channel to the CS card 31.The password will then be transmitted via the CS channel to the F-SE software module. The F-SE software module, knowing the user and therefore the secret key contained in his card, will compare the received password to the expected password. This mechanism known as challenge-response authentication allows the F-SE software module to validate the user's identity. This allows the company that has given the integrated circuit cards to users to ensure that only authorized users can sign, for example, bank transactions.

The Sec server, thanks to the secure and centralized means it represents, allows not only a secure deployment of the F-SE filter software but also the possibility of setting up a centralized policy to control the use of the security services offered by the integrated circuit board. The Sec server allows the establishment of a centralized policy because the same server can be linked to a plurality of F-PC software modules deployed on the personal computers of a plurality of users. The Sec server allows the centralized definition and control of the conditions of use of the security services offered by the different cards to users, by the application profile required and the rights of the users. The centralized policy in place of such a service therefore serves to store the necessary information with the user's rights, i.e. the rights to use the services requested by the application and the rights of the users.

This second execution mode in Figure 2B, which is well suited to private environments, is however difficult to apply to open applications for which the implementation of a secure central Ssec server is not possible.

Figure 3 shows a terminal module with similar functional architecture principles to those in Figure 2B in a different embodiment, without the need for a centralized server.

In the case of Figure 3, terminal module 1 is a portable or non-portable housing with one side containing the display screen 4 and the keyboard 5 and in which electronic circuits are embedded, preferably in such a way that they are not accessible from the outside. Housing 1 contains the reader 6 and has a reception opening for the microcircuit card 31 in the reader 6. The mode of operation described by reference to Figures 3, 4A, 4B and 4C should not be considered as being limited to a dedicated terminal. The following description can be quite easily applied to a terminal built around a type of personal computer or NC.

In a first embodiment, shown in Figure 4A, of this second embodiment of the terminal module in Figure 3, the electronic circuits of terminal module 1 are arranged around a standard microcontroller 2 and a secure microprocessor 3, which are connected to each other by a link and permanently implanted in the module 1 housing. Alternatively, the microprocessor 3 may be plugged into module 1 by means of a connector 41 represented by broken strokes in Figure 4A.

Err1:Expecting ',' delimiter: line 1 column 228 (char 227)

Interfaces or peripherals managed by the microcontroller 2 include, for example, the data display screen 4, e.g. liquid crystal display, the keyboard 5 for user input, the microcircuit card reader 6, an external link interface 7, e.g. RS 232 or PCM-CIA, an infrared link interface 8, and a DTMF 9 device for data transmission over a telephone line.

The components of module 1 also include a clock 10 and a power supply 11 for the various circuits and components of module 1.

The task of the standard microcontroller 2 is to manage the environment, i.e. to control interfaces 4-9 and clock 10, as well as power supply 11 to selectively power the secure microprocessor 3 in the case of a standalone module 1.

Err1:Expecting ',' delimiter: line 1 column 858 (char 857)

It is therefore a low-cost, low-power microcontroller which is particularly suitable for a wearable product, such as OKI MSM 63180.

Preferably, two clocks are provided in 10: a low frequency clock 10a, e.g. 32.368 KHz, and a high frequency clock 10b, ranging from 1 MHz to 12 MHz e.g. The microcontroller 2 commands the connection of its system clock to either of these two clocks.

The slow clock 10a clock a 2d timing device of the microcontroller 2 with a period of 0.5 s to realize a real time clock in module 1. The processing unit 2a can also operate using the slow clock 10a for functions that do not require computing speed in which case the system clock of the microcontroller 2 is connected to the slow clock 10a and the fast clock 10b is stopped. This mode of operation allows to limit the power consumption of the module 1, which is advantageous if it is portable and powered by an electric battery.

The read and write secure microprocessor 3 comprises a central unit 3a and temporary (RAM) 3b and permanent (ROM) 3c memories, as well as electrically reprogrammable semi-permanent memory (e.g. EEPROM or Flash RAM) 3d for storing, inter alia, application programs of module 1.

This secure microprocessor 3 is of the type used in microcircuit boards and has a limited number of inputs and outputs, its internal buses being inaccessible from the outside.

The fact that the microprocessor 3 has a 3D semi-permanent memory makes it possible to load one or more application programs from outside, for example from a server or a microcircuit board, and to evolve the application (s) (access control, financial and/or commercial transactions, e-wallet, etc.) for which the module 1 is intended, depending on the needs.

Depending on the version chosen, the secure microprocessor 3 can perform the calculation of cryptographic functions requiring large computations implemented in asymmetric algorithms of the RSA or DSA type, or implement simpler algorithms, for example of the DES type. a SIEMENS SLE44C160S non-cryptographic microprocessor with 14 KB of ROM and 16 KB of EEPROM; a SGS THOMSON ST16CF54A cryptographic microprocessor with 16 KB of ROM, 4 KB of EEPROM and 480 bytes of RAM; a PHILIPPS P83C858 cryptographic microprocessor with 20 KB of ROM and 8 KB of EEPROM.

The secure microprocessor 3 is connected via link 12 to the standard microcontroller 2 and via links 13 and 14 to the external interface 7 and to the microcircuit board reader 6 via interface adapter switches 15 and 16 respectively.

Err1:Expecting ',' delimiter: line 1 column 929 (char 928)

The implementation programmes may also be distributed between these different locations, depending on the security rules to which they are subject.

The functional diagram in Figure 4B illustrates a first software architecture configuration of Module 1 in Figure 4A in which all application programs A1, A2, ..... An and security functions (condensate computation, symmetric cryptographic algorithms such as DES, triple DES, or asymmetric algorithms as proposed by RSA) are implemented in the secure microprocessor 3.

The applications named above and in the following description A1, A2, ..... An include at least the filters F1, F2, ..., Fn, and therefore in particular the query translation software issued by the application service provider (s) FAp that is part of the main application 54 (Figure 8A).

The standard microcontroller 2 manages the environment by means of various management programs or interface managers, namely: a micro-circuit board reader or interface manager 21;a serial interface manager 22;a keyboard manager 23;a keyboard manager 5;an infrared interface manager 24;a display manager 25;a clock manager 26;a power supply manager 11;a DTMF interface manager 27;a driver 28 of other interfaces, where module 1 has an interface or interfaces other than those shown in Figure 2.

Thus, the secure microprocessor 3 can control the interfaces by means of commands which are interpreted by the interpreter 20 and executed by the standard microcontroller 2 through the managers 21-28.

Figure 4C illustrates a second software configuration of Module 1 of Figure 4A in which one or more Ax applications and one or more Sx cryptographic functions are stored in reprogrammable memory 30a of a secure microprocessor 30 of a microcircuit board 31. When card 31 is inserted into drive 6, the microprocessor 30 runs Ax applications and Sx cryptographic functions, while other applications and security functions may reside in and be implemented by the Secure Microprocessor 3 of Module 1. This is, for example, the microprocessor 30 of the card 31 can provide an electronic signature function in the cryptographic circuit where the Secure Microprocessor 3 does not integrate a decryption processor (if a Secure Microprocessor 3 is also integrated into the cryptographic application, it will be possible to call the 3 commands from the Microchip 31).

In this second configuration, which is otherwise identical to that shown in Figure 4B, the interpreter 20 performs the same role vis-à-vis the microprocessor 30 as it does vis-à-vis the secure microprocessor 3. The module 1 can thus perform different applications depending on the type of micro-circuit card 31 inserted in the reader 6, for example: user authentication in the context of a banking transaction (account consultation, transfer of funds, etc.) carried out via a telephone line using the DTMF 9 interface; consultation of the balance of an electronic wallet, or recharging of a specific wallet, from which a module 31 micro-circuit card completing the consumer's wallet is inserted into the reader 6; additionally, a module 1 allows the user to access a number of different points on the card, for example, a medical card, etc.

The execution mode described above in Figure 4A and the software configurations shown in Figures 4B and 4C apply analogously to a terminal built around a conventional PC with the secure microprocessor in addition. In this execution mode, the microcontroller 2 corresponds to PC 102 as shown in Figure 2A, the processing unit 2a corresponds to the PC 102c microprocessor, and the RAM 2b and 2c peripherals correspond to the RAM 102d and the hard disk 102b respectively. Similarly, the PC 102a inputs/outputs correspond to the interface modules 7, 8 and 12 of Figure 4A. The connection between the secure microprocessor and the PC 101 can be via a fixed connection to the PC or a USB connection to the PC or a microchip, or a connection to the PC 3 or PC 101, via the internal bus or a wireless connection to the PC, or a wireless connection to the PC, or a wireless connection to the PC.

In this case, the interpreter software module 20 and the peripheral management software modules 21 to 28 are implanted and run on the PC. The functional architecture of this execution mode is equivalent to that shown in Figure 2B, the interpreter module 20 thus implanted on the PC performing the same role as the interpreter module I in Figure 2B: it executes the commands for controlling the exchanges with the user received from the filtered software F itself securely implanted in the microprocessor 3 (Figure 4B) or the integrated circuit board 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 terminal module 1 are arranged around a single microcontroller 29 replacing microcontroller 2 and microprocessor 3 and capable of providing the same type of physical and logical protection as microprocessors designed for integrated circuit boards. This microcontroller manages all the interface means of terminal module 4-9 PC. It consists of a processing unit 29a, temporary memory (RAM) 29b, a permanent memory (ROM) 29c and a semi-permanent memory (PROMEE) 29 modules which would provide translation software storage. The computer processing unit 29a is built around a computer controller 2a which allows the processing of data from the terminal 1a and 2a, and a controller 3a which can be connected directly to the terminal 1a and 2a, and a controller 2a which can be connected to the terminal 2a and 2a, allowing the processing of data from the terminal 2a and 2a.

Err1:Expecting ',' delimiter: line 1 column 420 (char 419)

In this case, all applications A and cryptographic functions C are stored in a semi-permanent memory 130a (EEPROM or Flash RAM) of the microprocessor secured to the micro-circuit board Axx131, and the latter works as described in Figure 4C and the cryptographic functions in this case.

In the examples described above, for the sake of simplicity, the microprocessor 30, 130 of the integrated circuit board and the secure microprocessor 3 possibly implanted in the terminal module have a single communication port. This implies that in these examples, the exchanges between the different entities, namely the electronic unit 154 (Figure 8) containing the main application, the secure microprocessor 3 and the microprocessor 30, 130 of the integrated circuit board are made through the microcontroller 2 or 29 of the terminal module. These descriptions should not be considered as limiting: other implementations may be considered in the context of the present invention.The current available secure integrated circuit board microprocessors, which can be used for the board itself (microprocessor 30, 130) or in the terminal module (microprocessor 3), can have two communication ports. Different embodiments optimising communication flows are therefore easily conceivable with this type of microprocessor.

Following an important feature of the invention, a filter software is implanted in the reprogrammable EEPROM associated with Secure Microprocessor 3 or 29 of Terminal Module 1 and/or Secure Microprocessor 30, 130 of Card 31, 131. This filter software is known to translate high-level requests from the Sap server or PC into elementary sequences of commands executable by these microprocessors (commands which are notably defined by Part 4 of ISO 7816-4).

This solution has the advantage of significantly reducing the data rate exchanged between terminal module 1, 101 and the SAP server or PC, but requires secure implementation of the translation software to prevent instructions sent to the microcircuit board from being altered.

This filter software is an integral part of the application software part installed in terminal module 1 and/or card 31, 131 and is therefore downloadable.

Err1:Expecting ',' delimiter: line 1 column 135 (char 134)

Err1:Expecting ',' delimiter: line 1 column 151 (char 150)

Processing modules 46, 47, 48 rely on basic services provided by the microcircuit board operating system 49.

Figure 8A illustrates the software architecture of a secure transaction execution system using terminal modules 1 with a secure microprocessor 3 in accordance with the execution mode of the invention in Figure 4A.

Block 51 refers to software run by the secure microprocessor 3 of terminal module 1, block 52 software run by the microcontroller 2 or PC 102 of terminal module 1, block 53 software run by the microprocessor 30 of a microcircuit board 31, and block 54 the main application software, or application service provider, deployed in the SAP server or PC.

Block 51 is similar to block 43 in Figure 7, i.e. the secure microprocessor 3 has an architecture similar to that of an integrated circuit board. a communication protocol software 60 an operating system 61a block 62 representing the part of the application software implanted in terminal module 1, this part of the application software being essentially made up of the aforementioned filter software. Different software modules of this type corresponding to different applications may coexist in the secure microprocessor 3.optionally, a software 63 allowing for authentication of the standard microcontroller 2 by the secure microprocessor 3 and authentication of the secure microprocessor 3 of terminal module 1 by the microprocessor 30 of the card 31,a 64 secure file management software,a 65 cryptographic services software.

Block 52 includes: a communication protocol software 70;a command interpreter 71 corresponding to software 20 in Figures 4B and 4C;authentication software 72 allowing, in conjunction with software 63, the authentication of standard microcontroller 2 by the secure microprocessor 3 of terminal module 1;software 73 for the management of internal microcontroller 2 resources;software 74 for the control of user interfaces (managers 23 and 25 of screen 4 and keyboard 5);software 75 for the control of communication interfaces 7, 8 and 9 (managers 22, 24, 27);

Finally, block 53 is similar to block 43, but does not contain, in the example in Figure 8A, application software or filters. a communication protocol software 80; an APDU command interpretation software 81; a secure file management software 82 (e.g. PIN control); a cryptographic software 83 (symmetric cryptographic calculations with secret or asymmetric keys, public and private keys, etc.) allowing, inter alia, in conjunction with software 63, the authentication of the secure microprocessor 3 of terminal module 1 by the microprocessor 30 of card 31, the operating system 84 of microprocessor 30 of card 31.

The communication protocol 60, 70, 80 allows data exchanges between: the microprocessor 30 of the card 31 and the standard microcontroller 2 or PC 102 of the terminal module 1; the secure microprocessor 3 and the microcontroller 2 of the terminal module 1; the secure microprocessor 3 of the terminal module 1 and the microprocessor 30 of the card 31.

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

In Figure 8B, block 152 refers to software run by the microcontroller 2 of the terminal module 101, block 153 refers to software run by the microprocessor 130 of a programmable microcircuit board 131 and block 154 refers to the main application software implemented in the SAP server or a PC.

Block 152 comprises the same software 70, 71 and 73 to 75 as block 52 in Figure 8A, and block 76 which is authentication software of the standard microcontroller 2 of terminal module 101 with respect to microprocessor 130 of card 131.

Block 153 for microprocessor 130 of card 131 comprises software 62 and 80 to 84 of blocks 51 and 53 of Figure 8A, and software 77 for authenticating, in conjunction with software 76, the standard microcontroller 2 of terminal module 101 with respect to microprocessor 130 of card 131.

Unlike a conventional system, in the secure transaction system of the invention, the filter software 62 which translates high-level application queries into basic microcircuit board executable commands is implanted in the secure user environment, i.e. either in terminal module 1 (for applications A1, A2.....An of execution modes 4A-4C and 5) or in a semi-permanent memory card 31, 131 usable with terminal module 1, 101 (for applications Ax of the embodiment mode of Figure 4C and for all applications of the embodiment mode of Figure 6).

In addition to its function of managing a microcircuit board, this filter software 62 manages user interactions, i.e. data exchange sequences between a user and the terminal module that are required in an application, which take place via the interface means, namely the screen 4 and the keyboard 5. It is 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, e.g. voice, with the required ergonomics, might be suitable.

The secure installation of the filter software 62 in the secure microprocessor 3 or 29 of terminal module 1 or the microprocessor 30, 130 of the microcircuit board 31, 131 ensures the security of transactions, since the keys and rules necessary for accessing files on the microcircuit board 31, 131 are contained in the translation software 62 and are therefore inaccessible to third parties.

The functions performed by filter 62 software will be illustrated below by using the example of an e-commerce application. A buyer, a merchant, a bank.

The trader has a Sap (Web) e-commerce server accessible from the Internet. a PC computer with access to the SAP e-commerce server, which enables the buyer to consult a catalogue of goods.a bank-issued integrated circuit card 31 with a microprocessor 30 containing a private key but no cryptographic capability for signing,a terminal module 1 as shown in Figure 4A, with a standard microcontroller 2, a secure microprocessor 3 with cryptographic capability for signing a message, a keyboard 5, a display 4, an integrated circuit card interface 6 and a series 7 interface for connecting to a PC.

The operating principles are as follows: the transaction is signed by terminal module 1 using a private key held by card 31. This private key is protected by a confidential carrier code (PIN) that the buyer must enter in a secure environment, i.e. on terminal 1, and by a prior authentication of terminal 1 by card 31 using a Kauth secret key.

Err1:Expecting ',' delimiter: line 1 column 464 (char 463)Err1:Expecting ',' delimiter: line 1 column 254 (char 253), Kauth, shared by terminal module 1 and card 31,i. terminal module 1 sends a private key read request to card 31,j. when all access conditions are met, card 31 accepts the read request, and returns the private key, encrypted by a secret key, Kchif, shared by card 31 and terminal module 1,k. terminal module 1 decrypts the private key, signs the transaction by means of the private key, destroys the private key, disconnects from card 31 and sends the signed transaction to the PC computer which transmits the transaction to server S.

This example can be easily transposed to an electronic transaction without a PC, with Terminal 1 connecting directly to a SAP server via a modem link (Figure 3), the buyer entering the order (product reference) on Terminal 1.

It should be noted that authentication of the secure microprocessor 3 by the card can also be performed through the private key reading command by associating a MAC (Message Authentication Code) authentication code calculated by means of a secret key.

Err1:Expecting ',' delimiter: line 1 column 134 (char 133)

Such a translation filter software acts as a screen, a filter between the outside world, that is, the applications, and the devices it manages.

It improves the security offered by: 1. it imposes a sequence on the elementary orders sent. For example, in the case illustrated above, it requires that the transaction be validated by the user before being signed.2. it has the secret settings for generating and authenticating these elementary orders.

When the filter software is run in the secure microprocessor 3 of terminal module 1, these properties allow for the imposition of an access policy on card 31, which 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 intended for its initial deployment).

The security benefits of running the filter software in the secure microprocessor of the terminal module or the integrated circuit board are only possible because the software runs in a secure environment that ensures that: the secrets contained in the filter software are not accessible because they are stored in the secure microprocessor 3, 29, 30 or 130,the confidentiality and integrity of the filter software is preserved because the filter software is stored in the secure microprocessor 3, 29, 30 or 130.

In the case of terminal module 1 as a dedicated product with its own interfaces, display 4 and keyboard 5, the security objective is achieved by the fact that the software controlling the data exchanges with the user cannot be changed, as it is stored permanently in the permanent memory 2c of microcontroller 2 or securely in microcontroller 29.

Other mechanisms can further improve the security of the chain of trust between the secure microprocessor of the integrated circuit board, the possible secure microprocessor of the terminal module, the standard microcontroller or PC of the terminal module and the user. (a) secure download of the filter software; (b) authentication of the standard microcontroller by the secure microprocessor or, which is equivalent but better suited in the case of a terminal execution mode around a PC, authentication of the interpreter software module I (20) by the filter software F (62) and/or establishment of a secure communication channel between these two microprocessors or software I and F; (c) protection of a secret by the standard microcontroller; (d) mutual authentication and establishment of a secure communication channel between the secure microprocessor of the integrated circuit board and the secure microprocessor of the terminal module; (e) authentication of the terminal module, and possibly the terminal module-card pair; (f) authentication of the microcircuit board by the terminal module.

A) Secure download of filter software

The organizational diagram in Figure 10 illustrates the process of downloading an application program (filter software) into Secure Microprocessor 3 or 29 of Module 1 or Secure Microprocessor 30, 130, from a card 31, 131 present in drive 6. This download can be done from a Sap server via, for example, the PC and the external link interface 7 or the infrared link interface 8, or directly via a telephone link through the DTMF link interface 9. The download can also be done to Secure Microprocessor 3 or 29 (if the terminal module is equipped with it) from a microcircuit board in the inductor 6.

At step 32, the area of 3D memory allocated to the application program to be received is empty and microprocessor 3 is waiting for the application program to load following a load request.

The next step 33 is an authentication procedure by the microprocessor 3 of the entity called upon to download the application program (Sender). This authentication procedure may, for example, use encryption mechanisms well known to technical specialists, e.g. symmetric mechanisms with shared secret keys or asymmetric mechanisms with private and public keys.

Err1:Expecting ',' delimiter: line 1 column 161 (char 160)

Step 36 is the storage in EEPROM 3d of the data frames transmitted by the downloading entity.

Step 37 is a test to determine whether the download is complete: if not, the download program returns to step 36 and the download continues; if yes, a verification of the integrity of the data received by the microprocessor is carried out in step 38.[3] For this purpose, a message authentication code (MAC) can be associated with the downloaded program to allow verification of not only its integrity, but also its origin. The MAC can be produced using a symmetric cryptography mechanism (DES in heated mode CBC). Verification of origin and integrity can also be achieved using an asymmetric cryptography mechanism: a condensed software sensor is downloaded from the downloaded program; the signature of the public key is then secured with the help of the microprocessor's private key.

It should be noted that in this last example, the public key does not in principle 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 remove signature verification or simply replacing the originally intended public key with a public key for which he would know the associated private key.

If test 39 shows that the data received is correct, a flag indicating that the received application program is validated is drawn up in step 40, otherwise the download program returns to the initial step 32.

This process of loading application software, i.e. filter software, into secure reprogrammable memory (3d, 30a, 130a depending on the method of implementation), includes mechanisms to confirm the origin and integrity of the data received from the software issuer.

(B) Authentication of the interpreter software module 1, 20, 71 by the filter software F, 62 or, if equivalent in the corresponding execution mode, authentication of the standard microcontroller 2 by the secure microprocessor and/or establishment of a secure communication channel between these two software or microprocessors.

For a user to have complete confidence in the terminal module through which he or she performs transactions, it is necessary: authenticate the data transmitted from the interpreter software 20, 71 to the secure microprocessor 3, 30 or 130 running the filter software; ensure that the data transmitted by the filter software to be displayed by the interpreter software of the terminal module 1, 101 owned by the user can only be displayed by the user.

When the means of controlling data exchanges with the user, i.e. the interpreter software 20, 71, are fixed and unchangeable in terminal module 1, 101, as for example in ROM 2c of the standard microcontroller 2, the authentication of the software module is equivalent to the authentication of the microcontroller.

Similarly, where the filter software is implemented in a way that cannot be modified by an unauthorised person, in secure processing facilities such as the secure microprocessor 3, the integrated circuit board or the secure Ssec server, authentication by such secure means is equivalent to authentication by the filter software itself.

In the following description, we will describe the mechanisms for authenticating the software means of controlling the interfaces or interpreter software 20, 71 by the filter software.

Various solutions can be found to meet these requirements.

A first solution is to encrypt all data exchanged between the interpreter software 20, 71 and the filter software.

A second solution is to have the interpreter software 20, 71 authenticated by the filter software and/or to establish a secure communication channel between these two software.

These two solutions necessarily imply that at least one known secret parameter of the filter software F, 62 is stored in the interpreter software 20, 71.

In the second solution, the filter software F, 62 authenticates the interpreter software 20, 71 using a conventional authentication process, based on information transmitted by the interpreter software 20, 71 and combined with the secret parameter.

This authentication mechanism can also be applied to messages exchanged between the two software to build message authentication codes to guarantee the origin and integrity of each message transmitted.

In the case of the execution mode described in Figure 4A, however, this solution requires that, preferably, physical protection of the link between the two microprocessors be provided to prevent a fraudster from reading the data exchanged, and in particular the personal identification code (PIN) of the card which the user may be required to enter via the 5 keyboard for the execution of transactions.

C) Protection of a secret parameter by the standard microcontroller 2

The above description shows the need to store at least one secret parameter in the interpreter software. The terminal execution mode from a PC, in which the interpreter software is run on the PC itself, therefore offers due to the limited security of the PC a limited but sufficient degree of security to prevent a virus from replacing the interpreter software. A higher degree of security is achieved by implanting the interpreter software in the ROM 2c of the standard microcontroller 2.This operation is intended to establish trust between the two microprocessors. Every precaution must be taken during this operation to ensure the authenticity of the microcontroller 2 (operation carried out at the factory, operation protected by so-called transport keys themselves stored in the temporary memory of the microcontroller 2 at the factory, and knowledge of which is a condition for the initialization of this secret parameter).to cause the temporary memory to be erased in case of intrusion (power cutting, etc.).

D) Mutual authentication and establishment of a secure communication channel between the microprocessor on the integrated circuit board and the secure microprocessor on the terminal module

This mutual authentication and the establishment of the secure communication channel shall be achieved by implementing mechanisms identical to those used between the standard microcontroller 2 and the secure microprocessor running the filter software as described in point B.

E) Authentication of the terminal module

It is important to guard against any attack on the keyboard set 5, display 4, secure microprocessor 3, for example by counterfeiting terminal modules, replacing a terminal module with a counterfeit terminal module in order to retrieve user-entered information (keyboard espionage), accessing the secrets of an integrated circuit board, or making false signatures.

To this end, a mechanism for authenticating the user's terminal can be added.

This is achieved through an automatic personalisation process.

Authentication of the terminal module only

The personalisation may consist of calculating a memorable password generated and displayed by the terminal according to the secret settings contained in the terminal's microprocessor (s) when the user enters a PIN. For example, if the terminal has two microprocessors, the password is stored in the secure microprocessor, encrypted by the PIN and an X secret key, and then passed to microcontroller 2 for decryption with the X key also stored in microcontroller 2 and the PIN entered by the user.

The same principle can be applied to a card/terminal pair whenever a microcircuit board is used with the terminal module. The customization can for example consist of calculating, by means of the translation software, a password based on secret information contained in the card's secure microprocessor and one or more secret information contained in the terminal module. The same principle as described above can be used to calculate the password. This password, generated when the terminal module is used in conjunction with the card and the user, is displayed on screen 4 during subsequent uses of the terminal module with the card. The user can thus verify and have assurance that the terminal module in possession, coupled with the terminal module, is authentic.

F) Authentication of the microcircuit board by the terminal module

To further enhance the security of the transaction system according to the invention, a conventional authentication process can be implemented to ensure authentication by terminal module 1, 101 of the microchip card used. Such an authentication process can, among other things, prevent the user's personal identification number (PIN) that the user enters into module 1, 101 by key 5 to execute a secure transaction from being captured by a counterfeit card that has been substituted by a fraudster for the user's authentic card and then this fraudster would retrieve the PIN from the counterfeit card.

The transaction system architecture and the security mechanisms described above provide a very high level of security for transactions carried out using Terminal Module 1, 101. The main objective of the project is to extend the nature of the truly secure services that a microcircuit board can provide by using the keyboard 5, the screen 4 and the protection of data exchanged with the user; to use the card in the context of an insecure environment (personal PC likely to be affected by viruses or pirate programs), by hermetically isolating it from this environment through a software and/or hardware architecture that strictly controls access to the card, i.e. who controls the commands sent to the cryptographic functions contained in the card.

Err1:Expecting ',' delimiter: line 1 column 722 (char 721)a telephone with a display, which may incorporate a secure microprocessor and an integrated circuit board interface; a set-top box for a cable TV network incorporating a reader connected to a television set, a television set, a keyboard or possibly the remote control associated with the set-top box or television set as a means of user interface; generally any equipment which can be secured by the integration of a secure microprocessor in which a sensitive application may be installed,or by integrating an integrated circuit board interface allowing the control of such equipment by an application ported to an integrated circuit board.

Err1:Expecting ',' delimiter: line 1 column 161 (char 160)

Claims (38)

1. A terminal for execution of secure electronic transactions by a user in conjunction with at least one application installed on an electronic unit, said terminal comprising:

   - a terminal module including at least:

   * first interface means with said application for receiving from it requests relating to said transactions,

   * second interface means with said user;

   * third interface means with a personal security device,

   * first data processing means (2; 29; 102) comprising at least first software means (1; 20; 71) for controlling said interface means, and

   - a personal security device including at least second secure data processing means (30; 130) comprising at least second software means (80-84) for executing elementary commands and means for executing cryptographic computations,

   characterised in that:

   - said terminal (1, 31; 101, 131) is adapted to receive said requests from said application (Fap) installed on said electronic unit (Sap; PC) in the form of high-level requests independent of said personal security device,

   - at least one of said terminal module (1; 101) and said personal security device comprises :

   * at least one reprogrammable memory (3d; 30a; 102b; 130a; Ssec)for storing at least one filter program (F, 62) translating said high-level requests into at least one of either:

   (i) at least an elementary command or a sequence of elementary commands that can be executed by said second software means (80-84) of said second data processing means (30; 130), or

   (ii) at least one sequence of data exchanges between said terminal module (1 ; 101) and said user via said second interface means (4, 5), which can be executed by said first software means (I, 20, 71) of said first data processing means (2; 29; 102), and

   * means for protecting said filter program (F, 62) to prevent an unauthorised entity from either reading and/or modifying said filter program, and

   - at least one of said first and said second data processing means (3; 29, 30; 102; 130; Ssec) comprise a data processing device for executing said filter program (F, 62).
2. A terminal according to claim 1 characterised in that said device for executing the filter program comprises first means for identifying and/or authenticating said application (Fap) installed on said electronic unit (Sap; PC) or the source of said requests sent by said application.
3. A terminal according to claim 2 characterised in that said data processing device for executing said filter program (F, 62) comprises means for verifying the integrity of data received from said application (Fap).
4. A terminal according to any one of claims 1 to 3 characterised in that said data processing device for executing said filter program (F, 62) comprises centralised means (Ssec) for controlling conditions of use of services of the personal security device (31) in accordance with said application (Fap) and/or the user.
5. A terminal according to any one of claims 1 to 4 characterised in that said data processing device for executing said filter program (F, 62) comprises:

   - means for commanding loading in a secured manner of said filter program into said programmable memory via said first or said third interface means from an entity external to said module, and

   - first access control means for authorising said loading of said filter program only in response to at least one predefined condition.
6. A terminal according to any one of claim 1 to 5 characterised in that it comprises second means for authenticating said first data processing means (2; 3; 29; Ssec) by said second data processing means (30; 130).
7. A terminal according to any one of claims 1 to 6 characterised in that it comprises third means for authenticating said second data processing means (30; 130) by said first data processing means (3; 29).
8. A terminal according to claim 6 or claim 7 characterised in that it comprises a first communication channel (6) between said first data processing means (2; 3; 29) and said second data processing means (30; 130) and first means for securing said first communication channel.
9. A terminal according to any one of claims 1 to 8 characterised in that it comprises fourth means for authentication of said terminal module (1; 101) by said user, independently of said personal security device (31; 131).
10. A terminal according to claim 9 characterised in that said fourth authentication means comprise means for calculating by said first data processing means (2; 3; 29) and for presentating to said user via said second interface means (4) a password known to said user and calculated on the basis of a first secret parameter stored in said first data processing means (2; 3; 29).
11. A terminal according to any one of claims 1 to 10 characterised in that it comprises fifth means for conjoint authentication of said terminal module (1; 101) and said personal security device (31; 131) by said user.
12. A terminal according to claim 11 characterised in that said fifth authentication means comprise means for calculating by said device for executing said filter program (3; 29; 31; 131) and for presentating to said user via said second interface means (4) a password known to said user and calculated on the basis of at least second and third secret parameters stored respectively in memory in said first data processing means (2; 3; 29) and in memory in said second data processing means (30; 130).
13. A terminal according to any one of claims 1 to 12 characterised in that said terminal module (1) includes said programmable memory (3d) for loading and storing said filter program (F, 62).
14. A terminal according to claim 13 characterised in that said filter program (F, 62) generates first commands for implementing said at least one sequence of exchanges of data between said terminal module (1) and said user and said first data processing means comprise a first microprocessor (2; 102) for controlling said interface means (4-9) programmed by virtue of said first software means (20, 71) for controlling said interface means to execute said first commands generated by said filter program (F, 62), and a second secure microprocessor (3) of the integrated circuit card type disposed in said terminal module and including said programmable memory (3d), said second microprocessor (3) executing said filter program (F, 62) to control said at least one sequence of exchanges of data by means of said first commands sent to said first microprocessor (2) and for applying said at least one elementary command or sequence of elementary commands to said second data processing means.
15. A terminal according to claim 14 characterised in that said first software means (20, 71) for controlling the interface means include at least a fourth secret parameter, said second microprocessor (3) being controlled by said filter program (F, 62) to authenticate said first software means (20, 71) for controlling the interface means on the basis of information sent by said first microprocessor (2) and combined at least with said fourth secret parameter.
16. A terminal according to claim 15 characterised in that it comprises a second communication channel (12) between said first software means (20, 71) for controlling the interface means and said second microprocessor (3) and second means for securing said second communication channel.
17. A terminal according to claim 16 characterised in that said second securing means comprise means for encryption and decryption by said first software means (20, 71) and by said second microprocessor (3), of data sent on said second communication channel (12) on the basis of at least a fifth secret parameter stored in memory in said first and second data processing means.
18. A terminal according to claim 16 or claim 17 characterised in that said second securing means comprise first physical means for protecting said second communication channel (12) against intrusion.
19. A terminal according to any one of claims 15 to 18 characterised in that said first microprocessor (2) includes a temporary memory (2b) for storing said secret parameter and second means for physically protecting said temporary memory (2b) against intrusion.
20. A terminal according to any one of claims 14 to 19 characterised in that said second microprocessor (2) is a microcontroller.
21. A terminal according to claim 13 characterised in that said filter program generates first commands for implementing said at least one sequence of data exchanges between said terminal module and said user and said first data processing means comprise said device for executing said filter program and consist in a secure microprocessor (29) adapted to:

    * execute said filter program (F, 62) for translating and converting said high-level requests into at least one sequence of data exchanges between the terminal module and the user and/or into at least one elementary command or a sequence of elementary commands that can be executed by said second software means of said second data processing means (31),

    * control said interface means (4-9) using said first commands generated by said filter program to implement said at least one sequence of exchanges between said terminal module (1) and said user.
22. A terminal according to claim 21 characterised in that said microprocessor (29) includes said programmable memory.
23. A terminal according to claim 21 characterised in that said programmable memory is external to said microprocessor (29).
24. A terminal according to claim 23 characterised in that said filter program (F, 62) is stored in encrypted form in said programmable memory and in that said microprocessor (29) comprises means for reading, decrypting and executing said filter program.
25. A terminal according to any one of claims 14 to 24 characterised in that said second data processing means of said personal security device (31) comprise a second data processing device (30) for secure execution of a filter program and a programmable memory (30a) for loading and storing said filter program (62), said first software means of said first data processing means being adapted to receive said commands for implementing said at least one sequence of exchange of data from either of said filter program executing devices (3; 29; 31) installed in said module and said personal security device, respectively.
26. A terminal according to any one of claims 13 to 25 characterised in that:

    - said filter program (F, 62) comprises at least one secret parameter,

    - said second data processing means (30) comprise second means of conditional access control for authorising execution of said cryptographic computations in response to elementary commands generated by said filter program (F, 62) only if at least a second predefined condition depending on said secret parameter is satisfied.
27. A terminal according to any one of claims 1 to 12 characterised in that said personal security device (131) includes said programmable memory (130a) for loading and storing said filter program (F, 62).
28. A terminal according to claim 27 characterised in that said filter program (F, 62) generates first commands for implementing said at least one sequence of exchanges of data between said terminal module (1) and said user and said first data processing means comprise a first microprocessor (2; 102) for controlling said interface means (4-9), programmed by said first software means (20, 71), to execute said first commands generated by said filter program (F, 62), and said second data processing means comprise a secure second microprocessor (130) of the integrated circuit card type disposed in said personal security device (131) and including said programmable memory (130a), said second microprocessor (130) executing (i) said filter program (F, 62) for controlling said at least one sequence of exchanges of data by means of said first commands sent to said first microprocessor (2; 102), and (ii) said elementary commands.
29. A terminal according to claim 6 and claim 28 characterised in that said first software means (20, 71) for controlling said interface means include at least one secret parameter and said second microprocessor (130) of said personal security device (131) is controlled by said filter software (62) to authenticate said first microprocessor (2) on the basis of information sent by said first microprocessor (2) and combined at least with said secret parameter.
30. A terminal according to claim 28 or claim 29 characterised in that said second microprocessor (130) of said personal security device (131) is adapted to command the loading of said filter program (F, 62) into said programmable memory (130a) via said first interface means (7-9) and said third interface means (6) with said personal security device (131).
31. A terminal according to any one of claims 13 to 30 characterised in that said terminal module (1; 101) is an integrated circuit card reader and said personal security device is an integrated circuit card (31; 131).
32. A terminal according to claim 13 characterised in that said terminal module (1) comprises a personal computer (102) and in that said reprogrammable memory is included in the hard disk (102b) of said computer.
33. A terminal according to claim 32 and any one of claims 14 to 17 characterised in that said first microprocessor is the microprocessor (102c) of said personal computer (102), said personal computer (102) being also interfaced to said secure microprocessor (3).
34. A terminal according to claim 32 characterised in that said filter program (F) comprises a loading/decryption first module (Fcd) and an encrypted second module (Fchi) for said translation of high-level requests, said first module (Fcd) commanding the loading of said second module (Fchi) into RAM of said computer (102) and its decryption for execution of said filter program by said computer.
35. A terminal according to claim 32 characterised in that said filter program (F) comprises at least one first module (F-PC) installed on said personal computer (102) and at least one second module (F-SE) installed on a security server (Ssec), said personal computer (102) and said security server (Ssec) being connected by a secure communication channel (CS) enabling protected exchange of data between said modules.
36. A terminal according to any one of claims 32 to 35 characterised in that said personal security device (31) is an integrated circuit card.
37. A system for performing secure transactions characterised in that it comprises at least one terminal (1, 31; 101, 131) according to any one of claims 1 to 36 and at least one electronic unit (Sap; PC) including means for transmitting said high-level requests to said terminal(1, 31; 101, 131).
38. A system according to claim 37 characterised in that it comprises a plurality of terminals (1, 31; 101, 131), at least one server (S) constituting said electronic unit and means (CR) for sending digital data between said server (S) and said terminals.