FR2984648A1

FR2984648A1 - Method for providing response to request by individual electronic system for banking transaction, involves analyzing specific signature using cryptographic unit, where part of unit is selected based on result of analysis of signature

Info

Publication number: FR2984648A1
Application number: FR1161991A
Authority: FR
Inventors: Rami Wehbi
Original assignee: Oberthur Technologies SA
Current assignee: Idemia France SAS
Priority date: 2011-12-20
Filing date: 2011-12-20
Publication date: 2013-06-21
Anticipated expiration: 2031-12-20
Also published as: FR2984648B1

Abstract

The method involves receiving a command that includes a characteristic of a specific action, and analyzing the specific action. A specific signature is analyzed (4000) using a cryptographic unit (4100), and the analyzed signature is transmitted. A part of the cryptographic unit is selected based on a result of analysis of the signature. The cryptographic unit is arranged with a cryptographic key that is selected according to the result of analysis of the signature. The cryptographic unit is arranged with an encryption algorithm (4300). Independent claims are also included for the following: (1) a computer program comprising instructions for performing a method for providing response to a request by an individual electronic system (2) an individual electronic system (3) a method for authentication of relative information (4) a computer program comprising instructions for performing the method for authentication of relative information (5) a server.

Description

Domaine technique et art antérieur L'invention s'inscrit dans le domaine des dispositifs électroniques individuels, parmi lesquels notamment les solutions de paiement électroniques utilisant des moyens de paiement portables, comme les cartes bancaires, communiquant avec des terminaux de paiement. TECHNICAL FIELD AND PRIOR ART The invention is in the field of individual electronic devices, including in particular electronic payment solutions using portable payment means, such as bank cards, communicating with payment terminals.

La norme EMV (« Europay Mastercard Visa ») définit actuellement les spécifications que les acteurs du paiement bancaire doivent respecter. Les outils de paiement impliqués sont notamment les cartes de paiement à microcircuit (cartes à puce) et les terminaux de paiement disponibles chez les commerçants. Au-delà des cartes à puce, d'autres moyens de paiement mobiles - portables - disposant d'un microcircuit ou d'un microcontrôleur capable d'effectuer au moins quelques opérations électroniques, voire bien plus, sont utilisés ou appelés à se développer. C'est le cas par exemple des dispositifs NFC (c'est-à-dire communiquant suivant la norme « Near Field Communication »), intégrés par exemple dans les téléphones portables. Ces systèmes impliquent plusieurs acteurs, parmi lesquels le détenteur du moyen de paiement, le commerçant disposant d'un terminal de paiement et l'émetteur du moyen de paiement, qui est typiquement une banque ou un groupement de gestions de cartes ou moyens de paiement. De plus, une autorité de certification distincte de la banque est chargée de délivrer à ces différents acteurs des éléments d'authentification tels que des clés ou des certificats électroniques. Une transaction chez un commerçant comprend, conformément à la norme EMV, décrite dans le document « EMV Integrated Circuit Card 30 Specifications for payment Systems version 4.2 » une analyse de la transaction envisagée par le terminal puis une analyse de la transaction par le moyen de paiement. Le résultat de cette double analyse est transmis à l'émetteur du moyen de paiement, avec un cryptogramme signant l'analyse et permettant ainsi d'authentifier le moyen de paiement. The EMV ("Europay Mastercard Visa") standard currently defines the specifications that the banking payment actors must respect. The payment tools involved include payment cards with microcircuit (smart cards) and payment terminals available at merchants. Beyond smart cards, other mobile payment means - portable - with a microcircuit or a microcontroller capable of performing at least some electronic operations, or even more, are used or expected to develop. This is the case for example NFC devices (that is to say communicating according to the "Near Field Communication" standard), integrated for example in mobile phones. These systems involve several actors, among which the holder of the means of payment, the merchant with a payment terminal and the issuer of the means of payment, which is typically a bank or group of card management or payment means. In addition, a certification authority separate from the bank is responsible for delivering to these various actors authentication elements such as keys or electronic certificates. A transaction at a merchant includes, in accordance with the EMV standard, described in the document "EMV Integrated Circuit Card 30 Specifications for Payment Systems version 4.2" an analysis of the transaction envisaged by the terminal and an analysis of the transaction by the means of payment . The result of this double analysis is transmitted to the issuer of the means of payment, with a cryptogram signing the analysis and thereby authenticating the means of payment.

Par facilité de langage, on dit qu'un cryptogramme comprenant le résultat de l'analyse est généré et transmis. Cela est effectué systématiquement, que le résultat de l'analyse soit positif ou négatif. Dans certains cas, le résultat de l'analyse consiste en une décision de demander une autorisation à l'émetteur du moyen de paiement. Cette demande d'autorisation est également signée par un cryptogramme. Dans tous les cas, le cryptogramme est généré de la même manière à partir d'une clé-maître contenue dans la carte et qui y a été préalablement inscrite par l'émetteur, après avoir été délivrée par l'autorité de certification. Cette solution présente un problème car elle offre, dans une certaine mesure, une faille vis-à-vis des attaques consistant à enregistrer les réponses d'une carte à laquelle est demandée successivement un grand nombre de transactions d'un montant supérieur au seuil autorisé dans la mémoire de la carte. Ces attaques, effectué par un tiers malveillant s'étant procuré la carte et disposant d'un lecteur de carte adéquat, sont effectués en accumulant un nombre important de réponses de la carte. Cela permet dans certaines circonstances à l'attaquant de déterminer, par analyse des signaux électriques générés par la carte, les moyens cryptographiques, tels que des clés, authentifiant le moyen de paiement. For ease of language, it is said that a cryptogram comprising the result of the analysis is generated and transmitted. This is done systematically whether the result of the analysis is positive or negative. In some cases, the result of the analysis is a decision to request authorization from the issuer of the means of payment. This authorization request is also signed by a cryptogram. In all cases, the cryptogram is generated in the same way from a master key contained in the card and which has been previously entered by the issuer, after being issued by the certification authority. This solution presents a problem because it offers, to a certain extent, a flaw with respect to the attacks consisting in recording the responses of a card to which is successively requested a large number of transactions of an amount greater than the authorized threshold. in the memory of the card. These attacks, carried out by a malicious third party having obtained the card and having an adequate card reader, are made by accumulating a large number of responses of the card. This allows the attacker in certain circumstances to determine, by analyzing the electrical signals generated by the card, the cryptographic means, such as keys, authenticating the payment means.

