web-dev-qa-db-fra.com

Format PKCS # 1 et PKCS # 8 pour la clé privée RSA

Quelqu'un peut-il m'aider à comprendre comment une clé RSA est littéralement stockée dans ces formats? Je voudrais connaître la différence entre les formats PKCS et les encodages (DER, PEM). D'après ce que je comprends, PEM est plus lisible par l'homme. PEM/DER pour les clés/certificats est-il similaire à UTF-8/16 pour les caractères? Quelle est la signification de DER/PEM? Désolé trop de questions mais marre de googler et d'obtenir des réponses vagues. Merci.

11
useful

PKCS # 1 et PKCS # 8 (Public-Key Cryptography Standard) sont des normes qui régissent l'utilisation de primitives cryptographiques particulières, du remplissage, etc. Les deux définissent des formats de fichier qui sont utilisés pour stocker des clés, des certificats et d'autres informations pertinentes.

PEM et DER sont un peu plus intéressants. DER est l'encodage ASN.1 pour les clés et les certificats, etc., sur lequel vous pourrez en savoir beaucoup sur Google. Les clés privées et les certificats sont encodés à l'aide de DER et peuvent être enregistrés directement comme ceci. Cependant, ces fichiers sont binaires et ne peuvent pas être copiés et collés facilement, de nombreuses implémentations (sinon la plupart?) Acceptent également les fichiers encodés PEM. PEM est essentiellement un DER encodé en base64: nous ajoutons un en-tête, des métadonnées facultatives et les données DER encodées en base64 et nous avons un fichier PEM.

7
Luke Joshua Park

(Développer plus que je ne pense est approprié pour un montage.)

PKCS1 , disponible en plusieurs versions en tant que rfcs 2313 2437 3447 et 8017 , concerne principalement l'utilisation de l'algorithme RSA pour la cryptographie, y compris le cryptage décryptage signature et vérification. Mais comme la cryptographie est souvent utilisée entre les systèmes ou au moins les programmes, il est pratique d'avoir un format défini et interopérable pour les clés, et PKCS1 définit des formats assez minimaux pour les clés publiques et privées RSA dans l'annexe A.1. Comme Luke l'a laissé entendre, cela utilise ASN.1 codé de manière conventionnelle comme DER , qui est une norme pour le codage interopérable de presque tous les types.

PKCS8 disponible en tant que rfc5208 d'autre part est une norme pour la gestion des clés privées pour tous les algorithmes, pas seulement RSA. Il utilise également ASN.1 DER, et commence par combiner simplement un AlgorithmIdentifier, une structure ASN.1 (première) définie par X.509 qui identifie sans surprise un algorithme, avec un OCTET STRING qui contient une représentation de la clé d'une manière dépendant de l'algorithme. Pour l'algorithme RSA, identifié par un AlgorithmIdentifier contenant un OID qui signifie rsaEncryption, l'OCTET STRING contient le codage de clé privée PKCS1. PKCS8 permet également d'ajouter des "attributs" arbitraires, mais cela est rarement utilisé . (Par exemple Impossible de convertir .jks en .pkcs12: excès de clé privée )

PKCS8 fournit également une option pour crypter la clé privée, en utilisant un cryptage basé sur un mot de passe (en pratique, mais pas explicitement requis). Ceci est courant, en particulier lorsque PKCS8 est utilisé en tant que partie clé privée de PKCS12/PFX, bien qu'il ne soit pas universel.

Étant donné que la plupart des systèmes doivent aujourd'hui prendre en charge plusieurs algorithmes et souhaitent pouvoir s'adapter à de nouveaux algorithmes au fur et à mesure de leur développement, PKCS8 est préféré pour les clés privées et un schéma similaire à n'importe quel algorithme défini par X.509 pour les publickeys. Bien que PKCS12/PFX soit souvent préféré aux deux.

Aucun de ceux-ci n'a quoi que ce soit à voir avec les certificats ou d'autres objets PKI comme les CSR, CRL, OCSP, SCT, etc. Ceux-ci sont définis par d'autres normes, y compris certains autres membres de la série PKCS - bien qu'ils puissent utiliser le définis par ces normes.

