Vous êtes ici: accueil » documentation » pkix » horodatage
Garantir électroniquement la date et l'heure
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 :
Bien des services peuvent être construits si l'on dispose d'une bonne garantie quant à l'heure et la date :
Un service d'horodatage se conçoit difficilement sans une PKI 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. Le temps n'est pas une substance comme les autres, 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.
Le principe générique de l'horodatage est le suivant :
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 :
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.
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.
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 entre signatures et 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).
L'heure et la date fournie par le serveur d'horodatage doivent bien sûr être les plus fiables possibles. 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 :
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 » :
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.
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 :
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.
