FR3089080A1 - Sécurisation de l’affichage de données par la réalité augmentée - Google Patents

Abstract

Les données affichées sur un écran en provenance de serveurs peuvent être altérées par des personnes malveillantes. La réalité augmentée permet de sécuriser cet affichage sans modifier les infrastructures existantes. Ainsi, l’utilisateur USER peut continuer d’accéder aux données DATA d’un serveur 10 à l’aide d’un ordinateur 12 en les affichant sur son écran 120. L’utilisateur exécute alors une application sur son téléphone intelligent 40. Cette application acquiert l’image IMG affichée sur l’écran qui comporte la donnée DATAaff et un code d’authentification associé CODEaff ; récupère les donnée et code affichés, de l’image acquise ; vérifie, à l’aide de la donnée récupérée, ledit code récupéré, et affiche, sur l’écran 43 de son téléphone 40, l’image acquise IMG augmentée d’un indicateur IND fonction du résultat de la vérification, éventuellement en remplacement du code d’authentification CODEaff. L’utilisateur est ainsi prévenu automatiquement et en temps réel de la fiabilité des données affichées. Figure pour l’abrégé : Figure 3

Description

Description

Titre de l'invention : Sécurisation de l’affichage de données par la réalité augmentée

Domaine technique [0001] L’invention concerne l’affichage sécurisé de données à un utilisateur.

Technique antérieure [0002] La Figure 1 illustre un système ou schéma 1 classique d’accès à des données DATA par un utilisateur USER.

[0003] Ces données sont stockées sur un serveur applicatif ou de données 10 distant de l’utilisateur USER. Ce dernier y accède à l’aide d’un dispositif d’accès 12, par exemple un ordinateur personnel, via un réseau de communication 14. L’ordinateur personnel 12 comporte un dispositif d’affichage 120, tel un écran. L’ordinateur personnel 12 et le dispositif d’affichage 120 sont généralement reliés par une connexion 121. Lorsque les données sont récupérées par l’ordinateur 12 depuis le serveur distant 10, elles sont affichées localement à l’utilisateur USER sous forme d’image IMG sur l’écran 120.

[0004] On retrouve ce schéma lors d’accès à des services web. A titre illustratif, il peut s’agir de sites Internet commerciaux ou de site Internet administratifs. Il peut aussi s’agir de serveurs d’agrégation de contenus dans un environnement loT (Internet des objets), c’est-à-dire de données ou mesures générées par des objets connectés.

[0005] Dans ce schéma, certaines données doivent être protégées. C’est le cas par exemple de données bancaires, de données transactionnelles, de données d’identification, de mesures confidentielles, etc.

[0006] Le système 1 de la Figure 1 présente certains problèmes de sécurité en raison d’un manque de sécurisation du serveur 10, du dispositif d’accès 12 et du réseau de communication 14. Ainsi une personne mal intentionnée peut intervenir sur l’un de ces éléments pour modifier les données DATA.

[0007] Dans l’exemple montré où DATA = « hello », une personne mal intentionnée 20 peut modifier les données sur le serveur 10 en « hollo » (DATA’) puis éventuellement une autre personne encore modifier ces données sur le réseau 14, sur le dispositif d’accès 12, ou sur la connexion 121 de telle sorte que sont affichées, sur l’écran 120, d’autres données « hillo » (DATA”).

[0008] Ce schéma d’accès à des données est largement répandu. Il n’est donc pas simple de le modifier. Pour autant il existe un besoin de le sécuriser. La sécurisation de données peut concerner l’intégrité des données et/ou l’authenticité des données.

Exposé de l’invention [0009] Dans ce contexte, l’invention propose un procédé d’affichage sécurisé de données, comprenant les étapes suivantes réalisées par un équipement utilisateur :

- acquérir une image affichée par un premier dispositif d’affichage distinct de l’équipement utilisateur, l’image affichant au moins une donnée et un code d’authentification associé,

- récupérer la donnée affichée et le code d’authentification affiché, de l’image acquise,

- vérifier, à l’aide de la donnée récupérée, ledit code d’authentification récupéré, et

- afficher, sur un deuxième dispositif d’affichage de l’équipement utilisateur, la donnée récupérée avec un indicateur fonction du résultat de la vérification.

[0010] Ainsi, l’utilisateur est automatiquement averti, visuellement, de si la donnée a été modifiée compte tenu du code d’authentification fourni. La mise en œuvre d’un équipement utilisateur distinct du premier dispositif d’affichage pour l’affichage final de la donnée permet de conserver le schéma d’accès traditionnel aux données, comme montré en Figure 1.

[0011] Corrélativement, l’invention concerne un équipement utilisateur comprenant un dispositif d’affichage, et un microprocesseur configuré pour réaliser les étapes définies ci-dessus.

[0012] Des caractéristiques optionnelles de modes de réalisation de l’invention sont définies dans les revendications dépendantes.

