FR 3025341 A1 20160304 FR 1458191 A 20140902 1 DOMAINE DE L'INVENTION La présente invention concerne de façon générale le domaine de la cryptographie, et plus particulièrement celui de la sécurisation de clés de cryptage, utilisées par exemple lors de transactions. La présente invention vise notamment un procédé et un dispositif de traitement cryptographique mettant en oeuvre une sécurisation accrue d'une clé de cryptage. CONTEXTE DE L'INVENTION Dans le domaine des communications numériques, il existe un grand nombre d'applications qui font appel à des services cryptographiques sécurisés. C'est par exemple le cas des transactions informatiques telles que les transactions financières mises en oeuvre par des applications de paiement. De telles applications de paiement, comme par exemple les applications conformes au standard international de sécurité EMV (Europay, Mastercard, Visa), sont classi_quement prévues dans des cartes à puce fortement sécurisées. Ces cartes à puce sont introduites dans un lecteur ou « terminal de paiement » ou POS (pour « Point Of Sale ») aux fins de procéder à la transaction financière. En variante, les puces peuvent être munies de moyens de communication sans fil permettant la transaction financière sans insertion dans un lecteur. Enfin, elles peuvent également être embarquées par un terminal utilisateur, tel un téléphone, opérant comme lecteur de la carte à puce pour la transaction. Ces puces, également dénommés élément sécurisé (SE pour « Secure Element ») ou élément de sécurité matériel (HSE pour « Hardware Security Element »), sont particulièrement bien adaptées à la protection des clés cryptographiques. La majorité des mesures de sécurité visant à protéger ces clés est mise en oeuvre au niveau matériel de la carte. De tels éléments sécurisés ne sont pas toujours disponibles. Par ailleurs, pour des raisons de coût, il peut également être souhaitable de ne pas avoir à diffuser de telles puces à un nombre important d'utilisateurs. Il peut aussi être souhaitable de limiter la dépendance des transactions à la détention physique de telles puces, afin que ces transactions se révèlent être plus souples pour les utilisateurs. Ainsi, il est apparu un intérêt à prévoir des applications de transaction reposant sur des services cryptographiques au sein même de plateformes matérielles dépourvues de mesures sécuritaires, et par conséquent de tels éléments sécurisés. Dans la publication US 2013/054,474, une application de paiement est mise en oeuvre dans un dispositif mobile utilisateur sans toutefois détenir la clé cryptographique nécessaire à la réalisation d'une transaction de paiement. Cette clé est détenue par un élément sécurisé distant auquel un serveur d'authentification et de transaction accède. En pratique, cet élément sécurisé distant utilise la clé cryptographique qu'il détient afin de calculer un cryptogramme attendu pour une transaction donnée et le communique au dispositif mobile. Ainsi ce dernier peut transmettre le cryptogramme au terminal de paiement de sorte que la transaction de paiement soit autorisée. 3025341 2 Toutefois ce mode de fonctionnement repose sur un appel de procédure à distance pour récupérer le cryptogramme attendu, qui peut s'avérer particulièrement coûteux en temps. Dans la publication susvisée en lien avec les figures 15 et 16, une latence de 200 millisecondes est évoquée, ce qui semble toutefois constituer une estimation optimise. Or une latence de cet 5 ordre de grandeur ou plus longue peut s'avérer préjudiciable à la réalisation de transactions car, pour des raisons de sécurité, celles-ci sont généralement configurées pour s'interrompre en cas d'attente trop longue. RESUME DE L'INVENTION 10 L'invention concerne donc un procédé de traitement cryptographique, comprenant, sur un dispositif mobile, type téléphone mobile, carte à puce non sécurisée, etc., une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme, qui inclut par exemple les informations 15 relatives à la transaction, à un serveur distant de transaction. La présente invention vise à résoudre tout ou partie des inconvénients relevés dans les techniques de l'art antérieur. A cet effet, selon l'invention, ladite clé de cryptage a une durée de vie limitée, par exemple pour une transaction ou une session de communication, impliquant de la sorte un 20 renouvellement fréquent de cette clé de cryptage. Une telle clé s'apparente ainsi à une « clé de session » pour sa durée de vie éphémère. En outre, l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée (c'est-à-dire que la durée de vie de la clé a expiré) : 25 recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile, décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et 30 supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. Ainsi la donnée personnelle n'est que temporaire sur le dispositif mobile. Comme dans la publication susmentionnée, le procédé selon l'invention permet de sécuriser l'accès et le stockage des clés de transaction générées alors même que le dispositif 35 mobile est dépourvu de mécanismes de sécurité. En effet, les clés générées à raison de leurs péremptions sont détenues par un serveur distant sécurisé. En outre, la présente invention permet de réduire les risques d'échec d'une transaction en s'affranchissant du calcul du cryptogramme par le serveur distant sécurisé et des échanges d'informations entre le dispositif mobile et ce serveur aux fins de ce calcul, tout en 3025341 3 conservant un fort niveau de sécurité. Ainsi, la latence d'au moins 200 millisecondes évoquée dans la publication susvisée est largement réduite. Cette situation avantageuse et sécurisée est rendue possible par l'invention grâce à la transmission de la nouvelle clé de cryptage à utiliser et à sa protection par des données 5 personnelles temporaires, c'est-à-dire récupérées uniquement pour accéder à cette clé de cryptage. En effet, l'utilisation de ces données personnelles temporaires assure une sécurité forte de la clé de cryptage transmise car elles ne sont pas stockées à demeure sur le dispositif mobile. Corrélativement, l'invention concerne également un dispositif mobile, type téléphone 10 mobile, carte à puce non sécurisée, etc., comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme, qui inclut par exemple les informations relatives à la transaction, à un serveur distant de 15 transaction. Selon l'invention, ladite clé de cryptage a une durée de vie limitée. Selon l'invention toujours, le module d'obtention de la clé de cryptage est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée : recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, 20 obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile, décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite 25 nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur. Le dispositif mobile et le produit programme d'ordinateur selon l'invention présentent 30 des avantages similaires à ceux exposés précédemment en lien avec le procédé. D'autres caractéristiques du procédé et du dispositif mobile selon des modes de réalisation sont décrites dans les revendications dépendantes, et résumées ci-après en termes de procédés. Le procédé de traitement cryptographique peut constituer une partie d'un procédé de 35 communication dont un exemple est décrit en détail par la suite. De même le dispositif mobile fait partie d'un système comme décrit pas la suite. Selon des modes de réalisation, la donnée personnelle est un code PIN saisi par un utilisateur. Cette configuration permet de conserver l'interaction classique de l'utilisateur, sans nécessiter la saisie de nouvelles données aux fins de l'invention. 3025341 4 Selon d'autres modes de réalisation, une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant. Cette configuration améliore la sécurité de la clé de cryptage fournie, de façon encryptée par le serveur sécurisé distant. 5 Selon d'autres modes de réalisation, le procédé comprend la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction. Cette disposition permet à ce dernier serveur de pouvoir valider le cryptogramme reçu du dispositif mobile. Selon d'autres modes de réalisation' ladite clé de cryptage est sélectionnée parmi 10 une liste chaînée ou série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, c'est-à-dire que la génération des clés est récursive. Ladite sélection est en outre réalisée selon l'ordre inverse de génération des clés, signifiant que la dernière clé générée est utilisée en premier, et la première clé générée en dernier. Cela permet un renouvellement sécurisé des clés. 15 Selon encore d'autres modes de réalisation, le cryptogramme comprend des informations relatives à une transaction informatique, par exemple relatives à une transaction financière, telles qu'un montant. Une transaction informatique, telle qu'une réservation, un achat ou un paiement, consiste notamment en la mise en oeuvre d'une suite atomique, cohérente, isolée et durable d'opérations qui font passer une base de données des transactions d'un état 20 A, antérieur à la transaction, à un état B postérieur à celle-ci. Selon encore d'autres modes de réalisation, la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme, c'est-à-dire après un nombre fixé de transactions utilisant cette clé, par exemple à chaque nouvelle transaction informatique. Cette disposition permet de garantir un renouvellement régulier des clés de cryptage. 25 Selon encore d'autres modes de réalisation, le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé symétrique. Cette disposition permet un traitement rapide à la fois du cryptage de cette clé par le serveur distant et du décryptage de celle-ci par le dispositif mobile. Ainsi la latence introduite par les traitements selon l'invention est minimisée. 30 BREVE DESCRIPTION DES FIGURES D'autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels : 35 la figure 1 représente schématiquement une infrastructure dans laquelle des modes de réalisation de la présente invention sont mis en oeuvre ; la figure 2 illustre un exemple d'architecture matérielle pour les équipements représentés sur la figure 1 ; 3025341 5 les figures 3a, 3b et 3c illustrent, sous forme d'ordinogrammes, des étapes générales de procédés pour une mise en oeuvre de l'invention, respectivement au niveau du dispositif mobile, du serveur d'authentification et du serveur sécurisé distant de la figure 1 ; et la figure 4 illustre les échanges de messages entre les équipements de la figure 5 1 lors d'une mise en oeuvre de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION La figure 1 illustre un exemple d'infrastructure dans laquelle la présente invention peut être mise en oeuvre. Cette infrastructure peut être similaire à celle décrite dans la 10 publication US 2013/054,474 susmentionnée. L'infrastructure 1 comporte un dispositif mobile 10, un point de vente POS 12 officiant comme lecteur du dispositif mobile 10, un ou plusieurs réseaux de communication 14, un serveur d'authentification d'utilisateur 16, un serveur de transaction 17 et un serveur sécurisé distant 18. Bien qu'un seul dispositif mobile 10 soit représenté, une pluralité de dispositifs 15 mobiles 10 détenus par une pluralité d'utilisateurs respectifs est largement envisagée pour réaliser de façon concomitante ou non une ou plusieurs transactions nécessitant la mise en oeuvre de l'invention. Le dispositif mobile 10 peut être tout type d'équipement utilisateur doté d'une mémoire et de moyens de traitement, type CPU, pour mémoriser et exécuter une application requérant 20 un service cryptographique sécurisé. Il s'agit par exemple d'une application de paiement nécessitant l'utilisation d'une clé pour chiffrer ou encrypter les informations relatives à la transaction financière. A titre d'exemple, le dispositif mobile peut être un téléphone portable, un module de traitement type carte à puce non sécurisée. 25 Le dispositif mobile 10 comporte notamment des moyens de communication sans fil conforme à la norme ISO/IEC 14443, afin de communiquer avec le lecteur 12. A cette fin, le dispositif mobile peut mettre en oeuvre le protocole NFC. En variante, des moyens de communication par contact type ISO/IEC 7816 ou filaire (USB) peuvent être envisagés. Le dispositif mobile 10 peut également comprendre des moyens de communication 30 avec le serveur d'authentification 16 par l'intermédiaire d'un réseau de communication 14, type réseau étendu tel que le réseau de téléphonie mobile ou le réseau Internet. La figure 2 représente un exemple d'architecture matérielle pour un équipement tel le dispositif mobile 10. L'équipement comprend un bus de communication 2 auquel sont reliées : 35 - une unité de traitement 20 -ou microprocesseur- notée CPU (pour Central Processing Unit); - une ou plusieurs mémoires non volatile 22 par exemple ROM (pour Read Only Memory), EEPROM (pour de Electrically Erasable Read Only Memory) ou encore Flash, stockant par exemple l'application de paiement; 3025341 6 - une mémoire vive 24 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory) ; et - une interface de communication 26 adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de 5 lecture/écriture. Optionnellement, l'équipement peut comprendre une interface d'entrées/sorties I/O (pour Input/Output), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; cette interface I/O permet à un utilisateur d'interagir avec le système au cours de la mise en oeuvre du procédé via une 10 interface graphique, notamment de saisir un code PIN comme décrit par la suite. La mémoire vive 24 comprend des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution d'un programme informatique comprenant des instructions pour la mise en oeuvre d'étapes d'un procédé selon l'invention lors de sa mise en oeuvre. Les codes d'instructions du programme stocké en mémoire non-volatile 15 sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU. Le bus de communication permet la communication et l'interopérabilité entre les différents éléments représentés sur la figure 2. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément de l'équipement représenté, directement ou par l'intermédiaire d'un autre élément de 20 celui-ci. De retour à la figure 1, le point de vente POS 12 peut être tout type de terminal de paiement classique, doté d'un lecteur apte à communiquer avec le dispositif mobile 10. La lecture peut être de type RFID ou selon la norme ISO/IEC 14443, voire avec contact. 25 Le point de vente POS 12 est également doté de moyens de communication sur le réseau 14 afin de communiquer avec le serveur de transaction 17 (qui peut être commun avec le serveur d'authentification 16). Le serveur de transaction 17 est classique. Bien entendu, une pluralité de serveurs peut être prévue pour réaliser l'ensemble des fonctions exposées par la suite. 30 Le terminal de paiement 12 peut avoir l'architecture matérielle représentée sur la figure 2, équipée en outre d'un lecteur comme exposé ci-dessus. Le serveur d'authentification et de transaction 16 est relié au réseau de communication 14 aux fins d'établir une connexion sécurisée avec le dispositif mobile 10 pour la réalisation d'une transaction. En outre, le serveur 16 dispose d'une connexion, soit directe, 35 soit via un réseau étendu tel le réseau 14, au serveur sécurisé distant 18 afin d'obtenir une clé de cryptage à jour comme expliqué par la suite. A titre d'exemple de connexion directe, le serveur sécurisé 18 peut être un serveur web hébergé dans le serveur d'authentification 16. Le serveur 16 peut être conforme à l'architecture matérielle représentée sur la figure 2. 3025341 7 Le serveur sécurisé distant 18 comprend par exemple un module sécurisé SE stockant une liste chaînée de clés de cryptage pour le dispositif mobile 10. En variante, le serveur sécurisé distant 18 est mis en oeuvre dans un tel module sécurisé SE, par exemple un serveur dans une carte à puce. Dans cette variante, la carte à puce peut être installée dans le 5 serveur 16 et communiquer par des unités APDU selon le protocole ISO 7816. Dans la suite de la description on fera référence principalement à un « module sécurisé » 18. En particulier, le module sécurisé distant 18 stocke en mémoire une clé maître MK pour chaque application de transaction (par exemple de paiement) mise en oeuvre par un dispositif mobile 10. La clé maître MK est utilisée comme point de départ d'un processus de 10 génération d'une liste de clés de transaction ou « clés de session », utilisées par les dispositifs mobiles 10 pour crypter les informations de transaction en cryptogramme. Cette génération est également connue sous l'appellation de diversification ou dérivation de clés. La génération de la série de clés est effectuée à l'aide d'une fonction f à sens unique appliquée récursivement à MK puis à chaque clé SKn générée : 15 SK, = f(MK) = f(SK,) Le nombre n d'itérations est prédéfini, par exemple n=1024. Ainsi la liste de clés de cryptage obtenue est chaînée {SKI, SK2, SKn}. En raison de la nature de la fonction f, les clés sont mises à disposition du dispositif 20 mobile 10 dans l'ordre inverse de la liste chaînée, c'est-à-dire dans l'ordre n, n-1, n-2, ..., 2, 1. Ainsi, si une clé SK, est volée, elle ne peut être utile qu'à la détermination des clés d'indice supérieur, c'est-à-dire des clés déjà répudiées. La clé maître MK n'est jamais transmise et peut être réutilisée pour produire une nouvelle liste chaînée, par exemple en utilisant une autre fonction à sens unique (ayant par 25 exemple un paramétrage différent). Dans une variante évitant de stocker la liste chaînée, SK, peut être obtenue directement par une fonction f(SK, i). Afin de garantir une forte sécurité des transactions, chaque clé de cryptage ainsi générée a une durée de vie limitée dans le temps à compter de sa mise en circulation, c'est-à- 30 dire dès lors qu'elle est mise à disposition par le module sécurisé distant. La clé de cryptage qui est en cours d'utilisation est dite « clé courante ». A titre d'exemple, la durée de vie limitée peut être définie par une fréquence de renouvellement de la clé courante. Par exemple, chaque dimanche à minuit la clé courante SK; devient obsolète et est remplacée par la nouvelle clé courante SK;_,. 35 Dans un autre exemple, cette durée de vie limitée peut être définie au regard d'un nombre de transactions utilisant la clé courante. Par exemple, la clé de cryptage peut être renouvelée toutes les k transactions. A titre d'exemple, k=10. Ce mécanisme de regénération régulière de la clé courante de cryptage utilisée pour les transactions permet de réduire les risques associés à la compromission de la clé de 3025341 8 cryptage. En outre, le fait que la clé de cryptage courante soit transmise au dispositif mobile rend possible que le cryptogramme pour la transaction soit calculé par le dispositif mobile directement à partir de cette clé de cryptage désormais détenue localement. Afin de protéger la clé de cryptage courante, l'invention prévoit que le module sécurisé 5 distant communique la nouvelle clé de cryptage sous forme encryptée à l'aide d'une clé formée à partir d'une donnée personnelle fournie par l'utilisateur. Ainsi, le module sécurisé distant 18 comporte également des moyens cryptographiques permettant d'encrypter des données, et notamment d'encrypter les clés SK, à l'aide d'un algorithme cryptographique à clé symétrique, par exemple l'algorithme triple DES 10 (3DES) : enc3des(SK,, Ksym) où enc3des est la fonction d'encryptage basée sur le Triple DES. La clé symétrique Ksym utilisée peut être générée à la volée à partir de la donnée personnelle de l'utilisateur, lorsqu'une nouvelle clé SK, doit être communiquée. La donnée personnelle de l'utilisateur est sauvegardée en mémoire du module sécurisée distant pour être utilisée dans la formation de la clé symétrique. Cette donnée personnelle peut être saisie par 15 l'utilisateur lors d'une procédure d'inscription ou d'installation de l'application de paiement, permettant par exemple d'associer cette donnée personnelle à la clé maître MK correspondant à l'application installée. En variante, les clés SK, sont toutes encryptées à l'avance et stockées comme telles dans le module sécurisé. 20 La donnée personnelle de l'utilisateur est préférentiellement une information que l'utilisateur connaît bien, telle qu'un code PIN. En particulier, il peut s'agir du même code PIN que celui utilisé dans une procédure d'authentification auprès du serveur 16. En variante, il peut s'agir d'un mot de passe, ou d'un mot de passe étendu (« passphrase » selon la terminologie anglo-saxonne). 25 Dans un mode de réalisation, la clé symétrique est la donnée personnelle de l'utilisateur. En variante, la clé symétrique est distincte de la donnée personnelle mais calculée à partir de celle-ci, éventuellement uniquement à partir de celle-ci, par exemple à partir d'une fonction de hachage SHA-256(PIN). Dans un autre mode de réalisation, la clé symétrique est formée à partir de la donnée 30 personnelle de l'utilisateur et d'une donnée commune au dispositif mobile et au module sécurisé distant 18, par exemple un numéro unique d'identification de l'application de paiement considérée. Par exemple, la clé symétrique peut résulter d'un calcul cryptographique sur ces deux données au moins, par exemple AES (donnée commune, PIN) où les données communes sont 35 utilisées comme clé pour crypter la donnée personnelle (vice et versa). Dans une variante, on peut appliquer une fonction de hachage sur la concaténation (« I ») de ces deux données : SHA-256(donnée communeldonnée personnelle). Dans ces modes de réalisation utilisant la donnée commune, la clé symétrique est d'une plus grande longueur et donc offre un encryptage plus robuste. 3025341 9 La figure 3 illustre, sous forme d'ordinogrammes, des étapes générales de procédés au niveau du dispositif mobile (figure 3a), du serveur d'authentification (figure 3b) et du serveur sécurisé distant (figure 3c) pour une mise en oeuvre de l'invention. Ces étapes sont décrites ci-dessous à l'aide d'un exemple de diagramme temporel de séquence représenté sur 5 la figure 4. A l'étape 302, le dispositif mobile 10 est en attente d'une demande de transaction par l'utilisateur, par exemple du lancement d'une application de paiement par l'utilisateur ou en variante d'une indication par l'utilisateur d'un souhait de transaction au sein de cette application. L'ensemble des étapes qui suivent du dispositif mobile 10 peuvent être mises en 10 oeuvre par l'application de transaction elle-même, notamment l'application de paiement susvisée. Lorsqu'une telle demande est reçue, l'utilisateur est invité à saisie un code d'authentification (code PIN ou mot de passe) lors de l'étape 304 permettant au dispositif mobile 10 de réaliser, si le code saisi est bon, une procédure d'authentification (étape 306) 15 auprès du serveur 16. La procédure d'authentification peut mettre en oeuvre un échange de type « challenge/response » (stimulation/réponse) largement connu. A noter que cette connexion avec le serveur d'authentification 16 peut être initiée par l'utilisateur avant de recevoir une demande de transaction (par exemple avant d'exécuter l'application de paiement). 20 Par exemple, l'authentification peut être menée lors du démarrage du dispositif mobile 10 par l'utilisateur (par exemple son téléphone mobile). Dans ce cas, le code d'authentification peut être le code PIN demandé au démarrage du terminal mobile 10. En référence à la figure 3b, le serveur d'authentification 16 est en attente d'une demande d'authentification (test 340). Lorsqu'une telle demande est reçue, il traite la demande 25 de façon classique (étape 342), par exemple en mettant en oeuvre une procédure de type « challenge/response » avec l'émetteur de la demande. Ce traitement de l'étape 342 conduit à l'émission d'un message OK en cas d'authentification réussie ou d'un message NOK en cas d'échec d'authentification. Ces étapes d'authentification sont schématiquement représentées par les flèches 402 30 et 404 sur la figure 4. En cas d'échec d'authentification (test 344), le serveur 16 se remet en attente d'une nouvelle demande d'authentification (étape 340). En cas d'authentification réussie (test 344), le serveur d'authentification 16 vérifie si la clé de cryptage courante SK, pour le dispositif mobile 10 est valide ou périmée (ou obsolète) en 35 se basant sur des règles d'obsolescence (test 346). L'obsolescence de la clé SK, peut résulter d'une durée expirée depuis l'émission de cette clé, d'une date d'expiration ou encore d'un nombre de transactions déjà réalisées à l'aide de cette clé comme décrit précédemment pour la durée de vie des clés. 3025341 10 A noter que le serveur d'authentification dispose en mémoire d'une table mémorisant un état de la clé courante ou des clés courantes associées à chaque dispositif mobile 10. Ainsi à l'aide de la procédure d'authentification identifiant le dispositif mobile, le serveur d'authentification 16 est capable de récupérer, de cette mémoire, la ou les clés courantes. Si 5 nécessaire, le dispositif mobile 10 peut indiquer dans sa demande d'authentification (étape 306) l'application mise en oeuvre, de sorte à permettre au serveur 16 d'identifier la clé de cryptage associée à la transaction souhaitée. Si la clé SK, n'est pas obsolète, le serveur 16 retourne à l'étape 340 en attente d'une nouvelle demande d'authentification. 10 Si la clé SK, s'avère être périmée (ou si aucune clé n'a encore été communiquée), le serveur d'authentification 16 sollicite le module sécurisé 18 pour l'obtention d'une nouvelle clé de transaction. Il peut s'agir d'un appel à une fonction du module sécurisé hébergé sur le module sécurisé 18. C'est l'étape 348 à l'issue de laquelle le serveur 16 obtient cette nouvelle clé, sous forme encryptée comme décrit ci-après. Elle est représentée par les flèches 406 15 (demande d'une nouvelle clé), 408 (encodage de la clé) et 410 (réception de la clé) sur la figure 4. En référence à la figure 3c, le module sécurisé du module sécurisé 18 a été configuré lors d'une étape d'initialisation 360 au cours de laquelle une liste chaînée de clés de cryptage {SKI, SK2, Sl REVENDICATIONS1. Procédé de traitement cryptographique, comprenant, sur un dispositif mobile, une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme à un serveur distant de transaction, caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée : recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile, décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. 2. Procédé selon la revendication 1, dans lequel la donnée personnelle est un code PIN saisi par un utilisateur. 3. Procédé selon la revendication 1 ou 2, dans lequel une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant. 4. Procédé selon l'une des revendications précédentes, comprenant la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction. 5. Procédé selon l'une des revendications précédentes, dans lequel ladite clé de cryptage est sélectionnée parmi une série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, ladite sélection étant réalisée selon l'ordre inverse de génération des clés. 6. Procédé selon l'une des revendications précédentes, dans lequel le cryptogramme comprend des informations relatives à une transaction informatique. 7. Procédé selon l'une des revendications précédentes, dans lequel la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme. 8. Procédé selon l'une des revendications précédentes, dans lequel le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé 35 symétrique. 9. Dispositif mobile comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme à un serveur distant de transaction. 3025341 14 caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et en ce que le module d'obtention de la clé de cryptage mobile est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée : recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, 5 obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile, décrypter la nouvelle clé de cryptage à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. 10 10. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.