FR2954838A1 - Securisation des flux de donnees dans un systeme informatique - Google Patents

Abstract

On propose un procédé de sécurisation de flux de données émis par des applications de communication mises en oeuvre par un système informatique comportant un ou plusieurs ports de communication. Le procédé comporte les étapes : - de surveillance d'au moins un desdits ports de communication utilisés par les applications à sécuriser pour intercepter un flux de données à émettre ou à recevoir, - de prise en compte d'une politique de sécurisation, commune auxdites applications, définissant quels sont les flux de données à sécuriser, en déterminant si le flux de données intercepté doit être sécurisé, et dans l'affirmative, - de sécurisation du flux de données intercepté par application d'une fonction de traitement audit flux de données, et - de transmission du flux de données sécurisé via le port sur lequel le flux de données était initialement prévu par l'application.

Description

Sécurisation des flux de données dans un système informatique La présente invention concerne la sécurisation des flux de données émis ou reçu par un système informatique. Les applications de communication, telles que les clients de messagerie électronique ou autre, intègrent généralement des mécanismes de sécurisation des messages. Il s'agit la plupart du temps du chiffrement et/ou de la signature de ces messages selon diverses techniques de cryptographie. La signature garantit l'intégrité des données et l'identité de l'émetteur, le chiffrement garantit la confidentialité de la communication. Ces mécanismes de sécurisation sont souvent propres à chaque application et à chaque type de données à sécuriser. Ainsi, sur un poste informatique, on retrouve autant de mécanismes de sécurisation des données que d' applications de communication. Avec la diversification des types d'échanges de données sur les postes informatiques (courriels, messagerie instantanée, échanges pair à pair, voix sur IP ou autre), il devient compliqué pour l'utilisateur de gérer la sécurisation de ses communications. En effet, il doit configurer chaque application afin de sélectionner les options de sécurisation à appliquer aux envois de données. Une configuration partielle ou inadaptée peut, dans les pires cas, conduire à des failles de sécurité dans le système informatique. Selon un autre point de vue, le besoin de sécurisation est souvent autant lié à la nature de l'échange et aux liens qui existent entre les personnes qui échangent des messages ou flux, qu'aux applications utilisées pour cet échange. Les systèmes actuels ne facilitent pas la prise en compte de ces liens.

La protection des communications dans les systèmes informatiques pose donc problème pour les raisons indiquées ci-avant. La présente invention vient améliorer la situation. A cet effet, selon un premier aspect de l'invention, on propose un procédé fonctionnant selon les mécanismes décrits dans la revendication 1.

Ainsi, selon l'invention, les flux de données sont interceptés pour sécurisation avant leur transmission, conformément à une politique de sécurisation centralisée. La sécurisation des données est ainsi simplifiée pour l'utilisateur du système informatique puisqu'il lui suffit de définir la politique de sécurisation appliquée par un composant de sécurisation, par exemple un logiciel, qui se charge de sécuriser les flux interceptés conformément à cette politique de sécurisation. La politique de sécurisation permet d'identifier un flux à sécuriser en fonction par exemple de l'application émettrice du flux, du destinataire du flux ou de tout autre critère de d'identification des flux à sécuriser prévu dans la politique de sécurisation. La politique de sécurisation peut en outre faire partie d'un profil d'utilisateur défini pour l'utilisateur émetteur des flux de données à sécuriser. Ainsi, chaque utilisateur est capable de définir les flux à sécuriser selon la nature de la relation qu'il entretient avec un destinataire, ou selon l'usage qu'il fait d'une application donnée. La politique de sécurisation est ainsi adaptée aux habitudes de communication de l'utilisateur émetteur. Par exemple, l'émetteur configure une politique qui sécurise systématiquement tous les flux, ou seulement certains flux, vers un destinataire donné, ou vers un groupe de destinataires donné, ou encore sans tenir compte des destinataires. Inversement, il peut décider de ne jamais sécuriser les flux de l'application (débrayage de la sécurité) ou vers certains destinataires, ou bien encore il peut décider de définir la politique à appliquer uniquement au moment de l'émission du flux. L'invention est en outre applicable aussi bien à la sécurisation de flux de données synchrones que de flux asynchrones. Ainsi, il est possible de sécuriser la plupart des flux de données mis en oeuvre sur un poste informatique : courriels, messagerie instantanée, voix sur IP, échanges pair à pair, ou autre. Le fait de surveiller les ports de communication du système informatique permet d'intercepter tous les flux émis par ce système, sans avoir à interférer avec le fonctionnement des applications émettrices de flux et donc sans perturber l'utilisation qui est faite de ces applications: la sécurisation s'effectue ainsi de manière transparente pour l'utilisateur qui utilise ses applications sans modifier ses habitudes d'utilisation. Les ports surveillés (ou écoutés) sont par exemple des ports TCP (« Transmission Control Protocol ») communément utilisés par les applications de communication. Les flux de données à émettre par transmission sécurisée sont par exemple les flux émis par des applications dont les communications doivent, conformément à la politique de sécurisation, être sécurisées. La fonction de traitement appliquée pour la sécurisation du flux est typiquement une fonction de chiffrement et/ou de signature de tout ou partie des données du flux. Outre cette fonction de traitement, le composant de sécurisation a pour rôle de déterminer la fonction de traitement à appliquer à un flux en fonction du destinataire de ce flux et d'un profil de sécurisation, associé à ce destinataire, défini dans la politique de sécurisation. Enfin, dans les cas où la politique de sécurisation ne permet pas de déterminer quelle est la fonction de traitement à appliquer, le composant de sécurisation est conçu pour interroger l'utilisateur émetteur du flux en affichant par exemple un formulaire qui présente à l'utilisateur des choix à effectuer pour décider de la politique de sécurisation à appliquer lors de l'envoi de données, pour traiter la réponse de l'utilisateur et pour appliquer la fonction de traitement choisie par cette réponse. Selon un mode de réalisation, les réponses de l'utilisateur sont utilisées pour modifier la politique de sécurisation couramment définie. Des règles de sécurisation sont ainsi déduites des réponses fournies : par exemple, l'émetteur peut décider de toujours sécuriser ce type d'échange avec les destinataires, ou de ne jamais les sécuriser, ou bien encore de ne pas modifier la politique de sécurisation. Lorsque la méthode de chiffrement utilisée est un chiffrement asymétrique par un mécanisme à clé publique et clé privée, la clé de chiffrement utilisée est une clé publique affectée au destinataire du flux à sécuriser. Le chiffrement peut également se faire par chiffrement symétrique. Dans ce cas, la clé de chiffrement peut être déjà connue du destinataire ou être transmise avec les données chiffrées. La signature peut elle se faire par un mécanisme de chiffrement asymétrique à clé publique et clé privée, un condensat du message, envoyé avec le message lui-même, étant chiffré avec la clé privée de signature de l'émetteur, stockée sur son ordinateur. Selon un mode de réalisation, la politique de sécurisation permet de spécifier le ou les ports à surveiller. Ces ports peuvent par exemple correspondre aux ports utilisés par des applications de communication dont on souhaite sécuriser les échanges. Par exemple, on écoute sélectivement les ports utilisés par les messageries électroniques, les applications de messagerie instantanée ou autre. Selon un mode de réalisation, la politique de sécurisation permet de spécifier une sécurisation systématique des communications à destination d'un destinataire particulier.

