FR2837047A1 - Message electronique avec avis de reception et suivi(mars) - Google Patents

Abstract

La présente invention concerne un procédé d'envoi de mèl à au moins un destinataire spécifique, comportant une étape de création d'une enveloppe numérique comportant au moins un élément d'identification de l'expéditeur, le contenu du mèl et les éléments permettant l'acheminement du mèl au destinataire spécifique, une étape de transmission par un réseau numérique de ladite enveloppe numérique à une plate-forme comportant un serveur centralisateur, ladite plate-forme effectuant la création d'un mèl comportant les informations liées au destinataire dudit mèl et le contenu électronique, et la transmission du mèl par l'intermédiaire d'un fournisseur d'accès Internet, caractérisé en ce qu'il comporte en outre une étape de mémorisation des éléments contenus dans l'enveloppe numérique et des informations concernant le destinataire du courrier. L'innovation technique décrite permet à un expéditeur privé ou industriel de flux de courrier postal de répondre complètement à la remise dudit courrier sous une forme alternative mais pertinente lors d'une période de déni de remise de l'opérateur postal national.

Description

<Desc/Clms Page number 1>

MESSAGE ELECTRONIQUE AVEC AVIS DE RECEPTION ET SUIVI (MARS).

La présente invention concerne le domaine des envois et des réceptions de mèls à remise sécurisée. Il est de tradition depuis 1969 d'utiliser le protocole IPv4 ( Internet Protocol version 4) afin de transmettre d'une console informatique à une autre console un flux d'information sous forme électronique.

Un mèl consiste en un message simple codé en ASCII-256 et couplé avec un ou plusieurs éventuels fichiers attachés codés en MIME. Le serveur d'expédition des mèls est un serveur SMTP. Chaque utilisateur est identifié par une adresse mèl unique défini par un identifiant utilisateur, un nom de domaine et un suffixe : c'est une adresse non équivoque qualifiant un utilisateur spécifique sur un domaine déterminé par ses huit lettres et son extension.

L'usage courant veut que toutes les opérations soient facilement identifiables à vue. Il demeure toujours un risque de non-acheminement d'un mèl. Un automate est en charge de transmettre les problèmes de délivrance d'un mèl aussi bien à cause des problèmes de délais de remise que des défauts des serveurs SMTP s'échangeant les informations.

Pour l'envoi de documents officiels ou nécessitant un traitement particulier, on utilise des produits complémentaires permettant d'assurer l'authentification des parties, le séquestre du mèl transitant, le respect des paramètres d'envoi du routeur expéditeur et le cryptage du flux de données électroniques composant le corps du mèl. Parfois, les outils progiciels mis en oeuvre pour garantir l'absolu sécurité de chacune des étapes du processus de transmission impose la présence d'un technicien maîtrisant la gestion des PKI (gestionnaire de clefs), des garde-barrières ou même des moyens durs

<Desc/Clms Page number 2>

d'intentification biométriques des parties (iridologie, reconnaissance des traits du visage ou empreintes palmaires).

Le système de courrier recommandé postal classique permet de s'assurer qu'un courrier sera effectivement acheminé de la meilleure façon possible. Il permet d'obtenir une preuve de la bonne réception par le destinataire de l'enveloppe contenant les documents. Afin de s'assurer que le courrier sera remis à son destinataire réel, on utilise l'artifact d'un avis de réception. Cet avis de réception est signé par le destinataire puis est remis à l'expéditeur. Dans tous les cas, la remise de l'enveloppe et non de son contenu est certifiée par ces systèmes. Dans le cas où l'enveloppe serait vidée, intentionnellement ou non, il n'est pas possible de retrouver le document tel qu'il a été envoyé sans posséder soi-même une procédure d'archivage des envois (c'est-à-dire de conservation pérenne de l'envoi avec la garantie de lisibilité dans le temps de l'envoi s'il a été soumis sous forme numérique). Une assurance est généralement proposée par le transporteur pour rembourser de façon forfaitaire les éventuelles spoliations.

Dans le cas du mèl, l'aspect dématérialisé du flux d'information numérique impose une relation forte entre le corps du texte et l'enveloppe numérique de support de l'envoi. Quel que soit le protocole utilisé pour l'envoi des données (routeur SMTP, par exemple), il est à noter que le support de l'enveloppe tout comme le contenu formel du message sont tous deux numériques. Le mode même de routage des mèls impose un transport par paquets, chacun utilisant un chemin inter-routeurs différent.

Les brevets PCTOO/33203 et US5850520 présentent un système et une méthode de confirmation et de vérification de la délivrance d'une communication numérique. Le mèl ou chacune de ses pièces jointes est

<Desc/Clms Page number 3>

stocké sur une adresse URL unique transmise au destinataire par un premier mèl d'information. Après un double-clic de la souris sur ce lien hypertexte unique, le destinataire pourra télécharger le contenu du fichier original sur sa station. Le lien hypertexte pourra se faire sur une URL dont la validité peut être temporaire avec un retrait automatique des mèls non sollicités (WOOO/17768).

L'originalité de cette application baptisée boomerang tient à ce que l'expéditeur est instantanément notifié de la remise de son envoi par un second mèl d'information. Toutes ses transactions sont stockées sur un serveur dédié à leur consultation. A noter que le document consulté peut soit être créé à la volée (seules les données de fusion avec le formulaire-type seront archivées), soit être stocké à l'identique de façon fixe (format 1/1 PAL/pixel).

Avantageusement, le serveur SMTP boomerang aura informé par un échange de mèls les parties de leur droits et devoirs réciproques (tel que décrit dans le brevet US5903723). Il n'est en aucun cas responsable des éventuelles altérations de forme ou de fonds (lisibilité d'un contenu crypté par un procédé propriétaire à l'une des parties) qu'il est possible d'avoir soit avec les outils de messagerie servant d'interface, soit avec ceux de visualisation. Ce procédé très verbeux impossible plus de cinq états transitoires, source inévitable d'erreurs.

