使用数字签名验证服务器
我了解如何通过数字签名实现不可否认性和完整性，但我还不掌握身份验证。
我正在用 C# 开发一个客户端-服务器应用程序，它应该能够使用数字证书和数字签名进行身份验证。我知道如何检查签名的有效性和完整性（使用 SignedCms.CheckSignature()），但是如何验证所涉及的任何部分？
例如：
- 客户端向服务器请求数字签名，
- 客户端接收签名并验证它，
- 如果验证成功，则继续。
客户端可能是中间人攻击的受害者，并在步骤 2 中收到有效签名。验证会成功，但客户端不会与正确的服务器通信。
我缺少什么？
I understand how Non-repudiation and Integrity are achieved with Digital Signatures, but it's the Authentication that I don't grasp yet.
I'm developing a Client-Server application in C#, that should be capable of Authentication with Digital Certificates and Digital Signatures. I know how to check the validity and integrity of a Signature (with SignedCms.CheckSignature()), but how does this authenticates any of the parts involved?
For example:
- The client asks the Server for a Digital Signature,
- The client receives the signature and validates it,
- If the validation succeeds, continue.
The client could be a victim of a man-in-the middle attack and receive a valid signature in step 2. The validation would succeed, but the client wouldn't be talking to the right server.
What am I missing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
只有当中间人拥有用于签署请求的私钥时，他们才能收到有效的签名。我认为您可能错过的关键是，更改数字签名项目的任何方面都会使签名无效。中间人可以重新提交请求，但如果他们更改请求，签名验证将失败。
They could only receive a valid signature if the man in the middle possesses the private key with which to sign the request. I think the key thing you may be missing is that altering any aspect of the item which is digitally signed would invalidate the signature. The man in the middle can re-submit the request, but if they change it, the signature validation will fail.
您缺少对签名证书的信任。
考虑 SSL 证书，它们具有到 Windows（或任何操作系统）信任的根 CA 的签名路径。如果 MITM 提供自签名证书或由不受信任的 CA 生成的证书，则会被浏览器拒绝并显示警告。因此，只有由您认识的 CA 颁发的证书或与您认识的 CA 关联的证书才受信任。
对于自签名证书，它变得更加复杂，您需要安全地交换密钥指纹、序列号或其他常量标识符，并验证签名密钥实际上是您期望的密钥 - 通常不应该使用自签名证书的原因之一面向公众的网站或其他服务。
因此，如果存在 MITM 攻击，并且原始计算机的签名被剥离，消息发生更改，然后使用未知证书进行签名，只要您根据您信任的内容检查签名证书的身份，那么您就会拒绝签名的证书信息。
（实际上，情况会变得更复杂，但我希望你能明白我的意思）
You're missing trust of the signing certificate.
Consider SSL certificates, they have a signing path to a root CA which is trusted by Windows (or whatever OS). If the MITM presents a self signed cert, or one produced by an untrusted CA then it gets rejected by the browser and a warning is displayed. So a certificate is only trusted if it's issued by a CA that you know, or chains up to one you know.
For self signed certs it becomes more complicated, you need to securely exchange the key fingerprint, serial number or other constant identifier and validate that the signing key is in fact one you expect - one reason why self signed certs generally shouldn't be used for public facing web sites or other services.
So if there's an MITM attack, and the signature from the original machine is stripped, the message changed, and then resigned using an unknown certificate as long as you check the identity of the signing cert against something you trust then you'll reject the resigned message.
(in reality it gets more complicated, but you get the point I hope)