2

OK - I'm trying to design a system that can provide personalised/differentiated content at minimal expense to the server.

One of the designs I'm currently exploring is where the request is somehow signed using a key/value pair where the value is secret, e.g.:

Original URL: /posts/foo?format=json

Secret pair (known to server and client):
    ABCDE: 12345

Hash: HMAC('/posts/foo?format=json', '12345')

Actual URL: /posts/foo?format=json&ABCDE=<hash>

(A safer method would be to include in an HTTP header, but let's ignore that for now).

Obviously, a non-safe action would have to have a nonce (to avoid replay) - but I was hoping to not demand a nonce for GET requests, and instead just return the content symmetrically encrypted using `12345' (the secret value) as the key.

This means that the hash for a particular URL could be precomputed by the server, and it could just return the (cached) encrypted content. If the content included a message-digest (again using 12345) then this could be tamper-proof over insecure connections.

Are there negative security implications to verifying using a hash like this, or using this symmetric key as the secret?

(Edited: replaced "sha1" with some HMAC)

cloudfeet
  • 2,528
  • 17
  • 22
  • 1
    I have a feeling you're trying to reinvent [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code). – Adi Dec 13 '13 at 12:35
  • Don't attempt to build a MAC from a Hash. It usually goes wrong, often fatally. Use HMAC, as Adnan suggested. – CodesInChaos Dec 13 '13 at 12:50
  • How would you design your system if server load was not a problem? You may do better to start from there and then optimise your design. – paj28 Dec 13 '13 at 12:51
  • But if at all possible, use SSL. Properly configured SSL (session resumption, etc.) is pretty cheap and prevents many attacks, including replays. – CodesInChaos Dec 13 '13 at 12:52
  • @Adnan, @CodesInChaos - I am not using this as a MAC. The hash is not of the content, it is of the URL and the secret. The goal is to get an unguessable (but predictable if the secret is known) value for `ABCDE` for each URL. – cloudfeet Dec 18 '13 at 17:21
  • @CodesInChaos - Replay attacks are an issue - but what replay attacks can one perform with a GET? – cloudfeet Dec 18 '13 at 17:29
  • 1) For the key reuse part see [Why can't I use the same key for encryption and MAC?](http://security.stackexchange.com/questions/37880/why-cant-i-use-the-same-key-for-encryption-and-mac) 2) You are using this as a MAC on the url. The requirements you listed are those of a MAC. Most homebrew MACs are broken, your original design was flawed, but not as bad as some similar variants. 3) I still think SSL is far better than any of this. – CodesInChaos Dec 18 '13 at 18:45

1 Answers1

3

As I read it, your question boils down to: is it safe to use the same key for both symmetric encryption of some data, and a MAC on some other data ?

It is possible to build a (somewhat contrived) example where such usage is not safe. For instance, the symmetric encryption could be a custom stream cipher where the stream consists in HMAC values computed over successive value of a counter; in that case, the MAC using the same key could interact with encryption and leak information. However, with "normal" encryption algorithms and HMAC, risks are low. The same could not be said if the MAC was CBC-MAC: using the same key for encryption in CBC mode, and for CBC-MAC, is a deadly sin.

In general, it is best if each individual key serves a unique purpose. The generic method, here, is to have a "master key" K, and derive from that key, using a one-way Key Derivation Function, a key for encryption and another key for the MAC. In practice, this can be as simple as hashing K with SHA-256, and splitting the 256-bit output into two 128-bit halves; the first half is to be used for the encryption, the second half for the MAC. This is secure based on some partial one-wayness assumptions over SHA-256, assumptions which are quite reasonable.

SSL itself uses its own KDF, which is called, in the SSL specification, the "PRF".

If the secret key is somewhat weak, i.e. is derived from a password, then attackers observing the exchange may use what they saw to run an offline dictionary attack, i.e. try potential passwords; this is "offline" in the sense that attackers do that on their own machines and don't have to talk to the honest server for each try. Offline dictionary attacks are a problem. Running the protocol within SSL is a good way to thwart such eavesdroppers.

If there is no SSL, the same attackers could turn active and modify the encrypted data returned by the server. Thus, the encryption system should also include its own MAC. Combining MAC and encryption is known to be tricky, so modes which do the job properly (like GCM) are highly advisable.

More deviously, attackers could also make fake errors. If you send your GET over plain HTTP, an active attacker could intercept it and return a fake 404 response: since there is no encrypted data in a 404 (indeed, the point of the 404 is to state that there is no data at all), the client has nothing to verify, and cannot reject the 404 message as fake. Depending on what you use your protocol for, this may induce security issues. To protect against active attackers, all responses from the server should be authenticated, including negative responses (404). But, at that point, you are on the verge of reinventing SSL...

On a similar vein, an active attacker could return an old response from the server. Suppose that at some time, data block D1 was stored on the server, and could be obtained with a GET. Later on, the data block is updated with D2. However, the key has not changed, and the GET request from the client is still the same. An active attacker could substitute the D2 from the server by a copy of D1, as previously intercepted.

This can be avoided by using a nonce -- a client nonce, sent by the client; the server then must dynamically compute a MAC on what it returns, and the MAC input must include the client nonce. At that point:

  • the protocol is no longer as lightweight as could be hoped for;
  • this really looks like a homemade SSL.

Summary: it is not easy to outperform SSL. SSL is relatively complex, but that complexity is (mostly) intrinsic to the hardness of the problem at hand. A communication protocol which resists to impersonations, alterations and replay attacks, will have to include a number of finely tuned cryptographic elements, and will not be substantially simpler or cheaper to operate than SSL.

If you can arrange for your client and server to share a common high-entropy secret key, then TLS PSK cipher suites will give you good performance and about as little complexity as is possible (no certificate, no asymmetric crypto).

Community
  • 1
Tom Leek
  • 168,808
  • 28
  • 337
  • 475