FR3025959A1 - Procede de securisation d'une application permettant de realiser des transactions de proximite entre deux terminaux - Google Patents

Abstract

Procédé de sécurisation d'une application permettant de réaliser des transactions de proximité en mode off-line, entre smartphones et terminaux via NFC. Le smartphone est considéré comme non sûr, mais doté d'un élément de sécurité SE réputé sûr. Le nouveau procédé garantit la sécurité des données de la transaction attaquables par d'éventuels malwares présents dans le smartphone. Il est caractérisé en ce que son utilisation pour sécuriser l'application A : • Nécessite une programmation adaptée à A et à l'utilisation de ce procédé, dans le mobile, • Ne nécessite aucune programmation dans le SE qui se borne à fournir un ensemble de services de sécurité préétablis indépendamment des applications supportées • Ne nécessite que peu de ressources au niveau SE, ce qui le rend adapté à une utilisation ouverte, simplifiant grandement les problèmes d'installation de nouvelles applications mobiles émises par un prestataire de service.

Description

Introduction, état de l'art : A la mi-2014, on ne peut que constater l'immense succès du smartphone au prés des populations de la planète, et la multiplication de ses usages. L'utilisation pour des transactions sécurisées se développe à grand pas, notamment avec la technologie NFC (Near Field Communication [1]) qui, pour les transactions de proximité, semble incontournable. Nul doute que le smartphone remplacera à terme la carte à puce, migration d'ailleurs largement facilitée par la compatibilité « carte contactless» - smartphone NFC.

Dans les systèmes actuels de transactions sécurisées avec les Smartphones, l'architecture la plus répandue est appelée SE-centric, où le SE (secure element) du smartphone est vu par le lecteur de cartes sans contact comme une simple carte sans contact, et où tout le process sensible de chaque type de transactions est exécuté par des programmes spécifiques dans le SE. Dans de nombreuses réalisations, le SE n'est autre que la SIM [2] émise par l'opérateur de mobile (MNO). Le SE étant une JAVA-CARD [3], ce choix est parfaitement naturel, mais emmène des difficultés et complexités pour le SE qui contient les programmes (applets) appartenant aux prestataires émetteurs de ces applications. Le SE est donc partagé du point de vue de son utilisation entre différents acteurs (un émetteur du SE, plusieurs prestataires de service), ce qui engendre des contraintes au niveau du SE rendant son architecture et sa gestion assez complexes: importantes capacités de stockage et de calcul, sécurité et isolation inter-applets, procédures d'installation d'applets avec leurs clés, etc. Tout ceci est à considérer dans un environnement multi-MNO et multi-prestataires de services. Chaque prestataire de service doit déployer ses applications sur les smartphones de différents MNO, en s'adaptant aux particularités des SIMs de chaque MNO, ce qui multiplie d'autant la difficulté. Par ailleurs, le niveau de confiance d'un prestataire de service en la sécurité de ses applications smartphones doit être indépendant de l'opérateur de ces smartphones, et chaque applet présente dans un smartphone et sa SIM peut être vue par le prestataire de service comme une menace pour ses propres applets. Ceci exige des procédures d'évaluation sécuritaires complexes, et coûteuses en temps et en argent.

Certains attribuent la lenteur du déploiement du NFC à ces difficultés. Par ailleurs cette complexité peut avoir aussi des implications en terme de performances, aspect critique dans le cas de transactions NFC. La tokenisation est un principe simple poussé originellement il y a une douzaine d'années par l'industrie bancaire pour le e-commerce, et qui réapparaît ces dernières années : le numéro de carte bancaire (PAN) est sensible car encore utilisable seul pour payer sur certains sites de e-commerce ; mais définir un nouveau système de paiement planétaire est une tâche immense, avec des impacts incommensurables sur les serveurs et réseaux de paiement. Dans une approche on-line, on remplace donc le PAN par un « token » PAN' à durée de vie courte, de format identique au PAN, obtenu par l'utilisateur de façon sûre auprés d'un serveur spécialisé, et reconverti en PAN lors du « clearing » dans la banque émetteur ; les réseaux monétiques ne sont pas impactés. EMVco a publié une spécification [5] décrivant différents usages de ce concept, notamment le paiement NFC, et on peut dire que HCE et Tokenisation se marient bien, puisque ce dernier peut être vu comme un procédé sécuritaire pour HCE. Ce procédé se généralise d'ailleurs à toute donnée (clés, identifiants) à usage limité ( nombre, dates, pour des raisons de sécurité) dans les architectures où le contrôle des transactions est on-line. Fin 2013 est apparue l'approche HCE (Host Card Emulation) [4] disponible dans l'OS 50 ANDROID 4.4 installé sur des tablettes et Smartphones récents. Grâce à HCE, le 3025959 - 2 - smartphone peut émuler une carte sans contact avec une applet Android, et sans recours au SE. Google a d'ailleurs choisi cette approche dans son service Google-Wallet en lieu et place de l'approche SE-Centric. Il est clair que HCE ne peut satisfaire à certaines contraintes de sécurité imposées par exemple par les Banques Françaises et la Banque de 5 France : le niveau de confiance EAL4+ [7] ne peut être atteint qu'avec un SE physique. En terme d'approche sécuritaire pour terminaux grand public, on peut aussi mentionner le Trusted Computing Group [6] et son SE appelé TPM, chargé de contrôler la séquence de « boot » d'un terminal pour aboutir à une configuration logicielle de confiance.

