Loading ...
Sorry, an error occurred while loading the content.

Super-Encryption AND Digital Signatures

Expand Messages
  • wmatthewlong
    Question... If (1) WS-Security is used, and (2) the message body is super- encrypted, is there ANY need for digital signatures? Thx, -Matt Long Phalanx
    Message 1 of 22 , Dec 1, 2003
    • 0 Attachment
      Question...

      If (1) WS-Security is used, and (2) the message body is super-
      encrypted, is there ANY need for digital signatures?

      Thx,

      -Matt Long
      Phalanx Systems, LLC
    • Rich Salz
      ... A digital siganture (at least public-key based) tells you two things: That content wasn t modified in transit Who the sender was -- the holder of the
      Message 2 of 22 , Dec 1, 2003
      • 0 Attachment
        > If (1) WS-Security is used, and (2) the message body is super-
        > encrypted, is there ANY need for digital signatures?

        A digital siganture (at least public-key based) tells you two things:
        That content wasn't modified in transit
        Who the sender was -- the holder of the related private key
        Super-encryption doesn't address the second item. If you need
        crypto-strength assurance of client identity, than you need digsig. As
        with almost all crypto matters, however, please note that I am not
        claiming the contra-positive of that statement. :)
        /r$

        --
        Rich Salz, Chief Security Architect
        DataPower Technology http://www.datapower.com
        XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
        XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
      • wmatthewlong
        Hi Rich, If it is modified in transit, would it not fail to decrypt from the receiver s pov. With the caveat that WS-Security is used to identity the sender
        Message 3 of 22 , Dec 1, 2003
        • 0 Attachment
          Hi Rich,

          If it is modified in transit, would it not fail to decrypt from the
          receiver's pov. With the caveat that WS-Security is used to
          identity the sender and thus obtain the sender's public key. (Replay
          attacks excluded via wsu:Nonce).

          -Matt

          --- In soapbuilders@yahoogroups.com, Rich Salz <r.salz@v...> wrote:
          > > If (1) WS-Security is used, and (2) the message body is super-
          > > encrypted, is there ANY need for digital signatures?
          >
          > A digital siganture (at least public-key based) tells you two
          things:
          > That content wasn't modified in transit
          > Who the sender was -- the holder of the related private key
          > Super-encryption doesn't address the second item. If you need
          > crypto-strength assurance of client identity, than you need
          digsig. As
          > with almost all crypto matters, however, please note that I am not
          > claiming the contra-positive of that statement. :)
          > /r$
          >
          > --
          > Rich Salz, Chief Security Architect
          > DataPower Technology
          http://www.datapower.com
          > XS40 XML Security Gateway
          http://www.datapower.com/products/xs40.html
          > XML Security Overview
          http://www.datapower.com/xmldev/xmlsecurity.html
        • Rich Salz
          ... But if it s typical XML-Encryption, then anyone can create new fake content. Data is encrypted with a bulk key (3DES or AES), and that session key is
          Message 4 of 22 , Dec 1, 2003
          • 0 Attachment
            > If it is modified in transit, would it not fail to decrypt from the
            > receiver's pov.

            But if it's typical XML-Encryption, then anyone can create new fake
            content. Data is encrypted with a bulk key (3DES or AES), and that
            session key is encrypted with the reciever's public key, so only the
            receiver can get the key and do the bulk decrypt. But since it's a
            public key, anyone can generate content.

            > With the caveat that WS-Security is used to
            > identity the sender and thus obtain the sender's public key. (Replay
            > attacks excluded via wsu:Nonce).

            But the Sender's keys do not normally enter into encryption at all.

            How are you planning on super-encrypting? Super-encryption typically
            means its encrypted twice. The goal is to make it harder for the adversary
            to get to the plaintext -- they have twice as many keys to crack, and
            getting that first one doesn't give them plaintext, it only gives them
            hihg-entropy encrypted text, that they THEN need to crack to get the
            plaintext.

            Super-encryption doesn't make it hard to generate bogus content, and it
            does nothing to verify the source of the content. Unless you're doing
            something I'm missing, which is quite possible. So, how are you
            doing to do this?

            Make sense?
            /r$

            --
            Rich Salz Chief Security Architect
            DataPower Technology http://www.datapower.com
            XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
            XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
          • mlong@bridgetonconsulting.com
            Here s the scenario. (1) Sender generates an RC2 key-pair. (2) Sender encrypts the RC2 Key (not the IV) via RSA using the sender s RSA private key. (3) Sender
            Message 5 of 22 , Dec 2, 2003
            • 0 Attachment
              Here's the scenario.

              (1) Sender generates an RC2 key-pair.
              (2) Sender encrypts the RC2 Key (not the IV) via RSA using the sender's RSA
              private key.
              (3) Sender then generates the RC2 cipher value.
              (4) Sender generates a second RC2 key-pair
              (5) Sender encrypts the RC2 Key via RSA using the receivers RSA public key.
              (6) Sender then generates the cipher value based on the previous cipher value.

              (7) send the message ...
              (8) Receiver decrypts the outer cipher value using the receiver's RSA private
              key, yielding IV and decrypted KEY for RC2 decryption. (Only the receiver can
              decrypt the message).
              (9) Receiver decrypts the inner cipher value using the sender's RSA public key,
              yielding IV and decrypted KEY for RC2 decryption. (Only the sender could have
              sent the message).

              WS-Security comes into play because an authenticated sender enables a quick
              lookup of the sender's public key and encryption algorithm from the pov of the
              receiver.

              Is this clearer?

              Thx,

              -Matt


              Quoting Rich Salz <rsalz@...>:

              > > If it is modified in transit, would it not fail to decrypt from the
              > > receiver's pov.
              >
              > But if it's typical XML-Encryption, then anyone can create new fake
              > content. Data is encrypted with a bulk key (3DES or AES), and that
              > session key is encrypted with the reciever's public key, so only the
              > receiver can get the key and do the bulk decrypt. But since it's a
              > public key, anyone can generate content.
              >
              > > With the caveat that WS-Security is used to
              > > identity the sender and thus obtain the sender's public key. (Replay
              > > attacks excluded via wsu:Nonce).
              >
              > But the Sender's keys do not normally enter into encryption at all.
              >
              > How are you planning on super-encrypting? Super-encryption typically
              > means its encrypted twice. The goal is to make it harder for the adversary
              > to get to the plaintext -- they have twice as many keys to crack, and
              > getting that first one doesn't give them plaintext, it only gives them
              > hihg-entropy encrypted text, that they THEN need to crack to get the
              > plaintext.
              >
              > Super-encryption doesn't make it hard to generate bogus content, and it
              > does nothing to verify the source of the content. Unless you're doing
              > something I'm missing, which is quite possible. So, how are you
              > doing to do this?
              >
              > Make sense?
              > /r$
              >
              > --
              > Rich Salz Chief Security Architect
              > DataPower Technology http://www.datapower.com
              > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
              > XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
              >
              >
              >
            • Rich Salz
              Clever idea. Just because I haven t heard of it doesn t mean it s not known to real cryptographers, of course. :) One of the best lists for discussing this
              Message 6 of 22 , Dec 2, 2003
              • 0 Attachment
                Clever idea. Just because I haven't heard of it doesn't mean it's not
                known to real cryptographers, of course. :) One of the best lists for
                discussing this kind of thing in detail is the cryptography list moderated
                by Perry Metzger; email to majordomo@... for details.

                Anyhow, your technique provides confidentiality -- only the intended
                recipient can see the content. It also provides sender-authentiaction,
                since only the sender can encrypt the inner session key. But it doesn't
                provide a priori content integrity; that will depend on the content
                itself being error-detecting. This is probably okay for XML, since you're
                most likely to end up with something that won't parse. But that's
                only probablistic and if the data being sent is something like a GIF
                or MPEG, you'll probably never know.

                I'm curious why a standard dsig/enc combination isn't appropriate?
                /r$
                --
                Rich Salz Chief Security Architect
                DataPower Technology http://www.datapower.com
                XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
              • mlong@bridgetonconsulting.com
                ... There is nothing wrong with the dsig, but it s overhead (and plenty of it). IMHO, the necessity for large and scaleable secure applications it great. I
                Message 7 of 22 , Dec 3, 2003
                • 0 Attachment
                  Quoting Rich Salz <rsalz@...>:

                  > I'm curious why a standard dsig/enc combination isn't appropriate?

                  There is nothing wrong with the dsig, but it's overhead (and plenty of it).

                  IMHO, the necessity for large and scaleable secure applications it great. I
                  don't believe that xml-enc + xml-dsig on a one to many basis will ever be
                  functionally scaleable (except in name only).

                  If you take my premise based on an intermediary, then the requirements for
                  secured/encrypted data are only based on a single and relatively simple
                  concept. Not to mention the reduction in overhead in the fact the sender and
                  receiver need not exchange keys. Only the intermediary-2-sender and
                  intermediary-2-receiver need to exchange public keys, i.e., the intermediary
                  decrypts the sender's message; then encrypts the message for the receiver.
                  That scenario to me dramatically increases the scalability of
                  secured/encrypted interop over an unsecured channel.

                  Thoughts?

                  -Matt
                • Rich Salz
                  In talking it over with a colleague here, we did find one weakness in your scheme. Once the recipient has unwrapped the outer part, and then unwrapped the
                  Message 8 of 22 , Dec 3, 2003
                  • 0 Attachment
                    In talking it over with a colleague here, we did find one weakness in
                    your scheme. Once the recipient has unwrapped the outer part, and then
                    unwrapped the internal key, they can forge any message and make it
                    appear as if it came from the sender. I don't know if you're worried
                    about that or not. "But you promised me $10,000. not $1,000. See, I have
                    your original message."

                    One way to fix this might be to include a signed hash of the original
                    document.

                    You should look at PKCS#7 (sorry I wasn't clear, when I said what's
                    wrong with a standard I meant any standard, not just XML DSIG).

                    As for your intermediary approach.. you know about Kerberos, right?
                    /r$
                    --
                    Rich Salz, Chief Security Architect
                    DataPower Technology http://www.datapower.com
                    XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                    XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                  • mlong@bridgetonconsulting.com
                    ... You are correct, but sender-2-recipient is secured AFAIK, e.g., using SSL to send credit card info to a processor doesn t guarantee the processor isn t
                    Message 9 of 22 , Dec 3, 2003
                    • 0 Attachment
                      Quoting Rich Salz <rsalz@...>:

                      > In talking it over with a colleague here, we did find one weakness in
                      > your scheme. Once the recipient has unwrapped the outer part, and then
                      > unwrapped the internal key, they can forge any message and make it
                      > appear as if it came from the sender. I don't know if you're worried
                      > about that or not. "But you promised me $10,000. not $1,000. See, I have
                      > your original message."

                      You are correct, but sender-2-recipient is secured AFAIK, e.g., using SSL to
                      send credit card info to a processor doesn't guarantee the processor isn't
                      publishing the information to a chat room, but you inherently trust that VISA
                      isn't doing that. Only the sender and the intended recipient can see/decrypt
                      the information. Right!?!
                      >
                      > One way to fix this might be to include a signed hash of the original
                      > document.
                      >
                      > You should look at PKCS#7 (sorry I wasn't clear, when I said what's
                      > wrong with a standard I meant any standard, not just XML DSIG).
                      >
                      > As for your intermediary approach.. you know about Kerberos, right?

                      I have doubts about Kerberos in the short-term, because of the overhead of
                      ticket exchange and the decentralization of KDCs. One can certainly utilize
                      Kerberos intra-enterprise effectively as generally you are working with a
                      single KDC, but once you start scaling with reckless abandon outside the
                      enterprise engineering issues compond rather quickly.

                      This is a good discussion.

                      -Matt
                    • mlong@bridgetonconsulting.com
                      ... Isn t the security equally as strong as sending CC info over SSL, or not? -Matt
                      Message 10 of 22 , Dec 3, 2003
                      • 0 Attachment
                        Quoting Rich Salz <rsalz@...>:
                        > Anyhow, when I posted the weakness I said it's something you *might*
                        > care about. As long as the sender is is not concerned about the
                        > possibility of receiver fraud (even if the receive has been compromised
                        > by an adversary), than it doesn't matter. Whether or not that is an
                        > issue depends on the application. But it certainly makes the technique
                        > inapplicable for widepsread general use.

                        Isn't the security equally as strong as sending CC info over SSL, or not?

                        -Matt
                      • Rich Salz
                        ... Since VISA is liable for any fraud if they publish your ccard number, there is strong incentive for them to not do that kind of thing. Similarly, there are
                        Message 11 of 22 , Dec 3, 2003
                        • 0 Attachment
                          > You are correct, but sender-2-recipient is secured AFAIK, e.g., using SSL to
                          > send credit card info to a processor doesn't guarantee the processor isn't
                          > publishing the information to a chat room, but you inherently trust that VISA
                          > isn't doing that. Only the sender and the intended recipient can see/decrypt
                          > the information. Right!?!

                          Since VISA is liable for any fraud if they publish your ccard number,
                          there is strong incentive for them to not do that kind of thing.
                          Similarly, there are strict rules and penalties for disclosure of
                          personal information. Now, SET was worried about this, and they made
                          sure that things were encrypted every-which-way, so that, e.g., the
                          Merchant never saw your CCard number, but passed it along to the
                          CreditCard clearinghouse, who *could* see the number, but couldn't see
                          some merchant info, etc. etc. It all turned out to be too heavyweight,
                          and the existing legal framework (plus incentives from the CCard
                          companies to merchants) was enough to support "just use SSL."

                          Anyhow, when I posted the weakness I said it's something you *might*
                          care about. As long as the sender is is not concerned about the
                          possibility of receiver fraud (even if the receive has been compromised
                          by an adversary), than it doesn't matter. Whether or not that is an
                          issue depends on the application. But it certainly makes the technique
                          inapplicable for widepsread general use.

                          > This is a good discussion.

                          Yup. Hope we're not boring everyone else. :)
                          /r$

                          --
                          Rich Salz, Chief Security Architect
                          DataPower Technology http://www.datapower.com
                          XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                          XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                        • Rich Salz
                          ... Yes; the weaknesses are pretty much the same: with a symmetric key either side can forge content. But for Ccards over the web, the out-of-band framework
                          Message 12 of 22 , Dec 3, 2003
                          • 0 Attachment
                            > Isn't the security equally as strong as sending CC info over SSL, or not?

                            Yes; the weaknesses are pretty much the same: with a symmetric key
                            either side can forge content.

                            But for Ccards over the web, the out-of-band framework makes it
                            reasonable to do accept this risk. Neither the merchant nor the payment
                            house want to expose the information they receive, nor do any other kind
                            of "defraud the sender" thing because there are financial and legal
                            incentives to not do that. SSL gives hop-by-hop privacy, with some
                            information about the entity at the other end. It does *not* give
                            signature-style content integrity, and it's not a end-to-end
                            authenticated signed content. It's transport-level security (that's why
                            the IETF renamed it to TLS). For retail CCard transactions over the Web,
                            TLS is okay. For many other things -- where there are outside
                            agreements, risk management, or other factors influencing things -- it
                            is not okay.

                            For example, a doctor should not be able to use either SSL or your
                            technique to do online perscriptions. A corrupt pharmacist (perhaps
                            he's a friend of Rush Limbaugh :), could turn the scrip from 100 pills
                            of Vicodin to 500 pills of vicodin, and *the doctor can't prove
                            otherwise.* That's why I said what you want to do might be okay for
                            your application, but not for general purpose.

                            /r$

                            --
                            Rich Salz, Chief Security Architect
                            DataPower Technology http://www.datapower.com
                            XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                            XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                          • mlong@bridgetonconsulting.com
                            ... Hmmm...under my scenario the content can be duplicated, but not altered. Because the receiver does not have the private key of the sender, i.e., the
                            Message 13 of 22 , Dec 4, 2003
                            • 0 Attachment
                              Quoting Rich Salz <rsalz@...>:

                              > > Isn't the security equally as strong as sending CC info over SSL, or not?
                              >
                              > Yes; the weaknesses are pretty much the same: with a symmetric key
                              > either side can forge content.
                              >
                              > For example, a doctor should not be able to use either SSL or your
                              > technique to do online perscriptions. A corrupt pharmacist (perhaps
                              > he's a friend of Rush Limbaugh :), could turn the scrip from 100 pills
                              > of Vicodin to 500 pills of vicodin, and *the doctor can't prove
                              > otherwise.* That's why I said what you want to do might be okay for
                              > your application, but not for general purpose.


                              Hmmm...under my scenario the content can be duplicated, but not altered.
                              Because the receiver does not have the private key of the sender, i.e., the
                              receiver cannot re-encrypt the inner cipher value identically (to spoof the
                              original sender) due to the fact that the original sender's private key is not
                              known to the receiver.

                              However, the receiver could create a new outer cipher value (assuming the
                              receiver is the intended recipient) and forward the message. Then the
                              recipient of the forwarded message would then receive an inner cipher value !=
                              to the authenticated sender. Which tells the sender something is wrong
                              assuming a point-2-point processing model.

                              -Matt
                            • Rich Salz
                              ... Perhaps I don t understand. I was talking about re-using the cipher to create a modified message. The adversary (compromised recipient) doesn t need to
                              Message 14 of 22 , Dec 4, 2003
                              • 0 Attachment
                                > Hmmm...under my scenario the content can be duplicated, but not altered.
                                > Because the receiver does not have the private key of the sender, i.e., the
                                > receiver cannot re-encrypt the inner cipher value identically (to spoof the
                                > original sender) due to the fact that the original sender's private key is not
                                > known to the receiver.

                                Perhaps I don't understand. I was talking about re-using the cipher to
                                create a modified message. The adversary (compromised recipient)
                                doesn't need to generate a new inner key, he just re-uses it generate a
                                new messsage. Now the original sender can't prove the receiver wrong.
                                /r$

                                --
                                Rich Salz, Chief Security Architect
                                DataPower Technology http://www.datapower.com
                                XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                              • mlong@bridgetonconsulting.com
                                Allow me to try this will a little pseudo-math. Encryption for Sender: SymmetricKey1 = TripleDES(IV1,Key1) CipherValue1 = Encrypt[TripleDES(MyMessage)]
                                Message 15 of 22 , Dec 4, 2003
                                • 0 Attachment
                                  Allow me to try this will a little pseudo-math.

                                  Encryption for Sender:

                                  SymmetricKey1 = TripleDES(IV1,Key1)
                                  CipherValue1 = Encrypt[TripleDES(MyMessage)]
                                  InnerEncryptedKey = RSA_Encrypt(Key1) [using sender's RSA private key]

                                  SymmetricKey2 = TripleDES(IV2,Key2)
                                  CipherValue2 = Encrypt[TripleDES(CipherValue1)]
                                  OuterEncryptedKey = RSA_Encrypt(Key2) [using receiver's RSA public key]


                                  Decryption for Receiver:

                                  Key2 = RSA_Decrypt[OuterEncryptedKey] [using receiver's RSA private key]
                                  CipherValue1 = Decrypt[TripleDES(CipherValue2)]
                                  Key1 = RSA_Decrypt[InnerEncryptedKey] [using sender's RSA public key]
                                  MyMessage = Decrypt[TripleDES(CipherValue1)]

                                  Naturally, IV1 and IV2 are the first 8 octets of their respective cipher
                                  values. (omitted for brevity).

                                  (1) You could decrypt MyMessage and send it two someone else.
                                  (a) But you couldn't impersonate the sender (the senders private key is
                                  not available)
                                  (2) You could decrypt CipherValue2 and re-encrypt CipherValue1 which something
                                  akin to CipherValue2' and forward the message.
                                  (a) But the decryption of CipherValue1 now yields a sender not from the
                                  source of the message sent, i.e. public key of forwarding sender cannot be
                                  used to decrypt the Key1 of CipherValue1.

                                  More thoughts and comments, please.

                                  Thx,

                                  -Matt









                                  Quoting Rich Salz <rsalz@...>:

                                  > > Hmmm...under my scenario the content can be duplicated, but not altered.
                                  > > Because the receiver does not have the private key of the sender, i.e., the
                                  >
                                  > > receiver cannot re-encrypt the inner cipher value identically (to spoof the
                                  >
                                  > > original sender) due to the fact that the original sender's private key is
                                  > not
                                  > > known to the receiver.
                                  >
                                  > Perhaps I don't understand. I was talking about re-using the cipher to
                                  > create a modified message. The adversary (compromised recipient)
                                  > doesn't need to generate a new inner key, he just re-uses it generate a
                                  > new messsage. Now the original sender can't prove the receiver wrong.
                                  > /r$
                                  >
                                  > --
                                  > Rich Salz, Chief Security Architect
                                  > DataPower Technology http://www.datapower.com
                                  > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                  > XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                  >
                                  >
                                  >
                                • Rich Salz
                                  Good -- a common notation. :) Now, a compromised receiver does the following. First, get the keys: Key2 = RSA_Decrypt[OuterEncryptedKey] [using receiver s RSA
                                  Message 16 of 22 , Dec 4, 2003
                                  • 0 Attachment
                                    Good -- a common notation. :)

                                    Now, a compromised receiver does the following. First, get the keys:
                                    Key2 = RSA_Decrypt[OuterEncryptedKey] [using receiver's RSA private key]
                                    CipherValue1 = Decrypt[TripleDES(CipherValue2)]
                                    Key1 = RSA_Decrypt[InnerEncryptedKey] [using sender's RSA public key]
                                    Next, use those keys to create a bad message:
                                    BadCipher1 = Encrypt[TripleDES(*BAD MESSAGE*, Key1)]
                                    BadCipher2 = Encrypt[TripleDes(BadCipher1, Key2)]

                                    The adversary can now present present the two encrypted keys and
                                    BadCipher2, and nobody can prove they didn't come from the original
                                    sender. ("But you told me to give 1,000 pills -- here's the message")

                                    /r$
                                    --
                                    Rich Salz, Chief Security Architect
                                    DataPower Technology http://www.datapower.com
                                    XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                    XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                  • mlong@bridgetonconsulting.com
                                    ... But BadCipher1 now has RSA_Encrypt(Key1) from the receiver and not the original sender, because the receiver never had access to the sender s RSA private
                                    Message 17 of 22 , Dec 4, 2003
                                    • 0 Attachment
                                      Quoting Rich Salz <rsalz@...>:

                                      > Good -- a common notation. :)
                                      >
                                      > Now, a compromised receiver does the following. First, get the keys:
                                      > Key2 = RSA_Decrypt[OuterEncryptedKey] [using receiver's RSA private key]
                                      > CipherValue1 = Decrypt[TripleDES(CipherValue2)]
                                      > Key1 = RSA_Decrypt[InnerEncryptedKey] [using sender's RSA public key]
                                      > Next, use those keys to create a bad message:
                                      > BadCipher1 = Encrypt[TripleDES(*BAD MESSAGE*, Key1)]
                                      > BadCipher2 = Encrypt[TripleDes(BadCipher1, Key2)]
                                      >
                                      > The adversary can now present present the two encrypted keys and
                                      > BadCipher2, and nobody can prove they didn't come from the original
                                      > sender. ("But you told me to give 1,000 pills -- here's the message")

                                      But BadCipher1 now has RSA_Encrypt(Key1) from the receiver and not the
                                      original sender, because the receiver never had access to the sender's RSA
                                      private key. Therefore, the proof of who sent the message resides with the
                                      decryption of Key1 (since it is always encrypted with the sender's private
                                      key).

                                      Where is this breaking down?
                                    • Rich Salz
                                      ... No, use the original encrypted Key1. ... Right, but there s no proof of what content the sender provided. More precisely, the proof is who generated
                                      Message 18 of 22 , Dec 4, 2003
                                      • 0 Attachment
                                        >>Now, a compromised receiver does the following. First, get the keys:
                                        >>Key2 = RSA_Decrypt[OuterEncryptedKey] [using receiver's RSA private key]
                                        >>CipherValue1 = Decrypt[TripleDES(CipherValue2)]
                                        >>Key1 = RSA_Decrypt[InnerEncryptedKey] [using sender's RSA public key]
                                        >>Next, use those keys to create a bad message:
                                        >>BadCipher1 = Encrypt[TripleDES(*BAD MESSAGE*, Key1)]
                                        >>BadCipher2 = Encrypt[TripleDes(BadCipher1, Key2)]

                                        > But BadCipher1 now has RSA_Encrypt(Key1) from the receiver and not the
                                        > original sender

                                        No, use the original encrypted Key1.

                                        > Therefore, the proof of who sent the message resides with the
                                        > decryption of Key1

                                        Right, but there's no proof of what content the sender provided. More
                                        precisely, the proof is "who generated Key1", which is even further from
                                        protecting the content.

                                        > Where is this breaking down?

                                        Our terminology, I think.

                                        Both sender and receiver need Key1 and Key2. Since both 3DES is
                                        symmetric, Key1 and Key2 can both encrypt and decrypt. Once the
                                        adversary (compromised receiver) has both keys, he can use them to
                                        encrypt anthing he wants. Now take that bogus message -- and the keys
                                        *in their original wrappers* -- and prove the sender didn't generate
                                        that content.

                                        Does this help?
                                        /r$
                                        --
                                        Rich Salz, Chief Security Architect
                                        DataPower Technology http://www.datapower.com
                                        XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                        XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                      • mlong@bridgetonconsulting.com
                                        ... Thanks, I m clear now. Receiver decrypts both wrappers then reuses RSA_Encrypted(Key) for the outbound traffic. Now, my trusted intermediary/trust-broker
                                        Message 19 of 22 , Dec 4, 2003
                                        • 0 Attachment
                                          Quoting Rich Salz <rsalz@...>:
                                          >
                                          > No, use the original encrypted Key1.

                                          Thanks, I'm clear now. Receiver decrypts both wrappers then reuses
                                          RSA_Encrypted(Key) for the outbound traffic.

                                          Now, my trusted intermediary/trust-broker scenario to combat this.
                                          Setup:
                                          (a) Subdivide users into two categories, i.e., consumers/senders and
                                          providers/receivers.
                                          (b) Consumers create endpoints within the intermediary to connect to
                                          providers.
                                          (c) Both consumers and providers share Public Key with intermediary, but not
                                          with each other (not that it matters).
                                          (d) Providers share authentication information for their respective services
                                          with the intermediary, but not the consumers. Likewise for consumers.

                                          The Message:
                                          (1) Encrypted message sent by consumer "C" to intermediary "I" targeted at
                                          provider "P".
                                          (2) "I" authenticates "C" and uses the auth info to determine Public Key match
                                          for encrypted key.
                                          (3) "I" fully decrypts the message, then re-encrypts the message based "I"
                                          Private Key, "P" symmetric algorithm, and "P's" Public Key.
                                          (3) "I" forwards message to "P" utilizing orthogonal authentication info
                                          provided by "P" and original sender identification (which doesn't need
                                          encryption AFAIK)
                                          (4) "P" authenticates "I" and such decrypts message using "I's" PK.

                                          Therefore, as long as the message authenticates for "I", then it must come
                                          from "I" where the original sender has been authenticated and message properly
                                          decrypted and re-encrypted. Naturally, this relies on the authentication
                                          information being well protected from both perspective of "C","P", and "I".

                                          Tell me where this break, please.

                                          Thx,

                                          -Matt
                                        • Rich Salz
                                          A simpler fix is for the sender to do SHA1(message), and then encrypt (key1+digest) with their private key. That s simpler because it s a classic digital
                                          Message 20 of 22 , Dec 4, 2003
                                          • 0 Attachment
                                            A simpler fix is for the sender to do SHA1(message), and then
                                            encrypt (key1+digest) with their private key. That's simpler
                                            because it's a classic digital signature, and its properties are
                                            well understood.

                                            The two biggest problems with your current idea are that
                                            1. "I" must be online and completely trusted for every single
                                            message exchange. This gives up all the benefits of public-
                                            key crypto.
                                            2. There's no end-to-end security link. What prevents P from
                                            using his own keypair to forge a message that looks like
                                            I-on-behalf-of-C?

                                            A simpler fix for your first scheme might be for the sender to include
                                            RSA_Encrypt(SHA1(message)) alongside the encrypted key1. Then perhaps
                                            you include a timestamp, so adversaries can't capture and reply old
                                            messages.

                                            I know you think that the standard mechanisms are expensive and full
                                            of overhead. There's a reason: without them, you leave yourself
                                            open to various attacks.
                                            /r$

                                            --
                                            Rich Salz Chief Security Architect
                                            DataPower Technology http://www.datapower.com
                                            XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                            XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                          • mlong@bridgetonconsulting.com
                                            Rich, RSA_Encrypt(SHA1(message) + key1) this looks promising. Also, doesn t eliminate the need for a xml digital signature. You see what I m after, i.e., high
                                            Message 21 of 22 , Dec 9, 2003
                                            • 0 Attachment
                                              Rich,

                                              RSA_Encrypt(SHA1(message) + key1) this looks promising. Also, doesn't
                                              eliminate the need for a xml digital signature.

                                              You see what I'm after, i.e., high security + scalable implementable features
                                              + compact wire format.

                                              Thoughts!?!

                                              -Thx,

                                              -Matt



                                              Quoting Rich Salz <rsalz@...>:

                                              > A simpler fix is for the sender to do SHA1(message), and then
                                              > encrypt (key1+digest) with their private key. That's simpler
                                              > because it's a classic digital signature, and its properties are
                                              > well understood.
                                              >
                                              > The two biggest problems with your current idea are that
                                              > 1. "I" must be online and completely trusted for every single
                                              > message exchange. This gives up all the benefits of public-
                                              > key crypto.
                                              > 2. There's no end-to-end security link. What prevents P from
                                              > using his own keypair to forge a message that looks like
                                              > I-on-behalf-of-C?
                                              >
                                              > A simpler fix for your first scheme might be for the sender to include
                                              > RSA_Encrypt(SHA1(message)) alongside the encrypted key1. Then perhaps
                                              > you include a timestamp, so adversaries can't capture and reply old
                                              > messages.
                                              >
                                              > I know you think that the standard mechanisms are expensive and full
                                              > of overhead. There's a reason: without them, you leave yourself
                                              > open to various attacks.
                                              > /r$
                                              >
                                              > --
                                              > Rich Salz Chief Security Architect
                                              > DataPower Technology http://www.datapower.com
                                              > XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                              > XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                              >
                                              >
                                              >
                                            • Rich Salz
                                              ... Yeah, there s no such thing as a free lunch. :) Folks often complain about how big SSL is, or how complicated XML DSIG is, etc. Unfortunately, they are
                                              Message 22 of 22 , Dec 9, 2003
                                              • 0 Attachment
                                                > You see what I'm after, i.e., high security + scalable implementable features
                                                > + compact wire format.
                                                >
                                                > Thoughts!?!

                                                Yeah, there's no such thing as a free lunch. :)

                                                Folks often complain about how "big" SSL is, or how complicated
                                                XML DSIG is, etc. Unfortunately, they are that way because they need
                                                to be in order to be resistant to various threats. And then you have
                                                to fight the deployment barriers: if SSL, PKCS#7 and/or XML DSIG are
                                                already everywhere, what's the incentive to try something that hasn't
                                                had the same level of analysis? Unless you're Ron Rivest (the R of RSA)
                                                designing a new micro-payment protocol (www.peppercoin.com), you're
                                                generally better off accepting the trade-offs of commodity security
                                                mechanisms.

                                                Now, RSA_PublicKey_Encrypt(SHA1(message) + key1) seems reasonable
                                                to me. But it's quite possible that there's some obscure corner of
                                                crypto that makes this a bad idea. I still think it's worth
                                                posting it to the cryptography mailing list.

                                                /r$

                                                --
                                                Rich Salz Chief Security Architect
                                                DataPower Technology http://www.datapower.com
                                                XS40 XML Security Gateway http://www.datapower.com/products/xs40.html
                                                XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
                                              Your message has been successfully submitted and would be delivered to recipients shortly.