Résumé de l'invention L'invention vise à résoudre ce problème et pour cela propose un procédé de réponse par un dispositif électronique individuel à une 30 sollicitation, le procédé comprenant une réception d'une commande comprenant au moins une caractéristique d'une action envisagée, une analyse de ladite action envisagée, puis une signature de ladite analyse à l'aide de moyens cryptographiques et l'émission de ladite analyse signée, caractérisé en ce qu'au moins une partie desdits moyens cryptographiques est choisie en fonction d'un résultat de ladite analyse. Un tel procédé constitue une avancée considérable dans le domaine de la sécurité des actions réalisées à l'aide d'un dispositif électronique portable, par exemple les transactions bancaires, et des paiements électroniques en général, car il sécurise considérablement les dispositifs électroniques portables contre les attaques du type évoqué plus haut. En effet, l'accumulation de réponses à des demandes d'action - ou sollicitation - par exemple pour des montants excessivement élevés, ne peut pas permettre de découvrir la clé-maître ou les moyens cryptographiques utilisés pour générer une acceptation par la carte, puisqu'au moins une partie des moyens cryptographiques utilisés est dépendante du résultat de l'analyse. Le nouveau procédé ne découle aucunement des connaissances disponibles jusque-là. On remarquera, par exemple, que le document JP2004184959 évoque, sans application particulière aux paiements électroniques, la génération de plusieurs cryptogrammes à partir d'une clé unique. Il ne divulgue pas l'utilisation d'un résultat d'une analyse d'une transaction envisagée pour choisir des moyens cryptographiques. Selon une caractéristique de mise en oeuvre, les moyens cryptographiques comprennent une clé de cryptographie, ou/et un algorithme de chiffrement, par exemple un algorithme triple DES. Ils peuvent également comprendre un algorithme de génération de code d'authentification de message. Selon une caractéristique de mise en oeuvre, l'algorithme de génération de code d'authentification de message est appliqué à des 30 données dépendant de ladite transaction comprenant par exemple un compteur de transactions, un montant de la transaction ou une date de la transaction. Par ailleurs, typiquement, le résultat est une acceptation, un refus, ou une demande d'accord à une autorité tierce distante, par exemple un émetteur du dispositif électronique individuel. L'invention propose aussi un programme informatique comprenant des instructions aptes à mettre en oeuvre, quand elles sont exécutées par un dispositif comprenant un microcontrôleur et une mémoire, chacune des étapes d'un procédé tel qu'évoqué précédemment. SUMMARY OF THE INVENTION The invention aims to solve this problem and for this purpose proposes a method of response by an individual electronic device to a solicitation, the method comprising receiving a command comprising at least one characteristic of an intended action. , an analysis of said envisaged action, then a signature of said analysis using cryptographic means and the transmission of said signed analysis, characterized in that at least a part of said cryptographic means is chosen according to a result of said analysis. Such a method constitutes a considerable advance in the field of security actions performed using a portable electronic device, for example banking transactions, and electronic payments in general, because it significantly secures portable electronic devices against attacks of the type mentioned above. Indeed, the accumulation of responses to requests for action - or solicitation - for example for excessively high amounts, can not make it possible to discover the master key or the cryptographic means used to generate acceptance by the card, since at least part of the cryptographic means used is dependent on the result of the analysis. The new process does not derive from the knowledge available until then. It will be noted, for example, that document JP2004184959 evokes, without particular application to electronic payments, the generation of several cryptograms from a single key. It does not disclose the use of a result of an analysis of a contemplated transaction to choose cryptographic means. According to an implementation characteristic, the cryptographic means comprise a cryptographic key, or / and an encryption algorithm, for example a triple DES algorithm. They may also include a message authentication code generation algorithm. According to an implementation characteristic, the message authentication code generation algorithm is applied to data dependent on said transaction comprising for example a transaction counter, an amount of the transaction or a date of the transaction. Typically, however, the result is an acceptance, a denial, or a request for agreement from a remote third authority, for example a sender of the individual electronic device. The invention also proposes a computer program comprising instructions able to implement, when they are executed by a device comprising a microcontroller and a memory, each of the steps of a method as mentioned above.

