Brevet FR3099974A1 — publié le 20210219

Description Titre de l'invention : PROCÉDÉ DE TRANSMISSION D'UNE INFORMATION NUMÉRIQUE Domaine technique [0001] La présente invention concerne le domaine des services en ligne accessibles par le réseau Internet. L'accès à des sites ou services distants se fait par l'établissement d'une session de communication entre un équipement connecté, par exemple un ordinateur, une tablette ou un téléphone cellulaire, et un serveur dont l'utilisateur connaît l'adresse et la saisit dans un navigateur, ou auquel l'utilisateur accède via un moteur de recherche ou encore par un lien transmis par un message électronique ou apparaissant sur la page d'un autre site. [0002] A partir de la page visualisée, il procède ensuite à des transactions, qui peuvent concerner des questions sensibles, telles que la fourniture d'informations confidentielles, d'acquisition de produits et/ou de services, d'engagements ou le paiement en ligne. [0003] Le développement de ces moyens transactionnels a malheureusement entraîné la pro- lifération de fraudes. Une fraude répandue est appelée hameçonnage («phishing»). Cette forme de piratage informatique est utilisée par des fraudeurs pour tenter de récupérer des informations (généralement bancaires) auprès d'internautes, en dupant les internautes par le biais d'un courrier électronique semblant provenir d'une entreprise de confiance, typiquement une banque ou un site de commerce. 100041 Le mail envoyé par ces pirates usurpe l'identité d'une entreprise (banque, site de commerce électronique, etc.) et les invite à se connecter en ligne par le biais d'un lien hypertexte et de mettre à jour des informations les concernant dans un formulaire d'une page web factice, copie conforme du site original, en prétextant par exemple une mise à jour du service, une intervention du support technique, etc. 100051 Ainsi, par le biais du formulaire, les pirates réussissent à obtenir les identifiants et mots de passe des internautes ou bien des données personnelles ou bancaires (numéro de client, numéro de compte en banque, etc.). 100061 Grâce à ces données les pirates sont capables de transférer directement l'argent sur un autre compte ou bien d'obtenir ultérieurement les données nécessaires en utilisant intelligemment les données personnelles ainsi collectées. 100071 Certains sites e-commerce se disent revendeurs d'un ou de plusieurs produits d'une marque/services. L'internaute qui procède à la transaction ne peut constater l'authenticité du produit qu'à sa livraison. ETAT DE LA TECHNIQUE ET INCONVENIENTS 2 100081 Les solutions basées sur la consultation d'une liste de sites d'hameçonnage ne sont pas totalement efficaces car elles ne prennent pas en compte les sites les plus récents qui n'ont pas encore été qualifiés et enregistrés dans la base, et les cyberfraudeurs ont développé des stratégies de changements très rapides des adresses des sites d'hameçonnage. [0009] Pour contrer ces types de fraudes on connaît dans l'état de la technique le brevet français FR3045187B1. Ce brevet apporte une réponse efficace aux problèmes susvisés, niais présente une faille de sécurité, car les données provenant du serveur de confiance transitent par le serveur marchand. Pour un déploiement avec un grand nombre de serveurs marchands, il est difficile de garantir que tous présenteront une robustesse suffisante à des attaques informatiques; et en cas d'accès au code transmis par le serveur de sécurité, l'ensemble du processus peut être corrompu. Or l'opérateur du serveur de sécurité ne dispose généralement d'aucun moyen lui permettant de vérifier la sécurité des serveurs marchands qui sont ses clients. SOLUTION APPORTEE L'INVENTION [0010] Afin de remédier à ces inconvénients, la présente invention propose selon son acception la plus générale un procédé de communication sécurisé entre au moins un serveur informatique et des utilisateurs disposant chacun d'au moins un système informatique connecté et comportant une étape initiale d'enregistrement d'un identifiant unique dudit serveur informatique dans la mémoire d'un serveur informatique de confiance, le procédé se communication étant caractérisé en cc que ledit système informatique connecté présente un premier mode de communication numérique et un second mode de communication numérique, et en cc que ledit procédé comporte en outre les étapes suivantes : [0011] Des étapes initiales comprenant : - La transmission d'une application ASC au système informatique connecté ; - Ladite application ASC étant installée sur ledit système informatique connecté, son exécution commandant l'ouverture automatique d'une session informatique avec ledit serveur de confiance selon ledit second mode de communication numérique ; Des étapes de validation d'une information présentée sur ledit système connecté comprenant : une opération d'ouverture d'une session de communication par ledit système connecté avec un serveur informatique ; une opération d'ouverture d'une session de communication sécurisée par ledit serveur informatique avec ledit serveur de confiance, et de transmission par ledit serveur informatique d'un identifiant dudit - - 3 système connecté ; - une opération de calcul par ledit serveur de confiance d'un code horodaté associé à ladite clé ; - une opération de transmission dudit code horodaté par le serveur de confiance audit système connecté correspondant à l'identifiant préalablement transmis par ledit serveur, via un premier protocole de communication ; - une opération d'acquisition dudit code horodaté par ledit système connecté selon un premier protocole, et - d'ouverture d'une session de communication par ledit système connecté selon un second protocole, avec ledit serveur de confiance par l'intermédiaire de ladite application préalablement chargée et de transmission dudit code acquis ; - une opération de vérification de la conformité du code transmis par ledit système connecté ; - une opération de transmission audit système connecté par ledit serveur de confiance d'un message numérique de validation comprenant un indicateur de conformité du code et une information relative au serveur associé au code validé. [0012] Avantageusement, le serveur procède à une vérification de l'accréditation de l'identifiant du système connecté et/ou de l'utilisateur et de transmission dudit identifiant au serveur de confiance dans le cas où cette vérification est positive. [0013] Selon une première variante, le système connecté est constitué de deux équipements fonctionnant avec des protocoles de communication différents. [0014] Selon une deuxième variante, le système connecté est constitué d'un seul équipement fonctionnant avec des protocoles de communication différents. [0015] Avantageusement, ledit message numérique est envoyé par un serveur tiers. [0016] Selon un mode de mise en oeuvre particulier, ledit message numérique envoyé par un serveur tiers en cas de conformité du code contient un lien hypertexte dont l'activation commande l'ouverture d'une session avec un serveur de paiement ou autre, pour la réalisation d'une transaction sécurisée. [0017] DESCRIPTION DETAILLEE D'UN EXEMPLE NON LIMITATIF DE L'INVENTION [0018] La présente invention sera mieux décrite à la lecture de la description qui suit, concernant un exemple non limitatif de réalisation se référant aux dessins annexés où: [0019] [Fig. 1] la figure 1 représente une vue schématique d'un premier mode de communication du système d'information de l'utilisateur ; [Fig. 2] la figure 2 représente une vue schématique d'un deuxième mode de communication du système d'information de l'utilisateur ; [Fig. 3] la figure 3 représente une vue schématique d'un troisième mode de communication du système d'information de l'utilisateur ; [Fig. 4] la figure 4 représente une vue schématique d'un quatrième mode de communication du système d'information de l'utilisateur ; [Fig. 5] la figure 5 représente le logigramme de l'étape d'installation de l'application de sécurité pour la mise en oeuvre de l'invention ; [Fig. 6] la figure 6 représente le logigramme de l'étape de vérification de la conformité d'un site ; [Fig. 7] la figure 7 représente le logigramme de l'étape de vérification selon une première variante de réalisation ; [Fig. 8] la figure 8 représente le logigramme de l'étape de vérification selon une deuxième variante de réalisation ; [Fig. 9] la figure 9 représente le logigramme de l'étape de vérification selon une troisième variante de réalisation. [0020] Architecture générale [0021] Le système met en oeuvre un serveur de confiance (10) comportant une mémoire pour l'enregistrement de serveurs transactionnels (20) vérifiés. [0022] L'étape d'enregistrement (étape 1) (figure 5) est réalisée par l'ouverture d'une session entre un serveur marchand (20) et le serveur de confiance (10) attribuant au serveur marchand (20) un identifiant de session et l'enregistrement des informations relatives au site dont la sécurisation est attendue. [0023] Ces informations contiennent notamment un identifiant du site, par exemple l'adresse URL racine, l'adresse physique Mac (Media Access Controll), l'adresse IP et/ou toute autre information d'identification du site. [0024] Préalablement à l'enregistrement, une vérification de l'authenticité de ces in- formations est effectuée de manière connue. Le serveur de confiance (10) calcule ensuite une clé unique ou une clé de chiffrement unique, associée à l'identifiant du site validé. Cette clé est enregistrée sur le serveur marchand (20). [0025] On entend au sens du présent brevet par «serveur marchand» le serveur dont les contenus doivent être certifiés. Il peut s'agir d'un serveur de commerce électronique, mais aussi d'un serveur d'information, et plus généralement d'un serveur d'un contenu que l'éditeur souhaite certifier pour que l'utilisateur final puisse vérifier qu'il consulte le site officiel, et non pas un site clandestin imitant le site officiel pour se livrer par exemple à des malveillances de type phishing. [0026] Équipement des utilisateurs [0027] Les utilisateurs utilisent un système informatique connecté qui est constitué: [0028] Soit de deux équipements connectés distincts, par exemple - un ordinateur ou une tablette utilisée en tant qu'ordinateur (30) communiquant avec l'internat via un protocole TCP/IP, notamment pour les échanges avec les serveurs marchands (20) - un téléphone intelligent ou une tablette (31) communicant avec le serveur de confiance (10) via un réseau GSM et un protocole tel que http ou push. [0029] Le système peut comporter des moyens GPS pour la géolocalisation de la distance entre PC et téléphone et ainsi fournir un moyen pour détecter l'éloignement anormal entre un téléphone et un PC dans le cas d'une utilisation en pairage. [0030] Dans ce cas, les deux équipements disposent de moyens d'échanges d'information, par radiofréquence (par exemple en Bluctooth ou NFC) ou sonore, ou optique (par exemple par affichage d'un code matriciel sur le premier équipement et lecture de cc code par la caméra du second équipement, ou lecture visuelle d'un code alphanumérique avec saisie manuelle sur le second équipement, ou encore une signature vocale et plus généralement tout moyen d'authentification. [0031] Soit un seul équipement connecté comportant deux modes de communication, par exemple: - Un protocole TCP/IP, notamment pour les échanges avec les serveurs marchands (20) - Un protocole tel que HTTP ou PUSH pour les échanges avec le serveur de confiance SC (10) - Éventuellement sur le même canal internet. - Dans ce cas, une mémoire partagée permet d'enregistrer les données provenant de l'une des voies, et de les traiter avec le processeur pour commander une action sur la deuxième voie de communication. [0032] La figure 1 représente un premier mode de connectivité où le système connecté de l'utilisateur est constitué de deux équipements distincts, un ordinateur (30) et un téléphone intelligent (31). [0033] Selon cette première variante, chacun des équipements (30, 31) dispose de son propre mode de communication. [0034] L'ordinateur (30) communique avec l'Internet selon le protocole TCP/IP via une box (35) à laquelle il est relié par voie filaire ou en WIFI. [0035] Le téléphone intelligent (31) communique avec l'Internet par un réseau xG, par exemple 4G ou 5G, via un protocole HTTPS ou PUSH. [0036] Cette solution offre le plus de sécurité car chaque mode de communication est to- talement séparé, en termes de protocole et de nombre d'équipement. [0037] La figure 2 illustre une situation hybride, domestique, où le téléphone intelligence (31) utilise la même box (35) à laquelle il se connecte, en WIFI ou en LIFI par 6 exemple, pour accéder à l'Internet avec un protocole HTTPS ou PUSH. [0038] La figure 3 illustre une autre situation hybride, itinérante, où le téléphone intelligent (31) communique avec 'Internet via un réseau xG avec un protocole HTTPS ou PUSH, et l'ordinateur (30) accède à l'internet via une liaison WIFI, USB ou Bluetooth avec le téléphone. [0039] La figure 4 illustre un cas d'usage différent, où le système informatique de l'utilisateur se réduit à un seul équipement, par exemple un téléphone intelligent (31) connecté à l'internet via le réseau xG, par exemple 4G ou Wifi, et utilisant deux protocoles différents, TCP/IP pour les échanges via le navigateur avec le site marchand et HTTPS ou PUSH pour les autres communications. [0040] Chargement de l'application ASC [0041] Pour permettre à un utilisateur d'utiliser la solution de sécurisation proposée par l'invention, il commence par charger sur son système informatique connecté un fichier ASC contenant un code informatique exécutable, comme cela est illustré sur la figure 5. [0042] Cette application est installée sur l'un des équipements, en l'occurrence le téléphone intelligent ou la tablette ou la montre connectée ou autre mode intelligent mobile de communication (31) de l'utilisateur par téléchargement soit (étape 2.1.) depuis une plateforme de téléchargement d'application (12), soit (étape 2.2) depuis le serveur de confiance (10). Lors de cette opération, le serveur de confiance (10) peut optionnellement prévoir un échange de messages pour l'enregistrement d'informations spécifiques à l'utilisateur, et transmettre un identifiant de session ou de pairage (en anglais «cookie») ou plus généralement une variable qui sera enregistré sur le terminal connecté (31) de l'utilisateur. [0043] Cette application peut aussi être installée directement sur un équipement unique (30). [0044] Vérification de l'authenticité d'un site [0045] La figure 6 illustre un exemple de logigramme de la vérification de l'authenticité d'un site. [0046] Lorsque l'utilisateur se connecte à un site (20) avec un premier équipement connecté (30), par exemple par l'intermédiaire d'un moteur de recherche ou de la saisie de l'adresse dans la barre du navigateur ou encore par l'activation d'un lien hypertexte, il ouvre de façon habituelle une session (étape 3) avec le serveur (20) hébergeant le site correspondant à l'adresse considérée selon un protocole TCP/IP. [0047] S'il s'agit d'un site préalablement enregistré sur le serveur de confiance (10), le serveur (20) ouvre une session (étape 4) via la clé qui lui a été attribuée par le serveur de confiance (10) lors de l'enregistrement initial. [0048] Le serveur de confiance (10) calcule alors un code numérique horodaté, qui est transmis (étape 5), non pas au serveur (20), mais directement au premier équipement 7 connecté (30). Ce code est indépendant de la page du serveur (20). [0049] Ce code peut être affiché sous la forme d'un code matriciel de type QR code ou autre forme. Le fichier HTML correspondant à la page intégrant ce code est transmis (étape 5) au premier équipement (30) qui commande l'affichage de la page intégrant le code visualisé sous une forme graphique (32). [0050] Le premier équipement connecté (30) ouvre de façon habituelle une session (étape 3) avec le serveur (20) hébergeant le site correspondant à l'adresse considérée, selon un protocole TCP/IP. [0051] Le serveur (20) ouvre une session (étape 4) via la clé qui lui a été attribuée par le serveur de confiance (10) lors de l'enregistrement initial, et transmet de manière chiffrée au serveur de confiance (10) l'identifiant de l'équipement connecté (30). [0052] Le serveur (20) peut, préalablement à cette transmission de l'identifiant, procéder à des traitements locaux pour vérifier l'accréditation de l'utilisateur et/ou du premier équipement connecté (30) correspondant à l'identifiant. [0053] Cette vérification consiste par exemple à vérifier si l'identifiant du premier équipement (30) et/ou de l'utilisateur ne fait pas partie d'une liste d'exclusion hlacklist »en anglais (par exemple d'utilisateur frauduleux, ou domiciliés dans des pays où l'offre du serveur (20) n'est pas autorisée). Dans ce cas, le serveur (20) utilise la session (ouverte à l'étape 3) pour notifier le refus de service. [0054] Sinon, si le traitement local autorise la poursuite d'une transaction, le serveur (20) ouvre une session (étape 4) avec le serveur de confiance (10) pour transmettre l'identifiant de l'équipement connecté (30). [0055] A la différence de la solution antérieur proposée par le brevet FR3045187B1, une attaque informatique du serveur (20) ne met pas en cause la sécurité de l'ensemble du processus car les codes calculés par le serveur de confiance (10) ne transitent plus par le serveur (20). [0056] Par ailleurs, cette solution nouvelle permet de dissocier les traitements de sécurité: [0057] Les traitements globaux, contre les fraudes génériques telles que le harponnage, sont réalisées exclusivement par l'opérateur du serveur de sécurité, pour l'ensemble des serveurs utilisant la solution Les traitements spécifiques à l'activité d'un marchand sont effectués exclusivement localement, sur le serveur (20), ce qui permet d'ajuster très précisément les choix d'accréditation. [0058] Le serveur de confiance (10) calcule alors un code numérique horodaté, qui est transmis (étape 5) au premier équipement connecté (30) de l'utilisateur. [0059] Dans l'exemple illustré en figure 6, ce code est traité par le premier équipement connecté (30) pour afficher une représentation graphique, par exemple un QR code (32), que l'utilisateur photographie avec un second équipement connecté (31), par 8 exemple un téléphone intelligent. Ce code (32) peut aussi être affiché en caractère alphanumérique, pour permettre à l'utilisateur une saisie manuelle ou vocale avec le second équipement connecté (31). Il peut également être transmis sous forme de message sonore enregistré par le second équipement connecté (31) ou encore sous la forme d'un fichier numérique transmis au second équipement connecté (31) par NFC, Bluctooth, liaison USB, par exemple. [0060] L'utilisateur peut ainsi procéder à une vérification en scannant photographiant le code graphique (32) visualisé sur un premier équipement (30), par exemple un ordinateur ou une tablette, à l'aide d'un second équipement (31), distinct de l'équipement (30) qui a établi la session avec le serveur (20). [0061] L'acquisition du code (32) par l'activation de l'application ASC préalablement installée sur le second équipement (31) entraîne dans une étape 6.1 l'ouverture d'une session avec le serveur de confiance (10) et la transmission par le second équipement (31) du code flashé. Le serveur de confiance (10) compare le code transmis avec les codes générés pendant la tranche temporelle de validité et en cas de succès, transmet au second équipement (31) un message numérique comportant un indicateur de conformité, par exemple un code commande une plage colorée d'une première couleur, ainsi que des informations enregistrées en relation avec l'identifiant du site associé au code (32). [0062] Dans une étape 6.2, le serveur de confiance (10) fait appel à un serveur tiers (12) de notification par un dialogue sécurisé qui comporte un message avec l'indicateur de conformité précédemment calculé et l'identifiant du second équipement (31) de l'utilisateur. [0063] Dans une étape 6.3, le serveur tiers de notification (12) transmet au second équipement connecté (31) de l'utilisateur dont il connaît l'identifiant le message de conformité. [0064] L'utilisateur peut ainsi obtenir la confirmation que le site consulté est authentique. [0065] Dans l'exemple illustré en figure 7, où il n'y a qu'un seul équipement (31), ce code est reçu selon un premier protocole (étape 5), par exemple TCP/IP, et est traité par l'équipement connecté (31) qui l'enregistre en mémoire, et l'application de sécurité lit ce code pour le retourner au serveur de confiance (10) via un second protocole (étape 6.1) depuis le même équipement connecté (31), par exemple PUSH ou HTTPS. Cette situation correspond par exemple à un situation hybride nomade. [0066] Quel que soit le nombre d'équipements, dans le cas d'un site frauduleux, le code éventuellement simulé par le fraudeur sera acquis par le second équipement (31) et transmis au serveur de confiance (10), et conduira à un traitement de vérification infructueux, ce qui déclenchera l'envoi d'un message numérique d'alerte. [0067] Situation d'appairage 9 [0068] Dans l'exemple représenté en référence à la figure 8, correspondant à une situation d'appairage, dans laquelle un lien est créé sur le serveur de confiance (10) entre le premier équipement connecté (30) et le second équipement connecté (31), les étapes sont les suivantes [0069] Les étapes 3, 4, 5 et 6.1 restent identiques à cc qui a été décrit précédemment. [0070] Dans l'étape 6.2 le serveur de confiance (10) fait appel à un serveur tiers de noti- fication (12) par un dialogue sécurisé comportant un message avec l'indicateur de conformité et l'identifiant du second équipement connecté (31) de l'utilisateur. [0071] Dans l'étape 6.3, le serveur tiers de notification (12) transmet au second équipement connecté (31) de l'utilisateur dont il connaît l'identifiant le message de conformité. [0072] Dans une étape 6.4, le premier équipement connecté (30) dialogue avec le serveur de confiance (10) pour indiquer l'état du lien avec le premier équipement connecté (30) appartenant au même système connecté de l'utilisateur. [0073] Le message numérique envoyé en cas de conformité peut aussi contenir un lien hy- pertexte dont l'activation commande l'ouverture d'une session (étape 7) avec un serveur tiers (15), par exemple un serveur de paiement, pour la réalisation d'une transaction sécurisée. [0074] Contrairement à une hase de données ou un système de fichiers, la session conserve les informations pendant quelques minutes. Le serveur crée des fichiers stockés dans un répertoire particulier. [0075] La figure 9 représente une variante simplifiée dans une situation d'appairage initial où l'indicateur de conformité est affiché simplement sur le second équipement connecté (31). [0076] Les sessions sont particulièrement utilisées pour les applications nécessitant des espaces membres et accès sécurisés avec authentification: [0077] Gestion d'un caddie sur un site de vente en ligne. Formulaires éclatés sur plusieurs pages. Stockage d'informations relatives à la navigation de l'utilisateur (thème préféré, langues...). [0078] Le principe de l'invention est de séparer la validation d'un site, d'un produit sur un site et la page de paiement. [0079] Pour cela l'invention prévoit de créer un chaînage au minimum de deux codes nu- mériques permettant de certifier auprès du demandeur que le code a une direction et une propriété précise dont il peut vérifier les informations. [0080] Cette solution supprime l'effet«attaque de l'homme du milieu (HDM) ou«middle man attack» en créant une rupture dans la logique de communication web. L'attaque de l'homme du milieu (HDM) ou man in the middle attack (MITM) est une attaque qui a pour but d'intercepter les communications entre deux parties, sans que ni l'une ni l'autre ne puisse se douter que le canal de communication entre elles a été compromis. Le canal le plus courant est une connexion à Internet de l'internaute. L'attaquant doit d'abord être capable d'observer et d'intercepter les messages d'une victime à l'autre. L'attaque « homme du milieu » est particulièrement applicable dans la méthode d'échange de clés Diffic-Hellman, quand elle est utilisée sans authentification. Avec authentification, Diffie-Hellman est en revanche invulnérable aux écoutes du canal, et est d'ailleurs conçue pour cela. [0081] La solution selon l'invention prévoit le téléchargement d'une application depuis une plateforme de téléchargement sécurisée et de confiance sur un équipement connecté, par exemple une tablette ou un téléphone cellulaire. [0082] Cette application, une fois chargée, lui donne la possibilité de scanner les codes qui sont activés à sa demande pour certifier. [0083] Les codes uniques créés par le serveur de confiance à chaque demande du serveur web retournent sur le site pour qu'ils soient affichés. [0084] Pour le demandeur il lui suffit de scanner le code avec l'équipement connecté chargé de l'application téléchargée. [0085] L'information scanné est dirigée vers le serveur de confiance qui certifie en premier lieu le code et prend en compte les informations qu'il a dans sa base. [0086] Il retourne vers le demandeur un certificat associé à différents types d'informations les détails de l'appartenance du code (URL du site, produit, validation de la marque et du site (code trust), URL de paiement). 11 [Revendication 1] REVENDICATIONSProcédé de communication sécurisé entre au moins un serveur informatique (20) et des utilisateurs disposant chacun d'au moins un système informatique connecté (30) et comportant une étape initiale d'enregistrement d'un identifiant unique dudit serveur informatique (20) dans la mémoire d'un serveur informatique de confiance (10), le procédé de communication étant caractérisé en ce que ledit système informatique connecté (30) présente un premier mode de communication numérique et un second mode de communication numérique, et en ce que ledit procédé comporte en outre les étapes suivantes : - des étapes initiales comprenant : * la transmission d'une application ASC au système informatique connecté (30) ; * ladite application étant installée sur ledit système informatique connecté (30), son exécution commandant l'ouverture automatique d'une session informatique avec ledit serveur de confiance (10) selon ledit second mode de communication numérique ; - des étapes de validation d'une information présentée sur ledit système connecté (30) comprenant : - une opération d'ouverture d'une session de communication par ledit système connecté (30) avec un serveur informatique ; - une opération d'ouverture d'une session de communication sécurisée par ledit serveur informatique (20) avec ledit serveur de confiance (10), et de transmission par ledit serveur informatique (20) d'un identifiant dudit système connecté (30) ; * une opération de calcul par ledit serveur de confiance (10) d'un code horodaté associé à ladite clé ; - une opération de transmission dudit code horodaté par le serveur de confiance (10) audit système connecté (30) correspondant à l'identifiant préalablement transmis par ledit serveur (20), via un premier protocole de communication ; - une opération d'acquisition dudit code horodaté par ledit système connecté (30) selon le premier protocole, et * une opération d'ouverture d'une session de communication par ledit système connecté (30) selon un second protocole, avec ledit serveur de confiance (10) par l'intermédiaire de ladite application préalablement chargée et de transmission dudit code acquis ; 12 [Revendication 2] [Revendication 3] [Revendication 4] [Revendication 5] [Revendication 6] * une opération de vérification de la conformité du code transmis par ledit système connecté (30) ; * une opération de transmission audit système connecté (30) par ledit serveur de confiance (10) d'un message numérique de validation comprenant un indicateur de conformité du code et une information relative au serveur (20) associé au code validé. Procédé de communication sécurisé selon la revendication 1 caractérisé en ce que le serveur (20) procède à une vérification de l'accréditation de l'identifiant du système connecté (30) et/ou de l'utilisateur et à la transmission dudit identifiant au serveur de confiance (10) dans le cas où cette vérification est positive. Procédé de communication sécurisé selon la revendication 1 caractérisé en ce que le système connecté (30) est constitué de deux équipements (30, 31) fonctionnant avec des protocoles de communications différents. Procédé de communication sécurisé selon la revendication 1 caractérisé en ce que le système connecté (30) est constitué d'un seul équipement fonctionnant avec des protocoles de communication différents. Procédé de communication sécurisé selon la revendication 1 caractérisé en ce que ledit message numérique est envoyé par un serveur tiers (15). Procédé de communication sécurisé selon la revendication 5 caractérisé en ce que ledit message numérique envoyé par un serveur tiers (15) en cas de conformité du code contient un lien hypertexte dont l'activation commande l'ouverture d'une session avec un serveur de paiement, pour la réalisation d'une transaction sécurisée.