Le brevet US5022080 propose une solution de notarisation d'un document électronique qui évite qu'un document puisse être modifié en dehors de sa date d'enregistrement validé en heure GMT. Aucune variante n'est indiquée quant à un mèl transitant sur un réseau local (LAN) ou étendu (WAN ou extranet d'entreprise), ou lorsque le document confonds aussi parfaitement le corps du mèl, ses inserts et son enveloppe de transport.

<Desc/Clms Page number 4>

De plus, le seul côté retenu de l'invention décrite dans le brevet US5936149 est l'horodatage fortement précis de chacune des étapes de la vie du mèl : initialisation de l'enveloppe, complétude du champs texte et accroche des pièces jointes avec leur spécificités propres, demande de routage du premier routeur SMTP, notation des éventuels renvois sur indisponibilité dudit routeur, notation d'un éventuel retour en non-remise (NPAI).

Le brevet EP01/107203 permet de remédier au défaut d'authentification du destinaire d'un mèl donné. L'expéditeur encapsule son envoi dans une double-enveloppe numérique qui ne pourra être ouverte par son destinataire après téléchargement sur une URL désignée qu'après l'avoir décryptée grâce à une demi-clef à validité temporelle de trois minutes reçue sur le téléphone portable de ce dernier (numéro de poste GSM obligatoirement connu de l'originateur du mèl). Les lourdeurs de la procédure d'émission du mèl et de celle de sa réception sont telles que l'usage de cette invention n'est pas imaginable industriellement.

Enfin, notre brevet FR2801390 décrit le fonctionnement d'une plate-forme de courrier hybride acceptant des flux numériques en entrée qui seront ensuite transformés après horodatage et séquestre successifs des différentes transformations en des documents autres que numériques (lettre simple, lettre recommandée, télécopie, télégramme, SMS, messages sonores encapsulé MP3, etc. ). Si le flux d'entrée de cette plate-forme peut être un mèl, il est à noter qu'il n'est pas prévu que le flux de sortie sera également un mèl (obligation de transformation imposée par une fonctionnalité hybride).

CARACTERISE EN CE QUE l'invention décrite dans ce document a pour but de pallier ces inconvénients en proposant un système peu

<Desc/Clms Page number 5>

coûteux permettant de mémoriser, et de certifier le contenant et le contenu des mèls. Elle permet également d'envoyer des messages rapidement et à toute heure en libérant l'expéditeur de l'ingrate et fastidieuse impression d'une copie archive du document transmis ou le doublement de l'envoi du mèl par une lettre recommandée papier avec demande d'avis de réception.

L'innovation technique décrite permet à un expéditeur privé ou industriel de flux de courrier postal de répondre complètement à la remise dudit courrier sous une forme alternative mais pertinente lors d'une période de déni de remise de l'opérateur postal national (grève, conditions atmosphériques désastreuses, éloignement trop important de l'expéditeur vis-à-vis du destinataire, etc. ).

Ce nouveau service de messagerie à valeur ajoutée permettra de mieux gérer les échanges entre boîtes aux lettres et facilitera l'organisation de la distribution de l'information. Ce service sera mis en ligne sur Internet. Avec MARS, il s'agira d'offrir, au-delà de la messagerie de base, un service à valeur ajoutée comme le font les opérateurs postaux
L'invention concerne un procédé d'envoi de mèl à au moins un destinataire spécifique, comportant une étape de création d'une enveloppe numérique comportant au moins un élément d'identification de l'expéditeur (son adresse électronique), le contenu du courrier (texte simple et/ou fichiers attachés) et les éléments descriptifs du contenant permettant l'acheminement du courrier au destinataire spécifique (nommé par son adresse électronique), une étape de transmission par un réseau numérique sécurisé (RSA, SSL v3 ou au-delà, par exemple) de ladite enveloppe numérique à une plate-forme comportant un serveur centralisateur. La plate-forme centrale effectue dès réception du mèl un ensemble d'actions permettant de ne pas rompre la chaîne de

<Desc/Clms Page number 6>

sécurisation entamée et de garantir ainsi l'intégrité, l'intégralité et la non-répudiation du mèl.