[0013] Dans un mode de réalisation, l’étape consistant à afficher affiche l’image acquise augmentée de l’indicateur, éventuellement en remplacement du code d’authentification. L’invention s’appuie ainsi sur une solution de réalité augmentée où l’indicateur est ajouté à l’image captée par l’équipement de l’utilisateur. Le code d’authentification n’ayant un rôle que pour la vérification de l’authenticité ou de l’intégrité de la donnée, il peut être supprimé lors de l’affichage de l’image et ainsi être remplacé par l’indicateur. Par exemple, l’indicateur est affiché en superposition d’un affichage de l’image acquise.

[0014] Dans un autre mode de réalisation, le code d’authentification affiché est dans un format lisible de façon optique par une machine. Des formats connus sont par exemple un code-barres, un QR code, des caractères compatibles ROC (reconnaissance optique de caractères, soit « optical character recognition » ou OCR en anglais). Ces formats permettent une automatisation aisée du procédé de sécurisation de l’affichage de la donnée.

[0015] Dans encore un autre mode de réalisation, l’étape consistant à vérifier comprend un calcul cryptographique par l’équipement utilisateur à partir de la donnée récupérée, du code d’authentification récupéré et d’une clé cryptographique en mémoire de l’équipement utilisateur. Cette vérification cryptographique peut ainsi être menée en local par l’équipement utilisateur.

[0016] Dans le cadre d’un schéma cryptographique à clé symétrique, le calcul cryptographique peut comprendre le calcul d’un code de vérification à l’aide de la clé cryptographique et de la donnée récupérée puis la comparaison du code de vérification calculée avec le code d’authentification récupéré. Dans ce cas notamment mais non exclusivement, la clé cryptographique peut être récupérée par l’équipement utilisateur auprès d’un serveur distant. En effet, il est classique que les clés symétriques utilisées par le serveur générant les codes d’authentification changent régulièrement.

[0017] Dans le cadre d’un schéma cryptographique à clés asymétriques, par exemple à base de courbes elliptiques, le code d’authentification récupéré peut être une signature numérique de la donnée récupérée, auquel cas le calcul cryptographique peut comprendre une vérification de la signature numérique formée du code d’authentification récupéré, à l’aide de la donnée récupérée et de la clé cryptographique (clé publique correspondant à celle utilisée par un serveur pour générer le code d’authentification). La clé publique pouvant être connue à l’avance de l’équipement, cette approche peut avantageusement être menée hors ligne.

[0018] En variante à une vérification cryptographique locale, l’étape consistant à vérifier comprend l’envoi de la donnée et du code d’authentification récupérés à un serveur distant (préférablement différent d’un serveur auprès duquel la donnée est directement récupérée par le premier dispositif d’affichage) via un canal de communication sécurisé et la réception, du serveur distant, d’un statut représentatif d’un résultat de vérification du code d’authentification. L’indicateur est alors fonction du statut ainsi obtenu. Cette disposition où les calculs cryptographiques sont réalisés par le serveur distant permet de simplifier les traitements au niveau de l’équipement utilisateur et de sécuriser la vérification (aucune clé n’étant émise hors du serveur distant).

[0019] Dans encore un autre mode de réalisation, l’image affiche une pluralité de données et de codes d’authentification associés, les étapes consistant à récupérer, vérifier et afficher sont réalisées pour chaque donnée et le code d’authentification associé. Ainsi, l’utilisateur peut accéder simultanément à plusieurs données avec des indicateurs de validité (intégrité ou authenticité par exemple) respectifs. Notamment, deux indicateurs affichés peuvent indiquer deux résultats de vérification différents pour deux données. L’utilisateur peut ainsi rapidement identifier les données corrompues dans un affichage multi-données.

[0020] Dans un autre mode de réalisation, l’étape consistant à acquérir l’image affichée comprend l’acquisition optique de l’image par une caméra de l’équipement utilisateur. En effet, l’équipement utilisateur n’est pas relié, par voie de communication, au premier dispositif d’affichage. La caméra permet d’acquérir la donnée affichée par ce dernier. C’est en cela que l’affichage ultérieur, sur le deuxième dispositif d’affichage, de cette image acquise avec l’indicateur constitue de la réalité augmentée.

[0021] L’invention concerne également un produit programme d’ordinateur comprenant des instructions configurées pour une mise en œuvre des étapes du procédé ci-dessus lorsque ledit programme est exécuté sur un ordinateur, ainsi qu’un support tangible comprenant un tel produit programme d’ordinateur.

Brève description des dessins [0022] D'autres particularités et avantages de l'invention apparaîtront encore dans la description ci-après, illustrée par les figures ci-jointes qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif.

[0023] [fig.l]

La Figure 1 illustre un système classique d’accès à des données DATA par un utilisateur USER.

[0024] [fig.2]

La Figure 2 illustre un système d’accès selon des modes de réalisation de l’invention.

[0025] [fig.3]

La Figure 3 montre des étapes générales d’un mode de réalisation de l’invention.

[0026] [fig.4]

La Figure 4 illustre la sécurisation de données lors d’un affichage simultané de plusieurs données, selon les modes de réalisation de l’invention.

[0027] [fig.5]

La Figure 5 illustre la sécurisation de données stockées par un serveur sécurisé sous forme de blockchain, selon les modes de réalisation de l’invention.

