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

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

Expand Messages
  • 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 1 of 22 , Dec 3, 2003
      > 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 2 of 22 , Dec 4, 2003
        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 3 of 22 , Dec 4, 2003
          > 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 4 of 22 , Dec 4, 2003
            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 5 of 22 , Dec 4, 2003
              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 6 of 22 , Dec 4, 2003
                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 7 of 22 , Dec 4, 2003
                  >>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 8 of 22 , Dec 4, 2003
                    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 9 of 22 , Dec 4, 2003
                      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 10 of 22 , Dec 9, 2003
                        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 11 of 22 , Dec 9, 2003
                          > 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.