Domaine de 1 ' invention

La présente invention concerne le domaine de la sécurisation de communication électronique asynchrone sur des réseaux informatiques, notamment, mais non limitativement le réseau internet ou des réseaux privés virtuels.

Les informations, par exemple des données numériques produites par des objets connectés, des télécopies, ou des messages textuels, des fichiers numériques, sont transmis grâce à un ensemble standardisé de protocoles de transfert de données, qui permet l'élaboration d'applications et de services variés comme la publication de données, le courrier électronique, la messagerie instantanée, le pair-à- pair, etc. Les solutions les plus sécurisées utilisent des techniques de chiffrement de bout en bout ( « End-to-end encryption » en anglais). Lorsqu'un message est envoyé à un destinataire, celui-ci est chiffré par l'utilisateur, sur l'équipement informatique de l'émetteur, selon des solutions garantissant que seul le récepteur peut décrypter la missive. Le serveur par lequel transite la conversation ne sert qu'à relayer sans jamais tenter de le décoder. Dans ce cas, les utilisateurs peuvent communiquer entre eux sans intermédiaires .

Au lieu d'être envoyé sous forme de texte, le message est brouillé en forme de chiffres et il faut une clé pour le décrypter. Les clés sont éphémères et disparaissent quand le message a été déchiffré par l'utilisateur. De ce fait, les pirates, cybercriminels et même les employés de l'opérateur de service ne sont pas en mesure de lire les correspondances. À titre d'exemple, le service de messagerie WhatsApp (nom commercial) propose une solution de chiffrement de bout en bout .

État de la technique

On connaît dans l'état de la technique la demande de brevet WO2014175830 décrivant un procédé pour traiter un paquet de données depuis un premier dispositif informatique vers un second dispositif informatique afin de permettre une communication de cryptage de bout en bout

Le paquet de données comprend un message crypté à l'aide d'une première clé de cryptage afin de former un message crypté, des données d'identification du second dispositif informatique cryptées à l'aide d'une seconde clé de cryptage afin de former des données d'identification cryptées, et des première et seconde clés de cryptage cryptées.

Le procédé selon cette solution connue consiste à décrypter la seconde clé de cryptage cryptée, décrypter les données d'identification cryptées à l'aide de la seconde clé de cryptage décryptée, et transmettre le paquet de données en fonction des données d'identification décryptées, le message crypté et la première clé de cryptage étant conçus pour ne pas pouvoir être décryptés par le serveur afin de permettre une communication de cryptage de bout en bout entre les premier et second dispositifs informatiques.

La demande de brevet W02012067847 décrit également des systèmes et des procédés permettant un cryptage de bout en bout. Conformément à un mode de réalisation, un procédé d'enregistrement de dispositif comprend les étapes suivantes :

— une application exécutée par un processeur informatique reçoit un mot de passe utilisateur d'un utilisateur ; — au moyen du processeur informatique, l'application combine le mot de passe utilisateur et une extension du mot de passe ;

— au moyen du processeur informatique, l'application traite de manière cryptographique la combinaison du mot de passe utilisateur et de l'extension du mot de passe, ce qui permet d'obtenir des informations publiques cryptographiques. Les informations publiques cryptographiques sont fournies à un serveur. Par contre, le mot de passe utilisateur n'est pas fourni au serveur.

On connaît aussi le brevet EP1536601 qui concerne un procédé de cryptage bout à bout de courriers électroniques envoyés d'un émetteur à un destinataire comportant les étapes suivantes :

a) l'émetteur demande à un système de cryptage un certificat correspondant audit destinataire,

b) le système de cryptage renvoie audit émetteur un premier certificat correspondant audit destinataire, l'émetteur envoie avec son logiciel de courrier électronique un courrier électronique sortant audit destinataire crypté avec ledit certificat,

c) ledit courrier électronique est envoyé par ledit système de cryptage.

Le système de cryptage décrypte le courrier électronique en utilisant une clé privée correspondant au certificat, et le système de cryptage rend disponible le contenu dudit courrier électronique audit destinataire.

