FR2961330A1 - Method for securing electronic transaction between user of e.g. personal computer and goods or service merchant during purchasing of train tickets, involves assuring coherence between constitutive elements of contract and signed message - Google Patents

Abstract

The method involves transmitting an acceptance or refuse message (7) of a contract (5) towards a secure element e.g. smart card, by a personal terminal (2) for emitting a signed acceptance or refuse message (8) towards the terminal and a recipient, where a secure interaction zone object is formed by variable assembly of graphical representations of constitutive elements of the contract. The message is analyzed and the signed message of electronic transaction is calculated by the element. Coherence between the constitutive elements and the signed message is assured by the element.

Description

DESCRIPTION The method of securing user interactions on a hostile terminal The field of the invention is that of the delivery of secure goods or services. More specifically, it relates to securing interactions between a user and a personal terminal of this user. This security is implemented during the realization of an electronic transaction between the user of a personal terminal and a provider. A personal terminal is considered to be a PC, a mobile telephone or any electronic equipment provided with a man-machine interface. It is assumed in the hypothesis of an unsafe personal terminal, because can be affected by malicious software type virus.

In the state of the art, the electronic transactions conform to the model of purchase of a good or a service described in FIG. 1, which is not restrictive of the invention, namely: o User 1 (who has a personal terminal (2)) chooses a good or a service: this choice can be done for example o for the remote mode, in a virtual store through a communication network (3) such as the Internet,; in this case the terminal allows the "navigation" on the Internet by the use of an application generally called "browser", o for the local mode, in a real store, the user pays at the cash desk the good, product or service chooses. o The personal terminal receives a "contract" (5) from the provider (4) (in our example the service provider is the merchant of the good or service being purchased), summarizing the main characteristics of the transaction, and the poster (6). o The user checks the contract (6) through the man / machine interface of his personal terminal, if he agrees, confirms his agreement, by entering his confidential transaction code (7) (called CC in the rest of the document) on the human / machine interface of his personal terminal (for example the keypad of his telephone). He is the only one to know this code, which is generally provided by a service provider or payment operator, and this seizure action is therefore proof of his agreement. o The personal terminal then sends a signature (8) calculated after verifications, in particular of the CC. This agreement may have probative legal value in certain types of transactions.

This template applies to contact or remote payment, electronic signature, auction ... etc. In the case of the contact payment, a means of local communication is required between the personal terminal (the mobile) and the service terminal which can be based on different standardized technologies, such as NFC, Bluetooth, Zigbee, or 2D barcode. ... In the following we talk about the NFC as the preferred field of application of the invention, but it extends immediately to the areas corresponding to these other technologies.

A transaction therefore results in an electronic signature proving to the merchant or service provider the agreement of the customer and committing it. The calculation of the signature, the NFC verification: Near Field Communication: standardized technique giving the mobile the ability to be used as a contactless card, or a Bluetooth contactless terminal: www.bluetooth.org; Zigbee: https://www.zigbee.org/; 2D bar code or Flashcode:: ISO / IEC 18004 standard, 1

CC and additional checks can be made directly in the personal terminal. This verification at the personal terminal is questionable because the public terminals are generally not secure terminals because of their costs and the complexity of the components constituting said personal terminals, it is very difficult today to assess on the plan of their intrinsic security personal terminals, and those are unfortunately exposed to the risks of malware, trojans, viruses or bot-net, etc.