Ce procédé est caractérisé en ce qu'il comporte en outre une étape de mémorisation des éléments contenus dans l'enveloppe numérique et des informations concernant le destinataire du courrier, ladite mémorisation étant systématiquement effectuée immédiatement après réception de l'enveloppe numérique du mèl, et, lorsque l'enveloppe numérique comporte une séquence d'instructions de conservation, pendant une seconde durée d'archivage au moins dix fois supérieure à période de réémission des mèls sur incidents par le MX (gestionnaire d'envois des mèls), le procédé comportant en outre une étape accessoire de délivrance d'un certificat de vie comportant un identifiant numérique ainsi que les informations archivées relatives à un courrier spécifique, cette étape étant activée par une requête émise par l'expéditeur de ladite enveloppe numérique. Dans le cas d'un premier envoi, l'expéditeur créé alors un profil par défaut des paramètres généraux de ses futures enveloppes numériques.

Avantageusement, on mémorise en outre les informations concernant la remise du mèl au destinataire spécifique, allant de son environnement technique au type d'outils de messagerie avec avis de réception (MARS) utilisé, de la vitesse de sa liaison Internet au mode de correction d'erreurs du progiciel de cryptage utilisé.

Dans une variante préférée, les informations de remise du mèl comprennent une identification certaine du récepteur du MARS. Il est systématiquement demandé une marque-signature non répudiable juridiquement au destinataire.

A cette fin de non répudiabilité des contenus, nous déférencierons l'intégralité et l'intégrité d'un mèl : - INTEGRALITE

<Desc/Clms Page number 7>

Madame Michu appartient à un lot de cent clientes qui doivent recevoir un mèl. L'intégralité, c'est le fait de s'assurer que le lot de cent clientes sorti de la plateforme informatique avant le routeur est bien parti dans son entièreté ; - INTEGRITE Madame Michu est une cliente qui doit recevoir un message par MARS. S'assurer que Madame Michu a bien reçu le MARS souhaité avec les éléments demandés en pièces jointes et partis sur le routeur avec la bonne adresse électronique.

En supplément, lorsque l'on souhaite traiter intégrité et intégralité, le plus complexe est de traiter les reprises en cas de détection de non-intégrité et de non-intégralité.

La mémorisation du contenu de l'enveloppe numérique utilise préférentiellement des moyens de certification de date et de contenu. On peut également créer un journal des actions effectuées à partir de la réception de l'enveloppe numérique auquel on donne accès directement depuis la messagerie de l'expéditeur du mèl.

Avantageusement, le serveur centralisateur envoie une notification de réception de l'enveloppe numérique à l'expéditeur de ladite enveloppe. Cette notification peut comprendre la liste des éléments reçus et inviter à compléter l'enveloppe numérique s'il manque des éléments nécessaires à l'envoi du MARS ou si l'enveloppe s'avérait être corrompue ou virusée.

Dans une variante, l'expéditeur utilise un moyen d'identification certain pour l'envoi de l'enveloppe numérique.

L'invention concerne également l'interface pour la mise en oeuvre du procédé d'envoi de MARS.

Pour répondre aux besoins de sécurité, il est nécessaire de modifier un grand nombre d'infrastructures, en particulier les environnements logiciels des

<Desc/Clms Page number 8>

utilisateurs. Il semble bon d'utiliser les compétences de plusieurs éditeurs de logiciels de messageries.

L'invention présentée ici repose sur une infrastructure distribuée entre les postes utilisateurs, le serveur de collection d'évènements et le service de suivi. Ceci nous impose donc une nécessité d'usage de protocoles ouverts.

Afin de répondre le plus efficacement possible à la demande de sécurité des entreprises, il est nécessaire de définir un protocole d'événements d'envoi et de réception de message et d'avis de réception basé sur des standards actuellement proposés et de convaincre des constructeurs de messageries d'implémenter des interfaces sur le poste client. Dans une première période, il est possible de choisir des développements basés sur la plateforme Microsoft Outlook, mais ce choix n'est aucune exclusif.

Les services postaux qui sont associés au concept d'accusé de réception comprennent plusieurs caractéristiques dont deux principales qui sont usuellement demandées.

La première caractéristique est que l'émetteur des messages est informé de la bonne réception d'un message. Contrairement aux services postaux, l'implémentation de cette caractéristique dans une messagerie électronique ne nécessite pas de contrainte ni au destinataire ni à l'acheminement du message. Autrement dit, c'est un service à valeur ajouté au fonctionnement normal de la messagerie.

La deuxième caractéristique est la traçabilité des courriers dans le but de réaliser des statistiques de suivi. Nous utiliserons le concept d'événement comme unité de base de notre approche. L'envoi d'un message

<Desc/Clms Page number 9>

électronique peut se résumer en une simple formule : c'est 1 + 2n-événements [n étant le nombre des destinataires].

La solution proposée doit respecter des standards internationalement reconnus et ouvertement publiés afin de garantir une plus large possibilité d'interopérabilité entre communautés différentes. Le respect des standards doit permettre une évolution de la ou des solutions.

Il est souhaitable que certains éléments de la solution, par exemple la gestion des participants d'une communauté puissent être utilisée pour d'autres contextes applicatifs (accès à des bases de données, services administratifs, etc.).

Il apparaît que l'agrégation de toutes les données syslog n'est pas suffisante.

De plus, il est prouvé que l'utilisateur final n'est pas intéressé par le chemin toujours différent que prend un mèl pour aller d'un poste informatique à un autre.

Nous supposons que cette constatation peut être appliquée à notre conception de MARS. L'expéditeur ne demandera qu'exceptionnellement le résumé quotidien de l'ensemble de ses envois de MARS.

Pareillement, une demande relative à la fourniture de tous les messages perdus reste sans intérêt.

Dans le cas de MARS, les traces laissées sont nombreuses et au moins égales à trois : (1) celle générée par l'expéditeur à la création du MARS ; (2) celle générée par le destinataire lors de la fabrication de l'AR ; (3) celle générée par la réception de l'AR qui termine ainsi la transaction.

Le risque de perte d'événements ou même de faux évènements est acceptable : cela ne ferait que perturber le système de suivi sans influence sur la messagerie.

Même si le réseau tombe en panne, l'avis de réception est disponible et accroché au MARS qui l'a

<Desc/Clms Page number 10>

généré. Les traces laissées par le routage d'un MARS sont aussi bien dans le message que dans le système de suivi.

Lors d'une demande de validation d'un évènement par un membre habilité, le serveur central est en mesure de valider simplement la requête relative à un évènement avec un chiffrement fort (autorisé par la DCSSI).

Vu l'importance du marché des mèls transmis quotidiennement et vue la complexité potentielle de l'infrastructure à mettre en place, il est indispensable d'utiliser des techniques normalisées et ouvertes afin de répondre aux besoins d'évolution et d'adaptation.

Le service MARS doit être nécessairement ouvert à tous les fournisseurs de technologie et de services et doit permettre une ouverture vers d'autres communautés extérieures, par exemple, d'autres administrations.

La solution s'appuie sur n'importe quelle messagerie existante qui utilise les protocoles SMTP et PoP3/IMAP, i. e. des protocoles standards de la messagerie de l'Internet. Pour le format des messageries sont utilisés les formats MIME et S/MIME.

Dans le contexte S/MIME, le RFC 2634 ESS (extended security services) défini un format d'avis de réception sécurisé. Ce RFC a été créé pour supporter plusieurs besoins des administrations ou autres services publics ou militaires. Il est proposé d'utiliser cette technique pour répondre aux besoins d'avis de réception.

Nous soulignions qu'actuellement le NIST est en train de préciser un profil d'utilisation S/MIME pour les services de l'administration américaine. Ce profil s'appuie aussi sur l'ESS. Le besoin de traçabilité et d'archivage est adressé avec le protocole DVCS qui est une généralisation d'un service d'horodatage et permet également une interface standardisée vers un service d'archivage.

<Desc/Clms Page number 11>

Le système de génération de statistiques s'appuie sur l'utilisation d'un format d'événement standardisé et publié permettant ainsi l'utilisation des produits du marché.

La solution proposée comporte un poste client et un service d'enregistrement d'évènements. Chaque entité participant à un groupe privé d'utilisateurs possède un réseau local de haute qualité en matière de disponibilité et pour chaque réseau un ou plusieurs serveur (s) d'enregistrement d'évènements (environ 50K messages/jour /serveur).

La collecte des évènements vers le serveur centralisé à des fins de statistiques et de suivi peut se faire avec anonymation possible de l'identité des utilisateurs qu'ils soient ou non membres d'un groupe d'utilisateurs privés donné. Elle ne nécessite qu'une disponibilité moyenne des machines. Elle permet de réaliser soit à la demande soit à date fixe un certain nombre de statistiques automatisées.

En matière d'architecture fonctionnelle, la solution comprend les éléments suivants : - une interface utilisateur intégrée avec la messagerie permettant la création, réception et gestion des messages sécurisés ; - un service d'horodatage avancé permettant de gérer des traces d'évènements (création, réception) afin de constituer la base des événements pour le suivi et la génération des statistiques ; - un service de back-office de génération de statistiques et de suivi ; - en option, un service d'archivage accessible d'une façon similaire que le service d'horodatage par l'interface utilisateur. Ce service comprend une interface vers n'importe lequel service de conservation de données ;

<Desc/Clms Page number 12>

- une infrastructure pour générer des moyens d'identification pour la communauté (i. e. fichier de description des empreintes palmaires, clés d'authentification).

