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.

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.

share|improve this question
add comment

2 Answers 2

up vote 6 down vote accepted

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.

share|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
add comment

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
share|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
add comment

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.