FR2974923A1 - Transmission sure d'image sur terminal non sur - Google Patents

Abstract

Le domaine de l'invention est celui des applications sécuritairement sensibles sur un terminal de type PC, Smartphone, tablette....On fait l'hypothèse que ce terminal est non sûr, ce qui correspond bien à la situation actuelle. On considère la problématique de transmission d'une image par un serveur à un utilisateur de ce type de terminal, dans le cas où l'image contient des informations importantes pour l'utilisateur et dont la modification par un malware lui porterait tort : par exemple pour conclure une transaction, où l'image représente le contenu de la transaction qui engage l'utilisateur. La propriété apportée par l'invention est l'intégrité de l'image et le cas échéant l'intégrité de l'approbation par l'utilisateur. Un exemple illustratif est une transaction avec un smartphone pour l'achat de contenus, payés en appelant des numéros surtaxés. Un malware peut provoquer le paiement de montants qui n'ont rien à voir avec ce qu'attend l'utilisateur, et peut même provoquer des paiements spontanés en dehors de tout accord de l'utilisateur, si ce malware a « volé » le code confidentiel de l'utilisateur conditionnant le paiement.

Description

Introduction Le domaine de l'invention est celui des applications sécuritairement sensibles sur un terminal de type PC, Smartphone, tablette....On fait l'hypothèse que ce terminal n'est pas forcément de confiance, ce qui correspond bien à la situation actuelle. En effet l'actualité est riche d' évènements montrant la fragilité des systèmes informatiques, attaqués de diverses manières par des virus, chevaux de Troie, attaques « man in the middle » ou autres techniques mises en oeuvre par des hackers, et pour lesquelles nous utilisons le mot générique de « malware ». On considère la problématique de transmission d'une image I par un serveur S à un 10 utilisateur U sur un terminal T muni d'un moyen de restitution d'image tel que imprimante ou écran : voir figure 1. On suppose que I contient des informations importantes pour U et dont la modification par un malware porterait tort à u : par exemple pour conclure une transaction avec S où I représente le contenu de la transaction qui engage U.

15 La propriété recherchée dans l'invention est donc l'intégrité de I et le cas échéant l'intégrité de l'approbation par U. Un exemple illustratif est une transaction avec un smartphone pour l'achat de contenus, payés en appelant des numéros surtaxés. Un malware peut provoquer le paiement de montants qui n'ont rien à voir avec ce qu'attend l'utilisateur, et peut même provoquer des paiements spontanés en dehors de tout accord de l'utilisateur, si ce malware a 20 «volé » le code confidentiel de l'utilisateur conditionnant le paiement. Dans la suite, un élément sera dit sûr si il ne peut être attaqué par un malware, et non sûr dans le cas contraire. On considère dans la suite que S est un serveur sûr mais T est un terminal non sûr ; même si les moyens de transmission de données entre S et T sont sécurisés en confidentialité et intégrité (techniques telles que SSL, TLS, etc utilisées sur le NET) la problématique reste inchangée du fait que l'on fait l'hypothèse que T est non sûr. L'attaquant est donc un malware, installé malicieusement dans le terminal T ou capable 30 d'opérer entre S et T, et donc s'interposant entre S et U .

Etatde l'art connu actuellement (avril 2011)