At the level of the state of the art, this security problem is solved by adding a "secure element" SE to the personal terminals, in which all the elements and tasks that are sensitive in terms of security (encryption key and authentication, encryption algorithm, PIN code etc ...). In the case of mobile-type personal terminals, the most commonly used SEs are USIM cards (on a UICC basis), or secure SD`m cards. With PCs it can be a traditional smart card if the PC has a suitable card reader, but more simply it can be a USB security key. The ES can also be an integral part of the terminal, but made in such a way that its data and programs are protected: this is the case for example with the TCG2 standards.

FIG. 2 schematizes a state of the art of the exchanges for the realization of an electronic transaction (TE) between the provider provider of the good or the service, the personal terminal (2) and the SE (9) of the client user (1) requiring the electronic transaction (TE), in both cases: on the left the terminal is a PC connected to a server provider via the Internet; on the right, the terminal is a mobile connected to a provider terminal during an NFC3 transaction, or connected to a provider server via the Internet. These two cases are equivalent from the point of view of the subject matter of the invention. The terminal receives from the provider a contract describing the nature of the transaction (for example: purchase of a good or a service) and presents it to the user on his man / machine interface. The terminal, after input by the client user on the man / machine interface of the terminal of the CC, sends the SE (9) and the signature application (11) embedded in the SE, the CC accompanied by the contract, by the message (10); the application (1l) checks the CC, can perform some additional tests depending on the application considered, then calculates if the control is positive a signature that refers to the terminal: message (12). The terminal then sends back to the server or terminal providing this signature by the message (8). At the level of the state of the prior art, it can be seen that this solution protects the most sensitive data (keys, algorithms, controls) but in no way protects the entire realization of the electronic transaction against virus attacks intended for example to mislead the user on the amount that will actually be taken from him during a payment, or attacks intended to steal his CC. This observation unfortunately remains valid when we assume that the ES is intrinsically safe.

Since we can not have complete trust in the terminal, we can fear that it will become the target of virus or Trojan attacks turning it into a "hostile" terminal. At the level of the state of the prior art, the possible attacks are twofold, as shown in Fig. 3: o Attack on the integrity of the contract, for example to make the user believe that he will pay 10E while the amount of the transaction signed would be 100E. This is the case in figure 3 if the contract proposed in 5 stipulates for example 100E, but that the virus modifies the contract displayed in 6 by changing 100E in 10 E. To be interesting, this type of attack must be done in collusion between the provider and the issuer of the virus, and this scenario is not z TCG: Trusted Computing Group: https://www.trustedcomputinggroup.org/ NFC: Near Field Communication: standardized technique giving mobile the ability to be used as a contactless card, or a contactless terminal 2 completely unrealistic, especially with the category of viruses called "botnet". Moreover, the mere technical possibility of carrying out such an attack would completely call into question the security image that must be attached to the types of transactions considered. o Attack on CC confidentiality, any capture of this CC at the time of the entry of this one by the user on the human / machine interface of the personal terminal without the knowledge of the user allows to "force" or simulate his "agreement" on fictitious transactions. In this case, the user no longer has any control over the transactions he generates involuntarily! It is important to protect yourself against such attacks, which may seem a little theoretical, whether you are in a PC or mobile context. Even if their implementation is not simple, they could, through the media, result in a significant degradation of the public trust, or even call into question certain contractual characteristics of the applications attacked, and thus have business consequences. extremely harmful.

The object of the invention is to counter the attacks described in Figure 3, without imposing particular constraints on the terminal or require the use of certified terminals from a security point of view. At the level of the state of the prior art, this type of security implemented without the use of certified terminals is very difficult to achieve and deploy, the mobile-type personal terminals or PC can not prohibit charging and installation software applications chosen by their user or a malicious third party (virus).

In the invention, this transactional security problem is solved by implementing a concept of a "Secure Interaction Area", called ZIS, as represented in a non-limiting example of a purchase transaction for a train ticket. Here, the ZIS is a graphic object presented on the screen of the user's terminal, for example constituting a graphic window for a terminal of the PC type or constituting a banner on the screen of a terminal of the mobile phone type. This graphic object is used to display the content of the contract relating to a purchase transaction of a ticket, or at least its important elements: o Incorporating a variability of structure and presentation between two different transactions, making its content not predictable by an attacker and thus preventing any automated attack against the user of the terminal (through a malicious software for example). o Making difficult modifications during an automated attack (by a malicious software in the terminal) against the user of the terminal. o But keeping some characteristics of form or presentation allowing a recognition by the user of the validity and the origin of the information of this ZIS o By allowing more the user to confirm his agreement by introduction of his confidential code CC transaction confirmation.

The subject of the invention is therefore a method for securing electronic transaction between a user and a provider, said method comprising at least the following steps: Transmission by said provider via a contract sent in a message to the terminal of said user and transmitted by the terminal to a security element SE, Provision by said security element SE elements of the transaction to the terminal for display to the user and acceptance of the transaction, collection by said terminal of the acceptance or the refusal by the user of the proposed contract, 3 Transmission by said terminal of acceptance to the security element SE for processing with a view to issuing a signed acceptance message (or refusal), through the terminal, to the provider, said method being characterized in that:

The contract provided by the OS to the terminal for display to the user is a graphic object called ZIS, and designed to be protected in integrity, The ZIS object consists of a variable assembly of graphical representations of the elements of the contract between the provider and the user, The ZIS object is further disturbed by the addition of graphic elements not constituting the contract, the security element SE carries out an analysis of the acceptance of the user (or refusal) and calculates, if necessary, a signed validation and acceptance message of the transaction,

In one variant, the method according to the invention is also characterized in that the ZIS can be a multimedia object that is not limited to graphic information: sound (to vocalize fields such as the amount) or even video (to present for example contract data such as the description of the service purchased).

Different embodiments are possible, corresponding to different secondary claims; these different modes are: o local mode: the treatments are carried out totally in the SE, which supposes a software architecture and a kinematics of the exchanges described hereafter; o The computing power of the OS being limited, two optimized embodiments in this case are described below o remote mode: the processing is performed in a remote server, at the request of the SE which is another type of possible kinematics The invention will be better understood on reading the description which follows and on examining the figures which accompany it. These are presented as an indication and in no way limitative of the invention. The figures show: FIG. 4: the principle of realization of the ZIS: schematizes the exchanges between provider, terminal, and SE related to the concept of ZIS, object of the invention. Figure 5: the kinematics of exchanges in the case CS: details Figure 4 in the case of the mode of entry of the secure acceptance by the secret code CS. Figure 6: the kinematics of the exchanges in the case CVD: details figure 4 in the case of the mode of seizure of the acceptance of the user on a dynamic virtual keyboard. Figure 7: An example of a graphical representation of a contract Figure 8: An example of two different transactions on the mobiles of two different users, illustrating the variability / invariance of the ZIS Figure 9: Remote server for the calculation of the ZIS, adapting the kinematics of Figure 4 to this particular case.

The ZIS is generated by a trusted element following receipt by the latter of the message 5, message corresponding to the contract proposed by the provider. This trusted element is either the OS itself or a remote server accessible by means of communication of the user's terminal, this means making it possible to establish a secure channel between the user's terminal and the OS when the transport network used is open and public like Internet-type networks.

The format / structure of the ZIS (position of the fields, background, colors, orientations ...) is variable for each user for each transaction. In an alternative implementation of the invention the structure of the ZIS could be defined by the user, which would allow him to participate in the verification of the authenticity and integrity of the information presented in the ZIS because of the respect of the previously defined structure. This user-specific description then imposes on the OS (which is the property of a user) or on the remote server (which is common to a set of users) the management of format and structure data of the ZIS associated with the user. this user. In a secondary implementation of the invention an appropriate interface allows the user's terminal, after an authentication phase, to define and structure its own ZIS by inserting the elements of its choice, elements corresponding to the capabilities of the user. generation by the SE of ZIS. The object of this variation for each of the transactions of the ZIS structure is to make very difficult the automatic attacks on formats not known a priori and can not be predicted because of the generation algorithms implemented by the component SE .

The invention is therefore based on a method of generating the ZIS object and taking it into account in the various steps of the transaction: this object therefore has the following particularities:

at. an attack on the integrity of the ZIS (for example to change the amount or description of the service) would require a complex analysis to understand the different content fields, and make relevant and consistent changes. b. The control of the user acceptance is done through a conventional confidential code (CC). The theft of the authenticator of the user (CC) is countered by the use of a secret code CS generated randomly by the SE, visualized according to the principles a / above, and that only the user is capable of to read, and thus to type on the keyboard in addition to its confidential code o or / and by a technique of input on a dynamic virtual keyboard visualized according to the principles a / above. The choice of one or the other of the methods and the value of the CC is made during the registration of the user and the personalization of the SE.

More precisely, the following characteristics are applied:

Generation of the ZIS - The calculation of the ZIS by the SE (9) can be limited to the portions of the ZIS that are to be protected, so as to minimize the calculations to be made in the SE (9). - The ZIS (or the portions of the ZIS to protect) is a graphic object on the screen of the personal terminal, incorporating among other principles the concepts of "captcha"; the associated kinematics is described in figure 4 - It is generated by the SE (9), which is a trusted element, by an application Appli_ZIS (14) executing in the SE (9) which receives the contract thanks to the message (13) sent by the terminal to the SE (9) after receiving the message (5) containing the contract sent by the provider (4) to the terminal (2). It is sent by the SE (9) to the terminal (2) in the form of a sequence of pixels, to make it difficult for a virus in the terminal (2) any significant change. - The ZIS is authenticated by the client thanks to its graphic properties 5 - It can not be modified by a virus in the terminal: A significant change would require an understanding of the information in the window This would require an image analysis, segmentation / transformation 2D / separation of fields, and recognition of characters in limited time to a few seconds which is the maximum time that the user must respect to accept or refuse the contract.

Confirmation of the agreement: According to Figure 4, if the user agrees, he provides his terminal the confidential code CC (message 7). The SE (9) contains an application Appli_ZIS (11) which controls the CC, performs certain additional checks specific to the application in question, and calculates the signature that it sends back to the terminal by the message (12). The invention describes two methods for entering and controlling the PIN, both of which prevent a DC-type attack, corresponding to two embodiments of the invention described below. Both methods can be used simultaneously.

- Secret code CS: The interactions relating to this mode are described in FIG. 5. A secret code CS is generated randomly at the same time as the ZIS by the application Appli_ZIS (14) in the SE (9).

The Appli_ZIS sends to the Appli_SIG by the message (16) the data necessary to conclude the transaction, therefore value of the generated CS and the data of the contract obtained in (13). The CS is part of the graphic elements of the ZIS, and can not be read by a virus in the terminal. The ZIS and this CS are transmitted to the terminal by the message (15), and the terminal displays it on the screen: (6). Figure 7 gives an example of a graphical representation of the ZIS where the CS appears with the value "143"; but another user could have a totally different ZIS from the point of view of the background and the presentation of the different fields. The user if he agrees informs the fields CC and CS (with what he reads on the screen: "143"): message (7) The CC control (permanent data recorded at the personalization) and the CS (data generated by the application Appli_ZIS (14) and sent to the application Appli_SIG (11) in the message (16) .If a virus "steals" the CC, the CS being variable with each transaction, this virus does not can only "force" the agreement of the client.The application (II) can carry out additional controls or complementary processing specific to the type of transaction, then it elaborates a signature of the elements of the contract received in the message (16) .This signature is valid user agreement, and is sent to (12) the terminal, which returns it in (8) to the service provider note that this procedure also allows to counter a replay attack: the malware in the terminal (2 ) would re-use a ZIS from a previous transaction, since the CS changes to a This is why it can also be used with the method described below. This method is easily adapted to the case where the CC is replaced by a biometric characteristic specific to the user, measured on the terminal. In the messages (7) and (10), it is then necessary to replace the data CC with a characteristic data of the measured biometric data, which is verified by the Appli_SIG application (11). Examples of biometric characteristics particularly suited to the context of the invention are the fingerprint, the typing dynamics, the face recognition ....

- Dynamic Virtual Keyboard (CVD) 6

In order to avoid the spying by malicious software CC characters entered on the keyboard of the terminal, we use here a dynamic keyboard (the position of the keys is varaible to each transaction) drawn on the screen of the terminal (2) to inside the ZIS. This embodiment can be combined with the previous mode.

The dynamic keyboard (ie the order of the keys of the numeric keypad displayed on the screen) is generated randomly in the SE (9) by the application Appli_ZIS (14) and transmitted to the terminal (message 15) ; the terminal displays the graphic window and the dynamic keyboard on the screen: 6. The Appli_ZIS sends to the Appli_SIG by the message (16) the data necessary to conclude the transaction, therefore the description of the CVD generated and the data of the contract obtained in (13). The user, if he agrees, enters (7) his CC on the virtual keyboard. The terminal transmits the positions of the clicks (x, y coordinates of the clicks) in (10). The positions of the clicks are recognized by the application Appli_SIG (II) compared to the dynamic keyboard generated in the previous step by the Appli_ZIS (14), and sent to the application (11) by the message (16). This is for example a table containing a set of elements {symbol; position x, y; dimension key} where symbol is one of the symbols {1 2 3 4 5}. The application (II) therefore deduces the numbers of the CC typed by the user, which it compares to the CC registered personalization of the SE. If this control of the DC is positive, the application Appli_SIG (11) can carry out additional controls or complementary processing specific to the type of transaction, then it elaborates a signature of the elements of the contract received in the message (16). This signature is the user's agreement, and is sent to the terminal (12), which sends it back to the service provider (8).

Generation of the graphic window In order to make recognition and modification by software in the terminal (2) difficult, one or more of the following methods can be used, as shown in FIG. The characteristics of the ZIS vary according to the user, who can choose some; they are fixed during the customization of the OS for a given user: - order and position of the fields, - fonts used, - character orientation of certain fields, spacing, superposition - background: pattern mixing (including same color) that the texts whose recognition must be prevented. - redundancy (for example the amount which is a particularly important field can be duplicated); thus a partial modification by a virus would be detected by the user who would see that the two amounts are not identical) - drawing by the user of his own font (this is the case of Figure 7 for the rising fields) and security code). - Random disruption to prevent malware from acting by correlation / pattern recognition (case of Figure 7)

Mobile Dependency and Transaction Independence The security of the ZIS requires that the user have prior knowledge of their on-screen presentation, in order to detect any attempted attack by a virus that would use a standard ZIS. Thus, the ZIS is displayed as shown in FIG. 8, and in the case of the embodiment of the protection of the confidential code based on the CS (the adaptation to the other mode (CVD) is immediate). o Specifically for each user: colors, textures, shapes of the ZIS vary from one mobile to another: for example the key that symbolizes a 7

secure transaction appears in a different color and position on the mobile users 1 and 2 of Figure 8. These characteristics are dependent on the mobile of the user considered. o For a user, similarly from one transaction to another. therefore, the user will be able to recognize colors, textures, forms that he finds at each transaction, as shown in Figure 8 o Note that these common sense principles do not prevent the introduction of graphical disturbances in the ZIS for a given user and various transactions, in order to avoid correlation attacks. o The only principle to be respected is that these variations do not prevent the user from detecting an abnormal behavior of the transaction processing software, revealing an attack. An example is given in FIG. 7. The rising and CS zones use a user-specific font, on a background of variable motive, and moreover, variable lines are superimposed on these zones without altering their readability by one eye. human, while making any correlation and recognition of character almost impossible. The set of parameters corresponding to the characteristics of the invariant ZIS for a given user, are registered during the registration of this user, in his SE.

A variant of the invention uses audio It is possible in addition or in replacement to display the contract on the PC or Mobile screen, to vocalize some of its fields. This vocalization must be done to the maximum in the OS, which must send to the terminal indications on the formants of the messages to be pronounced, therefore a set (tone, duration, transition with the next phoneme). This is the reason why in practice it is limited to the vocalization of numerical fields such as the financial amount, since a complete alphanumeric summary of the contract would be outside the possibilities of the ES. Here again it is necessary to keep the principle of mobile dependence and transaction independence: the background noise, the tone used .., will be specific to a particular user, and thus allow this one to be alerted to any changes from what he is used to. The confirmation of the user's agreement is identical to that described above.

Another variant of the invention uses video Some fields may be presented with scrolling, according to parameters imposed by the OS at the terminal. The confirmation of the agreement of the user is identical to that described above One embodiment of the invention is based on the following principles to calculate the ZIS in the SE (9) by the application (14) to limit the computing load of the OS (which is a simple smart card chip) that could be crippling without an appropriate implementation. Furthermore, this processing can be limited to the portion of the ZIS that must be protected, the rest can be done in the terminal: in Figure 7, only two fields are protected: the amount, and the CS to which is added the amount

o The graphic data are fixed to the personalization of the chip, since these data are constant for a given user. These data are: a. Size of the ZIS window (or portion of ZIS): n, m b. Background: n. m pixels 8 c. The parameters of a field are: 1. Its identifier 2. Position of the origin of the field in the ZIS (or of the portion of ZIS), 3. font used, 4. number of characters, 5. dx, dy = offset values between characters (dy = 0 for horizontal variation) 6. character orientation (among a small number of orientations: -20 °, 0 °, + 20 °) d. Font: for example, it is limited to ten digits for the amount of a payment transaction, or the CS. When variable orientations are allowed, (3 in the previous case) the font is described as many times as possible (three) in the previous case. 1. Rectangle dimension containing the characters 2. Rectangle pixel values

o There is no geometric transformation to perform during the transaction (translation, rotation, scale): indeed, the calculation of the pixels of the ZIS (or the portion of ZIS) o Display: it is a simple an assembly function which is based on a position pixel computation primitive (x, y) in the ZIS (or the portion of ZIS) o deduce with the parameters c2 and c5 the field concerned, and if n there is none, deduce the pixel with the parameter b, and end o deduce the character concerned with the parameter c5 o with the parameters c3 and c6 deduce the pictogram of the character o deduce with the parameter dl the relative coordinates x 'y' with respect to the character o with the parameter d2, calculate pixel with the pixel of the character or the pixel (x, y) of the background if the pixel is not on the character's path. o End: go to the next pixel: if x <n, (x + 1, y), and if not if y <m, (0, y + 1) or otherwise calculate the ZIS (or the portion of ZIS) is finished.

Another embodiment: It is based on the creation by the user of his own font: it draws on a graphical input means the graphic symbols representing the 10 digits. This can be done easily on any "smart-phone", since their screens are graphic and pointy with a stylus. It is understood that this embodiment responds well to the principle of mobile dependence and transaction independence, allowing the user to detect any presence of malicious software. Indeed, no character recognition algorithm used by this malware can work with fonts completely unpredictable, as is the case in this variant. The figure 7 is placed in this hypothesis: one sees that the figures which appear in the amount and the CS do not correspond to usual fonts! The case of audio Given the very limited context of speech synthesis in which we place ourselves (vocalization only of digital data) the technique of "phonemes" is classic and proven, and implementable in an SE. 9 2961330 Remote implementation through a secure channel with a trusted server

The OS, in the case of the SIM, can establish secure communication with a remote server, as shown in FIG. 9. This security is end-to-end. Standards ETSI ETSI TS 102 484 V7.1.0 (2008-07) Technical Specification: Smart Cards; Secure channel between UICC and an end-point terminal describe such a possibility, and ETSI TS 102 225 Technical Specification Smart Cards; Secured packet structure for UICC based applications describe this feature.

The ZIS can therefore be carried out not by the SE itself, but by a non-attackable trusted server (17) with which the OS and the terminal communicate via the wired internet network (case of the PCs) or radio (case mobile): o The OS establishes a secure end-to-end secure channel (18) through the terminal, enabling the contract data to be securely conveyed from the SE to the server, as well as the description of the CVD or the value of CS generated by the Appli_ZIS (14). The theft of this data would allow malicious software on the terminal (2) to force the agreement of the user, hence the importance of the secure channel at this level. O The server returns (19) to the display terminal the graphic data of the ZIS (without security, at this level, because of the integrity properties of the ZIS described above) o The terminal displays the ZIS: (6) . o The rest of the exchanges are identical to the previous cinematics.

Note that this variant is well suited to the case of a multimedia ZIS, because in this case, the computing power of the server can accommodate a complete lack of restriction with respect to the multimedia format used. The message 19 may be a video with the associated sound, sent in one of the conventional formats existing on the Internet. 30 10

Claims (4)

REVENDICATIONS1. Method for securing electronic transaction between a user (1) and a provider (4), said method comprising at least the following steps: - Transmission by said provider (4) of a contract sent in a message (5) to the terminal (2) of said user (1) and transmitted by the terminal (2) through a message (13) to a security element SE (9), Return by said security element SE (9) elements of the transaction to the terminal (2) in a message (15) for display (6) by the terminal (2) to the user (1) and acceptance (or refusal) (7) by the latter of the transaction, input on said terminal (2) of the acceptance (or refusal) (7) by the user (1) of the contract displayed in (6), Transmission by said terminal (2) of the acceptance (or refusal) (10) to the security element SE for processing with a view to issuing a signed (or refusal) acceptance message (12) to the terminal (2), then (8) from the terminal (2) to the prestata ire (4). said method being characterized in that: The contract provided (15) by the OS (9) to the terminal (2) for display to the user is a graphic object called ZIS, and designed to be integrity-protected, - The object ZIS is constituted by a variable assembly of the graphical representations of the elements constituting the contract (5) between the provider (4) and the user (1). - The ZIS object is further disturbed by the addition of non-graphical elements. constituting the contract, - the security element SE carries out an analysis of the acceptance of the user (or the refusal) and calculates if necessary a validation and signed acceptance message of the transaction (12) the coherence with the constituent elements of the contract displayed in the ZIS and the signed acceptance is ensured by the SE. 2- Method according to claim 1, characterized in that said step of calculating the ZIS by the SE is limited to the portions of the ZIS that are to be protected. 3- Method according to claims 1 to 2 characterized in that said step of accepting the terms of the contract (5) presented in (6) to the user (1) on the screen of the terminal (2) comprises a step of seizure (7) of a confidential code (CC) by the user (1). The CC and its control mode described below are personalization data of the SE (9). 4- Method according to claims 1 to 3 characterized in that the protection of the ZIS (or a portion of the ZIS) against malicious modifications by software in the terminal (2) is provided by at least one of the following elements : o the portion of the ZIS to be protected is represented by means of random graphic formats and features, as well as a subset of the constituent elements of the contract, the representation of which depends on choices pre-established by the user. o The portion of ZIS to be protected is sent in (15) by the SE (9) to be displayed by the terminal (2) in the form of a series of pixels. o The ZIS is easily interpreted by the user, but malware in the terminal (2) can very easily change without alerting the user (1). 11- Method according to claims 1 to 4, characterized in that the customer acceptance phase of the proposed transaction is enriched with the following steps: o The application Appli_ZIS (14) of the SE (9) adds to the ZIS a security code (CS) that it has randomly chosen for the current transaction, o Appli_ZIS application (14) sends by a message (16) the value of the security code CS to the signature application (11). oThe CS code is read and entered by the user in (7) during the acceptance phase. oThe signature application receives in (10) the CC and CS introduced in (7) by the user and controls the CC according to the personalization data of the SE (9) and the CS with respect to the CS contained in the message (16). 6. The method of claim 5 characterized in that the acceptance phase by the user uses a biometric technique instead of the CC. 7- Method according to claims 1 to 4, characterized in that the customer acceptance phase of the proposed transaction corresponds to the following steps: o the elements of a CVD (dynamic virtual keyboard, the positioning of the keys is variable randomly at each transaction) are generated in the SE (9) by the application Appli_ZIS (14) in the constituent elements of the ZIS. oAppi_ZIS application (14) transmits the indications on the position of the virtual keys to the signature application (11) of the SE (9) by the message (16). o The entry on the dynamic virtual keyboard of the CC (7) results in a series of "clicks" whose coordinates on the screen are transmitted in (10) to the signature application (11). o The signature application checks the acceptance of the user by the correspondence between the position of the "clicks" collected and those coming from the message 16. 8-Method according to claims 1 to 7, characterized in that the application Appli_ZIS (14) implements a graphic processing minimization technique for calculating the ZIS (or protected parts of the ZIS) based on the assembly of pixels from different rectangular areas, without complex geometric calculations, and uses personalization data introduced in the SE (9) in a specific manner to a given user (1): o graphical representation of the digits or letters used in the ZIS o choice among a plurality of possible choices of characteristics constituting the ZIS 35 9- Method according to the Claims 1 to 7, characterized in that all or part of the information of the ZIS is presented in audio form to the user. 10- Method according to claims 7 there, characterized in that said step of computing the ZIS 40 by the SE (9) is subcontracted to an external trusted server through the following steps: o establishment of a secure channel (18) between the SE (9) and an external server (17) o transmission on this channel by the SE (9) to the external server (17) of the proposed contract data in (5) and received from the terminal (13). ). oemission of the external server (17) to the terminal (2) by the message (19) of the graphical data of the ZIS. oemission of the server (17) to the SE (9) data securing the seizure of the CC, according to claims 5 or 6. through the secure channel (18). 11. The method according to claims 1 to 7 and 10, characterized in that the ZIS calculated by the ZIS server (17) can be a multimedia object (audio, and / or still image and / or video), without any restrictions. required by the possible low ES calculation capabilities. 12