FR 3044847 A1 20170609 FR 1562027 A 20151208 1 DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne les échanges de données entre entités 5 électroniques, notamment dans le cadre de la gestion collaborative de documents électroniques. Elle concerne plus particulièrement un procédé d'échange de données au sein d'un groupe d'entités électroniques. ARRIERE-PLAN TECHNOLOGIQUE 10 Lorsque l'on souhaite restreindre l'accès à des documents électroniques à un groupe donné d'utilisateurs, il est envisageable de chiffrer les documents électroniques à l'aide d'un algorithme cryptographique et de ne communiquer la clé de déchiffrement qu'aux utilisateurs habilités à accéder aux documents. Le document GB 2 477 762 propose dans ce contexte qu'un serveur 15 dédié distribue la clé de déchiffrement aux utilisateurs autorisés. De tels serveurs sont toutefois fréquemment la cible d'attaques informatiques au cours desquelles un attaquant cherche à s'emparer des clés de déchiffrement mémorisées dans le serveur. En cas de succès d'une telle attaque, la sécurité du système est 20 compromise puisque l'attaquant pourra déchiffrer les documents du groupe d'utilisateurs. OBJET DE L'INVENTION Dans ce contexte, la présente invention propose un procédé d'échange de données au sein d'un groupe d'entités électroniques comprenant une première 25 entité électronique et au moins une seconde entité électronique, caractérisé en ce qu'il comprend les étapes suivantes : - réception, par la première entité électronique et en provenance d'un serveur distant de partage de documents, d'une donnée de vérification ; - obtention, par la seconde entité électronique, d'une donnée 30 caractéristique du groupe auprès du serveur distant de partage de documents ; - vérification, par la première entité électronique et au moyen de la donnée de vérification, que la seconde entité électronique détient ladite donnée caractéristique ; - en cas de vérification réussie, distribution par la première entité 3044847 2 électronique d'une clé cryptographique chiffrée destinée à la seconde entité électronique ; - réception, par la seconde entité électronique, de données chiffrées par la clé cryptographique ; - affichage des données échangées sur la seconde entité électronique. Le serveur distant de partage de documents (ou serveur "web" de partage de documents) est ainsi utilisé pour permettre un échange sécurisé entre la première entité électronique et la seconde entité électronique, et non comme élément central du système. La clé cryptographique est en effet générée au sein de la première entité électronique et distribuée à partir de cette première entité électronique. Une fois la clé cryptographique distribuée, on peut prévoir une étape d'utilisation de la clé cryptographique au sein d'un algorithme cryptographique mis en oeuvre par la seconde entité électronique. Selon une variable envisageable, on peut prévoir les étapes suivantes : - saisie d'une donnée de diversification (par exemple convenue entre les membres du groupe) sur la seconde entité électronique ; - utilisation, au sein d'un algorithme cryptographique mis en oeuvre par la seconde entité électronique, d'une clé dérivée à partir de la clé cryptographique et de la donnée de diversification saisie. Dans les deux cas, l'algorithme cryptographique peut être par exemple un algorithme de chiffrement ou de déchiffrement des données concernées, qui représentent par exemple un document électronique (à partager sous le sceau de la confidentialité entre les membres du groupe). Cette solution permet de s'affranchir de l'utilisation d'une entité de certification lourde et couteuse et engendre donc une simplification d'utilisation pour l'utilisateur. L'utilisateur doit uniquement valider sa demande de rejoindre un groupe et le reste est réalisé par l'un des membres du groupe (première entité électronique). Ce membre sait que cet utilisateur est connu du serveur distant après leur authentification mutuelle. Selon des caractéristiques optionnelles (et donc non limitatives) : - l'algorithme cryptographique est un algorithme cryptographique de cryptographie symétrique ; - les données chiffrées sont reçues par la seconde entité électronique en 3044847 3 provenance d'une autre entité électronique du groupe ; - les données chiffrées sont reçues par la seconde entité électronique en provenance du serveur distant ; - l'étape d'obtention comprend une sous-étape d'authentification de la 5 seconde entité électronique auprès du serveur en utilisant un algorithme cryptographique à clé asymétrique ; - ladite donnée caractéristique est une clé publique ; - ladite donnée de vérification est une clé privée associée à la clé publique (la première entité électronique pouvant également recevoir, avec la clé 10 privée, la clé publique et/ou un identifiant du groupe) ; - l'étape de vérification comprend une sous-étape de transmission d'un défi de la première entité électronique à la seconde entité électronique, une sous-étape de chiffrement du défi par la seconde entité électronique et au moyen de la clé publique, une sous-étape de transmission du défi chiffré de la seconde entité 15 électronique à la première entité électronique et une sous-étape de déchiffrement du défi chiffré par la clé privée pour comparaison avec le défi transmis ; - le procédé d'échange comprend une étape de dérivation de la clé cryptographique à partir de la clé privée ; - le procédé d'échange comprend une étape de génération d'une 20 nouvelle clé publique par la seconde entité électronique, une étape de chiffrement de ladite nouvelle clé publique en utilisant la donnée caractéristique et une étape de transmission de la nouvelle clé publique chiffrée de la seconde entité électronique à la première entité électronique ; - le procédé d'échange comprend une étape de réception par la première 25 entité électronique, en provenance de la seconde entité électronique, d'un identifiant au sein du groupe ; - la clé cryptographique est générée par la première entité électronique en utilisant ledit identifiant au sein du groupe ; - la clé cryptographique est générée par la première entité électronique 30 en utilisant ledit identifiant au sein du groupe ; - la clé cryptographique est générée par la première entité électronique en utilisant une donnée de diversification convenue par des utilisateurs associés respectivement auxdites entités électroniques du groupe ; - le procédé d'échange comprend une étape de chiffrement de la clé 3044847 4 cryptographique au moyen d'une clé publique associée à la seconde entité électronique ; - l'étape de distribution comprend une étape de transmission de la clé cryptographique chiffrée de la première entité électronique à la seconde entité 5 électronique ; - l'étape de distribution de la clé cryptographique comprend une étape transmission de la clé cryptographique chiffrée au serveur et, sur requête de la seconde entité électronique, une étape de transmission de la clé cryptographique chiffrée du serveur à la seconde entité électronique ; 10 - la seconde entité électronique est conçue pour fonctionner, au moins lors des étapes d'obtention et d'échange, dans un environnement d'exécution de confiance ; - l'affichage des données est réalisé en mode sécurisé ; - la première entité électronique ou la seconde entité électronique 15 contient une puce à microcircuit sécurisée. Le procédé d'échange peut comprendre en outre les étapes suivantes (mises en oeuvre avant l'étape de chiffrement du défi effectuée au sein de la seconde entité électronique) : - transmission, de la seconde entité électronique au serveur, d'un 20 identifiant de la seconde entité électronique et d'un identifiant du groupe ; - transmission, en réponse, de ladite donnée caractéristique du serveur à la seconde entité électronique. DESCRIPTION DETAILLEE D'UN EXEMPLE DE REALISATION La description qui va suivre en regard des dessins annexés, donnés à 25 titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés : - la figure 1 représente un exemple de contexte dans lequel peut être mise en oeuvre l'invention ; 30 - la figure 2 représente, sous forme de logigramme, un exemple de procédé conforme à l'invention ; et - la figure 3 représente, sous forme de logigramme, une variante envisageable pour une partie du procédé de la figure 2. La figure 1 représente schématiquement les éléments principaux d'un 3044847 5 exemple de contexte dans lequel peut être mise en oeuvre l'invention. Dans cet exemple, une pluralité d'entités électroniques Co, Cl, Ci, CN sont connectées à un réseau local L. Un tel réseau local L est par exemple de type réseau local sans fil (ou WLAN pour "Wireless Local Area Network"), ou de 5 type réseau local utilisant la lumière visible (ou Li-Fi pour "Light Fidelity"), ou de type réseau sans fil de capteurs (ou WSN pour "Wireless Sensor Network"). En variante, les entités électroniques Co, Cl, C, CN peuvent communiquer au moyen de liaisons de type communication en champ proche (ou NFC pour "Near Field Communication") ou de type Bluetooth Low Energy. 10 Chaque entité électronique Co, Cl, C1, CN est ici un ordinateur personnel (par exemple portable), mais pourrait être en variante une entité électronique d'un autre type, par exemple un téléphone cellulaire ou une tablette électronique. Chaque entité électronique Co, Cl, C1, CN comprend par exemple un processeur (tel qu'un microprocesseur) et au moins une mémoire. Les procédés 15 effectués par l'une des entités électroniques Co, C1, Ci, CN, comme décrit ci- dessous, peuvent alors être mis en oeuvre du fait de l'exécution, par le processeur de l'entité électronique concernée, d'instructions de programme d'ordinateur mémorisées dans la mémoire de l'entité électronique concernée. Selon une possibilité de réalisation, le processeur est conçu pour 20 exécuter sélectivement un système d'exploitation polyvalent (en anglais "Rich Operating System") de manière à créer un environnement d'exécution polyvalent (ou REE pour "Rich Execution Environmenf') ou un système d'exploitation de confiance (en anglais "Trusted Operating System") de manière à créer un environnement d'exécution de confiance (ou TEE pour "Trusted Execution 25 Environment"). Chaque entité électronique Co, C1, Ci, CN comprend un module de communication pour échanger des données sur le réseau local L. Dans l'exemple décrit ici, le module de communication est un module de communication sans fil qui permet d'échanger des données par ondes radio via notamment une antenne 30 A. On pourrait prévoir en variante d'utiliser, pour l'une au moins des entités électroniques Co, C1, Ci, CN, un module de communication filaire. Les entités électroniques Co, C1, Ci, CN peuvent deux à deux échanger des données entre elles via le réseau local L. On remarque toutefois que, bien qu'elles soient présentes sur le même 3044847 6 réseau local pour le groupe, les différentes entités électroniques Co, C1, Ci, CN peuvent appartenir respectivement à différents domaines (c'est-à-dire à différentes parties d'un réseau informatique). Autrement dit, chaque entité électronique Co, C1, Ci, CN est répertoriée dans un domaine particulier d'un réseau informatique et 5 les domaines respectivement associés à deux entités électroniques au moins peuvent être différents. Ces domaines particuliers peuvent par exemple représenter un regroupement suivant une classification par secteur d'activité professionnelle, économique ou encore stratégique. Le réseau local L comprend également une passerelle P connectée 10 d'une part à l'antenne A et d'autre part à un réseau public I, par exemple un réseau métropolitain (ou MAN pour "Metropolitan Area Network") ou un réseau étendu (ou WAN pour "Wide Area Network") tel que le réseau Internet. Chaque entité électronique Co, C1, Ci, CN peut ainsi échanger des données avec un serveur distant S connecté au réseau public I et hébergeant un 15 service de gestion collaborative de documents. On dénomme parfois un tel serveur S "serveur web de partage de documents". Il s'agit d'un serveur sur la toile, ou "en ligne". Ce type de serveur permet de partager des documents sous forme de fichier à extension pdf, de documents bureautique (de type Word®, Excel®, etc.), ou d'image, par exemple. 20 Un tel serveur est par exemple de type Dropbox® (Dropbox, Inc.), google Drive® (google®), iCloud® (Apple®) ou encore OneDrive® (Microsoft®). Le serveur S échange ainsi des données avec des entités électroniques Co, C1, Ci, CN associées respectivement à plusieurs domaines (comme expliqué ci-dessus) et est ainsi un serveur multi-domaine. 25 On considère ici que, suite à un processus préalable de souscription (ou "enrollment" selon la terminologie anglo-saxonne parfois utilisée), chaque utilisateur d'une entité électronique C1 est abonné au service de gestion collaboration de documents et détient dans ce cadre un identifiant ID;. Lorsque l'utilisateur d'une entité électronique C1 fournit cet identifiant ID1, ainsi 30 éventuellement qu'un moyen d'authentification (tel qu'un mot de passe) au serveur S, le serveur S peut mettre en place un canal d'échange sécurisé (notamment chiffré) entre l'entité électronique Ci concernée et le serveur S. Selon une possibilité de réalisation, l'entité électronique Ci reçoit, au cours du processus d'abonnement, une clé privée associée à une clé publique 3044847 7 dans une infrastructure à clé publique (cette clé privée pouvant être éventuellement la clé pK; mentionnée ci-après). Dans un tel cas, le moyen d'authentification peut être un message (par exemple un défi, ou "challenge", reçu au préalable en provenance du serveur S) signé par application d'un algorithme 5 cryptographique (tel qu'un algorithme de type RSA) utilisant cette clé privée, ce qui permet au serveur de vérifier la signature par utilisation de la clé publique associée et d'authentifier ainsi, en cas de vérification positive, l'entité électronique Ci. Chaque entité électronique Co, C1, Ci, CN mémorise (par exemple dans la 10 mémoire précitée) une clé privée pK; associée à une clé publique PK; dans une infrastructure à clé publique (ou PKI pour "Public Key Infrastructure"). Chaque entité électronique Co, C1, Ci, CN comprend un module cryptographique conçu pour effectuer notamment des opérations de chiffrement, de déchiffrement, de signature et/ou de vérification de signature. Un tel module 15 cryptographique est par exemple réalisé en pratique du fait de l'exécution, par le processeur de l'entité électronique concernée fonctionnant dans l'environnement d'exécution de confiance (ou mode TEE), d'instructions de programme d'ordinateur mémorisées dans la mémoire de l'entité électronique concernée. En variante, un tel module cryptographique est par exemple un crypto-processeur 20 effectuant des opérations cryptographiques sous commande du processeur de l'entité électronique concernée. En variante, le module cryptographique peut être un module annexe de sécurité, par exemple un module comportant une puce à microcircuit sécurisée. Le module cryptographique est par exemple dans ce cas un élément sécurisé (ou SE 25 pour "Secure Element"), un élément sécurisé intégré (ou eSE pour "Embedded Secure Element"), une carte à circuit intégré universelle (ou UICC pour "Universal Integrated Circuit Card') ou une carte à circuit intégré universelle intégrée (ou eUICC pour "embedded Universal Integrated Circuit Card"). Chaque entité électronique Co, C1, Ci, CN comprend enfin une interface 30 homme-machine, qui comprend par exemple un écran et une interface utilisateur sécurisée telle que présentée plus bas. La figure 2 représente un exemple de procédé conforme à l'invention. Avant la mise en oeuvre de ce procédé, les utilisateurs des entités électroniques Co, C1, Ci, CN se sont mis d'accord (de manière collégiale) pour que 3044847 8 l'utilisateur de l'entité électronique Co ait un rôle de meneur (ou "leader" selon la terminologie d'origine anglo-saxonne) de sorte que l'entité électronique Co a un rôle particulier dans le procédé (et apparaît ainsi spécifiquement sur la figure 2). Les autres entités électroniques C1, Ci, CN ont quant à elles un rôle 5 semblable et seul le traitement mis en oeuvre au sein de l'une des ces entités électroniques Ci est donc représenté en figure 2 (les autres entités électroniques mettant en oeuvre un traitement semblable). Le procédé de la figure 2 débute à l'étape E2 à laquelle l'entité électronique Co émet, à destination du serveur de gestion S (parfois désigné sous 10 le terme "ligue", en anglais "league"), une requête REQ.CR de création d'un groupe (ou équipe, en anglais "team"), accompagnée de l'identifiant ID° de cette entité électronique Co et de son moyen d'authentification précité (par exemple un mot de passe). La requête de création du groupe REQ.CR comprend par exemple un 15 identifiant du groupe IDT, un nom du groupe, un nom du meneur (utilisateur de l'entité électronique Co), une période de validité et/ou un nombre de membres du groupe. En variante, certains de ces éléments (en particulier l'identifiant du groupe IDT) pourraient être définis par le serveur S (par exemple lors de l'étape E6 décrite ci-dessous). 20 Comme déjà indiqué, les éléments communiqués par l'entité électronique Co au serveur S permettent l'établissement d'un canal d'échange sécurisé entre l'entité électronique Co et le serveur S. À réception de la requête REQ.CR (et après authentification de l'utilisateur grâce au moyen d'authentification précité), le serveur S génère à 25 l'étape E6 une paire clé privée pKT - clé publique PKT destinée au groupe, comme expliqué dans la suite. Le serveur S envoie alors la clé privée pKT et la clé publique PKT générées à l'entité électronique Co via le canal d'échange sécurisé susmentionné (étape E8). Le serveur S peut également transmettre à cette occasion l'identifiant 30 du groupe IDT à l'entité électronique Co, notamment lorsque l'identifiant du groupe IDT est généré par le serveur S. On peut prévoir en outre que la clé privée pKT et/ou la clé publique PKT soient signées par une clé privée du serveur S. L'entité électronique Co reçoit la clé privée pKT, la clé publique PKT et 3044847 9 éventuellement l'identifiant du groupe IDT, et mémorise ces données à l'étape E10. Lorsque les clés PKT, PKT sont signées comme indiqué ci-dessus, l'entité électronique Co vérifie également lors de l'étape El 0 cette signature à l'aide de la 5 clé publique du serveur S (associée à la clé privée du serveur S dans une infrastructure à clé publique). L'utilisateur de l'entité électronique Co communique alors l'identifiant du groupe IDT à tous les autres membres du groupe, c'est-à-dire aux utilisateurs des entités électroniques Cl, C, CN. L'identifiant du groupe IDT peut par exemple être 10 transmis par un système de messagerie électronique auquel ont accès les entités électroniques Co, C1, Ci, CN. En variante, par exemple lorsque l'identifiant du groupe IDT est formé d'une suite de chiffres (ou de lettres), on peut prévoir que l'entité électronique Co affiche l'identifiant du groupe IDT reçu à l'étape E10 et que l'utilisateur de l'entité électronique Co communique à l'oral cet identifiant du groupe 15 IDT aux utilisateurs des autres entités électroniques Cl, C, CN de manière à ce que ces derniers saisissent l'identifiant du groupe IDT sur leur entité électronique Cl, C, CN. En variante, l'utilisateur de l'entité électronique CO pourrait montrer l'écran de l'entité électronique Co aux utilisateurs des autres entités électroniques C1, C, CN de manière à ce que ces derniers prennent connaissance de l'identifiant 20 du groupe IDT et saisissent celui-ci sur leur entité électronique Cl, C, CN. Dans tous les cas, la saisie de l'identifiant IDT peut être réalisée sur une interface utilisateur sécurisée (de manière logicielle et/ou matérielle), telle qu'un clavier sécurisé de saisie (par exemple de type clavier NIP ou "pin pad" selon l'appellation anglo-saxonne), le fonctionnement de l'entité électronique concernée 25 pouvant en outre alors basculer dans l'environnement d'exécution de confiance (ou mode TEE). Une telle interface utilisateur sécurisée est par exemple de type objet portable sécurisé (en anglais "secure wearable objecf'), pouvant répondre à un niveau d'assurance EAL supérieur à 4 au sens des Critères Communs (selon la 30 norme IS015408), un niveau EAL4+ (VANS) ou supérieur et/ou un niveau supérieur à 3 selon la norme FIPS 140-2. Chaque entité électronique Cl, Ci, CN (autre que l'entité électronique Co) peut ainsi émettre à l'étape E12 une demande REQ.PK d'obtention de la clé publique PKT, accompagnée de l'identifiant du groupe IDT et de l'identifiant ID; de 3044847 10 l'entité électronique C; concernée auprès du serveur S (ainsi éventuellement que des moyens d'authentification associés). Le serveur S reçoit ces données à l'étape E14. Si l'identifiant ID; (de même que le cas échéant les moyens 5 d'authentification) est reconnu, le serveur S crée un canal d'échange sécurisé avec l'entité électronique concernée C; et peut ainsi transmettre via ce canal d'échange sécurisé la clé publique PKT (associée au groupe identifié par l'identifiant IDT reçu à l'étape E14) au cours de l'étape E16. L'entité électronique concernée C; reçoit ainsi la clé publique PKT 10 associée au groupe à l'étape E18 et mémorise cette clé publique PKT pour utilisation ultérieure, comme expliqué ci-après. Selon une possibilité de réalisation, la clé publique PKT peut être transmise au sein d'un certificat qui regroupe la clé publique PKT et une signature de cette clé publique PKT au moyen de la clé privée du serveur S (signature 15 générée par exemple lors de l'étape E6 décrite plus haut). Dans un tel cas, l'entité électronique concernée C; vérifie la signature (contenue dans le certificat) au moyen de la clé publique du serveur S (clé publique associée à la clé privée du serveur S dans une infrastructure à clé publique) afin de s'assurer notamment de l'intégrité de la clé publique PKT. 20 Les étapes E12 à E18 sont mises en oeuvre pour chacune des entités électroniques Ci, C, CN du groupe (sauf l'entité électronique Co du meneur). On peut prévoir à cet égard que le serveur S vérifie (avant de mettre en oeuvre l'émission de la clé publique à l'étape E16) que le nombre d'émissions antérieures de la clé publique PKT n'a pas atteint le nombre de membres du groupe (reçu à 25 l'étape E4 dans l'exemple mentionné ci-dessus) et refuse d'émettre à nouveau la clé publique PKT lorsque le nombre d'envois de la clé publique PKT atteint le nombre de membres du groupe. Selon un mode de réalisation envisageable, le serveur S mémorise une liste des membres du groupe (précisément : une liste des identifiants ID; des 30 membres du groupe). Une telle liste est par exemple créée lors de l'étape E6 en y insérant uniquement à ce moment l'identifiant 'Do de l'entité électronique Co ; ensuite, à chaque passage à l'étape E14 (après vérification de l'identifiant ID; et éventuellement des moyens d'authentification associés), l'identifiant reçu ID; est ajouté dans la liste (ce qui revient à ajouter un membre au groupe). Le serveur S 3044847 11 refuse alors d'ajouter un nouveau membre lorsque le nombre d'identifiants ID; dans la liste atteint le nombre de membres reçu à l'étape E4. Après la mise en oeuvre des étapes E12 à E18 pour chacune des entités électroniques C1, C, CN, toutes les entités électroniques Co, C1, C, CN détiennent 5 la clé publique du groupe PKT (l'entité électronique Co détenant par ailleurs la clé privée pKT associée, reçue à l'étape El 0). Le procédé peut alors se poursuivre à l'étape E20 à laquelle l'entité électronique Co émet un défi CH (ou "challenge" selon l'appellation d'origine anglo-saxonne) à destination de chacune des autres entités électroniques C1, Ci, 10 CN. Pour chaque entité électronique C1, C, CN, une telle étape peut par exemple être initiée sur sollicitation de l'entité électronique C1, Ci, CN concernée au moyen d'une requête d'ajout au groupe (émise par l'entité électronique Ci, Ci, CN concernée à destination de l'entité électronique Co) ; une telle requête peut en outre contenir l'identifiant ID; de l'entité électronique C1, C, CN concernée auprès 15 du serveur S. Comme précédemment, on décrit ci-dessous le procédé mis en oeuvre pour une entité électronique C; particulière, sachant qu'un procédé du même type est mis en oeuvre pour chaque entité électronique C1, Ci, CN. Le défi CH émis par l'entité électronique Co est par exemple une donnée 20 de session convenue entre les membres du groupe, par exemple la date du jour, le nom de la salle dans laquelle les membres sont réunis ou tout autre texte (par exemple un nom commun choisi par le meneur et transmis à l'oral aux membres du groupe) ou code alphanumérique, éventuellement obtenu par tirage aléatoire (de sorte qu'il ne sera utilisé que dans le lieu concerné et au moment concerné). 25 On peut prévoir par ailleurs que le défi CH soit signé par l'entité électronique Co au moyen de la clé privée pKT (c'est-à-dire qu'une signature, générée par application au défi CH d'un algorithme cryptographique de signature utilisant la clé privée pKT, soit transmise avec le défi CH à l'étape E20). L'entité électronique C; destinataire du défi CH reçoit le défi CH à l'étape 30 E22. Lorsque le défi est signé comme indiqué ci-dessus, l'entité électronique C; vérifie alors la signature au moyen de la clé publique PKT (reçue à l'étape E18). L'entité électronique C; concatène alors le défi CH reçu et un identifiant TID; de l'entité électronique C; au sein du groupe et chiffre le résultat (CH, TID;) de la concaténation au moyen de la clé publique PKT du groupe (étape E23). Pour ce 3044847 12 faire, l'entité électronique Ci applique un algorithme cryptographique de chiffrement utilisant la clé publique PKT aux données concaténées (CH, TID;). Les données chiffrées [CH, TIDdPKT sont alors transmises à l'entité électronique Co lors de l'étape E24. 5 L'entité électronique Co reçoit ces données chiffrées [CH, TIDdPKT et procède à leur déchiffrement au moyen de la clé privée pKT du groupe à l'étape E26 (en appliquant à ces données un algorithme cryptographique de déchiffrement utilisant la clé privée pKT). L'entité électronique Co compare le défi contenu dans les données 10 déchiffrées au défi CH émis à l'étape E20, et s'assure ainsi (en cas de comparaison positive) que l'entité électronique C; (qui a transmis les données chiffrées [CH, TIDdPKT) détient bien la clé publique PKT et est donc bien membre du groupe. L'entité électronique Co ajoute en outre l'identifiant TID; de l'entité électronique Ci au sein du groupe à la liste des membres du groupe (ce qui revient 15 à ajouter l'utilisateur de l'entité électronique C; en tant que membre du groupe). Si en revanche le défi contenu dans les données déchiffrées ne correspond pas au défi CH émis à l'étape E20, l'entité électroniques Co n'ajoute pas l'utilisateur de l'entité électronique C; au sein du groupe et ne procède pas (pour l'entité électronique Ci qui lui a transmis la réponse erronée) à l'étape E30 20 décrite plus bas. Comme déjà indiqué, les étapes E20 et E26 sont réalisées pour chacune des entités électroniques C1, Ci, CN (autres que l'entité électronique Co du meneur). L'entité électronique Co mémorise donc (par exemple au sein d'une liste de membre du groupe) les identifiants TID; au sein du groupe de tous les 25 membres du groupe. L'entité électronique Co peut alors générer à l'étape E28 une clé secrète SK, par exemple par dérivation de la clé secrète pKT et, dans le mode de réalisation décrit ici, en utilisant les identifiants TID; des entités électronique C1 au sein du groupe, ainsi qu'éventuellement des données de diversification (ou "seed' 30 selon l'appellation anglo-saxonne). Selon un exemple de réalisation envisageable, l'entité électronique Co applique une fonction de hachage aux identifiants TID; de manière à obtenir une chaine de longueur fixe ; l'entité électronique Co détermine alors la clé secrète SK par application à la clé secrète pKT d'une fonction cryptographique de dérivation 3044847 13 de clé utilisant les données de diversification et la chaîne ainsi obtenue. Les données de diversification sont par exemple choisies par l'utilisateur de l'entité électronique Co (ou en variante, de manière collégiale entre les utilisateurs des entités électroniques Co, C1, Ch CN du groupe) : il peut s'agir par 5 exemple de la date du jour, d'un numéro de salle de réunion ou du nom de la salle de réunion, d'un nombre aléatoire obtenu par exemple par lancé successif de dés ou d'un nom tiré d'un livre. Selon une variante de réalisation, ces données de diversification ne sont pas utilisées pour calculer la clé secrète SK, mais introduites lors de l'utilisation de 10 la clé secrète, comme expliqué plus bas (à propos de l'étape E36). Pour chaque entité électronique C1, Ch CN, l'entité électronique Co peut alors chiffrer la clé secrète SK au moyen de la clé publique PK; de l'entité électronique concernée C; et transmettre la clé secrète chiffrée [SK]1 à l'entité électronique C; concernée (étape E30). 15 La clé publique PK; a par exemple été diffusée au préalable, par exemple par l'entité électronique C; associée à cette clé publique PK;, à tous les utilisateurs (en pratique à toutes les entités électroniques d'utilisateurs) susceptibles d'échanger avec l'entité électronique C. En variante (ou en sus), l'entité électronique C; peut transmettre sa clé publique PK; lors de l'étape E24 décrite 20 plus haut. Il est également envisageable selon une autre possibilité de réalisation que l'entité électronique concernée C; génère une (nouvelle) clé publique PK; et la transmette (par exemple sous forme chiffrée au moyen de la clé publique PKT du groupe) à l'entité électronique Co (cette nouvelle clé publique n'étant alors pas connue du serveur S). 25 Chaque entité électronique C1, Ch CN (autre que l'entité électronique Co) reçoit ainsi la clé secrète chiffrée [SK] I(' à l'étape E32. Chaque entité électronique C1, Ci, CN (autre que l'entité électronique Co) déchiffre la clé secrète reçue chiffrée [SK](1 au moyen de sa propre clé privée pK; (par application d'un algorithme cryptographique de chiffrement utilisant cette clé 30 privée pK;) et mémorise la clé secrète SK (étape E34). La clé secrète SK peut ainsi être utilisée à l'étape E36 par chacune des entités électroniques Co, C1, Ci, CN, par exemple pour chiffrer ou déchiffrer (ici au moyen d'un algorithme de cryptographie symétrique, par exemple un algorithme de type AES) des données, par exemple des documents (électroniques), à 3044847 14 échanger entre les membres du groupe (i.e. entre les entités électroniques Co, C1, Ci, CN). En vue de ces échanges, de telles données chiffrées peuvent être reçues (par l'une quelconque des entités électroniques Co, C1, Ci, CN) directement 5 d'une autre entité électronique Co, C1, Ci, CN du groupe. En variante, les données chiffrées pourraient être reçues (par l'une quelconque des entités électroniques Co, C1, Ci, CN) en provenance du serveur distant de partage de documents S (comme représenté schématiquement à l'étape E38), où des fichiers correspondant aux documents peuvent être mémorisés sous forme chiffrée par la 10 clé secrète SK (par exemple suite à une commande de chargement d'un tel fichier chiffré sur le serveur S par un autre membre du groupe, c'est-à-dire au moyen de l'une quelconques des entités électroniques Co, C1, Ci, CN). Cette clé secrète SK n'est toutefois pas mémorisée au niveau du serveur S et la sécurité du système ne risque donc pas d'être compromise par une attaque 15 au niveau du serveur S. Par ailleurs, dans le cas où les échanges de documents sous forme chiffrée sont réalisés à l'étape E36 entre deux entités électroniques Co, C1, Ci, CN du groupe, des échanges avec le serveur S sont utilisés lors de la mise en place du système (étapes E2 à E18), mais aucun échange avec le serveur S n'est 20 nécessaire lors de l'utilisation de la clé secrète SK (étape E36). La phase d'utilisation peut donc être réalisée dans le cadre du réseau local L, sans nécessiter d'accès au réseau public I. Selon une variante envisageable, déjà évoquée ci-dessus, on peut prévoir que chaque entité électronique Co, C1, Ci, CN utilise, au sein des 25 algorithmes cryptographiques mis en oeuvre lors de l'étape d'utilisation E36, une clé secrète dérivée obtenue par dérivation à partir de la clé secrète SK et d'une donnée de diversification commune (connue de tous les membres du groupe). Une telle donnée de diversification commune est par exemple la date du jour, le numéro (ou le nom) de la salle de réunion du groupe, ou tout autre chaine 30 de caractères convenue (de manière collégiale) entre les membres du groupe. Lorsqu'une entité électronique Co, C1, Ci, CN doit mettre en oeuvre un algorithme cryptographique lors de l'étape d'utilisation E36 (par exemple un algorithme de chiffrement ou de déchiffrement), la donnée de diversification est par exemple saisie par l'utilisateur de l'entité électronique concernée sur un 3044847 15 moyen de saisie associé à l'entité électronique concernée. La clé secrète dérivée, utilisée lors de la mise en oeuvre de l'algorithme cryptographique précité, est alors déterminée par l'entité électronique concernée par dérivation de la clé secrète SK au moyen de la donnée de diversification saisie. 5 Les moyens de saisie peuvent être sécurisés : il peut s'agir par exemple de l'interface utilisateur sécurisée déjà mentionnée, par exemple un clavier sécurisé de saisie (éventuellement de type clavier NIP ou "pin pad" selon l'appellation anglo-saxonne) ; en variante ou en complément, le fonctionnement de l'entité électronique concernée peut basculer dans un environnement d'exécution 10 de confiance (ou TEE pour "Trusted Execution Environment") lors de la saisie des données de diversification par l'utilisateur de l'entité électronique concernée. Lorsqu'une entité électronique reçoit des données chiffrées, et les déchiffre lors de l'étape E36 en utilisant la clé secrète SK, cette entité électronique peut ainsi afficher les données déchiffrées (représentant par exemple un 15 document électronique) sur son écran ; on peut prévoir en outre d'effectuer un tel affichage en mode sécurisé, c'est-à-dire ici lors du fonctionnement de cette entité électronique dans son environnement d'exécution de confiance (ou mode TEE). La figure 3 représente, sous forme de logigramme, une variante envisageable pour une partie du procédé de la figure 2. 20 Cette variante concerne les étapes E30 et suivantes, et le procédé décrit à présent débute de manière identique à ce qui a été décrit ci-dessus pour les étapes E2 à E28. Lorsque la clé secrète SK est générée à l'étape E28, l'entité électronique Co (utilisé par le meneur) procède à l'étape E129, pour chaque autre entité 25 électronique C1, Ci, CN, au chiffrement de la clé secrète SK au moyen de la clé publique PK1, PK1, PKN de cette autre entité électronique C1, Ci, CN, ce qui permet d'obtenir autant de versions chiffrées [SK]1, [SKJPK', [SKr" de la clé SK qu'il y a d'autres entités électronique C1, Ci, CN. Comme indiqué pour le mode de réalisation de la figure 2, la clé publique 30 PK1, PK1, PKN de chaque autre entité électronique C1, Ci, CN a été reçue au préalable par l'entité électronique Co, lors d'échanges antérieurs et/ou à l'étape E26. L'entité électronique Co émet alors toutes les versions chiffrées (préparées à l'étape E129) à destination du serveur S (étape E130), en associant 3044847 16 par exemple chaque version à l'identifiant ID; de l'entité électronique C1, C, CN à laquelle cette version est destinée (cet identifiant ID; ayant été reçu par l'entité électronique Co avec la requête d'ajout au groupe provenant de l'entité électronique concernée C1, C, CN, comme mentionné plus haut lors de la 5 description de l'étape E20). L'entité électronique Co peut également émettre à cette occasion son identifiant 'Do (ainsi qu'éventuellement les moyens d'authentification associés) et l'identifiant du groupe IDT. Le serveur S reçoit les versions chiffrées [Sie', [SKr', [SKr" et les mémorise, par exemple en association avec l'identifiant du groupe IDT (étape 10 E132). On remarque que le serveur S ne mémorise ainsi que des versions chiffrées de la clé secrète SK (et non la clé secrète SK en clair), ce qui protège cette clé secrète SK d'éventuelles attaques. Lorsque ces étapes sont effectuées (ce que le meneur peut indiquer à l'oral aux autres membres du groupe), chaque entité électronique C1, Ci, CN (autre 15 que l'entité électronique Co du meneur) émet à l'étape E134 une demande REQ.SK de la clé secrète SK à destination du serveur S, accompagnée de l'identifiant ID; de l'entité électronique concernée auprès du serveur S (ainsi éventuellement que des moyens d'authentification associés) et de l'identifiant du groupe IDT. 20 Le serveur S reçoit la demande REQ.SK à l'étape E136 et vérifie alors la validité de l'identifiant ID; (éventuellement en utilisant les moyens d'authentification également reçus à cette étape). Si l'identifiant ID; est bien vérifié, le serveur S lit (en mémoire) la version chiffrée [SK](' associé à cet identifiant ID; pour le groupe identifié par l'identifiant 25 du groupe IDT (également reçu à l'étape E136) et envoie cette version chiffrée [SK](' en réponse à l'entité électronique Ci. (Si l'identifiant ID; n'est pas vérifié ou que l'authentification échoue, le serveur S met fin au procédé sans effectuer les étapes suivantes.) L'entité électronique C; reçoit la version chiffrée à l'étape E140 et 30 procède à son déchiffrement (au moyen d'un algorithme cryptographique de déchiffrement) en utilisant sa clé privée pK;, afin d'obtenir la clé secrète SK et de la mémoriser (étape E142). Comme déjà indiqué, les étapes E134 à E142 sont effectuées par chaque entité électronique C1, C, CN (autre que l'entité électronique Co) de telle 3044847 17 sorte que toutes les entités électroniques C1, Ci, CN du groupe mémorisent ainsi la clé secrète (commune) SK. La clé secrète SK peut ainsi être utilisée à l'étape E144 par chacune des entités électroniques Co, C1, Ci, CN, par exemple pour chiffrer ou déchiffrer (ici au 5 moyen d'un algorithme de cryptographie symétrique) des documents (électroniques) à échanger entre les membres du groupe (i.e. entre les entités électroniques Co, C1, Ci, CN), comme expliqué plus haut à propos de l'étape E36. REVENDICATIONS1. Procédé d'échange de données au sein d'un groupe d'entités électroniques (Co, C1, Ci, CN) comprenant une première entité électronique (Co) et au moins une seconde entité électronique (C1, Ci, CN), caractérisé en ce qu'il comprend les étapes suivantes : - réception (E10), par la première entité électronique (Co) et en provenance d'un serveur distant de partage de document (S), d'une donnée de vérification (pKT) ; - obtention (E18), par la seconde entité électronique (Ci ; Ci ; CN), d'une donnée (PKT) caractéristique du groupe auprès du serveur distant de partage de documents (S) ; - vérification (E20 ; E26), par la première entité électronique (Co) et au moyen de la donnée de vérification (pKT), que la seconde entité électronique (C1 ; C1 ; CN) détient ladite donnée caractéristique (PKT) ; - en cas de vérification réussie, distribution (E30 ; E130) par la première entité électronique (Co) d'une clé cryptographique (SK) chiffrée destinée à la seconde entité électronique (Ci ; Ci ; CN) ; - réception (E36), par la seconde entité électronique (Ci ; Ci ; CN), de données chiffrées par la clé cryptographique (SK) ; - affichage des données échangées sur la seconde entité électronique (C1 ; Ci ; CN). 2. Procédé d'échange selon la revendication 1, comprenant une étape d'utilisation (E36 ; E144) de la clé cryptographique (SK) au sein d'un algorithme cryptographique mis en oeuvre par la seconde entité électronique (Ci ; C1 ; CN). 3. Procédé d'échange selon la revendication 1, comprenant les étapes suivantes : - saisie d'une donnée de diversification sur la seconde entité électronique (Ci ; C1; CN) - utilisation, au sein d'un algorithme cryptographique mis en oeuvre par la seconde entité électronique (C1 ; Ci ; CN), d'une clé dérivée à partir de la clé cryptographique (SK) et de la donnée de diversification saisie. 4. Procédé d'échange selon la revendication 2 ou 3, dans lequel l'algorithme cryptographique est un algorithme de chiffrement ou de déchiffrement. 3044847 19 5. Procédé d'échange selon l'une des revendications 2 à 4, dans lequel l'algorithme cryptographique est un algorithme cryptographique de cryptographie symétrique. 6. Procédé d'échange selon l'une des revendications 1 à 5, dans lequel 5 les données chiffrées sont reçues par la seconde entité électronique (Ci ; ; CN) en provenance d'une autre entité électronique (Co ; C1 ; ; CN) du groupe. 7. Procédé d'échange selon l'une des revendications 1 à 5, dans lequel les données chiffrées sont reçues par la seconde entité électronique (Cl ; ; CN) en provenance du serveur distant (S). 10 8. Procédé d'échange selon l'une des revendications 1 à 7, dans lequel l'étape d'obtention comprend une sous-étape d'authentification de la seconde entité électronique auprès du serveur en utilisant un algorithme cryptographique à clé asymétrique. 9. Procédé d'échange selon l'une des revendications 1 à 8, dans lequel 15 ladite donnée caractéristique est une clé publique (PKT) et dans lequel ladite donnée de vérification est une clé privée (pKT) associée à la clé publique (PKT). 10. Procédé d'échange selon la revendication 9, dans lequel l'étape de vérification comprend une sous-étape de transmission (E20) d'un défi (CH) de la première entité électronique (Co) à la seconde entité électronique (Ci ; ; CN), 20 une sous-étape de chiffrement (E23) du défi par la seconde entité électronique (Cl ; ; CN) et au moyen de la clé publique (PKT), une sous-étape de transmission (E24) du défi chiffré de la seconde entité électronique (Cl ; C1; CN) à la première entité électronique (Co) et une sous-étape de déchiffrement (E28) du défi chiffré par la clé privée (pKT) pour comparaison avec le défi transmis. 25 11. Procédé d'échange selon la revendication 9 ou 10, comprenant une étape de dérivation de la clé cryptographique (SK) à partir de la clé privée (pKT). 12. Procédé d'échange selon l'une des revendications 9 à 11, comprenant une étape de génération d'une nouvelle clé publique par la seconde entité électronique, une étape de chiffrement de ladite nouvelle clé publique en 30 utilisant la donnée caractéristique et une étape de transmission de la nouvelle clé publique chiffrée de la seconde entité électronique à la première entité électronique. 13. Procédé d'échange selon l'une des revendications 1 à 12, comprenant une étape de réception (E26) par la première électronique (Co), en 3044847 20 provenance de la seconde entité électronique (C1), d'un identifiant (TID;) au sein du groupe. 14. Procédé d'échange selon la revendication 13, dans lequel la clé cryptographique (SK) est générée par la première entité électronique (Co) en 5 utilisant ledit identifiant (TID;) au sein du groupe. 15. Procédé d'échange selon la revendication 13 ou 14, dans lequel la clé cryptographique (SK) est générée par la première entité électronique (Co) en utilisant une donnée de diversification convenue par des utilisateurs associés respectivement auxdites entités électroniques (Co ; C1; C1; CN) du groupe. 10 16. Procédé d'échange selon l'une des revendications 1 à 15, comprenant une étape (E30 ; E129) de chiffrement de la clé cryptographique (SK) au moyen d'une clé publique (PK;) associée à la seconde entité électronique (Ci). 17. Procédé d'échange selon l'une des revendications 1 à 16, dans lequel l'étape de distribution comprend une étape de transmission (E30) de la clé 15 cryptographique chiffrée ([SK]I1) de la première entité électronique (Co) à la seconde entité électronique (Ci). 18. Procédé d'échange selon l'une des revendications 1 à 16, dans lequel l'étape de distribution comprend une étape transmission (E130) de la clé cryptographique chiffrée ([SK]I1) au serveur (S) et, sur requête de la seconde 20 entité électronique (CO, une étape de transmission de la clé cryptographique chiffrée ([SK]l') du serveur (S) à la seconde entité électronique (Ci). 19. Procédé d'échange selon l'une des revendications 1 à 18, comprenant les étapes suivantes : - transmission (E12), de la seconde entité électronique (C1) au serveur 25 (S), d'un identifiant (ID;) de la seconde entité électronique (C1) et d'un identifiant (IDT) du groupe ; - transmission (E16), en réponse, de ladite donnée caractéristique (PKT) du serveur (S) à la seconde entité électronique (Ci). 20. Procédé d'échange selon l'une des revendications 1 à 19, dans 30 lequel la seconde entité électronique (Ci ; C1; CN) est conçue pour fonctionner, au moins lors des étapes d'obtention et d'échange, dans un environnement d'exécution de confiance. 21. Procédé d'échange selon l'une des revendications 1 à 20, dans lequel l'affichage des données est réalisé en mode sécurisé. 3044847 21 22. Procédé d'échange selon l'une des revendications 1 à 21, dans lequel la première entité électronique (Co) ou la seconde entité électronique (Ci ; C1 ; CN) contient une puce à microcircuit sécurisée.