Deux orientations peuvent être décrites : 35 s Faire en sorte que le terminal T soit sûr, au moins pour les applications sensibles qu'il supporte. Des groupes de normalisation tels que TCG ou GP travaillent actuellement sur cette approche difficile, car démontrer la sécurité d'un sous ensemble matériel et logiciel d'un terminal aussi complexe qu'un PC ou un smartphone est une tâche très difficile, nécessitant un examen long et méticuleux des 40 architectures, schémas, description formelle et logiciels sources, examen à répéter à chaque évolution, et à réaliser par des experts indépendants auxquels les fabricants confient toutes ces données. Par contre cette approche s'applique bien aux cartes à puce, de complexité beaucoup plus faible que PCs ou smartphones. - Utiliser des méthodes non sensibles aux malware, telles que les « CAPTCHA » (COmpletely Automated Public Turing test to tell Computers and Humans Apart), qui, comme l'acronyme l'indique, sont difficiles à attaquer par un programme d'ordinateur. Cette technique est d'utilisation courante actuellement pour empêcher des attaques telles qu'un automate essayant de se connecter à un serveur en essayant différents mots de passe. Cependant le contexte de l'invention est différent, car on cherche ici avant tout à garantir l'intégrité de l'information I transmise à l'utilisateur, ainsi que de son éventuelle approbation. Mais en restant dans le domaine de l'invention, plusieurs brevets pertinents ont été considérés W02007/056808 Le principe se base sur la lecture d'un «secure object » ou captcha superposition de l'image (données de la transaction) et d'un code « secure Id ». L'utilisateur doit lire ce code, et taper le secureld sur un clavier pour renvoi au serveur, indépendamment de la confirmation de la transaction représentée par l'image I grâce à un code confidentiel.. Ce point constitue un inconvénient en terme de simplicité du dialogue utilisateur. EP1843288 Principe analogue, mais le secureId est ici un « défi » auquel l'utilisateur répond non pas en le renvoyant par saisie sur le clavier, mais en élaborant une réponse au défi, calculée par l'utilisateur (par exemple avec une grille de nombres) , puis saisie au clavier . Le serveur peut alors vérifier que réponse au défi et défi envoyés sont cohérents. Demande 1002516 à l'INPI, du même auteur Elle décrit 2 approches, l'une étant assez analogue à W02007/056808 , l'autre basée sur une technique de clavier virtuel La première approche semble donc antériorisée par ce brevet. Elle décrit également une implémentation à base de carte a puce, et les protocoles correspondants, qui s'adapte bien aux nouvelles applications sécuritairement sensibles sur smartphones. Document présent Etend la demande précédente au cas d'un contrôle personnel I est alors une photo Etend la demande précédente par l'utilisation de polices de caractère 40 spécifiques à l'utilisateur, facilitant ainsi la reconnaissance par 20 25 2974923- l'utilisateur de l'image et complexifiant une attaque par un rnalware de cette intégrité ; Propose une cinématique n'exigeant pas, contrairement W02007/056808 et EP1843288, de la part de l'utilisateur, l'introduction au clavier (réel ou virtuel) d'un nouveau code, et simplifiant donc le dialogue utilisateur, tout en permettant la confirmation de la transaction de façon simple et robuste. Décrit des techniques de codage et de génération du Captcha pour un organe de faible puissance de calcul tel qu'une carte à puce. Description générale L 'invention a pour objet un procédé de sécurisation d'une image I envoyée par un 15 prestataire S à un terminal non sûr T d'un utilisateur U, ledit procédé comportant, conformément à la figure 1, au moins les étapes suivantes - Identification de l'utilisateur U par S (1) - Emission par S de l'image I à destination du terminal T (3) de l'utilisateur U, ledit procédé étant caractérisé en ce que .- L'utilisateur U s'est enregistré auprès du prestataire S dans une phase préalable d'inscription et a fourni des données reconnaissables par lui audit prestataire S, une marque M contenant des données reconnaissables par l'utilisateur U, est établie par S (2) et incorporée à l'image I, qui devient ainsi I+M. - S envoit l'image composée de l'image originale I et de la marque M établie par S à T (3) L'utilisateur U reconnait la marque M au sein de l'image présentée, cette reconnaissance permettant alors une approbation de la transaction sous différentes formes. 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 35 et nullement limitatif de l'invention. - la figure 1 décrit le principe général de transmission sûre d'une image à un utilisateur ayant un terminal non sûr le figure 2 donne des exemples d'images et de marques, au sens de l'invention. la figure 3 donne des exemples de police de caractères spécifiques de l'utilisateur - la figure 4 décrit différentes possibiltés pour le format des données graphiques décrivant la marque et éventuellement l'image la figure 5 décrit une application de type « contrôle de droit personnel » et sa cinématique. la figure 6 décrit un principe de marquage d'une image photographique peu consommateur de ressources. la figure 7 décrit une variante du schéma de base permettant une saisie de l'approbation de l'utilisateur sur terminal non sûr. - la figure 8 adapte la figure 7 à une application de paiement sur smartphone. 10 - la figure 9 décrit le rôle détaillé du « secure element » tel que la SIM dans l'application de la figure 8.

Schéma général figure 1 15 L'utilisateur U est connu du serveur S par une procédure préalable (non figurée) d'inscription où U a défini pour se connecter à s un identifiant, et où de plus U et S ont convenu d'une donnée que nous appellerons « marqueur » m . Ce marqueur peut être une valeur numérique comme une date de naissance ou tout autre information que U est sensé mémoriser, et qui reste fixe d'une transaction à l'autre. Optionnellement, pour la phase 20 d'approbation, un mot de passe ou code confidentiel CC peut être défini lors de cette procédure préalable. - Message 1 L'utilisateur U se connecte à un serveur S et s'identifie : procédure classique de type le «login » . Notons qu'un malware voulant attaquer U n'a évidemment aucun intérêt à agir à cette étape. 25 - Traitement 2 : Après contrôle de cette identité et mot de passe, S retrouve la valeur m correspondant à l'identité de U, établit I, puis modifie I en I+M où M est une représentation graphique de m: Cette modification peut être de natures diverses simple superposition, ou opération graphique plus complexe mais laissant la lisibilité de M pour U. Par contre cette modification ne doit pouvoir être imitée par un malware. Message 3 le serveur envoie l'image I+M au terminal T qui l'affiche ou l'imprime Interaction al : U voit I+M, et compare M avec le m qu'il connaît. Si il y a correspondance entre M et m, l'utilisateur en déduit que l'image n'a pas 35 été altérée par un malware. - Optionnellement, une phase d'approbation par l'utilisateur U suit, décrite plus bas.

Une variante de ce schéma général est que la marque au lieu de contenir une valeur 40 constante connue de U et S contienne une valeur variable mais que U a un moyen quelconque de vérifier: par exemple une valeur qui se déduit cryptographiquement des informations d'identification du message 1, et de dates...