Afin de mieux comprendre la solution, nous l'illustrons avec un cycle de vie d'un message : - L'utilisateur compose un message avec des destinataires soit de la même communauté, soit d'autres ; - L'interface utilisateur permet de distinguer les membres de la communauté cible permettant ainsi un affichage différent de l'état d'acheminement du message. En particulier pour les membres de la communauté cible, un message est initialement marqué Non reçu ; - Avant l'envoi du message, l'événement de l'envoi est horodaté par DVCS. Ainsi le service de suivi prend compte de la transaction ; - Ensuite, le message est envoyé normalement avec la messagerie standard SMTP vers le (s) destinataire (s) ; - A la réception du message, le (s) destinataire (s) sont informés de la demande de génération d'un avis de réception et peuvent initier sa génération.

Cela inclus des options de refus ou d'acceptation. Il est essentiel que cette activité soit entièrement contrôlée par le destinataire ; - Un autre événement d'horodatage est généré ;
L'avis de réception est ensuite envoyé à l'émetteur du message initial ; - La réception de l'AR modifie automatiquement l'état du message envoyé ( refusé , accepté , etc. ) ; - Un autre événement d'horodatage est généré pour clore l'activité.

<Desc/Clms Page number 13>

L'architecture du logiciel client comporte l'implémentation en forme plug-in pour des messageries standards. Le paramétrage utilise des certificats X. 509.

Chaque utilisateur est associé au service réalisé par un Trousseau individuel d'accès MARS. Si le gestionnaire du réseau le désire, il est possible d'associer une PKI (gestionnaire de clefs publiques) à l'ensemble des utilisateurs par l'entremise d'un serveur d'annuaire LDAP.

En option favorite, il est également possible d'intégrer d'autres produits au choix de l'administration, y compris des produits déjà existant et/ou adaptés aux besoins de MARS.

Quant à l'infrastructure de gestion des utilisateurs, la participation des utilisateurs de MARS nécessite un moyen d'authentification auprès de service de suivi et pour l'authenticité des avis de réception. Ce moyen d'accès est appelé Trousseau d'Accès M. A. R. S (TAMARS).

Le TAMARS est fourni à chaque utilisateur, techniquement il s'agit d'une bi-clé RSA avec certificats X. 509, permettant l'authentification de l'utilisateur et d'un certificat de confiance permettant l'authentification des serveurs de suivi et d'archivage. Le TAMARS est fourni aux utilisateurs en format PKCS12, le format standard defacto d'échange de certificats et secrets, protégé par un code confidentiel personnel.

La création de TAMARS nécessite une infrastructure avec quelques éléments qui sont normalement trouvés dans une infrastructure de gestion de clé (IGC ou ICP), notamment la génération de clés et de certificats et leur distribution.

Nous remarquons que la gestion des utilisateurs, en particulier l'enregistrement, des participants MARS existe en dehors de notre invention. Il s'agit essentiellement de l'enregistrement dans l'annuaire.

<Desc/Clms Page number 14>

Les besoins fonctionnels pour l'infrastructure de génération de TAMARS sont donc principalement d'une nature technique et pas organisationnelle. Pour la solution MARS, n'importe quelle solution de fourniture de certificats par un opérateur spécialisé peut être utilisée.

Nous remarquons également que la partie ICP et l'utilisation des techniques S/MIME semble indiquer une protection des messages S/MIME par signature ou chiffrement, cela n'est pas l'objectif de l'invention proposée. La solution reste néanmoins totalement ouverte et compatible avec une telle évolution.

Dans le contexte de l'invention, il s'agit seulement de gérer la participation à une communauté privée d'abonnés d'une façon standardisée et évolutive, donc de répondre à quelques besoins de sécurité concernant l'accès au service de traçage et de conservation des données.

Architecture service d'horodatage avancé
Il s'agit d'un service implémentant le protocole ccpd (certify claim of possession of data) accessible par HTTPS. Le logiciel client possède le certificat du service permettant ainsi l'authentification du service.

Afin de répondre aux besoins d'une grande communauté, le service peut être réalisé d'une façon distribué avec plusieurs serveurs HTTPS placés dans les endroits critiques de l'infrastructure réseau.

Le service horodatage génère une base d'événements en utilisant des techniques et des formats standardisés et publiés. Les évènements vont être exploités par le service de suivi.

Ce service est réalisé par une version adaptée d'un logiciel ayant une autorisation DCSSI, sur des machines PC/Linux+Apache, par exemple. Le service peut coexister sur la même plate-forme que le service d'archivage.

<Desc/Clms Page number 15>

Un serveur est nécessaire par communauté privée d'utilisateurs.

Architecture service d'archivage
Il s'agit d'un service implémentant le protocole cpd (certify possession of data) accessible par HTTPS de la même façon que le service d'horodatage.

Ce service peut aussi être implémenté d'une façon distribuée en fonction du développement des charges et ceci en toute transparence vis-à-vis des clients. Ce service peut s'interfacer avec un service de conservation et distribution de données.

