L’horodatage

Généralités
Le principe de l’horodatage est d’associer de façon la plus sûre possible une date et une heure à des données.
Avoir une garantie cryptographique de l’heure permet par exemple :
– De prouver l’existence de certaines données à partir d’une certaine date,
– A cette garantie d’existence on peut joindre des garanties de possession,
– De certifier des heures et dates de signature,
– De renforcer les fonctions de non-répudiation associées à la signature, puisque lors d’une signature classique la date de signature n’est pas forcement fiable, et peut donc être contestée,
– De garantir les heures et dates de validité des CRL. Si par exemple on souhaite vérifier une signature longtemps après qu’elle ait été faite, on devra entre autres s’assurer que le certificat qui était associé à la clé privée qui a signé n’était pas révoqué. Donc absent de la CRL. Cela suppose donc d’archiver les CRL, et de consulter la bonne, c’est à dire la CRL dont on est certain des dates de validité, ou une CRL qui conserve toutes les dates de révocation mais dont ces dates puissent être garanties.
– ...

Bien des services peuvent être construits si l’on dispose d’une bonne garantie quant à l’heure et à la date :
– Des certifications de date de signature,
– Des preuves de possession,
– Des preuves d’existence,
– Des mécanismes pour garantir des heures de transaction (achats/ventes, jeux, votes),
– Des systèmes de messages certifiés avec accusé de réception,
– Intervenir dans des processus de notarisation et d’archivage sécurisé
– ...

Un service d’horodatage se conçoit difficilement sans une ICP (Infrastructure à Clés Publiques) quelque part, plus ou moins proche (utilisation de certificats, signature, CRL...). Dans certains cas, l’Autorité d’Horodatage peut cependant être sa propre autorité de certification.
La mesure du temps n’est pas triviale, et il se pose naturellement la question de la légitimité de celui qui donne l’heure.
Il n’existe pas actuellement d’Autorité d’Horodatage reconnue au niveau mondial, européen ou même français.
A bien des égards, une Autorité d’Horodatage peut être vue comme un tiers qui certifie des heures et des dates, sans avoir d’intérêt à les falsifier.
Dans ce sens, il est probable que les Autorités d’Horodatage qui émergeront, et survivront, seront des Autorités émanant d’institutions publiques plutôt que de sociétés privées. Question de légitimité et de pérennité.
Dans la plupart des cas, une Autorité d’Horodatage ne fait que générer ce qu’on appelle des jetons pour d’autres services, en particulier des services de signature.

Fonctionnement
Le principe générique de l’horodatage est le suivant :

– Les données à horodater sont passées au travers d’une fonction de condensation (SHA-1, MD5...)
– Ce condensé (une valeur de longueur fixe, de 128 ou 160 bits par exemple) est envoyé à l’Autorité d’Horodatage
– Celle-ci joint au condensé le GDH (Groupe Date Heure, au format UTC : Coordinated Universal Time dont le format est YYYYMMDDhhmmssZ)
– L’AH signe la concaténation condensé + GDH (au moyen de RSA, DSA...) : le résultat est une capsule CMS (Cryptographic Message Syntax, RFC 2630), appelée jeton (Time-Stamp token en anglais)
– Le tout est renvoyé au demandeur qui dispose alors d’une preuve du fait que le condensé existait avant la date donnée dans le GDH. Le condensé étant une " empreinte " des données initiales, la preuve s’applique donc aussi à ces données.

Les jetons générés sont donc des capsules CMS (RFC 2630) dont la structure "Content" du "ContentInfo" est à "SignedData". La RFC 3161 définit le format des jetons d’horodatage (enfin finalisée en août 2001 après une quinzaine de drafts), ainsi que les formats des échanges avec les Autorités d’Horodatage.
L’ETSI publie d’ailleurs un profil qui précise la RFC.

Une des principales applications des jetons d’horodatage peut être de certifier la date d’une signature.
Dans ce cas, la cinématique devient :