Exemples de marquage L'invention se base sur une technique de marquage d'une image I par une marque M L'image marquée étant notée I+M. Une technique pouvant être employée est de type « CAPTCHA » (Completely Automated Public Turing test to tell Computers and Humans Apart) avec des améliorations et adaptations à la problématique décrite ici, notamment en ce qui concerne l'intégrité des données-de la transaction. 10 Le marquage M, c'est-à-dire la transformation de I en I+M se base sur l'apposition d'une suite de caractères alphanumériques ou symboles qu'un logiciel de type OCR (optical character recognition) ne peut interpréter : la figure 2 représente trois exemples : a/ où l'image est un suite de caractères représentant un nombre (64792), et la marque un autre nombre qui lui est superposée (319), chaque nombre restant facilement reconnaissable par 15 un oeil humain . Dans le cas b/ l'image est une photographie sur laquelle apparaît le nombre « 143 ». Dans le cas c /,l'image est un texte de type contrat de location sur laquelle est apposée une marque : les chiffres « 1 » , « 4 » et « 3 » et des courbes destinées à rendre difficile pour un malware l'extraction de la marque afin de modifier l'image, donc le texte du contrat. L'apposition de M à I peut être de divers types : on considère les pixels de I et de 20 M qui correspondent (même coordonnées) - Superposition : simple remplacement pixels de I par ceux de M Mélange : opération entre les pixels de I et M . opération entre les valeurs des pixels Opération de morphologie : les pixels de I au voisinge de ceux de M sont modifiés selon un algorithme particulier La figure 3 représente différentes formes de symboles par exemple en haut une police de caractères alphanumériques dessinée par l'utilisateur lui-même, ce qui a deux intérêts : L'utilisateur reconnaît plus facilement une anomalie due à un malware La tâche du malware est plus compliquée comme montré ci-dessous. Robustesse du procédé: l'Image et la marque sont générées par S et envoyées vers T. Il convient de rendre difficile la séparation entre image et marque par un malware s'interposant entre S et U, car ce 35 malware pourrait modifier l'image et remettre la marque initiale séparée de l'image initiale. Cette attaque est une transformation I+M en I'+M où I' est une image différente de 1 l'attaque consiste à faire (I+M)-I+I'=I'+M. Ceci est possible si I+M est séparé en I et M par le malware. 40 Les précautions de réalisation suivantes doivent donc être prises .30 2974923. I ne doit pas pouvoir être connue ou reconstituée par le malware (au sens égalité stricte bit à bit), sous peine d'isoler M facilement en faisant (I+M)-I=M I est donc exclusivement connue et/ou calculable par S ; o dans le cas où I représente une photo (fig 2b) il ne faut donc pas que cette photo dans le SE soit accessible en lecture en dehors de la phase d'inscription du droit personnel par une autorité, sinon un malware dans le terminal ferait facilement l'opération ci-dessus: De plus, des variations aléatoires peuvent être ajoutées par le SE, telles que par exemple décalages en x et y, rotations, ou des variations de paramètres tels que seuils de .10 quantification des couleurs. o dans le cas où I représente une suite de caractères alphanumériques (figure 2 a) ou c) il ne faut pas que 1 puisse être calculée par le malware du terminal d'après les données contextuelles de la transaction, telles que par exemple le texte apparaissant dans la figure 2 c) ou le nombre « 64792 » de la figure 2a). 15 Des variations aléatoires peuvent être introduites, de façon à ne pas empêcher la lisibilité par l'utilisateur, mais à rendre impossible la prédiction par le malware de I au bit prés et donc de réaliser l'attaque (I+M)-I+I'. Ces variations peuvent jouer sur le positionnement et la taille des caractères, leur orientation, la police utilisée, etc. 20 - On peut généraliser le marquage à l'utilisation en lieu et place de caractères numériques ou alphanumériques d'une suite de 'signes qui n'ont un sens que pour l'utilisateur, qui, dans une phase de parametrage du procédé, définit lui-même son alphabet de signes. L'utilisation d'une police de caractère spécifique de l'utilisateur nécessite un surcroît important de travail pour un malware, car il devra dans un 25 premier temps « apprendre » en fonction du déroulement des transactions la forme spécifique des caractères avant de pouvoir séparer I et M. Ceci rajoute donc un niveau de sécurité puisque un malware diffusé par une organisation malveillante n'a pas de connaissance à priori de l'alphabet utilisé sur tel terminal, puisque choisi et dessiné par son utilisateur. Ceci peut également se substituer au test de 30 correspondance entre M et m de la figure 1 étape a/ La figure 3 donne des exemples : dans un cas, il s'agit de 10 chiffres dessinés par l'utilisateur, par exemple avec une souris ou un stylet lors de la phase parametrage du système ; dans l'autre cas, il s'agit de symboles graphiques quelconques.

