Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

The "numeric code" is the *exit* status of the program.  You can
find it in "$?" directly after the execution of the command (in
any POSIX shell).

Got it, thanks! Luckily for me, it’s zero. ;-)

> Is there an equivalent, either in openssl tool itself, or in the email
> clients that you know of?

I don't know of any email clients that handle this properly, and I'm
not familiar with the openssl time stamping CLI.  The manpage is at:

https://www.openssl.org/docs/man1.0.2/apps/ts.html
https://www.openssl.org/docs/man1.1.0/apps/ts.html

Thanks!! Will check. 


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Viktor Dukhovni]

> On Apr 6, 2017, at 5:16 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
>> $ openssl cms -verify -verify_retcode -CAfile ~/Certs/Our_Root_CA.pem 
>> -inform SMIME -signer $author -in ~/Documents/test-smime-decr.txt
> 
> I saw no numeric code – but no error either.

The "numeric code" is the *exit* status of the program.  You can
find it in "$?" directly after the execution of the command (in
any POSIX shell).

> Yes, thanks! Done that. Checks out correctly.
> 
>Further issues arise if the data is expected to remain verifiable
>past the lifetime of the signer's certificate.  It that case, it
>should be verified on arrival and re-encrypted for long-term
>storage using an integrity protection mechanism that does not
>depend on the long-term validity of the signer's key.
> 
> This is the trickiest one.
> 
> With Java code signing tool (aka “jarsigner”) I can provide a “digital
> notary” – timestamping authority that would digitally sign a timestamp
> to deal with this “past the lifetime of the signer’s certificate” issue.
> Done with “-tsa https://whatever.timestamping.authority.com”
> 
> Is there an equivalent, either in openssl tool itself, or in the email
> clients that you know of?

I don't know of any email clients that handle this properly, and I'm
not familiar with the openssl time stamping CLI.  The manpage is at:

https://www.openssl.org/docs/man1.0.2/apps/ts.html
https://www.openssl.org/docs/man1.1.0/apps/ts.html

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

> On Apr 6, 2017, at 5:00 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
 
Two problems here, the "Verification successful" message is just a
diagnostic message to "stderr" and should not be considered a
reliable indication of signature validity.  You really should
use the "-verify_retcode" option to ensure that verification
failure leads to a non-zero exit code.


$ openssl cms -verify -verify_retcode -CAfile ~/Certs/Our_Root_CA.pem -inform 
SMIME -signer $author -in ~/Documents/test-smime-decr.txt
. . . . .
--Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3--
Verification successful

I saw no numeric code – but no error either.


Secondly, you would typically care *who* signed the message, and
just that it was signed by some random certificate issued by
a trusted root. 

That’s right. ;-)

Therefore, you should also use the:

author=$(mktemp author.XX)
... -signer $author ...

option to capture the signer's certificate, and then inspect it
somehow (check the subject name or serial number, or ...).

Yes, thanks! Done that. Checks out correctly.


Further issues arise if the data is expected to remain verifiable
past the lifetime of the signer's certificate.  It that case, it
should be verified on arrival and re-encrypted for long-term
storage using an integrity protection mechanism that does not
depend on the long-term validity of the signer's key.

This is the trickiest one.

With Java code signing tool (aka “jarsigner”) I can provide a “digital notary” 
– timestamping authority that would digitally sign a timestamp to deal with 
this “past the lifetime of the signer’s certificate” issue. Done with “-tsa 
https://whatever.timestamping.authority.com”

Is there an equivalent, either in openssl tool itself, or in the email clients 
that you know of?




smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Viktor Dukhovni]

> On Apr 6, 2017, at 5:00 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> But with your help, and providing the top root in the “-CAfile …” argument, I 
> got it!! 
> 
> 
> $ openssl cms -verify -CAfile ~/Certs/Our_Root_CA.pem -inform SMIME -in 
> ~/Documents/test-smime-decr.txt
> Content-Type: multipart/alternative;
>   boundary=Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3
> Content-Transfer-Encoding: 7bit
> 
> 
> --Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3
> Content-Type: text/plain;
>   charset=us-ascii
> . . . . .
> --Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3--
> Verification successful

Two problems here, the "Verification successful" message is just a
diagnostic message to "stderr" and should not be considered a
reliable indication of signature validity.  You really should
use the "-verify_retcode" option to ensure that verification
failure leads to a non-zero exit code.