Ce service peut co-exister sur la même plateforme que le service d'horodatage. Nous proposons un serveur par communauté privée d'abonnés.

Les besoins en serveurs d'archivage sont à mutualiser avec les serveurs de production de statistiques.

Si le choix de l'hébergement est à la charge de la plate-forme MARS, il est nécessaire que l'ensemble des évènements arrive dans une salle blanche. De plus, une connexion Internet proche des machines permettant un tunnel VPN pour la collecte des évènements reste nécessaire ainsi qu'une connexion Internet externe de la salle blanche vers le centre de supervision.

Si l'hébergement est externalisé, il est optimal d'utiliser des serveurs d'un tiers partie de confiance. Dans ce cas, l'administration des données sera réalisée localement tout comme l'archivage (respectant la norme AFNOR NF Z42-013).

Service de suivi
Il s'agit d'un service de back-office d'analyses d'événements dans un format standardisé et publié afin de générer des statistiques et des informations concernant la facturation, etc. Cette technique permet

<Desc/Clms Page number 16>

l'utilisation de produit du marché qui sera proposé dans le contexte MARS.

Semblable aux interfaces homme-machine de gestion des documents séquestrés, l'interface MARS permettra de faire tous types de statistiques à des fins de facturation inter-services ou de contrôle de l'efficacité des formations.

Un simple PC peut stocker jusqu'à 50K évènements par jour. Une configuration simple répondant aux besoins d'une centaine d'utilisateurs nécessite sept (7) postes afin de garantir le travail de suivi : 2 serveurs de collecte d'évènements, 2 serveurs de production de statistiques et 2 serveurs d'archivage, ainsi qu'un poste d'administrateur local (machine en stand-by). La raison du doublement des serveurs s'explique par la nécessité d'avoir des ressources CPU toujours disponibles.

