W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2000

RE: encryption in XML & in SMIME

From: Ed Simon <ed.simon@entrust.com>
Date: Thu, 21 Sep 2000 09:45:54 -0400
Message-ID: <3120721CA75DD411B8340090273D20B10C1BDF@sottmxs06.entrust.com>
To: "'PJM Veugen'" <Veugen@fel.tno.nl>
Cc: Don Davis <dtd@world.std.com>, xml-encryption@w3.org
Yes, I think you are right.  

To avoid the second signing, one could (as you suggest) include 
the <From> element as input to the digest of the message to be 
encrypted.  This could be done using XML Signature's Transform 
facility.  

Let me know what you you think.  It is very beneficial to know that
someone is actually writing code around this topic rather than just
approaching it as a thought problem.

Ed
-----Original Message-----
From: PJM Veugen [mailto:Veugen@fel.tno.nl]
Sent: Thursday, September 21, 2000 4:51 AM
To: Ed Simon
Cc: Don Davis; xml-encryption@w3.org
Subject: Re: encryption in XML & in SMIME


Dear Mr. Simon,

Since our research group at TNO in the Netherlands is also involved in
XML/S stuff, I have been following this interesting thread at the
XML-encryption mailing list. It's indeed a problem when a PKI
environment is used, to ensure that the encryptor and the signer are the
same person without having an expensive sign twice. Note that an
encryption is equally expensive as a sign when the receiver's public key
is used to encrypt.
I noticed your elegant solution to the sign/wrap/sign problem but found
a potential flaw. What about the following "attack":
1. A sends a message to B using your method of signing the two digests.
2. C intercepts the message, and obtains the two digests by decrypting
the signature.
3. C creates a new <EMAIL> element by changing <From>A</From> into
<From>C</From> and computes a new digest for it.
4. C makes a new <SignedInfo> element by combining the new digest and
the other old plain text digest.
5. C completes his XML signature.
6. C sends the adjusted message to B and has stolen the contents from A
(without actually knowing the contents).

I'm more a cryptography expert than an XML expert so maybe I'm
overlooking something here. One way to fix the attack would be to
include something that identifies A into the plain text digest. It
doesn't have to be added to the <EncryptedNode> itself but should only
be included somehow in the digest.

Greetings,

Thijs Veugen
TNO-FEL, The Netherlands
http://www.tno.nl/instit/fel/felmain.html

Ed Simon wrote:
> 
> Just had a thought as to how one can get the same
> effect of sign/wrap/sign without actually having to
> sign twice.
> 
> To review,
> here is the unprotected XML-formatted email:
> 
> <EMail>
> <To>Captain Kirk</To>
> <From>Starfleet Command</From>
> <StarDate>2435CE January 19 11:22:33.44 UCT</StarDate>
> <Subject>Romulan invasion fleet</Subject>
> <Message>Please intercept the Romulan invasion fleet at...</Message>
> </EMail>
> 
> Starfleet Command wants to encrypt the Message and sign the entire
> email.  It also wants to prevent third parties from making it
> appear they sent the message contents as in the scenarios Don
> has described for S/MIME.
> 
> One approach to this has been to sign the message, encrypt (wrap)
> the signed message, and the sign the whole email.  In my
> oversimplified syntax, stuff within the <Signature> element is
> signed, and stuff within the <Encryption> element is encrypted.
> 
> So using this syntax, we get
> 
> <Signature>
> <EMail>
> <To>Captain Kirk</To>
> <From>Starfleet Command</From>
> <StarDate>2435CE January 19 11:22:33.44 UCT</StarDate>
> <Subject>Romulan invasion fleet</Subject>
> <Message><Encryption>MIIxyz...</Encryption></Message>
> </EMail>
> </Signature>
> 
> where the encrypted "MIIxyz..." is the encrypted version of
> "<Signature>Please intercept the Romulan invasion fleet
at...</Signature>".
> 
> Now let's try to do this without signing twice using XML Signature
> and XML Encryption.
> 
> First, we calculate the digest of
> "Please intercept the Romulan invasion fleet at..." and stow it.
> 
> Second, we encrypt
> "Please intercept the Romulan invasion fleet at..."
> 
> Third, we create the <EMail> element with the encrypted text.
> 
> <EMail>
> <To>Captain Kirk</To>
> <From>Starfleet Command</From>
> <StarDate>2435CE January 19 11:22:33.44 UCT</StarDate>
> <Subject>Romulan invasion fleet</Subject>
> <Message><Encryption>MIIxyz...</Encryption></Message>
> </EMail>
> 
> Fourth, we calculated the digest of the <EMail> element.
> 
> Fifth, we create the XML Signature's <SignedInfo> element
> and include a <Reference> elements for the two digests that
> have been calculated.
> 
> Sixth, we complete the XML Signature according to the
> <SignedInfo> element just created.  This one XML Signature
> covers both the full email and the original plaintext message.
> The final result, in glorious detail, might look something like
> this:
> 
>     <Signature xmlns="http://www.w3.org/2000/07/xmldsig#"
>                   Id="X01">
>            <SignedInfo>
>                    <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
>                    <SignatureMethod
> Algorithm="http://www.w3.org/2000/07/xmldsig#dsa"/>
>                    <Reference URI="id(#id1)//Message/EncryptedNode">
>                                                         <!-- XPath might
> need fixing.
>                                          Supposed to point to content of
>                                                          <EMail>'s
<Message>
> element. -->
>                          <Transforms>
>                      <Transform
> Algorithm="http://www.w3.org/2001/03/Encryption#decrypt">
>                           <DecryptTransform
> xmlns="http://www.w3.org/2001/03/Encryption">
>                                <Decrypt Match="."/>
>                           <DecryptTransform>
>                       </Transform>
>                          </Transforms>
>                          <DigestMethod
> Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
>                          <DigestValue>...</DigestValue>
>                    </Reference>
>                    <Reference URI="#id1">
>                          <Transforms>
>                              <Transform
> Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000710"/>
>                          </Transforms>
>                          <DigestMethod
> Algorithm="http://www.w3.org/2000/07/xmldsig#sha1"/>
>                          <DigestValue>...</DigestValue>
>                    </Reference>
>         </SignedInfo>
>         <SignatureValue>...</SignatureValue>
>         <KeyInfo>...</KeyInfo>
>         <Object Id="id1">
> 
>                         <EMail
> xmlns="http://www.example.org/Starfleet/EMail">
>                                 <To>Captain Kirk</To>
>                                 <From>Starfleet Command</From>
>                                 <StarDate>2435CE January 19 11:22:33.44
> UCT</StarDate>
>                                 <Subject>Romulan invasion fleet</Subject>
>                                 <Message>
>             <EncryptedNode xmlns="http://www.w3.org/2001/03/Encryption"
>                               NodeType="Text"
> 
>
EncryptionInfo="http://www.example.org/Starfleet/encryptioninfo.xml#encrypti
> onInfo23">
>                               (Base64 of encrypted Element node)
>             </EncryptedNode>
>                                 </Message>
>                         </EMail>
> 
>         </Object>
>     </Signature>
> 
> Beauty, eh?
> 
> The ownership of the original message is protected,
> the privacy of the original message is protected, and
> the whole email is signed so there is no doubt whom it
> is from and for whom it was intended.
> 
> Rather than signing twice, two digests are covered by
> one signature.
> 
> Any comments?  Did I make any glaring errors?
> 
> Ed
Received on Thursday, 21 September 2000 09:52:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:17 GMT