EnvelopedCMS avec AES et rsaEncryption (remplissage PKCS # 1 v1.5 au lieu du remplissage v2 (OAEP)) possible?

J’utilise un peu. NET à des fins cryptographiques. Jusqu’à présent, j’utilisais 3DES (ID 1.2.840.113549.3.7) en combinaison avec rsaEncryption (ID 1.2.840.113549.1.1.1, RSAES-PKCS1-v1_5). Alors que le premier doit maintenant être remplacé par AES (ID 2.16.840.1.101.3.4.1.42), je dois toujours utiliser rsaEncryption / RSAES-PKCS1-v1_5 , et non RSAES-OAEP .

Si je passe juste un argument supplémentaire au constructeur EnvelopedCMS que j’appelle, je peux passer de 3DES à AES:

ContentInfo plainContent = new ContentInfo(new Oid("1.2.840.113549.1.7.1"), data); EnvelopedCms encryptedMessage = new EnvelopedCms(plainContent); // using 3DES // EnvelopedCms encryptedMessage = new EnvelopedCms(plainContent, new AlgorithmIdentifier(new Oid("2.16.840.1.101.3.4.1.42"))); // for AES (id-aes256-CBC) CmsRecipient recipient = new CmsRecipient(cert); encryptedMessage.Encrypt(recipient); byte[] encryptedBytes = encryptedMessage.Encode();

C’est bien jusqu’à présent. Malheureusement, certains destinataires ne peuvent pas déchiffrer mes messages, même s’ils sont capables de déchiffrer AES. L’examen de la structure ASN.1 m’indique que non seulement 3DES a été remplacé par AES, mais que rsaEncryption (1.2.840.113549.1.1.1) a été remplacé par RSAES-OAEP (1.2.840.113549.1.1.7). Puis-je forcer à utiliser RSAES-PKCS1-v1_5 avec EnvelopedCMS? Ou voyez-vous un autre problème dans la commutation 3DES-> AES?

Éditer: au cas où je ne pourrais pas changer le remplissage aussi facilement en v1.5, quelles autres options ai-je? Appel manuel de CryptoServiceProviders et création de l’enveloppe PKCS # 7 par moi-même? Y a-t-il des manières plus élégantes?

Le .NET Framework EnvelopedCms est construit sur les fonctions Windows CAPI CryptMsg *. CryptMsgOpenToEncode prend en charge deux méthodes d’encodage des destinataires, l’une d’elles étant conditionnellement compilée (bien que je n’ai pas été en mesure de déterminer quand elle n’est pas disponible; j’imagine que c’est un problème entre Win9x et NT4 / WinXP compat).

Sur un coup de tête, j’ai regardé pour voir ce qui pourrait basculer pour utiliser l’autre chemin de code, et si cela changerait votre résultat ici. Oui, si on utilise en interne “useCms”, l’algorithme de chiffrement du destinataire est 1.2.840.113549.1.1.1.

Option 1) Utiliser l’identification SubjectKeyIdentifier

Si vous interagissez avec un autre système, comme c’est le cas ici, assurez-vous que le certificate a une extension SubjectKeyIdentifier explicite avant d’utiliser ce formulaire d’identification. .NET / Windows constituera une valeur implicite s’il n’y en a pas de manière explicite et si toutes les implémentations de CMS ne correspondent pas au certificate du destinataire dans ce cas (par exemple, OpenSSL).

Vous accomplissez ceci en changeant votre CmsRecipient en

 CmsRecipient recipient = new CmsRecipient(SubjectIdentifierType.SubjectKeyIdentifier, cert);

Option 2) Ajouter un atsortingbut non protégé

EnvelopedCms permet à d’autres métadonnées d’être ajoutées au message sans chiffrement. Si vous spécifiez l’une de ces valeurs, l’encryptor / encoder utilise l’autre chemin de code.

Avant d’appeler Encrypt add

 // Pkcs9DocumentName requires a non-empty ssortingng. // You can use any AsnEncodedData value, though. encryptedMessage.UnprotectedAtsortingbutes.Add(new Pkcs9DocumentName("a"));

Chacun de ceux-ci a travaillé dans des tests locaux.