Content-type: text/html Manpage of PKCS8

PKCS8

Section: OpenSSL (1)
Updated: 0.9.6c
Index Return to Main Contents
 

NOM

pkcs8 - utilitaire de conversion de clé privée PKCS#8  

SYNOPSIS

openssl pkcs8 [-topk8] [-inform PEM|DER] [-outform PEM|DER] [-in nomfichier] [-passin arg] [-out nomfichier] [-passout arg] [-noiter] [-nocrypt] [-nooct] [-embed] [-nsdb] [-v2 alg] [-v1 alg]  

DESCRIPTION

La commande pkcs8 interprète les clés privées au format PKCS#8. Elle traite aussi bien le format PKCS#8 non encodé PrivateKeyInfo et EncryptedPrivateKeyInfo, avec certains algorithmes PKCS#5 (v1.5 et v2.0) et PKCS#12.  

OPTIONS DE A COMMANDE


-topk8
Par défaut, une clé privée PKCS#8 est attendue à l'entrée et une clé privée au format traditionnel est écrite. Avec l'option -topk8, la situation est inversée : une clé privée au format traditionnel est lue et une clé au format PKCS#8 sera écrite.
-inform DER|PEM
Ceci spécifie le format d'entrée. Si une clé au format PKCS#8 est attendue à l'entrée, une version encodée DER ou PEM de la clé PKCS#8 est attendue. Autrement, une clé privée au format traditionnel encodée DER ou PEM est prise.
-outform DER|PEM
Ceci spécifie le format de sortie. Les options sont interprétées de la même manière que pour l'option -inform.
-in nomfichier
Ceci spécifie le nom du fichier d'entrée à partir duquel la clé est lue, ou l'entrée standard si cette option est omise. Si la clé est encodée, une phrase de passe sera demandée.
-passin arg
Le fichier d'entrée source de mots de passe. Pour de plus amples informations sur le format de l' arg voir la section ARGUMENTS DE MOT DE PASSE d'openssl(1).
-out nomfichier
Ceci spécifie le nom de fichier de sortie où la clé sera écrite ou la sortie standard par défaut. Si des options d'encodage sont spécifiées, alors une phrase de passe sera demandée. Le nom de fichier de sortie ne doit pas être le même que le nom de ficheir d'entrée.
-passout arg
Le fichier de sortie source de mots de passe. Pour de plus amples informations sur le format de l' arg voir la section ARGUMENTS DE MOT DE PASSE d'openssl(1).
-nocrypt
Les clés PKCS#8 générées ou reçues en entrée sont normalement une structure PKCS#8 EncryptedPrivateKeyInfo et utilisent un algorithme d'encodage du mot de passe approprié. Avec cette option, une structure PrivateKeyInfo claire est attendue ou générée. Cette option n'encode pas les clés privées et devrait être utilisée uniquement si c'est nécessaire. Certains programmes comme certaines versions de logiciel certifiant du code Java utilisaient des clés privées claires.
-nooct
Cette option génère une clé privée RSA dans un format déprécié que certains programmes utilisent. Plus spécifiquement, une clé privée doit être entourée par un OCTET STRING mais certains programmes incluent la structure même sans ce OCTET STRING autour.
-embed
Cette option génère une clé privée DSA dans un format déprécié que certains programmes utilisent. Plus spécifiquement, une clé privée doit être entourée par un OCTET STRING mais certains programmes incluent la structure même sans ce OCTET STRING autour.
-nsdb
Cette option génère des clés DSA dans un format déprécié compatible avec les bases de données de clés privées Netscape. La structure PrivateKey contient une SEQUENCE comprenant les clés publiques et privées respectivement.
-v2 alg
Cette option active l'utilisation des algorithmes PKCS#5 v2.0. Habituellement les clés privées sont encodées avec un algorithme à base de mots de passe nommé pbeWithMD5AndDES-CBC qui utilisent un encodage DES à 56 bits mais c'était l'algorithme d'encodage le plus fort pris en charge par PKCS#5 v1.5. En utilisant l'option -v2, des algorithmes PKCS#5 v2.0 sont utilisées qui peuvent utiliser tout algorithme d'encodage comme triple DES à 168 bits ou encore RC2. Toutefois peu d'implémentations supportent PKCS#5 v2.0 à ce jour. Si vous utilisez des clés privées uniquement avec OpenSSL, ceci n'importe pas.

L'argument alg est l'algorithme d'encodage à utiliser, qui peuvent être entre autres des, des3 et rc2. L'utilisation de des3 est recommandé.

-v1 alg
Cette option spécifie l'algorithme PKCS#5 v1.5 ou PKCS#12 à utiliser. Une liste complète des algorithmes possibles est incluse ci-dessous.
 

NOTES