Description des modes de réalisation [0028] La Figure 2 illustre un système d’accès 1 selon des modes de réalisation de l’invention.

[0029] Un serveur 30 stocke des données DATA à sécuriser. Le serveur 30 est sécurisé comparativement au serveur 10. La sécurisation peut être mise en œuvre à l’aide d’un module matériel de sécurité (ou HSM pour « hardware security module ») de type élément sécurisé. Un élément sécurisé est notamment un composant ou plate-forme matérielle inviolable (typiquement une puce) utilisée dans un équipement (serveur ici) et capable d’héberger, de façon sûre, des applications et des données en conformité avec des règles et des exigences de sécurité fixées par des autorités de confiance.

[0030] Les données stockées dans le serveur sécurisé 30 peuvent être de natures différentes, données alphanumériques, données image (photo, graphique, ...).

[0031] Dans une application loT, ces données sont par exemple des mesures ou données générées par des capteurs ou objets connectés, ou des données issues d’un traitement de ces mesures. Dans une application bancaire, le serveur 30 est par exemple un serveur bancaire traitant des données bancaires (numéro de compte, montant ou information de transaction, etc.). Dans une application d’administration publique, les données peuvent relever de documents officiels, par exemple des identifiants d’administré.

[0032] Les données peuvent être statiques en mémoire ou être générées dynamiquement (par exemple les mesures d’un capteur loT).

[0033] Le serveur sécurisé 30 génère puis stocke en mémoire, pour chaque donnée DATA à sécuriser, un code d’authentification CODE ou « code MAC ». Préférentiellement le code d’authentification CODE est généré à l’aide d’une clé cryptographique KEY.

[0034] Dans certaines variantes, telles que celle illustrée à la Figure 5 (basée sur une blockchain), le code d’authentification CODE n’est pas lié à la donnée DATA par une clé cryptographique (bien que la donnée DATA elle-même ait pu être générée à l’aide d’une clé cryptographique, comme par exemple dans le cadre de signatures de transactions) : seule une valeur de hachage est calculée à partir de DATA. Le serveur ne stocke alors pas de telle clé cryptographique.

[0035] La clé cryptographique KEY peut être unique et commune à toutes les données stockées sur le serveur 30. En variante, elle peut être dédiée à un type de données, à un type de service auquel se rattachent les données, à une ou plusieurs sources de données, etc. La clé cryptographique KEY peut être une clé symétrique ou la clé privée d’un schéma à clés asymétriques.

[0036] Le code d’authentification CODE peut être de type signature, code MAC (par exemple HMAC) ou valeur de hachage calculée à partir de la donnée DATA correspondante. Des techniques classiques de calcul de signature ou hash utilisant la clé cryptographique KEY sont mises en œuvre tels les algorithmes SHA (pour « Secure Hash Algorithm » en langue anglaise), DS A (pour « Digital Signature Algorithm » en langue anglaise) ou encore RSA (du nom de ses concepteurs Ronald Rivest, Adi Shamir et Leonard Adleman).

[0037] Dans un mode de réalisation visant à protéger des images comme données DATA, l’algorithme de calcul du code d’authentification CODE est robuste à certaines altérations de l’image résultant notamment de l’acquisition 530 (décrite ci-après) de l’image affichée par l’équipement utilisateur 40 décrit par la suite. Des marqueurs typiques d’image, basés notamment sur les techniques connues d’empreinte numérique (ou « fingerprinting » en langue anglaise) peuvent donc être utilisées pour former le code CODE.

[0038] Le code d’authentification CODE est mémorisé par le serveur sécurisé 30 sous forme de séquence numérique non codée ou sous forme codée, par exemple sous forme de code-barres monodimensionnel ou bidimensionnel (QR code) ou toute autre représentation graphique le codant.

[0039] Le serveur applicatif ou de données 10 est connecté au serveur sécurisé 30 par une liaison de communication 32 permettant au serveur 10 de récupérer, périodiquement, en continu ou à la demande, les données DATA à mettre à disposition des utilisateurs ainsi que les codes d’authentification CODE associés. Les données DATA sont stockées avec leurs codes CODE associés.

[0040] Par exemple dans une application loT, les données DATA (mesures de capteurs connectés) sont récupérées en continu par le serveur 10 qui officie en tant qu’agrégateur de contenus loT. Dans une application bancaire, des données DATA d’une transaction bancaire sont récupérées par le serveur marchand 10 du serveur bancaire 30 lorsqu’une transaction est initiée par un utilisateur effectuant un achat sur un site marchand. Dans une application d’administration publique, un serveur 10 de l’administration peut charger périodiquement, chaque nuit par exemple, les données de documents officiels nouvellement créés.

[0041] Le serveur 10 peut coder le code d’authentification CODE sous forme de code-barres monodimensionnel ou bidimensionnel (QR code) ou toute autre représentation graphique le codant, pour le stocker ainsi ou le coder à la volée en réponse à une requête d’un utilisateur pour récupérer la donnée associée.

[0042] Les deux serveurs 10 et 30 peuvent appartenir à un même réseau de communication type WLAN, Internet, 3G, 4G, 5G, ou être interfacés sur différents réseaux interconnectés via une ou des passerelles.