Pour les communications vers de multiples destinataires, la politique de sécurisation peut également être appliquée pour tous les flux de données émis vers les différents destinataires. Dans des modes de réalisation, on prévoit en outre une étape d'identification d'un destinataire du flux de données intercepté. Dans ce cas, le flux intercepté et identifié est sécurisé si le destinataire du flux fait partie des destinataires pour lesquels une sécurisation systématique est requise par la politique de sécurisation. L'identification du destinataire peut par exemple se faire selon une adresse physique d'une machine sur un réseau, ou selon une adresse symbolique d'un utilisateur du réseau. On peut en outre prévoir d'obtenir une clé de chiffrement associée au destinataire, pour le chiffrement du flux de données. Dans des modes de réalisation, on prévoit en outre l'identification du type de flux détecté. Ainsi, la politique de sécurisation permet de sécuriser le flux selon son type. Par exemple, un utilisateur pourrait décider de sécuriser tous les flux de type "transfert de fichier" sortant de son système. Ainsi, quels que soit le logiciel et le port que ce dernier utilise ou utilisera pour transférer un fichier, le flux sera sécurisé. Afin de renforcer la sécurité des échanges on peut en outre prévoir, lorsque la fonction de traitement appliquée est une fonction de chiffrement, les étapes : - d'obtention d'une première clé de chiffrement à utiliser lors de l'application de la fonction de traitement au flux de données intercepté; - de chiffrement de la première clé de chiffrement au moyen d'une deuxième clé de chiffrement; - de transmission de la première clé de chiffrement chiffrée au destinataire. En outre, il est possible de changer de clé de chiffrement à chaque communication, la première clé de chiffrement étant dans ce cas par exemple générée aléatoirement.

Dans un mode de réalisation, le chiffrement de la première clé de chiffrement se fait par chiffrement asymétrique avec une deuxième clé de chiffrement qui est une clé publique de chiffrement affectée au destinataire du flux de données à sécuriser, obtenue auprès : - d'un annuaire de clés stocké auprès du système informatique, ou - d'un serveur distant de clés de chiffrement, ou - du destinataire du flux de données intercepté. Le stockage des clés publiques auprès d'un serveur distant permet notamment d'économiser de l'espace de stockage et d'assurer l'authenticité de la clé utilisée. L'annuaire permet de tenir à jour la liste des clés de chiffrement en fonction des communications de l'utilisateur du système informatique.