Selon un autre aspect, l'invention consiste en un dispositif électronique individuel comprenant un microcontrôleur et une mémoire, le dispositif électronique individuel répondant, quand il est sollicité en vue d'une action envisagée, en analysant l'action envisagée, et en mettant en oeuvre des moyens cryptographiques pour signer l'analyse produite, caractérisé en ce que le dispositif électronique individuel choisit au moins une partie desdits moyens cryptographiques en fonction d'un résultat de l'analyse. Avantageusement, le dispositif électronique individuel comprend une carte à microcircuit dans une mémoire de laquelle sont enregistrés les moyens cryptographiques. Le dispositif, qui peut être un moyen de paiement, peut être conforme à la norme EMV, ou comprendre une interface de communication NFC, et être par exemple intégré dans un terminal de téléphonie mobile. Selon un autre aspect de l'invention, celle-ci consiste en un procédé d'authentification d'informations relatives à une action par une autorité distante, le procédé comprenant la vérification à l'aide de moyens cryptographiques, de l'authenticité d'une signature reçue avec les informations de transaction, caractérisé en ce que les moyens cryptographiques sont choisis en fonction d'un résultat d'analyse reçu également avec les informations de transaction. According to another aspect, the invention consists of an individual electronic device comprising a microcontroller and a memory, the individual electronic device responding, when it is solicited for a planned action, by analyzing the action envisaged, and by setting implement cryptographic means to sign the generated analysis, characterized in that the individual electronic device selects at least a portion of said cryptographic means according to a result of the analysis. Advantageously, the individual electronic device comprises a microcircuit card in a memory of which the cryptographic means are recorded. The device, which may be a means of payment, may be in accordance with the EMV standard, or comprise an NFC communication interface, and be for example integrated in a mobile telephone terminal. According to another aspect of the invention, it consists of a method for authenticating information relating to an action by a remote authority, the method comprising the verification using cryptographic means, the authenticity of a signature received with the transaction information, characterized in that the cryptographic means are chosen according to an analysis result also received with the transaction information.

L'invention propose aussi un programme d'ordinateur comprenant des instructions aptes à mettre en oeuvre, quand elles sont exécutées par dispositif comportant un microprocesseur et une mémoire, chacune des étapes d'un procédé selon la revendication de procédé d'authentification précédente. Enfin, selon un autre aspect de l'invention, celle-ci consiste en un serveur qui, quand il reçoit des informations relatives à une action signées en provenance de terminaux, vérifie à l'aide de moyens cryptographiques, l'authenticité d'une signature reçue avec les informations relatives à une action, caractérisé en ce que les moyens cryptographiques sont choisis en fonction d'un résultat d'analyse reçu également par le serveur avec les informations. Brève description des figures L'invention va maintenant être décrite en relation avec les figures annexées suivantes : La figure 1 présente les éléments matériels mettant en oeuvre l'invention La figure 2 présente les messages échangés entre ces différents éléments matériels. Les figures 3 et 4 présentent les actions effectuées par les éléments de la figure 1. La figure 5 présente un détail des figures 3 et 4, qui constitue une étape de signature. La figure 6 présente un détail des figures 3 et 4, qui constitue une étape d'authentification. Exposé détaillé de l'invention En figure 1, on a représenté les éléments matériels mis en oeuvre dans l'invention. Une carte de paiement 100, détenue par une personne physique client d'une banque, est utilisée en relation avec un terminal de paiement 200. La carte 100 constitue un dispositif électronique individuel. Le terminal de paiement est en la possession d'un commerçant, a été fourni à celui-ci par une banque, et dispose de moyens de lecture de cartes similaires à la carte de paiement 100. Les banques ayant fourni respectivement la carte de paiement 100 et le terminal de paiement 200 peuvent être différentes. Le terminal de paiement 200 est relié par un réseau de communication 400 à un serveur de banque 300 appartenant à la banque qui a émis la carte de paiement 100 ou à un groupement de gestions de cartes de paiement. La mise en relation du terminal 200 et du serveur 300 est faite, en cas de besoin, au moment où une transaction est envisagée ou peu de temps après une transaction. La carte de paiement 100 comprend un microcontrôleur et une mémoire, dans laquelle sont enregistrés les moyens informatiques nécessaires au procédé de réponse selon l'invention. En figure 2, on a représenté les échanges entre les éléments qui viennent d'être présentés. Le scénario décrit est celui d'une transaction chez un commerçant. La transaction débute par des étapes, non représentées, au cours desquelles le commerçant lance l'application du terminal 200 puis introduit dans celui-ci les données de la transaction, notamment son montant, et au cours desquelles le terminal 200 effectue une évaluation de risques liés à la transaction (par exemple en prenant en compte des caractéristiques d'assurance) et le détenteur de la carte 100 s'authentifie en entrant son code personnel. De plus, la carte 100 et le terminal 200 s'authentifient mutuellement par une méthode de type DDA (pour « Dynamic Data Authentication»), à l'aide de clés de cryptographie asymétrique et de certificats. Une fois ces opérations effectuées, le terminal 200 effectue une analyse des données de la transaction, puis envoie à la carte 100 une 30 commande GENERATE AC 1000 (il s'agit d'une commande APDU, ce qui 2 98464 8 7 signifie « Application Protocol Data Unit », ou unité élémentaire de communication en matière de cartes à microcircuit - AC signifie « Application Cryptogram »). Cette commande constitue une sollicitation de la carte 100 par le terminal 200, en vue d'une transaction. Elle contient 5 les données de la transaction. La carte 100 procède ensuite à l'analyse de la transaction puis envoie au terminal 200 un message de réponse 1100 (réponse APDU). En fonction du contenu du message de réponse 1100, le terminal 200 peut devoir émettre une demande d'autorisation 1200 à destination 10 du serveur de banque 300. Dans ce cas, le serveur de banque 300 procède ensuite à une analyse des données de la transaction et envoie ensuite au terminal 200 une réponse de la banque 1300. Le terminal 200 génère alors une deuxième commande GENERATE AC 1400 (commande APDU), qui est transmise à la carte de paiement 100, celle-ci interprète 15 cette commande et y répond par un deuxième message de réponse 1500 (réponse APDU) transmis au terminal de paiement 200. Celui-ci effectue la transaction 1600 à ce stade, si elle a été autorisée. Le terminal effectue ensuite une étape de transmission finale 1700 à destination du serveur de banque 300, pour vérification finale de la transaction et mise à jour de 20 bases de données. Dans certains cas, en fonction du contenu du message de réponse 1100, les étapes 1200 à 1500 ne sont pas effectuées, car il n'est pas nécessaire que le terminal 200 demande une autorisation au serveur de banque 300. Dans ce cas, la transmission du message de réponse 1100 25 est directement suivie par la transaction 1600, si elle a été autorisée, puis par une étape de transmission finale 1700, transmission effectuée du terminal de paiement 200 au serveur de banque 300. Le fait que les étapes 1200 à 1500 ne sont pas toujours effectuées est représenté sur la figure par des pointillés. The invention also proposes a computer program comprising instructions able to implement, when they are executed by a device comprising a microprocessor and a memory, each of the steps of a method according to the preceding authentication method claim. Finally, according to another aspect of the invention, the latter consists of a server which, when it receives signed action-related information from terminals, verifies by means of cryptographic means, the authenticity of a message. signature received with the information relating to an action, characterized in that the cryptographic means are chosen according to a result of analysis also received by the server with the information. BRIEF DESCRIPTION OF THE FIGURES The invention will now be described with reference to the following appended figures: FIG. 1 shows the hardware elements implementing the invention FIG. 2 shows the messages exchanged between these different hardware elements. Figures 3 and 4 show the actions performed by the elements of Figure 1. Figure 5 shows a detail of Figures 3 and 4, which is a signature step. FIG. 6 shows a detail of FIGS. 3 and 4, which constitutes an authentication step. DETAILED DESCRIPTION OF THE INVENTION FIG. 1 shows the material elements used in the invention. A payment card 100, held by a natural person customer of a bank, is used in connection with a payment terminal 200. The card 100 constitutes an individual electronic device. The payment terminal is in the possession of a merchant, has been provided to it by a bank, and has means for reading cards similar to the payment card 100. The banks having respectively provided the payment card 100 and the payment terminal 200 may be different. The payment terminal 200 is connected by a communication network 400 to a bank server 300 belonging to the bank that issued the payment card 100 or to a management group of payment cards. The connection of the terminal 200 and the server 300 is made, if necessary, at the moment a transaction is envisaged or shortly after a transaction. The payment card 100 comprises a microcontroller and a memory, in which the computer resources required for the response method according to the invention are recorded. In Figure 2, there is shown the exchanges between the elements that have just been presented. The scenario described is that of a transaction at a merchant. The transaction begins with steps, not shown, in which the merchant launches the application of the terminal 200 and then enters the transaction data, including the amount thereof, during which the terminal 200 performs a risk assessment. related to the transaction (for example taking into account insurance characteristics) and the cardholder 100 authenticates by entering his personal code. In addition, the card 100 and the terminal 200 mutually authenticate with a DDA (Dynamic Data Authentication) type method, using asymmetric cryptography keys and certificates. Once these operations are completed, the terminal 200 performs an analysis of the data of the transaction, then sends the card 100 a GENERATE command AC 1000 (this is an APDU command, which means "Application" Protocol Data Unit ", or basic communication unit for microcircuit cards - AC stands for" Application Cryptogram "). This command constitutes a solicitation of the card 100 by the terminal 200, in view of a transaction. It contains the data of the transaction. The card 100 then proceeds to analyze the transaction and sends the terminal 200 a response message 1100 (APDU response). Depending on the contents of the response message 1100, the terminal 200 may need to issue a request for authorization 1200 to the bank server 300. In this case, the bank server 300 then proceeds to an analysis of the data of the transaction. and then sends to the terminal 200 a response from the bank 1300. The terminal 200 then generates a second GENERATE AC command 1400 (APDU command), which is transmitted to the payment card 100, which interprets this command and responds to it by a second response message 1500 (APDU response) transmitted to the payment terminal 200. This makes the transaction 1600 at this stage, if it has been authorized. The terminal then performs a final transmission step 1700 to the bank server 300, for final verification of the transaction and update of 20 databases. In some cases, depending on the content of the response message 1100, steps 1200 to 1500 are not performed because it is not necessary for the terminal 200 to request authorization from the bank server 300. In this case, the transmission of the response message 1100 is directly followed by the transaction 1600, if it has been authorized, then by a final transmission step 1700, transmission made from the payment terminal 200 to the bank server 300. The fact that the steps 1200 to 1500 are not always performed is shown in the figure by dashed lines.

