FR 2846819 A1 20040507 FR 0213869 A 20021106 PROCEDE D'ECHANGE SECURISE ENTRE DEUX UNITES DE COMMUNICATION, SYSTEME DE CONTROLE ET SERVEUR POUR LA MISE EN îUVRE DU PROCEDE La présente invention concerne les techniques d'échange sécurisé entre unités de communication. De plus en plus de services en ligne à valeur ajoutée se développent autour des notions de base de la sécurité applicative, en particulier la signature électronique et le chiffrement de données. Pour réaliser ces opérations de cryptographie à clé publique, un préalable fréquent est la détention d'une 10 bi-clé, c'est-à-dire d'un couple clé privée - clé publique, et d'un certificat délivré par une Autorité de Certification (AC). Certains de ces services impliquent deux utilisateurs indépendants l'un de l'autre, qui ne sont pas nécessairement abonnés au même service. L'un de ces utilisateurs peut ne pas disposer des éléments de cryptographie 15 appropriés. Par exemple, dans le cas d'un service de courrier électronique hautement sécurisé (chiffré, et avec accusé de réception signé), l'expéditeur d'un message peut ne pas connaître a priori les éléments de sécurité de son destinataire, et le destinataire peut ne pas disposer du nécessaire. Cela empêche un tel service à valeur ajoutée de se répandre puisqu'un utilisateur 20 qui n'a pas fait de lui-même les démarches d'enregistrement auprès d'une AC ne sera jamais inclus dans un tel service, même passivement, contrairement à ce qui se passe dans la vie quotidienne o, par exemple, tout le monde peut recevoir un courrier recommandé avec accusé de réception. L'objet fondamental permettant d'avoir confiance en la partie publique 25 d'une clé cryptographique (clé publique) est le certificat. Le standard de certificat utilisé dans de nombreux réseaux dont l'lntemet est X.509, version 3. Une spécification en est fournie par le groupe de travail PKIX de l'IETF ("Internet Engineering Task Force") dans la Request For Comments (RFC) 3280, "Internet X.509 Public Key Infrastructure; Certificate and Certificate 30 Revocation List (CRL) Profile" publiée en avril 2002. Le certificat est un objet comprenant notamment: -2 * la clé publique à certifier; * l'identité de son possesseur; * une période de validité; * une signature cryptographique de ces données par la clé privée d'une Autorité de Certification (AC) émettrice du certificat. Avoir confiance en la clé publique associée à une identité revient à s'assurer de la validité du certificat. Pour PKIX, un certificat est valide à un instant T donné (en termes de confiance): * soit s'il est explicitement déclaré comme "certificat de confiance". En 10 pratique, les certificats des utilisateurs ne sont jamais déclarés de confiance. On déclare plutôt un nombre réduit de certificats de confiance, consistant en les certificats de certaines AC; * soit s'il vérifie les conditions suivantes: - la signature cryptographique du certificat est mathématiquement 15 valide; l'instant T fait partie de la période de validité du certificat; - le certificat n'est pas révoqué à l'instant T; - la clé publique de l'AC émettrice est disponible par un certificat de l'AC, et ce certificat de l'AC est lui-même valide à l'instant T. Les certificats cryptographiques ont une durée de vie déterminée dans la Politique de Certification de l'Autorité de Certification qui les émet. Cette durée est typiquement d'un à trois ans pour des certificats d'utilisateurs. Cette durée étant longue, il est nécessaire de prévoir la possibilité de compromission de la clé certifiée au cours de la période de validité du certificat. 25 Un mécanisme de révocation et de contrôle de révocation est donc mis en place pour permettre d'invalider un certificat qui ne doit plus être utilisé. D'autre part, le fait qu'une signature électronique ait été effectuée avec un certificat de durée de vie relativement longue ne donne que peu d'indications sur la date à laquelle la signature a été effectuée. Il faut donc 30 coupler le mécanisme de signature électronique à un mécanisme -3 d'horodatage. La phase d'enregistrement est celle au cours de laquelle l'utilisateur fournit à l'Autorité de Certification des détails et des justificatifs sur son identité, que l'AC vérifie, ainsi que la preuve de possession de la clé qu'il s'agit de certifier. Cette phase doit être réalisée en conformité avec la Politique de Certification de l'AC. Elle est fondamentale car c'est sur la foi de cet enregistrement que les tiers pourront avoir confiance en la concordance de l'identité du titulaire du certificat avec le porteur de la clé correspondante. Plusieurs classes de certification sont définies, en fonction de la rigueur avec laquelle les vérifications sont effectuées lors de la phase d'enregistrement. Par exemple, les certificats gratuits que l'on peut obtenir sur Internet ne certifient qu'une adresse de messagerie électronique: aucune vérification n'est 15 réalisée; cela correspond à la classe 1. A l'inverse, un certificat de classe 3 n'est attribué qu'après une vérification très rigoureuse de l'identité du titulaire, avec fourniture de papiers d'identité officiels, appel téléphonique sur le lieu de travail, etc. La fonction de signature électronique permet de garantir l'authenticité 20 d'un document, c'est-à-dire d'authentifier de façon sre son ou ses signataires et de garantir que le document n'a pas été modifié (intégrité). La signature électronique est souvent utilisée pour garantir la non-répudiation. La non-répudiation d'un document consiste à se prémunir contre un déni ultérieur de son auteur. Les formats les plus couramment utilisés pour des messages signés sont: * PKCS#7, publié par la société RSA Security, Inc. et par l'IETF en mars 1998 (RFC 2315, "PKCS #7: Cryptographic Message Syntax; Version 1.5"), qui a été repris dans CMS ("Cryptographic Message Syntax", 30 RFC 2630, IETF, juin 1999). Ces standards sont utilisés notamment -4 dans la spécification S/MIME ("Secure Multipurpose Internet Mail Extensions") pour les courriers électroniques signés. Ils reposent sur des certificats issus de PKIX (X.509, CRL, OCSP) et sont "extensibles" dans le sens o il est possible de rajouter des extensions (compléments 5 d'information) signées (authenticatedAttributes) ou non (unauthenticatedAttributes); * XML-DSig, faisant partie de la famille des formats de données XML ("eXtended Markup Language"). Ce format permet d'utiliser les certificats issus de PKIX, et est également extensible; * PGP correspondant aux messages signés issus du logiciel PGP ("Pretty Good Privacy" commercialisé par la société Networks Associates Technology, Inc.) et de ses analogues. Ses certificats sont différents de ceux issus de PKIX. Un inconvénient de la technique de signature est qu'il est nécessaire 15 de disposer d'un certificat pour l'appliquer. Dans le cas de certains services, cela peut constituer une entrave. Par exemple, pour l'envoi de courrier électronique avec accusé de réception à signer, on ne peut pas exiger d'accusé de réception de la part d'un utilisateur qui n'est pas préalablement certifié. Le chiffrement de données permet de garantir la confidentialité des informations stockées ou transmises à un tiers. Les formats les plus couramment utilisés pour des messages chiffrés sont PKCS#7/CMS et PGP. Le principe le plus courant du chiffrement d'un message M est le suivant: * l'émetteur tire une clé de session symétrique K qui ne sera utilisée que pour le chiffrement de M (une nouvelle clé K sera générée pour chaque message chiffré); * l'émetteur chiffre M avec K (K[M]) grâce à un algorithme de chiffrement symétrique (par exemple DES, 3DES, RC2, RC4, AES...); -5 * l'émetteur chiffre K avec la clé publique Kpub du destinataire (Kpub[K]), en chiffrement asymétrique; et * l'émetteur envoie au destinataire K[M] et Kpub[K]. Le déchiffrement se déroule alors ainsi: * le destinataire reçoit K[M] et Kpub[K]; * grâce à la clé privée Kpriv correspondant à la clé publique Kpub, le destinataire déchiffre K: Kpriv[Kpub[K]] = K; et * grâce à clé de session symétrique K, le destinataire déchiffre le message M: K[K[M]] = M. L'inconvénient de cette technique de chiffrement/déchiffrement est qu'elle nécessite de connaître a priori la clé publique du destinataire, et donc qu'il faut que le destinataire ait un certificat. Par exemple, on ne peut pas envoyer de courrier électronique chiffré à un destinataire non préalablement certifié. Cela restreint l'utilisation de certains services à valeur ajoutée. Un but de la présente invention est de pallier ces limitations de la technique antérieure. L'invention propose ainsi un procédé d'échange sécurisé entre une première unité de communication et une seconde unité de communication par l'intermédiaire d'un système de contrôle. Une clé privée et un certificat 20 incorporant une clé publique associée à la clé privée sont générés pour la seconde unité en réponse à la réception par le système de contrôle, depuis la première unité, d'une requête de communication avec la seconde unité. Ensuite, la seconde unité exécute au moins une opération cryptographique avec la clé privée en relation avec un message issu de la première unité. Dans le cadre d'un service à valeur ajoutée tel qu'évoqué précédemment, le procédé permet à un émetteur de demander, pour son destinataire, l'émission d'une bi-clé et d'un certificat temporaires lui permettant de jouer son rôle de récepteur, même en l'absence de son enregistrement au service. Un avantage est que les utilisateurs actifs peuvent ne plus échanger -6 uniquement en univers clos, mais avec tout le monde, grâce à l'inclusion dans les destinataires potentiels des utilisateurs "passifs" non inscrits, ce qui rend les services plus attrayants. D'autre part, ces utilisateurs "passifs" sont sensibilisés au service qu'ils 5 auront ainsi expérimenté, et pourront donc venir augmenter les rangs des utilisateurs "actifs", c'est-à-dire des clients des fournisseurs offrant ces services. Un mode de réalisation du procédé comprend les étapes suivantes: - la première unité transmet au système de contrôle la requête de 10 communication avec la seconde unité, accompagnée d'au moins un identifiant de la seconde unité; - le système de contrôle génère pour la seconde unité au moins une clé privée et un certificat incorporant une clé publique associée à la clé privée; - le système de contrôle transmet une version chiffrée de la clé privée à la seconde unité, par un premier chemin de communication; - le système de contrôle transmet une clé de déchiffrement à la seconde unité, par un second chemin de communication; et - la seconde unité récupère la clé privée à partir de sa version chiffrée à 20 l'aide de la clé de déchiffrement, et exécute au moins une opération cryptographique avec la clé privée. Dans une autre réalisation, le procédé comprend les étapes suivantes: - la première unité transmet au système de contrôle la requête de communication avec la seconde unité, accompagnée d'au moins un 25 identifiant de la seconde unité; - le système de contrôle obtient une clé d'authentification pour la seconde unité et notifie la requête de communication à la seconde unité par un premier chemin de communication; - 7 - la seconde unité s'authentifie auprès du système de contrôle, en établissant un canal de communication authentifié sur un second chemin de communication entre la seconde unité et le système de contrôle; - la seconde unité génère un couple clé privée - clé publique; - la seconde unité transmet au système de contrôle, sur le canal authentifié, une requête de certificat générée au moyen d'au moins la clé publique; - le système de contrôle génère et transmet à la seconde unité, sur le canal authentifié, le certificat incorporant la clé publique; et - la seconde unité exécute au moins une opération cryptographique avec la clé privée. Un autre aspect de la présente invention se rapporte à un système de contrôle d'échanges sécurisés entre une première unité de communication et une seconde unité de communication, comprenant des moyens pour générer, 15 en réponse à la réception, depuis la première unité, d'une requête de communication avec la seconde unité, au moins un certificat incorporant une clé publique associée à une clé privée propre à la seconde unité, et des moyens pour commander l'exécution par la seconde unité d'au moins une opération cryptographique avec la clé privée en relation avec un message issu 20 de la première unité. Un autre aspect de la présente invention se rapporte à un serveur de contrôle d'échanges sécurisés entre une première unité de communication et une seconde unité de communication, comprenant des moyens pour s'adresser à un serveur de certification en réponse à la réception, depuis la 25 première unité, d'une requête de communication avec la seconde unité, afin d'obtenir du serveur de certification au moins un certificat incorporant une clé publique associée à une clé privée propre à la seconde unité, et des moyens pour commander l'exécution par la seconde unité d'au moins une opération cryptographique avec la clé privée en relation avec un message issu de la 30 première unité. -8 D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'exemples de réalisation non limitatifs, en référence aux dessins annexés, dans lesquels les figures 1 à 4 sont des diagrammes illustrant quatre exemples de mise en oeuvre de l'invention. Le procédé selon l'invention trouve application lorsqu'un utilisateur souhaite utiliser un service nécessitant la mise en oeuvre de cryptographie en incluant un tiers, alors que ce tiers ne dispose pas d'un certificat numérique utilisable dans le cadre dudit service. Aux fins de la présente description, on désigne par: * "S" le service ou, selon le contexte, le système de contrôle d'échanges sécurisés assurant la fourniture de ce service, * "U" l'utilisateur du service, ou une unité de communication dont se sert cet utilisateur, * "T" le tiers, ou une unité de communication dont se sert ce tiers, * "K" une clé privée affectée au tiers T, * "C" le certificat du tiers T, incorporant la clé publique associée à la clé privée K, * "M" un message que U destine à T, et 20 * "P" un mot de passe. La figure 1 illustre un premier mode de réalisation du procédé selon l'invention, o l'utilisateur U a un message M à faire parvenir au tiers T au travers d'un service sécurisé nécessitant du chiffrement de données et la signature par le destinataire d'un accusé de réception. Deux types d'opérations 25 cryptographiques sont donc requis: * le chiffrement de données destinées à T, et * la signature électronique d'un accusé de réception par T. Dans l'exemple représenté, le système de contrôle d'échanges sécurisés rendant ce service se limite à un serveur S. Le procédé se déroule 30 alors comme suit: -9 Etape 1: L'utilisateur U adresse au serveur S une demande d'émettre un message vers le tiers T, en fournissant un identifiant de T (coordonnées) qui puisse être certifié. Les informations fournies sur T peuvent être de nature diverse selon le service et le destinataire. 5 Le plus courant est une adresse de messagerie électronique (e-mail). Cela peut aussi être un numéro de téléphone mobile ou encore une adresse IP d'un serveur déterminé. Etape 2: Le serveur S procède à la génération sécurisée de la clé privée K et du certificat C correspondant. La clé K est chiffrée, par exemple par 10 combinaison avec un mot de passe P: P[K]. Selon le type du tiers T, cela peut être tout autre procédé de chiffrement. Etape 3: Le serveur S expédie le certificat C à l'utilisateur U. Etape 4: L'utilisateur U chiffre M avec la clé publique contenue dans le certificat C, et envoie le message chiffré C[M] au serveur S. Etape 5: S notifie au tiers T qu'il a reçu un message sécurisé, par exemple par e- mail ou par un service de messages courts (SMS, "Short Message Service) d'un réseau radio mobile, et l'invite à se connecter pour le récupérer. Etape 6: T se connecte à S pour récupérer, dans un premier temps, la clé 20 chiffrée P[K] et le certificat C. Etape 7: Par un autre chemin de communication, T récupère le mot de passe P. Cet autre chemin peut par exemple passer par un autre serveur disponible uniquement pendant un laps de temps très court à partir du retrait de P[K], ou par un serveur vocal accessible seulement 25 depuis son propre téléphone, ou correspondre à l'envoi d'un SMS sur un terminal radio mobile, etc. Le tiers T est alors en mesure de connaître sa clé privée K en la déchiffrant à l'aide du mot de passe P, soit K = P[P[K]]. - 10 Etape 8: T se connecte à la page de mise à disposition du message chiffré C[M]. Dans le service considéré, la récupération du message a lieu en deux phases: a. Signature de l'accusé de réception et envoi de l'accusé de 5 réception signé au serveur S pour lui indiquer qu'il a bien retiré le message. S vérifie cette signature. b. Retrait du message chiffré C[M] et déchiffrement grâce à K, soit K[C[M] = M. Etape 9: L'accusé de réception signé est envoyé par le serveur S à 10 l'utilisateur U qui en vérifie la signature. Par ce procédé, le tiers T a eu la possibilité de participer au déroulement du service S, sans y être inscrit et sans disposer a priori d'un certificat cryptographique. Le certificat qui a été délivré à T dans ce cadre est de préférence de 15 classe basse, puisque aucune vérification autre que son adresse d'e-mail n'a été effectuée. De plus, il est recommandé, dans ce genre de cas, d'avoir une période de validité du certificat très courte, afin d'éviter qu'il soit utilisé dans un cadre autre que celui-ci. En cryptographie, on utilise fréquemment des clés différentes lorsque 20 leurs usages sont différents. Par exemple, on distingue une clé de signature d'une clé de chiffrement. Cette distinction se fait par le "Key Usage " défini dans le certificat. Il est possible, dans le procédé précédemment décrit, de générer deux clés K pour le tiers T, notamment s'il doit réaliser un déchiffrement et une signature. Ces clés sont déchiffrées séparément à l'issue 25 de l'étape 7. Dans la description faite en référence à la figure 1, le tiers T réalise deux opérations cryptographiques, à savoir un déchiffrement et une signature électronique. On peut envisager de lui faire effectuer d'autres opérations cryptographiques mettant en jeu de la cryptographie à clé publique, comme par 30 exemple de l'authentification, ou de l'horodatage de données. - 11 Le tiers peut aussi ne réaliser qu'une seule opération, la signature par exemple. Le procédé peut être utilisé pour tout service mettant en relation deux individus ayant besoin d'une ou plusieurs opérations cryptographiques. Le rôle 5 du serveur S peut être enrichi, modifié, scindé entre plusieurs serveurs (par exemple un pour le service proprement dit, un autre pour l'émission de certificats). Dans la description faite en référence à la figure 1, l'enregistrement du tiers T est fait sur la foi des informations fournies par l'utilisateur U. Il est 10 également possible de demander à T la confirmation de ces informations, de les lui faire enrichir, ou de réaliser une véritable opération d'enregistrement au sens de la PKI, afin de lui délivrer un certificat ayant une réelle validité, c'est-àdire un certificat de classe plus élevée. Il est aussi possible aussi de recueillir du tiers T des informations que 1 5 le serveur S transmettra à l'utilisateur U afin de vérifier qu'il n'y a pas eu d'erreur de saisie et que le destinataire est le bon. Le prestataire de service peut avantageusement profiter du déroulement du procédé pour proposer au tiers T de s'enregistrer et de s'abonner au service, éventuellement dans des conditions privilégiées. On peut 20 en cela considérer que l'utilisateur U a parrainé le futur abonné. Toujours sous l'angle du marketing, le service incluant un tiers non abonné peut donner lieu à une tarification particulière vis-à-vis de l'utilisateur U, par rapport au service de base entre deux abonnés. Le certificat émis pour le tiers T peut incorporer des contraintes 25 importantes afin qu'il ne soit pas capable de l'utiliser dans d'autres applications. Il peut présenter des extensions particulières, et particulièrement des dates de validité très restrictives. En outre, cela évite d'avoir à gérer de la révocation sur ces certificats par définition temporaires. Le procédé décrit en référence à la figure 1 utilise deux chemins de 30 communication pour envoyer au tiers T d'une part la clé privée chiffrée P[K], et - 12 d'autre part le moyen P de la déchiffrer. Ces deux chemins peuvent être de toutes natures: e-mail, téléphone mobile par canal vocal ou SMS, téléphone fixe, pager, courrier, télégramme, etc. Le mode particulier de réalisation du procédé illustré par la figure 2 5 correspond à un service de courrier électronique recommandé avec accusé de réception signé. L'utilisateur U est un abonné à ce service voulant envoyer un pli avec accusé de réception signé à un tiers T non abonné, dont il connaît le numéro de téléphone mobile et l'adresse électronique. Dans cet exemple, la fonction de système S de contrôle d'échanges 10 sécurisés n'est pas assurée par un serveur unique, comme dans le cas de la figure 1, mais conjointement par le serveur SI gérant le service et par un serveur de certification Spki pour l'émission de certificats temporaires, de classe basse, pour ce type de besoin particulier. On notera que les fonctions des serveurs SI et Spki peuvent sans problème être regroupées dans la même 15 machine. La signature est réalisée au moyen d'une application écrite en langage à code mobile présente dans une page web sur le serveur S. Le langage à code mobile permet à cette application d'être indépendante de la plateforme sur laquelle elle s'exécute. C'est par exemple le langage Java (voir "The Java 20 Language Specification" publié par la société Sun Microsystems, Inc.). L'application est alors appelée "applet". Le procédé peut alors se dérouler comme suit: Etape 11: U se connecte au serveur SI grâce à un navigateur web, et choisit d'envoyer un message en clair (non chiffré) avec accusé de 25 réception signé, à un tiers T, dont il connaît l'adresse e-mail et le numéro de téléphone mobile. Les éléments transmis au serveur sont le message M, l'adresse e-mail de T et le numéro de téléphone mobile de T. Etape 12: Si s'adresse à Spki pour lui demander la génération d'un certificat 30 de signature temporaire pour T, de durée 7 jours (période retenue - 13 par le service pour la garde des plis recommandés avec accusé de réception). Les éléments transmis à Spki incluent l'adresse e-mail de T. Etape 13: Spki génère la bi-clé avec la clé privée K et le certificat associé C, ainsi que le mot de passe P. Spki chiffre K avec P, stocke P, et transmet C et P[K] à S1. De la sorte, S1 ne dispose pas de la clé privée de T et ne peut pas signer à sa place l'accusé de réception. S1 transmet à T, par exemple par e-mail, un avis de mise à disposition d'un message, ainsi que l'adresse de retrait. Etape 14: Etape 15: 15 Etape 16: T se connecte à cette adresse de retrait du serveur S1 grâce à un navigateur, et récupère C, P[K], I'accusé de réception à signer, ainsi que l'applet de signature. Il est informé dans la page qui s'affiche qu'un mot de passe lui permettant de signer va immédiatement lui être envoyé par SMS. S1 donne à Spki l'ordre d'envoyer au tiers T le mot de passe P. Les éléments transmis à Spki incluent le numéro de téléphone de T. Etape 17: Spki envoie à T un SMS contenant P. Etape 18: I'applet exécutée dans l'unité T récupère K grâce à P en déchiffrant P[K] reçu à l'étape 15. Etape 19: T signe l'accusé de réception grâce à K, dans l'applet. Etape 20: T envoie l'accusé de réception signé à S1. Etape 21: S1 vérifie la signature de l'accusé de réception. Etape 22: S1 envoie le message M au tiers T, par e-mail ou par un affichage web. Etape 23: T visualise M. Etape 24: Le serveur S1 envoie à l'utilisateur U, par exemple par e-mail, l'accusé de réception signé par T. - 14 Etape 25: U vérifie la signature de l'accusé de réception, et a ainsi l'assurance que T a bien reçu son message. Naturellement, le procédé de signature d'accusés de réception illustré par la figure 2 peut être couplé avec du chiffrement, de l'authentification par clé 5 publique, ou d'autres fonctions cryptographiques à valeur ajoutée telles que de l'horodatage, l'inclusion d'une preuve persistante de validité du certificat, etc. Dans une variante de réalisation, au lieu de demander à l'utilisateur U de spécifier deux chemins distincts vers le tiers T, le système de contrôle S, notamment le serveur SI, demande à T lui-même de choisir le mode de 10 transmission de P. Ceci offre certes moins de sécurité car si T n'est pas le destinataire prévu (par exemple en cas d'usurpation d'adresse e-mail), il peut recevoir tous les éléments et donc le message. Dans le cas décrit en référence à la figure 2, il faudrait pour cela que l'usurpateur se procure également le téléphone mobile de T. Mais cela ajoute de la souplesse au procédé. Il est possible d'implémenter dans l'applet Java une fonction de destruction de la clé privée K après usage. Pour être certain que cette clé K ne puisse pas être reconstituée, il est avantageux que ce soit l'applet et elle seule qui aille chercher P[K] sur le serveur SI, et qui la déchiffre à l'aide de P, puis qui détruise K et P[K] sur le poste client et sur le serveur. Le système de contrôle S peut en outre inclure un serveur de transmission S3 distinct de Spki, chargé d'envoyer au tiers T le mot passe P. Cette architecture permet que Spki ne connaisse pas le numéro de téléphone de T, ce qui présente un intérêt particulier quand le serveur de certification Spki est exploité par une autorité distincte du prestataire de service, le numéro de 25 téléphone pouvant alors être considéré comme une ressource critique. Une telle réalisation est illustrée par la figure 3. Le fonctionnement en est essentiellement le même que celui de la figure 2, avec les différences suivantes: * L'étape 16 est subdivisée en deux sous-étapes: l'une (16a) o le serveur 30 SI ordonne à Spki de transmettre le mot de passe P au serveur de transmission S3, avec une certaine référence, et l'autre (16b) o SI - 15 ordonne à S3 de relayer P au tiers T par SMS, en fournissant à S3 la même référence ainsi que le numéro de téléphone à employer. * L'étape 17 est subdivisée en deux phases: l'une (17a) o Spki fournit P et la référence à S3, puis l'autre (17b) o S3 relaye P à T par SMS. La figure 4 illustre un autre mode de réalisation de l'invention dans lequel, en vue de l'obtention du certificat, le système de contrôle S ne transmet au tiers T qu'un moyen d'authentification, en plus de l'applet contrôlant les opérations exécutées par le poste du tiers T. Ce moyen d'authentification consiste par exemple en un mot de passe 10 Pauth- Laclé privée K allouée au tiers T est générée dans l'applet puis certifiée par le serveur Spki, ce qui économise un certain nombre d'opérations en amont. Cette réalisation permet aussi de ne générer un certificat que si le tiers T se manifeste. Un autre avantage est que la clé privée K n'est jamais transmise, même sous forme chiffrée. Le déroulement du procédé est alors le suivant, dans le cas déjà envisagé sur la figure 2 d'un service de courrier électronique recommandé avec accusé de réception signé. Etape 31: U se connecte au serveur SI grâce à un navigateur web, et choisit d'envoyer un message en clair avec accusé de réception signé, à un 20 tiers T. Les éléments transmis au serveur sont le message M et l'adresse e-mail de T. Etape 32: SI s'adresse à Spki pour lui demander la génération d'un mot de passe comme moyen d'authentification de T, dont la durée de validité peut être de 7 jours. Etape 33: Spki génère et stocke le mot de passe Pauth' qu'il transmet à Si. Etape 34: SI transmet à T, par exemple par e-mail, un avis de mise à disposition d'un message, ainsi que l'adresse de retrait. - 16- Etape 35: Etape 36: 10 T se connecte à Sl grâce à un navigateur, et récupère Pauth, l'accusé de réception à signer, ainsi que l'applet de signature. Il est informé dans la page qu'il doit s'authentifier auprès de Spki. T s'authentifie auprès de Spki, en présentant le mot de passe Pauth' L'authentification peut aussi porter sur l'adresse e-mail ou une adresse IP de T si une telle adresse a été fournie à Spki et stockée en relation avec Pauth' L'authentification de T peut se faire dans le cadre d'un canal authentifié, consistant par exemple en une session du protocole SSL ("Secure Socket Layer", défini par la société Netscape Communications Corporation) établie avec le serveur Spki. Etape 37: l'applet exécutée dans l'unité T génère la bi-clé K - Kpub. Etape 38: I'applet exécutée dans l'unité T génère une requête de certificat de signature à l'aide de la clé publique Kpub générée à l'étape 37, et généralement aussi à l'aide de la clé privée K. La requête est transmise au serveur Spki dans la session SSL. Etape 39: Spki génère un certificat temporaire de signature pour T et le communique d'une part à Sl et d'autre part à T dans la session SSL. Etapes 40 à 46: identiques aux étapes 19 à 25 décrites en référence à la figure 2. - 17 REVENDICATIONS 1. Procédé d'échange sécurisé entre une première unité de communication (U) et une seconde unité de communication (T) par l'intermédiaire d'un système de contrôle (S), dans lequel au moins une clé 5 privée (K) et un certificat (C) incorporant une clé publique associée à la clé privée sont générés pour la seconde unité en réponse à la réception par le système de contrôle, depuis la première unité, d'une requête de communication avec la seconde unité, et la seconde unité exécute au moins une opération cryptographique avec la clé privée en relation avec un message 10 (M) issu de la première unité. 2. Procédé selon la revendication 1, dans lequel le système de contrôle (S) transmet à la seconde unité (T) une application en langage à code mobile, adaptée pour superviser les opérations effectuées par la seconde unité en relation avec la clé privée (K). 3. Procédé selon la revendication 1 ou 2, comprenant les étapes suivantes: - la première unité (U) transmet au système de contrôle (S) la requête de communication avec la seconde unité (T), accompagnée d'au moins un identifiant de la seconde unité; - le système de contrôle génère pour la seconde unité au moins une clé privée (K) et un certificat (C) incorporant une clé publique associée à la clé privée; - le système de contrôle transmet une version chiffrée de la clé privée à la seconde unité, par un premier chemin de communication; - le système de contrôle transmet une clé de déchiffrement à la seconde unité, par un second chemin de communication; et - 18 - la seconde unité récupère la clé privée à partir de sa version chiffrée à l'aide de la clé de déchiffrement, et exécute au moins une opération cryptographique avec la clé privée. 4. Procédé selon la revendication 3, dans lequel la clé privée (K) est chiffrée à l'aide d'un mot de passe (P) transmis à la seconde unité (T) par le second chemin de communication. 5. Procédé selon chacune des revendications 2 et 3, dans lequel l'application en langage à code mobile exécutée dans la seconde unité (T) va chercher la version chiffrée de la clé privée au système de contrôle (S), 10 déchiffre la clé privée (K) à l'aide de la clé de déchiffrement (P), exécute ladite opération cryptographique, puis détruit la clé privée à la seconde unité et commande la destruction de la version chiffrée de la clé privée au système de contrôle. 6. Procédé selon l'une quelconque des revendications 3 à 5, dans lequel le système de contrôle (S) notifie la requête de communication à la seconde unité (T) après avoir obtenu le certificat (C), et dans lequel en réponse à la notification, la seconde unité établit une session de communication avec le système de contrôle par l'intermédiaire du premier chemin de communication pour se faire envoyer la version chiffrée de la clé privée et le certificat. 7. Procédé selon la revendication 1 ou 2, comprenant les étapes suivantes: - la première unité (U) transmet au système de contrôle (S) la requête de communication avec la seconde unité (T), accompagnée d'au moins un identifiant de la seconde unité; - le système de contrôle obtient une clé d'authentification (Pauth) pour la seconde unité et notifie la requête de communication à la seconde unité par un premier chemin de communication; 19 - la seconde unité s'authentifie auprès du système de contrôle, en établissant un canal de communication authentifié sur un second chemin de communication entre la seconde unité et le système de contrôle; - la seconde unité génère un couple clé privée - clé publique; - la seconde unité transmet au système de contrôle, sur le canal authentifié, une requête de certificat générée au moyen d'au moins la clé publique; - le système de contrôle génère et transmet à la seconde unité, sur le canal authentifié, le certificat incorporant la clé publique; et - la seconde unité exécute au moins une opération cryptographique avec la clé privée (K). 8. Procédé selon la revendication l'une quelconque des revendications 3 à 7, dans lequel l'identifiant de la seconde unité (T) inclut une adresse de messagerie électronique et/ou un numéro de téléphone mobile. 9. Procédé selon l'une quelconque des revendications 3 à 8, dans lequel le système de contrôle (S) comprend un premier serveur (Si) communiquant avec la première unité (U) et, par le premier chemin de communication, avec la seconde unité (T), et un second serveur (Spki) communiquant avec la seconde unité par le second chemin de communication. 10. Procédé selon la revendication 9, dans lequel la requête de communication est reçue par le premier serveur (SI) qui sollicite le second serveur (Spki) pour qu'il obtienne le certificat (C), le second serveur retournant le certificat au premier serveur. 11. Procédé selon la revendication 9 ou 10, dans lequel le système de contrôle (S) comprend un troisième serveur (S3) par l'intermédiaire duquel le second serveur (Spki) communique avec la seconde unité (T). - 20 12. Procédé selon l'une quelconque des revendications 3 à 11, dans lequel le second chemin de communication est sélectionné par la seconde unité (T). 13. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend le déchiffrement d'un message (M) issu de la première unité (U), et dans lequel après avoir obtenu le certificat (C) , le système de contrôle (S) transmet la clé publique à la première unité, la première unité chiffrant le message à l'aide de ladite clé publique et 10 transmettant le message chiffré à destination de la seconde unité. 14. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend la signature d'un accusé de réception d'un message (M) issu de la première unité (U). 15. Procédé selon la revendication 14, dans lequel le système de contrôle (S) reçoit ledit message (M) de la première unité (U) et l'accusé de réception signé par la seconde unité (T), et vérifie la signature de l'accusé de réception avant de faire suivre le message à la seconde unité. 16. Procédé selon l'une quelconque des revendications précédentes, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend une authentification vérifiable par la clé publique, une opération d'horodatage et/ou l'inclusion d'une preuve persistante de validité du certificat (C). 17. Système de contrôle d'échanges sécurisés entre une première unité de communication (U) et une seconde unité de communication (T), comprenant des moyens pour générer, en réponse à la réception, depuis la première unité, d'une requête de communication avec la seconde unité, au moins un certificat (C) incorporant une clé publique associée à une clé privée (K) propre à la seconde unité, et des moyens pour commander l'exécution par la seconde - 21 unité d'au moins une opération cryptographique avec la clé privée en relation avec un message (M) issu de la première unité. 18. Système selon la revendication 17, dans lequel les moyens pour commander l'exécution d'au moins une opération cryptographique par la 5 seconde unité (T) comprennent des moyens de transmission à la seconde unité d'une application en langage à code mobile. 19. Système selon la revendication 17 ou 18, comprenant des moyens pour, en réponse à la réception de la requête de communication, générer pour la seconde unité (T) au moins une clé privée (K) et un certificat (C) incorporant 10 une clé publique associée à ladite clé privée, des moyens pour transmettre une version chiffrée de la clé privée à la seconde unité, par un premier chemin de communication, et des moyens pour transmettre une clé de déchiffrement (P) à la seconde unité, par un second chemin de communication. 20. Système selon la revendication 17 ou 18, comprenant des moyens pour, en réponse à la réception de la requête de communication, obtenir une clé d'authentification pour la seconde unité (T) et notifier la requête de communication à la seconde unité par un premier chemin de communication, des moyens d'authentification de la seconde unité et d'établissement d'un canal de communication authentifié sur un second chemin de communication 20 entre la seconde unité et le système de contrôle, des moyens de commande de la seconde unité pour qu'elle génère un couple clé privée - clé publique et émette, sur le canal authentifié, une requête de certificat générée au moyen d'au moins la clé publique, et des moyens pour générer et transmettre à la seconde unité, sur le canal authentifié, le certificat (C) incorporant la clé 25 publique. 21. - Système selon la revendication 19 ou 20, comprenant un premier serveur (SI) communiquant avec la première unité (U) et, par le premier chemin de communication, avec la seconde unité (T), et un second serveur 22 (Spki) communiquant avec la seconde unité par le second chemin de communication. 22. Système selon la revendication 21, dans lequel le premier serveur (SI) comprend des moyens de réception de la requête de communication et 5 des moyens pour solliciter le second serveur (Spki) pour qu'il obtienne le certificat (C), le second serveur retournant le certificat au premier serveur. 23. Système selon la revendication 21 ou 22, comprenant un troisième serveur (S3) par l'intermédiaire duquel le second serveur (Spki) communique avec la seconde unité (T). 24. Système selon l'une quelconque des revendications 17 à 23, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend le déchiffrement d'un message (M) issu de la première unité (U), le système de contrôle (S) comprenant des moyens pour transmettre la clé publique à la première unité après avoir obtenu le certificat 15 (C) et des moyens pour relayer à la seconde unité un message chiffré par la première unité à l'aide de ladite clé publique. 25. Système selon l'une quelconque des revendications 17 à 24, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend la signature d'un accusé de réception d'un message 20 (M) issu de la première unité (U). 26. Système selon la revendication 25, comprenant des moyens de réception dudit message de la première unité (U), des moyens de réception de l'accusé de réception signé par la seconde unité (T), et des moyens de vérification de la signature de l'accusé de réception avant de faire suivre le 25 message (M) à la seconde unité. 27. Serveur de contrôle d'échanges sécurisés entre une première unité de communication (U) et une seconde unité de communication (T), comprenant des moyens pour s'adresser à un serveur de certification (Spki) en réponse à la - 23 réception, depuis la première unité, d'une requête de communication avec la seconde unité, afin d'obtenir du serveur de certification au moins un certificat (C) incorporant une clé publique associée à une clé privée (K) propre à la seconde unité, et des moyens pour commander l'exécution par la seconde 5 unité d'au moins une opération cryptographique avec la clé privée en relation avec un message (M) issu de la première unité. 28. Serveur selon la revendication 27, dans lequel les moyens pour commander l'exécution d'au moins une opération cryptographique par la seconde unité (T) comprennent des moyens de transmission à la seconde 10 unité d'une application en langage à code mobile. 29. Serveur selon la revendication 27 ou 28, dans lequel le certificat (C) est obtenu avec une version chiffrée de la clé privée produite par le serveur de certification (Spki), le serveur de contrôle d'échanges sécurisés (SI) comprenant des moyens pour transmettre la version chiffrée de la clé privée à 15 la seconde unité (T). 30. Serveur selon l'une quelconque des revendications 27 à 29, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec la clé privée (K) comprend le déchiffrement d'un message (M) issu de la première unité (U), le serveur de contrôle d'échanges sécurisés (SI) 20 comprenant des moyens pour transmettre la clé publique à la première unité après avoir obtenu le certificat (C) et des moyens pour relayer à la seconde unité un message chiffré par la première unité à l'aide de ladite clé publique. 31. Serveur selon l'une quelconque des revendications 27 à 30, dans lequel ladite opération cryptographique exécutée par la seconde unité (T) avec 25 la clé privée (K) comprend la signature d'un accusé de réception d'un message (M) issu de la première unité (U). 32. Serveur selon la revendication 31, comprenant des moyens de réception dudit message de la première unité (U), des moyens de réception de l'accusé de réception signé par la seconde unité (T), et des moyens de 24 vérification de la signature de l'accusé de réception avant de faire suivre le message (M) à la seconde unité.