L'obtention de la clé publique auprès du destinataire permet de s'assurer que la clé publique émane effectivement de ce dernier, en particulier lors d'une première communication avec lui, ou lors d'une session d'initialisation de la communication. Selon d'autres aspects de l'invention, il est prévu : - un programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon le premier aspect de l'invention lorsque le programme est exécuté par un processeur ; - un support lisible par un ordinateur sur lequel est enregistré un tel programme d'ordinateur ; et - un système informatique pour la mise en oeuvre d'un procédé selon le premier aspect de l'invention. Selon d'autres aspects, l'invention concerne un système informatique comportant : - un ou plusieurs ports de communication utilisés par des applications pour transmettre et recevoir des flux de données, - une unité de sécurisation des flux de données émis par des applications de communication mises en oeuvre par le système informatique, configurée pour - intercepter un flux de données à émettre via l'un au moins desdits ports, - déterminer, par application d'une politique de sécurisation, commune auxdites applications, définissant quels sont les flux de données à sécuriser, si un flux de données intercepté doit être sécurisé, - sécuriser un flux de données intercepté et transmettre ce flux de données sécurisé vers sa destination initiale. Les avantages procurés par le programme d'ordinateur, le support lisible par ordinateur, et le système informatique, tels que succinctement exposés ci-dessus, sont au moins identiques à ceux mentionnés plus haut en liaison avec le procédé selon l'invention. D'autres caractéristiques et avantages de l'invention apparaîtront encore à la lecture de la description qui va suivre. Celle-ci est purement illustrative et doit être lue en regard des dessins annexés sur lesquels : - la figure 1 illustre un contexte général de mise en oeuvre d'un mode de réalisation de l'invention ; - la figure 2 est un organigramme d'étapes mises en oeuvre dans un procédé selon un mode de réalisation de l'invention ; - la figure 3 illustre l'obtention d'une clé de chiffrement selon un mode de réalisation de l'invention ; - les figures 4 et 5 illustrent la mise en oeuvre de modes de réalisation de l'invention dans le cadre d'un flux de messagerie électronique, et dans le cadre d'un flux de messagerie instantanée ; et - la figure 6 illustre schématiquement un système informatique selon un mode de réalisation de l'invention. En référence à la figure 1, on décrit un contexte général de mise en oeuvre d'un mode de réalisation de l'invention. Dans ce mode de réalisation, on propose de sécuriser les échanges de données d'un système informatique 10. Par exemple, il s'agit d'un ordinateur de bureau connecté à réseau de communications 11 tel qu'Internet. Le système informatique met en oeuvre diverses applications de communication 12. Par exemple, il s'agit d'un client de courrier électronique, d'une application de messagerie instantanée, d'une application de voix sur IP, d'une application d'échange pair à pair ou autre.

Ces applications de communication établissent des communications selon différents types de flux de données (texte, son, image, ou autre) via une interface de communication 13 du système. Cette interface comporte différents ports de communication (non représentés). Les communications sont destinées à des systèmes informatiques destinataires 14 reliés au système informatique, via le réseau 11.

On dispose entre les applications 12 et l'interface de communication 13, un composant de sécurité 15. Ce composant est par exemple un logiciel configurable par l'utilisateur du système informatique, pour sécuriser ou chiffrer les communications mises en oeuvre sur ce système. Ainsi, l'utilisateur peut utiliser les différentes applications, et peut passer de l'une à l'autre sans se soucier de la politique de sécurité à mettre en oeuvre pour chacune des applications. Le composant 15 se charge d'écouter les ports de communication pour intercepter les flux sortant et les sécuriser avant leur transmission vers les destinataires 14. Par exemple, le composant de sécurité est associé à une adresse électronique de l'utilisateur du système 10 au moyen d'un certificat contenant cette adresse électronique. L'utilisateur définit une politique de sécurité, valable pour toutes les applications, en configurant le composant de sécurité. La politique de sécurisation définit quels sont les flux de données à sécuriser, pour quels destinataires, et quel est le mode de sécurisation à appliquer. Pour cela, l'utilisateur peut : - configurer chacune des applications à sécuriser de telle sorte que le composant de sécurité intercepte les flux émis par ces applications. Par exemple sécuriser son application de messagerie et son application de messagerie instantanées. Le procédé prévoit une configuration type à appliquer pour chaque port à sécuriser, elle consiste essentiellement à définir les nouveaux ports à utiliser par l'application pour adresser le composant. Muni de ces éléments, l'utilisateur doit modifier la configuration réseau de ces applications en fonction de la configuration type indiquée : par exemple, pour chacun des ports utilisés par l'application à sécuriser, l'utilisateur remplace la configuration de l'application par la configuration adaptée au composant de sorte à adresser le composant lors de l'émission/réception des flux à sécuriser, puis il répercute dans la configuration du composant la configuration initiale de l'application, de sorte à ce que le composant relaie les flux applicatifs vers les adresses et ports usuellement utilisés par l'application. La configuration permet de sécuriser ainsi plusieurs applications qui utiliseraient les mêmes ports, 25 - établir une liste des adresses de destinataires pour lesquels une sécurisation systématique de tous les flux de données émis vers ces destinataires est requise (adresse de courriel, de messagerie instantanée, de voix sur IP, ou autre), sachant que cette liste pourra aussi être alimentée dynamiquement par le composant de sécurité lors de l'interception d'un échange avec lesdits destinataires, - déterminer le mode de sécurisation des flux de données en identifiant au moins une fonction de traitement à appliquer à un flux de données : signature numérique et/ou chiffrement, ainsi que choix des algorithmes de signature numérique et/ou chiffrement; le mode de sécurisation est de préférence fonction d'un ou plusieurs paramètres, par exemple fonction du destinataire du flux de données et/ou de l'application émettrice du flux de données et/ou du type de flux de données et/ou du protocole utilisé pour transmettre ce flux et/ou du port de communication utilisé; dans ce but, un mécanisme de définition de règles de détermination du mode de 20 30 35 sécurisation est proposé à l'utilisateur; des règles par défaut sont avantageusement proposées pour simplifier le travail de l'utilisateur, - choisir une méthode d'obtention d'une clé cryptographique à utiliser lors de l'exécution de la fonction de traitement : la méthode consiste par exemple à générer une seule clé cryptographique pour l'ensemble des adresses ou à générer une clé cryptographique par adresse à sécuriser (dans ce cas un annuaire de clés est mis à jour), ou toute autre méthode. Par exemple, l'utilisateur peut décider de sécuriser tous les échanges des applications à sécuriser. Dans ce cas tous les ports de communication de ces applications sont analysés et tous les flux sont sécurisés. Ou encore, il peut décider de ne pas sécuriser systématiquement : chaque fois qu'un flux est détecté, le système demande à l'utilisateur (dans une fenêtre de dialogue) de confirmer qu'il souhaite sécuriser l'échange. Par exemple encore, l'utilisateur peut décider de sécuriser différemment les différentes applications. Cela peut être le cas d'un client de messagerie à usage professionnel pour lequel tous les flux de données sont sécurisés sans qu'il ne soit demandé de confirmation à l'utilisateur.