– Une signature est effectuée sur des données. Cette signature se matérialise par une capsule CMS (ou éventuellement PKCS#7)
– Un condensé de cette capsule est calculé, puis envoyé au TSA (Time Stamp Authority).
– Le TSA horodate ce condensé, le résultat étant une autre capsule CMS, le jeton.
– Ce jeton est ensuite inséré dans un des attributs non signés de la capsule initiale (c’est ce que recommande la RFC).

Si c’est ajouté dans un des champs non signé, c’est parce que cette information vient après que la signature ait été faite. Cela signifie aussi qu’on peut envisager d’extraire ce jeton et de le remplacer par un faux. C’est pourquoi, même si l’on utilise de l’horodatage, il faut prendre garde à avoir une heure de signature relativement fiable, afin de pouvoir la comparer à celle certifiée par le jeton.
Encore un fois, l’horodatage sert essentiellement à prouver l’existence de données à partir d’une date et d’une heure donnée. La donnée en question ici est une signature.

Politique d’horodatage
Le fonctionnement d’un serveur d’horodatage, comme toute autorité qui est amenée à signer, doit être régi par une Politique d’Horodatage (PH) et une déclaration des Pratiques d’Horodatage (DPH). Ces documents donnent les formats, exigences de sécurité, responsabilités... etc (PH) et la façon dont ces propriétés sont garanties, les procédures en cas de situation d’urgence, le détail des contrôles effectués... etc (DPH).
L’ETSI finalise une Politique d’Horodatage type.

Clé et certificat de signature du TSA
Les algorithmes les plus utilisés pour les serveurs d’horodatage sont RSA ou DSA. Le choix entre ces deux algorithmes se fera par exemple en considérant les performances attendues et la proportion relative de signatures et de vérifications de signature dans l’ensemble de l’infrastructure.
A plus ou moins court terme, les courbes elliptiques devraient être disponibles sur les dispositifs d’horodatage (ECC : elles présentent l’avantage d’utiliser des clés de longueurs plus courtes que RSA ou DSA, à sécurité égale. Gain en performance, donc).
Si la clé privée du serveur d’horodatage en vient à être compromise, il faudrait être en mesure de révoquer le certificat correspondant, et donc de publier une CRL.
La clé de signature du serveur d’horodatage doit être longtemps utilisable, et doit donc avoir une longueur suffisante (1024 ou 2048 bits par exemple).

Heure de confiance et dispositif de signature
L’heure et la date fournie par le serveur d’horodatage doivent bien sûr être les plus fiables possible. Le cœur des serveurs d’horodatage est en général constitué d’un boîtier.
Ce boîtier peut avoir les propriétés suivantes :

– Une implémentation matérielle des algorithmes de signature qu’utilise le serveur d’horodatage (génération, stockage, signature...)
– Une connexion à une source de temps fiable qui lui permet de resynchroniser régulièrement son horloge. Ces sources peuvent être le réseau GPS, l’horloge atomique du NIST... etc.
– Des détecteurs anti-intrusion qui bloquent le boîtier si on essaie de l’ouvrir
– ...

Concernant les sources de temps, les aspects politiques et économiques entre pays ou entreprises sont à prendre en compte.

Ces dispositifs peuvent être certifiés (Critères Communs (EAL 3,4), FIPS-140 niveau 4...)
Le dispositif de signature devrait être protégé au niveau réseau, principalement pour se prémunir des dénis de service et des accès non autorisés.
Certaines API d’accès implémentent un protocole de sécurisation comme GSS ou SSL-TLS. Ce qui est alors recherché est l’authentification forte des applications qui accèdent au TSA.

De même, le dispositif de signature devrait être protégé physiquement, dans ce qu’on appelle communément un " bunker " :

– Contrôle des accès
– Habilitation du personnel
– Protection norme TEMPEST
– Site de secours géographique
– Procédures d’urgence prêtes H24
– ...

Service de vérification
A tout serveur d’horodatage devrait être joint un service de vérification, permettant de vérifier la validité des jetons générés. On envoie par exemple le condensé des données à vérifier, ainsi que le jeton, et le service de vérification affiche le contenu du jeton et son statut.

Accessibilité
Pour envoyer des données à un serveur d’horodatage (des condensés, formatés au sein de requêtes), la RFC prévoit l’utilisation du mail, du transfert par fichier, d’HTTP, ou de connexions TCP. Ce dernier moyen est le plus répandu, et la plupart des serveurs d’horodatage ont le port 318 à l’écoute des requêtes d’horodatage conformes au protocole défini dans la RFC.
Les éditeurs de TSA fournissent des API permettant d’y accéder. Ces API peuvent avoir les propriétés suivantes :

– Calcul de condensés
– Ouverture et fermeture de la connexion avec le TSA
– Formatage et envoi d’une requête d’horodatage
– Récupération du certificat du TSA
– Vérification d’un jeton d’horodatage
– ...

Juridique
Ni la loi du 13 mars 2000 sur la signature électronique, ni le décret qui la précise, ne font de mention explicite à l’horodatage. Tout au plus est-il dit que les Autorités de Certification devront porter des heures et dates fiables sur les certificats et CRL qu’elles délivrent. Il y a cependant fort à parier que, via des précisions législatives ou des décisions de jurisprudence, l’horodatage sera amené à avoir un rôle crucial, vu l’importance de la date en droit.

 
 
 
 
 
 
Partager sur Twitter  |  Partager sur LinkedIn