假设我们有一个多用户系统:
例如:
以下声明应该测试为真:
以下声明应该测试错误:
以下是问题:
答案 0 :(得分:1)
数字签名用于验证发件人生成的邮件确实是由该发件人生成的。在这种情况下,您可以使用数字签名来验证产品的生成器确实是中央机构。在这种情况下,产品将始终具有由CA使用私钥生成的数字签名,然后任何人都可以使用CA的公钥进行验证。
转移,这是困难的地方。哪一方将进行验证。它是否会成为CA,或者只是为了让第2方知道第1方在购买物品之前是真正的(合法的)所有者,或两者兼而有之?
好的,根据您的评论。我认为答案是始终在混合中使用CA.在这种情况下,您可以基本上始终通过所有者系统上的AES等对称算法对虚拟商品进行加密,直到使用时为止。解密虚拟商品的密钥永远不会存储(长期)在所有者系统上,而是在请求时由CA传递。现在,CA可以保存当前有效用户的密钥。如何存储或计算这些密钥我将在稍后讨论。
对于验证项目Z1真正属于用户Xi的用户Xj,这可能与CA签署由用户的用户ID和带有CA私钥的项目的加密副本组成的消息一样简单。由于用户名包含在消息中,当用户Xj使用CA公钥验证签名时,用户Xj知道它是有效的并由用户Xi拥有。
设置密钥: CA显然应该具有非对称密钥对(私有和公共)。每个用户还应具有非对称密钥对。 CA将与其用户共享其公钥,并且每个用户将与CA共享他/她的公钥(这可以是某种形式的帐户设置的一部分)。用户现在将通过加密使用用户的私钥加密和签名的唯一用户ID登录到CA,该私钥将公钥附加到邮件中。 CA使用提供的公钥进行解密(所有这些都可以在SSL设置中处理,或者基本上是第二层加密,以帮助更好地保护唯一ID)。当购买发生时,CA可以通过执行用户唯一ID的HASH,虚拟物品的序列号和CA的PRIVATE键来创建密钥,以用作对称算法的输入键。 CA现在使用此新计算密钥加密项目,并使用其(CA)私有非对称密钥对其进行签名。新加密的项目现在发送到用户的系统。 CA不必存储密钥,因为他们知道如何计算密钥,CA私钥仍然受到保护,因为您正在使用HASH加上其他东西,并且该项目现在为每个用户进行了唯一加密。
现在要解密有效项目,用户已经登录,并且CA已经知道这是该项目的有效所有者,因此可以计算密钥并将其下载到用户以进行实时解密。这个密钥永远不会存储在机器上。
现在,如果DOESNT拥有该项目的用户尝试使用有效用户项目的副本,则会发生以下两种情况之一,非所有者用户将登录并计算该项目的错误密钥,并且因此,项目将不正确地解密,CA可以执行自动识别,用户不会实际拥有该项目,并从那里锁定所有帐户中的项目,让有效用户的帐户知道某人正在尝试使用该项目等。
转移: 有效用户将登录并声明他们想要将项目转移给另一个用户。此时,项目与所有者1解除关联,并重新关联到所有者2.由于CA拥有所有密钥生成,所有者1将无法再解密其项目。事实上,在转移时,软件可以简单地删除所有者1的本地系统上的副本。
对不起,这是长篇大论,但这些类型的问题通常都是。
答案 1 :(得分:1)
问题在于经典的加密原语。正如其他答案所详细提到的,您需要使用公钥加密。以下是我能想到的程序:
货物所有权,比如货物ID和用户公钥的绑定,需要由权威机构CA跟踪,以确保所有货物都是唯一拥有的。
CA的主要作用是保证没有两个用户可以索取相同的商品,我称之为“双重索赔”。以分散的方式摆脱“双重主张”的脆弱性是非常困难的。有一个名为bitcoin的非常有趣的项目试图解决非常相似的问题。它提供了一种新的解决方案来消除CA.如果您有兴趣,design paper涵盖了基本想法。