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

Re: [soapbuilders] Re: Super-Encryption AND Digital Signatures

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.