algorithm - 密码学:虚拟属性(property)所有权的数字签名？

Question

假设我们有一个多用户系统，其中:

中央机构 (C) 可以创建并发行虚拟商品 (Zk) 给它自己的所有权。

商品(Zk)的所有者(Xi)可以将所有权转让给另一个用户(Xj)。

用户 (Xi) 可以声称拥有一个商品 (Zk)，这应该是可验证的。

例如:

C 创建两个虚拟元素 Z1 和 Z2。 (并且从未创建过 Z3)

C 将 Z1 的所有权转让给用户 X1

X1 将 Z1 的所有权转让给 X2

以下声明应测试为真:

X2 声称拥有 Z1

C声称拥有Z2

以下声明应测试为假:

X2 声称拥有 Z2(不是所有者)

X2 声称拥有 Z3(不存在)

X1 声称拥有 Z1(前所有者)

以下是问题:

这种系统的架构草图是什么？

我们使用哪些加密方法(数字签名、pki 等？)以及以何种方式使用？

创建了哪些 key 以及将它们提供给谁？

C 使用什么算法来创建一个好的 Zk？

Xi 和 Xj 用于转移所有权的算法是什么？

Xi 使用什么算法来生成拥有 Zk 的声明？

Xi 使用什么算法来验证 Xj 拥有 Zk 的声明？

Answer 1

数字签名用于验证发件人生成的消息确实是由该发件人生成的。在这种情况下，您可以使用数字签名来验证产品的生成者确实是中央机构。在这种情况下，产品将始终具有 CA 使用那里的私钥生成的数字签名，然后任何人都可以使用 CA 的公钥进行验证。

移情，这就是它变得困难的地方。哪一方将进行验证。它将成为 CA，还是只是为了让第 2 方在购买该元素之前知道第 1 方是真正的(和合法的)所有者，或者两者兼而有之？

好的，根据您的评论。我认为答案是始终让 CA 参与其中。在这种情况下，您基本上可以始终通过所有者系统上的 AES 等对称算法对虚拟元素进行加密，直到使用时为止。解密虚拟元素的 key 永远不会(长期)存储在所有者系统上，而是在请求时由 CA 传递。现在 CA 可以保存当前有效用户的 key 。这些 key 是如何存储或计算的，我稍后会谈到。

对于用户 Xj 验证项目 Z1 确实属于用户 Xi，这可以像 CA 签署由所有者的用户 ID 和项目的加密副本组成的消息与 CA 私钥一样简单。由于用户名包含在消息中，当用户 Xj 使用 CA 的公钥验证签名时，用户 Xj 知道它是有效的并且归用户 Xi 所有。

按键设置:
CA 显然应该有一个非对称 key 对(私有(private)和公共(public))。每个用户还应该有一个非对称 key 对。 CA 将与其用户共享其公钥，每个用户将与 CA 共享他/她的公钥(这可以是某种形式的帐户设置的一部分)。用户现在将通过加密唯一用户 ID 来登录 CA，该唯一用户 ID 使用用户的私钥加密和签名，并将公钥附加到消息中。 CA 使用提供的公钥解密(所有这些都可以在 SSL 设置中处理，或者本质上是第二层加密以帮助更好地保护唯一 ID)。当发生购买时，CA 可以通过执行用户唯一 ID、虚拟元素的序列号和 CA 的 PRIVATE key 的 HASH 来创建一个 key ，以用作对称算法的输入 key 。 CA 现在使用这个新计算的 key 加密项目，并使用他们的 (CA) 私有(private)非对称 key 对其进行签名。新加密的项目现在被发送到用户的系统。 CA 不必存储 key ，因为他们知道如何计算它，CA 的私钥仍然受到保护，因为您正在获取它的 HASH 以及其他内容，并且该项目现在为每个用户唯一加密。

现在要解密有效项目，用户已经登录，并且 CA 已经知道这是该项目的有效所有者，因此可以计算 key 并将其 SSL 传递给用户以进行实时解密。但是，此 key 永远不会存储在机器上。

现在，如果不拥有该项目的用户尝试使用有效用户项目的副本，则会发生以下两种情况之一，非所有者用户将登录并计算该项目的错误 key ，因此该项目将不正确地解密，CA 可以执行自动识别用户实际上并不拥有该项目并从那里锁定所有帐户的项目，让有效用户的帐户知道有人试图使用那里的项目，等等......

转移:
有效用户将登录并声明他们要将项目转移给另一个用户。此时，该项目与所有者 1 解除关联，并重新与所有者 2 关联。由于 CA 拥有所有 key 生成，因此所有者 1 将不再能够解密其项目。事实上，在转移点，软件可以简单地删除所有者 1 本地系统上的副本。

对不起，这是冗长的，但这些类型的问题通常是。