How to ensure that only a well defined client talks to a Web service (WCF)?

Question

4.86/5 (6 votes)

See more:

Hi all,

I need to develop a client/server architecture:

- language c#
- native client
- server: web service, may be wcf service

The biggest challenge ist to ensure, that only our client software can talk (send data) to the web service.
I protect the client itself with a digital certificate and some other things so it can't be modified. But how to make sure that nobody captures the network traffic and then sends faked data to the service. SSL is not possible.
Can I use the public key from the digital certificate (Microsoft Code Signing certificate) to encrypt the data before sending? But if so, someone else could also use this public key to send encrypted data to the service.

What would be the right (a good) solution for that problem?

Thanks.

Thom

Posted 16-Feb-11 20:12pm

ThomT

Updated 17-Feb-11 6:33am

Sergey Alexandrovich Kryukov

v2

Add a Solution

Comments

Sergey Alexandrovich Kryukov 17-Feb-11 2:17am

Pretty interesting yet practically sound Question, my 5.
--SA

Sunasara Imdadhusen 17-Feb-11 2:24am

Good question!!

3 solutions

Solution 3

I found a part of the solution by myself so I post it here as answer.

I've to use a client certificate for Authentication.

I have to set the 'Client Credential Type' to Certificate. I also found how to use a certificate from a file and not from registry: An easy way to use certificates for WCF security[^]

But again there are 2 questions open:
1.
Can I use for this also the already available code signing certificate? I think not because the client needs the private key of the certificate and this is something I will not give out.

2.
How do I make sure that no other program uses my certficate to identify itself against the server service? I need to copy the certificate to the client computer and so, everyone could use it (or simply post it in the inet for everybodies use). I know I can protect the certificate with a password but this password must be then inside my exe which can be decompiled.

What is the complete solution?

Thanks
Thom

Posted 17-Feb-11 2:08am

ThomT

Comments

Sergey Alexandrovich Kryukov 17-Feb-11 13:43pm

I answered your questions in my comment to my Answer, please review it, then respond.
Again, available certificate will not help.
What really can make your application to be different is if you sign the application with the same key used as a proof of its ability to decipher the Token. Modified client application will not be able to run at all, newly created fake client application will not be able to decipher the Token.
--SA

Solution 5

Part 2

This is a different Answer based on clarification of the problem. Previous Answer is named as "Part 1", this one will be "Part 2".
The Answer in Part 1 remains valid, but it's based on the assumption that a trusted channel for distribution of software certificate can be created. Initial requirements (no SSL, etc.) are related only to the Service and Client run time when client software is already deployed; there were no limitation on the mechanism of deployment.

According to the clarification, Client software is freely distributed to some anonymous clients, so there is no way to distribute any information secret from third party, which opens the possibility to forge Client software with modified behavior which could mimic the same authentication procedure a legitimate Client software can pass. How that is possible? 1) It is useless to spy on network package during exchange of Authentication Token, because these packets are used only once (see Part 1), 2) it is not possible to modify original Client software keeping its digital signature, because the assemblies can be signed and a private key is stored at software team only. Nevertheless, it's possible to run Client software under debugger and capture the K_u key before decryption of the Authentication Token.

That leads to one obvious solution which I don't really like. The client software should be protected with one of the powerful software protection tools which, in particular, make both code analysis and debugging impossible (I have experience working with XHEO Code Veil, http://xheo.com/products/code-protection). The problem is that powerful solutions are proprietary. The real problem is not even license and royalty costs which can be considerable, but the lack of opportunity to evaluate strength of protection and validity of company's claims. That will solve the problem in principle, but again, it doesn't make me satisfied.

Unfortunately, this is inherent problem of the approach when the modification of Client software is freely distributed and the possibility of the modified Client behavior presents a threat. I already expressed my concern: this can be considered as the bigger architectural problem, a fragility of the general data model. However, I clearly realize that rethinking of this model can be not feasible.