10 Description générale 15 L'invention a pour objet de définir une architecture de sécurité pour les applications sécuritairement sensibles émises par un prestataire de service, permettant de réaliser des transactions de tous ordres entre un utilisateur muni de son terminal personnel smartphone (ou tablette, ou objet communicant quelconque) et ce prestataire de service par l'intermédiaire d'un terminal d'acceptation (ou serveur d'acceptation) . Dans la suite, nous 20 appelons SE un élément réputé sûr car non attaquable par un malware, et qui peut se présenter sous différentes formes : SIM, carte SD-secure, SE « erabedded » donc intégré au hardware du smartphone, etc. Le dit procédé étant caractérisé en ce que 25 * Il est basé sur un élément de sécurité hardware SE * Il offre des qualités en termes de sécurité et performances équivalentes à celles du SE-centric, * Pour un ensemble d'applications données, il permet l'utilisation de SE beaucoup plus simples et donc moins coûteux que dans l'architecture SE-centric, suivant des 30 modes d'utilisation eux aussi simplifiés : en effet Au lieu de procédés permettant de garantir la sécurité et l'isolation des applications, basés sur ^ Une unité d'exécution de programmes écrits dans un langage particulier (JAVA par exemple) 35 ^ des mécanismes de gestion des données de ces programmes ^ des règles d'accès et de partage de ces données il repose sur deux fonctions simples (scellement & signature, et réinitialisation, détaillées dans la suite) dont la bonne réalisation et la bonne utilisation permettent de garantir l'exécution d'applications transactionnelles 40 et l'intégrité de leurs données. * De par ses caractéristiques, il peut optiormellement être de nature ouverte, donc sans relation de dépendance entre prestataire de service et émetteur du SE (MNO par exemple).

45 3025959 3 Description détaillée : L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif 5 de l'invention. Figure 1 : le type d'applications considérées Figure 2 : le modèle de transaction Figure 3 : l'architecture générale prise en compte Figure 4 : le principe de la solution de l'invention 10 Figure 5 : la réalisation Figure 6 : la fonction réinitialisation Figure 7 : le fonctionnement C2C Type d'applications considéré L'invention s'adresse à un type d'applications, représentables par un automate d'état (figure 1) ; l'état est ici le reflet d'un droit de l'utilisateur spécifique à l'application considérée, et la transaction modifie tout ou partie de ce droit. Par exemple pour les applications typiques ci-dessous, l'état contiendrait au moins les données : Pme : porte monnaie électronique balance Emv : paiement cartes : pointeur vers historique des transactions montant autorisé avant autorisation Couponing : coupons consommés D'une façon générale, l'état apparaît comme la valeur d'un ensemble de variables E={a,b,...,f} et une transaction T provoque une transition à de nouvelles valeurs } où les nouvelles valeurs ne dépendent que des anciennes valeurs et des 25 paramètres de la transaction T. Notons que certaines applications ne sont pas de ce type : c'est le cas par exemple d'applications d'identité numérique dont le but est de répondre à une question du type ensemble de prédicats sur tel et tel attribut, la réponse pouvant être un booléen avec signature pour authentifier cette réponse . Exemple : avez-vous plus de 18 ans et moins de 30 25 ans, et êtes vous étudiant ; la réponse peut être OUI ou NON. La figure 1 représente la transition état En à état En+1, suite à la transaction Tn. Sn est une donnée cryptographique garantissant l'intégrité de la séquence d'états E1,E2,...,En,En+1. Par exemple il doit être impossible pour un malware dans le smartphone de modifier E1,E2,E3 en El ,E2, ou en El ,E2,E'3,E'4 (E'3 et E'4 états créés par le malware) sans que 35 ceci soit détectable par le terminal d'acceptation impliqué dans la transaction. Modèle de transactions La figure 2 représente l'architecture objet de l'invention qui supporte évidemment plusieurs 40 applications (1) telles que A, A' ...émises par différentes prestataires de services PS-A, PS- A' . Les smartphones et les terminaux d'acceptation peuvent être utilisés pour plusieurs applications, et dans les figures les blocs fonctionnels spécifiques d'une application sont nommés avec un suffixe « -A » alors que les blocs fonctionnels génériques, indépendants des applications, n'ont pas de suffixe. 15 20 3025959 - 4 - Dans ce document, nous ne décrirons que les blocs fonctionnels génériques, et les liaisons entre blocs génériques et blocs spécifiques aux applications, puisque le but de l'invention est de décrire une architecture supportant différentes applications et indépendante de ces applications pourvu qu'elles soient du type décrit figure 1.

5 Les transactions pour une application, A par exemple, s'effectuent entre un smartphone (5) et un terminal d'acceptation (3) ou serveur d'acceptation (4), selon l'architecture de la figure 2 : le smartphone effectue une transaction de proximité avec le terminal d'acceptation (3) ou une transaction distante avec serveur d'acceptation (4). TM-A (31) (resp SM-A (41)) représentent les données et programmes dans le terminal 10 d'acceptation (resp le serveur d'acceptation) traitant les transactions de l'application A Dans le smartphone, P-A (52) est le programme de l'application A dont la sécurité se base sur les fonctions de sécurité GSF (55) du SE (51) et sont indépendantes de A. Mais ces fonctions utilisent des paramètres spécifiques à l'application A, stockés dans la zone ASP-A (53). Un fichier LOG-A (54) contient la séquence d'états El,E2,...,En+1.