[0043] Le réseau 14 par lequel l’utilisateur USER accède au serveur 10 est typiquement le réseau Internet non sécurisé accédé via un réseau de téléphonie mobile type 3G, 4G, 5G, d’un réseau sans fil WLAN, d’un réseau filaire ADSL, LAN ou d’un réseau optique.

[0044] Le dispositif d’accès 12 peut être un ordinateur personnel, un smartphone, une télévision connectée, un ordinateur embarqué (par exemple dans un véhicule), une station en libre accès (dans le domaine publique) ou tout autre dispositif connecté au réseau 14. Le dispositif d’accès comprend un navigateur web ou tout autre moyen permettant d’accéder au serveur 10 via le réseau 14 et de demander l’accès aux données DATA que celui-ci est amené à stocker.

[0045] Pour une application loT, l’utilisateur USER utilise le navigateur web ou toute autre application pour accéder aux données agrégées par le serveur 10 provenant par exemple d’une flotte d’objets connectés à surveiller. Dans un scénario bancaire, l’utilisateur USER réalise un achat sur un site marchand via son navigateur, lequel achat déclenche une transaction bancaire dont les détails (les données DATA) sont récupérés pour affichage à l’utilisateur avant validation. Dans une application d’administration publique, l’utilisateur USER utilise le navigateur web pour consulter des données personnelles d’administré, par exemple le nombre de points qu’il lui reste sur son permis de conduire à points.

[0046] Selon l’invention, les données DATA ainsi transmises par le serveur 10 au dispositif d’accès 12 sont accompagnées des codes d’authentification CODE associés.

[0047] Ainsi, comme illustré sur la Figure 3 montrant des étapes générales d’un mode de réalisation de l’invention, l’utilisateur USER interagit avec le dispositif d’accès 12 (via une interface classique : clavier, souris, écran tactile, commande vocale, interface embarquée dans un véhicule, etc.) pour accéder 500 à au moins une donnée DATA du serveur 10 via par exemple un navigateur web.

[0048] Cette donnée DATA est ainsi récupérée à l’étape 510, accompagnée du code d’authentification CODE associé, soit sous forme de séquence numérique non codée soit sous forme codée, par exemple un QR code. S’il est reçu sous forme de séquence numérique et qu’un affichage sous forme de code-barres est souhaité, le dispositif d’accès 12 réalise la conversion (étape non représentée) du code CODE sous forme de code-barres ou toute autre représentation graphique le codant, par exemple un QR code.

[0049] A l’étape 520, la donnée et le code d’authentification sont affichés sous forme d’image IMG sur le dispositif d’affichage 120. La donnée ainsi affichée est notée DATA_aff et le code d’authentification affiché est noté CODE_aff.

[0050] De retour à la Figure 2, l’utilisateur USER dispose en outre d’un équipement utilisateur 40 permettant de sécuriser l’affichage des données DATA en s’appuyant par exemple sur la réalité augmentée.

[0051] L’équipement utilisateur 40 comporte notamment :

- un appareil photo ou une caméra conventionnelle 41 ou tout moyen optique équivalent pour acquérir l’image IMG affichée sur l’écran 120,

- une interface de communication 42 avec le serveur sécurisé 30. Il peut s’agir d’une liaison dédiée et sécurisée. En variante, il peut s’agir d’une interface sur un réseau de communication classique (non sécurisé) sur lequel l’interface 42 et le serveur 30 établissent un canal de communication sécurisé 50 à l’aide de techniques connues,

- un dispositif d’affichage 43 permettant à l’utilisateur USER de visualiser les données DATA de façon sécurisée, en s’appuyant notamment sur de la réalité augmentée. Le dispositif d’affichage 43 peut être directement intégré à l’équipement utilisateur 40 ou être relié à celui-ci par une liaison dédiée (par exemple HDMI, VGA, etc.),

- une mémoire 44 stockant optionnellement une clé cryptographique KEY’ et des instructions de code informatique pour une mise en œuvre de l’invention, et

- un processeur 45 exécutant ces instructions.

[0052] D’autres composants classiques de l’équipement utilisateur 40 ne sont pas illustrés pour simplifier la représentation, par exemple une mémoire vive, une interface uti8 lisateur (clavier, souris, micro, haut-parleur, etc.), une source d’alimentation, etc.

[0053] L’équipement utilisateur 40 peut prendre la forme d’un téléphone intelligent (ou smartphone), d’une tablette ou d’un ordinateur portable, qui de façon classique sont déjà équipés d’une caméra 41, d’une ou plusieurs interfaces 42 sur un réseau de téléphonie mobile et/ou sur un réseau Wifi (nom commercial), d’un écran d’affichage 43 et de mémoires 44 et processeur 45.

[0054] En variante, l’utilisateur USER peut utiliser des lunettes intelligentes, par exemple des lunettes intelligentes avec une réalité augmentée, par exemple des Google Glasses (nom commercial). De telles lunettes présentent les composants évoqués ci-dessus.

