Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I am looking at ways to secure http communication using HMAC. My understanding is that in this scenario the client and the server both know a secret. This means the secret must be first generated on the client (or the server? Does it matter which side?). At this point only one side has the secret. How does the secret get passed to on the other side (or if not passed once how does it ever come to know it)? Would this not involved sending it across albeit one time? How else would the secret ever be known to both the client and server? If sending it across during initialization is in fact the thing to do, how can this be done securely?

Now I realize that a separate channel might be used like email etc, but what if you needed to use establish HMAC automatically without user involvement?

share|improve this question
5  
What you describe is basically the biggest issue with symmetric encryption/signing. You always need a secure channel to exchange key information. This is why asymmetric encryption (RSA…) with certificate chains is much more widespread. –  leoluk Mar 7 '13 at 3:39
    
Can't you just throw HTTPS at the problem and verify the server's public key somehow? –  CodesInChaos Mar 7 '13 at 9:26

3 Answers 3

First, HMAC is used for verifying the originator of a message and only the sender needs a secret. It is useless for purposes of secrecy. Second, key exchange is a hard thing. You can do it through a side channel, but since that is hard, that is why most browsers do it for you by way of a pre-installed list of root CA certs that are installed with the browser. This is how your browser knows to trust information coming from a particular server.

Since the server knows a secret that the client can trust, it is possible for the client to send a session key that only the server can read and then that shared secret can be used for secure communication. That's the basis behind SSL and why SSL is used as commonly as it is since otherwise you have to do the key distribution yourself for every client.

Edit: As CodesInChaos pointed out, any kind of encryption can be used to validate the MAC is valid for the message by an authorized party. It doesn't have to be public/private, but that doesn't really alter the fact that key-exchange is the problem as public/private is more easily dealt with in this particular case than using symmetric keys.

share|improve this answer
    
With HMAC sender and receiver needs to both know the shared secret. That's the difference between a signature and a MAC. –  CodesInChaos Mar 7 '13 at 9:25
    
@CodesInChaos - I suppose that is true, when you don't need authentication, you can use a symmetric key simply to ensure it is unaltered by an authorized party. The way I was taught though, a signature uses an HMAC for signing. Definitely worth clarifying that it can be used either way though. –  AJ Henderson Mar 7 '13 at 14:15

I think you need to question your constraints. If you were able to use HTTP*S* instead of HTTP, then you would be able to delegate all this tedious and error prone key exchange protocol to the browsers or operating systems involved.

Really, this is just Diffie-Hellman key exchange, and trying to create a new solution to an old problem is just inviting trouble.

share|improve this answer

Like Henderson said the design of HMAC is authentication, you 'd better implement PGP. In PGP both party does not need to share their private key, only sending their public key for the other side for encrypting data. HMAC also helps checking the data integrity so you may combining both PGP and HMAC if you like to have secure communication, authentication and data integrity at the same time.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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