L'étape de transmission finale 1700 peut être effectuée alors que la carte 100 n'est plus en liaison avec le terminal 200, par exemple quand le terminal est un terminal portable et qu'il a été reposé sur son socle. On parle alors de vérification décalée, hors ligne. The final transmission step 1700 can be performed while the card 100 is no longer connected to the terminal 200, for example when the terminal is a portable terminal and has been rested on its base. This is known as off-line, off-line verification.

En figure 3, on a représenté les opérations effectuées par les différents acteurs. Comme déjà évoqué, la transaction inclut une étape d'analyse par le terminal 3000, qui est effectuée sur la base de règles de sécurité définies dans celui-ci, telles que les montants autorisés pour le commerçant, et les règles d'assurance. Figure 3 shows the operations performed by the different actors. As already mentioned, the transaction includes an analysis step by the terminal 3000, which is performed on the basis of security rules defined therein, such as the amounts authorized for the merchant, and the insurance rules.

Cette analyse par le terminal est suivie par la transmission de la commande GENERATE AC 1000, qui inclut le montant de la transaction envisagée et un résultat d'analyse par le terminal. Puis une étape d'analyse par la carte 3100 est menée. Celle-ci prend en compte des informations et des règles de sécurité définies dans sa mémoire, comme un montant maximum de transaction, un plafond de paiement sur une semaine et un historique de paiement. L'analyse par la carte prend aussi en compte le résultat de l'analyse par le terminal qui lui a été transmis précédemment. En particulier, si le terminal a refusé la transaction, la carte refuse à son tour la transaction. Et si le terminal a indiqué qu'il souhaitait une autorisation de la banque, la carte ne peut pas par elle- même approuver la transaction. Un résultat d'analyse 3150 est obtenu à ce stade. Ce résultat d'analyse 3150 est soit une approbation de la transaction par la carte, notée TC (pour « Transaction Certtficate»), ou une décision de demande d'autorisation à la banque, notée ARQC (pour « Autorisation ReQuest Cryptogram »), ou enfin un refus définitif de la transaction, noté AAC (pour « Application Authentification Cryptogram »). Il est procédé à ce moment-là à une étape de génération d'un message signé par la carte 4000, et ce message est transmis au terminal 30 de paiement 200, dans le cadre du message de réponse 1100. This analysis by the terminal is followed by the transmission of the command GENERATE AC 1000, which includes the amount of the transaction envisaged and a result of analysis by the terminal. Then an analysis step by the 3100 card is conducted. It takes into account information and security rules defined in its memory, such as a maximum transaction amount, a payment cap on a week and a payment history. The analysis by the card also takes into account the result of the analysis by the terminal that has been transmitted previously. In particular, if the terminal has refused the transaction, the card in turn refuses the transaction. And if the terminal has indicated that it wants an authorization from the bank, the card can not by itself approve the transaction. An analysis result 3150 is obtained at this stage. This analysis result 3150 is either an approval of the transaction by the card, denoted TC (for "Transaction Certtficate"), or an authorization request decision to the bank, noted ARQC (for "ReQuest Cryptogram Authorization"), or finally a definitive refusal of the transaction, noted AAC (for "Application Authentication Cryptogram"). At this time, a step is taken to generate a message signed by the card 4000, and this message is transmitted to the payment terminal 200, as part of the response message 1100.

