24

Is it fundamentally possible to validate that an unmodified version of your client connects to your server?

I was just thinking about the idea of having my client-side app hash its own source code and sends that as a key to the server with any requests as proof that it's unmodified, but that's silly because anyone could just have the client send a hash of the unmodified version via a modified version.

I was wondering if there might be a secure way to do this though, via some sort of proof that the client was unmodified.

kelalaka
  • 5,409
  • 4
  • 24
  • 47
J.Todd
  • 1,300
  • 1
  • 10
  • 20
  • 1
    Regarding your "password" approach, this is exactly how [API keys](https://en.wikipedia.org/wiki/Application_programming_interface_key) work. However, that will only uniquely identify the *user*; it will not verify that the user is using your original software (rather than, e.g., a written-from-scratch clone). – apsillers Sep 23 '14 at 18:55
  • @apsillers I think that would be ok. I'm not worried about a legit user causing problems. If you put that up as an answer I'm happy to select it. – David Thielen Sep 23 '14 at 19:03
  • 7
    If you think that validating the client is the solution, then you are asking the wrong question. – rook Oct 31 '14 at 19:29
  • @Rook lets say I build an app environment where apps are verified for quality before being allowed onto the store. I want to check that the apps do not dynamically change their functionality, thus cheating the system. – J.Todd Oct 31 '14 at 19:36
  • 17
    Your application is a guest on the attacker's machine, and guests need to follow the rules. The attacker makes all of these rules. – rook Oct 31 '14 at 19:39
  • @j0dd What if the application's code consists of an interpreter? Are you going to ban it from reading files? Would you ban its files from changing? – Doval Oct 31 '14 at 19:39
  • @Doval I don't know it was just a thought. Seems impossible either way based on the answers though. – J.Todd Oct 31 '14 at 19:52
  • 6
    It has a name. Know it. "Remote Attestation" – Joshua Oct 31 '14 at 20:55
  • 4
    In the bad old days the server for the Windows version of AOL Instant Messenger sometimes sent a challenge. It was an address in the code space of the AOL-furnished client, and the client responded by sending whatever binary data was at that location in that version. A wrong answer resulted in a server-initiated disconnection. – O. Jones Nov 01 '14 at 18:38
  • This has a name... trusted platform. Yes, "trust" is an utterly bad wording for something that is only meant to take away user rights. If Microsoft and the American Movie Industry get their way one day, this will be possible (as long as nobody runs your client on an old computer which doesn't enforce the TPM shit). – Damon Nov 03 '14 at 11:00

6 Answers6

37

It is fundamentally impossible to validate a client on a system you don't control.

That doesn't mean it can't be done to a sufficient degree. eBook readers, for example, generally try to ensure the client is authentic. They (seem to) do so in a manner that is secure enough to defend against their threat. Good enough to protect nuclear secrets? No. But good enough for their threat environment.

Figure out how important that control is for your application, and determine the compensating controls you'll put in place to limit the damage when someone goes through the trouble of ripping apart and then mimicking your application. Don't think in terms of black/white, possible/impossible; think in terms of acceptable and achievable security.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 10
    In other words, it boils down to the old joke: You don't have to run faster than a a bear to escape it; you just have to run faster than your friend. You have to make it annoying enough to reverse engineer your application that people will go after something else (like downloading videos using bittorrent rather than your video-on-demand service). – ntoskrnl Nov 01 '14 at 14:18
  • Not sure I understand why this is correct. A hacked client needs to mimic a valid client. The hacked client cannot always be precompiled, because that would require reverse-engineering the original client which is equivalent to solving the halting problem. Therefore, for a sufficiently complicated client, the imitation must interpret the code on the fly rather than recompile it. That necessarily introduces extra delay, which can be detected by the server by measuring response times. Hence it should in principle be possible, shouldn't it? – user541686 Nov 02 '14 at 10:41
  • @Mehrdad If you like hypothetical reasoning then you should also take into account the [speed up theorem](http://en.wikipedia.org/wiki/Linear_speedup_theorem) which basically says that: no you can make the interpreter run as fast as needed, given enough resources. – Bakuriu Nov 02 '14 at 12:25
  • @Mehrdad: any VM is essentially an interpreter; clearly the perf cost here isn't necessarily huge. – Eamon Nerbonne Nov 02 '14 at 13:23
  • 1
    @Mehrdad You cannot (or at least should not) rely on response times in a client/server environment that runs over the Internet, at least with any level of precision necessary to do what you suggest. You have no idea what kind of connectivity the client has, what happens to the routes each packet takes, and how many people along the way are trying to stream Netflix along the way... – lc. Nov 02 '14 at 13:56
  • @Mehrdad, nothing says the hacked client is the same code base as the valid client - it just has to present correct enough inputs to convince you it's the valid client. And [timing can be closely analyzed](http://users.ece.cmu.edu/~dawnsong/papers/ssh-timing.pdf) and, if necessary, mimicked. – gowenfawr Nov 02 '14 at 13:59
  • Has anyone actually proven this? I have a vague idea for a proof: If someone has enough access to your client to be able to run it, he must have enough access to your client to be able to reverse-engineer it. Sounds like something Turing or someone might have proven already. – sudo Jul 03 '15 at 22:17
20

It is fundamentally impossible to validate that an unmodified version of your client connects to your server.

... unless you do what is necessary to ensure it. This means client-side tamper-resistant hardware.

When your code runs on the client's computer, the computer owner can run a debugger and modify the client code at any point with arbitrary values. The "debugger" can be a full-blown virtual machine. If you want to avoid that, you can try to engage in an elaborate hide&seek game where you imagine extra detection systems, and attackers counter these with variants of their own tools. This is the problem of people trying to design anti-cheat software solutions (e.g. PunkBuster); this is also the problem of people who want to sell Video-on-Demand services while preventing the customers from saving the videos locally and then publishing them on various file sharing platforms.

To sum things up, these protections don't work well, even when the data to protect is as trivial as extra lives in some game.

To avoid this, you have to make your code run on protected hardware, that will defend itself against deep inspection from its presumed owner. This is the model of gaming consoles, payment terminals and smart cards.

A TPM is an attempt at a compromise: a tamper-resistant module running within what is otherwise a normal PC; the assumption here is that a normal user will find it too hard to modify the hardware to, for instance, read and write all the RAM without going through the pieces that are under supervision of the TPM module (e.g. the CPU).

Without such hardware on the client side, what you are trying to do will not work. Unless altering the client code would be so worthless than nobody even tries. It all depends on the value of what is at stake here.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 4
    And even then the cat and mouse just moves into hardware via mod chips. I suppose the end game looks like attackers fabbing complete chip clones with modified TPM blocks. – Zan Lynx Oct 31 '14 at 20:12
  • The step in the cat and mouse game beyond that is hardware that has anti-tamper sensors in the enclosure and will wipe itself if they go off. Even that will probably fail against a determined attacker with deep pockets for anything in the mass market since the attacker can just keep buying more until they eventually defeat the intrusion detection system. – Dan Is Fiddling By Firelight Oct 31 '14 at 21:16
  • @DanNeely: Actually, I believe if you keep the original chip around you can probably pass the authentication requests in and out of it. You might even be able to do the network encryption through it as long as it doesn't check that the encryption request comes from an authenticated execution page. – Zan Lynx Nov 01 '14 at 00:59
  • 9
    So, the problem of "program running on a computer controlled by client" is reduced to the problem "how do I ensure total control over client computer". – Peteris Nov 01 '14 at 10:19
  • 1
    @Peteris Which, coincidentally, happens to be something very desirable to malware writers. – Riking Nov 02 '14 at 09:09
12

You could try Cryptographic Obfuscation when it exists

Cryptographic Obfuscation is where, in certain senses, you make a programs source code unreadable. What you can then do is hardcode a cyrptographic key into the program. You would also want the server to supply a random seed to your program since the computer could not be trusted. The only problem with this approach is the Cryptographic Obfuscation is that it has not yet been implemented, and also that only certain senses of it are possible.

PyRulez
  • 2,937
  • 4
  • 15
  • 29
  • I read through it; very neat, and very much an answer to my question, as a whole. – J.Todd Nov 01 '14 at 03:15
  • @jt0dd It is possible to change what to accepted answer is in case you are wondering. – PyRulez Nov 01 '14 at 03:32
  • 4
    Well the article explores the subject in depth, but your answer doesn't / doesn't have important parts such as a clear answer to the question (which is "no" it seems). Your answer would need to discuss the relevant contents of that article though. +1 for the article though, very interesting – J.Todd Nov 01 '14 at 03:37
5

I too have approached an issue such as this with the company I work for. after weeks of working it out, the answer is its not really possible.

And here is why:

You're basically encountering a "Trusted Client" problem. The client code runs on the user's PC, and the user has full control over the PC its originating from. The user can change the bytes of the program on disk, or even in memory in some cases. If you were to try to perform a hash or checksum against the code, he could simply change the code that did that verification and make it return "unmodified". Its a smoke and mirrors tactic.

You could try to make things a little harder on a malicious user but there's no practical way to achieve what you're hoping. Not without it becoming a large headache.

Cameron Does Things
  • 582
  • 3
  • 10
3

You can use HTTPS together with client certificate authentication. Then you can ensure that only clients with a valid certificate are able to use your site.

The client certificate will then replace the password you mentioned and the user will not notice the magic done in the background.

Uwe Plonus
  • 2,267
  • 12
  • 14
  • I don't think our customers will be willing to hassle with a certificate. I wish they would, but people find that a pain. – David Thielen Sep 23 '14 at 19:02
  • 1
    @DavidThielen you can create a certificate with the first start of the application and use this. Then your customers don't even know this. The security is weakened then but in your case it should be OK. – Uwe Plonus Sep 24 '14 at 04:28
  • 1
    If the app on the client system creates the certificate the first time it runs, how do we know when it is used that it is truly from them. Do we trust that first time and then we're safe from then on? Thanks – David Thielen Sep 24 '14 at 16:54
  • 1
    Yes, you trust it the first time and save it then. So at the second connection the client is already known. – Uwe Plonus Sep 24 '14 at 19:54
  • 1
    Thank you. If I could select two right answers I'd select this also. – David Thielen Sep 24 '14 at 22:50
2

If you want to uniquely identify the user, API keys will work well for you. In order to use Facebook's API, or Stack Exchange's API (etc., etc.), you'll need to get an API key to identify yourself as a particular user of the API and send that API key with every request. Thus, every request that hits the API can be traced back to an originating user. This also allows the API owner to control who accesses the API by restricting who is allowed access to an API key.

However, that will only uniquely identify the user. It will not verify that the user is using your original software (rather than, e.g., a written-from-scratch clone). Verifying that the user is using your original software is virtually impossible, since it relies on the assumption user doesn't have control over his or her own computer and can't, e.g., run the program in a debugger and change software instructions at will.

apsillers
  • 5,780
  • 27
  • 33