5

A basic question, but I'm not a master and this is puzzling me-

How is it possible to authenticate a client from the server's perspective?

i.e. imagine you're the server, and you want to give the client a key, but only if you're sure that the client is really the software you wrote and not someone pretending to be your software so that they can grab the key?

The only solution I can think of is various combinations of hardcoding a private key in the client, or hardcoding a predictable algorithm (i.e. server says "n" and client must say "n*2" back)... but any of this is crackable via decompiling... ?

In case it matters, the client-software needs to be O/S agnostic, i.e. run on windows, mac, linux, android, ios, etc.

|improve this question
6

It's not possible to authenticate a client in this way. As you correctly point out, it can always be reverse engineered and duplicated. Server authentication only works because the user doesn't have access to the server hardware, and to produce a secure client you must find a way to block the user from accessing the client hardware, which is generally impossible.

|improve this answer
  • Thanks Mike... so, if you don't mind- how does drm work where it needs to be able to send a key to the client to unlock the media, but ensure that an impersonator can't actually grab that key by pretending to be the client? – davidkomer Jun 17 '12 at 16:50
  • Note that most DRM today can be evaded. Also note that DRM is algorithms are quite expensive to purchase and complex to implement correctly. – Lucas Kauffman Jun 17 '12 at 20:24
  • As Lucas says, DRM doesn't really work. There aren't any widely-used DRM that haven't been cracked, precisely because the attackers have access to the hardware which contains the keys. – Mike Scott Jun 17 '12 at 22:26
0

Let me think out loud for a second. You could use a checksum of the client binary's files. If your hashing function is collision resistant - say SHA-1 for example - you can be sure that the client is authentic with very high probability.

Basic schema for the protocol:

  • Client Hello
  • Server Hello
  • Client ACK || checksum
  • Server Auth. finished
|improve this answer
  • 1
    What is to stop an attacker with different software from just from sending the correct checksum to the server? – Mike Scott Jun 18 '12 at 15:22
  • If you have found hash(a) = hash(b), when a != b, then you have a collision on the hashing function. That's why i emphasize the use of a collision resistance hashing function, meaning that it's hard to find a collision. – a0viedo Jun 18 '12 at 17:07
  • You don't have to find a collision, because what you send is just a number. It doesn't actually have to be a hash of anything. Just because the authentic software hashes itself and then sends the hash value doesn't mean that your attacking software has to work the same -- it can just send the correct hash value. – Mike Scott Jun 18 '12 at 17:46
  • This construction provides only software integrity. As mentioned by Mike, if an attacker can compute the hash on the binary files then he could create any malicious application and simply send the hash precomputed before. – a0viedo Jun 18 '12 at 18:14
  • Sure another person could do a timing attack on a request for the checksum, but bear in mind, the commands to the server are always meant to be particular only to the logged in user. i.e. you do it to yourself. The idea here is to keep the tampering contained only to the logged in user and not affect everyone else. – munchkin Apr 28 '15 at 9:55
0

It's no possible to distribute a software to clients that can connect but cannot be impersonated. You can make it hard by obfuscating the key, but never impossible.

With this in mind, I'd pick:

  • Use TLS with per-client keys (signed by your own CA).
  • If a client misbehaves, you blacklist their key and move on. No-one else is affected.
  • If a key gets filtered, you can simply provide a new one to the client (probably obfuscated inside a new binary).
|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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