Si le résultat d'analyse 3150 est du type TC, il est alors procédé à la transaction, au cours d'une étape de transaction 1600, par la carte de paiement 100 et le terminal de paiement 200. Puis une étape de transmission finale 1700 est effectuée, à destination du serveur de banque 300, qui effectue une étape d'authentification 5000, suivie d'une étape d'information finale de la banque 3300, qui consiste entre autres à la mise à jour de base de données. Si le résultat d'analyse 3150 est du type ARQC, il est procédé à une demande d'autorisation par la banque, via la demande d'autorisation 1200, comprenant les éléments transmis par la carte dans le message de réponse 1100. La banque effectue tout d'abord une étape d'authentification 5000, puis une étape d'analyse des données de la transaction, cette dernière étape étant référencée 3400 sur la figure. Si la banque décide de donner son autorisation à la transaction, le terminal 200 et la carte 100 sont informés par la réponse de la banque 1300 et la deuxième commande GENERATE AC 1400, représentée ensuite en figure 4. Cette deuxième commande 1400 est traitée par la carte qui génère un résultat 3550 de type TC. La réponse de la carte 1500 est transmise au terminal et le terminal et la carte procèdent alors ensemble à la transaction au cours de l'étape de transaction 1600. Le processus se poursuit par une étape de transmission finale 1700, l'authentification 5000 et l'information finale de la banque 3350, qui consiste entre autres à la mise à jour de base de données. Si, au contraire, la banque décide de ne pas donner son autorisation à la transaction, il est, comme précédemment, procédé à la transmission de la réponse de la banque 1300 et l'émission de la deuxième commande GENERATE AC 1400. La carte effectue le traitement 3500 de cette commande, et génère un résultat 3550 de type AAC. Il est procédé ensuite à la transmission au terminal 200 par la carte 100 d'un deuxième message de réponse 1500 comprenant le résultat 3550, à la transmission finale 1700 à la banque et à une étape d'authentification 5000, effectuée par la banque. Le processus se termine avec une étape d'information finale de la banque 3600, similaire à celle évoquée dans les précédents scénarios, c'est-à-dire consistant entre autres à la mise à jour de base de données. Si l'on revient maintenant à la figure 3, dans le cas où le résultat d'analyse 3150 est du type AAC, il est procédé directement, après l'émission du message de réponse 1100, à la transmission finale 1700 en direction de la banque. Celle-ci procède à une étape d'authentification 5000 qui permet d'effectuer l'étape d'information finale de la banque 3700, similaire à celle évoquée pour les précédents scénarios, c'est-à-dire consistant entre autres à la mise à jour de base de données. Dans tous ces scénarios, l'étape d'authentification 5000 permet au serveur 300 de s'assurer que les informations transmises sont intègres et ont bien été produites par une carte émise par la banque. Dans le cas particulier du refus de transaction, la banque est en mesure de tracer le refus, l'intégrité des informations transmises étant certifiée. On va maintenant décrire en figure 5 les détails d'un processus de génération d'un message signé par la carte 4000. Ce processus utilise une clé-maître 4100, contenue dans une mémoire sécurisée de la carte de paiement 100 (ici dans le microcircuit) et qui a été inscrite dans celle-ci par l'autorité de certification, en vue de l'authentification de la carte lors de transactions. Le processus utilise également un compteur de transaction 4200, enregistré dans une mémoire de la carte de paiement 100, qui est incrémenté à chaque transaction ou à chaque tentative de transaction impliquant la carte. Ces deux éléments sont utilisés par un algorithme de chiffrement 4300 (mémorisé dans le microcircuit de la carte), qui dans un mode de réalisation particulier de l'invention est un algorithme triple DES (DES3 - DES signifie « Data Encryption Standard») comme indiqué dans la norme EMV, par exemple dans l'annexe A1.3 de la version EMV 4.2 Book 2. L'algorithme 4300 génère, à l'aide d'au moins ces deux éléments, une clé de session 4400. La clé de session 4400 et des données particulières de la transaction 4500 sont ensuite utilisées par un algorithme de génération de code d'authentification de message 4600 (« MAC Algorithm »), comme indiqué dans la norme EMV, par exemple dans l'annexe A1.2 de la version EMV 4.2 Book 2, pour générer un cryptogramme 4700. L'algorithme 4600 est mémorisé dans le microcircuit de la carte. Les données particulières de transaction 4500 contiennent par exemple le montant de la transaction 4510, la date de la transaction 4520, ainsi que d'autres informations, comme la monnaie utilisée, le numéro de compte, des coordonnées bancaires ou un niveau maximal de transaction autorisé. Le résultat d'analyse 3150 (ou le résultat d'analyse 3550), le cryptogramme 4700, les données de la transaction 4500, ainsi que le compteur de transaction 4200 font alors l'objet d'une concaténation 4800 menant à la génération d'un message signé par la carte 4900. Ce message 4900 comprend un champ résultat 4910 (appelé CID pour « Cryptogram Information Data ») reprenant le résultat d'analyse 3150 (ou le résultat d'analyse 3550), un champ cryptogramme 4920 reprenant le cryptogramme 4700, un champ données 4930 reprenant les données particulières de la transaction 4500 et un champ compteur reprenant la valeur courante du compteur 4200. Conformément à l'invention, le résultat d'analyse 3150 (ou le résultat d'analyse 3550) est utilisé dans le processus de génération d'un message signé par la carte 4000 pour modifier la clé-maître 4100, dans une premier mode de réalisation ou, dans des variantes pour modifier l'algorithme de chiffrement 4300 ou l'algorithme de génération de code d'authentification de message 4600. Dans une variante particulière, la clé-maître 4100 et l'algorithme de chiffrement 4300 sont tous les deux modifiés en fonction du résultat d'analyse 3150 (ou le résultat d'analyse 3550), et dans un mode de réalisation particulier ce sont à la fois la clé-maître 4100, l'algorithme de chiffrement 4300 et l'algorithme de génération de code d'authentification de message 4600 qui sont modifiés. Dans un mode de réalisation particulier, on utilise trois clés maître différentes : une pour le résultat AAC, une autre pour le résultat TC et une dernière pour le résultat ARQC. Le message signé par la carte 4900 fait l'objet d'une transmission au terminal 200 dans le cadre du message de réponse 1100, ou du deuxième message de réponse 1500. Il est ensuite transmis au serveur 300 dans le cadre de la demande d'autorisation 1200 ou de la transmission finale 1700. En figure 6, on a représenté le processus d'authentification 5000 mis en oeuvre par la banque après réception d'un message, comme la demande d'autorisation 1200 ou la transmission finale 1700. If the analysis result 3150 is of the TC type, the transaction is then carried out during a transaction step 1600 by the payment card 100 and the payment terminal 200. Then a final transmission step 1700 is performed, for the bank server 300, which performs an authentication step 5000, followed by a final information step of the bank 3300, which consists inter alia of updating the database. If the analysis result 3150 is of the ARQC type, an authorization request is made by the bank, via the authorization request 1200, comprising the elements transmitted by the card in the response message 1100. The bank performs first of all an authentication step 5000, then a step of analyzing the data of the transaction, this last step being referenced 3400 in the figure. If the bank decides to give its authorization to the transaction, the terminal 200 and the card 100 are informed by the response of the bank 1300 and the second command GENERATE AC 1400, represented subsequently in FIG. 4. This second command 1400 is processed by the This map generates a 3550 result of type TC. The response of the card 1500 is transmitted to the terminal and the terminal and the card then proceed together to the transaction during the transaction step 1600. The process continues with a final transmission step 1700, the authentication 5000 and the 3350 Bank's final information, which includes updating the database. If, on the contrary, the bank decides not to give its authorization to the transaction, it is, as before, proceeded to the transmission of the response of the bank 1300 and the issuance of the second command GENERATE AC 1400. The card performs the 3500 processing of this command, and generates a result 3550 of AAC type. It is then proceeded to the transmission to the terminal 200 by the card 100 of a second response message 1500 comprising the result 3550, the final transmission 1700 to the bank and an authentication step 5000, performed by the bank. The process ends with a final information step of the bank 3600, similar to that evoked in the previous scenarios, that is to say consisting among others in updating the database. Turning now to FIG. 3, in the case where the analysis result 3150 is of the AAC type, it is proceeded directly, after the transmission of the response message 1100, to the final transmission 1700 towards the bank. The latter proceeds to an authentication step 5000 which makes it possible to carry out the final information step of the bank 3700, similar to that evoked for the previous scenarios, that is to say, consisting inter alia in the setting database update. In all these scenarios, the authentication step 5000 allows the server 300 to ensure that the information transmitted is integrity and has been produced by a card issued by the bank. In the particular case of the transaction refusal, the bank is able to trace the refusal, the integrity of the information transmitted being certified. The details of a process for generating a message signed by the card 4000 will now be described in FIG. 5. This process uses a master key 4100, contained in a secure memory of the payment card 100 (here in the microcircuit). ) and which has been registered by the certification authority for authentication of the card during transactions. The process also uses a transaction counter 4200, stored in a memory of the credit card 100, which is incremented with each transaction or with each transaction attempt involving the card. These two elements are used by an encryption algorithm 4300 (stored in the microcircuit of the card), which in a particular embodiment of the invention is a triple DES algorithm (DES3 - DES stands for "Data Encryption Standard") as indicated in the EMV standard, for example, in Appendix A1.3 of EMV 4.2 Book 2. The 4300 algorithm generates, using at least these two elements, a session key 4400. The session key 4400 and particular data of the transaction 4500 are then used by a message authentication code generation algorithm 4600 ("MAC Algorithm"), as indicated in the EMV standard, for example in Appendix A1.2 of the version EMV 4.2 Book 2, to generate a cryptogram 4700. The algorithm 4600 is stored in the microcircuit of the card. The particular transaction data 4500 contains, for example, the amount of the transaction 4510, the date of the transaction 4520, as well as other information, such as the currency used, the account number, bank details or a maximum authorized transaction level. . The analysis result 3150 (or the analysis result 3550), the cryptogram 4700, the transaction data 4500, and the transaction counter 4200 are then concatenated 4800 leading to the generation of a message signed by the card 4900. This message 4900 includes a result field 4910 (called CID for "Cryptogram Information Data") containing the analysis result 3150 (or the analysis result 3550), a cryptogram field 4920 containing the cryptogram 4700, a data field 4930 showing the particular data of the transaction 4500 and a counter field containing the current value of the counter 4200. According to the invention, the analysis result 3150 (or the analysis result 3550) is used in the process of generating a message signed by the card 4000 to modify the master key 4100, in a first embodiment or, in variants for modifying the encryption algorithm 4300 or the algorithm of ge In a particular variant, the master key 4100 and the encryption algorithm 4300 are both modified according to the analysis result 3150 (or the analysis result 3550). and in a particular embodiment, both the master key 4100, the encryption algorithm 4300 and the message authentication code generation algorithm 4600 are modified. In a particular embodiment, three different master keys are used: one for the AAC result, another for the TC result and one for the ARQC result. The message signed by the card 4900 is transmitted to the terminal 200 as part of the response message 1100, or the second response message 1500. It is then transmitted to the server 300 as part of the request for Authorization 1200 or the final transmission 1700. In Figure 6, there is shown the authentication process 5000 implemented by the bank after receiving a message, such as the authorization request 1200 or the final transmission 1700.

Ce processus d'authentification 5000 utilise une clé associée à un client 5100. Cette clé est liée par une correspondance ou est identique à la clé-maître 4100 contenue dans la carte de paiement 100. Elle a été délivrée au serveur de banque 300 par l'autorité de certification, parallèlement à l'inscription de la clé-maître 4100 dans la mémoire de la carte de paiement 100. La clé 5100 est utilisée, en conjonction avec le champ résultat 4910 pour faire générer à un algorithme de chiffrement 5300 une clé intermédiaire 5400. Cette clé intermédiaire 5400 est utilisée, en conjonction avec le champ cryptogramme 4920 pour faire générer à un algorithme de génération de code d'authentification de message 5600 un cryptogramme 5800. Le cryptogramme 5800 est comparé au contenu du champ données 4930, au cours d'une étape de comparaison 5900. Dans le cas où il est constaté que les deux cryptogrammes sont identiques, on considère que la carte 100 est authentifiée et il est procédé soit à l'analyse de la transaction par la banque au cours de l'étape 3400, soit à l'information de la banque au cours des étapes 3300, 3600 ou 3700. Dans le cas où il est constaté que les deux cryptogrammes ne sont pas identiques, le serveur 300 considère que la carte n'est pas authentifiée et met en place la procédure adéquate en cas de carte non authentifiée 3800. De manière conforme à l'invention, la clé associée au client 5100, l'algorithme de chiffrement 5300, ou encore l'algorithme de génération de code d'authentification 5600, ou encore plusieurs de ces moyens de cryptographie sont choisis en fonction du contenu du champ résultat 4910, selon la même règle que celle mise en oeuvre au cours du processus de génération d'un message signé par la carte 4000. Dans un mode de réalisation particulier, on utilise trois clés maître différentes : une pour le résultat AAC, une autre pour le résultat TC et une dernière pour le résultat ARQC. On utilise une règle de choix des moyens cryptographiques similaire à celle mise en oeuvre dans la carte 100 (processus de génération de message signé 4000). Dans une variante, les processus de signature et d'authentification décrits en figures 5 et 6 ne comprennent pas de génération d'un code d'authentification de message, mais lors de la signature on génère un cryptogramme de manière réversible en lieu et place de l'étape 4600, et lors de l'authentification on exécute un algorithme inverse à partir du champ cryptogramme 4920 pour ensuite comparer le résultat obtenu avec la clé intermédiaire 5400. Le processus reprend alors à l'étape 5900. Dans une variante, les processus de signature et d'authentification mis en oeuvre par l'invention comprennent pour moyens cryptographiques des algorithmes de chiffrement/déchiffrement asymétrique à base d'une clé privée/clé publique, des fonctions de hachage (fonction qui présente des ressemblances avec un algorithme de génération de code d'authentification de message), ou des générateurs de nombres pseudoaléatoires. Ces moyens cryptographiques sont choisis en fonction du résultat de l'analyse de l'action à autoriser. L'invention ne se limite pas aux modes de réalisation décrits mais englobe toutes les variantes dans le cadre de la portée des revendications. L'invention s'applique également au paiement par NFC (évoqué en introduction), et dans ce cas, le moyen de paiement peut être incorporé à un terminal mobile, par exemple un téléphone cellulaire, disposant d'une carte SIM (« Subscriber Identification Module »), d'une carte micro-SD (pSD, SD signifiant « Secure Digital») ou d'un microcircuit sécurisé intégré, la carte ou le circuit hébergeant une application bancaire. Les moyens cryptographiques sont mémorisés dans une carte à microcircuit, ou dans un ensemble sécurisé constitué d'un microcircuit et d'une mémoire. This authentication process 5000 uses a key associated with a client 5100. This key is linked by a correspondence or is identical to the master key 4100 contained in the payment card 100. It was delivered to the bank server 300 by the client. the certification authority, in parallel with the registration of the master key 4100 in the memory of the payment card 100. The key 5100 is used, in conjunction with the result field 4910 to generate a keying algorithm 5300 key intermediate 5400. This intermediate key 5400 is used, in conjunction with the cryptogram field 4920 to cause a message authentication code generating algorithm 5600 to generate a cryptogram 5800. The cryptogram 5800 is compared with the contents of the data field 4930, at the During a comparison step 5900. In the case where it is found that the two cryptograms are identical, the card 100 is considered authentic. e and it is proceeded either to the analysis of the transaction by the bank during the step 3400, or to the information of the bank during the steps 3300, 3600 or 3700. In the case where it is found that the two cryptograms are not identical, the server 300 considers that the card is not authenticated and sets up the appropriate procedure in case of unauthenticated card 3800. In accordance with the invention, the key associated with the client 5100, the encryption algorithm 5300, or the authentication code generation algorithm 5600, or several of these cryptographic means are chosen according to the content of the result field 4910, according to the same rule as that implemented in FIG. During the process of generating a message signed by the card 4000. In a particular embodiment, three different master keys are used: one for the AAC result, another for the TC result and one for the ARQ result. vs. A rule of choice of cryptographic means similar to that used in the card 100 (signed message generation process 4000) is used. In a variant, the signature and authentication processes described in FIGS. 5 and 6 do not include generation of a message authentication code, but during the signature a cryptogram is reversibly generated instead of step 4600, and during authentication, an inverse algorithm is executed from the cryptogram field 4920 to compare the result obtained with the intermediate key 5400. The process then resumes at step 5900. In a variant, the processes of signature and authentication implemented by the invention comprise, for cryptographic means, asymmetric encryption / decryption algorithms based on a private key / public key, hashing functions (function which has similarities with a generation algorithm message authentication code), or pseudo-random number generators. These cryptographic means are chosen according to the result of the analysis of the action to be authorized. The invention is not limited to the embodiments described but encompasses all variants within the scope of the claims. The invention also applies to payment by NFC (mentioned in the introduction), and in this case, the payment means can be incorporated into a mobile terminal, for example a cellular phone, having a SIM card ("Subscriber Identification Module "), a micro-SD card (pSD, SD stands for" Secure Digital ") or an integrated secure microcircuit, the card or circuit hosting a banking application. The cryptographic means are stored in a microcircuit card, or in a secure set consisting of a microcircuit and a memory.

