Résumé

  • RFC 9879 introduit PBMAC1 dans PKCS #12, impose un socle PBKDF2/HMAC-SHA-256 et rectifie l’encodage du mot de passe décrit par RFC 9579.
  • La compatibilité peut laisser un ancien lecteur atteindre les clés chiffrées après un contrôle MAC non compris, tandis que mot de passe et paramètres KDF peuvent rester faibles.
  • Une migration défendable conserve séparément paramètres effectifs, résultat du contrôle, politique d’échec et destination de la clé.

PKCS #12 transporte des certificats, des clés privées et d’autres secrets entre plates-formes. Dire qu’un fichier est « pris en charge » ne précise pourtant ni ce qui a été lu, ni ce qui a été vérifié. La syntaxe peut être reconnue, le contenu chiffré peut être ouvert, le MAC peut être correct, les paramètres peuvent respecter la politique locale et la clé peut finir dans le bon dispositif de garde. Ce sont cinq états, pas un seul.

RFC 9879 traite l’état d’intégrité. Publié en septembre 2025 comme RFC IETF de catégorie Information, il rend RFC 9579 obsolète et modifie RFC 7292 et RFC 8018. L’identifiant id-PBMAC1 devient un type autorisé dans le DigestAlgorithmIdentifier de PKCS #12. S’il est choisi, ses paramètres doivent être présents et cohérents, et le résultat doit être calculé sur authSafe suivant ces paramètres.

Le progrès vient de l’extensibilité. L’ancienne dérivation propre à PKCS #12 ne permettait essentiellement que de changer la fonction de hachage. PBMAC1 sépare la fonction de dérivation de la fonction d’authentification. Tout lecteur conforme doit prendre en charge PBKDF2 avec HMAC-SHA-256 pour le MAC et pour la fonction pseudo-aléatoire de PBKDF2. D’autres HMAC SHA-2 sont recommandés ; scrypt et d’autres choix peuvent être proposés.

Cette liberté rend l’inspection des paramètres indispensable. La longueur de clé dérivée doit être explicite. Une structure PBKDF2 dépourvue de keyLength doit être refusée ; avec HMAC-SHA-256, la longueur attendue est de 32 octets. PBKDF2 avec HMAC-SHA-1 est déconseillé et les autres condensats de 160 bits ou moins sont interdits.

Une difficulté d’audit se cache dans les anciens champs. Quand PBMAC1 est utilisé, les valeurs externes macSalt et iterations doivent être ignorées. Elles devraient néanmoins rester non vide et positive pour la compatibilité. Une console qui affiche l’ancienne itération comme preuve d’effort cryptographique peut donc montrer une valeur sans rapport avec le calcul réellement effectué dans PBMAC1-params.

La transition est volontairement asymétrique. RFC 9879 explique que la nouvelle syntaxe doit permettre à une application ancienne de déchiffrer encore le matériel de clé lorsqu’elle ne sait pas interpréter la nouvelle protection, à condition qu’elle puisse ignorer l’échec de vérification du MAC. Cette propriété évite qu’une modernisation d’enveloppe condamne immédiatement tout ancien lecteur. Elle crée aussi une frontière nette entre accessibilité et intégrité. Aucun produit n’est nommé comme ayant ce comportement ; il faut l’observer, non le supposer.

L’encodage du mot de passe fournit un cas rare où les octets d’exécution ont corrigé le texte. RFC 9579 demandait une BMPString terminée par NULL. L’erratum technique vérifié 7974 a établi que l’implémentation ayant produit les vecteurs avait laissé le mot de passe en UTF-8. RFC 9879 exige désormais l’UTF-8 sans terminaison NULL ni marque d’ordre des octets. Le nom du mot de passe ne suffit donc pas à comparer deux systèmes : il faut conserver les octets remis à la KDF.

Les vecteurs de test bornent la conformité. Des cas valides couvrent plusieurs combinaisons SHA-256 et SHA-512 ; des cas invalides modifient l’itération, le sel ou retirent la longueur de clé. Les réussir prouve le comportement de calcul visé. Cela ne prouve pas que les secrets choisis par les utilisateurs résistent à une recherche hors ligne, qu’un seuil local rejette les paramètres faibles, ni que l’importation préserve la garde de la clé.

Le document avertit qu’une KDF peut produire une clé réduite à un octet et que les paramètres de KDF ne sont pas eux-mêmes protégés cryptographiquement. Une sortie minuscule facilite la recherche exhaustive du HMAC. RFC 9879 recommande de rejeter les longueurs inférieures à 20 octets et autorise le rejet d’autres paramètres faibles. Cette possibilité doit devenir une règle locale explicite.

RFC 8018 rappelle la limite structurelle : une construction fondée sur un mot de passe permet une recherche hors ligne. Sel et itérations augmentent le coût ; ils n’ajoutent pas l’entropie que le mot de passe ne possède pas. Scrypt vise à réduire l’avantage du matériel massivement parallèle par un coût mémoire, mais RFC 9879 n’impose pas sa prise en charge. L’étiquette PBMAC1 ne décrit donc pas une force unique.

La preuve d’importation doit suivre l’ordre réel : conteneur reçu, versions identifiées, algorithme et paramètres effectifs extraits, politique de paramètres satisfaite, octets du mot de passe établis, MAC correct, déchiffrement séparément réussi, usage autorisé, clé placée dans une garde nommée, comportement de réexportation vérifié. Une étape inconnue ne doit pas être coloriée en vert par la suivante.

Sources