I'm in the process of designing a system that consists a client application and a single web-service. The client is distributed on several machines (installed by me or a colleague), and the communication between client and server is over the Internet.

What I'm looking for, is a way to ensure that the web-service can only receive requests from those physical machines that I originally installed the client-application on.

The computers will be running some kind of Windows, I'm not exactly sure which edition yet. And the web-service will be WCF-based.

My current thought is to install a client certificate on the machines, and use that for authentication on the web-service. I'm unsure of how or if there is a mechanism to lock the certificate to the physical machine, or just password protect it in order to prevent it from being exported and installed on another machine.

My knowledge of certificates is very basic, which is why I am asking if this seems like a viable approach, or if there is another way that would work better.

Edit: I realize that my original question was a bit vague about how secure I want this to be.

The client-application may be considered as a daily annoyance to the users that are forced to use it. And one of the points with the application, is to be able to tell that a person was at this location/computer at a certain point in time. So I want to be able to tell from my web-service that the request did not originate from "my machine". This is all in order to prevent the "annoyed user" from thinking up schemes to avoid having to be at the location where the client-app computer is located. Such as simply copying the application to a laptop computer.

So, it is more about preventing the simple ways to get around using my installations of the application from one of my computers. And the user type isn't someone with an IT background.

Thanks for the many helpful answers so far

  • Do you mean only reply to requests from the physical machines? Only receiving requests would mean a network component validating and authorizing packets to be sent to the web-server machine, thus no unauthorized packets would reach it.
    – this.josh
    Jun 9, 2011 at 20:03
  • Yeah, you are correct, i meant reply to requests. Or actually, just be able to tell that the request came from one of "my" machines.
    – Tom Jelen
    Jun 9, 2011 at 20:18
  • Some background on your requirements and threat model and how much you want to spend would help. E.g. are you trying to prevent the users from transferring the client to a different machine, after disabling its use on the previous one? Or you really care about which hardware (CPU? Motherboard? Disk?) that it runs on?
    – nealmcb
    Jun 11, 2011 at 2:11

4 Answers 4


How concerned are you about an insider threat and how savvy would you expect insiders to be? That's your biggest factor. Almost any security mechanism you put on the machine's hard drive can be cracked if the attacker gets a hold of or too much access to the hard drive. How long that will take will be a factor of how well you've secured the drive.

I can think of a lot of ways to do this:

  • IP filtering (spoofable)

  • set up IPSEC tunnels during install

  • Certificate based authentication

  • Require VPN authentication with something like a pseudo random key generator on a token

Anything is hackable, given the right threat.

Each mechanism has different ways of being attacked or compromised. IP addresses can be spoofed, IP Sec tunnels or certificates can be compromised if the attacker gets into the hard drive or people do something dumb with the computer's security data. Key generating tokens are great for being separate from the machine, but it requires COTS software and can get pricey.

Certificate authentication via client authenticated SSL is usually not too bad to configure - web servers will do a very simplistic authentication scenario, and you should be able to restrict your server to a list of clients that you trust based on the certificate's distinguished name. If you use software certificates, it means you will have to install a separate private key for each client. That means some level of diligent key management. You can upload private keys into browsers or other certificate stores with a rule to the OS not to export the private key. Some of this can be hacked or changed depending on the user's privileges, thus the question of insider threats.

If you limit your certificate authentication to SSL client auth, you won't have to change any of the logic of your web service unless you also have more specific privilege management requirements.


First of all, you need good session ID management in your Web Services.

Secondly, I'd recommend something like the Cookie Revolver Framework to tie the client-side certificate to machine IDs (e.g. MAC address of NIC and/or serial number from a hard drive) and static IP addresses. However, these can probably be faked using virtualized hardware in this day and age very easily.

I'd go for something where the client-side certificate was stored on something like an Aladdin USB eToken (2048-bit would be nice), but then you physically glue and otherwise prevent tampering of the device into a USB socket. That doesn't really work well either -- but perhaps a onboard TPM chip would? Try TrouSerS, it looks like they have EAP-TLS authentication based on TPM identities.


It sounds to me like the best approach here is to install a client certificate with the thick-client installation. If you wanted to add another layer, you could do something with firewall filtering, with the client updating a whitelist when it becomes active.


You can do several things that make it difficult for the end user to extract the certificate. Use of the Windows CryptoAPI and the local certificate store can make exporting the private key difficult (if not impossible) and allow your application to take advantage of the CSPs to pass the requests to the Web Service.

From your profile, I'm guessing you wrote the client in .NET so you're likely to find most of this on the MSDN resources at hand. (Though here's a place to start: http://msdn.microsoft.com/en-us/library/ms867080.aspx )

I can't find anything regarding whether or not preventing export of the private key has been circumvented from the certificate store, it doesn't mean it's not possible, but if it has been done, it's harder then a Google search to find.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .