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

Question

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.

Luke Joshua Park · Accepted Answer

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.

dave_thompson_085 · Answer

(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 à:

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

et PKCS8 crypté:

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).