15 Plusieurs applications A, A' (1) dans le Smartphone (5) peuvent être réalisées selon ce modèle:, formant dans le smartphone l'ensemble AS (appli store) (50). Architecture générale 20 L'architecture générale de la figure 3 fait apparaître le rôle du PS-A ou PS-A' : prestataires de service (2) responsables de la diffusion des applications A,A'.. dans différents terminaux d'acceptation (3) ou serveur d'acceptations (4), et smartphones (5). Le rôle des PS (2) est aussi dans la collecte (23) des informations des terminaux ou serveur d'acceptations, suite aux transactions réalisées avec les smartphones (5) et également les mises à jour des 25 paramètres des applications (1) dans les smartphones (5) par des messages (20), notamment la purge de la séquence d'état pour repartir sur un nouvel état El. Il est à noter que la séquence d'états n'est pas limitée en longueur, mais en pratique, du fait de la connectivité des smartphones, elle peut être de longueur très limitée, et son stockage et transfert ne posent pas de problèmes dans nos hypothèses.

30 Principe de la solution 35 La Figure 4 illustre le principe de la solution garantissant l'intégrité des états. Pour simplifier les notations, on note ici Etats En et En+1, E et E' * transaction Tn : T * Donnée ou preuve Sn : S 40 La transaction représentée correspond à l'application A, et donc l'ensemble des fonctions TM-A (31) dans le terminal d'acceptation est concerné par cette transaction : Le terminal d'acceptation avec sa fonction initialisation de transactions (32) envoie une demande pour une transaction T avec le smartphone (5) ; les paramètres de la transaction dépendent de l'application considérée, et ils doivent contenir des 45 informations utiles pour le dénouement de la transaction par le prestataire PS-A (2) telles que l'identité du terminal d'acceptation, et les caractéristiques de la transaction. Dans ce smartphone, le contenu courant E des variables d'état (ou plutôt leur condensé ) est conservé dans le SE (51) dans ASP-A (53) 3025959 - 5 - - Ce contenu est mis à jour dans le smartphone par le programme P-A (52) suivant les paramètres de la transaction T: E devient E', puis E' est communiqué au SE (51) - Le SE fournit une preuve cryptographique S de E et E' à P-A (52), qui la renvoie au terminal d'acceptation (3), et mémorise E' qui devient l'état courant dans ASP-A, à la 5 place de E. L'atomicité de cet ensemble d'opérations doit être assuré, ce qui est une propriété facile à obtenir dans un SE. La preuve est détaillée plus bas. - P-A enregistre E' et S dans un fichier LOG (54) et renvoie la preuve cryptographique et le fichier LOG au terminal d'acceptation (3). - La fonction traitement (33) du terminal d'acceptation qui a reçu les données de la 10 transaction T directement de (32) et le LOG venant du smartphone (5) réalise les actions suivantes : * Vérification du LOG et de la preuve S * Vérification de la cohérence entre les paramètres de la transaction T et la variation de E à E' : A(E,E')= paramètres transaction T . Cette vérification est totalement 15 dépendante de l'application considérée. * Mémorisation de la transition E-E' et sa preuve S dans un fichier de collecte (35), qui permettra après collecte par la fonction (36) de prouver au PS (2) l'authenticité de la transaction T. Il est à noter qu'un malware dans le terminal d'acceptation ne peut modifier ces éléments mémorisés, afin, par exemple, d'apporter un gain à 20 l'exploitant du terminal d'acceptation : En effet, le preuve S dépend de E et E' et modifier E' nécessiterait un changement de S, que seul le SE (51) peut calculer . Ce traitement (33) peut être fait en local, dans le terminal d'acceptation lui-même, ou déporté dans un serveur d'acceptation distant. Dans le cas local, le procédé objet de 25 l'invention rentre dans la catégorie des systèmes de transactions off-line, dont le fonctionnement est plus rapide et moins coûteux (pas de délais ni de coûts de transmission) que pour un système on-line. Cependant, en pratique, la vérification de la preuve cryptographique nécessite dans le cas off-line l'utilisation de cryptographie asymétrique, afin de ne pas avoir de secrets sensibles dans un terminal.

30 Dans le cas déporté dans un serveur d'acceptation distant, on est dans le cas d'un système on-line. Ce cas peut convenir avec n'importe quel type de cryptographie, symétrique ou asymétrique. La description ci-dessus se transpose aisément au cas des transactions entre un smartphone (5) et un serveur d'acceptation (4) 35 Réalisation La réalisation de cette solution est représentée par la figure 5 qui détaille la figure 4.

40 La transaction T est accompagnée d'un aléa x généré par la fonction TM-A (31). L'aléa classiquement sert à éviter les rejeux. Ce nombre x peut par exemple être constitué d'un nombre aléatoire, d'un horodatage, et/ou d'un compteur, afin d'éviter la duplication de transactions dans le fichier de collecte. Afin de diminuer le volume des LOGs et la charge de contrôle d'intégrité de ces LOGs, on 45 fait dépendre le condensé de l'état E des valeurs des variables de E mais aussi des états antérieurs à E ; de cette façon le contrôle d'intégrité du LOG ne nécessitera qu'une seule vérification de signature. En effet, lors d'une transition de E à E', P-A (52) calcule e'-h(E'), où h est une fonction de hashing (ou calcule de condensé) telle que par exemple SHA-1. PA (52) envoie e' avec l'aléa x à la fonction GSF (55) qui calcule u'=h(u,e') , où u est 3025959 - 6 - l'ancienne valeur de u, mémorisée par ASP-A (53) lors de la transaction précédente; u' dépend donc non seulement du dernier état E' mais de tous les états antérieurs. La preuve S est calculée par la fonction GSF (55) grâce à une fonction de signature cryptographique, dont la nature dépend de A : S=(x,Sig(u',x) ). Enfin GSF met à jour ASP-A (53) en 5 remplaçant u par u'. En notant E' et S resp En+l et Sn, le LOG (54) contient après la transaction : El, E2,....., En ,En+1, Sn 10 La vérification d'intégrité du LOG se fait par: u'=0 Pour i variant de 1 à n {Vérification que la transition (Ei,Ei+1) est cohérente avec l'application Al*} 15 Pour i variant de 1 à n+1 {ei=h(Ei) ; u=u'; u'=-1-1(u, e;) } Vérification de Sn avec u',x * cette vérification est spécifique à l'application A ; par exenye, pour une application de comptage de points, la variable compteur doit toujours décroître 20 Cette vérification peut être partielle : par exemple, i peut varier de p à n, p étant un entier entre 1 et n. Il suffit de commencer par la valeur initiale de u pour i=p ; un LOG partiel sera donc constitué dans ce cas par : Valeur initiale de u, Ep,....En,En+1, Sn. Il est à noter que la valeur initiale n'a pas à être recalculée si elle est préalablement mémorisée par P-A : en 25 effet les propriétés d'irréversibilité des fonctions de hashing empêchent un malware de modifier ce LOG partiel à sa convenance. Il est clair que ce principe de calcul et de vérification du LOG garantit son intégrité : Par exemple modifier E1,E2,E3, S2 et E1,E2,E'3,E'4,S'4 où E'3, E'4 et S'4 seraient 30 « inventés » par un malware est impossible : la vérification de S'4 ne peut être positive puisque à partir de la deuxième itération, la valeur de u' diffère pour la suite modifiée. Ce principe peut toutefois être adapté aux caractéristiques applicatives de chaque application : dans certains cas, il peut ne pas être utile de communiquer l'intégralité du LOG au terminal d'acceptation, ce qui permet de limiter la quantité de données échangées lors de 35 la transaction, donc sa rapidité. P-A renvoie le LOG ( total ou partiel, selon les besoins de l'application A) et S au terminal d'acceptation (3) et sa fonction contrôle (34) de la fonction traitement (33) du bloc fonctionnel correspondant à l'application A TM-A (31). La fonction contrôle (34) du terminal d'acceptation réalise les étapes suivantes : 40 a. Vérification intégrité du LOG (total ou partiel) tel que ci-dessus ; b. Vérification que E' est cohérent avec E et les paramètres de la transaction T reçus directement de (32) c. calculer les hashs e et e' en fonction de E et E' d. vérifie avec u calculé en a/ et l'aléa x reçu directement de (32) que le signature est 45 correcte. Cette vérification dépend de la nature de la fonction de signature choisie par 1 cette vérification est spécifique à l'application A ; par exemple, pour une application de comptage de points, la variable compteur doit toujours décroître 3025959 - 7 - l'application A ; si « ver » la fonction de vérification de la signature sig, il suffira de tester que ver(S)=(u',x) e. Rajouter T,E,E', u', x, sig dans le fichier de collecte (35) 5 Cette architecture résiste à toutes les attaques possibles dans le smartphone. * Si P-A (52) dont le fonctionnement serait altéré par un malware n'exécute pas correctement la transaction T, et obtient E" au lieu de E', la vérification b/ sera négative . * Si un malware dans le smartphone modifie le LOG, la vérification d'intégrité du 10 LOG en a/ sera négative. * Un malware ne peut se substituer au SE grâce à la vérification d/, car la fonction de signature et ses clés sont spécifiques à l'application A, et seul le SE peut les connaître. Il est à noter qu'un malware dans le terminal d'acceptation (3) ne peut modifier les éléments 15 T,E,E', u, x, sig mémorisés si, lors de la collecte (23) le prestataire PS-A ( 2) fait les vérifications décrites ci-dessus en c/ Réinitialisation du LOG 20 Le LOG d'une application A dans le smartphone contient un historique de l'activité transactionnelle de l'utilisateur de ce smartphone pour cette application, et l'état courant les droits qui lui restent suite aux transactions réalisées. Ces droits doivent pouvoir être réinitialisés par le PS-A. La décision de ré-initialisation est totalement liée à la nature de l'application.