Part 3

The schema with software protection (Part 2) was actually a combination with Part 1, a plan "B". I think the problem needs a radically different approach, plan "C". It should not require global change in the architecture and sit in the thin communication layer between Service and Client.

My idea is moving all business logic from Client part to Service, where it is not accessible for modification. This is relatively small modification of the architecture. There can be different approaches.

One obvious approach is transforming of the application into ASP.NET tier to represent the complete communication layer between Service and Client. This is quite doable. The potential problem is significant change in client capabilities due to limitations of HTTP protocol.

Alternative approach is to stay with regular UI-enabled client working through the transport protocol, but cleared from business logics, which is moved to the Service-part counterpart. Here I have some preliminary schemas which need some extra thinking.

—SA

Posted 18-Feb-11 11:46am

Sergey Alexandrovich Kryukov

Updated 18-Feb-11 13:06pm

v3

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2011-02-16T21:40:00

Solution 1

Part 1

This is absolutely possible. This is quite apparent, but logical proof of the method needs effort.

First, let's do our assumptions. I you cannot accept some of them — I have a plan "B".
First, we need to consider three parties: Service S, Client C and "Middleman" M; Middleman is able to spy on all communications between C and S. Apparently, M would not be able to impersonate C only if C has certain "benefit" over M. Not breaking the level of generalization, let's assume that the benefit is certain key C receives in its deployment bases on user authentication. The full source code of client can be open, only a key is secret.

Now, let me assume you know the method of deployment of the key to all clients even over Internet (without SSL) the way M cannot get this key even it it spies all the time. I assume that because this is a well-known method. I you're not sure it's possible, read this: http://en.wikipedia.org/wiki/RSA[^]. If your not convinced yet, I'll explain that on you request.

Now, I'm going to do the easiest assumptions on communication method. 1) It should be session-based non-secure protocol (HTML or TCP), 2) The session is divided in two parts: authentication followed by trusted; during authentication part client and service exchange messages used to proof authenticity of the client; after that, client is considered trusted and further work is done without any encryption. You did not require secret data communication, only authenticity of the client. If these two assumption are not OK, I can discuss plan "B" on further request.

Now, let's use same very RSA and create two keys. Further speculations are meant to maintain that the method is as strong as RSA. RSA is implemented in .NET. Let's follow the steps.

1) Generate two keys using RSA key generation function RSA => (K_s, K_d).
The function has no "backdoor": it is not possible to calculate one key base on knowledge or another key. I'll call K_s a "encrypting" key, K_d — a "decrypting" key:

(unencrypted data, K_s) —> (encrypted data)
(encrypted data, K_d) —> (unencrypted data)

2) Let's deploy K_d with C.
At this step, S has K_s and K_d, C has only K_d, M has not keys or data.

3) S starts, listen to connections, C connects, S accept (new) connection.

4) Authentication part of session protocol started. S generates "Authentication Token" T_u (unencrypted) and encrypt it into encrtypted token T_u:
(T_u, K_s) —> T_s, and sends it to a connected client C. New T_u is generated randomly for every new session.

5) C use K_s to decrypt T_s:
(T_s, K_u) —> T_u.

6) C sends T_u back to S openly, S compares its values with the value stored before sending it to C. That creates an evidence of C. Trusted part of protocol starts.

7) At this point M has both T_s and T_u. It cannot be used for impersonation of C, because it would require to connect to create a new session; but for this new session Authentication Token will be new, not known to M. Also, as there is no RSA "back door", M cannot obtain any of the keys from data.

