在 Hyperledger Indy 中实现隐私设计

在最近的一篇有关 Hyperledger 的博文中，Daniel Hardman 谈到了 Hyperledger Indy 及其用于解决去中心化身份管理问题的“ Privacy by Design ”方法。与很多在事后为产品或服务增加隐私的系统不同，Hyperledger Indy 基于隐私优先的方法而构建。随着世界监管力度的加强，包括 GDPR 和 ePrivacy，Indy 可以最大限度地减少用户在通过第三方系统验证数据时分享的信息量。

集中式身份服务提供者（例如社交媒体网站和消费者电子邮件服务）通过提供使用相同身份登录其他在线服务的能力来为用户提供便利。然而，由于隐私问题和安全漏洞，这种方法最近受到了审查。Business Insider 最近发布了一份报告，报告中提到了 Facebook 数据泄露，导致攻击者可以使用 Facebook 凭据访问其他服务，如 Tinder、Spotify 和 Airbnb。

为避免依赖集中式身份服务提供者，开源区块链项目 Hyperledger Indy 出现了，旨在解决集中式身份服务提供者中存在的问题，包括：

• 数据使用方式缺乏透明度。

• 只向服务提供商提供最小数据属性，防止数据的“过度共享”。

• 单点数据泄露可能会产生级联效应。如果用户的凭据被用于注册其他在线服务，那么就可以用这些凭据访问这些服务。

避免数据泄漏是 Hyperledger 试图解决的一个关键问题。Hardman 介绍了他们如何做到这一点：

Hyperledger Indy 允许你构建具有显式和最小化公开程度的交互——比以前要小得多。Indy 中的连接、交谈或证明机制不会泄露与隐私有关的东西，如果存在漏洞，那一定是来自更广泛的上下文。现在还没有其他技术能够实现 Indy 这样的最小化程度，也没有其他技术能够如此谨慎地将交互彼此分开。如果隐私问题就像生物危害一样，那么 Indy 就像是带上手套拿出盛在容器里的针头——它提供了世界上最好的乳胶和消毒剂。

作为集中式身份提供者的替代解决方案，并依靠它们来充分保护你的数据，Indy 使用了去中心化身份（DID）。DID 由它的所有者用户控制，并且独立于集中式提供者或授权实体。通过使用 DID，可以开发自主身份（SSI）解决方案，以便个人或企业可以存储身份识别，并向服务提供者提供相关数据，服务提供者可以在使用服务时使用声明对其进行验证。

默认情况下，DID 是成对唯一和匿名的，以防止相关性。Sovrin 基金会主席 Phillip J. Windley 解释了为什么这很重要：

Indy 致力于让身份所有者独立控制他们的个人数据和关系。构建 Indy 是为了使身份所有者在结构上成为基于身份的交易的一部分。成对身份识别不仅阻止了相关性，而且在没有身份所有者参与的情况下阻止第三方进行交易，因为身份所有者是唯一可以关联成对身份识别的角色。

虽然 DID 似乎是朝着用户隐私的正确方向迈出的一步，但是组织有可能会试图破坏 Indy 提供的保护。Hardman 解释说：

如果我们使用成对 DID 和零知识证明，那么消息很显然会是“不要试图关联我”，即使你可以找到一种方法来做到这一点（如果你足够努力的话）。HTTP Do-Not-Track 消息头显示“do not track me”，但它并不会提供任何实际的跟踪保护。VRM 社区长期以来一直在讨论用户定义条款。在一段关系中，你可以说“不要将我的数据用于广告”、“14 天后删除我的数据”或“将我的数据用于研究，但不能用于商业”。

Hardman 认为，在代码和架构中表达这些意图本身确实具有价值，并且对其有效性表示乐观：

随着时间的推移，我们期望能够通过监管、信任框架、声誉和类似的机制，不鼓励不尊重这些意图的行为。当然，我们必须始终清楚地说明意图和保证的局限性，以免造成一种安全假象，带来严重的后果。

Hyperledger 鼓励对隐私进行转化，因为存储个人身份信息（PII）会给消费者和企业带来风险。不过，存储用户的不透明身份识别，然后向用户的代理发出请求获取更多信息，并在使用后丢弃，这是向降低数据泄露的风险迈出的正确的一步。

查看英文原文： Implementing Privacy by Design in Hyperledger Indy