Brevet FR2930391A1 — publié le 20091023

TERMINAL D'AUTHENTIFICATION FORTE D'UN UTILISATEUR La présente invention se rapporte au domaine de la sécurisation, du stockage, du contrôle d'accès et de la diffusion de données numériques. La présente invention se rapporte plus particulièrement à un terminal permettant de réaliser une authentification forte d'un utilisateur souhaitant accéder à des services fournis par un serveur. Dans le domaine de la sécurisation de l'accès à des données, l'art antérieur connaît déjà par les publications ISO/CEI 9594-8, RFC -2459 et RFC-2510, la réalisation de cryptosystèmes standards à clé publique. Le principe du chiffrement avec un système à clé publique repose sur l'existence d'un couple de clés noté Ke (clé privée) et Kq (clé publique), de valeurs différentes mais mathématiquement liées, appartenant à une même entité propriiétaire. Kq est une clé publique qui est publiée dans une sorte d'annuaire comme appartenant à une certaine entité. Ainsi, n'importe qui peut récupérer cette clé Kq, en tester l'origine, et l'utiliser pour chiffrer un message qu'elle veut envoyer de manière confidentielle à l'entité propriétaire de la clé Kq. Ke est une clé privée qui n'est connue que de son propriétaire et qui doit être maintenue secrète. L'entité propriétaire de la clé Kq utilise la clé Ke pour déchiffrer les messages qu'elle reçoit et qui ont été chiffrés avec Kq. Les exemples les plus connus des protocoles cryptographiques asymétriques dits à clé publique sont: - le système RSA (du nom des inventeurs Rivest, Shamir et Adleman) basé sur la factorisation d'entiers ; - l'échange de clé de Diffie-Hellman ; - le système d'El Gamal basé sur le logarithme discret. Ce procédé, largement adopté, s'appuie sur des schémas de chiffrements et de signatures à clés publiques mettant en oeuvre au moins une infrastructure de clé publique, que l'on désignera par la suite par PKI (pour Public Key Infrastructure en langue anglaise), qui assure l'authenticité des clés publiques utilisées. Une autorité de certification, désignée par la suite par CA, délivre, après avoir réalisé un certain nombre de contrôles, un certificat numérique normalisé X.509 à une entité candidate, et certifie, en apposant sa signature privée sur ledit certificat numérique, la relation qui existe entre une clé publique et l'identité de l'entité légitime ayant accès à la clé privée correspondante. Dans ce contexte on suppose que les entités intervenant dans l'échange de flux de données chiffrées connaissent préalablement leurs identités et leurs clés publiques respectives qui sont enregistrées et publiées sur ledit certificat numérique. Un certificat numérique conforme au format X.509v3 se compose des principaux champs suivants : - Version : indique à quelle version de X.509 correspond ce certificat. Serial number : numéro de série du certificat propre à chaque PKI. - Signature Algo ID : identifiant du type de signature utilisée. Issuer Name : Nom distinctif du CA qui émet le certificat. - Validity period : période de validité. - Subject Name : Nom distinctif du détenteur de la clé publique. Subject public Key info : Informations (valeur, type d'algorithme...) sur la clé publique de ce certificat. Issuer Unique ID : identifiant unique de l'émetteur de ce certificat. - Subject Unique ID : identifiant unique du détenteur de la clé publique. - Signature : Signature numérique du CA sur les champs précédents. Par ailleurs, l'art antérieur connaît notamment par les publications IFIPS- 197, RFC 2405, la réalisation de cryptosystèmes standards à clé secrète. Le principe du chiffrement avec un système à clé secrète repose sur l'existence d'une unique clé secrète notée K (avec K=Ke=Kq) utilisée à la fois pour le chiffrement et le déchiffrement des données. En pratique, on utilise principalement des chiffrements par flux (désigné par Stream Cipher en langue anglaise) lorsque la vitesse de traitement est essentielle (téléphonie, liaison entre unité centrale...) ; lorsque la sécurité prédomine, on utilise plutôt des chiffrements par blocs (désigné par Block Cipher en langue anglaise). De tels cryptosystèmes ont l'avantage principal d'être efficaces en termes de temps de calcul, tant pour le chiffrement que pour le déchiffrement. Les exemples les plus connus des protocoles cryptographiques symétriques (à clé secrète) sont : - le système DES (de l'anglais Data Encryption Standard, RFC 2405) ; - le système AES (de l'anglais Advanced Encryption Standard, FIPS-197); - le système 3-DES ; - le système IDEA ; - le système RC6/RC4 (flux). L'inconvénient majeur de tels cryptosystèmes, tant à clé publique qu'à clé secrète, réside dans la complexité de l'administration et la gestion des clés. Ce qu'on entend par la gestion des clés rattachées à tout cryptosystème ce sont les aspects de sécurisation liés au stockage, à la distribution, à l'échange, à l'archivage, à la diversification fonctionnelle, à la restauration, au remplacement, à la révocation et à l'historique des clés. A cet inconvénient vient s'ajouter une faille bien plus importante encore des cryptosystèmes actuels lorsqu'il s'agit notamment de la lecture par un utilisateur des données sécurisées. Dans le cas d'un cryptosystème à clé publique, les données sécurisées sont systématiquement dissociées de l'authentification lors de son interprétation par un utilisateur : Il y a un risque réel d'usurpation et/ou d'altération des contenus sans aucun moyen de contrôle efficace. Il est ainsi délicat de déterminer qui a accédé ou à modifié des données sécurisées. Dans le cas d'un cryptosystème à clé secrète, le risque est quant à lui plus axé sur la confidentialité des données. Lors de l'interprétation par un utilisateur des données sécurisées, (déchiffrement des données), ces dernières se trouvent vulnérables pendant toute la période de lecture : il existe donc un risque réel d'interception, d'écoute passive frauduleuse ou encore de détournement de ces données. De plus, le manque d'interopérabilité entre les cryptosystèmes entre eux, qu'il s'agisse de PKI ou de cryptosystèmes à clé secrète, représente un obstacle essentiel à leur déploiement au sein des entreprises. On notera la complexité bien connue de l'art antérieur des certifications croisées entre PKI ou encore de leur incompatibilité avec des techniques de chiffrement d'un cryptosystème à clé secrète. Il est ainsi délicat pour une entité de mettre en place une politique de sécurité avec plusieurs autres entités utilisant des cryptosystèmes distincts. L'invention porte ainsi sur un terminal d'authentification forte d'un utilisateur, comprenant: - un lecteur de paramètres d'authentification d'un utilisateur ; - un récepteur d'un signal de géolocalisation ; -une interface de communication avec un autre appareil ; -un processeur, extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication. Selon une variante, le processeur extrait la position du terminal à partir du signal de géolocalisation et inclut la position extraite dans les données chiffrées. Selon encore une variante, le terminal comprend une mémoire non volatile mémorisant une clé de chiffrement symétrique, le processeur générant les données chiffrées en utilisant cette clé de chiffrement symétrique. Selon une autre variante, le terminal comprend : - une mémoire de stockage accessible par l'intermédiaire de l'interface de communication ; - une interface de commande par l'intermédiaire de laquelle un utilisateur peut commander la fin d'une session d'utilisation du terminal ; -le processeur commandant l'effacement de la mémoire de stockage à la fin de chaque session d'utilisation. Selon encore une variante, le terminal mémorise des applications d'interprétation de différents types de fichiers mémorisés dans la mémoire de stockage, le processeur étant apte à exécuter ces applications, apte à générer une image du contenu d'un fichier interprété et apte à transmettre cette image par l'intermédiaire de l'interface de communication. Selon encore une autre variante, le lecteur de paramètres d'authentification est un lecteur d'empreintes digitales. Selon une variante, le lecteur de paramètres d'authentification est un lecteur d'empreintes rétiniennes. Selon une autre variante, le lecteur de paramètres d'authentification est un clavier, le terminal comprenant en outre un lecteur de carte à puce. Selon encore une variante, l'interface de communication est une interface de communication sans fil. Selon encore une autre variante, le récepteur est configuré pour recevoir un signal GPS. On comprendra mieux l'invention et ses autres caractéristiques et avantages à l'aide de la description faite ci-après, à titre purement explicatif, en référence aux figures annexées où : -la figure 1 représente schématiquement un réseau de communication informatique dans lequel l'invention est mise en oeuvre ; -la figure 2 représente un terminal d'utilisateur et ses applications destinées à mettre en oeuvre l'invention ; -la figure 3 représente un terminal d'authentification forte d'un utilisateur ; -les figures 4 à 9 illustrent des processus mis en oeuvre dans le cadre de l'invention ; -la figure 10 illustre la structure d'une base de donnée globale d'un serveur; - la figure 11 illustre schématiquement les certificats mis en oeuvre lors de la génération d'un certificat négocié à partir de certificats négociés préexistants ; - les figures 12 à 19 illustrent des datagrammes de données ; -la figure 20 illustre le principe du stockage de données numériques diffusées, déporté dans le terminal 3 ; - la figure 21 illustre un processus de diffusion des données. L'invention propose un terminal d'authentification forte d'un utilisateur. Le terminal comprend un lecteur de paramètres d'authentification d'un utilisateur, un récepteur d'un signal de géolocalisation et une interface de communication avec un autre appareil. Le terminal comprend de plus un processeur extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication. La figure 1 représente de façon schématique un système 9 de contrôle d'accès à des données sécurisées. Le système 9 comprend des terminaux 1A à 1 n tels que des ordinateurs personnels, destinés à être utilisés par différents utilisateurs. Les terminaux 1A àln ont respectivement accès à des bases de données 2A à 2n typiquement mémorisées en local. Les terminaux 1A à 1 n sont aptes à communiquer avec des terminaux d'authentification 3A à 3n. Les terminaux 1A à 1n sont connectés à un réseau 4, en l'occurrence le réseau Internet. Un serveur 5 est connecté au réseau 4 et dispose d'un accès à une base de données 6. Un serveur de datation 7, tel qu'un serveur NTP, est connecté au réseau 4. Le serveur 7 pourra être utilisé pour réaliser la plupart des horodatages mis en oeuvre dans le cadre de l'invention. La figure 2 représente un terminal 1 et ses applications 11 à 17 destinées à être exécutées pour mettre en oeuvre différentes fonctionnalités du contrôle d'accès. Ces applications 11 à 17 pourront être installées sous forme de clients légers sur le terminal 1. La figure 3 représente un terminal d'authentification 3. Le terminal d'authentification 3 est destiné à permettre une authentification forte d'un utilisateur. Le terminal 3 comprend en l'occurrence un lecteur d'empreintes digitales 31, et un lecteur d'empreintes rétiniennes 34 afin de mettre en ceuvre des rnesures biométriques durant l'authentification. Le terminal 3 comprend également un écran 32 destiné à afficher des messages pour l'utilisateur. Le terminal 3 comprend de plus un récepteur 33 d'un signal de géolocalisation, par exemple un récepteur GPS. Le terminal 3 comprend un module de traitement et de commande 38. Le module 38 est connecté à une interface d'entrée/sortie 37, par exemple une interface câblée ou radiofréquence, destinée à mettre le terminal 3 en communication avec le terminal 1. Le récepteur 33 de géolocalisation est connecté au module 38. Un support 35 de stockage sécurisé de données est connecté au module de traitement et de commande 38. Le module 38 est connecté aux lecteurs biométriques 31 et 34, et peut communiquer avec une base de données 36. La base de données 36 comprend une clé de chiffrement symétrique Kst pour les transmissions du terminal 3. Cette clé de chiffrement Kst sera avantageusement définie durant la fabrication du terminal 3 et mémorisée dans une mémoire non volatile. Le serveur 5 mémorise préalablement la clé symétrique Kst du terminal 3 pour assurer le décryptage des données qu'il reçoit en provenance de ce terminal 3. Le terminal 3 est utilisé à la fois pour enregistrer des références d'authentification forte sur le serveur 5, et pour authentifier ensuite un utilisateur lors de ses accès au serveur 5 par comparaison entre ces références et une lecture instantanée de paramètres à comparer à ces références. Par une interface non représentée, par exemple un bouton-poussoir, l'utilisateur pourra définir le début ou la fin d'une session d'utilisation du terminal d'authentification 3. En l'occurrence, lors d'une authentification d'un utilisateur, le terminal 3 mesure une empreinte biométrique par l'intermédiaire des lecteurs 31 et 34. Le terminal 3 peut également comporter un lecteur de cartes à puce et un clavier de saisie d'un code d'identification personnelle de la carte à puce. Dans ce cas, l'identifiant de la carte à puce est utilisé pour être comparé à la référence mémorisée dans le serveur 5. Durant l'authentification, le terminal 3 récupère par l'intermédiaire de son récepteur 33 un signal de géolocalisation. Le terminal 3 en extrait sa position et la date et l'heure en cours. Lors de l'authentification, le terminal 3 transmet les données d'authentification (empreintes biométriques mesurées ou références de cartes à puce par exemple) et la date et l'heure extraites du signal de géolocalisation. Ainsi, en l'absence de disponibilité d'un serveur de datation, par exemple si seule une connexion au réseau local est disponible, on pourra réaliser malgré tout un horodatage de l'authentification forte. Cet horodatage pourra notamment permettre d'enrichir l'historique des accès d'un utilisateur au serveur ou permettre de restreindre des accès aux données sécurisées selon l'heure de l'authentification. Avantageusement, la position du terminal 3 est également transmise au serveur 5. Ainsi, la position de l'utilisateur pourra être prise en compte pour restreindre l'accès aux données sécurisées. Cette transmission est chiffrée au moyen de la clé de chiffrement symétrique Ksi: mémorisée dans le terminal 3. Le support de stockage sécurisé 35 peut être de tout type approprié, par exemple un disque dur ou une mémoire de type EEPROM. Selon les droits d'accès aux données sécurisées, définis dans le certificat de politique d'accès détaillé ultérieurement, la mémorisation des données sécurisées dans le terminal 1 pourra être interdite. Les droits d'accès pourront exiger que les données sécurisées issues du serveur 5 soient mémorisées dans le support de stockage 35, consultées au moyen d'une application 17 par lecture du support 35, puis effacées du support 35 en fin de session d'utilisation. L'application 17 devra donc ainsi gérer le stockage de données dans le terminal 3. Les échanges entre l'application 17 et le support de stockage 35 seront avantageusement chiffrés. Les droits d'utilisation dans le certificat de politique d'accès défini par le propriétaire des données sécurisées pourront également s'appliquer à ses propres accès aux données sécurisées. Les données stockées sur le support 35 pourront faire l'objet d'un chiffrage matériel afin d'empêcher des accès frauduleux. Comme illustré à la figure 20, les données numériques issues de la base 66 et diffusées vers l'utilisateur du terminal 3 arrivent sur la carte réseau 18 du terminal 1. Les données sont stockées transitoirement dans le support 35 du terminal 3 au lieu d'être stockées dans un disque dur 19 du terminal 1. Les données stockées transitoirement par le support 35 sont alors traitées par l'unité centrale 111 ou transférées dans la mémoire vive 112, où ces données ne sont pas duplicables par un tiers fraudeur. L'utilisation de la date extraite par le terminal 3 permettra également de renforcer la sécurité par croisement avec une valeur éventuellement récupérée sur un serveur de type NTP. Le terminal 3 est destiné à ne pas être nominatif. À cette fin, le terminal 3 efface toutes données nominatives de son utilisateur à la fin de la session, notamment toutes les données mémorisées sur le support 35. Le terminal 3 peut ainsi être utilisé successivement par des utilisateurs sans lien entre eux sans que leur information nominative ne soit vulnérable. Afin d'être compatible avec différents systèmes d'exploitation des terminaux de l'utilisateur, le terminal 3 inclura des API compatibles avec plusieurs types de systèmes d'exploitation. Le terminal 3 pourra ainsi être utilisé indifféremment par tous types d'utilisateurs, ce qui renforce sa capacité à être utilisé successivement par différents utilisateurs en fonction de leurs besoins. Le terminal 3 pourra envoyer des trames d'affichage sans que les données elles-mêmes ne soient enregistrables dans le terminal 1. Le terminal 3 pourra notamment disposer d'applications de lecture de différents formats de fichiers afin de permettre de visionner ces types de fichiers sur le terminal 1. L'interface 37 pourra notamment être une interface sans fil (définie par une norme IEEE 802.11 ou par une norme IEEE 802.15) ou une interface câblée (RJ45 ou USB par exemple). La figure 4 détaille un processus de génération d'un certificat numérique privé mis en oeuvre au moyen de l'application 12. Durant l'étape 401, l'utilisateur renseigne des champs textuels relatifs à l'identité de l'entité propriétaire. Ces données comprendront par exemple un nom, un prénom, un nom de société, un représentant légal, des coordonnées etc... L'utilisateur renseigne également tout autre champ pouvant faciliter son identification ou sa sélection par un filtrage. Durant l'étape 402, une ou plusieurs références d'authentification forte sont 'capturées par l'intermédiaire du terminal d'authentification 3. La ou les références d'authentification forte sont transmises au terminal 1. À l'étape 403, l'utilisateur choisit le type de protocoles cryptographiques et leurs différents paramètres de chiffrement. Ces choix définiront les paramètres pour le stockage et la transmission des données numériques de l'utilisateur. Ces paramètres pourront par exemple définir la taille des clés de chiffrement utilisées ou les algorithmes de chiffrement utilisés. À l'étape 404, l'ensemble des données récupérées par le terminal 1 est chiffré au moyen de la clé symétrique Kst mémorisée dans le terminal 3. À l'étape 405, le terminal 1 transmet les données chiffrées au serveur 5. À l'étape 406, le serveur 5 génère le certificat numérique privé CePr et le stocke dans la base de données 6. Le serveur 5 génère dynamiquement les différentes clés de chiffrement incluses dans le certificat privé CePr et génère une première clé de chiffrement symétrique KeS1 qu'il associe à la référence d'authentification forte de l'utilisateur. Le certificat privé CePr est chiffré avec cette clé KeS1. À l'étape 407, le serveur 5 génère un certificat public CePc associé au certificat numérique privé CePr, et publie ce certificat public CePc. L'utilisateur pourra limiter ou interdire la publication ou la consultation du certificat public CePc à sa convenance. L'utilisateur pourra utiliser l'application 11 ultérieurement pour définir si la publication du certificat public CePc est autorisée, restreinte ou interdite (par exemple si le certificat public est visible uniquement sur invitation émise par l'entité propriétaire). Les certificats publics pourront être publiés dans un annuaire dédié et être rendus publics à tout utilisateur en fonction des restrictions de publication. Le certificat numérique privé CePr pourra également être complété ultérieurement au moyen de l'application 12, pour inclure des informations sans incidence sur les chiffrements. L'entité propriétaire pourra par exemple compléter des champs d'information de son certificat numérique privé, par exemple en précisant l'adresse réseau d'un serveur mémorisant les données numériques chiffrées. Le certificat numérique privé CePr contient ainsi les données essentielles de l'identité de son entité propriétaire ainsi que les données utiles au cryptosystème. Le certificat numérique privé CePr contient notamment : - une ou plusieurs références d'authentification forte (par exemple l'empreinte digitale ou l'empreinte rétinienne de l'entité propriétaire) ; - optionnellement un certificat de l'entité propriétaire au format X. 509 ; - une deuxième clé de chiffrement symétrique KeS2 dédiée au chiffrement des données sécurisées de l'entité propriétaire durant leur stockage dans la base de données 6; -une troisième clé de chiffrement symétrique KeS3 destinée au chiffrement des flux de données sécurisées diffusés depuis la base de données 6 vers l'entité propriétaire elle-même; - une quatrième clé de chiffrement symétrique KeS4 destinée au chiffrement d'un certificat de politique d'accès; - un couple de clés de chiffrement asymétrique Kpr et Kpc, destiné au chiffrement/déchiffrement de certificats négociés avec d'autres entités. En particulier, le certificat numérique privé pourra comprendre les champs suivants : - Val_FPT : image binaire d'une ou plusieurs empreintes digitales ; - Val_Kp : Valeur du couple de clés de chiffrement asymétrique Kpr et Kpc; -Info_Kp : Information du protocole cryptographique asymétrique retenu; - Val_Ks : Valeur de la clé de chiffrement symétrique KeS2; - Info_Ks : Information du protocole cryptographique symétrique retenu ; - Import_X.509 : possibilité d'importer un certificat numérique de la norme X.509... -CRC : somme de contrôle d'intégrité de l'ensemble des champs ; - SN : numéro de série unique dudit certificat numérique privé CePr. Le serveur 5 pourra disposer d'un couple de clés de chiffrement asymétrique pour générer le champ CRC d'un certificat numérique privé. La valeur du champ CRC est calculée à partir d'une fonction de hachage non réversible appliquée aux informations contenue dans ce certificat numérique privé. La clé privée de ce couple de clés permet de chiffrer le résultat de la fonction de hachage pour générer le champ CRC du certificat numérique privé. Le propriétaire de ce certificat numérique privé pourra ainsi prouver par une procédure particulière de contrôle du serveur 5, que ce certificat a bien été émis par ledit serveur. Avantageusement, la procédure de contrôle permettra au serveur 5 de contrôler l'authenticité d'un certificat numérique privé importé par son propriétaire de la manière suivante : -application de la fonction de hachage non réversible aux informations contenues dans le certificat numérique privé importé. Le résultat noté 30 CRC_ temp est temporairement stocké par le serveur 5 ; - chiffrement du résultat CRC_temp avec la clé privée du couple de clés de chiffrement asymétrique du serveur 5. Le résultat de ce chiffrement esi: noté CRC_ temp_sig ; - comparaison de CRC_temp_sig avec le champ CRC du certificat numérique privé encore stocké dans le serveur. D'autres moyens de contrôle pourront être mis en oeuvre par le serveur, notamment par le déchiffrement du champ CRC importé au moyen de la clé 5 publique du serveur. La clé de chiffrement symétrique KeS2 sera de préférence dimensionnée pour réaliser un chiffrement fort des données numériques stockées. La clé de chiffrement de diffusion symétrique KeS3 (ainsi que la clé de diffusion vers un tiers Kse détaillée ultérieurement) sera davantage dimensionnée afin de 10 permettre une transmission et un temps de traitement réduit des données sécurisées transmises. Cette clé de chiffrement KeS3 symétrique (ainsi que la clé de diffusion vers un tiers Kse détaillée ultérieurement) pourra par exemple être du type 3DES et présenter une taille comprise entre 64 et 192 bits. Le certificat public CePc permet de garantir l'existence de son certificat 15 numérique privé associé CePr, ce qui permet d'initier par la suite des négociations pour l'accès aux données par un tiers. Le certificat public CePc est lié mathématiquement au certificat numérique privé associé, de sorte qu'un tiers souhaitant vérifier la validité de ce certificat CePc puisse requérir une vérification effectuée par le serveur 5. Le certificat public CePc pourra 20 comprendre une signature numérique du certificat privé associé CePr, par exemple une signature par une fonction de hash. Un tiers pourra ainsi soumettre un certificat public CePc au serveur 5 qui vérifiera le lien mathématique avec son certificat numérique privé associé. La recherche et la consultation de certificats publics de tiers pourra être effectuée au moyen de l'application 16. 25 Le certificat public CePc pourra comprendre les champs suivants : - Info_User : données restreintes d'identification du détenteur légitime du certificat numérique privé telles que le Nom, Prénoms, Pseudonyme, ... ; - Hash : empreinte numérique du certificat numérique CePr garantissant le lien mathématique avec le certificat numérique privé ; 30 -DHC : Date horodatée de création ; - SN : numéro de série unique dudit certificat numérique CePc. Le certificat numérique public CePc et le certificat numérique privé CePr pourront être irrévocables et présenter une durée de validité illimitée. Lors de la création du certificat numérique privé CePr, un certificat de politique d'accès temporaire est avantageusement créé pour définir la politique d'accès qui sera appliquée pour la diffusion des données numériques. Le certificat de politique d'accès temporaire pourra prévoir des droits d'accès très restrictifs par défaut, par exemple une diffusion limitée seulement à l'entité propriiétaire. L'application 16 permet à un utilisateur de rechercher des certificats numériques publics d'autres entités propriétaires. L'application 16 permet notamment d'interroger une base de données de certificats numériques publics et de sélectionner des certificats publics dont le contenu répond à des critères définis par l'utilisateur. L'application 16 permet de visionner les informations fournies par un certificat numérique public sélectionné. L'application 16 peut être déportée et être réalisée sous la forme d'un moteur de recherche consultable par l'intermédiaire d'Internet. Par l'intermédiaire de leur application 13, suite à une invitation du propriétaire des données, ou suite à une requête du tiers, les deux utilisateurs initient un processus de négociation. Les échanges initiaux entre les utilisateurs pourront être signés, horodatés puis stockés par le serveur 5. La figure 5 détaille le processus de négociation de droits d'accès entre l'entité propriétaire des données sécurisées et un tiers. Le tiers peut lui-même être détenteur de données sécurisées, et la négociation peut conduire à définir un droit d'accès réciproque aux données sécurisées des deux entités. Les utilisateurs réalisent cette négociation par l'intermédiaire de leur application 13 destinée à créer un certificat numérique négocié CeNe. Les échanges entre les utilisateurs et le serveur 5 sont sécurisés par un chiffrement adéquat. À l'étape 501, le tiers s'authentifie par une authentification forte auprès du serveur 5. L'application 15 permet notamment de transmettre des données biométriques lues sur le terminal 3 au serveur 5. Les données transmises par le terminal 1 du tiers sont comparées à une référence d'authentification forte mémorisée au préalable sur le serveur 5. Le tiers émet une requête de négociation d'accès aux données sécurisées à destination du propriétaire de ces données. À l'étape 502, l'entité propriétaire s'authentifie par une authentification forte auprès du serveur 5. L'entité propriétaire accepte la requête de négociation. L'entité propriétaire renvoie une proposition définissant les conditions de l'accès à ces données sécurisées. L'entité propriétaire peut notamment proposer un type de protocole cryptographique pour la transmission des données sécurisées, un type de publication souhaitée d'un certificat numérique public correspondant au certificat négocié CeNe, ou définir la durée de vie de ce certificat numérique négocié (la révocation automatique du certificat pouvant être gérée par le serveur 5). Différents types de publication du certificat numérique négocié pourront être envisagés, soit par mise à jour de leur certificat numérique public respectif, soit par une publication du certificat numérique public correspondant soit par un maintien secret de ce certificat. À l'étape 503, les conditions de l'accès aux données sécurisées peuvent éventuellement faire l'objet d'une négociation préalable. À l'issue de cette négociation, les utilisateurs signent et transmettent leur acceptation des conditions au serveur 5. La signature pourra être réalisée avec leur clé privée contenue dans leur certificat numérique privé respectif. La signature pourra être effectuée sur un hash des valeurs des paramètres négociés. Leur acceptation est horodatée et stockée par le serveur 5. À l'étape 504, le serveur 5 crée et mémorise un certificat numérique négocié CeNeaB pour le tiers et un certificat numérique négocié CeNeAb pour l'entité propriétaire. Ces certificats CeNeaB et CeNeAb sont chiffrés respectivement avec la clé publique KpcB et la clé publique KpcA contenues respectivement dans les certificats numériques privés CePrB et CePrA. L'accès aux données du certificat négocié est ainsi sécurisé à la fois par l'authentification forte et par une authentification cryptographique au moyen d'une clé privée. Pour simplifier, on considère que A est une entité propriétaire de données numériques et que B est un tiers pour ces données. Cependant, B peut être une entité propriétaire de données numériques stockées dans la base 66. A est alors considéré comme un tiers pour ces données. Une même clé de chiffrement symétrique KeSe peut être utilisée pour la diffusion des données numériques vers l'entité non propriétaire de ces données. On peut également envisager que les certificats CeNeaB et CeNeAb comprennent respectivement des clés de chiffrement de diffusion KeSeB et KeSeA pour la diffusion respectivement vers B et A en tant que tiers. Ces certificats négociés peuvent comprendre les champs suivants : -SN : numéro de série unique dudit certificat numérique. -TTL : période de validité du certificat ; - Val_Emp : empreintes numériques des certificats numériques privés utilisés durant sa génération ; - Val_Ks : Valeur de la clé de chiffrement symétrique de diffusion vers l'entité titulaire du certificat négocié ; -Info_Ks : Information sur le protocole de chiffrement symétrique retenu; - Import_X.509 : possibilité d'importer un certificat numérique de la norme X.509... -Hash : somme de contrôle d'intégrité de l'ensemble des champs ; La figure 6 illustre un processus d'accès au certificat numérique privé d'un utilisateur. Ce processus est notamment mis en oeuvre lors de la mise à jour du certificat privé, ou lors de toute opération d"accès aux données sécurisées. Durant une étape 601, l'utilisateur lance l'application 12 sur son terminal 1. Durant une étape 602, le terminal 1 détecte la présence du terminal d'authentification 3. Durant une étape 603, le terminal 3 lit une information d'authentification entrée par l'utilisateur, par exemple son empreinte digitale sur le lecteur 31. Durant une étape 604, l'information d'authentification lue est transmise de façon chiffrée (avec la clé Kst) vers le terminal 1. Durant une étape 605, le terminal 1 transmet de façon chiffrée l'information d'authentification lue au serveur 5. Durant une étape 606, le serveur 5 consulte la base de données biométriques 65 et compare l'information d'authentification lue avec la référence mémorisée. Durant l'étape 606, le serveur 5 compare également les informations d'horodatage générées par le terminal 3 avec des informations d'horodatage fournies par le serveur 7. À la fin de l'étape 606, une fois l'utilisateur authentifié, la clé de chiffrement symétrique KeS1 associée à la référence d'authentification mémorisée est montée en mémoire dans le serveur 5. Une clé symétrique est particulièrement appropriée pour chiffrer le certificat numérique privé puisque seul le propriétaire du certificat numérique privé l'utilise directement. Le certificat numérique privé de l'utilisateur stocké dans la base de données 62 est alors déchiffré au moyen de cette clé KeS1 à l'étape 607. À l'étape 608, les valeurs contenues dans le certificat numérique privé et utiles pour des opérations ultérieures sont montées en mémoire dans le serveur 5. Un couple de clés de chiffrement asymétrique Kpc et Kpr est notamment chargé en mémoire, afin de permettre le chiffrement ou le déchiffrement du certificat négocié CeNe. La figure 7 illustre un processus d'accès aux différents certificats négociés dont l'utilisateur est détenteur. À l'étape 701, l'utilisateur lance l'application 13 sur son terminal 1. Les étapes 702 à 705 d'authentification forte sont identiques aux étapes 602 à 605. À l'étape 706, le serveur 5 consulte la base de données biométriques 65 et compare l'information d'authentification lue avec la référence mémorisée à la fin de l'étape 706, une fois l'utilisateur authentifié, la clé privée KPr du couple de clés asymétriques est chargée en mémoire. À l'étape 707, les certificats négociés de l'utilisateur mémorisés dans la base de données 63 sont déchiffrés au moyen de cette clé privée Kpr. À l'étape 708, la liste de ses certificats négociés est transmise à l'utilisateur. La transrnission de cette liste est chiffrée au moyen d'une clé de session Kse2. La figure 8 illustre un processus de définition du certificat de politique d'accès de l'utilisateur propriétaire des données numériques. Lors d'une étape 801, l'entité propriétaire A lance l'application 14 sur son terminal 1. Le terminal 1 détecte la présence du terminal d'authentification 3. Durant une étape 802, une authentification forte de l'entité propriétaire est réalisée comme détaillé auparavant. À la fin de l'étape 802, une fois l'entité propriétaire authentifiée, sa clé de chiffrement symétrique KeS1A associée à sa référence d'authentification est chargée dans le serveur 5. Le certificat numérique privé CePrA est alors déchiffré au moyen de cette clé KeS1A à l'étape 803. La clé de chiffrement symétrique KeS4A est alors chargée dans le serveur 5 à II'étape 804. A l'étape 805, l'entité propriétaire définit des droits d'accès : quelle entité a un droit d'accès aux données numériques, quels droits sont associés à chaque entité (lecture, modification, recopie, chargement limité à un support d'un terminal d'authentification...), des restrictions d'accès en fonction du lieu, de l'heure ou du matériel de connexion au serveur 5. Le certificat de politique d'accès pourra également définir si un historique des accès doit être mémorisé et si un historique des accès doit être inclus dans les données numériques diffusées, formant un marqueur pour ces données. Un certificat de politique d'accès CeSeA contenant ces informations est généré à l'étape 806. Le certificat de politique d'accès CeSeA est chiffré avec la clé KeS4A à l'étape 807. Le certificat de politique d'accès CeSeA est mémorisé dans la base de données 64 à l'étape 808. L'entité propriétaire pourra sélectionner des paramètres de contrôle d'accès par défaut proposés par le serveur 5 lors de la création du certificat de politique d'accès CeSe. L'entité propriétaire pourra par exemple utiliser une base de connaissance de modèles de certificats de politique d'accès pour générer son propre certificat de politique d'accès. L'entité propriétaire pourra accéder ultérieurement à son certificat de politique d'accès par une authentification forte afin de modifier les droits d'accès définis pour des tiers ou pour lui-même à ses données numériques. De préférence, le certificat numérique de politique d'accès, CeSe, comprend au moins les champs suivants : SN : numéro de série unique de ce certificat numérique ; SN_CeNe : numéro de série unique correspondant au CeNe ; 20 - IPS : Index des paramètres de sécurité correspondant au(x) modèle(s) de politique d'accès importé(s). La figure 9 représente le processus de diffusion des données numériques de l'entité propriétaire vers le tiers authentifié. Lors d'une étape 901, le tiers B lance l'application 17 sur son terminal 1. Le terminal 1 détecte la présence du 25 terminal d'authentification 3. Durant une étape 902, une authentification forte de l'utilisateur B est réalisée comme détaillé auparavant. À la fin de l'étape 902, une fois l'utilisateur B authentifié, sa clé de chiffrement symétrique KeSIB associée à sa référence d'authentification est chargée dans le serveur 5. Le certificat numérique privé CePrB est alors déchiffré au moyen de cette clé 30 KeSIB à l'étape 903. A l'étape 904, le certificat numérique négocié CeNeaB est déchiffré au moyen de la clé privée KprB. Lors d'une étape 905, la clé de diffusion KseB pour la diffusion des données numériques vers B est alors chargée dans le serveur 5. A l'étape 906, la clé de chiffrement KeS4A est extraite du certificat CePrA et chargée dans le serveur 5. A l'étape 907, le certificat de politique d'accès CeSeA est déchiffré avec la clé KeS4A. Les droits d'accès sont lus par le serveur 5. A l'étape 908, le serveur 5 valide l'accès aux données numériques pour le tiers B. Le serveur 5 charge alors en mémoire la clé de chiffrement de stockage KeS2A depuis le certificat CePrA et déchiffre les données numériques de l'entité propriétaire mémorisées dans la base 66. A l'étape 909, les données à diffuser sont chiffrées avec la clé de chiffrement de diffusion KSeB. A l'étape 910, les données chiffrées sont diffusées vers le tiers B. L'application 17 permet à l'utilisateur du terminal 1 vers lequel des données ont été diffusées de visionner leur contenu. Avantageusement, les données à diffuser vers le tiers B sont également chiffrées avec une clé de chiffrement symétrique KeMaB basée sur la configuration matérielle du terminal 1 et/ou du terminal 3 du tiers B. La clé de chiffrement KeMaB sera par exemple basée sur l'adresse physique de la carte réseau 18 du terminal 1, sur des références de disque dur du terminal 1, sur une valeur de l'horloge système du terminal 1 ou du terminal 3, ou sur les références du processeur du terminal 1. La clé de chiffrement KeMaB sera typiquement générée à chaque session d'accès aux données chiffrées. La clé de chiffrement KeMaB sera par exemple stockée dans le certificat négocié CeNeaB ou dans un certificat numérique matériel CeMaB. De préférence, les certificats numériques matériels CeMa, comprendront au moins les champs suivants : - SN : numéro de série unique dudit certificat numérique CeMa ; - MAC : adresse physique de la carte réseau 18 du terminal 1; - SND : numéro de série du disque dur 19 correspondant au terminal 1; SNP : numéro de série du processeur 111 du terminal 1 ; - SNA : numéro de série du dispositif d'authentification 3 connecté au terminal 1. Lorsque l'entité propriétaire A souhaitera la diffusion de ses données numériques vers elle-même, on réalisera l'authentification forte de A, le déchiffrement de son certificat numérique privé avec la clé KeS1A, le déchiffrement de son certificat de politique d'accès KeSeA avec la clé KeS4A, le déchiffrement de ses données numériques avec la clé K:eS2A, le chiffrement des données à diffuser avec la clé KeS3A, puis la diffusion des données numériques vers A. De préférence, la phase d'authentification s'applique à chacune des requêtes transmises au serveur via un terminal fixe ou mobile. Chaque processus comprenant alors initialement une authentification forte, l'historique des accès aux données sécurisées est particulièrement précis, et chaque étape pouvant impliquer un accès à des données sensibles est sécurisée. Comme illustré à la figure 10, la base de données 6 comprend une base de certificats publics 61, une base de certificats numériques privés 62, une base de certificats négociés 63, une base de certificats de politique d'accès 64, une base de références biométriques 65, une base de stockage de données numériques chiffrées 66 et une base de protocoles cryptographiques 67. Pour des raisons de sécurité, les différentes clés de chiffrement ne sont pas fournies aux utilisateurs mais seulement chargées en mémoire par le serveur 5 en vue de leur utilisation pour les différentes opérations de chiffrement/déchiffrement. Le serveur 5 chargera en mémoire les clés requises seulement lorsqu'une authentification d'un utilisateur émettant une requête d'accès est validée. Ainsi, la mémorisation de clés d'un certificat privé d'un premier utilisateur dans son certificat négocié ne permet pas à un second utilisateur titulaire du certificat négocié d'obtenir les clés du premier utilisateur. La base de données 61 comprend les certificats publics des différents utilisateurs du serveur 5. Les certificats publics pour lesquels l'accès n'est pas restreint sont accessibles par un annuaire ou un moteur de recherche exécuté sur le serveur 5. La base de données des protocoles cryptographiques 67 contient les différents cryptosystèmes nécessaires pour réaliser les chiffrements/déchiffrements au niveau du serveur 5. La figure 11 représente une phase de création d'un nouveau certificat négocié à partir de deux certificats négociés existants. Les détenteurs A et B des certificats numériques privés CePrA et CePrB, et les détenteurs C et D des certificats numériques privés CePrC et CePrD ont préalablement créé respectivement les certificats négociés CeNeAb, CeNeaB, CeNeCd et CeNecD. Les certificats publics CePcAb CePcaB, CePcCd et CePccD correspondant à ces certificats négociés CeNeAb, CeNeaB, CeNeCd et CeNecD sont publiés dans un annuaire. L'utilisateur B (détenteur du certificat CeNeaB) et l'utilisateur C (détenteur du certificat CeNeCd) souhaitant définir des accès à des données numériques de l'un ou de l'autre, s'authentifient auprès du serveur 5, et négocient la création de nouveaux certificats négociés CeNeaBcd et CeNeabCd. Des certificats publics CePcaBcd et CePcabCd permettront aux utilisateurs B et C de négocier à nouveau la création d'un certificat négocié avec une autre entité. Bien qu'on ait décrit cette solution basée sur la négociation à partir de certificats négociés, la création et la négociation dl'un nouveau certificat négocié pourra être basée sur un ou plusieurs certificats numériques privés et un ou plusieurs certificats négociés. Ce processus de création du nouveau certificat négocié n'est pas une faille de sécurité pour les détenteurs de certificats négociés ne participant pas à cette négociation : en effet, l'utilisation de leur certificat négocié pour créer un nouveau certificat négocié n'implique pas un accès mutuel à leurs données sécurisées. En effet, ces détenteurs conservent leur certificat de politique d'accès pour définir les droits d'accès à leurs données numériques et peuvent donc interdire un accès aux détenteurs du nouveau certificat négocié. Le nouveau certificat négocié constitue ainsi seulement une étape vers l'accès aux données sécurisées, chaque détenteur étant alors libre de définir le certificat de politique d'accès à ses propres données sécurisées et correspondant à ce nouveau certificat négocié. Une telle procédure permet de mettre en place aisément des outils de diffusion vers un tiers des données numériques d'une entité propriétaire, même lorsque celle-ci n'a pas encore une confiance absolue dans ce tiers : l'entité propriétaire reste libre de fournir des droits d'accès au tiers progressivement, une fois que l'entité propriétaire a la garantie de pouvoir faire confiance au tiers. Les figures 12 à 18 représentent des exemples de datagrarnmes d'échanges visant à permettre la diffusion des données chiffrées. Pour réaliser le déchiffrement des données numériques diffusées vers le tiers autorisé, celui-ci doit disposer au préalable de la clé de chiffrement symétrique utilisée pour la diffusion. La figure 12 représente un datagramme d'un paquet d'une requête émise par le tiers autorisé vers le serveur 5 et destinée à établir une clé de chiffrement symétrique matérielle KCeMa pour la diffusion des données. Le premier champ IDS est un identifiant numérique de la session de diffusion de données. Le second champ ID CePr est un identifiant unique du certificat numérique privé de l'entité propriétaire. Le troisième champ ID CeNe est un identifiant unique du certificat numérique négocié de l'entité propriétaire avec le tiers autorisé. Le quatrième champ ID CePr' est un identifiant unique du certificat numérique privé du tiers autorisé. Le cinquième champ Ord est le numéro du paquet parmi les différents paquets destinés à établir la clé de chiffrement matérielle. Le sixième champ Qr indique si l'échange concerne une requête de l'utilisateur ou une réponse du serveur. L'intégrité des sept premiers champs du paquet de la figure 12 est garantie par le champ Checksum, contenant une somme de contrôle d'intégrité de ces champs. L'authentification des huit premiers champs est garantie par le champ K_CePr qui est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs est chiffré au rnoyen d'une clé de chiffrement symétrique Kst du terminal 3. La figure 13 représente un datagramme d'un paquet d'une réponse transmise par le serveur 5 vers le tiers autorisé et destinée à lui fournir la clé de chiffrement symétrique utilisée pour la diffusion des données. Les six premiers champs ont une fonction identique à ceux du datagramme de la figure 12, Le septième champ Val_K_217 contient la clé de chiffrement symétrique de diffusion. Cette clé combine la clé de chiffrement matérielle transmise par le tiers autorisé avec une clé de session se trouvant dans le certificat négocié. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets. L'authentification des huit premiers champs est garantie par le champ K_CePr qui est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs est chiffré au moyen de la clé de chiffrement symétrique K_CeMa transmise dans le paquet de la figure 12. La figure 14 représente un datagramme d'un paquet d'une demande d'accusé de réception d'une requête d'accès du tiers autorisé aux données numériques de l'entité propriétaire. Les quatre premiers champs du paquet ont la même fonction que les champs des datagrammes des figures 12 et 13. Le cinquième champ ID F contient un identifiant numérique d'un fichier numérique auquel l'accès est requis. Les sixième et septième champs correspondent aux cinquième et sixième champs des datagrammes des figures 12 et 13. Le huitième champ NTP comprend un horaire d'un organisme officiel, soit fourni par le terminal 3, soit fourni par un serveur NTP. Le neuvième champ CeSe#CePr contient un index de paramètres de politique d'accès encapsulés. Le dixième champ Q_AR identifie une requête d'accusé de réception. Le onzième champ Val-SHA contient une valeur de contrôle d'intégrité du fichier à diffuser. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets. Le champ KcePr est une signature de l'ensemble de ces champs à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. L'ensemble des champs du paquet est chiffré au moyen de la clé K_217. La figure 15 représente un datagramme d'un paquet d'un accusé de réception du serveur transmis au tiers autorisé. Les neuf premiers champs du paquet ont la même fonction que les champs du paquet de la figure 14. Le dixième champ R_AR identifie un accusé de réception. Le onzième champ KcePr est une signature de l'ensemble de ces champs à lpartir de la clé privée contenue dans le certificat privé de l'entité propriétaire. Le champ Options contient un code de qualification (valider, archiver, bon pour accord...) du fichier à diffuser et est associé à la signature KCePr'. Le champ Val-SHA contient une valeur de contrôle d'intégrité du fichier à diffuser. Le champ Checksum Histo est une :somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr' contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique du tiers autorisé. L'ensemble des champs du paquet est chiffré avec la clé K__217. La figure 16 est un datagramme simplifié d'un paquet du flux de données numériques de l'entité propriétaire diffusées vers le tiers autorisé. Le premier champ définit l'ordre du paquet dans le flux, le second champ identifie que le paquet correspond à une réponse du serveur, le troisième champ comprend les données numériques diffusées, le cinquième champ comprend une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique de l'entité propriétaire. L'ensemble des champs du paquet est chiffré avec la clé K_217. La figure 17 est un datagramme d'un paquet d'une demande d'accusé de réception de la fin de la diffusion des données numériques, transmise du tiers autorisé vers le serveur. Les huit premiers champs du paquet ont la même fonction que les champs des paquets des figures 14 et 15. Le neuvième champ R AR identifie une requête d'accusé de réception. Le champ SG# est destiné à propager une nouvelle clé secrète d'initialisation de serveur dans le terminal 3. Cette clé permettra notamment de sécuriser les premiers échanges entre le terminal et le serveur 5. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique de l'entité propriétaire. L'ensemble des champs du paquet est chiffré avec la clé K_217. La figure 18 est un datagramme d'un paquet d'un accusé de réception de la fin de la diffusion des données numériques, transmise du serveur vers le tiers autorisé. Les huit premiers champs du paquet ont la même fonction que les champs des paquets des figures 14 et 15. Le neuvième champ AR identifie un accusé de réception. Le champ KcePr est une signature de l'ensemble des champs précédents à partir de la clé privée contenue dans le certificat privé de l'entité propriétaire. Le champ Options contient un code de qualification du fichier diffusé et est associé à la signature KCePr'. Le champ Val-SHA contient une valeur de contrôle d'intégrité du fichier diffusé. Le champ Checksum Histo est une somme cumulée de contrôle d'intégrité de l'ensemble des paquets précédents. Le champ KCePr' contient une signature de l'ensemble des champs précédents par la clé privée du certificat numérique du tiers autorisé. L'ensemble des champs du paquet est chiffré avec la clé K_217. La figure 19 représente le format de stockage de données numériques d'une entité propriétaire durant leur stockage dans le serveur. Le charnp ID correspond à l'identifiant des données numériques stockées. Le champ NTP contient des informations d'horodatage des données stockées, par exemple la date de dernière modification de ces données. Le champ TOS pour `Type Of Service' définit le type de service associé aux données. Le champ TTL cache définit la durée de vie des données numériques stockées et facilite l'archivage de ces données. Le champ Metadata contient des informations d'indexation des données numériques stockées. Le champ ID CePr contient l'identifiant unique du certificat numérique privé de l'entité propriétaire. Val_SHA comprend une valeur de vérification d'intégrité des données numériques stockées. Le champ suivant est une signature par la clé privée de l'entité propriétaire de l'ensemble des champs précédents. Le champ Data comprend les données numériques de l'entité propriétaire elles-mêmes. Le champ Histo comprend l'historique de l'ensemble des accès aux données numériques stockées. Le champ Histo pourra notamment comprendre les datagrammes des figures 15 et 18. Le champ Checksum file est une somme de contrôle des données numériques stockées. Le champ suivant est une signature par la clé privée de l'entité propriétaire de l'ensemble des champs précédents. La figure 21 illustre un procédé de diffusion des données à destination du tiers autorisé. Lors d'une première étape, les données numériques stockées de l'entité propriétaire sont déchiffrées. Des paquets de données destinés à la diffusion sont formés et font l'objet d'une encapsulation optimisée. Les paquets à diffuser sont chiffrés au moyen de la clé de chiffrement de diffusion du tiers autorisé. Les paquets de données sont compressés avant leur diffusion. Le terminal du tiers autorisé décompresse les paquets de données reçues, déchiffre les données numériques et réalise un chiffrement pour le stockage de ces données dans le terminal. Les données sont transmis à un module pour leur visualisation par le tiers autorisé. Dans l'exemple, le serveur 5 est accessible par les utilisateurs par l'intermédiaire d'Internet. On pourrait également envisager que le serveur 5 soit un serveur d'entreprise accessible en réseau local. Le serveur 5 ne permet la visualisation et l'accès à un certificat numérique privé qu'à son entité propriétaire. Dans l'exemple, bien qu'on ait illustré un seul serveur 5, les fonctions réalisées peuvent être réparties sur différents serveurs. De même, bien qu'on ait illustré une seule base de données 6, les différents contenus décrits pourront être stockés dans différentes bases de données distantes. Avantageusement, tous les certificats numériques susmentionnés (CePr, CePu, CeNe, CeSe, CeMa) sont stockés sur un ou plusieurs serveurs distants sécurisés dans une base de données selon une architecture client/serveur adaptée. REVENDICATIONS1. Terminal d'authentification forte (3) d'un utilisateur, caractérisé en ce qu'il comprend : -un lecteur (31,34) de paramètres d'authentification d'un utilisateur ; -un récepteur d'un signal de géolocalisation (33) ; - une interface de communication (37) avec un autre appareil ; - un processeur (38), extrayant la date et l'heure du signal de géolocalisation, générant des données chiffrées comprenant des paramètres d'authentification lus par le lecteur et la date et l'heure extraites, et commandant la transmission desdites données chiffrées par l'intermédiaire de l'interface de communication (37). 2. Terminal (3) selon la revendication 1, dans lequel le processeur (38) extrait la 15 position du terminal à partir du signal de géolocalisation et inclut la position extraite dans les données chiffrées. 3. Terminal selon la revendication 1 ou 2, comprenant une mémoire non volatile (36) mémorisant une clé de chiffrement symétrique, le processeur générant 20 les données chiffrées en utilisant cette clé de chiffrement symétrique. 4. Terminal selon l'une quelconque des revendications précédentes, comprenant : -une mémoire de stockage (35) accessible par l'intermédiaire de l'interface de 25 communication (37) ; - une interface de commande par l'intermédiaire de laquelle un utilisateur peut commander la fin d'une session d'utilisation du terminal ; le processeur (38) commandant l'effacement de la mémoire de stockage à la fin de chaque session d'utilisation. 30 6. Terminal selon la revendication 4, mémorisant des applications d'interprétation de différents types de fichiers mémorisés dans la mémoire de stockage (35), le processeur (38) étant apte à exécuter ces applications, apte à générer une image du contenu d'un fichier interprété et apte à transmettre 35 cette image par l'intermédiaire de l'interface de communiication. 7. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un lecteur d'empreintes digitales. 407. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un lecteur d'empreintes rétiniennes. 8. Terminal selon l'une quelconque des revendications précédentes, dans lequel le lecteur de paramètres d'authentification est un clavier, le terminal comprenant en outre un lecteur de carte à puce. 9. Terminal selon l'une quelconque des revendications précédentes, dans lequel l'interface de communication est une interface de communication sans fil. 10. Terminal selon l'une quelconque des revendications précédentes, dans lequel le récepteur est configuré pour recevoir un signal GPS.15