Dans une configuration, l'utilisateur peut indiquer les destinataires de flux pour lesquels une sécurisation systématique de tous les flux émis vers ces destinataires est requise. Optionnellement, il peut limiter la sécurisation systématique à certaines des applications sécurisées. Le système peut stocker localement un annuaire de certificats associés aux contacts (destinataires). Cet annuaire peut être automatiquement alimenté au fil des échanges, et comporter les adresses des destinataires avec qui les échanges peuvent être chiffrés, et les certificats associés. En référence à la figure 2, on décrit des étapes mises en oeuvre dans un mode de réalisation de l'invention. Dans une première étape S20, on se met à l'écoute des ports de communication du système informatique afin de détecter lors de l'étape T21 un flux de données à transmettre.

Par exemple, cette détection du flux consiste à détecter la sollicitation par une application d'un port de communication. Par exemple, lors du démarrage du composant de sécurité, on initialise une ou plusieurs interfaces de connexion (nommées "sockets" dans la terminologie anglo-saxonne) pour une liste de ports de communication IP associés au composant de sécurité, chaque interface étant associée à l'adresse machine prédéfinie pour le système informatique 10 (nommée "localhost"): ceci a pour effet de lancer en tâche de fond un processus informatique ("daemon" en anglais) qui intercepte tout le trafic IP adressé aux ports en question: ce processus est adressé au moyen de l'adresse "localhost" en association avec le numéro du port surveillé. Les applications de communication à sécuriser ont été au préalable configurées pour qu'elles utilisent ces interfaces de connexion lors de l'envoi ou la réception de flux de données, tel que décrit ci-dessus. Le composant se positionne alors en coupure de flux, intercepte et traite ces flux de manière transparente pour l'utilisateur, relayant les flux de données sécurisés vers les adresses et ports usuellement utilisés par l'application émettrice du flux intercepté.

