[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: [Fwd: Re: i have some troubles obtaining the right result with sfl.. pls help..]



For anyone who is interested,
 
The solution for this problem verifying a signedData message that was created with the SFL;  make sure that the signedData is in an ASN.1 type ContentInfo.  The CMS associates a content type identifier with the content.
 
See below for specific details...
 
Sue Beauchamp
DigitalNet 


From: Beauchamp, Sue
Sent: Thursday, October 28, 2004 11:42 AM
To: 'Mihai Badea'
Subject: RE: [Fwd: Re: i have some troubles obtaining the right result with sfl.. pls help..]

RumburaK,
 
I noticed that your message, sfl.cms, is not contentInfo wrapped. 
 
    CSM_Buffer *hau = msgtosign.GetEncodedContentInfo();
    delete hau;

    ((CSM_Buffer *)msgtosign.AccessEncapContentClear())->ConvertMemoryToFile("_SIGNED.tmp");


You deleted it when you called:  delete hau;
 
My first suggestion would be to create a file containing contentInfo wrapped signedData:
 
   hau->ConvertMemoryToFile("_SignedDataMsg.tmp");
   delete hau;
 
Then use _SignedDataMsg.tmp that contains a contentInfo wrapped signedData instead of _SIGNED.tmp.  You can see the contentInfo data in the mozzilla.asn file.  It is missing from the sfl.asn file. 
 

File: \\mihaib\donatii\mozilla.cms

Time: 19:24:11, 10/27/2004

---------------------------------------------------------------------

0 30 NDEF: SEQUENCE {

2 06 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)

13 A0 NDEF: [0] {

A signedData message does not have to have a messageDigest attribute unless there are signed attributes.   You don't have any signedAttributes in the signerInfo portion of the signedData message. 
 
SMP_Check gives an example of how to add signed attributes to a message, see file smp/SMP_Check/sm_checkCreate.cpp.
 
Try working with the contentInfo wrapped signedData message. 
I just received your e-mail with your certificate and code.  Thank you for sending all the data.  I will be running some tests with it now, but I wanted to let you know what I think is the problem so you can continue to work.  
 
Please let me know if this solves your problem or if you need further assistance.  In the meantime, I will be running the tests.
 
Sue Beauchamp



From: Mihai Badea [mailto:mihai.badea@xxxxxxxxxxxxx]
Sent: Thursday, October 28, 2004 4:46 AM
To: Beauchamp, Sue; imc-sfl@xxxxxxxx
Subject: [Fwd: Re: i have some troubles obtaining the right result with sfl.. pls help..]

Dear Sue Beauchamp,

I really apreciate your answer.
I will try to describe here more exactly my problem regarding the use of SFL library in my try to sign an email messge with S/MIME:

It is true that a mail client does not succesfully verify a signed message whom content was altered by editing or other means. That is normal.
But we have 3 diffrent situations here:

    1st:    An email composed and digitally signed with the mail client (i.e. mozilla).
Verifies OK as no modifications were made afterwards.
Mozilla says:
    "This message includes a valid digital signature. The message has not been altered since it was sent."
The example eml file attached is: mozilla-good.eml

    2nd:   An email composed and digitally signed with the mail client, then saved end altered manually by me.
I keep intact the "application/pkcs7-signature" MIME entity, but I randomly modify the body of the MIME entity which was externaly signed. As we would expect, the message does not verify. Though, the signature is still a signature and it can be parsed in order to verify the message. We can study the signer's certificate in a nice dialog box. The only problem is that the signature does not match the content.
Mozilla says:
   "This message includes a digital signature, but the signature is invalid. The signature does not match the message content correctly. The message appears to have been altered after the sender signed it. You shoud not trust the validity of this message until you verify its contents with the sender."
I expect to get at least the same result with the 3rd example (see below), signed by me through SFL.
The example eml attached file is: mozilla-modified.eml

    3rd:    An email edited and signed by me.
I used the correct multipart/signed MIME structure, but instead of a mozilla signature I included a signature created by me with the SFL. Nevermind the content of the message, the signature is invalid and cannot be parsed by the email client.
Mozilla says:
    "This message includes a digital signature, but the signature is invalid. There are unknown problems with this digital signature. You should not trust the validity of this message until you verify its contents with the sender."
The example eml attached file is: sfl-bad.eml

So I studied the differences between the valid signature generated with mozilla and the invalid signature generated with SFL, in ASN1 language.
I used the tool that you indicated me, GUIdumpASN (I also found it searching the net).
I must mention here that I also tried to use the method MsgToSign::AccessEncapContentFromASN1() but every time the process exited writing "Aborted".
Studying the two CMS generated objects in GUIdumpASN I noted that the following code below is present in the valid mozilla generated signature, but absent in the invalid SFL generated signature:

2555 30    9:           SEQUENCE {
2557 06    5:             OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
2564 05    0:             NULL
            :             }
2566 A0  423:           [0] {
2570 30   24:             SEQUENCE {
2572 06    9:               OBJECT IDENTIFIER
            :                 contentType (1 2 840 113549 1 9 3)
2583 31   11:               SET {
2585 06    9:                 OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
            :                 }
            :               }
2596 30   28:             SEQUENCE {
2598 06    9:               OBJECT IDENTIFIER
            :                 signingTime (1 2 840 113549 1 9 5)
2609 31   15:               SET {
2611 17   13:                 UTCTime '041025083404Z'
            :                 }
            :               }
2626 30   35:             SEQUENCE {
2628 06    9:               OBJECT IDENTIFIER
            :                 messageDigest (1 2 840 113549 1 9 4)
2639 31   22:               SET {
2641 04   20:                 OCTET STRING
            :                   25 34 CC 87 FF 95 DE 6A E7 15 17 2C F9 88 A2 D3
            :                   4D 87 22 CA
            :                 }
            :               }
2663 30   82:             SEQUENCE {
2665 06    9:               OBJECT IDENTIFIER
            :                 sMIMECapabilities (1 2 840 113549 1 9 15)
2676 31   69:               SET {
2678 30   67:                 SEQUENCE {
2680 30   10:                   SEQUENCE {
2682 06    8:                     OBJECT IDENTIFIER
            :                       des-EDE3-CBC (1 2 840 113549 3 7)
            :                     }
2692 30   14:                   SEQUENCE {
2694 06    8:                     OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
2704 02    2:                     INTEGER 128
            :                     }
2708 30   13:                   SEQUENCE {
2710 06    8:                     OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
2720 02    1:                     INTEGER 64
            :                     }
2723 30    7:                   SEQUENCE {
2725 06    5:                     OBJECT IDENTIFIER desCBC (1 3 14 3 2 7)
            :                     }
2732 30   13:                   SEQUENCE {
2734 06    8:                     OBJECT IDENTIFIER rc2CBC (1 2 840 113549 3 2)
2744 02    1:                     INTEGER 40
            :                     }
            :                   }
            :                 }
            :               }
2747 30  120:             SEQUENCE {
2749 06    9:               OBJECT IDENTIFIER
            :                 microsoftRecipientInfo (1 3 6 1 4 1 311 16 4)
2760 31  107:               SET {
2762 30  105:                 SEQUENCE {
2764 30   98:                   SEQUENCE {
2766 31   11:                     SET {
2768 30    9:                       SEQUENCE {
2770 06    3:                         OBJECT IDENTIFIER countryName (2 5 4 6)
2775 13    2:                         PrintableString 'ZA'
            :                         }
            :                       }
2779 31   37:                     SET {
2781 30   35:                       SEQUENCE {
2783 06    3:                         OBJECT IDENTIFIER
            :                           organizationName (2 5 4 10)
2788 13   28:                         PrintableString 'Thawte Consulting (Pty) Ltd.'
            :                         }
            :                       }
2818 31   44:                     SET {
2820 30   42:                       SEQUENCE {
2822 06    3:                         OBJECT IDENTIFIER commonName (2 5 4 3)
2827 13   35:                         PrintableString 'Thawte Personal Freemail Issuing CA'
            :                         }
            :                       }
            :                     }
2864 02    3:                   INTEGER 859768
            :                   }
            :                 }
            :               }
2869 30  122:             SEQUENCE {
2871 06   11:               OBJECT IDENTIFIER
            :                 id-aa-encrypKeyPref (1 2 840 113549 1 9 16 2 11)
2884 31  107:               SET {
2886 A0  105:                 [0] {
2888 30   98:                   SEQUENCE {
2890 31   11:                     SET {
2892 30    9:                       SEQUENCE {
2894 06    3:                         OBJECT IDENTIFIER countryName (2 5 4 6)
2899 13    2:                         PrintableString 'ZA'
            :                         }
            :                       }
2903 31   37:                     SET {
2905 30   35:                       SEQUENCE {
2907 06    3:                         OBJECT IDENTIFIER
            :                           organizationName (2 5 4 10)
2912 13   28:                         PrintableString 'Thawte Consulting (Pty) Ltd.'
            :                         }
            :                       }
2942 31   44:                     SET {
2944 30   42:                       SEQUENCE {
2946 06    3:                         OBJECT IDENTIFIER commonName (2 5 4 3)
2951 13   35:                         PrintableString 'Thawte Personal Freemail Issuing CA'
            :                         }
            :                       }
            :                     }
2988 02    3:                   INTEGER 859768
            :                   }
            :                 }
            :               }
            :             }

We can clearly see that important infos such as messageDigest and sMIMEcapabilities are missing from the SFL generated CMS object.
It is surely impossible to verify the content of a signe message with the MD5 digest value missing, which leads me to the fact that the SFL generated CMS object is indeed invalid, perhaps due to a mistake of mine. I am studying intensively the SFL API PDF regarding on how to include the missing code above in the generation of the CMS, but I still can't figure it out.
The CMS objects are attached here as mozilla.cms (mozilla's signature) and sfl.cms (SFL's signature).
I also attached the ASN1 interpretations of  these CMS in the files mozilla.asn and sfl.asn.
I hope this will help you to give me a hint of how to correctly sign a message. I also apologize for the size of this message.
Thank you for your help.

Best regards,
RumburaK


Beauchamp, Sue wrote:
RumburaK/Mihai Badea,
 
Your code example looks good, but it is always good to check the output.  First make sure the CMS message is correct by verifying the CMS message that was built.  See SMP/SMP_Check/sm_checkRead.cpp file on how to set up to verify the cms message that was created.  The verify code starts at about line 99.  
 
You can use the following command to get the ASN.1 binary data to look at in a ASN.1 tool:
 
   ((CSM_Buffer *)msgtosign.AccessEncapContentFromAsn1())->ConvertMemoryToFile("_SIGNED.bin");
 
If you don't have an ASN.1 viewer tool, you can use the free tool from Gemini Security:  http://www.geminisecurity.com/guidumpasn.html

As far as mime is concerned, all it takes is one improper carraige return/linefeed for a message not to verify.    Make sure that you build your mime message correctly.  Maybe the problem is as simple as that. 
 
Please e-mail me if you have any further questions.
 
Sue Beauchamp
BAE Systems  (formerly DigitalNet)
 
 
 

 

From: owner-imc-sfl@xxxxxxxxxxxx [mailto:owner-imc-sfl@xxxxxxxxxxxx] On Behalf Of Mihai Badea
Sent: Tuesday, October 26, 2004 4:41 AM
To: imc-sfl@xxxxxxxx
Subject: i have some troubles obtaining the right result with sfl.. pls help..

 

hello everybody,
i am trying to do simple s/mime operations with e-mail:
sign, verify, encrypt, decrypt - using a valid thawte certificate stored on disc and a password
i am testing the result in mozilla 1.7.3 on a gentoo system
i have compiled latest versions of smp, esnacc and crypto++
it seems that i am having some trouble, as mozilla doesn't read properly the cms  content in s/mime entities.
please help me with one thing:

i am trying to sign a message:

    const char *msg = "Content-Type: text/plain; charset=us-ascii; format=flowed\r\nContent-Transfer-Encoding: 7bit\r\n\r\nbau\r\n";
    const int len = strlen(msg);
    const CSM_Buffer encapcontent(msg, len);
    CSM_MsgToSign msgtosign;
    msgtosign.SetEncapContentClear((const CSM_Buffer &)encapcontent);
    msgtosign.SetIncludeContentFlag(false);
    msgtosign.SetIncludeOrigCertsFlag(true);
    CSM_AppLogin *papplogin = new CSM_AppLogin;
    papplogin->AddLogin("libsm_free3DLL", "sm_free3DLL \"cert.p12\" password");
    if (msgtosign.Sign(papplogin) == SM_NO_ERROR) printf("Signed succesfully.\n");
    CSM_Buffer *hau = msgtosign.GetEncodedContentInfo();
    delete hau;
    ((CSM_Buffer *)msgtosign.AccessEncapContentClear())->ConvertMemoryToFile("_SIGNED.tmp");

the code works ok.. i get the binary output in a file
then i convert the file "_SIGNED.tmp" to base64:
    uuenview -b -o _SIGNED.tmp
then i copy the base64 data to an mime entity in an eml file which i edit by hand
and i insert the whole message into a mozilla local folder (storage file)

if i use:
    msgtosign.SetIncludeContentFlag(true)
then i use application/pcks7-mime signed-data type for the encapsulating mime entity

if i use:
    msgtosign.SetIncludeContentFlag(false)
then i use application/pkcs7-signature in a multipart/signed

i even tried to base64 encode and insert into an email the outputs from the smp test program:
    /SMP_Check/SMP_Check
which is for example:
    TMPFirstSignedDataBinary.dat

again mozilla gave me errors like (signed, but invalid signature, encrypted with unknown method, etc).
though, the messages encrypted with mozilla work even if i edit eml files, decode them, encode again, change mime entities and insert back emails to local folder storage files. in worst cases i get an (signature does not match message error) because the checksum does't match anymore, but i can still view certificate infos etc.

i once decoded a signature from mozilla
and in the same time buid a signature for the same content and certificate
the binary files resulting were diffrent
maybe it would help me if i could compare both of them in asn.1 output to see the differences, but i didn't manage to do this yet

please some one tell me why the way i sign messages is not compatible with mozilla (which i think is the most representative secure mail for linux) or at least some how can i be sure that i am creating the correct cms data.

as a documentation i used the sfl 2.4 api pdf, which isn't quite a practical guide, and the sources in examples. somebody wrote perhaps a tutorial or something? (i would be glad to if i knew better the sfl :)

thank you!!
RumburaK