[0055] Selon le schéma cryptographique utilisé, la clé cryptographique KEY’ peut être la clé symétrique KEY stockée par le serveur 30 ou être la clé publique correspondant à la clé privée KEY stockée par le serveur 30. La clé KEY’ peut être stockée dans tout type de mémoire 44. De préférence s’il s’agit de la clé symétrique KEY, elle est stockée dans une mémoire sécurisée de l’équipement 40, par exemple un élément sécurisé.

[0056] La clé symétrique est de préférence récupérée par l’équipement 40 auprès du serveur 30 lorsqu’une vérification du code d’authentification CODE est réalisée. En effet, la clé symétrique KEY utilisée par le serveur 30 pour générer les codes d’authentification CODE est renouvelée régulièrement pour des raisons de sécurité. La clé publique dans le cas d’un schéma à clés asymétriques peut être stockée à long terme dans l’équipement 40 ce qui permet des vérifications selon l’invention même en mode non connecté.

[0057] Comme il sera décrit par la suite en lien avec la Figure 5, l’équipement utilisateur 40 peut ne contenir aucune clé KEY’ lorsque les calculs de vérification du code d’authentification CODE sont réalisés par le serveur 30 lui-même ou ne mettent pas en œuvre de clé cryptographique (exemple de la blockchain).

[0058] De retour à la Figure 3, l’utilisateur USER peut lancer, sur son équipement 40, une application dédiée aux fins d’une mise en œuvre de l’invention.

[0059] A l’étape 530, il acquiert, à l’aide de l’équipement 40, l’image IMG affichée sur l’écran 120. Il peut s’agir d’une simple photographie prise par l’appareil photo ou caméra 41, c’est-à-dire d’une acquisition optique. Il n’y a ainsi aucun besoin de connecter l’équipement 40 au dispositif d’accès 12 (et son écran 120). Ces deux dispositifs sont ainsi distincts.

