Re: Help!! BC crafted PKCS7/CMS envelope verification by OpenSSL
[email protected] Fri, 14 Dec 2018 18:34:12 -0500
| Newsgroups | gmane.comp.encryption.bouncy-castle.devel |
|---|---|
| Message-ID | <[email protected]> |
> We were using the following code snippet for signing and crafting the PKCS7 > files., > ... > envelopedData = sigData.getEncoded(); Aside: calling P7/CMS SignedData 'enveloped' can be misleading. P7/CMS, and derivatively SMIME, use 'Enveloped' to mean _encrypted_ data, usually hybrid-publickey encryption to recipient(s) using certs. > The final Base64 encoded envelope persisted into the file. Later, When i > tried to verify the signature by using the following command; > $ openssl cms -verify -noverify -inform PEM -in new.p7s > Verification successful > madan prabhu nic tamilnadu state unit > > For attached signature; it works fine. Same thing for the detached > signature; it's not working. > $openssl cms -verify -noverify -inform PEM -in newd.p7s -content > newd.txt > madan prabhu nic tamilnadu state unit > Verification failure > 140109147780928:error:2E09A09E:CMS > routines:CMS_SignerInfo_verify_content:verification > failure:crypto/cms/cms_sd.c:821: > 140109147780928:error:2E09D06D:CMS routines:CMS_verify:content verify > error:crypto/cms/cms_smime.c:393: > > The content of the file newd.txt is exactly same data. > Does the file contain text with Unix-style line terminator(s) LF and not Internet (and Windows) style CRLF? Or data with lone LF bytes? OpenSSL 'cms' (and also older 'smime') tries very weakly to do the canonicalization specified by SMIME (RFC5751 3.1.1 et pred) namely it converts all line endings to CRLF -- regardless of content-type and regardless of whether it's actually doing SMIME (-outform/inform smime) or PKCS7/CMS (-outform/inform der/pem) ... ... unless you specify -binary ; see the man page. Without that, for embedded data verify assumes the canonicalization has already been done and just uses the transmitted data, and succeeds, but for separate data (detached signature) it assumes canonicalization is needed to match the sender and does it, thus the data it (hashes and) tries to verify is not the same data you signed, causing verify fail.