在HTML5 SPA中进行有效负载签名的有效方法

Question

我希望在我们的web应用程序中实现一些高效（即具有良好性能）的逻辑来进行有效负载签名。HTML5客户端的目标是保证接收到的有效负载的内容确实是我们后端生成的内容。

我们不想使用共享盐进行有效负载哈希生成，因为用户可以轻松打开HTML5源并找到盐短语。

我们现在已经实现了RSA签名，我们的后端使用其私钥添加有效负载签名，我们的HTML5客户端使用其烘焙的公钥验证有效负载签名。然而，签名生成过程需要250毫秒（对于相对较小的负载），并且由于签名请求的性质，这段时间是不可接受的。

唯一的另一个想法是，每次客户端初始化其与后端的会话时，都会在运行时生成一个共享秘密。然而，这个秘密不能以明文形式发送，所以我们似乎必须实现Diffie-Hellman交换机制，如果可能的话，我们希望避免这种情况，或者通过现有库实现自动化。

请记住，由于我们销售产品的性质，保密和加密需要在应用程序层完成。我们不希望加密我们的流量，这是我们的客户可能会或可能不会实现的东西（因为它是一个内部网应用程序）。但是，我们必须避免将与我们的许可检查机制等相关的内容暴露给他们。后端不是基于云的，也不是由我们控制的，而是安装在客户的本地机器上。

前端是Javascript，后端是Java。

Answer 1

我们最终在客户端和服务器端都使用了TweetNaCl。该库提供了一种简单快捷的方式，无需通过自定义实现即可完成类似DH的共享秘密交换。有了一个短暂的共享秘密，我们可以很容易地为从250ms下降到10μs的有效负载生成哈希而不是签名。此外，RSA对初始DH交换进行签名非常重要，也是我们唯一使用RSA的地方。

请阅读@AlexandreFenyo answer，了解如何处理此类案件的正确理论。

Answer 2

请注意，Diffie-Hellman交换机制不受MITM攻击的保护，因此不加密流量意味着您需要验证来自服务器的DH数据。这就是为什么使用基于DH的密码套件的Web服务器使用其服务器证书的私钥对通过网络发送的DH元素进行签名，以便客户端检查这些元素是否真的来自他想要连接的服务器。这些元素是公共的，但需要签名。

您所说的“使用共享salt生成有效负载哈希”是一个密钥哈希消息身份验证码，因此正如您所注意到的，它基于一个共享秘密，并且由于您不想使用此机制，这意味着您不信任客户端。因此，您必须使用非对称密码对有效负载进行签名。

使用非度量算法签署服务器有效负载意味着您首先需要让服务器与客户端共享一个公钥。由于您不加密客户端和服务器之间的数据，因此您需要在客户端源代码内部部署服务器公钥。

您谈到了签名生成过程，但客户端的签名检查过程在您的案例中也非常重要，因为用户等待结果的总时间是签名时间和检查签名时间的总和（此外，如果要签名的数据不是动态生成的，则通常可以在服务器上预期签名，但验证永远无法预期）。所以你需要一种快速的方式来检查客户端的签名。首先，签署一个散列，而不是整个有效载荷。然后在客户端选择开发环境中可用的最快的不对称签名算法。请注意，对于对应于相同安全级别的相应密钥长度，检查RSA签名比检查DSA或ECDSA签名更快。所以你应该留在RSA。

所有这些，直到这一行可能对您没有太大帮助！现在有一种方法可以使用RSA来签名和验证签名来提高性能，这种方法与SSL/TLS在从同一服务器下载多个页面或其他对象时提高浏览器性能的方法相当相同：使用会话缓存。您与一个特定用户共享特定会话的公共秘密。永远不要将此公共秘密用于其他会话。当用户第一次连接时，仅使用RSA一次，以交换短暂的共享秘密或交换DH材料以创建此共享秘密。然后，每次服务器需要对一个对象进行签名时，它都会创建一个带有该特定秘密的键控哈希消息验证码。因此，如果用户找到了秘密，例如使用他的浏览器的调试模式，这不是问题：这个秘密只是在这里帮助他知道来自服务器的某些东西没有被更改。因此用户不能使用这个秘密来更改服务器和其他用户之间的数据交换。