具有软件保护的模式（第2部分）实际上是与第1部分的组合，即计划B。我认为问题需要一种截然不同的方法，计划C。它不应该要求架构中的全局更改，并且位于服务和客户端之间的瘦通信层中。 我的想法是将所有业务逻辑从客户端部分移动到服务，无法修改的地方。这是对架构的相对较小的修改。可以有不同的方法。 一种显而易见的方法是将应用程序转换为ASP.NET层，以表示服务和客户端之间的完整通信层。这是非常可行的。由于HTTP协议的限制，潜在的问题是客户端功能发生了重大变化。 替代方法是继续使用通过传输协议工作的常规UI客户端，但是从业务逻辑中清除，该业务逻辑被移至服务部分对应部分。这里我有一些初步的模式，需要一些额外的思考。 -SA Hi all,I need to develop a client/server architecture:- language c#- native client- server: web service, may be wcf serviceThe 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 解决方案 Part 1This 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 => (Ks, Kd).The function has no "backdoor": it is not possible to calculate one key base on knowledge or another key. I'll call Ks a "encrypting" key, Kd — a "decrypting" key:(unencrypted data, Ks) —> (encrypted data)(encrypted data, Kd) —> (unencrypted data)2) Let's deploy Kd with C.At this step, S has Ks and Kd, C has only Kd, 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" Tu (unencrypted) and encrypt it into encrtypted token Tu:(Tu, Ks) —> Ts, and sends it to a connected client C. New Tu is generated randomly for every new session.5) C use Ks to decrypt Ts:(Ts, Ku) —> Tu.6) C sends Tu 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 Ts and Tu. 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 Tu 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?—SAI 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?ThanksThomPart 2This 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 Ku 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 3The 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 这篇关于如何确保只有定义良好的客户端与Web服务（WCF）进行通信？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！