L'émetteur demande un certificat correspondant audit destinataire à un système d'encryption dans ledit réseau privé, le système d'encryption renvoie audit émetteur un premier certificat pro forma correspondant audit destinataire, le certificat pro forma étant généré ou retrouvé par le système d'encryption pour le destinataire et seulement utilisé entre l'émetteur (1) et le système d'encryption, l'émetteur envoie avec son client e-mail un e-mail sortant audit destinataire encrypté avec ledit certificat pro forma, ledit e-mail est transmis via ledit système d'encryption, ledit système d'encryption décrypte ledit e-mail en utilisant une clé privée correspondant audit certificat, ledit système d'encryption rend le contenu dudit e-mail disponible audit destinataire .

On connaît aussi dans l'état de la technique le brevet américain US7240366 décrivant un procédé d ' authentification de bout en bout basée sur les certificats de clé publique combiné avec le Session Initiation Protocol (SIP) pour permettre à un nœud SIP qui reçoit un message de requête SIP 1 ' authentification l'expéditeur de la demande. Le message de demande SIP est envoyé avec une signature numérique générée avec une clé privée de l'expéditeur et peut inclure un certificat de l'expéditeur. Le message de demande SIP peut également être chiffré avec une clé publique du destinataire. Après avoir reçu la requête SIP, le nœud récepteur SIP obtient un certificat de l'expéditeur et authentifie l'expéditeur sur la base de la signature numérique.

La signature numérique peut être incluse dans un en-tête d'autorisation de la requête SIP ou dans un corps de message en plusieurs parties construit conformément à la norme S/MIME.

La demande de brevet US20100189260 décrit une solution de gestion de droits attribués à une session de communication et aux composants liés à la demande de l'utilisateur. On fournit aux participants autorisés à participer à la session des outils d'accès tels que des clés de déchiffrement. Des restrictions basées sur les droits de conversation attribués sont étendues pour préserver les enregistrements et les documents associés de la session de communication . Inconvénient de l ' art antérieur

Les solutions de l'art antérieur permettent des transmissions de données ou messages chiffrés de bout en bout seulement entre un émetteur préalablement enregistré sur une plateforme transactionnelle et un destinataire, également préalablement enregistré sur une plateforme transactionnelle.

Lorsqu'un émetteur souhaite envoyer un message ou des données à un destinataire qui n'est pas déjà enregistré, il doit d'abord lui envoyer un message non crypté l'invitant à s'inscrire sur la plateforme transactionnelle.

Pendant ce temps, l'émetteur doit conserver le message en mémoire de son équipement informatique, surveiller la réception d'une notification d'inscription du destinataire, puis engager le processus de transmission du message ou des données chiffrées bout-en-bout avec le destinataire nouvellement inscrit.

L'interception du message d'invitation envoyé par l'émetteur peut être intercepté, et alors ouvrir une faille de sécurité .

Par ailleurs, si un délai long s'écoule entre l'envoi de l'invitation et la notification de l'enregistrement de l'émetteur, le message ou les données peuvent être perdus ou altérés.

En tout état de cause, les solutions de l'art antérieur nécessitent des mécanismes de synchronisation entre l'équipement informatique de l'émetteur, celui du destinataire et la plateforme transactionnelle.

En particulier dans la solution proposée par la demande de brevet US20100189260 (figure 3), les utilisateurs sont déjà connus de la plateforme, qui ne permet pas la communication avec un destinataire non connu de la plateforme.

Les solutions de l'art antérieur présentent par ailleurs une faille de sécurité connue sous le nom de l'attaque de l'homme du milieu (en anglais « man-in-the-middle attack ») qui 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.

Solution apportée par 1 ' invention

Afin de remédier à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé de transmission d'une information numérique chiffrée de bout en bout, entre un émetteur enregistré sur une plateforme transactionnelle, et au moins un destinataire quelconque, comportant les étapes suivantes :

• sélection sur l'équipement informatique de l'émetteur d'une information numérique et d'un identifiant numérique dudit destinataire

• chiffrement temporaire de ladite information numérique par l'exécution d'une application de chiffrement locale sur l'équipement informatique avec la clé privée de 1 ' expéditeur

· transmission par l'équipement informatique de l'émetteur de ladite information numérique chiffrée et dudit identifiant du destinataire à la plateforme transactionnelle

• transmission par la plateforme audit destinataire d'un message numérique d'invitation comportant un lien dont l'activation par ledit destinataire commande

