客户端加密 - 有什么建议/最佳实践 - 为我指明正确的方向吗？
我们需要加密客户端数据，以确保客户端浏览器和供应商之间存在“安全”通道。
基本前提是： 供应商生成公钥/私钥对：VendorPub 和 VendorPriv
我们的客户输入敏感数据。 提交表单上的 javascript 会对数据的敏感部分进行加密，提交到我们服务器的是 VendorPub(SensitiveData)。
我们将该包作为 VendorPub(SensitiveData) 提交给我们的供应商，只有他们才能使用该数据。
不考虑密钥长度和批准的算法（分别是 RSA 和 4096），当然整个事情将通过 SSL 连接...
它看起来可行，但我还没有模拟它...有什么建议吗？陷阱？
我们的开发环境是Visual Studio 2k5/ 2k8 / ASP.net 2.0或3.0
谢谢
We have a requirement to encrypt data client side to ensure a 'secure' channel exists between our client's browser and a vendor.
Basic premise is:
Vendor generates a public / private keypair: VendorPub and VendorPriv
Our clients enter sensitive data.
On submit the javascript on the form encrypts the sensitive portions of the data, what gets submitted to our server is VendorPub(SensitiveData).
We submit that package to our vendor as VendorPub(SensitiveData), only they can make use of that data.
Irrespective of key lengths and approved algorithms (RSA and 4096 respectively), and of course the whole thing would be over a SSL connection...
It looks doable, but I haven't mocked it up yet... Any suggestions? Pitfalls?
Our development environment is Visual Studio 2k5/ 2k8 / ASP.net 2.0 or 3.0
Thank you
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这绝对是可行的；虽然它可能有点迟缓。
这是 JS 中的 RSA 实现： http://www.ohdave.com/rsa/
It's definitely doable; although it might be a bit sluggish.
Here's a RSA implementation in JS: http://www.ohdave.com/rsa/
如果您要使用 SSL 连接（尽管我更喜欢 TLS），似乎没有什么（如果有的话）理由这样做。
如果您决定无论如何都这样做，那么 PK 加密技术的最大陷阱就是 MITM 攻击，即您不想只接受服务器的密钥并用它来加密数据。这将确保只有服务器可以读取数据，但是如果您尚未验证服务器的身份，则可能会将其完全发送给其他人。这就是 1) SSL/TLS 连接建立缓慢，2) SSL/TLS 库庞大且复杂的主要原因。加密比身份验证容易得多。
不过，没有比自己加密更需要自己执行此操作的理由了——SSL/TLS 已经同时进行身份验证和加密。
There seems to be little (if any) reason to do any of this if you're going to use an SSL connection (though I'd prefer TLS).
If you decide to do it anyway, the biggest pitfall with PK cryptography is a MITM attack -- i.e., you don't want to just accept the server's key and encrypt data with it. That will ensure that only the server can read the data, but if you haven't verified the identity of the server, you could be sending it to somebody else entirely. This is most of why 1) SSL/TLS connections are slow to set up, and 2) SSL/TLS libraries are big and complicated. Encryption is much easier than authentication.
There's no more reason to do this yourself than to do encryption yourself though -- SSL/TLS already do both authentication and encryption.
好的，所以最终的答案是：
它是可行的、相当快并且相当安全。然而，由于这是 PCI 要求，旨在缩小我们的环境范围，所以它失败了，因为我们仍然拥有加密方法，即，将由我们的系统提供执行加密的 javascript。
感谢所有参与进来的人。
加里
Ok, so the end answer is:
It's doable, reasonably fast and reasonably secure. However as this was a PCI requirement with the intent to de-scope our environment it was failed because we would still own the encryption method, IE the javascript that would do the encryption would be served from our system.
Thanks to everyone who chimed in.
Gary
目前的其他答案似乎忽略了这一点：“我们将该包作为 VendorPub(SensitiveData) 提交给我们的供应商，只有他们可以使用该数据”。换句话说，你是一个将数据视为黑匣子的中继者。
如果数据量不是很大的话，你所描述的是可行的。请记住，您不能让用户等待您的 JavaScript 运行。
顺便说一下，RSA4096 的规模大得可笑。 2048 目前是高级，3000 应该可以使用 30 多年。但是，给你更多的力量。解决公钥费用的一种正常方法是使用 RSA 加密对称 (DSA) 密钥 - 这样，实际数据的加密速度很快，唯一较慢的部分是解密（较短的）密钥。非对称密钥加密比对称密钥慢得多。
无论您决定实现什么，请确保在 JS 代码中进行正确的加密。
您还应该注意，这并不是真正保护用户免受您侵害的方法；而是一种保护用户免受攻击的方法。您控制网络服务器，因此您可以向用户发送经过修改的 JavaScript，通过您控制的密钥将他们的私人数据传递给您。用户不太可能注意到。
The other answers currently seem to have missed the point of this: "We submit that package to our vendor as VendorPub(SensitiveData), only they can make use of that data". In other words, you are a relay who treats the data as a black box.
What you are describing is doable if the amount of data is not very large. Remember, you can't keep the users waiting for your JavaScript to chug along.
RSA4096 is ridiculously huge, by the way. 2048 is high-grade at the moment and 3000-whatever is supposed to be good for 30+ years. But, more power to ya. A normal way to get around the public-key expense is to encrypt a symmetric (DSA) key using RSA - that way your encryption of the actual data is fast and the only slow part is decrypting the (shorter) key. Asymmetric-key encryption is much slower than symmetric.
Whatever you decide to implement, make sure you get the encryption right in the JS code.
You should also note that this isn't really a way to protect the users from you; you control the web server, so you could send the users doctored JavaScript that delivers their private data to you with a key you control. The users would be unlikely to notice.