Chaque MARS génère (1 + 2n) évènements [n étant le nombre de destinataires demandés par l'expéditeur sur Internet]. Chaque évènement est un élément unique donnant un état d'un mèl sous forme non signée. Il est possible d'enregistrer dans un premier temps le chrono des évènements par serveurs SMTP dans le cas d'un groupe privé d'utilisateurs sur un LAN donné.

Le serveur de collecte des évènements est à même de faire des tris en fonction de nombreux critères par une interface conviviale donnant toutes les possibilités d'analyse (par nom de domaine, par poids des messages, par type de cryptages...).

Les formulaires les plus utiles seront définis prioritairement afin qu'il soit rapidement possible de les appeler par un administrateur et/ou de les transmettre à un service d'audit qualité.

L'invention sera mieux comprise par la description détaillée du procédé selon l'invention.

<Desc/Clms Page number 17>

Un expéditeur cherche à créer un MARS sécurisé à partir de son terminal. S'il possède un navigateur adapté au réseau Internet, il se connecte à un serveur Web sur lequel il remplit alors un formulaire d'identification comportant quelques questions nécessaires à la création de son trousseau individuel d'accès (TIA). Son mot de passe lui est transmis pour confirmation quelques secondes après par mèl ou par tout autre moyen. Il précise alors les paramètres secondaires de sa demande de transmission : confidentiel, remise différée dans le temps...

Ces paramètres consistent en le type d'envoi désiré, en les coordonnées du (ou des) destinataire et en les options concernant l'archivage. L'adresse est une adresse unique ou un ensemble d'adresses réunies pour un envoi groupé. Il est également possible de définir un ensemble d'adresses personnalisé qui est mémorisé sur la base de données. L'expéditeur n'aura alors plus qu'à faire référence à ces adresses mémorisées, ce qui présente un gain de rapidité lorsqu'il s'agit d'effectuer des envois groupés.

Dans une variante préférée, l'expéditeur se trouve sur le réseau LAN ou extranet de son entreprise.

Lorsqu'il désire procéder à l'envoi d'un MARS sécurisé, il clique sur l'icône spécifique dans la barre des outils de son traitement de texte habituel. Une fenêtre de dialogue s'ouvre alors et propose à l'expéditeur de saisir les caractéristiques de sa requête : adresse du destinataire et la valeur des paramètres de son profil utilisateur (défini par son responsable réseau à l'ouverture de son compte) qu'il souhaite modifier spécialement pour cette requête. La fermeture de la fenêtre de dialogue génère une enveloppe numérique transmise immédiatement au routeur de l'entreprise qui s'occupe de l'envoi au serveur centralisateur.

<Desc/Clms Page number 18>

Les documents reçus par le serveur centralisateur sont mémorisés dans une base de données spécifique pendant une durée minimale définie par le prestataire de service. Cette durée est d'au moins un jour.

Dans le cas où l'expéditeur l'aurait demandé dans les paramètres d'envoi, il est possible d'archiver les informations concernant l'envoi pendant une durée au moins dix fois supérieure à la durée minimale. Cette option d'archivage permet de conserver les traces de tous les MARS durablement. Avantageusement pour le prestataire de service, la première durée minimale est gratuite, alors que l'extension de durée est payante. Il est également possible pour l'expéditeur de définir un prix d'extension à partir duquel le serveur centralisateur calcule la durée d'archivage supplémentaire à laquelle il a droit.

Eventuellement, les données concernant les adresses d'expédition et du destinataire, ainsi que l'enveloppe numérique, peuvent avoir une durée de vie limitée. Il est alors possible de réaliser des statistiques sur tous les éléments des MARS transmis.

Le serveur est en fait hébergé chez un huissier de justice au sein de son étude. L'huissier procède au séquestre de l'enveloppe numérique et à la création d'un identifiant numérique unique clef principale d'entrée du certificat de vie. Il est le gardien de la confidentialité des informations contenues dans le futur MARS. Il est à même de procéder à la création d'une ampliation, c'est-àdire de la copie certifiée conforme du MARS conservé.

Dans le cas où le document n'aurait pas pu être délivré (pour un problème de format par exemple ou de délai de validité dépassé), un message est envoyé par la plateforme à l'expéditeur du MARS directement sur son gestionnaire de messagerie.

Dès retour de l'avis de réception du MARS par la plate-forme, un second message peut informer

<Desc/Clms Page number 19>

l'utilisateur (s'il le désire) de la disponibilité de ce document et des paramètres de durée d'archivage de la version numérique du document original chez l'huissier de justice.

Dans le cas d'un retour d'un MARS (NPAIn'habite pas à l'adresse indiquée) ou d'une signalisation d'erreur par le routeur ou le fournisseur d'accès au réseau Internet (spoliation, destruction, par exemple), une indication est tout de suite portée sur le certificat de vie. Dans la variante ou l'avis de réception ne serait pas arrivé, la plate-forme d'envoi mettra tout en oeuvre pour informer le poste informatique de l'expéditeur d'un incident et d'y trouver une réponse efficace et satisfaisante pour l'expéditeur. La plate-forme agit en toute transparence en lieu et nom de l'expéditeur.

Lors de la première utilisation du service, l'expéditeur envoie un mèl vide à une adresse prédéfinie et reçoit un fichier informatif lui expliquant le processus à suivre afin de s'inscrire et de transmettre simplement un document par un second message à la plate-forme. Il lui sera alors proposé de faire un compte de dépôt afin de lui éviter de décliner ses références bancaires systématiquement. Toutes les informations concernant les transactions effectuées et l'archivage peuvent être mémorisées dans une base de données, éventuellement intégrée au serveur centralisateur.

Si l'utilisateur se trouve sur un réseau local au sein d'une structure, il lui sera facile de cliquer sur une icône de son traitement de texte afin de réaliser automatiquement la création de l'enveloppe numérique du MARS en question.

Dans le cadre d'entreprise où le nombre de MARS est important, la plate-forme est en mesure d'archiver ces documents entrants sur plusieurs années en fonction des besoins de l'entreprise.

<Desc/Clms Page number 20>

Les différents acteurs entrant en jeu dans des envois de MARS sont explicités ci-dessous.

Le salarié connecté à un réseau LAN clique sur une icône sur son terminal habituel. Apparaît alors une fenêtre de dialogue lui demandant les coordonnées de son destinataire et les éventuels paramètres de son profil utilisateur qu'il souhaite modifier. Une fois les données rentrées, une icône de validation lui permet de transformer sa requête en une enveloppe numérique transmise immédiatement à la plate-forme. En fonction de sa hiérarchie au sein de l'entreprise, il lui est possible de se connecter sur le site Web et de suivre en direct ses MARS. L'administrateur système de son entreprise lui aura donné un identifiant et un mot de passe dans ce sens.

L'internaute se connecte sur un site d'envoi de MARS par l'entremise de son navigateur habituel. S'il est nouveau, il devra compléter un rapide formulaire donnant ses coordonnées, ses préférences d'envoi, son numéro de carte bancaire, son mèl et ses priorités d'envoi (confidentiel, remise tardive, cryptage PGP, etc. ) La page HTML sécurisée sera transmise à la plate-forme pour validation (création d'un certificat utilisateur, création d'un compte par l'attribution d'un identifiant et d'un mot de passe).

Il n'aura plus qu'à passer une requête d'envoi d'un MARS pour initier son compte. Pour suivre son MARS à la trace, il lui suffira de se connecter sur son compte sur le site Web ou alors de faire une simple demande par mèl en donnant le code identifiant de son MARS comme clef. Quelques secondes après, il pourra avoir le tracking complet de son document.

L'huissier de justice possède un terminal de consultation de l'ensemble des documents (enveloppes numériques MARS et certificats de vie) qui sont sur le

<Desc/Clms Page number 21>

serveur centralisateur depuis l'ouverture du service.

Toutes les fois qu'un MARS arrive, il en fait un séquestre, attribue un identifiant unique et vérifie l'intégrité des informations consignées. Sur requête de l'expéditeur ou d'une Cour de justice, il est à même d'établir un procèsverbal relatif à un certificat de vie et/ou un MARS donné.

Il est seul habilité à ouvrir une enveloppe électronique émise par un expéditeur donné.

Le technicien logisticien voit arriver les enveloppes numériques de requête. Il est en charge du bon état de lisibilité de chaque MARS. En cas de problème informatique, il applique strictement les consignes de travail qui lui sont imposées. Chacun de ses gestes est pris en compte pour l'écriture d'une ligne dans le certificat de vie du MARS considéré (début de l'envoi par le routeur initial, fermeture du contenant, etc.).

Le responsable du centre d'appels ou des alertes reçoit tous les matins plusieurs centaines de messages d'alerte lui donnant l'état des éventuelles erreurs de routage, fausses directions, NPAI. Il a la charge de vérifier qu'elles ont bien été traitées et d'amender le certificat de vie du mèl correspondant. En cas où l'avis de réception ne serait pas arrivé selon un délai raisonnable (généralement de cinq heures), il a le devoir d'émettre une alerte qui sera incluse dans le certificat de vie. Outre cette tâche de complétude du certificat de vie, il répond aux réclamations téléphoniques techniques des clients et/ou prospects.

Le destinataire reçoit par l'entremise de son navigateur Internet habituel son mèl avec la demande d'avis de réception. Il accepte ou non de recevoir sa missive et émet éventuellement les restrictions liées à l'authentification visuelle de l'enveloppe électronique. Il lui est possible de refuser son MARS qui reviendra ainsi à l'expéditeur. Il est en mesure de joindre le service client

<Desc/Clms Page number 22>

pour répondre à toutes les questions ou interrogations qu'il pourrait avoir.

Le responsable Internet/réseaux a la charge d'expliquer le concept de MARS à remise sécurisé aux responsables informatiques et télécommunications des entreprises dont il a la charge. Dans le cas d'un grand compte, il est en mesure de porter un regard sur les problèmes de garde-barrières. De plus, il est en charge de la gestion des incidents de la plate-forme, de l'évolution des formats des fichiers ainsi que des évolutions produits.

Le code de stockage des mèls est alphanumérique et comporte 13 caractères. Les deux premiers sont RE (R comme Recommandé et E comme Email). Les caractères 3 à 10 sont numériques. Il ne doit pas y avoir deux numéros identiques dans une même journée pour un couple expéditeurdestinataire donné. Le caractère 11 représente le caractère de contrôle du numéro-Modulus 11 pondéré du facteur 86423597, la lle position de la clef étant le chiffre. Les caractères 12 et 13 sont toujours le code ISO du pays de l'expéditeur sur deux caractères (FR pour France).

La présentation ne doit pas comporter d'espace vide. Un exemple : RE102823740FR.

Le caractère de contrôle en position 11 a essentiellement deux raisons d'être. Son principal objet est de permettre à l'ordinateur de déceler toute erreur humaine qui peut avoir été commis dans le cas où le code a été saisi manuellement. En outre, il permet de vérifier que le code exploré électroniquement est lu correctement. Il fait partie du numéro. Il est tiré d'une partie des autres caractères de ce numéro et il est calculé d'après une formule mathématique entre le caractère de contrôle et les autres caractères, si un ordinateur lit mal un caractère l'erreur apparaît.

<Desc/Clms Page number 23>

La formule de calcul utilisée est désignée sous le nom de Modulus 11 R5R pondéré, car elle implique l'application de facteurs de pondération aux caractères initiaux, l'addition de leurs valeurs, la division de cette somme par 11, et la soustraction du reste de 11.

La formule est la suivante : appliquer les facteurs de pondération aux chiffres de base en utilisant le facteur 86423597, faire la somme des nombres obtenus, diviser cette somme par onze, si le reste est égal à zéro, utiliser cinq comme chiffre de contrôle, si le reste est égal à un, utiliser zéro comme chiffre de contrôle, dans les autres cas, soustraire le reste de 11 et utiliser le chiffre obtenu comme chiffre de contrôle.

Exemples de calcul :
Nombre imprimé 1 0 2 8 2 5 7 4
Pondération x 8 6 4 2 3 5 9 7
TOTAL 8+0+8+16+6+25+63+28 = 154
154/11 = 14 reste 0
Chiffre de contrôle : 5 Nombre autocontrôlé complet : 102825745.

Protocole DVCS
Loin de vouloir remplacer les produits actuels, nous nous sommes attachés à compléter l'infrastructure de certification existante afin que soit spécifié un standard pour répondre à une partie significative des besoins cidessus. Peter Sylvester d'EdelWeb est le co-auteur et l'éditeur de la norme RFC 3029 DVCS (Data Validation and Certification Services).

<Desc/Clms Page number 24>

A titre d'illustration, tentons de décrire, plus que la spécification DVCS que l'on trouve à l'adresse suivante : http ://www. ietf. org/rfc/rfc3029. txt, les raisons et caractéristiques de ce protocole.

Le protocole DVCS repose sur un double modèle : d'une part un modèle de document et d'autre part un modèle d'interaction avec un service. Le modèle de document reprend les exigences évoquées ci-avant. A ce jour, il repose sur CMS (Cryptographic Message Syntax), la partie de S/MIME v3 qui ne concerne que les documents à l'exclusion des problèmes de transport.

Bientôt, dès que les standards seront stabilisés, une forme équivalente, basée sur le format XML, sera spécifiée. Le modèle d'interaction avec le service est extrêmement simple : il s'agit d'un modèle de type "question/réponse"dans lequel, sans besoin de session, une requête peut être soumise au service qui génère une réponse. Le format de la requête est décrit dans la norme.

La réponse est une attestation DVCS (format CMS) qui peut donc être traitée et conservée comme un document de type "attestation dématérialisée".

La conception de ce protocole découle de la nécessité, en plus des infrastructures de certificat (CA, PKI), d'offrir aux utilisateurs des fonctions complémentaires telles que : - Le certificat Cl était il valable à la date

tu tel ? - Le document D signé par U et U dont les certificats sont respectivement Cl et C2 est-il valable (hors sémantique de contenu) ? - Le document D signé par U et U2 dont les certificats sont respectivement Cl et C2 était-il valable (hors sémantique de contenu) à la date T ?
Mieux encore : délivrez-moi une attestation (un document dématérialisé horodaté et signé) prouvant qu'à la

<Desc/Clms Page number 25>

date D j'ai bien effectué la demande de"vérification de la validité"du document D.

En prolongeant cette logique on arrive à : délivrez-moi une attestation dématérialisée témoignant que le document D existait à la date T ou délivrez-moi une attestation témoignant que moi utilisateur U j'étais bien en possession du document D à la date T ;
Pour aboutir finalement à un service générique de délivrance d'attestations dématérialisées en ligne (on peut donc envisager les équivalents des"certificats non gage","attestation d'activité salariée", etc.).

Descriptions protocoles MARS
La solution proposée s'appuie sur des produits des postes clients (logiciel de messagerie) communiquant selon des protocoles normalisés entre eux et avec le système d'enregistrement d'évènements.

Le protocole utilisé entre des logiciels de messagerie utilise l'échange des avis de réception défini par le RFC 2643 (ESS).

L'interface avec le système d'enregistrement des événements utilise le protocole suivant. Trois événements sont traités : - La création/émission d'un message ; - La réception d'un message et la création d'un avis de réception ; - La réception d'un avis de réception.

A la fin de la création d'un message le logiciel prépare une requête DVCS du type ccpd (certify claim possession of data) ou cpd (certify possession of data). Le premier type est une requête d'horodatage, le deuxième type correspond à une requête d'archivage. Le choix entre les deux requêtes est laissé libre à l'utilisateur. Les données à horodater/archiver sont le contenu du message. Le champ requester est renseigné avec

<Desc/Clms Page number 26>

l'adresse email de l'émetteur, le champ datalocations est renseigné avec les adresses des destinataires.

Le résultat de cette requête est un data validation certificat DVC, un document en format CMS. Le DVC est inclus dans le message dans la demande d'avis de réception.

Pendant la réception du message et la génération d'un avis de réception, le logiciel de messagerie prépare une requête de validate signed data DVCS. Le document à valider est le DVC inclus dans le message. Le champ requester est renseigné avec l'adresse email du destinataire.

Le résultat de cette requête est un data validation certificat DVC. Ce document en forme CMS est envoyé à l'émetteur avec l'avis de réception.

Pendant la réception d'un avis de réception, le logiciel prépare une requête de validate signed data DVCS ; le document à valider est le DVC inclus dans l'avis de réception. Le champ requester est renseigné avec l'adresse email de l'utilisateur (émetteur du message original).

En outre, l'émetteur et chaque destinataire peuvent interroger le système d'événements à chaque instant pour déterminer l'état d'avancement d'un message :
L'émetteur peut préparer une requête DVCS du type validate signed data. Le document à valider est le DVC obtenu pendant l'envoi du message initial. Le résultat est un DVC qui contient l'ensemble des DVC produit pendant chaque réception du message et des avis ;
Un destinataire peut préparer une requête DVCS du type validate signed data. Le document à valider est le DVC obtenu pendant la création de l'avis de réception. Si l'émetteur du message initial à reçu l'avis de réception, le résultat contient le DVC crée à cette action.

Le rôle du système d'enregistrement d'événements est de créer des attestations correspondant

<Desc/Clms Page number 27>

aux événements décrit ci-dessus. Le système stocke ces données pendant une durée configurable. Les données stockées sont les requêtes et réponses DVCS pour l'horodatage, et les requêtes sans données et les réponses en cas d'archivage.

L'ensemble des données stockées est transféré régulièrement au système de suivi.

Claims (19)

REVENDICATIONS

1-Procédé d'envoi de mèl à au moins un destinataire spécifique, comportant une étape de création d'une enveloppe numérique comportant au moins un élément d'identification de l'expéditeur, le contenu du mèl et les éléments permettant l'acheminement du mèl au destinataire spécifique, une étape de transmission par un réseau numérique de ladite enveloppe numérique à une plate-forme comportant un serveur centralisateur, ladite plate-forme effectuant la création d'un mèl comportant les informations liées au destinataire dudit mèl et le contenu électronique, et la transmission du mèl par l'intermédiaire d'un fournisseur d'accès Internet, caractérisé en ce qu'il comporte en outre une étape de mémorisation des éléments contenus dans l'enveloppe numérique et des informations concernant le destinataire du courrier, ladite mémorisation étant systématiquement effectuée pendant une première durée d'au moins un jour.

2-Procédé d'envoi de mèl selon la revendication 1, caractérisé en ce que l'enveloppe numérique comporte une séquence d'instruction de conservation.

3-Procédé d'envoi de mèl selon la revendication 1, caractérisé en ce que le procédé comporte en outre une étape accessoire de délivrance d'un certificat comportant les informations archivées relatives à un courrier spécifique, cette étape étant activée par une requête émise par l'expéditeur de ladite enveloppe numérique.

4-Procédé d'envoi de mèl selon la revendication 1 caractérisé en ce qu'on mémorise en outre

<Desc/Clms Page number 29>

les informations concernant la remise du mèl au destinataire spécifique ainsi que son éventuelle volonté de refuser le mèl avec demande d'avis de réception et suivi (MARS).

5-Procédé d'envoi de mèl selon la revendication 4 caractérisé en ce que les informations de remise du mèl comprennent une identification certaine du récepteur du mèl.

6-Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que la mémorisation du contenu de l'enveloppe numérique utilise des moyens de certification de date et de contenu.

7 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que l'on crée sur les serveurs de collection d'évènements et de service de suivi un journal des actions effectuées depuis la réception de l'enveloppe numérique

8-Procédé d'envoi de mèl selon la revendication 7 caractérisé en ce que en ce que l'expéditeur de l'enveloppe électronique a accès au journal.

9 - Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que l'architecture de l'infrastructure distribuée entre les postes utilisateurs utilise des protocoles ouverts.

10-Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que le serveur centralisateur envoie une notification de

<Desc/Clms Page number 30>

réception de l'enveloppe numérique à l'expéditeur de ladite enveloppe.

11-Procédé d'envoi de mèl selon la revendication 10 caractérisé en ce que ladite notification comprend la liste des éléments reçus

12-Procédé d'envoi de mèl selon la revendication 11 caractérisé en ce que ladite notification invite à compléter l'enveloppe numérique s'il manque des éléments nécessaires à l'envoi du mèl avec demande d'avis de réception et suivi (MARS).

13 - Procédé d'envoi de mèl selon l'une des revendications précédentes caractérisé en ce que les traces laissées sont nombreuses et au moins égales à trois : celle générée par l'expéditeur à la création du MARS, celle générée par le destinataire lors de la fabrication de l'AR et enfin celle générée par la réception de l'avis de réception qui termine ainsi la transaction.

14-Procédé d'envoi de mèl selon l'une quelconque des revendications précédentes caractérisé en ce que l'expéditeur utilise un moyen d'identification certain pour l'envoi de l'enveloppe numérique.

15-Procédé d'envoi de mèl selon la revendication 14 caractérisé en ce que l'expéditeur transmet les documents au serveur centralisateur par un moyen de télécommunication activé par le serveur centralisateur après identification de l'expéditeur.

16-Procédé d'envoi de mèl selon la revendication 14 ou 15 caractérisé en ce qu'il comporte une

<Desc/Clms Page number 31>

étape d'authentification de l'expéditeur par des moyens téléphoniques, biométriques ou iridologiques.

17-Procédé de conservation de mèl envoyé par un procédé selon l'une quelconque des revendications précédentes caractérisé en ce qu'il comporte un horodatage universel non répudiable et un processus de mise à niveau de la lisibilité du contenu des mèls avec demande d'avis de réception et suivi (MARS) durant toute la période d'archivage demandée à la création de ce MARS par l'expéditeur.

18-Interface pour la mise en oeuvre du procédé d'envoi de mèl selon la revendication 1, caractérisé en ce qu'elle permet la saisie de l'enveloppe numérique à envoyer.

19-Procédé de réception de mèl envoyé par un procédé selon l'une quelconque des revendications 1 à 16 caractérisé en ce que l'on procède de la façon exactement contraire au procédé décrit dans la revendication 1, c'est- à-dire que le destinataire d'un mèl simple est en mesure de demander l'authentification horodatée avec conservation de ce mèl selon ses propres critères personnels, mais selon les caractéristiques MARS.