o l'exécution d'une application de création sur l'équipement informatique dudit destinataire d'au moins un couple de clés de chiffrement,

o la transmission d'au moins une clé publique ainsi créée par l'équipement dudit destinataire à ladite plateforme transactionnelle et son enregistrement sur ladite plateforme en relation avec l'identifiant dudit destinataire • notification par ladite plateforme transactionnelle à l'équipement de l'émetteur d'un message numérique permettant la récupération et l'enregistrement dans une mémoire temporaire sur l'équipement de l'émetteur de ladite clé publique dudit destinataire

• déchiffrement de ladite information sur l'équipement de l'émetteur et chiffrement de ladite information avec la clé publique dudit destinataire

• transmission au destinataire par l'équipement informatique de l'émetteur de ladite information numérique chiffrée avec la clé publique de l'expéditeur, optionnellement par l'intermédiaire de la plateforme transactionnelle

• déchiffrement par l'équipement informatique dudit destinataire de ladite information avec la clé publique de l'expéditeur.

Selon un mode de réalisation avantageux, l'une au moins desdites applications de chiffrement est constituée par une application WEB transmise par ladite plateforme informatique à l'équipement informatique sous forme de code source exécutable par un navigateur [JavaScript].

Selon un autre mode de réalisation avantageux, l'une au moins desdites applications de chiffrement est constituée par une application mobile préalablement installée sur l'équipement informatique hôte.

Selon un autre mode de réalisation avantageux, l'une au moins desdites applications de chiffrement est constituée par une application mobile téléchargeable pour son installation l'équipement informatique du destinataire, ledit message numérique d'invitation contenant un mécanisme commandant ledit téléchargement. Selon une variante, la génération des clés de chiffrement comporte une étape de traitement cryptographique appliqué à une combinaison formée par un mot de passe choisi par l'utilisateur et un nonce transmis par ladite plateforme transactionnelle.

Selon un mode de mise en œuvre particulier, le procédé est appliqué à un groupe formé par une pluralité de destinataires, le procédé comportant :

- une étape d'introduction de clés de chiffrement intermédiaires uniques pour chaque information numérique, chaque destinataire accédant auxdites informations numériques, par le déchiffrement avec ses clés personnelles desdites clés intermédiaires,

- des étapes de recalcul de clés intermédiaires en cas de modification dudit groupe de destinataires.

Selon un autre mode de mise en œuvre particulier, le procédé est appliqué à un groupe d'informations numériques, le procédé comportant :

une étape d'introduction de clés de chiffrement intermédiaires uniques pour chaque information numérique, chaque destinataire accédant à l'ensemble dudit groupe d'informations numériques, par le déchiffrement avec ses clés personnelles desdites clés intermédiaires.

Selon un mode de mise en œuvre particulier, l'un au moins desdits équipements informatiques est constitué par un objet connecté.

Avantageusement, la génération des clés de chiffrement comporte une étape de traitement cryptographique appliqué à une combinaison formée par une information unique secrète enregistrée dans l'objet connecté au moment de sa fabrication et un nonce transmis par ladite plateforme transactionnelle .

L'invention concerne aussi l'application du procédé de transmission d'une information numérique chiffrée de bout en bout susvisé pour un service de messagerie.

Elle concerne aussi l'application du procédé de transmission d'une information numérique chiffrée de bout en bout susvisé pour un service de partage de fichiers.

Elle concerne aussi l'application du procédé de transmission d'une information numérique chiffrée de bout en bout susvisé pour un service de communication en temps réel multimédia [voix, chat].

Elle concerne aussi l'application du procédé de transmission d'une information numérique chiffrée de bout en bout conforme susvisé pour un service de communication d'informations numériques avec un objet connecté.

Elle concerne aussi l'application du procédé de transmission d'une information numérique chiffrée de bout en bout susvisé pour un service de communication d'informations numériques avec un équipement médical connecté.

L'invention concerne encore un objet connecté comportant une information unique et secrète enregistrée au moment de sa fabrication, un processeur pour l'exécution d'applications enregistrées dans une mémoire local, et des moyens de communication avec une plateforme distance, caractérisé en ce que l'une desdites applications enregistrées est apte à exécuter les traitements locaux propres au procédé objet de la revendication 1. De préférence, l'objet connecté selon l'invention comporte un calculateur associé à un circuit de communication réseau et une zone de mémoire non volatile dans lequel est enregistrée au moins une séquence numérique correspondant au mot de passe.

