2 信任网络
我们将信任网络定义为一组共享的 VaultysId。每个 VaultysId 拥有者都有自己的 VaultysId 集合用于通信。VaultysId 中包含的密钥可用于签名或加密数据。每个服务都可以使用从中派生密钥的自己的协议。
然而,协议是为了信任设置而定义的,即为了整合可靠密钥集合。该协议称为对称关系协议(SRP),因为它旨在创建由双方签名的证书,并最终在双方都相同。
2.1 对称关系协议
Bob 和 Alice 之间各自拥有一个 VaultysId。 交换的数据包括:
protocol
名称(例如p2p
)service
名称(例如auth
)timestamp
,用于防止重放攻击id1
和id2
分别是 Bob 和 Alice 的 VaultysId。Nonce
(随机数)sign1
和sign2
是由Id1
和Id2
的签名密钥创建的签名metadata1
和metadata2
是可以为空的 JSON 对象 我们可以用以下模式总结协议:message = { protocole, service, timestamp, id1, id2, nonce1, nonce2, metadata1, metadata2 }
sign1
和sign2
是使用sha256(messagepack(message))
的签名,使用id1
和id2
的签名密钥
元数据由 protocol
和 service
用户定义。例如,我们可以使用元数据在各方之间交换姓名、电子邮件和电话,以便它们在彼此的信任网络中得到认证。
我们定义:
- M1 =
protocol, service, timestamp, id1, nonce1, metadata1
- M2 =
id2, nonce2, metadata2
- sign1 和 sign2 是
sha256(M1 | M2)
的签名 certificate
=sha256(M1 | M2) | sign1 | sign2
certificateId
=sha256(certificate)
- 消息使用 MessagePack 进行序列化
该协议需要依赖以下基础设施
- Bob 和 Alice 已知的双向通信
channel
。主动攻击是允许的,除了初始的 握手(稍后详述) - 能够保存 Id 和证书的
storage
。storage
的安全模型是被动攻击(即能够读取数据,但不能篡改)。
2.2 概述
- Bob -> Alice:发送 M1
- Alice 验证这是否是她想要使用的
protocol, service, metadata1
的意图,并且数据是一致的。 - Alice 验证时间戳是否在合理时间内(由
protocol
定义) - Alice -> Bob:发送 M1 + M2 + sign2
- Bob 验证
metadata2, sign2
是否一致 - Bob -> Alice:
sign1
- Alice 验证
sign1
是否有效 - Alice -> Bob:
COMPLETE
以确认通信结束 - Alice 和 Bob 将 Id 与相同的
certificate
一起保存,该证书对于 Alice 和 Bob 是相同的
在协议的未来版本中,COMPLETE
可能会被 certificateId
替换,当它被定义时。
2.3 初始握手
初始握手是在各方之间交换未知密钥的一种方式。能够在协议期间更改数据的主动攻击不在安全模型的范围内。安全设置包括:
- 面对面协议实现。
- 安全的 p2p 通道:
- 通过交换临时随机密钥(例 如通过二维码)来加密协议中交换的数据
- 不需要前向保密
- 密钥在使用后销毁。该协议对后续恢复或被动攻击具有抵抗能力。 常量定义如下:
protocol
=p2p
service
=auth
timestamp
偏差为 10 秒metadata1
和metadata2
为空。
如果不是面对面握手,则时间戳可以放宽到几个小时(通常为 2 小时),但需要提醒的是,安全模型断言在握手期间传输信息或端点(电子邮件、聊天、短信)的通信渠道在握手期间未被破坏。
2.4 认证
完成握手协议后,随时可以相互认证。例如,我们可以通过以下单一认证方案替换基于 username/password/mfa
的经典登录系统:
protocol
=p2p
service
=auth
timestamp
偏差为 10 秒metadata1
和metadata2
为空。
双方验证 Alice
和 Bob
都有额外的步骤,检查双方握手注册证书的有效性:
2.5 参考实现
-
MessagePack 序列化由 https://github.com/ygoe/msgpack.js/tree/v1.0.3 处理
-
Ed25519 密码学由 https://github.com/StricaHQ/bip32ed25519/tree/v1.0.4 处理
-
用于 FIDO2 桥接实现的 COSE 反序列化由 https://github.com/hildjj/node-cbor/tree/v8.0.1 处理
-
用于 FIDO2 桥接实现的 X509 证书反序列化由 https://github.com/PeculiarVentures/x509/tree/v1.9.2 处理
-
随机数和 sha256 原语是 Nodejs 提供的原语 https://nodejs.org/api/crypto.html:
createHash
randomBytes
- 对于浏览器,委托给 https://github.com/browserify/crypto-browserify/tree/v3.12.0
2.6 示例
通道实现
通道是用于双向交换数据的抽象对象。基本上需要 2 个方法:
send(data): void
用于发送数据并忘记async receive(): data
用于等待数据接收
我们提供 2 种实现:
- 使用 webrtc 的
P2P 通道
(通过库 peer.js) - 依赖于浏览器的原生
fetch()
和服务器的 expressjs 或 nextjs 中间件的Server/Browser 通道
。
用于测试的 通道模拟
(在同一进程中使用 RAM)
我们正在开发其他几种实现,如 Patr