Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a server in a trusted environment. This server handles requests from clients in an a non-trusted environment. I'd like to authenticate each request and to know if the client code has been tampered or not.

Client software is installed in a secure environment and if I generate some 'secret' (nonces or pseudo-random numbers) and don´t store it in the client, it can assume to be safely-kept.

I thought about using a modified one time password (OTP) with the secret generated at installation time. I could include time syncronization at the client machines as a requirement. The OTP secret key would be derived from the client software md5 hash and maybe some form of hardware id at installation time.

Is there a industry standard way of doing what I want? I really dislike the idea of rolling my own, since I'm hardly qualified to do that.

share|improve this question
As AJ Henderson answered, it's not really possible. The best you can realistically do is have the clients send a hash of their application code (and config files, etc) to your server, and you can validate that against a known value. This will protect you from attacks that are not specifically tailored against your application - eg. if a malicious process modifies all apps running on the client. (If the malicious process is aware of the signing process, it will be able to intercept that validation, rendering it useless.) – Joel L Apr 12 '13 at 16:38

What you are trying to do is a great challenge and currently isn't possible. There has been some discussion about using TPMs to provide a vendor locked trusted environment that could be used as the basis of such a system, but the problem currently is that an untrusted system can not prove itself trustworthy since any inspection a trusted system could do could be faked. You have to have some trusted subsystem on the client that can do the validation actively. When all you have is a request from the client, you lack the access and level of trust necessary to achieve your goal.

share|improve this answer

If you could do what you are trying to achieve, then you could distribute music and video files only to "honest players" who will play the music or video but refuse to save it in a file. The music and movie industries would be very interested. Right now, this goal has eluded their grasp, despite a lot of money thrown at the issue (money is necessary for Science, but not sufficient).

The best known solution, right now, is to have tamper-resistant client hardware: the client code runs on a trusted machine, which will commit suicide if it detects a physical breach. HDCP works a bit like that.

share|improve this answer

Your Answer


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.