man ts (1): Outil d’autorité d’horodatage (client et serveur)

SYNOPSIS

openssl ts -query [-rand fichier:fichier...] [-config fichier_conf] [-data fichier_à_hacher] [-digest octets_sign] [-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...] [-policy id_objet] [-no_nonce] [-cert] [-in demande.tsq] [-out demande.tsq] [-text]

openssl ts -reply [-config fichier_conf] [section section_tsa] [-queryfile demande.tsq] [-passin src_mot_de_passe] [-signer tsa_cert.pem] [-inkey privée.pem] [-chain fichier_certs.pem] [-policy id_objet] [-in réponse.tsr] [-token_in] [-out response.tsr] [-token_out] [-text] [-engine id]

openssl ts -verify [-data fichier_à_hacher] [-digest octets_sign] [-queryfile demande.tsq] [-in réponse.tsr] [-token_in] [-CApath chemin_cert_confiance] [-CAfile certs_confiance.pem] [-untrusted fichier_cert.pem]

DESCRIPTION

La commande ts est une application client et serveur d’autorité d’horodatage (« Time Stamping Authority », TSA) conforme à la RFC 3161 (protocole d'horodatage, « Time-Stamp Protocol » TSP). Une TSA peut faire partie d'un déploiement de PKI et son rôle est de fournir des preuves à long terme de l'existence d'une certaine donnée avant un moment donné. Voici une brève description du protocole.

1.: Le client TSA calcule une valeur de hachage à sens unique pour un fichier de données et envoie le hachage à la TSA.
2.: La TSA attache la date et l'heure à la valeur de hachage reçue, les signe et envoie le jeton d’horodatage au client. En créant ce jeton, la TSA certifie l'existence du fichier original de données au moment où la réponse est créée.
3.: Le client TSA reçoit le jeton d'horodatage et en vérifie la signature. Il vérifie également si le jeton contient la même valeur de hachage qu'il avait envoyé à la TSA.

Une unité de données de protocole encodée DER est définie pour le transport d'une demande d'horodatage à la TSA et une autre pour l'envoi de la réponse d'horodatage au client. La commande ts a trois fonctions principales : créer une demande d'horodatage à partir d'un fichier de données, créer une réponse d'horodatage à partir d'une demande et vérifier si une réponse correspond à une demande particulière ou à un fichier de données.

Aucune prise en charge n’existe encore pour l’envoi de demandes et réponses automatiquement par HTTP ou TCP comme suggéré dans la RFC 3161. Les utilisateurs doivent envoyer les demandes par FTP ou courrier électronique.

OPTIONS

Création de demande d’horodatage

L’option -query peut être utilisée pour créer et afficher une demande d'horodatage avec les options suivantes :

-rand fichier:fichier...: Les fichiers contenant des données aléatoires utilisées pour initialiser le générateur de nombres pseudoaléatoires. Plusieurs fichiers peuvent être indiqués en utilisant le séparateur du système d'exploitation : « ; » pour Windows, « , » pour OpenVMS et « : » pour tous les autres. (Facultatif)
-config fichier_conf: Le fichier de configuration à utiliser, cette option remplace la variable d'environnement OPENSSL_CONF. Seule la section OID du fichier de configuration est utilisée avec la commande -query. (Facultatif)
-data fichier_à_hacher: Le fichier de données pour lequel la demande d'horodatage doit être créée. L’entrée standard est la valeur par défaut si aucune des options -data ou -digest n’est indiquée. (Facultatif)
-digest octets_sign: Indiquer explicitement l’empreinte du message est possible sans le fichier de données. L’empreinte doit être indiquée au format hexadécimal, deux caractères par octet, les octets éventuellement séparés par des deux-points (par exemple 1A:F6:01:... ou 1AF601...). Le nombre d’octets doit correspondre à l’algorithme de signature de message utilisé. (Facultatif)
-md2|-md4|-md5|-sha|-sha1|-mdc2|-ripemd160|...: La signature de message à appliquer au fichier de données, tous les algorithmes de signature de message pris en charge par la commande openssl dgst sont utilisables. La valeur par défaut est SHA-1. (Facultatif)
policy id_objet: La politique attendue par le client de la TSA à utiliser pour créer le jeton d'horodatage. Soit la notation OID avec points, soit les noms d’OID définis dans le fichier de configuration peuvent être utilisés. Si aucune politique n’est demandée, la TSA utilisera sa propre politique par défaut. (Facultatif)
-no_nonce: Aucun nonce n’est indiqué dans la demande si cette option est donnée. Sinon, un nonce pseudoaléatoire de 64 bits est inclus dans la demande. Utiliser nonce est recommandé pour se protéger contre les attaques par rejeu. (Facultatif)
-cert: La TSA devrait inclure son certificat de signature dans la réponse. (Facultatif)
-in demande.tsq: Cette option indique une demande d'horodatage précédemment créée au format DER qui sera envoyée dans le fichier de sortie. Utile pour examiner le contenu d'une demande au format lisible. (Facultatif)
-out demande.tsq: Nom du fichier de sortie où la demande doit être écrite. La sortie standard par défaut. (Facultatif)
-text: Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER. (Facultatif)

Création de réponse d’horodatage

Une réponse d’horodatage (TimeStampResp) se compose d'un état de réponse et du jeton d'horodatage lui-même (ContentInfo), si la création du jeton a réussi. La commande -reply permet de créer une réponse d'horodatage ou un jeton d'horodatage suivant la demande et l’affichage de la réponse ou du jeton dans un format lisible. Si -token_out n'est pas indiqué, la sortie est toujours une réponse d'horodatage (TimeStampResp), sinon c'est un jeton d'horodatage (ContentInfo).

-config fichier_conf: Le fichier de configuration à utiliser, cette option remplace la variable d'environnement OPENSSL_CONF. Consultez OPTIONS DU FICHIER DE CONFIGURATION pour les variables configurables. (Facultatif)
-spksect section: Le nom de la section du fichier de configuration contenant les paramètres pour la création de la réponse. S'il n'est pas indiqué, la section TSA par défaut est utilisée, consultez OPTIONS DU FICHIER DE CONFIGURATION pour plus de précisions. (Facultatif)
-queryfile demande.tsq: Le nom du fichier contenant une demande d’horodatage encodée en DER. (Facultatif)
-passin src_mot_de_passe: Indiquer la source pour la clef privée de la TSA. Consultez la section PARAMÈTRES DE PHRASE SECRÈTE d'openssl(1).
-signer tsa_cert.pem: Le certificat de signataire de la TSA au format PEM. Le certificat de signature TSA doit avoir exactement une utilisation de clef étendue attribuée : timeStamping. L'utilisation de la clef étendue doit aussi être critique, sinon le certificat sera refusé. Cela remplace la variable signer_cert du fichier de configuration. (Facultatif)
-inkey privée.pem: La clef privée du signataire de la TSA au format PEM. Cela remplace l'option signer_key du fichier de configuration. (Facultatif)
-chain fichier_certs.pem: L’ensemble des certificats au format PEM qui seront tous inclus dans la réponse en plus du certificat de signataire si l'option -cert a été utilisée pour la demande. Ce fichier est censé contenir la chaîne de certificats pour le certificat de signataire à partir de ses émetteurs. La commande -reply ne construit pas de chaîne de certificats automatiquement. (Facultatif)
policy id_objet: La politique par défaut à utiliser pour la réponse à moins que le client ne demande explicitement une politique TSA particulière. L'OID peut être indiqué en utilisant une notation avec points ou par son nom. Cela remplace l'option default_policy du fichier de configuration. (Facultatif)
-in réponse.tsr: Indiquer une réponse d'horodatage créée précédemment ou un jeton d'horodatage (si -token_in est également indiquée) au format DER qui sera écrit dans le fichier de sortie. Cette option ne nécessite pas de demande, elle est par exemple utile pour examiner le contenu d'une réponse ou d'un jeton ou pour extraire le jeton d'horodatage d'une réponse. Si l'entrée est un jeton et la sortie une réponse d'horodatage, une information d’état accordée (« granted ») par défaut est ajoutée au jeton. (Facultatif)
-token_in: Cet indicateur peut être utilisé avec l'option -in et indique que l'entrée est un jeton d'horodatage encodé DER (ContentInfo) au lieu d'une réponse d'horodatage (TimeStampResp). (Facultatif)
-out réponse.tsr: La réponse est écrite dans ce fichier. Le format et le contenu du fichier dépendent d'autres options (consultez -text, -token_out). La valeur par défaut est la sortie standard. (Facultatif)
-token_out: La sortie est un jeton d'horodatage (ContentInfo) au lieu d’une réponse d’horodatage (TimeStampResp). (Facultatif)
-text: Si cette option est indiquée, la sortie est au format texte lisible au lieu de DER. (Facultatif)
-engine id: Indiquer un moteur (en utilisant son identifiant unique id) forcera ts à essayer d'obtenir une référence fonctionnelle pour le moteur indiqué et l'initialiser si nécessaire. Le moteur sera ensuite utilisé par défaut pour tous les algorithmes disponibles. La valeur par défaut est « builtin ». (Faclutatif)

Vérification de réponse d’horodatage

La commande -verify sert à vérifier si une réponse d'horodatage ou un jeton d'horodatage est valable et correspond à une demande d'horodatage ou un fichier de données particuliers. La commande -verify n'utilise pas le fichier de configuration.

-data fichier_à_hacher: La réponse ou le jeton doivent être vérifiés par rapport à fichier_à_hacher. Le fichier est haché avec l’algorithme de signature de message indiqué dans le jeton. Les options -digest et -queryfile ne doivent pas être indiquées avec cette option. (Facultatif)
-digest octets_sign: La réponse ou le jeton doivent être vérifiés par rapport à la signature de message indiquée par cette option. Le nombre d'octets doit correspondre à l’algorithme de signature de message indiqué dans le jeton. Les options -data et -queryfile ne doivent pas être indiquées avec cette option. (Facultatif)
-queryfile demande.tsq: La demande originale d’horodatage au format DER. Les options -data et -queryfile ne doivent pas être indiquées avec cette option. (Facultatif)
-in réponse.tsr: La réponse d'horodatage à vérifier au format DER. (Obligatoire)
-token_in: Cet indicateur peut être utilisé avec l'option -in et indique que l'entrée est un jeton d'horodatage encodé DER (ContentInfo) au lieu d'une réponse d'horodatage (TimeStampResp). (Facultatif)
-CApath chemin_cert_confiance: Le nom du répertoire contenant les certificats de l’autorité de confiance du client. Consultez l'option similaire de verify(1) pour plus de précisions. Soit cette option, soit -CAfile doit être indiquée. (Facultatif)
-CAfile certs_confiance.pem: Le nom du fichier contenant un ensemble de certificats autosignés de l’autorité de confiance au format PEM. Consultez l'option similaire de verify(1) pour plus de précisions. Soit cette option, soit -CApath doit être indiquée. (Facultatif)
-untrusted fichier_cert.pem: Ensemble de certificats supplémentaires qui ne sont pas de confiance au format PEM pouvant être nécessaires lors de la construction de la chaîne de certificats d'un certificat de signature de la TSA. Ce fichier doit contenir le certificat de signature TSA et tous les certificats d’autorité intermédiaires sauf si la réponse les inclut. (Facultatif)

OPTIONS DU FICHIER DE CONFIGURATION

Les commandes -query et -reply utilisent un fichier de configuration défini par la variable d'environnement OPENSSL_CONF. Consultez config(5) pour une description générale de la syntaxe du fichier de configuration. La commande -query n’utilise que la section des noms symboliques d’OID et peut fonctionner sans elle. Cependant, la commande -reply a besoin du fichier de configuration pour fonctionner.

Quand une option de ligne de commande est équivalente à une variable, l'option est toujours prioritaire sur les paramètres du fichier de configuration.

Section tsa, default_tsa: C’est la section principale, qui indique le nom d’une autre section contenant toutes les options pour la commande -reply. Cette section par défaut peut être remplacée par l’option -section en ligne de commande. (Facultatif)
oid_file: Consultez ca(1) pour la description. (Facultatif)
oid_section: Consultez ca(1) pour la description. (Facultatif)
RANDFILE: Consultez ca(1) pour la description. (Facultatif)
serial: Le nom du fichier contenant le numéro de série hexadécimal de la dernière réponse d’horodatage créée. Ce nombre est incrémenté de 1 pour chaque réponse. Si le fichier n'existe pas au moment de la création de réponse d'un nouveau fichier, un nouveau est créé avec le numéro de série 1. (Obligatoire)
crypto_device: Indiquer le moteur OpenSSL qui sera défini par défaut pour tous les algorithmes disponibles. La valeur par défaut est « builtin », vous pouvez indiquer d'autres moteurs pris en charge par OpenSSL (par exemple, utiliser chil pour le HSM nCipher). (Facultatif)
signer_cert: Certificat de signature TSA au format PEM. Identique à l'option -signer en ligne de commande. (Facultatif)
certs: Un fichier contenant un ensemble de certificats encodés PEM qui doivent être inclus dans la réponse. Identique à l'option -chain en ligne de commande. (Facultatif)
signer_key: La clef privée de la TSA au format PEM. Identique à l'option -inkey en ligne de commande. (Facultatif)
default_policy: La politique par défaut à utiliser quand la demande n'exige pas de politique. Identique à -policy en ligne de commande. (Facultatif)
other_policies: Liste des politiques, séparées par des virgules, qui sont aussi acceptables par la TSA et utilisées seulement si la demande indique explicitement l'une d’entre elles. (Facultatif)
digests: La liste des algorithmes de signature de message que la TSA accepte. Au moins un algorithme doit être indiqué. (Obligatoire)
accuracy: La précision de la source de temps de la TSA en seconde, milliseconde et microseconde. Par exemple secs:1, millisecs:500, microsecs:100. Si l'un des composants est manquant, ce champ est supposé nul. (Facultatif)
clock_precision_digits: Indiquer le nombre maximal de chiffres pour représenter la fraction de seconde qui doit être incluse dans champ temporel. Les zéros finaux doivent être supprimés, donc moins de chiffres pourraient être présents ou aucune fraction de seconde du tout. Pris en charge uniquement sur les plate-formes UNIX. La valeur maximale est 6, la valeur par défaut est 0. (Facultatif)
ordering: Si cette option est « yes », les réponses créées par cette TSA peuvent toujours être ordonnées, même si la différence de temps entre deux réponses est inférieure à la somme de leurs précisions. « no » par défaut. (Facultatif)
tsa_name: Si cette option est « yes », le nom d'objet de la TSA doit être inclus dans le champ de noms TSA de la réponse. « no » par défaut. (Facultatif)
ess_cert_id_chain: Les objets SignedData créés par la TSA contiennent toujours l'identifiant de certificat du certificat de signature dans un attribut signé (consultez la RFC 2634, « Enhanced Security Services »). Si cette option est « yes » et que soit la variable certs, soit l'option -chain est indiquée, les identifiants de certificat de la chaîne seront également inclus dans l’attribut SigningCertificate signé. Si cette variable est « no », seul l'identifiant de certificat de signature est inclus. « no » par défaut. (Facultatif)

VARIABLES D'ENVIRONNEMENT

OPENSSL_CONF contient l'emplacement du fichier de configuration et peut être modifiée par l'option -config en ligne de commande.

EXEMPLES

Tous les exemples ci-dessous supposent que OPENSSL_CONF est défini vers un fichier de configuration approprié, comme dans le fichier d'exemple de configuration openssl/apps/openssl.cnf.

Demande d’horodatage

Pour créer une demande d'horodatage pour design1.txt avec SHA-1 sans nonce, avec la politique et sans certificat nécessaire dans la réponse :

  openssl ts -query -data design1.txt -no_nonce \
        -out design1.tsq

Pour créer une demande d'horodatage similaire en indiquant explicitement l’empreinte du message :

  openssl ts -query -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
         -no_nonce -out design1.tsq

Pour afficher le contenu de la requête précédente en format lisible :

  openssl ts -query -in design1.tsq -text

Pour créer une demande d'horodatage qui comprend la signature MD-5 de design2.txt, demande le certificat du signataire et nonce, indique un identifiant de politique (en supposant que le nom tsa_policy1 est défini dans la section OID du fichier de configuration) :

  openssl ts -query -data design2.txt -md5 \
        -policy tsa_policy1 -cert -out design2.tsq

Réponse d’horodatage

Avant de créer une réponse, un certificat de signature doit être créé pour la TSA qui contient l'extension d’utilisation de clef étendue critique timeStamping sans aucune autre extension d'utilisation de clef. Vous pouvez ajouter la ligne « extendedKeyUsage = critical,timeStamping » à la section de certificat utilisateur du fichier de configuration pour créer un certificat approprié. Consultez req(1), ca(1) et x509(1) pour les instructions. Les exemples ci-dessous supposent que cacert.pem contient le certificat de l’autorité de certification, tsacert.pem est le certificat de signature émis par cacert.pem et tsakey.pem est la clef privée de la TSA.

Pour créer une réponse d'horodatage pour une requête :

  openssl ts -reply -queryfile design1.tsq -inkey tsakey.pem \
        -signer tsacert.pem -out design1.tsr

Pour utiliser les paramètres du fichier de configuration :

  openssl ts -reply -queryfile design1.tsq -out design1.tsr

Pour afficher une réponse d’horodatage sur la sortie standard sous forme lisible :

  openssl ts -reply -in design1.tsr -text

Pour créer un jeton d'horodatage au lieu d’une réponse d'horodatage :

  openssl ts -reply -queryfile design1.tsq -out design1_token.der \
        -token_out

Pour afficher un jeton d’horodatage sur la sortie standard sous forme lisible :

  openssl ts -reply -in design1_token.der -token_in -text -token_out

Pour extraire le jeton d'horodatage d'une réponse :

  openssl ts -reply -in design1.tsr -out design1_token.der -token_out

Pour ajouter l’information d’état « granted » (accordé) à un jeton d'horodatage créant ainsi une réponse valable :

  openssl ts -reply -in design1_token.der -token_in -out design1.tsr

Vérification d’horodatage

Pour vérifier une réponse d’horodatage par rapport à une demande :

  openssl ts -verify -queryfile design1.tsq -in design1.tsr \
        -CAfile cacert.pem -untrusted tsacert.pem

Pour vérifier une réponse d’horodatage qui comprend la chaîne de certificats :

  openssl ts -verify -queryfile design2.tsq -in design2.tsr \
        -CAfile cacert.pem

Pour vérifier un jeton d'horodatage par rapport au fichier de données d'origine :

  openssl ts -verify -data design2.txt -in design2.tsr \
        -CAfile cacert.pem

Pour vérifier un jeton d'horodatage par rapport à une empreinte de message :

  openssl ts -verify -digest b7e5d3f93198b38379852f2c04e78d73abdd0f4b \
         -in design2.tsr -CAfile cacert.pem

D’autres exemples sont aussi disponibles dans le répertoire test.

BOGUES

Les bogues et suggestions peuvent être envoyés à Zoltan Glozik <[email protected]>. Une liste des problèmes connus suit.

— Pas de prise en charge d’horodatages par SMTP, mais c’est assez facile de mettre en œuvre une TSA automatique à base de courriers électroniques avec procmail(1) et perl(1). La prise en charge du serveur HTTP est fournie sous forme d'un module Apache séparé. La prise en charge de client HTTP est assurée par tsget(1). Le protocole TCP/IP pur n'est pas pris en charge.
— Le fichier contenant le dernier numéro de série de la TSA n'est pas verrouillé lorsqu'il est lu ou écrit. C’est un problème si plusieurs instances d’openssl(1) tentent de créer une réponse d'horodatage en même temps. Ce n'est pas un problème si le module de serveur Apache est utilisé : il fait un verrouillage correct.
— Recherchez le mot « FIXME » dans les fichiers source.
— Le code source devrait vraiment être examiné par quelqu'un d'autre.
— Plus de tests sont nécessaires, seuls quelques tests de base ont été effectués (consultez test/testtsa).

AUTEUR

Zoltan Glozik <[email protected]>, projet OpenTSA (<http://www.opentsa.org>)

TRADUCTION

La traduction de cette page de manuel est maintenue par les membres de la liste <debian-l10n-french AT lists DOT debian DOT org>. Veuillez signaler toute erreur de traduction par un rapport de bogue sur le paquet manpages-fr-extra.