Format PEM comme Luke l'a dit est un moyen de formatage, ou (super) encodage, (presque n'importe lequel) des données binaires/DER d'une manière plus pratique . Il découle d'une tentative des années 1990 de sécuriser le courrier électronique nommé Privacy-Enhanced Mail d'où PEM. À cette époque, les systèmes de messagerie pouvaient souvent transmettre, ou du moins de manière fiable, uniquement du texte imprimable avec un jeu de caractères limité et souvent une longueur de ligne limitée, de sorte que les données binaires codées par PEM étaient en base64 avec une longueur de ligne 64. Le schéma PEM lui-même n'était pas réussi et a été remplacé par d'autres comme PGP et S/MIME, mais le format qu'il a défini est toujours utilisé. De nos jours, les systèmes de messagerie électronique - peuvent transmettre des données binaires, mais comme Luke l'a dit, le copier-coller ne peut souvent gérer que les caractères affichés, de sorte que PEM est toujours utile et en outre plus facile à reconnaître pour les humains.

Pour être plus précis, PEM code certaines données, telles que, mais sans s'y limiter, une clé PKCS1 ou PKCS8 ou un certificat, CSR, etc., comme:

  • une ligne composée de 5 tirets, le mot BEGIN, un ou quelques mots (séparés par des espaces) définissant le type de données, et 5 tirets

  • un en-tête facultatif (et rare) de style rfc822, terminé par une ligne vide

  • base64 des données, divisées en lignes de 64 caractères (sauf le dernier); certains programmes utilisent à la place la limite MIME (légèrement plus récente) de 76 caractères

  • une ligne comme la ligne BEGIN mais avec END à la place

Certains lecteurs vérifient/appliquent la longueur de ligne et la ligne de fin et d'autres pas, donc si vous vous trompez, vous pouvez créer des fichiers qui fonctionnent parfois et parfois pas, ce qui est ennuyeux à déboguer.

Ainsi, par exemple, une clé privée PKCS1 (non chiffrée) dans PEM ressemble à:

-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCjcGqTkOq0CR3rTx0ZSQSIdTrDrFAYl29611xN8aVgMQIWtDB/
lD0W5TpKPuU9iaiG/sSn/VYt6EzN7Sr332jj7cyl2WrrHI6ujRswNy4HojMuqtfa
b5FFDpRmCuvl35fge18OvoQTJELhhJ1EvJ5KUeZiuJ3u3YyMnxxXzLuKbQIDAQAB
AoGAPrNDz7TKtaLBvaIuMaMXgBopHyQd3jFKbT/tg2Fu5kYm3PrnmCoQfZYXFKCo
ZUFIS/G1FBVWWGpD/MQ9tbYZkKpwuH+t2rGndMnLXiTC296/s9uix7gsjnT4Naci
5N6EN9pVUBwQmGrYUTHFc58ThtelSiPARX7LSU2ibtJSv8ECQQDWBRrrAYmbCUN7
ra0DFT6SppaDtvvuKtb+mUeKbg0B8U4y4wCIK5GH8EyQSwUWcXnNBO05rlUPbifs
DLv/u82lAkEAw39sTJ0KmJJyaChqvqAJ8guulKlgucQJ0Et9ppZyet9iVwNKX/aW
9UlwGBMQdafQ36nd1QMEA8AbAw4D+hw/KQJBANJbHDUGQtk2hrSmZNoV5HXB9Uiq
7v4N71k5ER8XwgM5yVGs2tX8dMM3RhnBEtQXXs9LW1uJZSOQcv7JGXNnhN0CQBZe
nzrJAWxh3XtznHtBfsHWelyCYRIAj4rpCHCmaGUM6IjCVKFUawOYKp5mmAyObkUZ
f8ue87emJLEdynC1CLkCQHduNjP1hemAGWrd6v8BHhE3kKtcK6KHsPvJR5dOfzbd
HAqVePERhISfN6cwZt5p8B3/JUwSR8el66DF7Jm57BM=
-----END RSA PRIVATE KEY-----

La même clé dans PKCS8 non chiffrée:

-----BEGIN PRIVATE KEY-----
MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAKNwapOQ6rQJHetP
HRlJBIh1OsOsUBiXb3rXXE3xpWAxAha0MH+UPRblOko+5T2JqIb+xKf9Vi3oTM3t
KvffaOPtzKXZauscjq6NGzA3LgeiMy6q19pvkUUOlGYK6+Xfl+B7Xw6+hBMkQuGE
nUS8nkpR5mK4ne7djIyfHFfMu4ptAgMBAAECgYA+s0PPtMq1osG9oi4xoxeAGikf
JB3eMUptP+2DYW7mRibc+ueYKhB9lhcUoKhlQUhL8bUUFVZYakP8xD21thmQqnC4
f63asad0ycteJMLb3r+z26LHuCyOdPg1pyLk3oQ32lVQHBCYathRMcVznxOG16VK
I8BFfstJTaJu0lK/wQJBANYFGusBiZsJQ3utrQMVPpKmloO2++4q1v6ZR4puDQHx
TjLjAIgrkYfwTJBLBRZxec0E7TmuVQ9uJ+wMu/+7zaUCQQDDf2xMnQqYknJoKGq+
oAnyC66UqWC5xAnQS32mlnJ632JXA0pf9pb1SXAYExB1p9Dfqd3VAwQDwBsDDgP6
HD8pAkEA0lscNQZC2TaGtKZk2hXkdcH1SKru/g3vWTkRHxfCAznJUaza1fx0wzdG
GcES1Bdez0tbW4llI5By/skZc2eE3QJAFl6fOskBbGHde3Oce0F+wdZ6XIJhEgCP
iukIcKZoZQzoiMJUoVRrA5gqnmaYDI5uRRl/y57zt6YksR3KcLUIuQJAd242M/WF
6YAZat3q/wEeETeQq1wrooew+8lHl05/Nt0cCpV48RGEhJ83pzBm3mnwHf8lTBJH
x6XroMXsmbnsEw==
-----END PRIVATE KEY-----

et PKCS8 crypté:

-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIC3TBXBgkqhkiG9w0BBQ0wSjApBgkqhkiG9w0BBQwwHAQIkErtXjGCalMCAggA
MAwGCCqGSIb3DQIJBQAwHQYJYIZIAWUDBAEqBBApOUG3MKrBC/5bDBH/s5VfBIIC
gN5o1aJxvJYbp2oA/quz+BnCFn8ts3wPPOcqarHddy0L/VH3BdqFNbnPZEaDnvDl
kqChRsti4AAeX18ItMeAyNLNFv0J4mfI8Q5E7iEnPp+dTsZqNfVIJe2NGxOS7zp2
oQQIZVgjW0akDehv6ZDN796qDBlMY2g80wbBrzVgMJu/byG9IQQjngUE9QNGwrsj
7lYSprxjfTZOk1aGBD0d/HsmetIJvCeJ2i/5xAiGgZRrSWMC6aN7Zlra3eIvHQTB
aKZ8/0IT3iKSr6FpkEopOQae8biiTEVGw9D339P3qOSs2ChWWF+OV2sEA67w6q5j
pz6Poc5jgq4FOcf06GdcVa4tst2uykNJCW0wHpcUR1Tr9ILLhrZPYBYVQWW53Eee
o4+mqW2YORdG3a/jLHpEjL0Vdg95QNpdZoMv8plotN1MUBLebd05aCe5hJUb/x74
3GTwmRGmKoHOhOO3hhUaMCmZIg1xPlNT3jqxrZDoATBeONbaFP8OOkeucVYHbdUO
Ad7z6J8XuZDoxM0BVrGykEiQL2nAOccdsGoC33C9hjkqgU8G9jWElbynJlVqv+1a
lFHWjX5lB6ueiY/rClpVlLmXGB83OVPlo70FV0B9rhRChyB1IJJRYPFDJHSHJNu+
Pqay8zw82Gh/G+TWH/JCLm5YjX55ZSFMUmvwOLaxyQpmAGNH6dIBTAaSctVA7UrV
jm7m+5T7seiNYNEi19vDJipgr0GbX8+np47VrsJDxsS20wTeA/9ltD0xXwNrEKHd
2Nv/1OaCgnBQHIGULgEn9pT3/vU87bBHYjVdrWoUmqd9zFYtdImQE9u8IKTxTe4R
UPRGHqltz4uOjbD1epkSGe0=
-----END ENCRYPTED PRIVATE KEY-----

Observez que le type de données dans chaque fichier (ou autre unité de données) est facilement reconnu à partir des lignes BEGIN/END. Les valeurs de clé réelles dans les données ne sont pas faciles à lire sans outils, bien que seule la troisième ait réellement besoin d'informations secrètes (le mot de passe utilisé pour chiffrer).

33
dave_thompson_085