Serveur et procédé d'horodatage de données électroniques

La présente invention concerne un serveur et un procédé d'horodatage de données électroniques.

On connaît déjà, dans l'état de la technique, un serveur d'horodatage du type comprenant :

- un module d'horodatage apte à horodater des données avec une heure et une date obtenues à partir d'une source de temps et,

- un module de signature apte à signer des données horodatées par le module d'horodatage.

En général, le serveur d'horodatage du type précité fournit un service d'horodatage en répondant à des requêtes contenant des données à horodater, émises depuis un terminal client.

A la réception d'une requête, le serveur obtient tout d'abord une date et une heure à partir de la source de temps et le module d'horodatage joint cette date et cette heure aux données électroniques contenues dans la requête, ou plus couramment à un condensé de ces données.

Afin de certifier l'authenticité de l'horodatage, les données (ou leur condensé) horodatées sont ensuite signées par le module de signature.

De façon connue en soi, l'opération de signature des données consiste à traiter les données horodatées avec une clé privée, cette clé privée étant associée à une autorité de certification. Ce traitement consiste à calculer un résultat chiffré à partir des données et de la clé. L'homme du métier désigne par "signature" non seulement ce résultat chiffré mais également, par abus de langage, l'ensemble constitué par la concaténation des données et de ce résultat chiffré. Une désignation couramment admise pour cet ensemble est "jeton d'horodatage".

Généralement, la clé privée est associée à une clé publique, cette clé publique permettant, à toute personne le souhaitant, de vérifier la signature.

Le « jeton d'horodatage » est enfin envoyé au terminal client ayant émis Ia requête.

Un service d'horodatage permet donc de certifier l'existence de données électroniques à partir d'une date et d'une heure données.

La qualité du service d'horodatage fourni par le serveur dépend notamment de l'exactitude et de la fiabilité de la date et de l'heure de la source de temps associée au module d'horodatage. La source de temps peut être, par exemple, une horloge interne du serveur ou une horloge atomique externe.

-Z-

Or, le besoin d'un utilisateur en matière d'horodatage peut varier quant à la fiabilité du service. On sait que l'obtention d'un service de très grande fiabilité occasionne des coûts assez élevés. En fonction de son besoin, l'utilisateur doit donc choisir le serveur auquel envoyer la requête et éventuellement formuler cette dernière selon un format spécifique à ce serveur.

En d'autres termes, un serveur d'horodatage ne peut fournir qu'un seul service d'horodatage, et ce quel que soit le besoin de l'utilisateur.

L'invention vise à remédier à cet inconvénient en proposant un serveur d'horodatage pouvant fournir au moins deux services d'horodatage se distinguant, par exemple, par un niveau de qualité différent.

A cet effet, l'invention a pour objet un serveur d'horodatage du type précité, caractérisé en ce qu'il comprend un module de décision apte à prendre en compte un critère prédéfini et à sélectionner, en fonction de ce critère, la source de temps devant fournir une heure et une date au module d'horodatage.

Ainsi, un utilisateur peut sélectionner un service d'horodatage avec une qualité adaptée à son besoin et ce par l'intermédiaire d'un même serveur.

Par ailleurs, comme l'utilisateur envoie des requêtes à un seul serveur, il n'a plus à reformuler la requête selon le format d'un serveur correspondant au niveau de qualité du service souhaité.

Selon l'invention, un même serveur peut fournir différents services d'horodatage ayant des niveaux de qualité différents, quant à la fiabilité de la source de temps sélectionnée pour l'horodatage des données.

Eventuellement, le serveur peut comporter un module d'obtention d'une heure et d'une date à partir d'une source de temps, le module d'obtention comprenant des moyens de paramétrage d'une adresse d'une source de temps devant fournir une heure et une date au module d'horodatage.

Ainsi, il est possible de paramétrer une adresse d'une source de temps ayant un niveau de fiabilité correspondant à la qualité du service souhaitée pour l'horodatage des données. Par exemple, l'adresse peut être une adresse d'une horloge atomique d'une université, ou une adresse d'une horloge interne du serveur.