If there is a reason to concern about open sending of T_u from C to S, this part also can have plan "B" based on additional pair of keys (one of them will be open and known to M to make this part of communication a secret from M.

That's it. Any concerns, further questions?

—SA

Posted 16-Feb-11 21:40pm

Sergey Alexandrovich Kryukov

Updated 19-Aug-14 9:20am

v9

Comments

Sandeep Mewara 17-Feb-11 5:34am

Wooo! 10+

Bookmarked... need to give concentrated time to understand all.

Sergey Alexandrovich Kryukov 17-Feb-11 19:19pm

Thank you, Sandeep.
This is not really difficult, the clear identification of goals here is a major concern.
--SA

Sandeep Mewara 17-Feb-11 5:34am

BTW, comment from OP:
Hello SAKryukov,

first of all, thank you for your considerations.

Concerns? Yes.
I understand the way how the keys are exchanged. But the problem still is, that someone could write a fake client, which looks for the service like the real client. The faked client could also implement the key exchange protocol and so be treated as our client. So my point is not to secure the communication itself but to proof the correctness of the client against the server (service).

As I wrote:
'to ensure, that only our client software can talk (send data) to the web service.'

Or do I miss the point? It would be nice if you could clarify this.

Thanks.

Thom

Espen Harlinn 17-Feb-11 9:31am

A very good effort, my 5++

Sergey Alexandrovich Kryukov 17-Feb-11 19:21pm

Thank you, Espen.
Let's see how it will finally resolve. Quite interesting Question, anyway.
--SA

Nish Nishant 17-Feb-11 12:41pm

Voted 5, good response. Long enough to be a Tip/Trick :-)

Sergey Alexandrovich Kryukov 17-Feb-11 19:20pm

Thank you,
As you can see, this is not finished yet.
--SA

Sergey Alexandrovich Kryukov 17-Feb-11 12:45pm

>Concerns. Yes.

You're right, but... let's see what you can have in principle. First of all, impersonation problem is not symmetrical to the problem if secret communication. That's it, with symmetric ciphering, secure conversation between C and S is based on the fact that M can read it all but not be able to decipher, while M can also exchange secret messages. False impersonation is inherently more difficult.

When you say "The faked client could also implement the key exchange protocol and so be treated as our client", why can you call this client "fake"? You say "only a well defined client talks to a Web service". If this "fake" client uses your legitimate application, this is what you want to care about (see below). Is it not? Then formulate a different problem, say "I want a client to pay for service". Then include payment in the process of key exchange!

What I say means you can only have what you can have. Essentially, you're trying to say: "I do not want a client to be different from others, but I don't want it to be different". The clients should be certified. At this moment, I left if for granted. Now, let's consider who you can certify them. First of all, certification authority cannot help, because your service has the most authority in your eyes.

Maybe, your goal is different. What you really can do is making your software non-modifiable. You could have your software digital signature to be used as a key. So, anyone can impersonate the legitimate client, but the client cannot modify software. It is not even possible to write client software to mimic this; the forged client can reproduce all aspect except a key, because private part is stored at the development side (and not even stored at the server; server has a public key, software team has both, deployed software has a way to use the key for the proof of authenticity, but the key cannot be forged). That’s the solution.

At this moment, you need to decide what protection you really need.
--SA

ThomT 17-Feb-11 13:46pm

May be I think in the wrong direction. What I want is that even if I give the client source code out to everyone I still like to make sure that only the client I compile is allowed to talk to the service. I have currently a code signing certificate and if I need other certificates, I can get them. But the point is: I must make sure that only data my certified client sends to the server service is accepted.

As I read I've to use a client certificate to authenticate the client against the server. But here the client has the full client certificate with the private key to encrypt the data which is then decrypted from the service with the public key of the client certificate. If I assume that this certificate can't be stolen I'm done. But if someone loads my client application and installs it, then he has the full client certificate on his computer and can write a client which behvios like mine.

What do you mean with payment? May be this is the solution?

I hope I've clarified the problem. Thanks to all for your help.

Thom

Sergey Alexandrovich Kryukov 17-Feb-11 19:17pm

