FR 3030821 A1 20160624 FR 1463169 A 20141222 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne l'authentification des applications 5 exécutables sur un processeur. Elle concerne plus particulièrement un procédé d'authentification d'une application, ainsi qu'un appareil électronique et un programme d'ordinateur associés. L'invention s'applique particulièrement avantageusement dans le cas où 10 le processeur sur lequel s'exécute l'application échange des données avec un module sécurisé. ARR IERE-PLAN TECHNOLOGIQUE Dans les procédés de traitement et d'échanges de données impliquant un processeur, sur lequel s'exécute une application, et un dispositif électronique 15 tiers, il arrive que l'application doive s'authentifier auprès du dispositif électronique tiers, afin de garantir à celui-ci qu'il échange des données avec l'application prévue à cet effet, et non avec un programme malveillant (ou "malware"). Afin de s'authentifier auprès du dispositif électronique tiers, il a été proposé que l'application transmette à celui-ci des données d'authentification (par 20 exemple une signature) préparées au moyen d'une clé secrète (par exemple une clé privée) connue seulement de l'application. Dans cette configuration toutefois, la diffusion d'une telle application dans des environnements non-sécurisés, tels que les appareils électroniques sur lesquels une telle application peut être installée, risque de rendre la clé secrète 25 accessible à des personnes malintentionnées. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé d'authentification d'une application exécutée par un processeur d'un appareil électronique, caractérisé en ce qu'il comprend les étapes suivantes : 30 - dérivation d'une clé cryptographique à partir d'une donnée reçue d'une entité électronique extérieure ; - déchiffrement, au moyen de la clé cryptographique dérivée, d'une clé secrète mémorisée chiffrée ; - émission de données d'authentification préparées au moyen de la clé secrète déchiffrée. La clé secrète peut être ainsi utilisée pour la préparation des données d'authentification après réception des données d'une entité électronique extérieure, mais n'est pas accessible sans ces données et ne pourra donc en revanche pas être utilisée par une personne malintentionnée. Selon des caractéristiques optionnelles et donc non limitatives : - la clé secrète chiffrée est mémorisée dans une mémoire non-volatile réinscriptible ; - la clé secrète déchiffrée est mémorisée dans une mémoire vive ; - le procédé d'authentification comprend des étapes de réception d'un défi et de préparation desdites données d'authentification par application au défi reçu d'un algorithme cryptographique utilisant la clé secrète déchiffrée ; - ladite donnée reçue est préparée par l'entité électronique extérieure sur la base d'une donnée reçue de l'application et d'une clé mémorisée dans l'entité électronique extérieure ; - les données d'authentification sont émises à destination d'un module sécurisé ; - le défi est généré, par exemple par tirage aléatoire, par le module sécurisé et émis par le module sécurisé à destination de l'application ; - l'entité électronique extérieure est le module sécurisé ; - l'entité électronique extérieure est un serveur (et est donc distincte du module sécurisé) ; - la clé secrète est une clé privée ; - le procédé comprend une étape d'émission par le module sécurisé d'un 25 message signé au moyen d'une clé privée mémorisée dans le module sécurisé à destination d'un serveur ; - le processus d'authentification du module sécurisé auprès de l'application utilise une clé publique mémorisée au sein de l'appareil électronique en association avec un code d'authentification de message produit par une 30 autorité extérieure ; - l'appareil électronique est un téléphone mobile ou une tablette numérique ; - l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur ; - le procédé comprend une étape d'émission par l'application d'un message signé au moyen de la clé secrète déchiffrée à destination d'un serveur ; - le procédé comprend une étape de déchiffrement d'une partie d'un code exécutable de l'application au moyen de la clé cryptographique dérivée ; - le module sécurisé est un élément sécurisé. Le procédé d'authentification peut comprendre en outre les étapes suivantes : - vérification, par le module sécurisé et au moyen d'une première clé publique mémorisée dans le module sécurisé, d'une signature annexée à une seconde clé publique associée à ladite clé privée (dans une infrastructure à clé publique ou PKI, pour "Public Key Infrastructure"); - vérification, par le module sécurisé, desdites données d'authentification au moyen de la seconde clé publique. Le procédé d'authentification peut également comprendre un processus d'authentification du module sécurisé auprès de l'application. L'invention propose également un appareil électronique comprenant un processeur et au moins une mémoire mémorisant une application exécutable par le processeur, l'application étant conçue de sorte que le processeur mette en oeuvre un procédé tel que proposé ci-dessus lorsque l'application est exécutée par le processeur. De même, l'invention propose que l'application susmentionnée soit un programme d'ordinateur comprenant des instructions exécutables par un processeur d'un appareil électronique (notamment par le processeur de l'appareil électronique susmentionné) et conçues de sorte que le processeur mette en oeuvre un procédé tel que proposé ci-dessus lorsque ces instructions sont exécutées par le processeur. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente schématiquement les éléments principaux d'un premier exemple de système dans lequel peut être mise en oeuvre l'invention ; - la figure 2 représente les étapes principales d'un premier exemple de procédé d'authentification d'une application ; - la figure 3 représente les étapes principales d'un second exemple de procédé d'authentification d'une application ; - la figure 4 représente les étapes principales d'un troisième exemple de procédé d'authentification d'une application ; - la figure 5 représente schématiquement les éléments principaux d'un second exemple de système dans lequel peut être mise en oeuvre l'invention ; et - la figure 6 représente les étapes principales d'un quatrième exemple de procédé d'authentification d'une application. La figure 1 représente schématiquement les éléments principaux d'un premier exemple de système, ici un appareil électronique, dans lequel peut être mise en oeuvre l'invention. Cet appareil électronique est par exemple un téléphone mobile, une tablette numérique, une montre connectée ou des lunettes connectées. Dans ces derniers cas, l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur (par exemple un bracelet dans le cas d'une montre connectée, ou des branches dans le cas de lunettes connectées). Ces éléments comprennent un processeur 10 (par exemple un microprocesseur), une mémoire non-volatile réinscriptible 12, une mémoire vive 14 et un module sécurisé 20. Ces éléments font ici partie de l'appareil électronique susmentionné. En variante, ces éléments pourraient être répartis dans plusieurs appareils électroniques formant un système, le processeur 10, la mémoire non-volatile 12 et la mémoire vive 14 étant par exemple compris dans un même appareil électronique, tandis que le module sécurisé est compris dans un autre appareil électronique. La mémoire non-volatile réinscriptible 12 mémorise des applications dont l'exécution par le processeur 10 permet la mise en oeuvre de procédés de traitement de données et d'échanges de données, ici notamment avec le module sécurisé 20. La mémoire non-volatile réinscriptible 12 mémorise ainsi notamment une application App qui cherche, lors de son exécution par le processeur 10, à s'authentifier auprès du module sécurisé 20 et met notamment en oeuvre pour ce faire les étapes décrites ci-dessous en référence à la figure 2. La mémoire non-volatile réinscriptible 12 mémorise également des données utilisées lors des procédés de traitement mis en oeuvre par le processeur 10. En particulier, la mémoire non-volatile réinscriptible 12 mémorise les données cryptographiques suivantes, utilisées comme décrit ci-dessous dans le 5 cadre du procédé de la figure 2: - une clé privée App_SK attribuée à l'application App, mémorisée dans la mémoire non-volatile réinscriptible 12 sous forme chiffrée par une clé cryptographique AEK (d'où la notation [App_SeEK adoptée en figure 1) ; - des données de dérivation App_Deriv ; 10 - une clé publique App_PK associée à la clé privée App_SK (dans une infrastructure à clé publique ou PKI, pour "Public Key Infrastructure") et la signature SIG(App_PK,OT_SK) de cette clé publique App_PK. Ces données sont spécifiques à l'application concernée (ici l'application App) et ont été calculées par une autorité extérieure 30, puis associées à 15 l'application App et par exemple inscrites dans la mémoire non-volatile réinscriptible 12 lors de l'installation de l'application App dans cette même mémoire non-volatile réinscriptible 12 (comme schématiquement représenté en pointillés en figure 1). La clé cryptographique AEK (avec laquelle est chiffrée la clé privée 20 App_SK) est obtenue (notamment au préalable, au niveau de l'autorité extérieure 30, en vue du chiffrement de la clé privée App_SK) par application d'une fonction de dérivation F à une clé racine OT_Apps (commune à toutes les applications) et aux données de dérivation App_Deriv susmentionnées (spécifiques à l'application concernée) : AEK = F(OT_Apps,App_Deriv). 25 On remarque qu'une partie du code exécutable (c'est-à-dire des instructions exécutables par le processeur 10) de l'application App peut également être chiffrée au moyen de la clé cryptographique AEK. Un tel chiffrement peut par exemple être réalisé par le fournisseur de l'application. (Une autre partie du code est dans ce cas mémorisée dans la mémoire non-volatile réinscriptible 12 sans 30 chiffrement afin de pouvoir effectuer les étapes décrites ci-dessous, au moins jusqu'au déchiffrement de la partie chiffrée du code.) La signature SIG(App_PK,OT_SK) est quant à elle obtenue (également au niveau de l'autorité extérieure 30) par application à la clé publique App_PK d'un algorithme cryptographique de signature utilisant une clé privée de l'autorité extérieure OT SK (cette clé privée étant utilisée quelle que soit l'application concernée). Au cours des procédés mis en oeuvre par le processeur 10, et notamment le procédé de la figure 2, la mémoire vive 14 peut mémoriser les 5 données manipulées par ces procédés, notamment comme décrit ci-après. Le module sécurisé 20 est par exemple un élément sécurisé, tel qu'un élément sécurisé intégré à l'appareil électronique (ou eSE pour "embedded Secure Element"). En variante, il pourrait s'agir d'une carte à microcircuit, par exemple de type UICC (pour "Universal Integrated Circuit Card') ou eUICC (pour 10 "embedded Universal Integrated Circuit Card"), ou d'une carte de type micro-SD sécurisée. Le module sécurisé 20 comprend un processeur et une mémoire non-volatile réinscriptible. Comme représenté en figure 1, cette mémoire non-volatile réinscriptible mémorise notamment la clé racine OT_Apps déjà mentionnée et la 15 clé publique OT_PK associée à la clé privée OT_SK susmentionnée (dans une infrastructure à clé publique). Ces clés ont par exemple été inscrites dans le module sécurisé lors d'une étape de personnalisation de ce module sécurisé 20 (comme schématiquement représenté en pointillés en figure 1). Selon une possibilité de réalisation, potentiellement utilisable lorsque l'appareil électronique 20 précité comprend des moyens de télécommunication, ces clés pourraient être mises à jour à distance (selon une technique dite OTA pour "Over-The-Air) depuis un serveur de l'autorité extérieure 30. Les procédés mis en oeuvre par le module sécurisé 20 comme décrit ci-dessous résultent de l'exécution, par le processeur du module sécurisé 20, 25 d'instructions de programmes mémorisés dans la mémoire non-volatile réinscriptible du module sécurisé 20, ou d'une autre mémoire du module sécurisé 20. En variante, le module sécurisé 20 pourrait être réalisé sous forme d'un circuit intégré à application spécifique (ou ASIC pour "'Application Specific 30 Integrated Circuit"), programmé pour mettre en oeuvre les procédés décrits ci- dessous. Le processeur 10 est relié au module sécurisé 20, par exemple au moyen d'un bus (ou en variante via une liaison de type IS07816 ou SPI ou HCl/SVVP), et peut ainsi, du fait de l'exécution des instructions des applications mémorisées en mémoire non-volatile 12 ou éventuellement en mémoire vive 14, échanger des données avec le module sécurisé 20. Le processeur 10 et le module sécurisé 20 pourraient en variante échanger des données par l'intermédiaire d'un réseau téléphonique et/ou informatique (par exemple en utilisant des protocoles de type GSM et/ou UMTS et/ou TCP/IP et/ou Bluetooth), notamment dans les cas mentionnés ci-dessus où le processeur 10 et le module sécurisé 20 ne font pas partie du même appareil électronique. La figure 2 représente les étapes principales d'un premier exemple de procédé d'authentification d'une application. Un tel procédé est ici mis en oeuvre dans le système de la figure 1. Comme indiqué ci-dessous, ce procédé comprend des échanges entre le processeur 10 et le module sécurisé 20. Ces échanges peuvent être réalisés directement entre ces éléments, sans mise en place d'un canal sécurisé. Toutefois, selon une variante envisageable, on peut au préalable établir un canal sécurisé entre le processeur 10 et le module sécurisé 20 et réaliser les échanges décrits ci-dessous via ce canal sécurisé, ce qui permet d'empêcher un attaquant passif d'avoir accès (par simple observation) aux données échangées. Pour ce faire, le module sécurisé 20 et le processeur 10 utilisent par exemple un schéma de type Diffie-Hellman, en générant chacun de leur côté une clé éphémère, en signant cette clé éphémère avec leur clé secrète, en vérifiant la signature effectuée par l'autre module et, en cas de vérification, en déduisant de ces éléments un secret commun et des clés de session à utiliser pour chiffrer les échanges ultérieurs. Quoiqu'il en soit, le procédé de la figure 2 débute à l'étape E2 par l'émission par le processeur 10 (du fait de l'exécution de l'application App) de la clé publique App_PK et de la signature SIG(App_PK,OT_SK) associée. Le module sécurisé 20 reçoit la clé publique App_PK et la signature SIG(App_PK,OT_SK) associée à l'étape E4. Le module sécurisé 20 peut ainsi vérifier à l'étape E6 la signature reçue SIG(App_PK,OT_SK) à l'aide de la clé publique OT_PK (associée à la clé privée OT SK et mémorisée dans le module sécurisé comme déjà indiqué), par exemple en appliquant la signature SIG(App_PK,OT_SK) un algorithme cryptographique de vérification de signature utilisant la clé publique OT_PK et en comparant le résultat obtenu à la clé publique App_PK (éventuellement transformée par une fonction de hachage utilisée pour former la signature). Selon une variante envisageable, la signature SIG(App_PK,OT_SK) peut être vérifiée en appliquant, à la clé publique App_PK et à la signature reçue SIG(App_PK,OT_SK), un algorithme cryptographique de vérification de signature utilisant la clé publique OT_ PK et produisant (directement) un résultat positif ou négatif. Si la signature n'est pas correctement vérifiée, le module sécurisé 20 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 10. Si la signature est correctement vérifiée, le procédé de la figure 2 se poursuit à l'étape E8 à laquelle le module sécurisé 20 génère un défi (ou "challenge" selon l'appellation anglo-saxonne) SE_Ch, par exemple par tirage aléatoire. Le module sécurisé 20 émet ensuite à l'étape E10 le défi SE_Ch et la clé racine OT_Apps à destination du processeur 10 sur lequel s'exécute l'application 15 App. Le processeur 10 reçoit le défi SE_Ch et la clé racine OT_Apps à l'étape E12 et met alors en oeuvre les étapes suivantes du fait de l'exécution de l'application App. Le processeur 10 détermine à l'étape E14 la clé cryptographique AEK 20 (déjà mentionnée plus haut) en appliquant la fonction de dérivation F à la clé racine OT_Apps reçue à l'étape E12 et aux données de dérivation App_Deriv mémorisées dans la mémoire non-volatile 12. Le processeur 10 peut alors déchiffrer à l'étape E16 la clé privée App_SK par application à la version chiffrée [App_SeEK (mémorisée dans la 25 mémoire non-volatile 12) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E14. La clé privée App_SK ainsi obtenue (c'est-à-dire déchiffrée) peut être mémorisée dans la mémoire vive 14 jusqu'à la mise en oeuvre de l'étape E18 décrite ci-dessous (puis éventuellement supprimée ensuite). 30 Dans les cas où une partie du code de l'application App est chiffrée au moyen de la clé cryptographique AEK comme décrit ci-dessus, le processeur 10 peut alors également procéder au déchiffrement de la partie chiffrée du code de l'application App. Le processeur 10 génère à l'étape E18 une signature SIG' par application au défi SE_Ch reçu à l'étape E12 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E16). Le processeur 10 envoie la signature SIG' ainsi obtenue au module sécurisé 20 à l'étape E20. Le module sécurisé 20 reçoit la signature SIG' à l'étape E22 et peut ainsi vérifier la signature SIG' à l'étape E24 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E6), par exemple en appliquant à la signature SIG' reçue un algorithme cryptographique de vérification de signature utilisant la clé publique App_PK, puis en comparant le résultat obtenu au défi SE_Ch généré à l'étape E8. Selon une variante envisageable, la signature SIG' peut être vérifiée en appliquant, au défi SE_Ch et à la signature reçue SIG', un algorithme cryptographique de vérification de signature utilisant la clé publique App_PK et produisant (directement) un résultat positif ou négatif. Si la signature SIG' n'est pas correctement vérifiée, le procédé d'authentification a échoué. Si la signature SIG' est correctement vérifiée à l'étape E24, le processeur 10 sur lequel s'exécute l'application App a ainsi démontré qu'il détenait la clé privée App_SK et s'est donc authentifié. La figure 3 représente les étapes principales d'un second exemple de procédé d'authentification d'une application. Ce procédé est mis en oeuvre dans un système du type de celui de la figure 1, dans lequel la mémoire non-volatile réinscriptible 12 mémorise en outre des données de dérivation additionnelles App_AEK_Deriv. Ces données sont également inscrites dans la mémoire non-volatile 12 lors de l'installation de l'application App (préparée par ou en collaboration avec l'autorité extérieure). Par ailleurs, dans ce mode de réalisation, la clé cryptographique AEK utilisée pour le chiffrement de la clé privée App_SK est obtenue en utilisant non seulement les données de dérivation App_Deriv, mais aussi les données de dérivation App_AEK_Deriv, par exemple comme suit : - une clé dérivée OT_App_K est déterminée par application d'une fonction de dérivation G à la clé racine OT_Apps et aux données de dérivation App_Deriv, soit OT_App_K = G(OT_App,App_Deriv) ; - la clé cryptographique AEK est déterminée par application d'une fonction de dérivation F à la clé dérivée OT_App_K et aux données de dérivation additionnelles App_AEK_Deriv, soit AEK = F(OT_App_K,App_AEK_Deriv). Comme pour le procédé de la figure 2, il est envisageable de manière optionnelle d'établir au préalable un canal sécurisé entre le processeur 10 et le module sécurisé 20 et de réaliser alors les échanges décrits ci-dessous via ce canal sécurisé. Le procédé d'authentification de la figure 3 débute à l'étape E30 par l'émission par le processeur 10 (du fait de l'exécution de l'application App) de la clé publique App_PK et de la signature SIG(App_PK,OT_SK) associée, ainsi que des données de dérivation App_Deriv. Le module sécurisé 20 reçoit la clé publique App_PK, la signature SIG(App_PK,OT_SK) associée et les données de dérivation App_Deriv à l'étape E32. Le module sécurisé 20 peut ainsi vérifier à l'étape E34 la signature reçue SIG(App_PK,OT_SK) à l'aide de la clé publique OT_PK, comme expliqué ci- dessus pour l'étape E6 dans le cadre de la figure 2. Si la signature n'est pas correctement vérifiée, le module sécurisé 20 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 10. Si la signature est correctement vérifiée, le procédé de la figure 2 se poursuit à l'étape E36 à laquelle le module sécurisé 20 génère un défi SE_Ch, par exemple par tirage aléatoire. Le module sécurisé 20 détermine alors à l'étape E38 la clé dérivée OT_App_K par application de la fonction de dérivation G à la clé racine OT_Apps (mémorisée comme indiqué plus haut et visible en figure 1 dans le module 25 sécurisé 20) et aux données de dérivation App_Deriv : OT_App_K = G (OT_Apps,App_Deriv). Le module sécurisé 20 émet ensuite à l'étape E40 le défi SE_Ch et la clé dérivée OT_App_K à destination du processeur 10 sur lequel s'exécute l'application App. 30 On remarque que la clé transmise (ici OT_App_K) est ainsi différente selon l'application (ici App) avec laquelle le module sécurisé est en communication (puisque les données de dérivation App_Deriv sont variables selon l'application), ce qui évite d'émettre une clé toujours identique. Le processeur 10 reçoit le défi SE_Ch et la clé dérivée OT_App_K à l'étape E42 et met alors en oeuvre les étapes suivantes du fait de l'exécution de l'application App. Le processeur 10 détermine à l'étape E44 la clé cryptographique AEK en appliquant la fonction de dérivation F à la clé dérivée OT_App_K reçue à l'étape 5 E12 et aux données de dérivation additionnelles App_AEK_Deriv mémorisées comme indiqué plus haut dans la mémoire non-volatile 12. Le procédé se poursuit ensuite de manière identique à ce qui a été décrit ci-dessus en référence à la figure 2, à partir de l'étape E16. La figure 4 représente les étapes principales d'un troisième exemple de 10 procédé d'authentification d'une application. Ce procédé est mis en oeuvre dans un système du type de celui de la figure 1, dans lequel la mémoire non-volatile réinscriptible 12 mémorise en outre des données de dérivation App_AEK_Deriv (comme pour le second exemple de procédé d'authentification décrit ci-dessus en référence à la figure 3) et des 15 données de dérivation App_AIK_Deriv. Ces données sont spécifiques à l'application concernée (ici l'application App) et inscrites dans la mémoire non-volatile 12 lors de l'installation de l'application App (préparée par ou en collaboration avec l'autorité extérieure). Par ailleurs, dans ce mode de réalisation, la clé cryptographique AEK 20 utilisée pour le chiffrement de la clé privée App_SK est obtenue conformément à ce qui a été décrit ci-dessus dans le cadre de la description de la figure 3. Le module sécurisé 20 mémorise en outre une clé privée d'authentification OT_Auth_SK et la mémoire non-volatile 12 mémorise (en association avec l'application App) la clé publique OT_Auth_PK associée à la clé 25 privée d'authentification OT_Auth_SK (dans une infrastructure à clé publique) et un code d'authentification MAC de cette clé publique OT_Auth_PK. Un tel code d'authentification MAC (pour "Message Authentication Code") est produit au préalable par l'autorité extérieure 30 par application à la clé publique OT_Auth_PK d'un algorithme cryptographique de génération de code 30 d'authentification de message utilisant une clé AIK obtenue par dérivation à partir de la clé dérivée OT_App_K et des données de dérivation App_AIK_Deriv, ici en utilisant la fonction de dérivation F déjà mentionnée : AIK = F(OT_App_K,App_AIK_Deriv). Il est également possible d'utiliser la clé AIK afin d'obtenir un code d'authentification de l'application App (qui pourrait alors être mémorisé annexé à l'application App et utilisé pour vérifier l'intégrité de l'application App). Le procédé de la figure 4 débute de manière identique à celui de la figure 3 par les étapes E30 à E44 décrites ci-dessus. Le procédé de la figure 4 se poursuit ensuite à l'étape E46 à laquelle le processeur 10 déchiffre la clé privée App_SK par application à la version chiffrée [App_SeEK (mémorisée dans la mémoire non-volatile 12) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E44. La clé privée App_SK ainsi obtenue est mémorisée dans la mémoire vive 14 au moins jusqu'à la mise en oeuvre de l'étape E48 décrite ci- dessous. Le processeur 10 génère alors à l'étape E48 une signature SIG' par application au défi SE_Ch reçu à l'étape E42 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E46). Le processeur 10 génère un défi App_Ch, par exemple par tirage aléatoire, à l'étape E50. Le processeur 10 envoie la signature SIG' et le défi App_Ch au module sécurisé 20 à l'étape E52. Comme déjà indiqué pour les autres modes de réalisation, les étapes 20 E46 à E52 sont mises en oeuvre du fait de l'exécution par le processeur de l'application App utilisée dans le présent mode de réalisation. Le module sécurisé 20 reçoit la signature SIG' à l'étape E54 et peut ainsi vérifier la signature SIG' à l'étape E56 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E34), par exemple 25 comme décrit ci-dessus à propos de l'étape E24. Si la signature SIG' n'est pas correctement vérifiée, le procédé d'authentification a échoué. Si la signature SIG' est correctement vérifiée à l'étape E56, le processeur 10 sur lequel s'exécute l'application App s'est authentifié. 30 Le procédé décrit ici se poursuit alors en vue de l'authentification du module sécurisé 20 par le processeur 10 sur lequel s'exécute l'application App. Pour ce faire, le module sécurisé 20 génère à l'étape E58 une signature SIG" par application au défi App_Ch reçu à l'étape E54 d'un algorithme cryptographique de signature utilisant la clé privée d'authentification OT_Auth_SK (mémorisée dans le module sécurisé comme indiqué plus haut). Le module sécurisé 20 envoie la signature SIG" ainsi obtenue au processeur 10 à l'étape E60. Le processeur 10 reçoit la signature SIG" à l'étape E62 et met en oeuvre les étapes qui suivent du fait de l'exécution de l'application App utilisée dans ce mode de réalisation. Le processeur 10 détermine à l'étape E64 la clé AIK par dérivation à partir de la clé dérivée OT_App_K (reçue à l'étape E42) et des données de dérivation App_AIK_Deriv (mémorisées dans la mémoire non-volatile 12) en utilisant la fonction de dérivation F : AIK = F(OT_App_K,App_AIK_Deriv). Le processeur 10 peut ainsi vérifier à l'étape E66 que le code d'authentification MAC mémorisé en association avec la clé publique OT_Auth_PK est bien égal au résultat de l'application, à la clé publique OT_Auth_PK mémorisée, de l'algorithme de génération de code d'authentification de message utilisant la clé AIK obtenue à l'étape E64, ce qui permet de s'assurer de l'intégrité de la clé publique OT_Auth_PK mémorisée. Si cette vérification est un échec, le processeur 10 met fin au procédé d'authentification, en envoyant par exemple un message d'erreur au module sécurisé 20. Si la vérification de l'étape E66 est correctement effectuée, le processeur 10 vérifie la signature SIG" à l'étape E68 en utilisant la clé publique OT_Auth_PK, par exemple en appliquant à la signature SIG" reçue un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK, puis en comparant le résultat obtenu au défi App_Ch généré à l'étape E50. Si la signature SIG" n'est pas correctement vérifiée, le procédé d'authentification a échoué. Si la signature SIG" est correctement vérifiée à l'étape E68, le module sécurisé 20 s'est authentifié auprès du processeur 10 (sur lequel s'exécute l'application App). On obtient ainsi une authentification mutuelle du processeur 10 sur lequel s'exécute l'application App et du module sécurisé 20. Dans certains modes de réalisation dans lesquels une partie du code de l'application App est mémorisée chiffrée dans la mémoire non-volatile 12, on peut procéder, après une telle authentification mutuelle, au déchiffrement de cette partie mémorisée chiffrée, au moyen de la clé cryptographique AEK dans l'exemple donnée plus haut. La figure 5 représente schématiquement les éléments principaux d'un second exemple de système dans lequel peut être mise en oeuvre l'invention. Ce système comprend un appareil électronique 100, par exemple un téléphone cellulaire, un serveur de fournisseur d'application 200 et un serveur d'une autorité extérieure 300. L'appareil électronique comprend un processeur 110 (par exemple un microprocesseur), une mémoire non-volatile réinscriptible 112, une mémoire vive 114, un module de communication 116 et un module sécurisé 120. La mémoire non-volatile réinscriptible 112 mémorise des applications dont l'exécution par le processeur 110 permet la mise en oeuvre de procédés de traitement de données et d'échanges de données, ici notamment avec le module sécurisé 120 et le serveur 200. La mémoire non-volatile réinscriptible 12 mémorise ainsi notamment une application App qui cherche, lors de son exécution par le 15 processeur 10, à s'authentifier auprès du module sécurisé 120 et met notamment en oeuvre pour ce faire les étapes décrites ci-dessous en référence à la figure 6. La mémoire non-volatile réinscriptible 112 mémorise également des données utilisées lors des procédés de traitement mis en oeuvre par le processeur 10. 20 En particulier, la mémoire non-volatile réinscriptible 112 mémorise les données cryptographiques suivantes, utilisées comme décrit ci-dessous dans le cadre du procédé de la figure 6: - une clé privée App_SK attribuée à l'application App, mémorisée dans la mémoire non-volatile réinscriptible 112 sous forme chiffrée par une clé 25 cryptographique AEK ; - des données de dérivation App_Deriv, App_AEK_Deriv et App_Al K_Deriv ; - une clé publique App_PK associée à la clé privée App_SK (dans une infrastructure à clé publique) et la signature SIG de cette clé publique App_PK au 30 moyen d'une clé privée d'une autorité extérieure OT_SK ; - une clé publique OT_Auth_PK associée (dans une infrastructure à clé publique) à une clé privée OT_Auth_SK mémorisée dans le module sécurisé 120, comme mentionné plus bas, ainsi qu'un code d'authentification MAC de la clé publique OT_Auth_PK. Mise à part la clé publique OT_Auth_PK (associée au module sécurisé 120), ces données sont spécifiques à l'application concernée (ici l'application App). La paire clé privée App_SK - clé publique App_PK, ainsi que les données de dérivation App_Deriv, App_AEK_Deriv, App_AIK_Deriv, sont préparées et fournies par le fournisseur de l'application App (la signature SIG et la clé publique OT_Auth_PK étant fournies par l'autorité extérieure 300 au fournisseur de l'application App comme schématiquement représenté en pointillés en figure 5). Au préalable (c'est-à-dire avant l'installation de l'application App au sein de l'appareil électronique 100), le fournisseur de l'application calcule : - une clé dérivée Prov_App_K par application d'une fonction de dérivation G à une clé racine Prov_Apps (commune à toutes les applications) et à la donnée de dérivation App_Deriv (spécifique à l'application concernée) : 15 Prov_App_K = G(Prov_Apps,App_Deriv) ; - la clé cryptographique AEK par application d'une fonction de dérivation F à la clé dérivée Prov_App_K et à la donnée de dérivation App_AEK_Deriv (spécifique à l'application concernée) : AEK = F(Prov_App_K,App_AEK_Deriv) ; - une clé AIK par application de la fonction de dérivation F à la clé 20 dérivée Prov_App_K et à la donnée de dérivation App_AIK_Deriv (spécifique à l'application concernée) : AIK = F(Prov_App_K,App_AIK_Deriv). Le fournisseur de l'application peut ainsi chiffrer la clé privée App_SK par application d'une fonction cryptographique de chiffrement utilisant la clé cryptographique AEK. 25 Le fournisseur de l'application obtient par ailleurs de l'autorité extérieure précitée la signature SIG de la clé publique App_PK (la clé publique App_PK étant par exemple transmise à un serveur de l'autorité extérieure, qui calcule la signature SIG au moyen de sa clé privée OT_SK et retourne la signature SIG). Le fournisseur de l'application obtient également de l'autorité extérieure 30 300 (comme schématiquement représenté en pointillés en figure 5) la clé publique OT_Auth_PK (associée à la clé privée OT_Auth_SK mémorisée dans le module sécurisé 120) et peut ainsi générer le code d'authentification MAC en appliquant, à la clé publique OT_Auth_PK, un algorithme de génération de code d'authentification utilisant la clé AIK préalablement calculée comme indiqué ci- dessus. Toutes ces données peuvent ainsi être associées à l'application App par le fournisseur d'application et inscrites dans la mémoire non-volatile réinscriptible 112 lors de l'installation de l'application App dans cette même mémoire non- volatile réinscriptible 12. Au cours des procédés mis en oeuvre par le processeur 110, et notamment le procédé de la figure 6, la mémoire vive 114 peut mémoriser les données manipulées par ces procédés, notamment comme décrit ci-après. Le module sécurisé 120 est du même type que le module sécurisé 20 décrit ci-dessus en référence à la figure 1 et ne sera donc pas décrit à nouveau. Le module sécurisé 120 mémorise, par exemple dans sa mémoire non-volatile réinscriptible, la clé publique OT_PK associée (dans une infrastructure à clé publique) à la clé privée OT_SK de l'autorité extérieure et la clé privée OT_Auth_SK déjà mentionnée, fournies par l'autorité extérieure 300 (comme représenté en pointillés en figure 5). Le processeur 110 est relié au module sécurisé 120 et au module de communication 116, par exemple au moyen d'un bus, et peut ainsi échanger des données avec ces éléments. Le module de communication 116 permet la connexion du processeur 110 à un réseau de télécommunication, comprenant par exemple un réseau de téléphonie mobile (par exemple de type GSM) et un réseau public (tel que le réseau Internet, utilisant par exemple un protocole de type IP), sur lequel est également connecté le serveur du fournisseur d'application 200 et le serveur de l'autorité extérieure 300. Le processeur 110, le serveur du fournisseur d'application 200 et le serveur de l'autorité extérieure 300 peuvent ainsi échanger des données via le module de communication 116, comme schématiquement représenté en figure 5, notamment des données utilisées au cours d'un procédé d'authentification tel que celui présenté ci-dessous en référence à la figure 6. Les messages échangés comme décrits ci-dessous peuvent par exemple être placés au sein de requêtes http ou https ou dans des réponses à de telles requêtes. Comme visible en figure 5, le serveur 200 mémorise la clé racine Prov_Apps déjà mentionnée (générée par le fournisseur d'application et valable pour toutes les applications). La figure 6 représente les étapes principales d'un quatrième exemple de procédé d'authentification d'une application, mise en oeuvre ici dans le cadre du système de la figure 5. En particulier, les étapes de ce procédé mises en oeuvre par le processeur 110 sont effectuées du fait de l'exécution par le processeur 110 de l'application App. Le procédé de la figure 6 débute à l'étape E100, à laquelle le processeur 100 envoie la donnée de dérivation App_Deriv à destination du serveur 200. Le serveur 200 reçoit la donnée de dérivation App_Deriv à l'étape E102 et peut ainsi déterminer à l'étape E108 la clé dérivée Prov_App_K par application 10 de la fonction de dérivation G à la clé racine Prov_Apps (mémorisée dans le serveur 200) et à la donnée de dérivation App_Deriv reçue : Prov_App_K = G(Prov_Apps,App_Deriv). Le serveur 200 envoie la clé dérivée Prov_App_K au processeur 110 à l'étape E106. 15 Le processeur 110 reçoit la clé dérivée Prov_App_K à l'étape E108 et la mémorise (par exemple dans la mémoire vive 114) pour utilisation ultérieure (voir ci-dessous les étapes E122 et E142). Le processeur 110 émet alors à l'étape E110 la clé publique App_PK et la signature SIG associée, à destination du module sécurisé 120. Comme indiqué 20 pour les procédés des figures 2 et 3, il est envisageable de manière optionnelle d'établir au préalable un canal sécurisé entre le processeur 110 et le module sécurisé 120 et de réaliser alors l'émission de l'étape E110 et les échanges décrits ci-dessous via ce canal sécurisé. Le module sécurisé 120 reçoit la clé publique App_PK et la signature 25 SIG à l'étape E112. Le module sécurisé 120 peut ainsi vérifier à l'étape E114 la signature reçue SIG à l'aide de la clé publique OT_PK, comme expliqué ci-dessus pour l'étape E6 dans le cadre de la figure 2. Si la signature n'est pas correctement vérifiée, le module sécurisé 120 30 met fin au processus d'authentification, en renvoyant par exemple un message d'erreur au processeur 110. Si la signature est correctement vérifiée, le procédé de la figure 6 se poursuit à l'étape E116 à laquelle le module sécurisé 120 génère un défi SE_Ch, par exemple par tirage aléatoire. Le module sécurisé 120 peut ainsi émettre le défi SE_Ch à destination du processeur 110 à l'étape E118. Le processeur 110 reçoit le défi SE_Ch à l'étape E120 et détermine à l'étape E122 la clé cryptographique AEK en appliquant la fonction de dérivation F à la clé dérivée Prov_App_K reçue à l'étape E108 et à la donnée de dérivation App_AEK_Deriv mémorisée comme indiqué plus haut dans la mémoire non-volatile 112 : AEK = F(Prov_App_K,App_AEK_Deriv). Le processeur 110 peut ainsi déchiffrer à l'étape E124 la clé privée App_SK par application à la version chiffrée [App_SeEK (mémorisée dans la mémoire non-volatile 112) d'un algorithme cryptographique de déchiffrement utilisant la clé cryptographique AEK déterminée à l'étape E122. La clé privée App_SK ainsi obtenue est mémorisée dans la mémoire vive 114 au moins jusqu'à la mise en oeuvre de l'étape E126 décrite ci-dessous. Le processeur 110 génère alors à l'étape E126 une signature SIG' par application au défi SE_Ch reçu à l'étape E120 d'un algorithme cryptographique de signature utilisant la clé privée App_SK (déchiffrée à l'étape E124). Le processeur 110 génère un défi App_Ch, par exemple par tirage aléatoire, à l'étape E128. Le processeur 110 envoie la signature SIG' et le défi App_Ch au module sécurisé 120 à l'étape E130. Le module sécurisé 120 reçoit la signature SIG' à l'étape E132 et peut ainsi vérifier la signature SIG' à l'étape E134 en utilisant la clé publique App_PK (dont la signature par l'autorité extérieure a été vérifiée à l'étape E114), par exemple comme décrit ci-dessus à propos de l'étape E24. Si la signature SIG' n'est pas correctement vérifiée, le procédé d'authentification a échoué. Le module sécurisé 120 peut alors émettre un message d'erreur à destination du processeur 110. Si la signature SIG' est correctement vérifiée à l'étape E134, le processeur 110 sur lequel s'exécute l'application App s'est authentifié auprès du 30 module sécurisé 120. Le procédé se poursuit alors en vue de l'authentification du module sécurisé 120 par le processeur 110 sur lequel s'exécute l'application App. Pour ce faire, le module sécurisé 120 génère à l'étape E136 une signature SIG" par application au défi App_Ch reçu à l'étape E132 d'un algorithme cryptographique de signature utilisant la clé privée OT_Auth_SK (mémorisée dans le module sécurisé 120 comme indiqué plus haut). Le module sécurisé 120 envoie la signature SIG" ainsi obtenue au processeur 110 à l'étape E138. Le processeur 110 reçoit la signature SIG" à l'étape E140 et détermine à l'étape E142 la clé AIK par dérivation à partir de la clé dérivée Prov_App_K (reçue à l'étape E108) et de la donnée de dérivation App_AIK_Deriv (mémorisées dans la mémoire non-volatile 112) en utilisant la fonction de dérivation F : AIK = F(Prov_App_K,App_AIK_Deriv). Le processeur 10 peut ainsi vérifier à l'étape E144 que le code d'authentification MAC mémorisé en association avec la clé publique OT_Auth_PK est bien égal au résultat de l'application, à la clé publique OT_Auth_PK mémorisée, de l'algorithme de génération de code d'authentification de message utilisant la clé AIK obtenue à l'étape E142, ce qui permet de s'assurer de l'intégrité de la clé publique OT_Auth_PK mémorisée. Si cette vérification est un échec, le processeur 110 met fin au procédé d'authentification, en envoyant par exemple un message d'erreur au module sécurisé 120. Si la vérification de l'étape E144 est correctement effectuée, le processeur 110 vérifie la signature SIG" à l'étape E146 en utilisant la clé publique OT_Auth_PK, par exemple en appliquant à la signature SIG" reçue un algorithme cryptographique de vérification de signature utilisant la clé publique OT_Auth_PK, puis en comparant le résultat obtenu au défi App_Ch généré à l'étape E128. Si la signature SIG" n'est pas correctement vérifiée, le procédé d'authentification a échoué. Si la signature SIG" est correctement vérifiée à l'étape E146, le module sécurisé 120 s'est authentifié auprès du processeur 110 (sur lequel s'exécute l'application App). On obtient ainsi une authentification mutuelle du processeur 110 sur lequel s'exécute l'application App et du module sécurisé 120. Dans certains modes de réalisation dans lesquels une partie du code de l'application App est mémorisée chiffrée dans la mémoire non-volatile 12, on peut procéder, après une telle authentification mutuelle, au déchiffrement de cette partie mémorisée chiffrée (étape E148), au moyen de la clé cryptographique AEK dans l'exemple donnée plus haut. Le processeur 110 peut alors émettre à l'étape E150 un message de confirmation de l'authentification à destination du module sécurisé 120. Le module sécurisé 120 reçoit ce message de confirmation à l'étape E152 et peut alors émettre un message signé, par exemple au moyen de la clé privée OT_Auth_SK, à destination du serveur de l'autorité extérieure 300 (E154), où ce message peut être reçu et sa signature vérifiée au moyen de la clé publique OT_Auth_PK (étape E156). On pourrait prévoir en variante (ou éventuellement en complément de ce qui vient d'être décrit) l'émission par le processeur 110 (du fait de l'exécution de l'application App) d'un message signé (par exemple au moyen de la clé privée App_SK) à destination du serveur 200. REVENDICATIONS1. Procédé d'authentification d'une application (App) exécutée par un processeur (10; 110) d'un appareil électronique (100), caractérisé en ce qu'il comprend les étapes suivantes : - dérivation (E14; E44; E122) d'une clé cryptographique (AEK) à partir d'une donnée (OT_Apps ; OT_App_K ; Prov_App_K) reçue d'une entité électronique extérieure (20; 200) ; - déchiffrement (E16; E46; E124), au moyen de la clé cryptographique dérivée (AEK), d'une clé secrète mémorisée chiffrée ([App_SK]AEK) ; - émission (E20; E52; E140) de données d'authentification (SIG') préparées au moyen de la clé secrète déchiffrée (App_SK). 2. Procédé d'authentification selon la revendication 1, dans lequel la clé 15 secrète chiffrée ([App_SK]AEK) est mémorisée dans une mémoire non-volatile réinscriptible (12; 112) et dans lequel la clé secrète déchiffrée (App_SK) est mémorisée dans une mémoire vive (14; 114). 3. Procédé d'authentification selon la revendication 1 ou 2, comprenant les étapes suivantes : 20 - réception (E12 ; E42; E120) d'un défi (SE_Ch) ; - préparation (E18; E48; E126) desdites données d'authentification (SIG') par application au défi reçu (SE_Ch) d'un algorithme cryptographique utilisant la clé secrète déchiffrée (App_SK). 4. Procédé d'authentification selon l'une des revendications 1 à 3, dans 25 lequel ladite donnée reçue (OT_App_K ; Prov_App_K) est préparée par l'entité électronique extérieure (20; 200) sur la base d'une donnée (App_Deriv) reçue de l'application (App) et d'une clé (OT_Apps ; Prov_Apps) mémorisée dans l'entité électronique extérieure (20; 200). 5. Procédé d'authentification selon l'une des revendications 1 à 4, dans 30 lequel les données d'authentification (SIG') sont émises à destination d'un module sécurisé (20). 6. Procédé d'authentification selon la revendication 5, comprenant une étape d'émission par le module sécurisé (20) d'un message signé au moyen d'une clé privée (OT_Auth_SK) mémorisée dans le module sécurisé (20) à destinationd'un serveur (300). 7. Procédé d'authentification selon la revendication 5 ou 6, dans lequel l'entité électronique extérieure est le module sécurisé (20). 8. Procédé d'authentification selon l'une des revendications 1 à 6, dans lequel l'entité électronique extérieure est un serveur (200). 9. Procédé d'authentification selon l'une des revendications 5 à 8, la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, dans lequel la clé secrète est une clé privée (App_SK), le procédé d'authentification comprenant les étapes suivantes : - vérification (E6 ; E34; E114), par le module sécurisé (20) et au moyen d'une première clé publique (OT_PK) mémorisée dans le module sécurisé (20), d'une signature (SIG) annexée à une seconde clé publique (App_PK) associée à ladite clé privée (App_SK) ; - vérification (E24; E56; E134), par le module sécurisé (20), desdites données d'authentification (SIG') au moyen de la seconde clé publique (App_PK). 10. Procédé d'authentification selon l'une des revendications 5 à 9, la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, comprenant en outre un processus d'authentification (E58, E68; E136; E146) du module sécurisé (20) auprès de l'application (App). 11. Procédé d'authentification selon la revendication 10, dans lequel le processus d'authentification du module sécurisé auprès de l'application utilise une clé publique (OT_Auth_PK) mémorisée au sein de l'appareil électronique en association avec un code d'authentification de message (MAC) produit par une autorité extérieure (30; 300). 12. Procédé d'authentification selon l'une des revendications 5 à 11, la revendication 8 étant prise dans la dépendance de la revendication 5 ou 6, dans lequel le module sécurisé (20) est un élément sécurisé. 13. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique est un téléphone mobile. 14. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique est une tablette numérique. 15. Procédé d'authentification selon l'une des revendications 1 à 12, dans lequel l'appareil électronique comprend un élément de maintien sur une partie du corps de l'utilisateur. 16. Procédé d'authentification selon l'une des revendications 1 à 15, comprenant une étape d'émission par l'application (App) d'un message signé au moyen de la clé secrète déchiffrée (App_SK) à destination d'un serveur (200). 17. Procédé d'authentification selon l'une des revendications 1 à 16, 5 comprenant une étape de déchiffrement d'une partie d'un code exécutable de l'application au moyen de la clé cryptographique dérivée (AEK). 18. Appareil électronique comprenant un processeur (10; 110) et au moins une mémoire (12 ; 112) mémorisant une application (App) exécutable par le processeur (10; 110), l'application (App) étant conçue de sorte que le processeur 10 (10; 110) mette en oeuvre un procédé selon l'une des revendications 1 à 17 lorsque l'application (App) est exécutée par le processeur (10; 110). 19. Programme d'ordinateur (App) comprenant des instructions exécutables par un processeur (10; 110) d'un appareil électronique et conçues de sorte que le processeur (10; 110) mette en oeuvre un procédé selon l'une des 15 revendications 1 à 17 lorsque ces instructions sont exécutées par le processeur (10; 110).