Description détaillée d'un exemple non limitatif de

1 ' invention La présente invention sera mieux comprise à la lecture de la description qui suit, se référant à un exemple non limitatif de réalisation illustré par les dessins annexés où :

— la figure 1 représente une vue schématique de l'architecture matérielle d'un système pour la mise en œuvre de 1 ' invention

— la figure 2 représente le diagramme des échanges de données entre Alice et Bob

— la figure 3 représente le schéma fonctionnel de l'étape d'enregistrement temporaire du message d'Alice

— la figure 4 représente le diagramme de génération des informations à partir du mot de passe choisi par Bob

— la figure 5 représente le schéma fonctionnel de l'étape de rechiffrement du message par Alice

— la figure 6 représente le schéma fonctionnel de l'étape de récupération du message par Bob

Architecture matérielle

La figure 1 représente une vue schématique de l'architecture matérielle, dans une situation simplifiée concernant les échanges entre deux utilisateurs seulement.

Les utilisateurs sont appelés Alice et Bob, et utilisent chacun un ou plusieurs équipements informatiques connectés respectivement (1, 11 ; 2, 12). Il peut par exemple s'agit d'un ordinateur connecté ou d'une tablette, ou d'un téléphone de type « Smartphone » .

Lorsqu'il s'agit d'un ordinateur, il est nécessaire qu'il dispose de ressources informatiques pour accéder à un réseau, par exemple internet, et un navigateur WEB usuel.

Dans le cas d'une tablette ou d'un téléphone, l'équipement comporte également des ressources telles qu'un navigateur ou une application mobile assurant la connexion à une plateforme distante.

Le système selon l'invention met en œuvre optionnellement un proxy (3), qui distribue la charge du service vers un ou plusieurs serveurs (4, 13, 14) qui peuvent être locaux ou distants dans le « cloud », exécutant une interface de programmation interactive (API).

Les serveurs (4, 13, 14) sont associés à un ou plusieurs équipements de gestion de base de données (5, 15, 16), qui peuvent être locale ou distante dans le « cloud ».

La communication entre les différents équipements utilise une couche de transport usuelle, par exemple TCP/IP ou Lora, et une couche de communication standard, par exemple http ou https .

Le proxy (3) et les serveurs (4, 13, 14) ainsi que les équipements de gestion de base de données (5, 15, 16) forment une plateforme d'échanges sécurisés (20).

Diagramme des échanges

L'initiateur des échanges est Alice, souhaitant transmettre à Bob un message sous une forme sécurisée via une plateforme, étant entendu que Bob ne dispose pas d'accès à la plateforme d'échanges (20).

Alice compose localement, sur l'un de ses équipements (1, 11) un message numérique (21) avec un éditeur quelconque, par exemple une application de messagerie adaptée à la plateforme (20), et donc cliente des API (4, 13, 14) et enregistre localement en mémoire tampon d'un de ses équipements (1,11).

Alice saisit ensuite un identifiant public (22) du destinataire Bob, par exemple une adresse de messagerie de Bob ou un numéro de téléphone mobile dans l'application exécutée sur son équipement de travail (1, 11).

Cette application commande alors l'ouverture d'une session de communication avec son identifiant. L'application commande ensuite l'émission d'une requête via la plateforme (20) pour la couche de transport et via cette session et, pour la couche de communication, via le jeton de session (ou mécanisme équivalent), d'identification de Bob, sous la forme d'un message comprenant au moins l'identifiant de Bob.

La plateforme (20) compare l'identifiant (22) transmis par Alice avec la liste des identifiants des titulaires d'un compte par une étape de vérification (23).

Si Bob est inconnu, c'est-à-dire ne dispose pas de compte sur la plateforme (20), la plateforme génère un compte temporaire associé à l'identifiant de Bob transmis par Alice.

Ce compte temporaire se traduit par :

— la création d'une entrée dédiée à Bob, dans la base de base de données (5, 15, 16)

— l'envoi par la plateforme (20) d'un message à Bob, contenant :

— un message textuel (25) d'information de Bob de l'existence d'un message émanant d'Alice