Par exemple, au démarrage du composant de sécurité, celui-ci initialise pour l'envoi de courriels une interface de connexion sur un port SMTP portant le numéro 25, pour le serveur de messagerie de l'utilisateur (dont l'adresse est par exemple smtp.fournisseur.fr). Les applications de messagerie sont dans ce cas configurées par l'utilisateur pour utiliser cette interface de connexion: ceci se fait en indiquant l'adresse "localhost" et un numéro de port (par exemple 1025) de l'interface de connexion dans les paramètres du serveur d'envoi de courriels. Lorsqu'un flux est intercepté sur une telle interface de connexion, il est transmis vers l'adresse et le port, usuellement utilisés pour adresser le serveur de messagerie, mémorisés pour cette interface de connexion, c'est-à-dire vers le serveur de messagerie de l'utilisateur d'adresse smtp.fournisseur.fr et par exemple le port numéro 25.

Toute autre méthode d'interception de flux est également envisageable: par exemple les mécanismes d'interception de flux utilisés par les logiciels anti-virus. Lorsqu'un flux de communication est détecté, le composant de sécurité 15 identifie lors de l'étape S22 si le flux de données intercepté doit être sécurisé conformément à la politique de sécurité définie : il considère d'une part la politique relative à l'application (par défaut les flux interceptés sont à sécuriser, mais l'utilisateur a la possibilité de débrayer la sécurité), d'autre part celle relative aux destinataires. Si la politique de sécurisation indique que le flux est bien à sécuriser, le composant de sécurité 15 recherche dans son annuaire interne le destinataire du flux de données intercepté afin de lui appliquer la politique de sécurisation qui lui est associé. Le destinataire est identifié par exemple par un identifiant ou une adresse du destinataire présent dans le flux de données intercepté. Par exemple, le composant analyse les données du protocole pour récupérer l'identifiant ou l'adresse du destinataire, les compare à son annuaire interne pour retrouver le destinataire adressé et en déduire la politique de sécurisation à lui appliquer. Lorsque le destinataire n'est pas identifié, le composant affiche un formulaire pour que l'émetteur indique la politique de sécurisation à adopter. Ces caractéristiques sont enregistrées dans l'annuaire, ce qui permettra au composant de déduire le comportement à adopter lors du prochain échange avec ce destinataire. Si la politique de sécurisation définit plusieurs modes de sécurisation des flux de données et des règles de détermination du mode de sécurisation à appliquer, le composant de sécurité 15 identifie la fonction de traitement à appliquer à un flux de données : cette fonction est par exemple une fonction de chiffrement et/ou de signature numérique. On suppose dans la suite que la fonction de traitement à appliquer est un chiffrement. Lors de l'étape S23, le composant de sécurité 15 obtient une clé cryptographique à utiliser lors de l'application de la fonction de traitement, en l'occurrence une clé de chiffrement associée au destinataire pour chiffrer les données du flux lors de l'étape S24.

Tout algorithme de chiffrement connu de l'homme du métier est susceptible d'être utilisé. Par exemple, on peut mettre en oeuvre un algorithme de cryptographie symétrique tel que « triple DES », ou d'autres algorithmes symétriques ou asymétriques. La méthode de sécurisation (chiffrement et/ou signature) proposée ici ne modifie pas le protocole de communication utilisé pour l'envoi du flux ou le format de codage du message, seules les données transmises via ce flux ou ce message sont chiffrées et/ou signées. Il s'agit donc d'une sécurisation applicative, de bout en bout. Par exemple, un flux HTTP reste un flux HTTP, un message électronique SMTP ou XMPP reste un message SMTP ou XMPP. En conséquence, le message sécurisé obtenu à l'étape 24 peut dans tous les cas être reçu par l'application destinatrice du flux / message, même en l'absence d'un composant de sécurité associé à cette application destinatrice. Ensuite, dès lors que cette application destinatrice dispose de la ou des clés nécessaires au déchiffrement ou à l'authentification de signature, elle peut déchiffrer le message ou authentifier son émetteur. En particulier, il n'est pas fait usage de tunnels tels que VPN ou de procédés de bascule sur des protocoles sécurisés tels que HTTPS pour encapsuler l'ensemble du flux transmis.

Enfin, lors de l'étape S25, le composant de sécurité 15 émet vers le destinataire le flux sécurisé û en l'occurrence chiffré - vers l'adresse et via le port usuellement utilisés par l'application émettrice du flux. Ce port est connu de par la configuration du composant de sécurité, l'adresse et port du serveur cible usuellement utilisés par l'application émettrice étant mémorisés par le composant de sécurité. Un programme d'ordinateur comportant des instructions pour la mise en oeuvre du procédé selon l'invention peut être réalisé selon un algorithme général déduit de l'organigramme général de la figure 2, et de la présente description détaillée. Par exemple, un programme de mise à jour du profil d'activité peut-être réalisé selon le pseudocode suivant : DETECT_FLW() Pour i = 0 à TAILLE(LIST_PORT)-1 Si (FLW(LIST_PORT(i)) = VRAI) alors SECUR(LIST_PORT(i)); i+1; FIN FIN FIN La fonction DETECT_FLW consiste à surveiller les ports de communication du système contenus dans l'objet LIST_PORT qui répertorie ces ports. La fonction FLW renvoie un booléen VRAI si le port qui lui est donné en argument est sollicité pour la transmission d'un flux de données ou un booléen FAUX sinon. Lorsqu'un flux est détecté, la fonction SECUR est appelée avec en argument le port sur lequel est détecté le flux en argument. SECUR(. ) IDENTIF_DEST(.) -* DEST ; CRYPTO_K(DEST) -* CRYPTO_K ; CRYPTO (. , CRYPTO_K) ; FIN La fonction SECUR reçoit en argument un port de communication à sécuriser. Elle appelle la fonction IDENTIF_DEST pour identifier le destinataire du flux, puis obtient la clé de chiffrement associée à ce destinataire avec la fonction CRYPTO K. La fonction de chiffrement CRYPTO est ensuite appelée pour chiffrer le flux selon la clé de chiffrement obtenue. En référence à la figue 3, on décrit plus en détails une méthode d'obtention de la clé cryptographique mise en oeuvre lors de l'étape 23 précédemment décrite.

Un utilisateur d'un système informatique 300 souhaite envoyer un message, créé avec une application 301 mise en oeuvre par le système 300, vers un utilisateur d'un système informatique 302. L'application 301 met alors en oeuvre l'interface de communication 303 du système, et un composant (ou module) de sécurité 304 intercepte le message afin, par exemple, de le chiffrer (ou crypter). Le composant de sécurité 304 est fonctionnellement identique au composant de sécurité 15 décrit ci-dessus.

Afin de chiffrer le message, le composant de sécurité obtient une clé cryptographique KC1, qui, dans l'exemple décrit ici, est une clé de chiffrement destinée à être utilisée pour chiffrer le message intercepté. Cette clé cryptographique KC1 doit être connue du destinataire pour lui permettre de déchiffrer par la suite le message. Différentes méthodes d'obtention de cette clé cryptographique KC1 sont utilisables.

Selon une première méthode (méthode A), le composant de sécurité 304 obtient la clé cryptographique KC1 par lecture dans une mémoire 305 du système 300. Par exemple, cette mémoire est un annuaire dédié de clés cryptographiques. Chaque clé cryptographique y est associée à un destinataire. L'annuaire peut être mis à jour régulièrement selon les échanges réalisés. Cette première méthode est mise en oeuvre par exemple lorsque le destinataire est connu du système informatique et que l'on dispose déjà de clés cryptographiques qui lui sont associées. Selon une deuxième méthode (méthode B), le composant de sécurité 304 obtient la clé cryptographique KC1 auprès d'un serveur de clés distant 306, via l'interface de communication. Dans cette deuxième méthode, le serveur 306 peut également servir de serveur d' authentification de clés. Par exemple, si une clé cryptographique KC1 est enregistrée dans l'annuaire 305, le composant de sécurité 304 peut demander au serveur 306 de vérifier l'authenticité de la clé cryptographique, c'est-à-dire qu'il s'agit bien d'une clé cryptographique acceptée par le destinataire. Selon une troisième méthode (méthode C), la clé cryptographique KC1 est une clé de chiffrement symétrique, tirée aléatoirement par l'émetteur du message à chaque nouvelle session de communication, chiffrée par le composant de sécurité 304 et adressée de manière chiffrée au destinataire, par exemple lors de l'initiation de la communication avec ce destinataire. Cette clé symétrique est utilisable pour chiffrer un message et pour déchiffrer un message chiffré avec cette clé. Le chiffrement de la clef cryptographique KC1 utilise par exemple une méthode de chiffrement asymétrique à clé publique et clé privée. Dans cet exemple, le composant de sécurité 304 obtient une clé publique de chiffrement KPUB2 associée au destinataire. Cette clé publique de chiffrement KPUB2 est obtenue auprès du destinataire, auprès du serveur 306, dans la mémoire 305, ou selon toute autre méthode appropriée. Par exemple, le destinataire, génère à partir d'une clé de chiffrement privée KPRI2, que lui seul connait, un ensemble de clés de chiffrement publiques qu'il met à disposition de ses correspondants. Ensuite, le composant de sécurité 304 chiffre la clé cryptographique KC1 au moyen de la clé publique de chiffrement KPUB2 associée au destinataire, la clé cryptographique KC1 étant elle utilisée pour chiffrer le message intercepté. De la sorte, seul le destinataire, qui possède la clé de chiffrement privée KPRI2 peut déchiffrer la clé cryptographique KC1 puis déchiffrer le message chiffré au moyen de cette clé cryptographique KC1. Dans cette troisième méthode, le composant de sécurité 304 communique directement, via l'interface 303 et l'interface de communication 307 du système 302, avec le composant de sécurité 308 du système 302. Le composant de sécurité 308 est fonctionnellement identique au composant de sécurité 15 décrit ci-dessus. Par exemple, le composant de sécurité 304 a identifié le destinataire du message, mais ne trouve pas de clé publique de chiffrement KPUB2 qui lui soit associée dans l'annuaire 305. Le composant de sécurité 304 prend alors contact directement avec le composant 308 pour procéder à un échange de clés de chiffrement publiques, propres à être utilisées pour le chiffrement de clés cryptographiques. Les composants 308 et 304 procèdent à l'échange de clés de chiffrement publiques. Le composant 308 enregistre alors une clé publique de chiffrement KPUB2 dans l'annuaire local 309 comme étant associée avec le destinataire du message intercepté. Le composant 308 garde la clé publique de chiffrement KPUB2 dans l'annuaire afin par exemple de l'associer au système 300 et éventuellement d'authentifier des messages chiffrés avec cette clé. Le composant 304 procède réciproquement. Ensuite, le composant 304 génère aléatoirement une clé cryptographique KC1, sous forme de clé de chiffrement symétrique, chiffre la clé cryptographique KC1 avec la clé publique de chiffrement KPUB2, et transmet la clé cryptographique KC1 chiffrée au composant 308 en précisant le type d'algorithme de chiffrement souhaité pour les données à échanger.

Le composant 308 renvoie alors au composant 304 un message d'acceptation du type d'algorithme de chiffrement souhaité. Le composant 304 peut alors chiffrer le message au moyen de la clé cryptographique KC1 et envoyer le message chiffré vers une application de communication 310 du système 302 via les interfaces de communication 303 et 307.

Cette troisième méthode est utilisée de préférence à la première ou à la deuxième méthode dans le cas où il y a plusieurs destinataires car elle est moins consommatrice en temps et puissance de calcul: en effet le message peut être chiffré une seule fois avec une clé cryptographique KC1 commune à tous les destinataires, seule la clé cryptographique KC1 étant chiffrée plusieurs fois, une fois pour chaque destinataire au moyen de la clé publique de chiffrement KPUB2 associée à chacun de ces destinataires.

En référence aux figures 4 et 5, on décrit la mise en oeuvre de modes de réalisation de l'invention dans le cadre d'un flux de messagerie électronique (courriel), et dans le cadre d'un flux de messagerie instantanée. Dans le mode de réalisation de la figure 4, un premier système informatique comporte une application de messagerie (courriels) 400 et un composant de sécurité 401. Un deuxième système informatique comporte une application de messagerie (courriels) 402 et un composant de sécurité 403. Les composants de sécurité 401 et 403 sont fonctionnellement identiques au composant de sécurité 15 décrit ci-dessus. L'application 400 génère un message 404 à transmettre à l'application 402. Le composant de sécurité 401 intercepte le message et examine dans une étape 405 l'adresse du destinataire du message. On suppose que, dans le mode de réalisation de la figure 4, il est fait usage de la méthode C d'obtention de clé cryptographique. Dans cet exemple, on suppose que le composant de sécurité 401 envoie une requête de demande 406 de clé publique de chiffrement vers le composant de sécurité 403 ou vers un service d'annuaire de clés. En réponse, le composant de sécurité 403 renvoie 407 un ensemble de clés publiques de chiffrement à utiliser pour sécuriser les messages dont il est le destinataire, une clé publique de chiffrement pouvant protéger une ou plusieurs adresses dudit destinataire. Ensuite, le composant 401 enregistre cet ensemble de clés dans une étape 408, en les associant au destinataire.

Afin de chiffrer le message lors de l'étape 410, le composant 401 tire aléatoirement une clé symétrique KC1 qu'il crypte avec la clé publique de chiffrement KPUB2 du destinataire associée à l'adresse de destination. Le message crypté 411 au moyen de la clé symétrique KC1 tirée est alors envoyé vers le destinataire, avec la clé symétrique KC1 cryptée par la clé publique de chiffrement KPUB2 du destinataire, pour décryptage et traitement par l'application 402.35 Dans le mode de réalisation de la figure 5, un premier système informatique comporte une application de messagerie instantanée 500 et un composant de sécurité 501. Un deuxième système informatique comporte une application de messagerie instantanée 502 et un composant de sécurité 503. Les composants de sécurité 501 et 503 sont fonctionnellement identiques au composant de sécurité 15 décrit ci-dessus. L'application 500 génère un appel 504 d'ouverture de session de messagerie avec l'application 502. Le composant de sécurité 501 intercepte l'appel et examine dans une étape 505 l'adresse du destinataire du message. Dans cet exemple, le composant de sécurité 501 transmet la requête en même temps qu'une requête d'ouverture de session de sécurisation 505 avec le composant 503. Le composant 503 transmet la requête d'ouverture de session à l'application 502 dans un message 506. En réponse, l'application 502 renvoie un message d'acceptation 507 de la session de messagerie avec le composant 500 vers le composant 503. Le composant 503 envoie alors vers le composant 501 un message 508 comportant le message 507 et une acceptation de la session de sécurisation. Le composant 501 transmet ensuite vers l'application 500 l'acceptation de la session de messagerie de l'application 502 dans le message 509. Le composant 501 exécute ensuite une phase de négociation pour l'obtention d'une clé de chiffrement selon la méthode C. Pour cela il propose par exemple une clé à utiliser pour chiffrer le message 510. En réponse, le composant 503 envoie un message d'acceptation de la clé proposée.

Alternativement il peut refuser la clé et en proposer une autre. On peut envisager d' autres mécanismes de négociation de la clé. Lorsqu'une clé a été négociée, le composant 501 notifie dans un message 512 à l'application 500 que l'échange de messages peut commencer. L'application transmet alors le message 513 qui est intercepté par le composant 501. Le composant 501 crypte alors le message lors de l'étape 514 avec la clé de chiffrement négociée puis transmet le message chiffré 515. Le composant 503 reçoit le message chiffré puis le décrypte lors de l'étape 516. Il transmet alors le message déchiffré 517 correspondant au message 513 initialement émis par 1"application 500. La session de messagerie continue ensuite son cours. Par exemple, l'application 502 transmet un message 518 qui est intercepté par le composant 503. Le composant 503 crypte alors le message lors de l'étape 519 avec la clé de chiffrement négociée puis transmet le message chiffré 520. Le composant 501 reçoit le message chiffré puis le décrypte lors de l'étape 521. Il transmet alors le message déchiffré 522 correspondant au message 518 initialement émis par 1"application 502.

La figure 6 illustre schématiquement un équipement selon un mode de réalisation de l'invention.

Cet équipement comporte une unité de traitement 60 pour mettre en oeuvre un procédé selon la présente invention. A cet effet il dispose d'une unité de mémoire 61. Cette unité de mémoire peut comporter différents types de mémoire. Par exemple l'unité de mémoire comporte une mémoire pour stocker des données de calcul. L'unité de mémoire peut également comporter une mémoire pour le stockage d'un programme d'ordinateur selon la présente invention pour son exécution par un processeur de l'unité de traitement. L'équipement peut en outre comporter des ports de communications 62 pour communiquer via un réseau de communication. Les ports de communication peuvent être gérés par une unité de communication 63. La présente invention a été décrite et illustrée dans la présente description détaillée et dans les figures. La présente invention ne se limite pas aux formes de réalisation présentées. D'autres variantes et modes de réalisation peuvent être déduits et mis en oeuvre par la personne du métier à la lecture de la présente description et des figures annexées. Dans les revendications, le terme "comporter" n'exclut pas d'autres éléments ou d'autres étapes. L' article indéfini « un » n' exclut pas le pluriel. Un seul processeur ou plusieurs autres unités peuvent être utilisées pour mettre en oeuvre l'invention. Les différentes caractéristiques présentées et/ou revendiquées peuvent être avantageusement combinées. Leur présence dans la description ou dans des revendications dépendantes différentes, n'excluent pas cette possibilité. Les signes de référence ne sauraient être compris comme limitant la portée de l'invention.

Claims (6)

1. REVENDICATIONS1. Procédé de sécurisation de flux de données émis par des applications de communication, mises en oeuvre par un système informatique et utilisant un ou plusieurs ports de communication, le procédé comportant les étapes : - d'interception (T21) d'un flux de données à émettre via l'un au moins desdits ports de communication, - de prise en compte d'une politique de sécurisation, commune auxdites applications, définissant quels sont les flux de données à sécuriser, en déterminant si le flux de données intercepté doit être sécurisé, et dans l'affirmative, - de sécurisation (S24) du flux de données intercepté par application d'une fonction de traitement audit flux de données, et - de transmission (S25) du flux de données sécurisé vers sa destination initiale.
2. 2. Procédé selon la revendication 1, dans lequel la politique de sécurisation définit quels sont les ports à surveiller, le procédé comportant en outre une étape de mise en place d'une surveillance pour intercepter un flux à émettre via un des ports de communication à surveiller.
3. 3. Procédé selon la revendication 1, dans lequel la politique de sécurisation identifie au moins une application à échanges sécurisés pour laquelle une sécurisation des flux de données issus de cette application est requise, le procédé comportant en outre une étape d'identification de l'application émettrice du flux de données intercepté.
4. 4. Procédé selon la revendication 2, dans lequel les ports surveillés sont des ports utilisés par des applications à échanges sécurisés.
5. 5. Procédé selon la revendication 1, dans lequel la politique de sécurisation définit si la fonction de 25 traitement à appliquer à un flux de données est une fonction de chiffrement et/ou de signature numérique.
6. 6. Procédé selon la revendication 1, dans lequel la politique de sécurisation identifie au moins un destinataire pour lequel est requise une sécurisation de tout ou partie des flux de données qui lui sont destinés, le procédé comportant en outre une étape d'identification (S22) d'un destinataire du flux de 30 données intercepté. 20. Procédé selon la revendication 6, comprenant - une étape d'interrogation d'un utilisateur émetteur du flux de données intercepté sur la fonction de traitement à appliquer, et - une étape de mise à jour de la politique de sécurisation des flux de données pour ce destinataire à partir de la réponse fournie par l'utilisateur émetteur. 8. Procédé selon la revendication 6, dans lequel la fonction de traitement appliquée est une fonction de chiffrement, le procédé comportant une étape d'obtention (S23) d'une clé de chiffrement, associée audit destinataire dans un profil d'utilisateur, à utiliser lors de l'application de ladite fonction de traitement au flux de données intercepté. 9. Procédé selon la revendication 1, dans lequel la fonction de traitement appliquée est une fonction de chiffrement, le procédé comprenant en outre les étapes : - d'obtention d'une première clé de chiffrement à utiliser lors de l'application de ladite fonction de traitement au flux de données intercepté; - de chiffrement de la première clé de chiffrement au moyen d'une deuxième clé de chiffrement; et - de transmission de la première clé de chiffrement chiffrée au destinataire. 10. Procédé selon la revendication 9, dans lequel le chiffrement de la clé de chiffrement se fait par chiffrement asymétrique, la deuxième clé de chiffrement étant une clé publique de chiffrement, affectée au destinataire du flux de données à sécuriser, obtenue auprès de l'une des entités de la liste suivante : - un annuaire de clés stocké auprès du système informatique, - un serveur de clés de chiffrement, ou - le destinataire du flux de données intercepté. 11. Procédé selon la revendication 9 ou 10, comportant en outre une étape d'authentification de la deuxième clé de chiffrement auprès d'une entité d'authentification distante du système informatique. 12. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé selon l'une 30 quelconque des revendications 1 à 1l, lorsqu'il est exécuté par un processeur. 13. Système informatique comportant : 1625- un ou plusieurs ports de communication (62) utilisés par des applications pour transmettre et recevoir des flux de données, - une unité (60) de sécurisation des flux de données émis par des applications de communication mises en oeuvre par le système informatique, configurée pour - intercepter (T21) un flux de données à émettre via l'un au moins desdits ports, - déterminer, par application d'une politique de sécurisation, commune auxdites applications, définissant quels sont les flux de données à sécuriser, si un flux de données intercepté doit être sécurisé, et - sécuriser un flux de données intercepté et transmettre ce flux de données sécurisé vers sa destination initiale.