Secondly, you would typically care *who* signed the message, and
just that it was signed by some random certificate issued by
a trusted root.  Therefore, you should also use the:

author=$(mktemp author.XX)
... -signer $author ...

option to capture the signer's certificate, and then inspect it
somehow (check the subject name or serial number, or ...).

Further issues arise if the data is expected to remain verifiable
past the lifetime of the signer's certificate.  It that case, it
should be verified on arrival and re-encrypted for long-term
storage using an integrity protection mechanism that does not
depend on the long-term validity of the signer's key.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

You really should peruse the cms(1) manpage, daunting as that might be. :-)

Alas, it is! ;-)

> And if I (failing to validate the certificate chain) want to just check
> whether the decrypted message was tampered with – is there a way to do
> that (without validating the certificate chain)?

If a single self-signed certificate is the expected signer, then you
can dispense with all the PKI nonsense and just test for the expected
signer.  With OpenSSL 1.1.0:

   openssl cms -CAfile signer.pem -no-CApath ...

with older versions:

   empty=$(mktemp -d empty.XX)
   openssl cms -CAfile signer.pem -CApath "$empty" ...
   rmdir "$empty"


Well, no – somehow it mistook the Root CA cert for “self-signed”. There 
actually are three levels: Root CA -> Cert-issuing CA -> Signer Cert. I 
verified that all the three certificates are present in that CMS message. So I 
need to either somehow tell openssl that one of those is the root, or point to 
an external PEM file containing the root ca cert copy.

But with your help, and providing the top root in the “-CAfile …” argument, I 
got it!! 


$ openssl cms -verify -CAfile ~/Certs/Our_Root_CA.pem -inform SMIME -in 
~/Documents/test-smime-decr.txt
Content-Type: multipart/alternative;
boundary=Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3
Content-Transfer-Encoding: 7bit


--Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3
Content-Type: text/plain;
charset=us-ascii
. . . . .
--Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3--
Verification successful
$


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Viktor Dukhovni]

> On Apr 6, 2017, at 3:54 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Content-Type: multipart/signed;
> ...


> Hoping that it includes the signing certificate of the signer, I tried to 
> verify its signature by:
> 
> $ openssl cms -verify -inform SMIME -in ~/Documents/test-smime-decr.txt
> Verification failure
> 140735229702224:error:2E099064:CMS 
> routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify 
> error:cms_smime.c:287:Verify error:self signed certificate in certificate 
> chain

You really should peruse the cms(1) manpage, daunting as that might be. :-)

Try:

   author=$(mktemp author.pem.XX)
   data=$(mktemp data.eml.XX)
   openssl cms -verify_retcode -verify -signer $author -CAfile 
/some/ca/certs.pem -out $data || {
rm -f "$author" "$data"
echo "verification failed"
   }
   ...

The original data (sans signature encapsulation) will be in the file named 
"$data".

> How do I find out what certificate chain the signer used? How do I verify
> the signature? If I have a directory that holds files of all the CAs I use,
> is it enough to just give it in “-CApath ${HOME}/my_cert_dir”,

You can use some appropriate combination of -CAfile and -CApath.  Perhaps both,
just in case, to avoid use of default CAfile or CApath, I don't recall whether
cms(1) uses the default file/path.

> or does that directory have to have a special structure (and the certs have to
> be in a certain format)?

No, just standard, unless the keyUsage or extendedKeyUsage bits prohibit use
for emailProtection.

> And if I (failing to validate the certificate chain) want to just check
> whether the decrypted message was tampered with – is there a way to do
> that (without validating the certificate chain)?

If a single self-signed certificate is the expected signer, then you
can dispense with all the PKI nonsense and just test for the expected
signer.  With OpenSSL 1.1.0:

   openssl cms -CAfile signer.pem -no-CApath ...

with older versions:

   empty=$(mktemp -d empty.XX)
   openssl cms -CAfile signer.pem -CApath "$empty" ...
   rmdir "$empty"

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

If the message is signed and then encrypted, you can then check the
signature on the decrypted output. 

This is what the decrypted message looks like (it’s first few lines):

$ head ~/Documents/test-smime-decr.txt
Content-Type: multipart/signed;
boundary=Apple-Mail-D1CE77F5-394F-4A97-918E-2D73904720BC;
protocol="application/pkcs7-signature";
micalg=sha1
Content-Transfer-Encoding: 7bit


