How is the HMAC key exchanged?

Question

Just wondering about this. Does it need a PKI to work?

Answer 1

An HMAC key is a symmetric key, i.e. a bunch of bytes. The "symmetry" relates to the following important fact: the very same key is used both to produce a HMAC value over some message, and to verify the HMAC value over the message. In that sense, HMAC is not a digital signature algorithm (but some people are nonetheless talking of "signatures" about HMAC, which is both wrong and confusing).

Distributing symmetric keys is a complex endeavour for two reasons:

• A secret value which travels is "less secret" because travel implies extra risks of exposure.
• A secret can remain secret only if not too many people are aware of it. Therefore, if n people must be able to do symmetric cryptography with each other, you more or less need a shared secret per pair of users; so there will be n(n-1)/2 symmetric keys in the whole system.

To make things easier, public-key cryptography was invented. It is also known as asymmetric cryptography; when used with digital signatures, the key used to generate signatures is distinct from the key used to verify signatures; they are mathematically linked to each other, but it is not feasible (or so we hope) to recompute the signature generation key from the signature verification key. Therefore we can afford to make the latter public, hence the name.

Public-key cryptography makes the key distribution problem substantially easier:

• The public keys are public, so confidentiality of transfer is no longer an issue.
• Each user only has one public/private key pair, so there are much fewer keys altogether in the whole system.

Now public-key cryptography makes key distribution easier, not easy. You still have to come up with something which allows user to make sure that they use the right public keys. This is where PKI comes into play: a PKI is a system to distribute public keys.

---

So how would things go in practice ? Consider SSL/TLS, often used in combination with HTTP, yielding HTTPS. When a Web browser connects to a HTTPS-powered Web site:

• An initial "handshake" procedure is performed, where the server shows his certificate to the client (the browser). This is PKI. The certificate contains the server's public key, and is signed, and that signature is the incarnation of the PKI. The client verifies a bunch of signature and is finally convinced that the public key it sees really is the genuine public key from the intended server.
• Using the server's public key, more asymmetric cryptography occurs (this time a key exchange, possible based on asymmetric encryption, not signatures), which ends up with a nice result: client and server now know a shared secret value, and nobody spying on the line would be able to rebuild that value.
• The shared secret value is then expanded (with a Key Derivation Function) into several symmetric keys, which the client and server will use to encrypt and MAC whatever data they then want to send to each other. In SSL/TLS, the usual MAC algorithm is HMAC.

The complete picture is that PKI is used to distribute public keys, and these public keys are then used with asymmetric cryptography to dynamically create a shared secret, and that shared secret is then used with symmetric algorithms such as HMAC.

So you do not distribute HMAC keys directly with a PKI; there is one intermediate layer.