Thank you for clarification, but that's not all. Let's be careful. What do you mean by "certified client"? It is certified client application or certified client as a person? This is important in your case. In my previous comment I described the way to make sure your client application is not modified or forged: it will not start or will not pass authentication with the service. You still did not respond on this opportunity; can you accept it or not. May be I did not express this approach clearly.
I feel this is the closest to what you need, otherwise you would be asking about well-known authentication practices.

If you need to certify a person, this is not easy, and has to be a part of social structure. You should understand that I don't dare to advice you much on this, as this takes too much detail of your business. When you ask clarification on "with payment", that indicates to me, you're interested in payment (are you indeed?), and this is the part of the problem. You see, if you require personal identity of a person defined as the "one who is a legitimate purchaser" this is one thing. You can design a transaction "deployment in exchange of money" and be satisfied. Not being your business insider, it's very hard to advice. This will not resolve such problem that, for example, the individual shares password and software and any required identity evidence with someone else, but certain things can be avoided. If Fantomas wears a mask of commissar Juve is one thing, but if he imprints Jove's fingerprints on gloves and grabs the documents... and so on (if you from Germany you might know those dudes :-). What you should understand is that if you wanted to use individual password verification via regular HMTP post (no SSL!), if can easily be cracked. (I think you do understand that.) However, it's not very hard to make it as unbreakable as SSL or better on top of HTML, using a bit more sophisticated schema.

However, I feel that you more afraid of integrity of the system that requires certain integrity from all the clients. To me, it may be the indication of that your inner model is too fragile, but, again, I don't dare to get into these issues. I try to help you based on your assumption that integral well-defined client code resolve the issue, so the only problem if preventing forgery.

Let me conclude. I don't think you're going in wrong direction. I think your understand things quite deeply in terms of analysis, but you're uncertain about your direction in terms of synthesis. So, you need to complete your analytical part first. You need to separate aspects of social structure from technical aspect, clearly depict involved parties, use cases and clearly identify your goals. I hope my speculations can give you some food for though. Please think and come back, I would be happy to continue.

--SA

ThomT 18-Feb-11 13:41pm

I still think about your last post but to answer one of your questions...

> What do you mean by "certified client"
This piece of software I've to write. The software will be downloadable by everyone so we've no idea who uses it. This software should send data to our server service and i should make sure that, as I wrote, even if someone has the source code of the client application, he can't use the source to create an exe (executable program) which is treated from our server service as our client software (our service should 'detect' that this software was not compiled by us and so reject requests from this client exe).

Greetings, thanks.
Thom

Sergey Alexandrovich Kryukov 18-Feb-11 14:45pm

Great, thanks for this clarification, it is the key.

So, you confirmed my assumption on your goals which I thought was most likely!
Now, here is the situation. What I've written in my Answer remains valid, but not applicable directly, it needs another step (#0). What I've added in my comments, is the next steps, now looks not so easy.

My earlier assumption that you can deploy the application and/or key the way you can trust each user should be thrown out. At this moment, next step needs some thinking. On a second though, even though you can guarantee the application is not modified (this is easy), it's not clear how to prevent the following scenario: running the application under debugger to mimic its action for a different, forged application. Of course, spying on authentication protocol package will be useless, because in my method is cannot be reused in next session, but the moment of passing a key to the (un)ciphering algorithm can be captured!

Well, there is an obvious way to protect, but I don't like it so much... Let's do the following: this thread is over-crowded with comments. Let me do the following: I'll put my reasoning in a separate "tentative answer" on the same page, and we'll continue there. Of course, you don't need to accept it -- yet. :-) OK?

--SA

Sergey Alexandrovich Kryukov 18-Feb-11 19:11pm

Hi Thom,
I posted "plan B" and "plan C" in a new answer. Please see. Now after your clarifications and some thinking I have enough confidence about the resolution. All this matter runs out of CodeProject format. Will you rather contact me directly? You can do it through my Web site found on my profile page; it has "Contact me" form...
--SA