— un lien vers une interface de création (26) par Bob d'un mot de passe, par exemple sous forme de code JavaScript et HTML.

Cette interface de création (26) est exécutée immédiatement ou en différé sur l'équipement (2) de Bob, localement et sans communication de la chaîne de caractères (27) créée par Bob à la plateforme (20) ni aux équipements (1, 11) d'Alice et plus généralement à aucun équipement présent sur le réseau.

La plateforme (20) transmet alors à Alice à un message d'acquittement. L'envoi de ce message signifie que :

— la plateforme (20) a créé un compte temporaire affecté à Bob

— la plateforme (20) a transmis à Bob le message (25) contenant le lien lui permettant à un moment de son choix de procéder à l'étape de saisie d'un mot de passe dans l'interface (26).

Enregistrement temporaire du message d'Alice

La figure 3 représente le schéma fonctionnel de l'étape d'enregistrement temporaire du message d'Alice.

La réception du message déclenche automatiquement les opérations suivantes :

— l'application cliente d'Alice commande le chiffrement du message (21) avec la clé publique d'Alice (19), transmise par la plateforme (20) à partir de l'information enregistrée dans la base de données (5, 15, 16) et correspondant à son compte. Cette clé publique est par exemple transmise dans le message ou dans le processus d'ouverture de la session. Elle peut également être stockée localement sur l'équipement (1, 11) d'Alice, par exemple dans la mémoire cache d'une application mobile. Cette étape aboutit à un message chiffré (42) contenant des métadonnées généralement non chiffrées, notamment un identifiant du destinataire Bob.

— ce message chiffré (42) est ensuite transmis par une transmission (102) à la plateforme (20) et enregistré, par exemple :

— dans la base de données (5, 15, 16) de la plateforme (20)

- dans une boîte de messagerie tierce liée à Alice - dans une plateforme Cloud...

La plateforme enregistre par ailleurs dans la base de données (5, 15, 16) de la plateforme (20) les métadonnées (43) contenant notamment l'adresse de stockage du message, par exemple sous forme d'adresse URL.

Optionnellement , l'équipement (1, 11) d'Alice génère une clé aléatoire de chiffrement (44) permettant le chiffrement symétrique du message (42). Cette clé aléatoire (44) est elle-même chiffrée de manière asymétrique avec la clé publique d'Alice (19) de façon à permettre ensuite à Alice de déchiffrer la clé aléatoire (44) avec sa propre clé privée.

Génération des informations publiques et privées de Bob Cette étape est asynchrone par rapport au processus d'échange. Elle intervient à un moment quelconque après la réception de la notification du message (25) et du lien associé .

La figure 4 représente le détail de la procédure de création des informations publiques et privées de Bob.

Le mot de passe (27) peut être saisi par un clavier physique ou virtuel par Bob. Il peut aussi être généré par un équipement de type générateur de code.

Ce mot de passe (27) fait l'objet d'un traitement par l'interface de création (26) pour générer :

— un condensât (hash) (28) par application d'un algorithme cryptographique connu

— optionnellement un ou plusieurs nombres aléatoires (29)

— un couple de clés publique (30) et privée (31).

À partir du code exécuté à partir de l'interface de création (26), Bob crée une chaîne de caractère (27) constituant un mot de passe. L'interface de création (26) génère dans l'exemple décrit un nombre aléatoire (29).

L'interface de création (26) commande le calcul de trois séquences numériques :

— un condensât (28) optionnel, par application d'un traitement de type Sha512 par exemple à la séquence de caractères (27), après application éventuelle d'un algorithme de salage à cette séquence (27)

— un couple de clés publiques privées respectivement (30, 31) par application d'un traitement, par exemple PBKDF2, à une combinaison du nombre aléatoire (29) et du mot de passe (27).

Le résultat de ces opérations conduit à :

— des données secrètes, qui ne seront pas transmises par Bob à des tiers : il s'agit du mot de passe

(27) et la clé privée (31)

— des données publiques, qui sont transmises à la plateforme (20) et enregistrées sur le compte de Bob : le condensât (28), le nombre aléatoire (29) et la clé publique (30).

Rechiffrement du message par Alice