En variante, le serveur peut comporter au moins deux modules d'obtention d'une heure et d'une date en fonction d'une source de temps, chaque module étant lié à une source de temps prédéfinie. Dans ce cas, chaque module d'obtention fournit une heure et une date à partir d'une source de temps prédéfinie. Le module de décision sélectionne le module d'obtention associé à une source de temps ayant un niveau de fiabilité correspondant à la qualité du service souhaitée pour l'horodatage des données.

Un serveur d'horodatage selon l'invention peut en outre comporter l'une ou plusieurs des caractéristiques suivantes :

- le serveur comprend une unité d'analyse de la requête afin d'extraire le critère prédéfini ;

- le critère prédéfini est un format de la requête ;

- le critère prédéfini est une indication contenue dans la requête ;

- le critère prédéfini est un émetteur de la requête ;

- le serveur comprend un moyen de stockage d'au moins une clé privée associée à une autorité de certification, cette clé privée étant utilisable par le module de signature ;

- le module de décision est apte à sélectionner, en fonction du critère prédéfini, la clé privée associée à l'autorité de certification, à utiliser par le module de signature ; le serveur comprend une mémoire contenant une table de correspondance entre au moins une clé privée du moyen de stockage et une source de temps susceptible de fournir une heure et une date au module d'horodatage à utiliser par le module de signature.

L'invention a encore pour objet un procédé d'horodatage de données contenues dans une requête d'horodatage comprenant : une étape d'horodatage des données avec une heure et une date obtenues à partir d'une source de temps, et

- une étape de signature des données horodatées lors de l'étape d'horodatage, caractérisé en ce qu'il comprend :

- une étape de décision prenant en compte un critère prédéfini et dans laquelle on sélectionne, en fonction de ce critère, la source de temps devant fournir une heure et une date destinées à l'horodatage des données.

Un procédé d'horodatage selon l'invention peut en outre comporter l'une ou plusieurs des caractéristiques suivantes :

- le procédé comprend une étape d'analyse des données contenues dans la requête afin d'extraire le critère prédéfini ;

- le critère prédéfini est un format de la requête ;

- le critère prédéfini est une indication contenue dans la requête ; le critère prédéfini est un émetteur de la requête ;

- pour l'étape de signature des données horodatées, une clé privée associée à une autorité de certification est sélectionnée en fonction du critère prédéfini,

parmi au moins deux clés privées associées à des autorités de certification différentes.

L'invention sera mieux comprise à la lecture de la description qui va suivre, donnée uniquement à titre d'exemple et faite en se référant au dessin dans lequel la figure unique représente schématiquement la structure générale d'un serveur d'horodatage selon l'invention.

On a représenté sur la figure un serveur d'horodatage 10 adapté à la fourniture d'un service d'horodatage.

