openssl网络钓鱼：V声称是A

有我的应用程序的几个组件，需要他们的通信安全的意义Origin Verify。这些组件不能共享一个共同的秘密。所以我必须选择非对称密钥加密。假设我已经两个组件A和B A发送一些数据F到B和B必须验证它确实从Aopenssl网络钓鱼：V声称是A

A来产生消化FH用自己的私钥
A重视A_pub，H其请求参数，发送F并声明原始/发件人为A
B验证摘要H与A_pub针对提供10

显然它看起来不错，但如果一些其他组件V做同样与V_pub并声称自己为A，B仍然认为该请求从A出来，因为这H是由具有V_prv OpenSSL的验证好了。

我想给抵御这种攻击的V

我使用ecparamsecp112r1，以尽量减少密钥长度。并且键被重复改变。

- 编辑 -

A，B和V是通过独特的URI标识应用程序组件。它目前打算限制安全页面流。例如您可以假设A,B,V成为我想要的只有A可以计算为B并且只有B可以进行到C ....并且我不想为此维护全局/应用程序范围的会话。所以如果B可以根据特殊参数A以状态/会话较少的方式传递给它，就可以验证此链接的来源。而且通用性越强，它在其他场景中的实现也越具有可重用性。

有一次，我想在可信的全局存储中维护一个校验和A_pub。但是，我恐怕不会是一个过度的工程？

我脑海中另一种方式是查询有关公钥的原始URL。但是我想避免这种情况。

来源

2012-03-31 Neel Basu

有两种可能性：1）'A'和'V'只是任意的标识符（如'第一方'和'第二方'），只要'B'保留它们并不重要直行。 2）'A'和'V'不是任意的，并且表示特定的事物。在这种情况下，如果你不告诉我们这是什么，你就不会得到有用的答案。 – 2012-03-31 20:06:52

请检查我的编辑 – 2012-04-01 07:29:02

该技术无法验证发件人的身份，只能说这些密钥是匹配的一对。

通常，B将拥有一些可用于验证A身份的可信信息。该信息通常是其先前已验证的A_pub的副本，或者是由可信任的第三方签署的，在这种情况下，B必须能够访问该第三方的公钥。

没有此附加信息，B无法验证A的身份。

来源

2012-03-31 16:59:21

您可以更详细地了解哪些选项？ – 2012-03-31 17:09:50

公钥基础结构的基础是每个设备都维护一个可信证书库。它使用这些证书来验证其他设备的身份。但是无法使用从该设备获取的_only_信息验证设备的身份;必须有一个“信任链”，以已知的信息为真。 – 2012-03-31 17:45:05

如何使用openssl命令行在'A_pub'上生成证书？ – 2012-03-31 18:35:02

openssl网络钓鱼：V声称是A

回答

相关问题