35 Format des données I+M La marque et l'image doivent être envoyées au terminal de façon à rendre le contenu incompréhensible pour un logiciel de type malware: il ne faut pas par exemple que l'information numérique représentée par la marque soit envoyée au terminal sous forme de suite de caractères numériques codés ASCII . De plus les données constituant image et 40 marque doivent être envoyées de façon « mélangée », c'est-à-dire de façon qu'il n'y ait pas -2974923 de principes simples pour les séparer, tel que par exemple l'ordre dans lequel S transmet les données au terminal T dans le message 3 de la figure 1, ou bien des entêtes particuliers associées aux données transmises permettant de les reconnaître. En effet, même si est utilisée une police de caractères spécifique à u et difficile à reconnaître par un malware, une telle séparation faciliterait le travail de l'attaquant et fragiliserait le procédé décrit par l'invention. Il y a plusieurs réalisations possibles représentées sur la figure 4, mais comme dans un des modes de réalisation de l'invention le calcul de I+M se fait dans un élément de type carte à puce, on s'intéresse aux formats adaptés aux faibles ressources (mémoire et calculs) typiques des cartes à puce. 10 o La Marque+Image sont une seule bitmap spatiale ou fréquentielle (JPEG par exemple) (fig 4a). Cette matrice de valeur de pixels ou de fréquences « mélange » les informations de l'image et de la marque. o La Marque+Image sont décrits de façon vectorielle : les vecteurs doivent être envoyés-au terminal en désordre tel que ceci apparaît sur la fig 4b deux caractères 15 (« 2 » et « 0 » ) y sont représentés, composés de plusieurs segments, la numérotation représentant l'ordre des segments dans le message 3 de S vers T. Mais ceci n'empêcherait pas un malware de reconstituer l'ordre en se basant sur la connexité des segments (segments qui ont un sommet commun). De cette façon, il serait possible d'isoler chaque caractère, et ceci pourrait faciliter la reconnaissance 20 de ces caractères. Plusieurs techniques sont possibles pour complexifier la reconstruction des caractères individuels en se basant sur un critère de connexité o Sur la figure 4b apparaissent des segments 5 et 13 reliant des points particuliers des caractères « 2 » et « 0 ». Ainsi un algorithme de parcours partant du segment 12 se perdra dans plusieurs parcours possibles (12,18,5,21,6..: ou 18,12,20,17.. etc) Sur la figure 4c, le description vectorielle des caractères est réalisée de façon à multiplier les sommets communs, puisque chaque vecteur est dessiné sur une trame fixe et joint deux points voisins de cette trame. Intégrité de l'approbation de l'utilisateur Dans un mode de réalisation particulier, l'invention permet non seulement de garantir l'intégrité du contenu de l'image, mais aussi l'intégrité de la décision de l'utilisateur, qui dépend du contenu de l'image. Notons que la décision de l'utilisateur peut être binaire 35 accord ou désaccord sur la transaction, auquel cas authentifier l'utilisateur (et son accord) a la même signification que garantir l'intégrité de sa décision. Par contre, pour certains types de transactions, on peut avoir des choix multiples, et dans ce cas, garantir l'intégrité de la décision est plus fort qu'authentifier simplement l'utilisateur. La partie approbation optionnelle de la figure 1 représente un moyen de réalisation pour 40 l'intégrité de la décision de l'utilisateur : cette décision ne peut se faire directement sur le terminal T car le malware pourrait alors simuler cette décision. C'est le cas si par exemple l'approbation de la transaction se base sur l'envoi au serveur S d'un mot de passe ou code confidentiel CC, tapé sur un clavier associé a T. CCdoit être connu de S, qui l'a enregistré au moment de l'inscription de U chez S. Le malware n'aurait aucun mal à capter les caractères tapés sur le clavier ! Aussi un moyen simple est d'utiliser un terminal T' différent de T et réputé sûr, empruntant des canaux de transmission. sûrs, différents de ceux employés par T, et donc non soumis au malware. Des réalisations possibles sont par exemple basées sur un téléphone mobile. Message 4: infos complémentaires textuelles Interaction b: l'utilisateur approuve la transaction au vu de 1' mage I, et des infos complémentaires reçues en 4 Message 5: message d'acquit Message 6 conclusion de la transaction, dépendant du contexte 15 applicatif . ce peut être par exemple le débit d'un compte bancaire, l'enregistrement de la transaction dans un fichier historique, la préparation de l'envoi d'un colis.:. Notons aussi que le terminal T' peut permettre dans la variante (ligne 39 page 4) du schéma général d'afficher le contenu variable de m que U doit retrouver sur l'image. 20 Amélioration de la robustesse du procédé La robustesse du procédé peut être renforcée si le serveur accorde un délai maximum avant de recevoir l'acquit 5, ce délai limitant le temps à la disposition d'un malware pour attaquer I+M, même si celui-ci est doté de moyens puissants de traitement et de reconnaissance 25 d'image, ou s'il invoque (via le NET par exemple) une entité ayant ces capacités. Le logiciel serveur incorpore donc dans ce cas une temporisation logicielle limitant le délai entre les messages 1 et 5 de la figure 1. Elle peut également l'être sans moyen programmatique si l'utilisateur contrôle que le délai entre 2 et a/ n'excède pas une certaine limite. 30 Cas des terminaux non sûrs mais disposant d'un élément sûr Un mode de réalisation important est celui où le terminal possède un élément de confiance, appelé SE (secure element). Des exemples typiques de SE sont des cartes à puce, comme la SIM par ex dans les smartphones. Des réalisations de SE existent aussi avec des clés USB. 35 Enfin un sous ensemble du terminal peut être réputé sûr. Nous utiliserons pour tous ces cas le mot SE, indépendamment de sa structure matérielle, et une particularité est que ce SE doit être simple (une grande complexité impliquerait qu'il ne pourrait être considéré comme étant sûr) et qu'il ne possède pas de moyens d'entrée sortie en propre, tels que clavier/souris et écran. Il est seulement doté d'un processeur avec ses données permanentes et volatiles, 40 d'un port d'entrée sortie, et son mode de réalisation le rend robuste contre toute attaque visant à découvrir des données dans ses mémoires permanentes (telles que des clés cryptographiques) ou de modifier son fonctionnement en injectant des perturbations ou bien en y introduisant un malware spécifique. Les SE étant des objets informatiques assez simples, ils sont dans l'état de l'art 2011 facilement évaluables du point de vue de leur sécurité ; ils peuvent être analysés par des experts du point de vue de leur constitution, leur architecture, leur réalisation et fonctionnement afin de détecter leur sensibilité à diverses attaques. Des procédures et des méthodologies d'évaluation sont même standardisées, et les SE peuvent donc être considérés dans le contexte de ce document comme des éléments de confiance. 10 'Dans un but de simplification de la description, on considère le cas du SE comme un cas particulier de la figure 1 le SE est vu par le terminal non sûr T comme un serveur sécurisé S et par ailleurs le SE, comme S, peut communiquer de façon sûre avec un terminal T' sûr. La norme GP décrit les moyens pour ce faire. Une application : contrôle de droit personnel sur un smatphone C'est le problème du contrôle d'un droit particulier accordé à une personne particulière dans ce cas, il ne suffit pas de contrôler des données représentant ce droit, mais il faut aussi contrôler que la personne est bien la titulaire de ce droit. C'est par exemple le cas d'un 20 voyageur ayant un abonnement lui permettant de payer ses billets a demi-tarif. On se place dans le cas d'un contrôle électronique par le contrôleur dans le train. Le billet et l'abonnement sont contenus dans le smartphone du voyageur, et le contrôleur possède son propre terminal à écran lui permettant d'interagir avec le mobile du voyageur, et de contrôler ses titres de transport. L'abonnement demi-tarif étant personnel, le contrôleur doit 25 vérifier que le titulaire de l'abonnement est bien la même personne que le voyageur, car sinon il y a des risques évidents de fraudes : un voyageur malhonnête pourrait emprunter le smartphone d'un titulaire d'un abonnement demi-tarif, substituer sa propre photo à celle du titulaire, et ainsi voyager demi-tarif Par ailleurs, pour des raisons de « privacy » la solution simple consistant à transférer dans le terminal du contrôleur la photo du voyageur qui 30 pourrait être authentifiée grâce à une signature électronique incorporant photo et données descriptives de l'abonnement n'est pas acceptable on admet généralement que chaque citoyen a le droit de voyager anonymement. La méthode utilisée est donc un marquage de l'image constituée par la photo du titulaire de l'abonnement, et est détaillée sur la figure 5. Le principe est analogue à celui de la figure 1, 35 mais ici le serveur S est le SE, sûr, et l'utilisateur U est le contrôleur qui vérifie le billet/abonnement du voyageur en utilisant le smartphone T de ce dernier, donc éminemment non sûr pour le contrôleur. Le contrôleur dispose également de son propre terminal T', considéré comme sûr. Notons qu'avec le NFC ou le NET, il est possible d'établir un canal sécurisé« end to end » entre le SE qui est dans T et le terminal sûr T': La 40 norme GP décrit ces possibilités.

Sur la photo affichée sur l'écran du smartphone T, apparaît la marque m=143. Ce nombre est une caractéristique constante du terminal du contrôleur, variable pour des contrôleurs différents, et est calculé par le SE en (2) à partir du message (1) envoyé au SE du smartphone de l'utilisateur par le terminal contrôleur T'. Ce calcul qui n'influe pas sur le procédé n'est pas décrit ici. En (3) le SE renvoie I+M au terminal T, pour affichage. En (4) le SE envoie à T' des informations textuelles (description du billet et de l'abonnement) en utilisant le canal sécurisé entre SE et T'. Le contrôleur a alors tous les éléments pour juger de la validité du titre de transport. Notamment en (a) il vérifie que la photo sur l'écran correspond bien au voyageur et il vérifie la marque : le nombre 143 doit être celui connu du contrôleur. Par l'interaction (b) il renvoie en (5) un acquit au SE qui correspond dans le SE à un « compostage du billet électronique », afin de le rendre inutilisable pour un nouveau voyage. Ce type de transactions de « contrôle de droit personnel » se rencontre dans maintes applications, mais les principes indiqués ci-dessus s'adaptent facilement à chaque contexte applicatif. Caractéristiques de réalisation d'une application contrôle de droit personnel La marque doit être apposée par le SE a des endroits spécifiques et constants de la photo où 20 apparaissent des variations de couleurs ou de luminosité importantes, sinon par traitement d'image assez simple un malware pourrait séparer image et marque, et comme expliqué précédemment, ceci fragiliserait le procédé. Un malware dans le terminal voulant attaquer le procédé aurait à réaliser une analyse d'image approfondie pour séparer marque et image, et changer cette dernière dans un temps inférieur aux quelques secondes laissées pour ce 25 contrôle. Ce délai peut être contrôlé par le logiciel de T' par une mesure du temps entre message 1 et b. Il est clair que l'image ne doit jamais sortir non marquée du SE, car dans ce cas, une simple différence entre image marquée et image non marquée permettrait de réaliser la séparation ci-dessus. 30 La figure 6 représente un processus pour réaliser le marquage de l'image dans un SE disposant d'une faible puissance de calcul, comme c'est le cas des SE de type carte à puce. Le quadrillage apparaissant sur la figure 6 définit des carrés correspondant aux blocs élémentaires d'un algorithme de compression de type JPEG (donc 8x8 ou 32x32 pixels) ou bien à un multiple de ces blocs (par exemple un carré de la figue 6 égale 2x2 blocs JPEG). 35 La compression JPEG remplace le tableau de 8x8 ou 32x32 pixels par une suite de coefficient (uv) qui sont une représentation frequentielle de l'image spatiale du tableau. L'image compressée JPEG s'obtient à partie des coefficients (uv) de chaque bloc, en parcourant les blocs de l'image de gauche à droite et de haut en bas. Pour chaque bloc, les couples (uv) sont donnés selon un parcours « zigzag » du bloc. La marque fait par exemple 40 3 caractères, qui s'inscrivent dans 3 carrés de l'image. ..2974923 Dans la technique représentée par la figure 6, le contenu JPEG de l'image marquée s'obtient simplement : lors du parcours décrit ci-dessus, lorsqu'un bloc est dans un carré qui correspond à un des caractères de la marque, on sélectionne le bloc correspondant au caractère de la marque. Dans l'exemple de la figure 10, le caractère le plus à gauche de la marque vaut « 1 » et il faut donc choisir lorsque le parcours arrive à l'emplacement pointé par la flèche 2 l'un des 4 blocs du carré pointé par la flèche 1, sur la figure 6. On n'a donc pas de calculs complexes à faire, car la transformation spatiale -> frequentielle (xy-iuv) utilisée dans JPEG est trop lourde pour être réalisée dans les SE de faible puissance de calcul, en des temps limités à quelques secondes. 10 Ce schéma s'étend au cas où plusieurs versions du même caractère sont enregistrées, correspondant à des variations de type forme/rotation, etc. 15 Variante du schéma de base sans utilisation d'un terminal sécurisé pour l'approbation Classiquement, l'approbation par l'utilisateur U d'une transaction entre lui et un serveur S se base sur l'introduction d'un code confidentiel (CC), tapé sur le clavier du terminal T, transmis au serveur puis reconnu ou non par le serveur. Cette méthode classique est évidemment à proscrire dans le cas où T n'est pas de confiance. C'est pourquoi dans la figure 1 apparaît le terminal T', mais qui n'a plus lieu d'être dans cette variante. La méthode décrite ci-dessous s'associe au principe de transmission sûre d'une image à un terminal non sûr de la figure 1, mais en considérant que l'image marquée I+M contient les symboles (par ex. les 10 chiffres) permettant de saisir le CC de l'utilisateur. Ce type de procédé, appelé souvent «clavier virtuel », est connu et largement utilisé sur Internet, mais il bénéficie ici de la robustesse apportée par le fait qu'il est intégré à I+M. Ainsi, la reconnaissance par l'utilisateur des informations de l'image marquée permet de plus la saisie de l'approbation. L'attaque (possible sur les systèmes actuels) consistant à reconnaître le clavier virtuel, c'est-a-dire par reconnaissance de caractères retrouver la position des différentes touches, puis avec les coordonnées des clics de souris, en déduire le CC de l'utilisateur devient ici très difficile du fait que le clavier virtuel est intégré a l'image I+M. Notons également que la méthode permettant à u de détecter une attaque contre l'intégrité de I, décrite figure 1 (m contenant une donnée reconnaissable par U) n'est plus nécessaire dans cette variante (bien qu'elle puisse malgré tout être utilisée si l'on craint que le malware, par une technique de type « phishing » ne s'empare du CC). En effet un malware qui substituerait I'+M' à I+M provoquerait en (4) l'envoi de coordonnées de clics ne correspondant pas au CC de U connu de S Pour qu'il n'en soit pas ainsi, ce malware devrait reconnaître la position des touches du clavier virtuel dans I+M, et garder les mêmes positions dans l'+M'. Comme mentionné plus haut, ceci est considéré comme irréaliste. La figure 7 représente cette variante de la figure 1 Le terminal est muni d'une souris ou bien l'écran est tactile. Le déroulement du début de la transaction est identique à celui 2974923 . décrit pour la figure 1 jusqu'au message 3. En b/, l'utilisateur, pour approuver la transaction réalise une séquence de clics. Le terminal T transmet dans le message 5 au serveur S ces clics (suite de coordonnées x,y ). Le serveur S peut avec I+M qu'il vient de générer et les coordonnées reçues vérifier la correspondance avec le CC enregistré pour U. S authentifie donc l'approbation de l'utilisateur sans qu'un malware ne puisse simuler cette approbation. Cette séquence est variable à chaque transaction, et il ne servirait à rien pour un malware de la perturber. L'échange 4 n'a plus lieu d'être car la souris n'a pas de possibilité de restitution d'informations vers l'utilisateur Variante du schéma de base dans le contexte smartphone Les smartphones sont un type de terminal se plaçant bien dans les cas précédemment décrit. Ils ont en effet un écran tactile, et d'autre part ne peuvent être considérés comme sûrs au 15 sens de ce document, dans la mesure où leurs operating systems sont de plus en plus complexes, et sujets à de nombreuses mises à jour. D'ailleurs de nombreuses attaques sont apparues en 2010 / 2011. La figure 8 est équivalente à la figure 7; mais dans le contexte transactions avec un smartphone via internet (l'entité distante T' est par ex un serveur prestataire de commerce 20 électrique) ou NFC «l'entité distante T' est alors le terminal prestataire ou commerçant). Le serveur S est ici le SE (« secure element », ou SIM) qui est de confiance. Le message 1 permet de lancer simplement la procédure de transmisssion sûre d'une image mais l'identité est implicite car le SE correspond au propriétaire du smartphone, dont il contient tous les éléments d'identification. Mais le SE se connecte via un canal NFC au terminal prestataire 25 (message 11) pour obtenir (message 12) les données de la transaction: ici notamment un descriptif de la transaction ( « tennis NIXE 42 H » sur la figure 8) et le montant (44,30 E sur la figure 8). Le SE peut donc calculer en (2) l'image marquée I+M puis l'envoyer au terminal T par le message (3) contenant la description graphique de cette image. 30 L'utilisateur (interaction a) peut alors vérifier les données de la transaction et du captcha I+M qui doivent être cohérentes : le montant 44,30 E de la transaction est le même que celui apparaissant dans le captcha I+M sur la figure 8. U peut alors saisir le CC en cliquant sur les caractères adéquats du captcha : l'interaction b est une suite de clics sur les chiffres en bleu du captcha. Les touches « < X OK » correspondent aux fonctions classiques 35 respectivement : annuler le dernier clic, annuler la transaction, approuver après les 4 clics, si le code confidentiel fait 4 chiffres comme c'est souvent le cas. Le message 5 est la suite des coordonnées (x,ÿ) des 4 points cliques, et le SE peut ainsi en tenant compte du captcha I+M et la position des différents caractères vérifier que la séquence de coordonnées est bien cohérente avec le code confidentiel de l'utilisateur enregistré dans le SE. Un contrôle dans le logiciel du SE du délai entre le message 12 et le message 5 permet de limiter le temps dont disposerait un malware pour attaquer le procédé: Si tout est correct, le SE peut alors réaliser l'opération de paiement (non détaillée ici) qui se termine par une opération de type signature de l'ordre de paiement, et le message 6 est un message d'approbation SE vers T' qui contient cette signature. La figure 9 reprend cette cinématique en terme de commandes/réponses de T au SE. Les flèches internes au SE représentent h information de l'offre du marchand servant pour a fonction paiement montant, identité marchand) ' i : lancement temporisation j position des caractères du CC k arrêt temporisation 1 cas de vérification positive du CC m : arrêt : dépassement de délai décrits ci-dessus relatives à un type' ité de ce choix au 25 Ces procédés peuvent s'appliquer à de nombreux cas de transactions pour de nombreux types de systèmes, tout en restant dans l'esprit de la description faite ci-dessus.

Références 30 SSL, TLS : voir IETF, RFC 2246 JPEG norme ISO/IEC 10918-1 SIM : norme 3GPP TS 31.102 GP: global platform http://www.globalplatform.org/ 35 NFC: Forum: http://www.nfc-forum.org/home TCG forum http://www.trustedcomputinggroup.org/ Les personnes connaissant l'état de l'art apprécieront que les procédés garantissent : 20 - l'intégrité des informations affichées vers un utilisateur, quelconque, de transaction, pour les transactions où l'utilisateur doit faire un choix, Pinté moyen notamment d'un simple code confidentiel.

Claims (7)

1. REVENDICATIONS1. Procédé de sécurisation de l'information comprise dans REVENDICATIONS1. Procédé de sécurisation de l'information comprise dans une image envoyée par un prestataire ou serveur S à un utilisateur U d'un terminal non sûr T, susceptible de contenir un logiciel « malware », cette image contenant des données importantes pour U, et comportant au moins les étapes suivantes Identification de U par S, Emission par S de l'image I+M à destination du terminal T de l'utilisateur LI, ledit procédé étant caractérisé en ce que : L'utilisateur U s'est enregistré auprès du prestataire S dans une phase préalable d'inscription et a fourni des données reconnaissables par lui audit prestataire S, Après identification de U, établissement pars S d'une marque M contenant les données reconnaissables par U, Cette marque M est incorporée à l'image de façon à rendre difficile la séparation de I+M en T et M et donc à rendre impossible pour un malware dans T de substituer I' à I, ou de modifier I en I' Envoi par S de l'image incorporant cette marque à T, Reconnaissance par U de la marque M , Optionnellement, si U dispose d'un terminal T' sûr, une phase d'approbation de la transaction peut suivre : envoi par S d'informations complémentaires à T', accord de l'utilisateur U (b) et réponse T' à S.
2. 2. procédé selon la revendication 1 caractérisé en ce que une police de caractère, définie et dessinée par l'utilisateur lors de la phase d'enregistrement de U auprès de S (ou d'un groupe de prestataires auquel S appartient), est utilisée pour M et optionnellement pour I..
3. 3. procédé selon les revendications 1 et 2 caractérisé en ce que une technique de génération de points communs entre caractères est mise en oeuvre lorsque la marque utilise une description graphique vectorielle de la police de caractère spécifique à l'utilisateur, pour éviter la reconstitution des caractères de la marque un à un par 35 association des segments ayant des sommets communs.
4. 4) proèédé selon le revendication 1 correspondant au cas d'usage « contrôle de droit personnel » où - l'image I est une photographie du titulaire du droit, le serveur Sest dans ce cas l'élément sécurisé SE de T 15 20le terminal T' du contrôleur est relié au SE par un canal sûr où transitent les messages décrits ci-apres, le dit procédé étant caractérisé en ce que la photographie du titulaire est marquée par une donnée calculée à partir de l'identifiant contrôleur transmis par T' vers le SE, et que le contrôleur connaît (donnée invariante) et peut donc vérifier, la photographie du titulaire du droit est affichée sur le terminal T de type smartphone de la personne contrôlée 10 - le contrôleur reçoit sur son terminal les données complémentaires descriptives du droit, envoyées par le SE à T' via le canal sûr le contrôleur a ainsi tous les éléments pour valider le droit contrôlé i. photographie du titulaire ü. marque authentifiant la photographie ni. les données complémentaires descriptives du droit si ces contrôles sont positifs, une approbation peut être envoyé par T'au SE
5. 5) procédé selon les revendications 1. et 4 permettant une implémentation dans le SE, peu consommatrice de ressources, du processus de marquage d'une 20 photographie JPEG, le dit procédé étant caractérisé en ce que : le SE enregistre classiquement la photo, et également pour les portions de photographie marquées, toutes les valeurs possibles de ces portions avec toutes les valeurs de marques, et leurs versions, pour l'envoi de la photographie marquée au terminal, le SE réalise parcours adapté de la photographie enregistrée dans sa mémoire permanente, parcours qui à chaque portion marquée sélectionne la portion marquée de valeur correspondant à la marque .
6. 6) procédé selon la revendication 1 pour le renvoi d'une approbation sur terminal non sécurisé mais muni d'une souris ou d'un écran tactile, caractérisé en ce que : 35 l'image et la marque affichées contiennent tous les caractères numériques qui créent un clavier virtuel dynamique sur lequel l'utilisateur U clique son code confidentiel, - Les clics sur certaines parties de l'image marquée sont transmis sous forme 40 de coordonnées des points cliques au SE qui, connaissant la correspondance position/touche du fait qu'il a généré lui-même l'image et la marque, vérifie le code confidentiel et donc l'approbation de l'utilisateur.
7. 7) procédé selon les revendications 1 et 6 adapté au cas des smartphones, le serveur S est dans ce cas l'élément sécurisé SE du smartphone T la transaction est du type paiement, et se fait entre l'utilisateur U propriétaire du smartphone, et un prestataire ayant un terminal ou un serveur T' sûr avec lequel le smartphone de U communique Un canal sécurisé est établi entre le SE et T' Le dit procédé étant caractérisé en ce que Le SE calcule une image et sa marque I+Nl , puis l'envoie pour affichage au terminal 15 - L'image contient au moins le montant de la transaction - Dans la marque sont rajoutés au moins les caractères nécessaires pour que l'image marquée contienne un clavier virtuel pour saisie du code confidentiel du U La saisie du CC se traduit par l'envoi au SE des coordonnées des clics de 20 l'utilisateur U - Une temporisation dans 'le SE contrôle que le temps entre les étapes d'affichage et de saisie du CC est inférieur à un délai maximum La logique de paiement peut alors se dérouler de façon classique. 25