Le serveur 10 est apte à recevoir une requête d'horodatage contenant des données à horodater, émise par un terminal client 12 et à renvoyer en réponse un « jeton d'horodatage » conformément au standard RFC3161 de NETF (de l'anglais : Internet Engineering Task Force).

Le « jeton d'horodatage » constitue ainsi une preuve de l'existence des données à une date et une heure données.

Le serveur 10 comprend un module de réception 14 d'une requête émise par le terminal 12, apte à recevoir la requête émise dans un format particulier par le terminal client et à reformuler cette requête dans un format interne au serveur 10.

A cet effet, le module de réception 14 comprend des unités 16 d'analyse de requêtes, chaque unité d'analyse étant spécifique au traitement d'un format particulier de requête émise par le terminal client 12.

Par exemple, l'unité 16a est spécifique au traitement du format « http », l'unité 16b au traitement du format de transmission « Socket », et l'unité 16c au traitement du format « Mail ».

Par ailleurs, chaque unité d'analyse 16 est apte à extraire un critère prédéfini de la requête, ce critère permettant de définir un niveau de qualité à attribuer à l'horodatage des données.

En particulier, le critère prédéfini peut être l'émetteur de la requête.

Dans ce cas, le serveur 10 peut comprendre des moyens de mémorisation d'une liste d'émetteurs préalablement identifiés et associés à un niveau de qualité à appliquer.

Le critère prédéfini peut encore être le format de la requête.

Le critère peut également être une indication contenue dans la requête.

Par exemple, un utilisateur pourra adjoindre cette indication à la requête en sélectionnant, au moment d'envoyer une requête, dans un menu affiché sur un écran du terminal client connecté au serveur 10, un niveau de qualité correspondant à son besoin parmi différents niveaux de qualité.

Les unités d'analyse 16 peuvent être facilement intégrées au serveur 10 sous forme de modules d'extension, du type « plugiciel » (de l'anglais « plug-in »).

Dans l'exemple décrit, on a représenté trois unités d'analyse mais l'invention ne se limite pas à ce mode de réalisation et peut notamment comporter une, deux, trois ou plus de trois unités d'analyse 16.

Le serveur 10 comporte également un module de décision 18 apte à recevoir en entrée la requête reformulée dans le format interne au serveur 10.

Le module de décision 18 est apte à prendre en compte le critère prédéfini extrait de la requête par le module de réception 14 et à sélectionner, en fonction de ce critère, une source de temps S devant fournir une heure et une date à un module d'horodatage 22 des données, cette source S devant être adaptée au niveau de qualité déterminé.

Ainsi, la source de temps S peut être sélectionnée, par exemple, parmi une horloge atomique d'une université S1 , une horloge interne du serveur S2 ou un réseau GPS S3 ...

De ce fait, l'heure et la date peuvent avoir des niveaux de fiabilité différents selon le choix de Ia source de temps S.

Le serveur 10 comprend également trois modules d'obtention 24a, 24b, 24c, d'une heure et d'une date à partir de la source de temps S, chaque module d'obtention étant apte à fournir une heure et une date au module d'horodatage 22.

Chaque module d'obtention 24a, 24b, 24c est respectivement lié à une source de temps prédéfinie S1 , S2, S3. Par ailleurs, la source S1 a un niveau de fiabilité plus grand que S2, qui a un niveau de fiabilité plus grand que S3.

En variante, le serveur 10 peut comporter un unique module d'obtention 24. Dans ce cas, le module d'obtention 24 comprend des moyens de paramétrage d'une adresse d'une source de temps S. Ainsi, le module d'obtention 24 peut fournir une date et une heure à partir d'une des sources S1 , S2 ou S3 au module d'horodatage 22, en paramétrant l'adresse correspondant à la source de temps sélectionnée.

Le module d'horodatage 22 est apte à horodater les données avec l'heure et la date fournies par les moyens d'obtention 24 à partir de la source de temps S.

Le serveur 10 comprend encore un module de signature 26 apte à signer les données horodatées par le module d'horodatage 22.

Généralement, la signature des données consiste à traiter les données avec une clé privée associée à une autorité de certification.

De façon connue en soi, une autorité de certification permet de garantir l'authenticité de la clé privée destinée à signer des données électroniques. En particulier, selon le niveau de fiabilité de l'autorité de certification associée à la clé privée, la signature des données sera plus ou moins fiable.

A cet effet, le serveur 10 comporte un module 28 de stockage de Ia clé privée C associée à l'autorité de certification, la clé privée C étant utilisable par le module de signature 26.

On a représenté sur la figure, un module de stockage 28 contenant trois clés privées C1 , C2, C3 chacune associée à une autorité de certification bénéficiant de niveaux de confiance différents. Dans cet exemple, la clé privée C1 est associée à une autorité de certification ayant un niveau de confiance plus grand que l'autorité de certification associée à la clé C2, l'autorité de certification associée à la clé C2 ayant un niveau de confiance plus grand que l'autorité de certification associée à la clé C3.

Ainsi, le module de décision 18 est apte à sélectionner, en fonction du critère prédéfini, la clé privée C1 , C2, C3 associée à l'autorité de certification à utiliser par le module de signature 26.

De façon optionnelle, le serveur 10 comporte encore une mémoire 30 contenant une table de correspondance entre une source de temps S et une clé privée C.

Par exemple, une source de temps peut être associée à une clé privée associée à une autorité de certification ayant un niveau de confiance équivalent de celui de la source de temps. Dans cet exemple, S1 est associé à C1 , S2 à C2 et S3 à C3.

En variante, une source de temps peut être associée à une clé privée associée à une autorité de certification ayant un niveau de confiance différent de celui de la source de temps.

Ainsi, il est possible d'avoir une relativement importante variété de services d'horodatage dépendant notamment du nombre de combinaisons réalisables d'une source de temps avec une clé privée.

Dans l'exemple décrit, on peut former neuf combinaisons différentes d'une source de temps avec une clé privée, de façon à définir neuf services d'horodatage correspondant chacun à un niveau de qualité différent.

De ce fait, il est possible de fournir une qualité de service d'horodatage adaptée au besoin du client du terminal 12.

On décrira ci-dessous les principaux aspects d'un procédé d'horodatage selon l'invention.

Le terminal client 12 envoie au serveur 10 une requête, par exemple avec un format de transmission « http » et contenant des données à horodater.

Le module de réception 14 dirige la requête vers l'unité d'analyse 16a, adaptée au traitement du format « http ».

L'unité d'analyse 16a extrait de la requête un critère prédéfini, par exemple une indication contenue dans la requête, et reformule la requête dans le format interne au serveur 10.

Le module de réception 14 transmet alors la requête reformulée dans le format interne au serveur 10, au module de décision 18.

Le module de décision 18 prend en compte le critère prédéfini et sélectionne alors un module d'obtention 24 lié à une source de temps S et une clé privée C dans le module de stockage 28, la source de temps S et la clé privée C étant adaptées à la qualité du service souhaité.

En particulier, si la requête contient une indication précisant un choix de service de relativement grande qualité, le module de décision 18 sélectionne le module d'obtention 24a, associé à la source de temps S1 ayant un niveau de fiabilité important.

Dans le cas où la requête ne contient aucune indication particulière précisant un choix de qualité de service, le serveur 10 vérifie que l'émetteur de la requête appartient à la liste d'émetteurs préalablement identifiés. Si ce n'est pas le cas, le choix de la qualité de service est par exemple réalisé en fonction du format de la requête.

Le module d'obtention 24a fournit alors une heure et une date à partir de la source de temps S1 sélectionnée. Le module d'horodatage 22 joint la date et l'heure aux données.

Après lecture de la table de correspondance contenue dans la mémoire 30, le module 18 sélectionne la clé privée C1 associée à une autorité de certification bénéficiant du niveau de fiabilité souhaité et la fournit au module de signature 26.

Le module de signature 26 signe alors les données horodatées avec la clé privée C1.

Les données ainsi horodatées et signées forment « un jeton d'horodatage » et l'unité d'analyse 16a, correspondant au format de transmission de la requête renvoie le « jeton » au terminal client 12. En général, le module de signature 26 incorpore le « jeton » dans un format PKCS#7 qui est un format classique des « jetons d'horodatage ».

Le serveur d'horodatage 10 peut donc fournir une variété relativement importante de qualités du service d'horodatage.

Il est notamment possible d'adapter la qualité du service à l'importance d'un document électronique et ce, sans avoir à reformuler la requête dans un format de transmission spécifique au serveur 10.

L'invention s'applique particulièrement à une autorité d'horodatage proposant des services d'horodatage à partir d'un serveur d'horodatage selon l'invention, qui pourrait fournir, dans un premier temps, un service d'horodatage gratuit de qualité faible afin de

tester le serveur d'horodatage puis, dans un second temps, fournir des services d'horodatage ayant des qualités différentes dont le coût augmenterait avec la qualité du service proposé.

En variante, chaque unité d'analyse 16 peut comprendre un module de décision 18 spécifique au format de la requête traité par l'unité 16.