L'invention s'applique à d'autres domaines pour lesquels il est nécessaire de signer les données d'une action réalisée au moyen d'un instrument individuel d'exécution d'une action. Par exemple, les domaines des titres de transport électroniques, des documents d'identité électroniques, et plus généralement des dispositifs électroniques permettant des contrôles de sécurité sont des domaines d'application de l'invention. The invention applies to other fields for which it is necessary to sign the data of an action performed by means of an individual instrument for executing an action. For example, the fields of electronic transport tickets, electronic identity documents, and more generally electronic devices for security checks are areas of application of the invention.

Claims

REVENDICATIONS1. A method of response by an individual electronic device (100) to a solicitation, the method comprising receiving a command (1000; 1400) comprising at least one characteristic of an intended action, an analysis (3100) of said intended action, then a signature of said analysis (4000) using cryptographic means (4100, 4300, 4600) and the transmission (1100; 1500) of said signed analysis, characterized in that at least a part of said cryptographic means ( 4100, 4300, 4600) is selected based on a result (3150; 3550) of said analysis.

2. Response method according to the preceding claim, wherein the cryptographic means comprise a cryptographic key (4100), chosen according to the result.

3. Response method according to one of the preceding claims, wherein the cryptographic means comprise an encryption algorithm (4300), chosen according to the result.

