2

I have an client/server architecture that periodically sends very small (10 or so bytes) UDP packets back and forth, which I'd like to authenticate without a large overhead in bandwidth or processing. Note that I don't care about an adversary seeing the plaintext, only I'd like to prevent them from modifying and re-transmitting the packets.

Here is the process I'm envisioning:

  1. User authenticates themselves with a username/password over HTTPS. Nothing out of the ordinary here.
  2. Server replies with a success message and N bytes (maybe around 32 bytes) of cryptographically generated random data. Both the client and server remember this string of data as their common_secret.
  3. At this point the HTTPS connection is closed and all further communication will be via small UDP packets, using this scheme for authentication:
  4. packet = plaintext + sha2(plaintext + common_secret)
  5. On receiving a packet, the server will calculate the same sha2 from the plaintext and its common_secret, and check that it matches the hash at the end of the packet.

An adversary will not be able to construct a valid packet without knowing common_secret. Is this a valid authentication scheme?

Joel
  • 1,069
  • 1
  • 8
  • 7
  • 3
    You system is basically secure, although it does not prevent replay attacks. You could consider HMAC which is a slightly better way to hash with a secret. Or even DTLS which is SSL over UDP. – paj28 Aug 03 '16 at 16:12

3 Answers3

3

Vulnerabilities in your method

Your construction is most likely vulnerable to a length extension attack which allows for the modification of the message, as well as a replay attack which allows for the resending of previously send messages.

Obligatory: This is why you shouldn't roll your own. Instead, use existing solutions for the problems you want to solve.

Secure Approaches

A solution against the first issue is to use a proper HMAC. If you do need protection against replay attacks, you need to exchange nonces or similar.

tim
  • 29,122
  • 7
  • 96
  • 120
  • SHA3 doesn't have length extension vulnerabilities, but neither does a sha2 hmac... – dandavis Aug 03 '16 at 17:03
  • 1
    @dandavis OP isn't using SHA3. And I haven't tried it in practice, but from what I can find online, sha2 as used by the OP does seem to be vulnerable. It's true though that sha2 HMAC would not be vulnerable, that's why I suggested to use a proper HMAC. – tim Aug 03 '16 at 17:06
  • just saying SHA3, or another sponge function like spritz, could be used instead of SHA2 to avoid LEAs. Sponges let you naively concat up reams of predictable data and then a little secret (> brute) and it's fine. – dandavis Aug 03 '16 at 17:07
2

No, it is not secure. As @paj28 points out, there are "obvious" replay attacks. There's a reason for each bit of overhead in DTLS and IPsec's auth mode. (Well, most of IPSec's auth mode.) You should just use one of them.

The same logic that leads to "Those who do not understand TCP/IP are doomed to reinvent it, poorly" applies here.

Adam Shostack
  • 2,659
  • 1
  • 10
  • 12
0

your algorithm looks like you are trying to complete integrity. use a HMAC instead for your signature. adding a nonce will require you to exchange further nonces adding to the complexity of having to exchange these again.

maybe use

HMAC with EPOCH

but now you must ensure both sides clocks are in sync and continue to work with DST if this applies, the epoch obviously only allows you confirm freshness within x seconds depends on latency if your network.

so maybe;

plaintext + HMAC(plaintext+epoch)

the fact you are using a HMAC means your secret is now the key for the HMAC.

as others have said inventing your own crypto is usually a bad idea.

why not sign with asymmetric encryption if available to you ?

Darragh
  • 1,102
  • 9
  • 15