25 Citons par exemple : - une demande de l'utilisateur (rechargement PME) ré-initialisation périodique (paiement EMV, si le rating de l'utilisateur reste positif un évènement tel que l'obtention d'un coupon par l'utilisateur Cette opération de ré-initialisation est sécuritairement sensible et ne doit pouvoir être faite 30 que par le PS-A (2) pour un utilisateur donné : Figure 6 Cette opération se traduit par une mise à jour dans le SE des données spécifique de l'application A, ASP-A (53) et se fait par l'application P-A sous contrôle d'un secret du SE connu seulement du PS-A qui a acquis ce droit après création de l'ASP-A dans le SE : clé 35 secrète kAti partagée entre prestataire de service PS-A et les SE d'identité j Le Prestataire PS-A envoie au smartphone une commande (20) de ré-initialisation protégée par cette clé. P-A efface le contenu du fichier LOG-A (54) et transmet la commande au SE (5) à la fonction GSF (55). La commande (20) contient E , u et un authentifiant calculé sur les données de la commande, utilisant la clé partagée kA_i 40 GSF vérifie l'authentifiant, avec cette clé et si il est correct, mémorise u dans ASP-A (53) P-A mémorise E, et efface et initialise le LOG (54) avec E.

45 Fonctionnement C2C Certaines applications, par exemple A, peuvent permettre des transactions entre 2 smartphones, en proximité (beam NFC par ex) ou à distance (WIFI, Bluetooth, GSM) : par 3025959 - 8 - ex un paiement par un utilisateur U avec son smartphone M d'un autre utilisateur U' avec son smartphone M'. L'architecture et les fonctionnalités objet de l'invention s'adaptent bien à ce cas. Un bloc fonctionnel TM-A (31) peut en effet être intégré dans le smartphone (5) qui devient 5 terminal d'acceptation (ou serveur d'acceptation) dans une transaction avec un autre smartphone M'. L'enregistrement des transactions de M avec d'autres smartphones se fait grâce au fichier de collecte (35), et en temps réel ou différé, le prestataire (2) lit ce fichier par la fonction collecte (23) et met à jour en conséquence l'état dans le smartphone M (5) et le SE (51) par 10 la fonction ré-initialisation (20). Accès aux fonctions du SE Il est à noter que dans l'architecture objet de l'invention, le niveau de ressources 15 spécifiques à chaque application A est faible : * un condensé (« u ») 16 octets - la fonction « Sig » de la figure (5) ou (6), choisie pour l'application A parmi celles supportées par GSF(55) :1 octet optionnellement une clé de signature pour la fonction « Sig »3 20 - la clé partagée kA_, 16 octets. - Le mot de passe W conditionnant l'accès de P-A (52) au SE lors des transactions de l'application A : 8 octets Il est à noter que ces données peuvent résider dans le SE, mais qu'une autre solution est de 25 les stocker en dehors du SE sous une forme rendant leur attaque impossible : le bloc (noté BASP-A dans le tableau ci-dessous) contenant ces données serait par exemple chiffré par une clé de stockage ks connue uniquement du SE, et créée lors de la création pour l'application A de ASP-A. - Avant toute utilisation, il faut donc que le smartphone demande au SE une ouverture 30 de ASP-A, dont les paramètres sont W et BASP-A. Le SE déchiffre BASP-A et initialise ASP-A. * Après utilisation, le smartphone demande au SE une fermeture de ASP-A, dont le paramètre est W ; le SE chiffre ASP-A avec ks et renvoie BASP-A . Un procédé « anti-retour » doit être implémenté pour éviter qu'un malware ne revienne à 35 une ancienne version de ASP-A : il peut se baser sur un compteur (co dans le tableau ci-dessous) monotone. Un SE classique de l'état de l'art peut donc contenir plusieurs dizaines d'applications. Une application dans le smartphone interagira avec le SE dans deux cas bien différents : 40 - création : création de ASP-A : c'est la cas d'une nouvelle application sensible chargée dans le smartphone. Cette création doit permettre de définir kA_, et optionnellement la clé et l'algorithme de signature désiré par A. Aucun détail n'est décrit à ce niveau, car des solutions apportant un bon niveau de sécurité et d'isolation entre les différents acteurs sont décrites dans la norme GP [8]. 45 - utilisation : utilisation des fonctions du GSF (55) décrites précédemment. 3 une même clé peut être utilisée par différentes applications si la différenciation se fait par les certificats 3025959 - 9 - Contrôle d'accès : Il s'agit de définir les programmes dans le smartphone qui ont le droit d'accéder aux fonctions du SE décrites précédemment. 5 * création : deux scénarios sont possibles : o libre : le faible niveau de ressources requis milite plutôt dans ce sens, notamment si le SE est intégré au smartphone. o Contrôlée : l'émetteur du SE (par exemple l'opérateur de smartphone dans le cas où le SE est une SIM) souhaite (comme c'est le cas actuellement dans le 10 contexte SIM-centric, pour les raisons expliquées en introduction) conditionner cette création à un accord commercial avec le prestataire de service. Aucun détail n'est décrit à ce niveau, car des solutions apportant un bon niveau de sécurité et d'isolation entre les différents acteurs sont décrites dans la norme GP [8] 15 Utilisations: dans ce cas un contrôle d'accès a intérêt à être mis en place : en effet même si un malware ne peut que réaliser une attaque de type déni de service (consommer des droits de l'utilisateur de façon indue...sans en tirer profit) il est préférable, comme dans les réalisations actuelles de mettre en place un contrôle de type mot de passe (nommé W dans la suite): certificat (ou partie ou hash du 20 certificat) correspondant à l'application P-A, tel que géré par l'OS du smartphone ( iOS ou ANDROID) qui vérifie grâce à ce certificat, lors de l'installation d'une application, une signature de cette application dépendant de son code, et de son auteur (en fait de la machine sur laquelle le logiciel outil de développement d'application a été installé) de sorte que la compromission de ce mot de passe ne 25 rend pas possible une attaque : il faudrait en effet que l'application malware ait le même certificat que l'application attaquée A, ce qui est difficile en pratique car l'auteur est forcément différent. Choix de la fonction de signature « Sig » de la figures 5 : l'état de l'art permet le choix 30 entre différents algorithmes de la librairie cryptographique du GSF (55) : à titre d'exemple, on peut citer AES, RSA, Schnorr sur Zn ou sur courbes elliptiques, et des fonctions de signature aveugle ou de groupe. Notons que le certificat, spécifique de l'application A, nécessaire à la vérification par un terminal d'acceptation et qui accompagne la signature (sauf dans le premier cas) peut être stocké dans la smartphone, 35 en dehors du SE. Exemple de commandes pour le cas création libre Extérieur Pa, Sa SE Pse,Sse bi clé inscrite par le fabricant du SE Création ASP-A W est le mot de passe d'accès PS-A envoie cette commande via P-A pour : * Définir W * obtenir une clé k pour initialiser de façon sécurisée le contenu de ASP-A Calcule W'=Pse(W) W', Pa I> Choix clé k, mémorise k k'=Pa(k) ; k' Caclule Salk')=k 3025959 -10- Mémorise k Initialisation de ASP-A PS-A prépare le contenu C : choix algorithme de signature, . co . bi-clé signature, . clé k, . clé kA_, C'=chiffré de C par k ; W,C' - choix de A avec W Déchiffre C'=C avec k Stocke dans zone ASP-A co=0 Fermeture W - stocke BASP-A BASP-A Incrémentation co - BASP-A=Chiffré de ASP-A avec ks Ouverture W,BASP-A 4 Déchiffre BASP-A avec ks , stocke dans ASP-A Vérifie croissance de co Utilisation : signature W,e',x - choix de A avec W Calcule sig avec clé de signature de ASP-A sig-S(e',e,x) sig Utilisation : réinitialisation à l'état E PS-A forme message M: M - * calcule e=h(E), u=0 * pour variante 2 calcule u=h(0,e) * M=(e u) MACkA_, (e u) choix de A avec W verif MAC avec clé kA_I de ASP-A si correct, initialise e ou u selon variant 1 ou 2. Destruction ASP-A - Toutes ls données de ASP-A sont effacées du SE Le diagramme ci-dessous montre les états et transitions de ASP-A selon les commandes du tableau ci-dessus. 3025959 signature Références 5 1. NFC: Forum: http://www.nfc-forum.org/home 2. SIM : norme 3GPP TS 31.102 3. Java-Card: 4. HCE: https://developer.android.com/guide/topics/connectivity/nfc/hce.html 5. Tokenisation: EMVco , Payment Tokenisation Specification 10 6. TCG : forum http://www.trustedcomputinggroup.org/ 7. Voir norme "Critères Communs » sur http://www.ssi.gouv.fr 8. GP : global platform : http://www.globalplatform.org/ 9. Voir par exemple ISO/IEC 29192 Diagramme d'é de ASP-A

