1
$\begingroup$

I am writing an application in Java that will be using SHA-1 HMAC message authentication. From what I understand, a connection over HTTPS is considered secure enough to share a secret key in plain text, and there is little added benefit to hashing the key before sending it from the client to the server.

So, my implementation would have to share a secret key when the first connection is made. After that, the client would send an API key along with the message that would identify the client and allow the server to look up the correct secret key.

For more information on the approach that I want to use, I am following this guide (Gary Rowe's Multibit Merchant).

The goal is to authenticate the client on subsequent connections.

Is my assumption correct that I can safely send the secret key over HTTPS on the initial connection?

Improve this question
$\endgroup$
2
  • $\begingroup$ It depends on the actually used cipher suite ... make sure it is not NONE, for example. Also, if you are just defining the protocol (i.e. no existing application to be compatible to), and don't have a highly performance critical or resource limited application, don't use SHA-1, use one of the SHA-2 variants instead in your HMAC. $\endgroup$
    – Paŭlo Ebermann
    Commented Mar 10, 2014 at 22:08
  • 2
    $\begingroup$ The BEST way is through a shared secret generated by FHMQV key exchange over a safe large prime field elliptic curve such as Curve511187 or E-521, though this may exceed your security requirements... $\endgroup$
    – Richie Frame
    Commented Mar 11, 2014 at 1:00

1 Answer 1

Reset to default
1
$\begingroup$

HTTPS itself does not do encryption, it simply relies on SSL/TLS in order to implement some level of security to your communications. The problem lies with the choice of underlying algorithm - SSL 2.0 is already considered insecure due to flaws. Similar (less critical) attacks have also been discovered for SSL 3.0/TLS 1.0 so you can only fully trust HTTPS if you know what the server AND client (browser) use behind the curtains.

Generally, the approach for communicating a secret key (read ANY secret key) assumes an effort of asymmetric cryptography (see RSA, for example). So your client would connect and send his (temporarily generated, if you must) public key and receive the secret key encrypted with this. The message can now only be decrypted by his private key which never appears in HTTPS traffic and is, mathematically, hard to figure out. This is, for the most part, the way HTTPS works.

Normally I would advise against reimplementing any sort of crypto but, if you have no control over the SSL/TLS versions the server advertises, I would go for an encrypted secret key exchange inside the session and leave the rest of the traffic as is. Just remember NOT to implement the primitives yourself - any language out there has a number of functions and libraries dedicated to this, including higher-level primitives for simply encrypting a message with little options.

It all depends on your skill and on the security you want to impose inside the system.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the answer. What exactly do you mean by "leave the rest of the traffic as is?" $\endgroup$
    – nckturner
    Commented Mar 11, 2014 at 1:22
  • $\begingroup$ I mean avoid re-encrypting all of the communications inside an encrypted protocol. Sending more encrypted text exposes you to issues such as the number of re-uses, the cipher chaining modes and other problems which require a good bit of knowledge to implement correctly (thinks a good implementation of TLS should solve on its own). A short exchange, strictly related to your secret key, would make these issues less important while still maintaining secrecy (even if someone would be able to do a MITM attack, he'd only get some knowledge of the traffic taking place, nothing regarding identity). $\endgroup$
    – AdrianH
    Commented Mar 11, 2014 at 6:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.