Lorsque Alice a transmis à la plateforme (20) le message chiffré (42) comme mentionné en référence à la figure 3, et que Bob a, de manière asynchrone, procédé à la saisie d'un mot de passe comme mentionné en référence à la figure 4, les conditions de finalisation de l'échange entre Alice, disposant déjà d'un compte, et Bob, qui ne disposait pas d'un compte au moment de l'émission du message (21), sont réunies.

La figure 5 représente le schéma fonctionnel de l'étape de rechiffrement du message par Alice.

Dans un mode d'exécution automatique, lorsqu'un équipement (1, 11) d'Alice est connecté à la plateforme (20), la plateforme (20) commande une étape de rechiffrement (52) du message (42) sur un équipement (1, 11) d'Alice, et non pas sur la plateforme (20).

Si nécessaire, par exemple lorsque l'équipement (1, 11) ne dispose pas d'un cache, cette opération prévoit la transmission (103) par la plateforme (20) à l'équipement connecté (1, 11) d'Alice de :

- la clé publique (30) de Bob

- les métadonnées (43) associées au message chiffré (42)

- optionnellement le message chiffré (42) sur l'équipement connecté (1, 11) d'Alice.

Première alternative Selon une première alternative, la plateforme (20) transmet à Alice l'intégralité du message chiffré (42), et Alice déchiffre ce message avec sa clé privée, puis le rechiffre avec la clé publique (30) de Bob que vient de lui transmettre la plateforme (20).

Le message originel (21), initialement chiffré avec la clé publique d'Alice (19) pour aboutir à un message chiffré transitoire (42), est à présent disponible sous une nouvelle forme chiffrée (45) avec la clé publique de Bob.

Le message (42) est supprimé de la plateforme (20) et remplacé par le message chiffré (45).

Cette variante nécessite des traitements lourds, pour des messages importants.

Deuxième alternative

Selon une autre alternative, la plateforme (20) transmet à Alice seulement la clé aléatoire (44). Alice déchiffre cette clé aléatoire (44) avec sa clé privée, puis rechiffre la clé aléatoire (44) ainsi déchiffrée avec la clé publique (30) de Bob que vient de lui transmettre la plateforme (20).

Dans ce cas, le message chiffré (42) est conservé, seules les métadonnées (43) associées sont mises à jour sur la plateforme grâce à une requête automatique d'Alice.

Cette variante permet de simplifier le traitement de message de gros volume.

Récupération du message par Bob

La figure 6 représente le schéma fonctionnel de l'étape de récupération du message par Bob.

Après cette opération de rechiffrement, la plateforme (20) envoie à Bob un message numérique comprenant une notification textuelle ou automatique lui permettant de récupérer le message chiffré d'Alice.

Alternativement, l'application de Bob interroge périodiquement la plateforme (20) pour vérifier la disponibilité de nouveaux messages, ou encore Bob se connecte manuellement à la plateforme (20) pour vérifier si de nouveaux messages sont disponibles.

Lors de la connexion, l'équipement informatique (2, 12) de Bob exécute un traitement similaire à celui illustré par la figure 5, à partir du mot de passe (27) qu'il avait initialement créé, et du nombre aléatoire (29) initialement enregistré sur la plateforme (20).

Cela permet à Bob de régénérer d'une part la clé publique (30) et la clé privée (31) qui n'est jamais stockée et ne transite jamais sur le réseau.

Bob peut ensuite récupérer les métadonnées chiffrées (43) et d'autre part le message chiffré (42 ou 45, selon la variante), et procéder à leur déchiffrement avec sa clé privée ( 31 ) . Pour les échanges suivants, les deux parties disposent d'un compte sur la plateforme (20) leur permettant de communiquer en mode chiffré de bout en bout.

Architecture fonctionnelle d'un objet connecté

Dans le cas où les échanges se font non pas entre deux personnes disposant d'équipement informatique, mais entre des objets connectés ou un objet connecté et une personne, l'objet connecté présente une architecture dont la figure 6 représente un exemple.

L'objet connecté comporte de façon connue un calculateur (300) associé à un circuit de communication réseau (301) .

II comporte une zone de mémoire non volatile (302) dans lequel est enregistrée au moins une séquence numérique correspondant au mot de passe (27). Optionnellement , la mémoire non volatile (302) peut aussi contenir une deuxième séquence numérique correspondant au nombre aléatoire (29).