--Apple-Mail-D1CE77F5-394F-4A97-918E-2D73904720BC
Content-Type: multipart/alternative;
boundary=Apple-Mail-7BC1697A-2A03-429F-A5F0-817DB6DBCEB3


Hoping that it includes the signing certificate of the signer, I tried to 
verify its signature by:

$ openssl cms -verify -inform SMIME -in ~/Documents/test-smime-decr.txt
Verification failure
140735229702224:error:2E099064:CMS 
routines:CMS_SIGNERINFO_VERIFY_CERT:certificate verify 
error:cms_smime.c:287:Verify error:self signed certificate in certificate chain
$


How do I find out what certificate chain the signer used? How do I verify the 
signature? If I have a directory that holds files of all the CAs I use, is it 
enough to just give it in “-CApath ${HOME}/my_cert_dir”, or does that directory 
have to have a special structure (and the certs have to be in a certain 
format)? In my case they’re a mix of PEM and DER files (with extensions .pem 
and .cer).

And if I (failing to validate the certificate chain) want to just check whether 
the decrypted message was tampered with – is there a way to do that (without 
validating the certificate chain)?

Thanks!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

I have no experience with engines and little interest at present in going 
there.

(

For CMS decryption without engines:

  $ openssl cms -decrypt -recip cert.pem -inkey key.pem -in cms.eml


Thank you!! Decryption succeeded (using the signing key – which the sender 
should not have done).



smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Viktor Dukhovni]

> On Apr 6, 2017, at 2:47 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Would you be able to provide me with a command line that would allow me to
> *decrypt* the message? My keys are on a hardware token, so I’ll have to use
> "–engine pkcs11 –keyform ENGINE"

I have no experience with engines and little interest at present in going there.

For CMS decryption without engines:

  $ openssl cms -decrypt -recip cert.pem -inkey key.pem -in cms.eml

If the message is signed and then encrypted, you can then check the
signature on the decrypted output.  If it is encrypted then signed,
you can check the signature prior to decryption with 'openssl cms -verify'.

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Blumenthal, Uri - 0553 - MITLL]

For S/MIME input:

   $ openssl cms -in cms.eml -cmsout -print

For DER input:

   $ openssl cms -inform DER -in cms.der -cmsout -print


Thank you!!!

The above gave me:

CMS_ContentInfo: 
  contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
  . . . . .
originatorInfo: 
recipientInfos:
  d.ktri: 
version: 
d.issuerAndSerialNumber: 
  issuer: CN=
  serialNumber: 1468961193
keyEncryptionAlgorithm: 
  algorithm: rsaEncryption (1.2.840.113549.1.1.1)
  parameter: NULL
encryptedKey: 
   - bb 14 f6 cc 55 26 86 ca-71 b4 2f 55 11 f0 bb   U&..q./U...
  . . . . . 

It showed me that the serial number of the intended recipient’s cert 
corresponded to the *signing* key and certificate (instead of the encryption 
key/cert). Which is why the legitimate clients refused to decrypt this email.

Would you be able to provide me with a command line that would allow me to 
*decrypt* the message? My keys are on a hardware token, so I’ll have to use 
“–engine pkcs11 –keyform ENGINE”…

Thanks!!


smime.p7s
Description: S/MIME cryptographic signature
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] How to "unwrap" S/MIME messages using openssl?

[Viktor Dukhovni]

> On Apr 6, 2017, at 1:25 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> I’m trying to debug the case of a (bad) email client sending encrypted S/MIME 
> email that the recipient cannot decrypt (we suspect the problem is that the 
> sender chooses a wrong public key/certificate to encrypt to).
>  
> Unfortunately, recipient email clients do not help figuring this out. All 
> they say is “you do not have the right key…”.
>  
> My goal is to “unwrap” the CMS/SMIME message, and print out some identity of 
> the recipient key/cert (anything that would allow me to tie this email to any 
> of the keys I have, or to ascertain that it’s none of those) would help 
> greatly. Printing out other details, such as “algorithms used” would also be 
> helpful.
>  
> I’m sure it’s possible to write an application to do that. But I strongly 
> suspect that the “openssl” command line tool would be able to address this 
> problem. 
>  
> Would somebody on this list please show me how I can print the “metadata” 
> (yes, that big word ☺) of the S/MIME email using openssl?

For S/MIME input:

   $ openssl cms -in cms.eml -cmsout -print

For DER input:

   $ openssl cms -inform DER -in cms.der -cmsout -print

-- 
Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users