Diffie Hellman Authenticated Version Security Overview

Question

EDIT

I still hope for some advice on this, I tried to clarify my intentions ...

When I came across connecting devices in my mobile infrastructure, I studied a lot of documents on this topic and also received some answers from previous questions. But I did not find a ready-made solution for solving the protocol - so I invented a derivative, and since I am not crypto, I am not sure about the safety warnings of the final solution:

Main questions:

• Is SHA256 sufficient as a fix function?
• Is adding a shared secret as authentication information in a secure chain?
• What is the general security of a 1024-bit DH group
• I assume no more than 2 ^ -24 bits probability of a successful MITM attack (due to a 24-bit call). Is this believable?
• What could be the most promising attack (besides pulling the device out of my numb, cold hands).

This is a sketch of the algorithm.

• For pairing, for the first time, the solution proposed in “Key Matching in Peer-to-Peer Wireless Networks” (DH-SC) is implemented. I based it on obligations arising from:
  • Correct the "UUID" for the transmitting object / role (128 bit sent when the protocol was launched, before the obligation)
  • Shared DH key (192-bit private key based on the Oakley 1024-bit group)
  • 24-bit random task
• Commit is calculated using SHA256
  • c = sha256 (UUID || DH pub || Chall)
• Both parties exchange this obligation, discover and transfer the simple content of the above values.

  Alice bob
     ca = commit ()                        
                     ------- ^ ca
                                             cb = commit ()
                     cb ^ -----------
     open
                     --- ^ DH pub a, chall a
                                             open
                     DH pub b, chall b ^ ---

• 24-bit random information is displayed to the user for manual authentication.

• DH session key is calculated (128 bytes, see above)

• When the user selects persistent pairing, the session key is stored with the remote UUID as a shared secret

• When connecting next time devices, the commit is calculated by additionally hashing the previous DH session before a random call. Surely it is not transmitted at the opening.

  • c = sha256 (UUID || DH pub || DH sess || Chall)

• Now the user does not need to authenticate when the local party can obtain the same commitment using their own, stored previous DH session key. After successfully connecting, the new DH session key will become the new shared secret.

Since this doesn’t exactly match the protocols I have found so far (and, as such, their evidence of security), I would be very interested to get an opinion from some of the more crypto guys. BTW. I read about the EKE protocol, but I'm not sure what an extra layer of security is.

Answer 1

"Is SHA256 sufficient as a commit function?"

Using SHA256 should be great. The only problem I've heard about is the hash extension vulnerability. If you produce multiple hashes using the same data, don't just concatenate more data to the end of the data that you already hashed. There are two hashes in your post "sha256 (UUID || DH pub || Chall)" and "sha256 (UUID || DH pub || DH sess || Chall)". If this second were "sha256 (UUID || DH pub || Chall || DH sess)" then there would be a relationship between the hash values ​​if the UUID, DH pub and Chall were the same values ​​as before. You must either take care to avoid the problem of expanding the hash, or include the salt value in the data you want to hash, either by passing the salt by reference, or with different values ​​for each code.

On the side of the note: is it really necessary to transfer the call when you have already saved the previous session key and do not need to ask the user to manually confirm the call code?

"Is adding a shared secret as authentication information in a secure chain?"

I suppose you want to ask: "Is it safe to include secret information in a hash that needs to be made public?" If the secret is that it’s really hard to guess, and it really will take a lot of time to carry out an attack using bruteforce, then yes, it’s safe. If a secret is something easy to guess or has only a few possible meanings, then no, it is unsafe if at the same time you do not include some difficult secret in order to force a potential listening device to guess all such secrets at the same time. For a large, effective random number, such as DH's shared secret, then this should be just fine.

"What is the overall security of a 1024-bit DH group?"

I'm not sure that the DH group 1024 is what you want to use. A key exchange that is considered close to being as efficient as the SHA256 hash algorithm that you use will be 521 bits of ECDH. The cryptographic strength of ECDH is considered to be 1/2, so if you need 256-bit protection, you want 521 bits of ECDH. Unfortunately, I'm not sure about the security of many of the individual 521-bit ECDH groups that have been published.

"I assume no more than a 2 ^ -24 bit probability of a successful MITM attack (due to a 24-bit call). Is this plausible?"

There are several ways to carry out a MITM attack. Eve will use every resource available to her to carry out her attacks, and if you are not careful, she will use what you did not think about. That's why cryptography needs an expert review.

Answer 2

Simply, if you create your own cryptographic solution, it will be weak.

for a little story, the guys from VISA should start again 4 times before he gets strong enough.

I'm not a security expert, but this is what my crypto teacher told me every time.

Answer 3

I came up with this possible attack based on my understanding of the protocol, inspired by Low's Attack on the Needham-Shroeder public key protocol :

• Alice wants to connect again. Calculates its ca caity and sends it to Bob. The message is captured by Mallory.
• Mallory answers. She does not know a common secret, so she invents it. Computes cb and sends to Alice.
• At this point, Alice cannot yet verify the shared secret. Therefore, she sends DHpubA and ChallA.
• Mallory ignores messages from Alice and disappears.

Mallory now has valid DHpubA, ChallA and corresponding (valid) ca.

• Mallory sends cha to Bob.
• Bob answers with cb.
• Mallory ships virtual set of DhpubA, ChallA
• Bob sends his DhpubB and ChallB

Since Bob can check Mallory's messages, she authenticates as Alice. Obviously, Mallory does not know DHprivA because she cannot calculate the current session key, but you still have a security flaw, since Bob believes that he is talking to Alice.

General recommendations : avoid implementing your own cryptographic solution and do not trust security reviews from anyone other than the established security company.

If you think that your security requirements are not met by standard cryptographic cryptography, try to indicate your requirements and ask if there is an appropriate security protocol.

Answer 4

That sounds good. Not sure what you mean by "fix [ed] UUID"? Could a fraudulent application access the UUIDs and the session: are they stored in the system or in the service? There is some text in the SDK that assumes that any keystore is always waiting for user confirmation before returning the key.