Claims (8)

1. REVENDICATIONS1) procédé de sécurisation d'une application transactionnelle A émise par un prestataire PS-A permettant de réaliser des transactions de proximité entre un smartphone M et un terminal T (via NFC par exemple) ou entre un smartphone M et un serveur S via internet, où M est considéré comme non sûr, mais doté d'un élément de sécurité SE réputé sûr, garantissant la sécurité des données de la transaction attaquables par d'éventuels malwares présents dans le smartphone M, Le dit procédé étant caractérisé en ce que son utilisation pour sécuriser l'application A : - Nécessite une programmation adaptée à A et à l'utilisation de ce procédé, dans le mobile, - Ne nécessite aucune programmation dans le SE qui se borne à fournir un ensemble de services de sécurité préétablis indépendamment des applications supportées
2. 2) procédé selon la revendication 1 se basant sur les éléments et principes techniques suivants : a) Il repose sur un ensemble de fonctions de sécurité appelées GSF réalisées sous forme d'un ou plusieurs programmes dans le SE - GSF est indépendant du type de transactions et de l'application A considérée, - Le programme GSF utilise des paramètres spécifiques à l'application A, appelés ASP-A : données décrivant l'état de l'application A dans le smartphone, clés cryptographiques et choix d'algorithmes cryptographiques, fixés lors de la prise en compte de l'application A sur le smartphone M, donc la création de ASP-A, - Selon un mode particulier de réalisation, la création de ASP-A peut être libre, donc indépendante de l'émetteur du SE, ce qui simplifie les modalités d'installation de nouvelles applications, - Aucun programme spécifique à l'application A n'a à être chargé dans le SE. b) Il repose aussi sur une application P-A dans le mobile, qui traite la logique générale de l'application A, ses interfaces utilisateurs et ses entrées sorties. c) Il repose également sur un ensemble de traitements appropriés TM-A réalisés dans le terminal T ou SM-A dans le serveur S, dépendant de l'application A considérée, et la collecte des données des transactions qui prouvent au prestataire PS-A la réalité des transactions, afin qu'il puisse mener les actions appropriées spécifiques de l'application A. d) Les données d'état de l'application A peuvent être réinitialisées à une valeur quelconque sous contrôle du prestataire de service émetteur de l'application A 3025959 2
3. 3) procédé selon les revendications 1 et 2 basé, lors de chaque transaction d'une application, sur 5 a) la génération par le SE d'une signature de paramètres d'état antérieur et postérieur à la transaction, et d'un élément anti-rejeu x, b) la mémorisation du nouveau paramètre d'état dans le SE, qui deviendra le paramètre d'état antérieur lors de la prochaine transaction c) le paramètre d'état postérieur u' est calculé de manière récursive par 10 u'=h(u,e') où u est le paramètre d'état antérieur ; la signature a donc la forme S(h(u,e'),x)
4. 4) procédé selon les revendications 1,2 et 3 permettant d'enregistrer dans le smartphone, en dehors du SE, un fichier LOG qui enregistre séquentiellement pour 15 chaque application les variables d'état après chaque transaction, ainsi que la signature et l'élément x.
5. 5) procédé selon les revendications 1, 2, 3 et 4 permettant la réinitialisation de l'état courant à une valeur quelconque, et l'effacement des fichiers LOGs. Cette 20 opération se traduit par une mise à jour dans le SE des données spécifiques de l'application et se fait sous le contrôle du prestataire de service qui a émis cette application. Le SE vérifie la provenance de cette opération et l'intégrité de ces données par un mécanisme cryptographique adéquat, basé au moins sur une clé partagée entre le SE et le prestataire de service. 25
6. 6) procédé selon les revendications 1,2,3,4 et 5 permettant au terminal qui a initialisé les paramètres de la transaction de vérifier l'exécution de cette transaction par un smartphone, par vérification du LOG (total ou partiel selon les besoins de l'application A considérée) avec la signature produite par le SE ainsi que par des 30 contrôles de cohérence entre les états avant et après la transaction. Un fichier de collecte sécurisé par les signatures produites par le SE permet après transfert au prestataire de service, la finalisation des transactions selon les modalités propres à l'application considérée. 35
7. 7) procédé selon les revendications 1,2,3,4 et 5 permettant au serveur qui a fixé les paramètres de le transaction de vérifier l'exécution de cette transaction par un smartphone, par vérification du LOG avec la signature produite par le SE ainsi que par des contrôles de cohérence entre les états avant et après la transaction. Un fichier de collecte sécurisé par les signatures produites par le SE permet après transfert au 40 prestataire de service, la finalisation des transactions selon les modalités propres à l'application considérée. 3025959 3
8. 8) procédé selon les revendications 1,2,3,4,5 et 6 permettant d'adapter l'architecture de sécurité de la revendication 1 au cas de transaction C2C, entre deux smartphones, via NFC ou internet ou tout autre canal de communication entre deux 5 smartphones. Un bloc fonctionnel terminal spécifique à l'application est intégré dans le smartphone qui devient terminal (ou serveur) dans une transaction avec un autre smartphone. L'enregistrement des transactions avec d'autres smartphones se fait grâce au fichier de collecte et en temps réel ou différé, le transfert au prestataire de service pour finalisation des transactions et le cas échéant mise à jour de l'état dans le 10 smartphone par la fonction ré-initialisation.