The response method according to one of the preceding claims, wherein the cryptographic means comprises a message authentication code generating algorithm (4600), selected according to the result.

The response method according to one of the preceding claims, wherein the result is an acceptance, a refusal, or a request for agreement from a remote third authority, for example a transmitter of the individual electronic device.

6. Response method according to one of the preceding claims, the action envisaged being a transaction.

7. Computer program comprising instructions able to implement, when they are executed by a device comprising a microcontroller and a memory, each of the steps of a response method according to one of the preceding claims.

8. An individual electronic device (100) comprising a microcontroller and a memory, the responding device (3100, 4000), when it is solicited for a planned action, analyzing (3100) the action envisaged, and setting implementing (4000) cryptographic means (4100, 4300, 4600) for signing the generated analysis, characterized in that the device chooses at least a part of said cryptographic means (4100, 4300, 4600) according to a result (3150 ) of the analysis.

An individual electronic device according to the preceding individual electronic device claim, comprising a microcircuit card in a memory of which the cryptographic means are recorded.

An individual electronic device according to one of the preceding individual electronic device claims, in accordance with the EMV standard.

11. Individual electronic device according to one of the preceding individual electronic device claims, comprising an NFC communication interface, and being for example integrated in a mobile telephone terminal.

A method for authenticating information relating to an action by a remote authority (300), the method comprising verifying (5000) using cryptographic means (5100, 5300, 5600), the authenticity of a received signature (1200; 1700) with information relating to an action, characterized in that the cryptographic means (5100, 5300, 5600) are selected according to an analysis result (3150) also received with the information.

13. Computer program comprising instructions able to implement, when executed by device comprising a microprocessor and a memory, each of the steps of a method according to the preceding authentication method claim.

14. A server (300) which, when it receives (1200, 1700) signed action information from terminals verifies (5000) using cryptographic means (5100, 5300, 5600), the authenticity of a signature of the information received with the transaction information, characterized in that the cryptographic means (5100, 5300, 5600) are chosen according to an analysis result (3150) also received with the transaction information.