Quel algorithme de chiffrement est utilisé dans les certificats protégés par mot de passe * .pfx / PKCS 12?
Comme le titre l'indique, je ne trouve aucune ressource sur laquelle l'algorithme de chiffrement est utilisé dans les certificats * .pfx/PKCS 12 qui sont protégés par mot de passe.
La réponse de Mike Ounsworth est correcte mais incomplète. PKCS # 12 spécifie un format de conteneur mais il spécifie également certains ensembles d'algorithmes qui lui sont propres:
Le schéma de chiffrement PBES1 défini dans PKCS # 5 fournit un certain nombre d'identificateurs d'algorithme pour dériver les clés et les IV; ici, nous en spécifions quelques autres, qui utilisent tous la procédure détaillée dans les annexes B.2 et B.3 pour construire des clés (et IV, si nécessaire). Comme l'indique leur nom, tous les identificateurs d'objet ci-dessous utilisent la fonction de hachage SHA-1.pkcs-12PbeIds OBJECT IDENTIFIER ::= {pkcs-12 1} pbeWithSHAAnd128BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 1} pbeWithSHAAnd40BitRC4 OBJECT IDENTIFIER ::= {pkcs-12PbeIds 2} pbeWithSHAAnd3-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 3} pbeWithSHAAnd2-KeyTripleDES-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 4} pbeWithSHAAnd128BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 5} pbewithSHAAnd40BitRC2-CBC OBJECT IDENTIFIER ::= {pkcs-12PbeIds 6}
Et si vous remarquez de la citation ci-dessus, il mentionne PKCS # 5 pour les algorithmes. PKCS # 5 spécifie deux types d'algorithmes: PBES1 et PBES2.
Les anciens algorithmes PBES1 ne sont qu'une liste d'ensembles d'algorithmes:
pbeWithMD2AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 1}
pbeWithMD2AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 4}
pbeWithMD5AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 3}
pbeWithMD5AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 6}
pbeWithSHA1AndDES-CBC OBJECT IDENTIFIER ::= {pkcs-5 10}
pbeWithSHA1AndRC2-CBC OBJECT IDENTIFIER ::= {pkcs-5 11}
PBES2 vous permet de mélanger et de faire correspondre le chiffrement et les algorithmes PRF séparément (par opposition aux ensembles d'algorithmes prédéfinis). Je vais simplement lister la partie pertinente de la table des matières ici afin que vous puissiez avoir l'idée:
B.1. Pseudorandom Functions . . . . . . . . . . . . . . . . . 28
B.1.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . 28
B.1.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . 29
B.2. Encryption Schemes . . . . . . . . . . . . . . . . . . . 29
B.2.1. DES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . 30
B.2.2. DES-EDE3-CBC-Pad . . . . . . . . . . . . . . . . . . 30
B.2.3. RC2-CBC-Pad . . . . . . . . . . . . . . . . . . . . . 30
B.2.4. RC5-CBC-Pad . . . . . . . . . . . . . . . . . . . . . 31
B.2.5. AES-CBC-Pad . . . . . . . . . . . . . . . . . . . . . 32
De retour à PKCS # 12, il spécifie également algorithmes MAC pour l'ensemble du fichier (pas pour les entrées individuelles):
Ce document utilise un type particulier de MAC appelé HMAC [11] [20], qui peut être construit à partir d'une variété de fonctions de hachage. Notez que les spécifications de [20] et [11] diffèrent quelque peu de celles de [9]. La fonction de hachage sur laquelle HMAC est basée est identifiée dans le MacData, qui contient le MAC; pour cette version de cette norme, la fonction de hachage peut être l'une des suivantes: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 ou SHA-512/256 [ dix].
Les mêmes algorithmes MAC sont également spécifiés dans PKCS # 5:
B.3. Message Authentication Schemes . . . . . . . . . . . . . 33
B.3.1. HMAC-SHA-1 . . . . . . . . . . . . . . . . . . . . . 33
B.3.2. HMAC-SHA-2 . . . . . . . . . . . . . . . . . . . . . 33
Enfin, comme l'indique la réponse de Mike Ounsworth, vous pouvez choisir n'importe quel algorithme de votre choix, même s'il n'est pas dans PKCS # 12 ou PKCS # 5. Cependant, il doit avoir un OID pour être utilisé dans le ASN.1 représentation du fichier p12.
Si vous avez un fichier .pfx spécifique que vous souhaitez vérifier, vous pouvez déterminer quelles méthodes de chiffrement ont été utilisées en utilisant openssl:
openssl pkcs12 -info -in cert.pfx -noout
Cela pourrait vous donner:
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Shrouded Keybag: pbeWithSHA1And3-KeyTripleDES-CBC, Iteration 2048
Cela nécessite que vous connaissiez le mot de passe du fichier .pfx. Si vous ne connaissez pas le mot de passe, vous pouvez toujours trouver la méthode de cryptage la plus externe en utilisant:
openssl pkcs12 -info -in cert.pfx -nomacver -noout -passin pass:unknown
Cela donne, par exemple:
PKCS7 Encrypted data: pbeWithSHA1And40BitRC2-CBC, Iteration 2048
Ce fichier de certificat particulier a été généré par openssl avec des paramètres par défaut et ressemble à:
- Une couche de cryptage externe utilisant RC2 40 bits avec SHA-1. La couche de cryptage externe contient le certificat.
- Une couche de cryptage interne utilisant 3DES avec SHA-1. La couche de cryptage interne contient la clé privée.
Je pense que cela n'est pas sûr, car un attaquant peut casser le cryptage le plus à l'extérieur avec une force brute facile (le cryptage 40 bits plus RC2 a diverses vulnérabilités), puis utiliser le même mot de passe sur la couche de cryptage interne. Cependant, cela mérite probablement une enquête supplémentaire.
Toutes les spécifications pour le format PKCS # 12 sont définies dans RFC7292 .
Le bref résumé est qu'un .p12 fichier (et je suppose aussi que l'ancien format PFX de Microsoft, mais je n'ai jamais travaillé avec eux) est juste un format de conteneur qui spécifie la structure de ce fichier, mais ne dit rien sur le type de données qui doit aller dans ça.
Pour utiliser une très mauvaise analogie, la spécification de Microsoft Excel .xlsx format spécifie la structure d'un fichier de sauvegarde Excel, mais ne vous dit rien sur les données ou les formules qu'il est autorisé à contenir; qui est contrôlé par la version d'Excel que vous utilisez.
Si vous deviez ouvrir un .p12 dans un éditeur hexadécimal, vous constaterez que l'un des champs de l'en-tête est AlgorithmIdentifier: _____ où le programme qui a créé le .p12 enregistre A) quel algorithme de cryptage a été utilisé pour crypter les données, et B) quel algorithme de hachage a été utilisé pour transformer le mot de passe en clé. Pour autant que je sache, il n'y a pas de liste définitive de ce qui est autorisé ici; le programme créant le .p12 peut utiliser tout AlgorithmIdentifier qu'il veut, y compris en créer un.
Par exemple, si j'écrivais un logiciel pour lire et écrire un mot de passe protégé .p12 fichiers, je pourrais définir AlgorithmIdentifier: AES256WithPBKDF2 et ce serait bien. Mais je pourrais également définir AlgorithmIdentifier: MikesCipherWithCatDoodles, et tant que le logiciel à l'autre bout sait quoi faire avec ça, ça va toujours.
TL; DR: Le format PKCS # 12 spécifie uniquement la structure du fichier, il ne répertorie pas les algorithmes légaux, donc l'algorithme de cryptage réel utilisé dépendra du logiciel utilisé pour créer le .p12 fichier.
Si vous voulez savoir quels algorithmes sont utilisés pour protéger votre .p12 fichiers, recherchez de la documentation sur le logiciel que vous utilisez pour les lire/écrire.
Comme cela a été nécroisé, pour être complet: OpenSSL peut analyser un fichier PKCS12, en plusieurs étapes, pour trouver les informations sur les algorithmes utilisés, sans le mot de passe. Par exemple:
$ openssl req -newkey rsa:1024 -nodes -keyout se152866.key -x509 -subj /CN=example.net -out se152866.crt
$ openssl pkcs12 -export -in se152866.crt -inkey se152866.key -passout pass:sekrit -out se152866.p12
$ openssl asn1parse -inform der -in se152866.p12 -i
0:d=0 hl=4 l=1521 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :03
7:d=1 hl=4 l=1463 cons: SEQUENCE
11:d=2 hl=2 l= 9 prim: OBJECT :pkcs7-data
22:d=2 hl=4 l=1448 cons: cont [ 0 ]
26:d=3 hl=4 l=1444 prim: OCTET STRING [HEX DUMP]:(long,omitted)
1474:d=1 hl=2 l= 49 cons: SEQUENCE
1476:d=2 hl=2 l= 33 cons: SEQUENCE
1478:d=3 hl=2 l= 9 cons: SEQUENCE
1480:d=4 hl=2 l= 5 prim: OBJECT :sha1
1487:d=4 hl=2 l= 0 prim: NULL
1489:d=3 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:8B3C863D73B51E41CADC9272E1696740B885E69E
1511:d=2 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:5992FE887D9EA8A3
1521:d=2 hl=2 l= 2 prim: INTEGER :0800
En comparant cela à l'ASN.1 pour PFX externe dans PKCS12 sec 4 et 4.1 nous voyons que le 'authSafe' est codé dans la valeur de l'élément OCTET STRING au décalage 26 avec la longueur d'en-tête (hl) 4 donner 30. Ignorer le (PB) MAC et regarder cela:
$ openssl asn1parse -inform der -in se152866.p12 -i -strparse 30
0:d=0 hl=4 l=1440 cons: SEQUENCE
4:d=1 hl=4 l= 671 cons: SEQUENCE
8:d=2 hl=2 l= 9 prim: OBJECT :pkcs7-encryptedData
19:d=2 hl=4 l= 656 cons: cont [ 0 ]
23:d=3 hl=4 l= 652 cons: SEQUENCE
27:d=4 hl=2 l= 1 prim: INTEGER :00
30:d=4 hl=4 l= 645 cons: SEQUENCE
34:d=5 hl=2 l= 9 prim: OBJECT :pkcs7-data
45:d=5 hl=2 l= 28 cons: SEQUENCE
47:d=6 hl=2 l= 10 prim: OBJECT :pbeWithSHA1And40BitRC2-CBC
59:d=6 hl=2 l= 14 cons: SEQUENCE
61:d=7 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:2333FBA5F3B3DCC8
71:d=7 hl=2 l= 2 prim: INTEGER :0800
75:d=5 hl=4 l= 600 prim: cont [ 0 ]
679:d=1 hl=4 l= 761 cons: SEQUENCE
683:d=2 hl=2 l= 9 prim: OBJECT :pkcs7-data
694:d=2 hl=4 l= 746 cons: cont [ 0 ]
698:d=3 hl=4 l= 742 prim: OCTET STRING [HEX DUMP]:(long,omitted)
nous voyons deux ContentInfo - un à l'offset 4 dans authSafe (34 dans le fichier) qui est crypté par mot de passe avec pbeWithSHA1And40BitRC2-CBC et le sel montré et les itérations 2048, et un à l'offset 679 (709) qui n'est pas crypté à ce niveau . Il faudrait décrypter le premier pour déterminer définitivement son type, mais je sais que pbe-RC2-40 est toujours utilisé pour les certbags, et il se trouve que c'est la taille correcte pour mon (exemple) cert. Pour le second, nous pouvons décoder sa partie contenu à 702 (732) un autre niveau pour obtenir SEQUENCE of SafeBag :
$ openssl asn1parse -inform der -in se152866.p12 -i -strparse 732
0:d=0 hl=4 l= 738 cons: SEQUENCE
4:d=1 hl=4 l= 734 cons: SEQUENCE
8:d=2 hl=2 l= 11 prim: OBJECT :pkcs8ShroudedKeyBag
21:d=2 hl=4 l= 678 cons: cont [ 0 ]
25:d=3 hl=4 l= 674 cons: SEQUENCE
29:d=4 hl=2 l= 28 cons: SEQUENCE
31:d=5 hl=2 l= 10 prim: OBJECT :pbeWithSHA1And3-KeyTripleDES-CBC
43:d=5 hl=2 l= 14 cons: SEQUENCE
45:d=6 hl=2 l= 8 prim: OCTET STRING [HEX DUMP]:F75E440A3D7429C7
55:d=6 hl=2 l= 2 prim: INTEGER :0800
59:d=4 hl=4 l= 640 prim: OCTET STRING [HEX DUMP]:(long,omitted)
703:d=2 hl=2 l= 37 cons: SET
705:d=3 hl=2 l= 35 cons: SEQUENCE
707:d=4 hl=2 l= 9 prim: OBJECT :localKeyID
718:d=4 hl=2 l= 22 cons: SET
720:d=5 hl=2 l= 20 prim: OCTET STRING [HEX DUMP]:644ED94520BF6A45B81C70F73AE2143DE123A620
que nous pouvons voir est un pkcs8ShroudedKeyBag qui à son tour est un EncryptedPrivateKeyInfo de PKCS8 et contient la clé privée chiffrée avec pbeWithSHA1And3-KeyTripleDES-CBC et le sel montré et 2048 itérations, plus un PKCS12Attribute, localKeyID.
Comme indiqué précédemment,
le format PKCS # 12 ne spécifie que la structure du fichier
Il peut donc être chiffré avec l'un des algorithmes suivants, selon la norme:
- 128 bits RC4 avec SHA1
- RC4 40 bits avec SHA1
- 3 clés 3DES avec SHA1 (168 bits)
- 2 clés 3DES avec SHA1 (112 bits)
- 128 bits RC2 avec SHA1
- RC2 40 bits avec SHA1
Mais, comme Mike Ounsworth l'a mentionné précédemment, il peut également s'agir de n'importe quel algorithme personnalisé.