0
$\begingroup$

I am trying to reverse engineer the Handshake wit a Smartwatch by sniffing the BLE traffic. There is what I figured out and were able to reproduce:

The manufacturer-app requests a random number from the server and sends it to the watch. The watch appends its own random number and encrypts the result with some PSK. The app forwards the encrypted result to the server, which decrypts the numbers, swaps them, and encrypts them again. The app then sends the encrypted result to the watch, which then acknowledges the first steps of tht key exchange.

Not is where I am stuck: AFAIK, the app then generates a KeyPair and sends the public key to the watch, which then responds with its public key. So, having its own keypair, the apps random number and the watches public key both parties perform something Diffie Hellmanisch to derive a session key.

Questions:

  1. Is the own keypair, random number and the partners public key sufficient to perform DH?
  2. Considering a public keylength of 256bits, is DH even reasonable to assume?
  3. Is the own random number even relevant for DH?
$\endgroup$
1
  • 1
    $\begingroup$ Cryptograms of 256 bits or so during (authenticated) DH key exchange would be consistent with (authenticated) ECDH, that is DH using an Elliptic Curve Group. The terminology of the question is too imprecise to make it more answerable, and by personal policy I don't help attacks on legitimate deployed systems. $\endgroup$ – fgrieu Jan 30 at 13:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.