La version encodée PEM d'un fichier PKCS#8 utilise les en-têtes et pieds de page suivants :

 -----BEGIN ENCRYPTED PRIVATE KEY-----
 -----END ENCRYPTED PRIVATE KEY-----


La version non encodée utilises:

 -----BEGIN PRIVATE KEY-----
 -----END PRIVATE KEY-----


Les clés privées utilisant des algorithmes PKCS#5 v2.0 avec un nombre d'itérations élévées sont plus sûres que celle utilisant les formats traditionnels compatible SSLeay. Ainsi, si on considère importante cette sécurité supplémentaire, les clés devraient être converties.

L'encodage par défaut est de seulement 56 bits car c'est l'encodage que la plupart des implémentations récentes gèrent.

Certains logiciels utilisent des algorithmes PKCS#12 d'encodage à base de mots de passe avec des clés privées au format PKCS#8 : celles-ci sont gérées automatiquement, mais il n'existe pas d'option pour les produire.

Il est possible d'écrire des clés privées encodées au format PKCS#8 car les détails de l'encodage sont inclus au niveau ASN1 alors que le format traditionnel les inclut au niveau PEM.  

Les algorithmes PKCS#5 v1.5 et PKCS#12.

Certains algorithmes peuvent être utilisés avec l'option -v1, y compris PKCS#5 v1.5 et PKCS#12. Ils sont décrit d'avantage ci-dessous.
PBE-MD2-DES PBE-MD5-DES
Ces algorithmes sont inclus dans la spécification PKCS#5 v1.5 originale. Ils offrent seulement 56 buts de protection comme ils utilisent le DES tous les deux.
PBE-SHA1-RC2-64 PBE-MD2-RC2-64 PBE-MD5-RC2-64 PBE-SHA1-DES
Ces algorithmes ne sont pas mentionnés dans la spécification originale PKCS#5 v1.5 mais ils utilisent le même algorithme de dérivation de la clé et sont gérés par quelques logiciels. Ils ont été cités dans PKCS#5 v2.0 et utilisent soit un RC2 à 64 bit soit un DES à 56 bit.
PBE-SHA1-RC4-128 PBE-SHA1-RC4-40 PBE-SHA1-3DES PBE-SHA1-2DES PBE-SHA1-RC2-128 PBE-SHA1-RC2-40
Ces algorithmes utilisent l'algorithme d'encodage à base de mots de passe PKCS#12 et permettent l'utilisation des algorithmes d'encodage fort comme le triple DES ou le RC2 à 128 bits.
 

EXEMPLES

Conversion d'une clé privée du format traditionnel vers PKCS#5 v2.0 en utilisant le triple DES :

 openssl pkcs8 -in key.pem -topk8 -v2 des3 -out enckey.pem


Conversion d'une clé privée PKCS#8 en utilisant un algorithme compatible PKCS#5 1.5 (DES) :

 openssl pkcs8 -in key.pem -topk8 -out enckey.pem


Conversion d'une clé privée vers PKCS#8 utilisant un algorithme compatible PKCS#12 (3DES) :

 openssl pkcs8 -in key.pem -topk8 -out enckey.pem -v1 PBE-SHA1-3DES


Lire une clé privée DER claire au format PKCS#8:

 openssl pkcs8 -inform DER -nocrypt -in key.der -out key.pem


Conversion d'une clé privée d'un format PKCS#8 quelconque vers le format traditionnel :

 openssl pkcs8 -in pk8.pem -out key.pem


 

STANDARDS

Des jeux de test de cette implémentation de PKCS#5 v2.0 ont été postés sur la liste pkcs-tng en utilisant triple DES, DES et RC2 avec un nombre d'itérations élevé. Certains personnes ont confirmé qu'ils pouvaient décrypter les clés privées produites et ainsi on peut supposer que l'implémentation PKCS#5 v2.0 est suffisamment correcte au moins concernant ces algorithmes.

Le format des clés privées PKCS#8 DSA (entre autres) n'est pas bien documenté, étant caché dans PKCS#11 v2.01, section 11.9. Le format par défaut d'OpenSSL pour les clés privées respecte ce standard.  

BOGUES

Il devrait y avoir une option qui affiche l'algorithme d'encodage utilisé et d'autres détails comme le nombre d'itérations.

Le format par défaut des clés privées pour OpenSSL devrait être PKCS#8 avec triple DES et PKCS#5 v2.0. Pour assurer la compatibilité avec quelques-uns des utilitaires, l'ancien format est maintenu actuellement.  

VOIR AUSSI

dsa(1), rsa(1), genrsa(1), gendsa(1)


 

Index

NOM
SYNOPSIS
DESCRIPTION
OPTIONS DE A COMMANDE
NOTES
Les algorithmes PKCS#5 v1.5 et PKCS#12.
EXEMPLES
STANDARDS
BOGUES
VOIR AUSSI

This document was created by man2html, using the manual pages.
Time: 20:41:59 GMT, July 10, 2005