[0060] A l’étape 540, l’image acquise est traitée pour récupérer la donnée DATA_aff affichée et le code d’authentification CODE,_[f affiché. Pour faciliter la récupération du code CODE_aff, ce dernier peut être affiché dans un format lisible de façon optique par une machine, typiquement une séquence de caractères (chiffres) compatible ROC, un codebarres ou QR code.

[0061] Des traitements classiques de l’image permettent la récupération de ces deux in formations : reconnaissance optique de caractères pour une données DATA_aff et un code CODE_aff sous formes alphanumériques ; décodage de code-barres lorsque CODE _aff lorsque ce dernier est sous forme de code-barres ; simple délimitation d’une image lorsque DATA_aff est une image, etc.

[0062] A l’étape 550, le code CODE_aff est vérifié à l’aide de DATA_aff.

[0063] Il s’agit de déterminer si l’un ou l’autre ou les deux ont été modifiés depuis leur génération par le serveur sécurisé 30. La relation liant CODE_aff à DATA_aff doit être la même que celle reliant CODE à DATA au niveau du serveur 30.

[0064] Aussi, lors de cette étape, le schéma cryptographique ou tout autre schéma (par exemple blockchain) utilisé par le serveur 30 est utilisé à nouveau. Il peut s’agir de calculer un code d’authentification CODE_verif à partir de DATA_aff et de la clé symétrique KEY’ puis le comparer à CODE_aff. En variante, il peut s’agir de vérifier la signature CODE_aff à l’aide de la clé asymétrique KEY’. Par exemple, dans le cas d’une signature à base de clés RSA, il peut s’agir de décoder la signature CODE_aff à l’aide de la clé asymétrique KEY’ pour obtenir une empreinte (signature décodée) SIGN_verif puis comparer celle-ci avec une empreinte SIGN_aff générée à partir de DATA_aff [0065] Ces calculs cryptographiques et la comparaison peuvent être réalisés localement par l’équipement utilisateur 40. Dans ce cas, l’étape de vérification 550 comprend un calcul cryptographique par l’équipement utilisateur à partir de la donnée DATA_aff, du code d’authentification CODE_a[[ et de la clé cryptographique KEY’ en mémoire de l’équipement 40.

[0066] L’équipement 40 obtient donc la clé cryptographique KEY’ à l’étape 551. La clé KEY’ est récupérée de la mémoire 44. En variante, elle est obtenue auprès du serveur 30 via la liaison de communication 50.

[0067] Une donnée ou empreinte de vérification, par exemple CODE_verif ou SIGN_verif, est alors générée à l’étape 552.

[0068] Une donnée ou empreinte de référence pour la vérification est obtenue à l’étape 553. Par exemple DATA_aff est récupérée dans le cas du schéma à clé symétrique ou SIGN_aff est calculée dans le cas du schéma à clés symétriques.

[0069] La donnée de vérification est alors comparée à la donnée de référence pour la vérification, lors de l’étape 554. Le résultat de vérification, par exemple un booléen, est ainsi émis à l’étape 555. Le booléen est par conséquent représentatif d’une donnée DATA_aff intègre et/ou authentifiée (vérification positive, booléen égal à 1 par exemple) ou d’une donnée DATA_aff et/ou code CODE_aff corrompue ou non authentifiée (vérification négative, booléen égal à 0 par exemple).

[0070] Dans une variante, les calculs de vérification (par exemple cryptographiques) et la comparaison sont déportés sur le serveur distant 30. C’est le cas de l’exemple en Figure 5 pour le cas de la blockchain sans clé cryptographique. Dans ce cas, l’équipement utilisateur 40 ne fait, lors de l’étape de vérification 550, qu’envoyer 556 la donnée DATA_aff et le code d’authentification CODE_aff récupérés au serveur distant 30 via le canal de communication sécurisé 50, puis recevoir 557, du serveur distant 30, un statut représentatif d’un résultat de vérification du code d’authentification. Le statut est typiquement un booléen comme évoqué ci-dessus : booléen égal à 1 en cas de vérification positive par le serveur 30 et booléen égal à 0 en cas de vérification négative par le serveur 30.

[0071] Alternativement, le serveur 30 peut ne pas réaliser de calculs cryptographiques, mais simplement comparer les éléments DATA_aff et CC)DE_a[[ reçus aux éléments DATA et CODE qu’il stocke (et a générés). Le cas échéant, un identifiant unique associés à ces éléments peut être affiché sur l’écran 120, acquis par l’équipement 40 et envoyé au serveur 30 pour permettre à ce dernier de retrouver, dans ses mémoires, un enregistrement {DATA, CODE] à partir duquel faire les comparaisons.

[0072] A l’issue de l’étape 550 de vérification, l’équipement utilisateur 40 dispose du résultat de vérification pour la donnée affichée, typiquement le booléen mis à 1 ou 0.

[0073] A l’étape 560, une image IMG_fin à afficher sur l’écran 43 est générée par l’équipement 40 à partir de la donnée DATA_aff ou l’image IMG acquise et du résultat de la vérification, à savoir le booléen.

[0074] L’image IMG_fin générée comporte la donnée DATA_aff accompagnée d’un indicateur IND fonction du résultat de la vérification. L’indicateur est ainsi graphique, c’est-à-dire visuel.

[0075] Il peut s’agir d’un indicateur dont la couleur varie en fonction du résultat de la vérification : rouge si le booléen vaut 0, vert s’il vaut 1 ; et/ou dont la forme varie en fonction du résultat de la vérification : une croix si le booléen vaut 0, une coche (ou « tick ») s’il vaut 1. Dans l’exemple de la Figure 2, l’indicateur est un encadré entourant la donnée DATA_aff et dont la couleur est fonction du booléen.

[0076] De préférence, l’image IMG_fin comprend l’image IMG acquise augmentée de l’indicateur. Ainsi, la solution s’appuie sur la réalité augmentée : ce qui est capturé par la caméra 41 est affiché, augmenté d’une information supplémentaire, ici l’indicateur. L’indicateur peut ainsi être affiché en superposition de l’image IMG acquise.

[0077] Le code d’authentification CODE_aff n’ayant plus d’utilité en vue de l’affichage final à l’utilisateur, il peut être supprimé dans l’image IMG_fin. Par exemple, l’indicateur est affiché en remplacement du code d’authentification, typiquement par superposition sans transparence sur la zone de l’image comportant le code. Cela permet de ne pas avoir à reconstituer l’image sur la zone occupée par l’indicateur. A titre illustratif, le carré occupé par un code CODE_aff de type QR code peut être remplacé par un carré plein comprenant une croix rouge (si booléen = 0) ou une coche verte (si booléen =1).

[0078] Une fois l’image IMG_fin générée, celle-ci est affichée à l’utilisateur USER sur l’écran à l’étape 570. Grâce à l’indicateur affiché, l’utilisateur sait si les données DATA_aff affichées sont de confiance ou pas. L’invention permet ainsi de sécuriser l’affichage des données DATA à l’utilisateur.

[0079] Dans une application loT, l’utilisateur USER peut ainsi visualiser des informations sécurisées venant de divers objets. Dans une application bancaire, le schéma proposé peut être utilisé pour valider une transaction en remplacement du mécanisme « 3-D Secure » (nom commercial) : lors que le site marchand (serveur 10) redirige sa page vers une page de la banque, l’utilisateur USER, au lieu d’entrer un code reçu par SMS, peut capturer, à l’aide de son téléphone mobile 40, l’image IMG de cette page affichée sur l’écran 120 qui est augmentée d’un code d’authentification. Une application sur le téléphone mobile 40 permet alors de vérifier le code d’authentification et les informations de transaction sur la page avant que l’utilisateur ne valide la transaction. Eventuellement, le téléphone mobile 40 peut contacter le serveur 30 de la banque (par exemple pour récupérer une clé cryptographique). Dans une application d’administration publique, l’invention permet de vérifier toute information ou document administratif délivré à l’utilisateur via un serveur non sécurisé 10.

[0080] Le procédé de la Figure 3 ne requiert pas d’intervention de l’utilisateur à partir du moment où il dispose la caméra 41 devant l’écran 120. L’utilisateur peut ainsi être instantanément prévenu de la validité de la ou des données affichées sur l’écran 120.

[0081] En outre, ce procédé ne nécessite pas d’adaptation de l’environnement classique des utilisateurs, à savoir le serveur 10 et le dispositif d’accès 12. La sécurisation des données et la vérification de celles-ci sont en effet effectuées aux deux extrémités de cet environnement classique.

[0082] Le procédé de la Figure 3 est de préférence réalisé en temps réel ou quasi-temps réel sur des images acquises continuellement par la caméra 41. Dans le cas où le service auquel l’utilisateur accède via le dispositif d’accès 12 propose un affichage dynamique de données DATA sur l’écran 120 (par exemple des mesures qui varient ou se renouvelle dans le temps, des transactions bancaires successives, etc.), le procédé permet ainsi à l’utilisateur de visualiser ces données successives avec une indication en temps réel de leur validité.

[0083] La Figure 4 illustre le cas d’un affichage simultané de plusieurs données DATAI, DATA2 et DAT A3. Des codes d’authentification CODEI, CODE2, CODE3 leur sont respectivement associés par le serveur 30. L’image IMG sur l’écran 120 affiche ainsi une pluralité de données DATAl_aff, DATA2_aff et DATA3_aff et de codes d’authentification associés CODEl_aff, CODE2_aff, CODE3_aff. L’affichage proposé garantit une association indiscutable entre chaque donnée affichée et le code correspondant. Dans l’exemple de la figure, l’affichage sous forme de tableau rend indiscutable le lien entre la donnée de la ligne et le code de la même ligne du tableau.

[0084] Le procédé de la Figure 3 est mis en œuvre simultanément pour chacune des données affichées DATAl_aff, DATA2_aff et DATA3_aff et codes affichés CODE 1 CODE2_aff, CODE3_a[[. L’altération de ces informations étant indépendante de l’une à l’autre, les vérifications 550 peuvent ainsi conduire à ce que deux indicateurs affichés indiquent deux résultats de vérification différents pour deux données. Dans l’exemple de la figure, les données DATA l_a[[ et DATA2_aff sont considérées comme valides (indicateurs INDi et IND₂ étant des coches) alors que la donnée DATA3_aff (indicateur IND₃ étant une croix) est indiquée comme corrompue ou non authentifiée.

[0085] La Figure 5 illustre le cas où les données DATA sont générées et stockées (action numérotée 1 dans un disque noir) par le serveur 30 sous forme de blockchain. Une première donnée DATAI est stockée et protégée par un bloc de contrôle CODE1 (type valeur de hachage) qui dépend de DATAI et d’une valeur de hachage précédente HASH. Une deuxième donnée DATA2 est stockée et protégée par un bloc de contrôle CODE2 qui dépend de DATA2 et d’une valeur de hachage précédente, par exemple CODE1. Une troisième donnée DAT A3 est stockée et protégée par un bloc de contrôle CODE3 qui dépend de DATA3 et d’une valeur de hachage précédente, par exemple CODE2. Dans cet exemple basé sur la blockchain, les codes d’authentifications CODE ne sont pas liés à leurs données DATA respectives par des clés cryptographiques : il s’agit uniquement de valeurs de hachage.

[0086] Les données DATAI, DATA2, DATA3 sont ici représentées par de simples valeurs. Elles peuvent cependant être plus complexe et notamment comprendre des valeurs (par exemple signatures) calculées par des algorithmes cryptographiques.

[0087] Dans l’exemple est rajoutée une quatrième donnée DATA4 consistant en un tableau formé des première à troisième données. La quatrième donnée DATA4 est stockée et protégée par un bloc de contrôle CODE4 qui dépend de DAT A4 et d’une valeur de hachage précédente, par exemple CODE3. Cette quatrième donnée DAT A4 peut être générée (action numérotée 2) à la demande, par exemple lorsque le serveur 10 veut récupérer les données DATAI à DATA3 et indique souhaiter les rendre accessibles sous un format particulier, ici sous forme de tableau.

[0088] Les données DATAI à DATA4 et leurs codes d’authentification associés CODE1 à CODE4 sont récupérés par le serveur 10 (action numérotée 3) et ainsi rendus disponibles à l’utilisateur USER.

[0089] Ce dernier y accède donc (action numérotée 4 - étapes 500 et 510). Dans l’exemple de la figure, la donnée DATA4_aff est affichée (action numérotée 5 - étape 520) sur l’écran 120 avec le code CODE4_aff. Ces informations sont récupérées (action numérotée 6 - étapes 530-540) par l’équipement 40. La vérification 550 consiste à envoyer 556 ces informations au serveur 30 via la liaison sécurisée 50 (action numérotée 7). En effet, la vérification du code d’authentification ne peut être effectuée qu’en connaissance de la valeur de hachage précédente pour la donnée considérée (ici la valeur de hachage C0DE3). Dans ce cas, l’équipement 40 ne comporte aucune clé cryptographique. Bien entendu en variante aux fins de réaliser les calculs de vérification dans l’équipement 40, cette valeur de hachage précédente peut être récupérée par l’équipement 40 auprès du serveur 30 à l’aide d’un identifiant de la donnée DATA4_aff à vérifier.

[0090] Le serveur 30 vérifie (action numérotée 8) donc les informations DATA4_aff et CODE4_aff reçues. Notamment il calcule un code de vérification CODE4_verif à partir de CODE3 et de DATA4_aff et compare celui-ci à CODE4_aff. Le résultat de la vérification (booléen) est alors envoyé à l’équipement 40 (action numérotée 9 - étape 557) qui peut afficher (action numérotée 10 - étape 570) la donnée DATA4_aff avec un indicateur IND sur la validité (intégrité et/ou authenticité) de cette donnée. Dans l’exemple de la figure, l’indicateur IND est explosé en trois indicateurs identiques associés à chacune des données composant la donnée DATA4_a[[.

[0091] Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

[0092] Bien que les explications ci-dessus s’appuient sur l’affichage visible par l’utilisateur USER du code d’authentification CODE sur l’écran 120, il pourrait être envisagé d’intégrer le code d’authentification de façon invisible pour l’utilisateur. Typiquement, des techniques connues de tatouage numérique (ou « watermarking » en langue anglaise). Des traitements ad hoc seront alors réalisés par l’équipement 40 lors de l’étape 540 pour récupérer le code d’authentification CODE depuis l’image IMG acquise.

Claims (1)

1. Revendications [Revendication 1] Procédé d’affichage sécurisé de données (DATA), comprenant les étapes suivantes réalisées par un équipement utilisateur (40) : - acquérir (530) une image (IMG) affichée par un premier dispositif d’affichage (120) distinct de l’équipement utilisateur (40), l’image affichant au moins une donnée (DATA_aff) et un code d’authentification associé (CODE_aff), - récupérer (540) la donnée affichée et le code d’authentification affiché, de l’image acquise, - vérifier (550), à l’aide de la donnée récupérée, ledit code d’authentification récupéré, et - afficher (570), sur un deuxième dispositif d’affichage (43) de l’équipement utilisateur (40), la donnée récupérée (DATA_aff) avec un indicateur (IND) fonction du résultat de la vérification. [Revendication 2] Procédé selon la revendication 1, dans lequel l’étape (570) consistant à afficher affiche l’image acquise (IMG) augmentée de l’indicateur (IND), éventuellement en remplacement du code d’authentification (CODE_aff). [Revendication 3] Procédé selon la revendication 2, dans lequel l’indicateur (IND) est affiché en superposition d’un affichage de l’image acquise (IMG). [Revendication 4] Procédé selon l’une des revendications 1 à 3, dans lequel le code d’authentification affiché (CODE_aff) est dans un format lisible de façon optique par une machine. [Revendication 5] Procédé selon l’une des revendications 1 à 4, dans lequel l’étape (550) consistant à vérifier comprend un calcul cryptographique (552) par l’équipement utilisateur (40) à partir de la donnée récupérée (DATA_aff), du code d’authentification récupéré (CODE_aff) et d’une clé cryptographique (KEY’) en mémoire de l’équipement utilisateur. [Revendication 6] Procédé selon la revendication 5, dans lequel la clé cryptographique (KEY’) est récupérée par l’équipement utilisateur (40) auprès d’un serveur distant (30). [Revendication 7] Procédé selon l’une des revendications 1 à 4, dans lequel l’étape (550) consistant à vérifier comprend l’envoi (556) de la donnée (DATA_aff) et du code d’authentification (CODE_aff) récupérés à un serveur distant (30) via un canal de communication sécurisé (50) et la réception (557), du serveur distant (30), d’un statut représentatif d’un résultat de vérification du code d’authentification. [Revendication 8] Procédé selon l’une des revendications 1 à 7, dans lequel l’image (IMG)

   affiche une pluralité de données (DATAl_aff, DATA2_aff, DATA3_a[[, DATA4_aff) et de codes d’authentification associés (CODEl_aff, C0DE2_aff, C0DE3_aff, C0DE4_aff), et les étapes consistant à récupérer (540), vérifier (550) et afficher (570) sont réalisées pour chaque donnée et le code d’authentification associé, et deux indicateurs affichés (INDI, IND2, IND3) indiquent deux résultats de vérification différents pour deux données.

   [Revendication 9] Procédé selon l’une des revendications 1 à 8, dans lequel l’étape (530) consistant à acquérir l’image affichée (IMG) comprend l’acquisition optique de l’image par une caméra (41) de l’équipement utilisateur (40).

   [Revendication 10] Equipement utilisateur (40) comprenant un dispositif d’affichage (43), un module (41) d’acquisition d’une image (IMG) affichée par un premier dispositif d’affichage (120) distinct de l’équipement utilisateur (40), l’image affichant au moins une donnée (DATA_aff) et un code d’authentification associé (CODE_aff), et un microprocesseur (45) configuré pour réaliser les étapes suivantes :

   - récupérer la donnée affichée et le code d’authentification affiché, de l’image acquise,

   - vérifier, à l’aide de la donnée récupérée, ledit code d’authentification récupéré, et

   - afficher, sur le dispositif d’affichage (43) de l’équipement utilisateur (40), la donnée récupérée (DATA_aff) avec un indicateur (IND) fonction du résultat de la vérification.