FR 3105682 A1 20210625 FR 1915204 A 20191220 L’invention concerne un procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre : une sonde (1) d’acquisition de données, un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle une clé de session générée par la plateforme pour le chiffrement symétrique des données échangées est transmise à la sonde et au terminal, alors que la clé de séquence est connue uniquement de la sonde (1) et de la plateforme (3). Figure à publier avec l’abrégé : Fig. 1 PROCEDE ET SYSTEME DE GESTION D’ECHANGE DE DONNEES DANS LE CADRE D’UN EXAMEN MEDICAL DOMAINE DE L'INVENTION La présente invention concerne le domaine technique général de la sécurité des services. En particulier, la présente invention concerne un procédé permettant : l’authentification d’entités échangeant des données – par exemple des données de nature médicale et/ou des données de commande et/ou des données de contrôle – dans un réseau de communication, et le chiffrement des données échangées afin de garantir d’une part leur confidentialité et d’autre part leur fiabilité. L'invention concerne également un système d’authentification et de chiffrement associé. Plus précisément, l’invention concerne une application avancée des solutions d’acquisition et de transfert de données : l’échographie dématérialisée. ARRIERE PLAN DE L'INVENTION L’imagerie par ultrasons est utilisée dans de nombreuses procédures de diagnostic en raison de sa nature non invasive, de son coût relativement bas et de l’absence d’exposition du patient à des rayonnements ionisants nocifs. Depuis quelques années, de nouvelles solutions d’échographie dites « ultra-portables » ont été développées dans lesquelles des données acquises par une sonde – et éventuellement traitées – sont transmises sur une plateforme de stockage et/ou de traitement distante – connue sous le nom de « cloud » – en utilisant un réseau de communication – tel que le réseau Internet. En effet, le cloud permet de mutualiser les structures de conservation et de traitement des données, et dispose d’une puissance de calcul très importante. Toutefois, la transmission de données – données médicales acquises, données médicales traitées, données système représentatives de données de commande/contrôle de la sonde etc. – par l'intermédiaire d’un réseau informatique (tel qu’Internet) pose le problème crucial de l'intégrité, de l'authenticité et de l'inviolabilité de ces données, afin d'assurer: l’intégrité des données système : par exemple les instructions de pilotage de la sonde ne doivent pas pouvoir être modifiées par un tiers malveillant afin d’éliminer les risques sur la santé du patient, la confidentialité des données médicales qui ne doivent pas être accessibles par un tiers malveillant : seul le personnel autorisé (médecin, etc.) doit avoir accès à ces données médicales, et la fiabilité des données médicales : toutes les composantes (i.e. données acquises, données traitées, mesures, etc.) de l’examen doivent être cohérentes (par exemple des données médicales d’un examen précédent ne doivent pas interférer avec les données médicales d’un examen en cours / toutes les données médicales acquises d’un examen en cours doivent être traitées / etc.). Un but de la présente invention est de proposer un procédé et un système permettant de réaliser un examen échographique en situation de mobilité et intégrant une solution aux problèmes d’intégrité, de fiabilité et de confidentialité précités liés à l'échange de données par l'intermédiaire d’un réseau informatique tel qu’Internet. BREVE DESCRIPTION DE L'INVENTION A cet effet, l’invention concerne un procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre : une sonde d’acquisition de données, un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle : une clé de session générée par la plateforme est transmise à la sonde et au terminal, ladite clé de session permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen médical, et une clé de séquence générée par la plateforme est transmise à la sonde, ladite clé de séquence permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la plateforme et la sonde durant la procédure d’examen médical. Dans le cadre de la présente invention, les données de session échangées peuvent consister en : des données système incluant : des données de commande (i.e. instructions de pilotage) de la sonde et/ou du terminal et/ou de la plateforme, et/ou des données de contrôle de la sonde et/ou du terminal et/ou de la plateforme ; des données médicales incluant : des données médicales acquises (et/ou prétraitées) par la sonde, et/ou des données médicales traitées par le terminal et/ou la plateforme distante. Ces données de session peuvent être chiffrées/déchiffrées par la sonde ou le terminal ou la plateforme distante. L’information contenue dans ces données de session est donc accessible par les trois entités du système. Dans le cadre de la présente invention, les données de séquence peuvent consister en : des données de commande (i.e. instructions de pilotage) générées par la plateforme, et permettant de définir un paramétrage de la sonde en fonction du type d’examen à réaliser, des données de contrôle (généralement) générées par la sonde et destinées à être transmises à la plateforme (pour permettre un suivi ultérieur des paramètres d’acquisition de données, etc.). Ces données de séquence ne peuvent être chiffrées/déchiffrées que par la sonde ou la plateforme distante. Ainsi, le terminal n’est pas adapté pour extraire l’information contenue dans ces données de séquence. Le terminal peut être utilisé pour stocker ces données de séquence chiffrées (la capacité de stockage de la sonde étant limitée) avant leur transfert vers la sonde ou la plateforme, mais ne peut pas accéder à l’information contenue dans ces données de séquence. Le fait que la clé de séquence soit uniquement connue de la sonde et de la plateforme permet de garantir l’intégrité des données pilotant la dépose d’énergie ultrasonore aux tissus biologiques du patient. Des aspects préférés, mais non limitatifs de l’invention sont les suivants : la procédure d’authentification peut comprendre une première phase d’échange entre le terminal et la plateforme par l’intermédiaire du réseau informatique, ladite première phase comportant : l’émission par le terminal d’une requête d’examen vers la plateforme, l’émission par la plateforme d’un message de réponse vers le terminal, le message de réponse incluant : des données accessibles au terminal, et des informations de vérification accessibles uniquement par la sonde, les informations de vérification étant chiffrées par chiffrement asymétrique en utilisant une clé publique de sonde, et incluant : la clé de session et la clé de séquence (pour un échange sécurisé des données de séquence entre la plateforme et la sonde); l’étape d’émission d’une requête d’examen vers la plateforme peut comprendre une sous-étape consistant à chiffrer asymétriquement la requête en utilisant une clé publique de plateforme, le procédé comprenant en outre une étape de réception par la plateforme de la requête chiffrée, ladite étape de réception incluant une sous-étape consistant à déchiffrer la requête chiffrée en utilisant une clé privée de plateforme ; l’étape d’émission par la plateforme d’un message de réponse peut comprendre une sous-étape consistant à chiffrer asymétriquement le message de réponse en utilisant une clé publique de terminal, le procédé comprenant en outre une étape de réception par le terminal du message de réponse chiffré, ladite étape de réception incluant : une sous-étape consistant à déchiffrer le message de réponse chiffré en utilisant une clé privée de terminal, et éventuellement, une sous-étape consistant à stocker en mémoire les informations de vérification chiffrées contenues dans le message de réponse ; la requête d’examen peut comprendre un identifiant de sonde associé à la sonde et un identifiant de terminal associé au terminal, l’étape d’émission du message de réponse comprenant les sous-étapes consistant à : rechercher dans une table de sonde la clé publique de sonde à partir de l’identifiant de sonde, rechercher dans une table de terminal la clé publique de terminal à partir de l’identifiant de terminal, générer la clé de session, et la clé de séquence, intégrer la clé de session, la clé de séquence, la clé publique de terminal et l’identifiant de terminal aux informations de vérification, et chiffrer asymétriquement les informations de vérification en utilisant la clé publique de sonde ; la procédure d’authentification peut comprendre une deuxième phase d’échange entre la sonde et le terminal par l’intermédiaire des moyens de communication avec ou sans fil, ladite deuxième phase incluant : l’émission par le terminal d’un message de transfert vers la sonde, le message de transfert comportant : une demande d’appairage à la sonde pour permettre l’échange de données médicales entre la sonde et le terminal, les informations de vérification chiffrées par chiffrement asymétrique en utilisant la clé publique de sonde, l’émission par la sonde d’un message de contrôle vers le terminal, le message de contrôle comprenant la clé de session chiffrée par chiffrement asymétrique en utilisant une clé publique de terminal ; l’étape d’émission d’un message de transfert vers la sonde peut comprendre une sous-étape consistant à chiffrer asymétriquement le message de transfert en utilisant une clé publique de sonde, le procédé comprenant en outre une étape de réception par la sonde du message de transfert chiffré, ladite étape de réception incluant une sous-étape consistant à déchiffrer le message de transfert chiffré en utilisant une clé privée de sonde ; avantageusement : la demande d’appairage peut comprendre l’identifiant du terminal renseigné par le terminal, et les informations de vérification peuvent comprendre l’identifiant du terminal renseigné par la plateforme, l’étape de réception par la sonde du message de transfert incluant, postérieurement à l’étape consistant à déchiffrer le message de transfert, les sous-étapes consistant à : déchiffrer les informations de vérification en utilisant la clé privée de sonde, extraire, des informations de vérification déchiffrées, l’identifiant de terminal renseigné par la plateforme, extraire, de la demande d’appairage, l’identifiant de terminal renseigné par le terminal, comparer l’identifiant de terminal renseigné par la plateforme et l’identifiant de terminal renseigné par le terminal, émettre une alarme si les identifiants de terminal sont différents, passer à l’étape d’émission d’un message de contrôle sinon ; la deuxième phase peut comprendre en outre une étape de réception par le terminal du message de contrôle, ladite étape de réception incluant : une sous-étape consistant à déchiffrer la clé de session chiffrée en utilisant une clé privée de terminal, et une sous-étape consistant à extraire du message de contrôle la clé de session ; la deuxième phase peut comprendre en outre une étape d’émission par le terminal vers la sonde, d’un message de confirmation incluant la clé de session, ledit message de confirmation étant chiffré par chiffrement asymétrique en utilisant une clé publique de sonde ; la deuxième phase peut comprendre en outre une étape de réception du message de confirmation par la sonde, ladite étape de réception incluant les sous-étapes consistant à : déchiffrer le message de confirmation en utilisant une clé privée de sonde, extraire la clé de session du message de confirmation et la comparer à la clé de session contenue dans les informations de vérification, émettre une alarme si la clé de session du message de confirmation est différente de la clé de session contenue dans les informations de vérification, émettre un message de validation vers le terminal sinon, pour permettre la mise en œuvre de la procédure d’examen. L’invention concerne également un système pour l’échange de données lors d’une procédure d’examen d’un patient, le système comprenant : une sonde d’acquisition de données, un terminal apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre d’une procédure d’authentification (préalablement à la mise en œuvre de la procédure d’examen) dans laquelle une clé de session et une clé de séquence sont générées par la plateforme : la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen, la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen . Avantageusement, la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre des phases, étapes et sous-étapes du procédé de gestion défini ci-dessus. L’invention concerne également une sonde d’acquisition de données médicales lors d’une procédure d’examen d’un patient, ladite sonde étant apte à communiquer avec un terminal par l’intermédiaire de moyens de communication avec ou sans fil, ledit terminal étant apte à communiquer avec une plateforme distante par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que la sonde comprend des moyens pour la mise en œuvre d’une procédure d’authentification (préalablement à la mise en œuvre de la procédure d’examen) dans laquelle une clé de session et une clé de séquence sont générées par la plateforme : la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen, la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen. L’invention concerne également un terminal apte, lors d’une procédure d’examen d’un patient, à communiquer avec : une sonde d’acquisition de données médicales par l’intermédiaire de moyens de communication avec ou sans fil, et avec une plateforme distante par l’intermédiaire d’un réseau informatique tel qu’Internet, remarquable en ce que le terminal comprend des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme : la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre le terminal, la sonde et la plateforme durant la procédure d’examen, la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen. L’invention concerne également une plateforme distante pour le traitement et/ou le stockage de données lors d’une procédure d’examen médical d’un patient, ladite plateforme étant apte à communiquer avec un terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, ledit terminal étant apte à communiquer avec une sonde d’acquisition de données médicales par l’intermédiaire de moyens de communication avec ou sans fil, remarquable en ce que la plateforme comprend des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme : la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen, la clé de séquence étant transmise (uniquement) à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen. D'autres caractéristiques, buts et avantages de la présente invention ressortiront encore de la description qui suit, laquelle est purement illustrative et non limitative et doit être lue en regard des dessins annexés, sur lesquels : est une représentation schématique d’un système pour l’échange de données (i.e. données de commande, données de contrôle et/ou données de nature médicale) lors d’une procédure d’examen d’un patient, est une représentation schématique d’une première phase d’échange entre un terminal et une plateforme, ladite première phase étant mise en œuvre lors d’une procédure d’authentification, est une représentation schématique d’une deuxième phase d’échange entre une sonde et le terminal, la deuxième phase étant mise en œuvre lors de la procédure d’authentification. DESCRIPTION DETAILLEE DE L'INVENTION 1. Généralités 1.1. Chiffrement L’invention décrite dans la suite utilise la technique de cryptographie des données qui permet à une entité émettrice, de chiffrer les données transmises de sorte que seule une entité réceptrice authentique puisse déchiffrer ces données afin de les interpréter. De façon connue, on distingue la cryptographie symétrique, où une même clé secrète sert à chiffrer et déchiffrer les données échangées, et la cryptographie asymétrique, où un couple de clés distinctes – dites « clé publique » et « clé privée » – sont utilisées. La cryptographie symétrique est adaptée pour un dialogue au sein d'un couple émetteur/récepteur unique avec confiance réciproque car l'émetteur et le récepteur partagent secrètement la même clé. La cryptographie asymétrique est mieux adaptée pour établir un dialogue avec de nombreux intervenants potentiels. Dans le cadre de la présente invention, le procédé et le système décrits dans la suite sont basés sur la technique de cryptographie asymétrique qui est mieux adaptée aux besoins de l’application visée. En effet, comme il ressortira dans la suite, l’invention met en œuvre des échanges de données entre au moins trois entités distinctes, l’authenticité de l’une de ces entités devant être validée par les deux autres entités préalablement à l’échange de toute donnée. Pour mémoire, il est rappelé à titre indicatif que lorsque la clé privée est détenue par l’entité réceptrice, tout système émetteur peut chiffrer une donnée au moyen de la clé publique et la transmettre à l’entité réceptrice : seule l’entité réceptrice peut déchiffrer la donnée au moyen de la clé privée. Ceci assure la confidentialité du document transmis. A l’inverse, lorsque la clé privée est détenue par l’entité émettrice, elle est la seule à pouvoir chiffrer la donnée. Toute entité réceptrice peut déchiffrer la donnée à l’aide de la clé publique : ceci avec l’assurance que l’entité émettrice qui a transmis la donnée est celle qui possède la clé privée. 1. 2. Architecture matérielle En référence à la figure 1, on a illustré un exemple de système dans lequel le procédé d’authentification décrit dans la suite peut être mis en œuvre préalablement à l’échange de données entre les différentes entités du système. Le système comprend trois entités séparées : une sonde d’acquisition 1, un terminal 2 local connecté à la sonde par des moyens de communication avec ou sans fil, et une plateforme 3 distante connectée au terminal 2 par l’intermédiaire d’un réseau informatique tel qu’Internet. 1.2.1. Sonde La sonde 1 permet l’enregistrement de données médicales représentatives d’une région d’intérêt d’un patient (structures internes, organe, etc.). La sonde 1 est par exemple une sonde échographique incluant : une pluralité de transducteurs ultrasonores pour l’émission d’ondes ultrasonores, la réception d’échos ultrasonores et la conversion des échos ultrasonores reçus en signaux électriques formant les données, un calculateur pour l’éventuel prétraitement des données, une unité de communication (avec ou sans fil) pour l’émission des données acquises vers le terminal externe. Le traitement des données acquises par la sonde 1 permet l’extraction d’informations relatives au patient et/ou l’affichage d’une image de la région d’intérêt, etc. 1.2.2. Terminal Le terminal 2 permet l’éventuel traitement de certaines données médicales acquises par la sonde 1 et/ou l’affichage d’images de la région d’intérêt. Le terminal 2 est par exemple un terminal mobile tel qu’un téléphone portable notamment de type Smartphone, un assistant personnel (ou « PDA » , sigle de l’expression anglo-saxonne « Personal Digital Assistant » ), ou tout type de terminal mobile connu de l’homme du métier, tel qu’une montre connectée de type Apple Watch®. En variante, le terminal 2 peut être un terminal virtuel, c’est-à-dire une émulation d’un terminal mobile physique. Dans le cadre de la présente invention, le terme « terminal virtuel » englobe toute ressource virtualisée, et/ou une partie d'une entité réelle. Par exemple, le terminal virtuel peut être un programme d’ordinateur, une machine virtuelle, une instance implémentées dans un environnement de « cloud computing » , un sous-système d'appareil physique tel qu’un écran d’affichage, etc. Outre l’éventuel traitement de données acquises par la sonde 1 et/ou l’affichage de la région d’intérêt, le terminal 2 permet le transfert : des données émises par la sonde (données médicales, données de contrôle, etc.) vers la plateforme 3 et le transfert de données émises par la plateforme 3 (données de commande, etc.) vers la sonde 1. Les échanges de données entre le terminal 2 et la plateforme 3 sont mis en œuvre en utilisant un réseau informatique tel qu’Internet. 1.2.3. Plateforme distante La plateforme 3 permet : la mise en œuvre de traitements nécessitant une puissance de calcul dépassant les capacités du terminal 2, et/ou le stockage des données reçues (données médicales, données de contrôle, etc.), et/ou le pilotage de la sonde 1 en lui transmettant des instructions de commande par l’intermédiaire du terminal 2. La plateforme 3 comprend une unité de traitement comportant par exemple un/des ordinateur(s), un/des micro-ordinateur(s), une/des stations de travail, et/ou d'autres dispositifs connus de l’homme du métier incluant un/des processeur(s), un/des microcontrôleur(s), un/des automate(s) programmable(s), un/des circuit(s) intégré(s) spécifique(s) d'application, et/ou d'autres circuits programmables. La plateforme 3 comprend également une unité de stockage comportant une (ou plusieurs) mémoire(s) qui peu(ven)t être une mémoire ROM/RAM, une clé USB, une mémoire d’un serveur central. L’unité de traitement peut être intégrée ou séparée de l’unité de stockage. Par ailleurs, les différents éléments constituant l’unité de traitement (respectivement l’unité de stockage) peuvent être situés à des positions physiquement différentes à l’échelle d’un bâtiment, d’une ville, d’un pays ou d’un ou plusieurs continents. Outre la conservation de données associées à l’examen médical (données de nature médicale, données de contrôle, etc.), l’unité de stockage permet également de stocker des instructions de code de programmation destinées à exécuter certaines étapes du procédé d’authentification décrit dans la suite. Il en va de même de la sonde 1 et du terminal 2 qui comprennent chacun une mémoire respective pour le stockage d’instructions de code de programmation pour la mise en œuvre du procédé d’authentification présenté ci-dessous. 1.3. Cercle de confiance La sonde 1 et la plateforme 3 sont des ressources appartenant à un même espace de confiance. La sonde 1 et la plateforme 3 sont par exemple fabriquées par une même organisation, ou appartiennent à une même organisation (même entreprise ou groupement d’entreprises). L’unité de stockage de la plateforme 3 comprend une table répertoriant l’ensemble des sondes 1 fabriquées et/ou appartenant à l’organisation. Plus précisément, chaque sonde 1 est caractérisée par un identifiant de sonde (une suite de caractères) auquel est associée une clé publique de sonde permettant de chiffrer des messages à l’attention de la sonde 1. L’identifiant de sonde et la clé publique de sonde sont stockés dans la table de sonde contenue dans l’unité de stockage de la plateforme 3. Seule la sonde 1 dispose de la clé privée de sonde permettant de déchiffrer les messages chiffrés à partir de la clé publique de sonde. En d’autres termes, la clé privée de sonde est stockée uniquement dans la mémoire de la sonde 1. Le terminal 2 n’appartient, quant à lui, pas à la même organisation. Il est apte à fonctionner avec différentes sondes 1. Il appartient à un utilisateur ayant un compte client auprès de la plateforme 3 et lui permettant de s’identifier. Lors de la souscription d’un compte client, un identifiant de terminal, une clé privée de terminal et une clé publique de terminal sont générés. L’identifiant de terminal et la clé privée de terminal sont stockés dans la mémoire du terminal 2. L’identifiant de terminal et la clé publique de terminal sont conservés dans une table stockés dans l’unité de stockage de la plateforme 3. 2. Procédé d’authentification On va maintenant décrire plus en détail le principe de fonctionnement du procédé d’authentification selon l’invention. Ce procédé d’authentification est mis en œuvre entre les différentes entités (sonde 1, terminal 2, plateforme 3) du système préalablement à l’échange de données entre ces entités. On suppose dans la suite que l’utilisateur dispose d’un compte utilisateur préalablement souscrit auprès de la plateforme 3, et que le terminal 2 de l’utilisateur a été enregistré lors de la souscription du compte utilisateur. Lors de l’opération d’enregistrement : un clé publique de plateforme a été envoyée au terminal 2 par la plateforme distante ; cette clé publique de plateforme permet au terminal de chiffrer les messages à destination de la plateforme 3, une clé privée de terminal a été générée par le terminal 2 ; cette clé privée de terminal permet au terminal 2 de déchiffrer les messages reçus ayant été chiffrés en utilisant une clé publique de terminal (stockée dans l’unité de stockage de la plateforme 3) associée la clé privée de terminal. Comme indiqué ci-dessus : la mémoire de la sonde 1 contient : la clé privée de sonde permettant de déchiffrer des messages chiffrés avec l’une des clés publiques de sonde, et éventuellement la clé publique de plateforme permettant de chiffrer les messages à destination de la plateforme 3 ; la mémoire du terminal 2 contient : la clé privée de terminal permettant de déchiffrer les messages chiffrés avec l’une des clés publiques de terminal, et la clé publique de plateforme permettant de chiffrer les messages à destination de la plateforme 3 ; l’unité de stockage de la plateforme 3 contient : une table de sonde incluant l’identifiant de chaque sonde 1 de l’organisation et la clé publique de sonde associée à chaque identifiant de sonde, une table de terminal incluant l’identifiant de chaque terminal 2 et la clé publique de terminal associée à chaque identifiant de terminal, la clé privée de plateforme permettant de déchiffrer les messages chiffrés avec l’une des clés publiques de plateforme. Le procédé d’authentification comprend deux phases : une première phase de dialogue 100 entre le terminal 2 et la plateforme 3, et une deuxième phase de dialogue 200 entre le terminal 2 et la sonde 1, la deuxième phase 200 étant postérieure à la première phase 100. Avantageusement, ces deux phases 100, 200 peuvent être mises en œuvre à des instants éloignés dans le temps. Ainsi, il est possible d’exécuter la deuxième phase 200 même si le réseau informatique (tel qu’Internet) n’est plus accessible. En effet, la sonde 1 et le terminal 2 étant destinés à être utilisés en situation de mobilité, il y a un risque que dans certaines conditions d’utilisation, l’accessibilité au réseau informatique Internet ne soit plus assurée au cours de l’acquisition de données pour réaliser un examen. 2.1. Première phase de dialogue La première phase de dialogue 100 permet à la plateforme 3 d’authentifier la sonde 1 et le terminal 2. La première phase de dialogue 100 permet également de transférer de la plateforme vers le terminal des données de commande pour le pilotage de la sonde (instructions d'examen, insonification, déroulé d'examen, etc. régissant l'énergie apportée par la sonde au patient). Ces données de commande sont avantageusement stockées dans le terminal pour permettre l’exécution du (ou des) examen(s) médical (médicaux) sans nécessiter une connexion à la plateforme. La première phase 100 comprend les étapes suivantes : émission 110 d’une requête d’examen par le terminal 2, et réception 120 de la requête d’examen par la plateforme 3, émission 130 par la plateforme 3, d’un message de réponse incluant des informations de vérification chiffrées en utilisant la clé publique de sonde, et réception 140 du message de réponse par le terminal 2. 2.1.1. Emission/réception d’une requête Plus précisément, lorsque l’utilisateur souhaite effectuer un examen, il saisit sur les moyens de saisie du terminal 2 des renseignements concernant l’examen, et notamment : l’identifiant du terminal, et l’identifiant de la sonde destinée à être utilisée pour l’examen. La requête peut également comprendre des informations personnelles relatives au patient (nom, prénom, numéro de dossier, etc.) et/ou à l’examen (date d’acquisition des données d’examen, type d’examen, etc.). A partir des renseignements saisis par l’utilisateur, le terminal 2 génère 111 une requête d’examen à destination de la plateforme 3. Cette requête comprend les identifiants du terminal 2 et de la sonde 1. Avantageusement, cette requête peut être chiffrée 112 à partir de la clé publique de plateforme. Ceci permet de limiter les risques d’obtention de renseignements critiques par un tiers malveillant ayant intercepté toutes les communications, par exemple pour usurper l'identité du terminal 2. La requête générée et chiffrée est envoyée 113 par le terminal 2. La plateforme 3 reçoit 121 la requête émise par le terminal 2, et la déchiffre 122 en utilisant la clé privée de plateforme. Une fois la requête déchiffrée, la plateforme 3 extrait 123 les identifiants de la sonde 1 et du terminal 2. Ainsi dans un mode de réalisation, l’étape d’émission/réception 110, 120 d’une requête comprend les sous-étapes consistant à : pour le terminal 2 : générer 111 une requête d’examen incluant les identifiants du terminal 2 et de la sonde 1, chiffrer 112 la requête à partir de la clé publique de plateforme, envoyer 113 la requête chiffrée à la plateforme 3, pour la plateforme 3 : recevoir 121 la requête, déchiffrer 122 la requête à partir de la clé privée de plateforme et extraire 123 les identifiants de sonde et de terminal. 2.1.2. Emission/réception d’un message de réponse 2.1.2.1. Emission 130 La plateforme 3 vérifie que l’utilisateur dispose de droits d’utilisation du système en fonction de l’identifiant de terminal notamment. La plateforme 3 recherche 131 dans la table de sonde, la clé publique de sonde associée à l’identifiant de sonde. Cette clé publique de sonde est destinée à être transmise au terminal 2 dans le message de réponse pour lui permettre de chiffrer les messages à destination de la sonde 1 avec ladite clé publique de sonde. Cette clé publique de sonde est également utilisée par la plateforme 3 pour chiffrer des informations de vérification incluses dans le message de réponse et destinées à la sonde 1, l’accessibilité à ces informations de vérification n’étant pas souhaitée pour le terminal 2. En effet, comme rappelé ci-dessus seule la clé privée de sonde permet de déchiffrer les messages chiffrés à l’aide d’une clé publique de sonde. Ainsi, même si le terminal 2 dispose de la clé publique de sonde, il n’est pas en mesure de déchiffrer les informations de vérification contenues dans le message de réponse et ayant été chiffrées avec la clé publique de sonde. Le fait de transmettre dans le message de réponse, des informations de vérification déchiffrables uniquement par la sonde 1 permet d’assurer l’authentification ultérieure du terminal 2 par la sonde 1 lors de la mise en œuvre de la deuxième phase 200. La plateforme 3 recherche 131 également dans la table de terminal, la clé publique de terminal associée à l’identifiant de terminal. Cette clé publique de terminal est intégrée aux informations de vérification à destination de la sonde 1 incluses dans le message de réponse. La clé publique de terminal est également utilisée par la plateforme 3 pour chiffrer le message de réponse. La plateforme 3 génère 132 ensuite le message de réponse. Ce message comprend : d’une part la clé publique de sonde pour permettre au terminal 2 de chiffrer les messages adressés à la sonde 1 lors de la mise en œuvre de la deuxième phase 200, et d’autre part, les informations de vérification à destination de la sonde 1 et auxquelles le terminal 2 ne doit pas pouvoir accéder ; ces informations de vérification comprennent notamment la clé publique du terminal, l’identifiant du terminal, une clé de session, et une clé de séquence, etc. La clé de session est utilisée pour chiffrer/déchiffrer les données échangées selon un mode de cryptographie symétrique (la clé de session est utilisée à la fois pour chiffrer et déchiffrer les données). La clé de session est enregistrée dans l’unité de stockage de la plateforme 3. Elle sera utilisée durant la mise en œuvre de l’examen pour : chiffrer/déchiffrer les messages adressés à/reçus de la sonde 1 chiffrer/déchiffrer les messages adressés au/reçus du terminal 2. La durée de validité de la clé de session dépend du type d’application visée. Elle peut être de quelques dizaines de minutes pour un examen pour un patient, ou de plusieurs heures/jours pour une session d’imagerie dans un véhicule d’urgence (en mobilité), voire à une prescription de traitement pour un patient et une durée donnée. Avantageusement, une clé de séquence est incluse dans les informations de vérification. Elle est réservée à l’échange d’information entre la plateforme et la sonde, via le terminal, en particulier d’informations sensibles de commande telles que les instructions de pilotage de la sonde. En effet, la (ou les) séquence(s) de paramétrage de la sonde (pour l’acquisition des données dans le cadre de l’examen) ne peuvent pas être envoyées directement de la plateforme vers la sonde, notamment du fait de la capacité mémoire limitée de la sonde. C’est pourquoi le terminal peut être utilisé pour stocker cette (ou ces) séquence(s), et pour la (ou les) transmettre séquentiellement par morceau à la sonde. La durée de validité de la clé de séquence est la même que la clé de session. Le message de réponse généré est chiffré 133 en utilisant la clé publique de terminal. Le fait de chiffrer le message de réponse en utilisant la clé publique de terminal permet d’éviter les risques d’interception frauduleuse de renseignements critiques pour le système, ceux-ci étant chiffrés et donc inexploitables en l’état. Cela permet en outre à la plateforme de s’assurer que le terminal 2 ayant généré la requête et que le terminal associé à l’identifiant contenu dans la requête constituent bien une seule et même entité (seul le terminal dont l’identifiant a été indiqué dans la requête disposant de la clé privée de terminal permettant de déchiffrer le message de la plateforme). Une fois chiffré, le message de réponse est envoyé 134 par la plateforme 3. Ainsi dans un mode de réalisation, l’étape d’émission 130 d’un message de réponse comprend les sous-étapes consistant à : rechercher 131 dans la table de sonde, la clé publique de sonde associée à l’identifiant de sonde, rechercher 131 dans la table de terminal, la clé publique de terminal associée à l’identifiant de terminal, générer 132 le message de réponse, le message de réponse comprenant : la clé publique de sonde, et des informations de vérification à destination de la sonde (clé publique du terminal, identifiant du terminal, clé de session, etc.), lesdites informations de vérification étant chiffrées en utilisant la clé publique de sonde, chiffrer 133 le message de réponse en utilisant la clé publique de terminal, envoyer 134 le message de réponse chiffré vers le terminal externe. 2.1.2.2. Réception 140 du message de réponse Le terminal 2 reçoit le message de réponse, le déchiffre 141 et le stocke 143 dans la mémoire du terminal 2 pour une utilisation ultérieure des données qu’il contient lors de la mise en œuvre de la deuxième phase de dialogue 200. Ainsi, la mise en œuvre de la deuxième phase 200 peut être éloignée dans le temps de la mise en œuvre de la première phase 100. Ceci permet de ne pas conditionner la mise en œuvre de la deuxième phase 200 à l’accessibilité au réseau informatique de type Internet. En d’autres termes, l’utilisateur peut exécuter la première phase 100 lorsqu’il dispose d’un accès au réseau informatique, et mettre en œuvre la deuxième phase 200 durant une situation de mobilité au cours de laquelle l’accessibilité au réseau informatique n’est pas garantie. Le lecteur appréciera que plusieurs premières phases 100 peuvent être effectuées consécutivement, pour une même (ou différentes) sonde(s) 1 associée(s) à un terminal 2, chaque première phase 100 correspondant à un examen respectif, d’un patient. Par exemple, si l’utilisateur sait qu’il doit réaliser huit examens planifiés au cours d’une journée de travail, il peut préalablement à ses déplacements, requérir la réception de huit messages de réponse correspondant chacun à un examen respectif. Pour résumer et en référence à la figure 2, l’étape de réception 140 du message de réponse par le terminal 2 comprend les sous-étapes consistant à : déchiffrer 141 le message de réponse, extraire 142 la clé publique de sonde et les informations de vérification chiffrées (avec la clé publique de sonde), stocker 143 la clé publique de sonde et les informations de vérification chiffrées. 2.2. De uxième phase de dialogue 200 La deuxième phase de dialogue 200 permet à la sonde 1 d’authentifier le terminal 2 et la plateforme 3. La deuxième phase 200 comprend les étapes suivantes : émission 210 par le terminal 2 d’un message de transfert contenant les informations de vérification chiffrées avec la clé publique de sonde, et réception 220 du message de transfert par la sonde 1, émission 230 par la sonde 1 d’un message de contrôle, le message de contrôle incluant des informations chiffrées avec la clé publique du terminal 2, et réception 230 par le terminal 2 du message de contrôle, émission 240 par le terminal 2 d’un message de confirmation, et réception 240 par la sonde 1 du message de confirmation, émission 250 par la sonde 1 d’un message de validation, et réception 250 du message de validation par le terminal 2. 2.2.1. Emission/réception du message de transfert La première étape de la deuxième phase consiste en l’émission 210 par le terminal 2 d’un message de transfert incluant les informations de vérification chiffrées à partir de la clé publique de sonde. Plus précisément, le terminal 2 génère 211 le message de transfert en intégrant dans celui-ci : une demande d’appairage incluant l’identifiant du terminal 2, et les informations de vérification extraites de la mémoire du terminal 2, ces informations de vérification ayant été chiffrées par la plateforme 3 à l’aide de la clé publique de sonde. Le terminal 2 chiffre 212 ensuite le message de transfert en utilisant la clé publique de sonde, et l’envoie 213 à la sonde 1. La sonde 1 reçoit 221 le message de transfert, le déchiffre 222 en utilisant la clé privée de sonde qu’elle est la seule à détenir, et extrait 223 du message : l’identifiant du terminal, ainsi que les informations de vérification chiffrées par la plateforme. 2.2.2. Emission/réception 230 du message de contrôle La sonde 1 déchiffre également les informations de vérification (chiffrées par la plateforme 3) en utilisant la clé privée de sonde. La sonde 1 extrait l’identifiant de terminal des informations de vérification, et le compare à l’identifiant de terminal indiqué par le terminal 2 dans le message de transfert : ceci permet à la sonde 1 de vérifier que l’identifiant de terminal indiqué par le terminal 2 correspond bien à l’identifiant de terminal indiqué par la plateforme 3. Si les deux identifiants correspondent, alors la sonde 1 possède un a priori positif sur la fiabilité du terminal 2. La sonde génère alors un message de contrôle permettant à la sonde 1 de confirmer l’authenticité du terminal 2. Pour générer le message de contrôle, la sonde 1 extrait des informations de vérification, et stocke dans sa mémoire : la clé de session (qui sera utilisée pour chiffrer/déchiffrer les messages envoyés/reçus durant l’examen), et la clé publique de terminal. La clé de terminal est utilisée pour chiffrer 232 le message de contrôle. Le fait de chiffrer le message de contrôle en utilisant la clé publique de terminal fournie par la plateforme permet à la sonde de garantir l’authenticité du terminal, seul celui-ci disposant de la clé privée permettant de déchiffrer le message de contrôle. La clé de session est quant à elle utilisée comme message de test pour confirmer l’identité du terminal 2 : si le terminal 2 correspondant bien à son identifiant, alors il est le seul à pouvoir déchiffrer le message de contrôle (chiffré avec la clé publique de terminal) et en extraire le message de test (i.e. la clé de session). Une fois chiffré, le message de contrôle est envoyé 232 au terminal 2. Le terminal 2 reçoit 233 le message de contrôle, le déchiffre 233 en utilisant la clé privée de terminal et extrait 234 la clé de session. La clé de session est stockée dans la mémoire du terminal 2 (elle sera utilisée pour chiffrer/déchiffrer les messages envoyés ou reçus durant l’examen). 2.2.3. Emission/réception 240, 250 des messages de confirmation et de validation Le terminal 2 génère un message de validation à destination de la sonde 1 pour s’authentifier. Ce message de validation comprend la clé de session. Le message de validation est chiffré en utilisant la clé publique de sonde, et envoyé à la sonde 1. La sonde reçoit le message de validation, le déchiffre en utilisant la clé privée de sonde, et extrait la clé de session. Cette clé de session est comparée à la clé de session stockée dans la mémoire de la sonde 1. Si la clé de session reçue dans le message de validation correspond à la clé de session contenue dans la mémoire de la sonde 1, alors l’authentification du terminal 2 est confirmée. La sonde émet 250 un message de confirmation au terminal 2 : toutes les entités (sonde 1, terminal 2, plateforme 3) du système satisfont les conditions de confiance requises, et l’examen peut débuter. 3. Examen Durant l’examen, toutes les données transmises entre les différentes entités sont chiffrées en utilisant la clé de session. Les instructions de contrôle de la sonde sont transmises par la plateforme au sein d’un message chiffré par la clé de séquence (connue uniquement de la sonde et de la plateforme). La clé de session garantit : l’intégrité des données système d’une part, et la confidentialité des données médicales d’autre part : seule la sonde 1, le terminal 2 et la plateforme 3 authentifiés disposant de la clé de session permettant l’accès aux données, et la fiabilité des données médicales : la clé de session étant unique pour chaque examen (ainsi si plusieurs examens successifs sont effectués par un même utilisateur pour un même patient, il n’y a aucun risque de confusion dans les données associées à ces différents examens, la correspondance entre la clé de session et l’examen étant biunivoque). La clé de séquence garantit l’intégrité des données de pilotage de la sonde qui dépose de l’énergie ultrasonore dans le tissu biologique du patient. Lorsque l’examen est terminé, la clé de session est effacée de la mémoire de la sonde 1, de la mémoire du terminal 2, et de l’unité de stockage de la plateforme 3, de même, la clé de séquence est effacée de la mémoire de la sonde 1 et de la plateforme 3. Ainsi l’accessibilité aux données par les différentes entités du système est limitée dans le temps à la mise en œuvre de l’examen. La fin d’examen peut être programmée par l’utilisateur en utilisant le terminal 2. Dans ce cas, le terminal 2 envoie à la sonde 1 et à la plateforme 3 un message de commande de fin d’examen. Si certaines données médicales relatives à l’examen n’ont pas été acquises par la sonde 1 et/ou n’ont pas été traitées par la plateforme 3, la sonde 1 et la plateforme 3 peuvent envoyer un message d’acceptation indiquant que la commande de fin d’examen a bien été prise en compte et que celle-ci sera effective dès finalisation de l’acquisition et/ou du traitement des données médicales par la sonde 1 et/ou la plateforme 3. 4. Conclusions L’invention définie précédemment permet l’échange sécurisé et fiabilisé de données entre différents entités d’un système utilisant un réseau informatique de type Internet. Le lecteur aura compris que de nombreuses modifications peuvent être apportées à l’invention décrite précédemment sans sortir matériellement des nouveaux enseignements et des avantages décrits ici (par exemple le procédé pourrait ne pas comprendre l’utilisation d’une clé de séquence). Par conséquent, toutes les modifications de ce type sont destinées à être incorporées à l’intérieur de la portée des revendications jointes.   Procédé de gestion des échanges de données durant une procédure d’examen médical d’un patient, le procédé permettant la gestion des échanges de données entre : une sonde (1) d’acquisition de données médicales, un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, caractérisé en ce que le procédé comprend, préalablement à la mise en œuvre de la procédure d’examen, la mise en œuvre d’une procédure d’authentification dans laquelle : une clé de session générée par la plateforme est transmise à la sonde et au terminal, ladite clé de session permettant le chiffrement/déchiffrement symétrique de données de session échangées durant la procédure d’examen médical, et une clé de séquence générée par la plateforme est transmise à la sonde, ladite clé de séquence permettant le chiffrement/déchiffrement symétrique de données de séquence échangées entre la plateforme et la sonde durant la procédure d’examen médical. Procédé de gestion selon la revendication 1, dans lequel la procédure d’authentification comprend une première phase (100) d’échange entre le terminal (2) et la plateforme (3) par l’intermédiaire du réseau informatique, ladite première phase (100) comportant : l’émission (110) par le terminal (2) d’une requête d’examen vers la plateforme (3), l’émission (130) par la plateforme (3) d’un message de réponse vers le terminal (2), le message de réponse incluant : des données accessibles au terminal (2), et des informations de vérification accessibles uniquement par la sonde (1), les informations de vérification étant chiffrées par chiffrement asymétrique en utilisant une clé publique de sonde et incluant la clé de session et la clé de séquence. Procédé selon la revendication 2, dans lequel : l’étape d’émission (110) d’une requête d’examen vers la plateforme (3) comprend une sous-étape consistant à chiffrer (112) asymétriquement la requête en utilisant une clé publique de plateforme, le procédé comprenant en outre : une étape de réception (120) par la plateforme (3) de la requête chiffrée, ladite étape de réception (120) incluant une sous-étape consistant à déchiffrer (122) la requête chiffrée en utilisant une clé privée de plateforme. Procédé selon l’une quelconque des revendications 2 ou 3, dans lequel : l’étape d’émission (130) par la plateforme (3) d’un message de réponse comprend une sous-étape consistant à chiffrer (133) asymétriquement le message de réponse en utilisant une clé publique de terminal, le procédé comprenant en outre : une étape de réception (140) par le terminal (2) du message de réponse chiffré, ladite étape de réception (140) incluant : une sous-étape consistant à déchiffrer (141) le message de réponse chiffré en utilisant une clé privée de terminal, et éventuellement, une sous-étape consistant à stocker (143) en mémoire les informations de vérification chiffrées contenues dans le message de réponse. Procédé selon l’une quelconque des revendications 2 à 4, dans lequel la requête d’examen comprend un identifiant de sonde associé à la sonde et un identifiant de terminal associé au terminal, l’étape d’émission (130) du message de réponse comprenant les sous-étapes consistant à : rechercher (131) dans une table de sonde la clé publique de sonde à partir de l’identifiant de sonde, rechercher (131) dans une table de terminal la clé publique de terminal à partir de l’identifiant de terminal, générer la clé de session, et la clé de séquence, intégrer la clé de session, la clé de séquence, la clé publique de terminal et l’identifiant de terminal aux informations de vérification, et chiffrer (133) asymétriquement les informations de vérification en utilisant la clé publique de sonde. Procédé de gestion selon l’une quelconque des revendications 2 à 5, dans lequel la procédure d’authentification comprend une deuxième phase (200) d’échange entre la sonde (1) et le terminal (2) par l’intermédiaire des moyens de communication avec ou sans fil, ladite deuxième phase (200) incluant : l’émission (210) par le terminal (2) d’un message de transfert vers la sonde (1), le message de transfert comportant : une demande d’appairage à la sonde (1) pour permettre l’échange de données entre la sonde (1) et le terminal (2), les informations de vérification chiffrées par chiffrement asymétrique en utilisant la clé publique de sonde, l’émission (230) par la sonde (1) d’un message de contrôle vers le terminal (2), le message de contrôle comprenant la clé de session chiffrée par chiffrement asymétrique en utilisant une clé publique de terminal. Procédé de gestion selon la revendication 6, dans lequel l’étape d’émission (210) d’un message de transfert vers la sonde (1) comprend une sous-étape consistant à chiffrer (212) asymétriquement le message de transfert en utilisant une clé publique de sonde, le procédé comprenant en outre : une étape de réception (220) par la sonde (1) du message de transfert chiffré, ladite étape de réception (220) incluant une sous-étape consistant à déchiffrer (222) le message de transfert chiffré en utilisant une clé privée de sonde. Procédé de gestion selon la revendication 7, dans lequel : la demande d’appairage comprend l’identifiant du terminal renseigné par le terminal (2), et les informations de vérification comprennent l’identifiant du terminal renseigné par la plateforme (3), l’étape de réception (220) par la sonde (1) du message de transfert incluant, postérieurement à l’étape consistant à déchiffrer (222) le message de transfert, les sous-étapes consistant à : déchiffrer les informations de vérification en utilisant la clé privée de sonde, extraire, des informations de vérification déchiffrées, l’identifiant de terminal renseigné par la plateforme (3), extraire, de la demande d’appairage, l’identifiant de terminal renseigné par le terminal (2), comparer l’identifiant de terminal renseigné par la plateforme (3) et l’identifiant de terminal renseigné par le terminal (2), émettre une alarme si les identifiants de terminal sont différents, passer à l’étape d’émission d’un message de contrôle sinon. Procédé de gestion selon l’une quelconque des revendications 6 à 8, dans lequel la deuxième phase (200) comprend en outre une étape de réception par le terminal (2) du message de contrôle, ladite étape de réception incluant : une sous-étape consistant à déchiffrer (233) la clé de session chiffrée en utilisant une clé privée de terminal, et une sous-étape consistant à extraire (234) du message de contrôle la clé de session. Procédé de gestion selon l’une quelconque des revendications 6 à 9, dans lequel la deuxième phase (200) comprend en outre une étape d’émission (240) par le terminal (2) vers la sonde (1), d’un message de confirmation incluant la clé de session, ledit message de confirmation étant chiffré par chiffrement asymétrique en utilisant une clé publique de sonde. Procédé de gestion selon la revendication 10, dans lequel la deuxième phase (200) comprend en outre une étape de réception du message de confirmation par la sonde (1), ladite étape de réception incluant les sous-étapes consistant à : déchiffrer le message de confirmation en utilisant une clé privée de sonde, extraire la clé de session du message de confirmation et la comparer à la clé de session contenue dans les informations de vérification, émettre une alarme si la clé de session du message de confirmation est différente de la clé de session contenue dans les informations de vérification, émettre (250) un message de validation vers le terminal (2) sinon, pour permettre la mise en œuvre de la procédure d’examen. Système pour l’échange de données lors d’une procédure d’examen d’un patient, le système comprenant : une sonde (1) d’acquisition de données, un terminal (2) apte à communiquer avec la sonde par l’intermédiaire de moyens de communication avec ou sans fil, une plateforme (3) distante apte à communiquer avec le terminal par l’intermédiaire d’un réseau informatique tel qu’Internet, caractérisé en ce que la sonde (1), le terminal (2) et la plateforme (3) comprennent des moyens pour la mise en œuvre d’une procédure d’authentification, préalablement à la mise en œuvre de la procédure d’examen, dans laquelle une clé de session et une clé de séquence sont générées par la plateforme : la clé de session étant transmise à la sonde et au terminal durant la procédure d’authentification, et permettant le chiffrement/déchiffrement symétrique de données de session échangées entre la sonde, le terminal et la plateforme durant la procédure d’examen, la clé de séquence étant transmise à la sonde durant la procédure d’authentification, et permettant le chiffrement/déchiffrement de données de séquence échangées entre la sonde et la plateforme durant la procédure d’examen. Système selon la revendication 12, dans lequel la sonde, le terminal et la plateforme comprennent des moyens pour la mise en œuvre du procédé de gestion défini aux revendications 1 à 11.