​
变更记录

  • 2019 年 7 月 29 日：初始草案
  • 2019 年 9 月 11 日：工作已开始
  • 11 月 4 日：Cosmos SDK 变更已合并
  • 11 月 18 日：Gaia 变更已合并

​
背景

目前，Cosmos SDK 应用的 CLI 目录会在用户主目录中的纯文本数据库里存储密钥材料和元数据。密钥材料会通过口令加密，并由 bcrypt 哈希算法保护。元数据（例如地址、公钥、密钥存储详情）则以明文形式提供。 这在很多方面都不理想。其中也许最重要的原因，是对密钥材料和元数据的安全保护不足。明文泄露后，攻击者可以通过多种手段监视某台计算机控制了哪些密钥，例如利用受污染的依赖项而无需任何特权执行。随后，这可能演变为针对特定用户或计算机的更有针对性的攻击。 所有现代桌面操作系统（Ubuntu、Debian、macOS、Windows）都提供内置的密钥存储，旨在让应用能够存储与其他所有应用隔离的信息，并且访问这些数据时需要输入口令。 我们正在寻找一种解决方案，既能为多种不同后端提供统一的抽象层，也能为不提供原生密钥存储的精简平台提供合理的回退方案。

​
决策

我们建议用 99designs 的 Keyring 替换当前基于 LevelDB 的 Keybase 后端。该应用旨在为多种密钥存储提供通用抽象和统一接口，并已被 99designs 的 AWS Vault 应用使用。 从目前来看，这能够满足保护用户机器上密钥材料和元数据免受恶意软件侵害的要求。

​
状态

已接受

​
影响

​
正面

提升了用户安全性。

​
负面

用户必须手动迁移。 针对所有受支持后端进行测试较为困难。 在 Mac 本地运行测试需要反复输入大量密码。

​
中性

未发现中性影响。

​
参考资料

  • #4754 将密钥存储切换到 keyring 密钥存储（由 @poldsam 提交的原始 PR）[已关闭]
  • #5029 为 github.com/99designs/keyring 支持的 keybase 添加支持 [已合并]
  • #5097 添加 keys migrate 命令 [已合并]
  • #5180 弃用磁盘上的 keybase，改用 keyring [PENDING_REVIEW]
  • cosmos/gaia#164 弃用磁盘上的 keybase，改用 keyring（gaia 的变更） [PENDING_REVIEW]

​
Changelog

  • July 29th, 2019: Initial draft
  • September 11th, 2019: Work has started
  • November 4th: Cosmos SDK changes merged in
  • November 18th: Gaia changes merged in

​
Context

Currently, a Cosmos SDK application’s CLI directory stores key material and metadata in a plain text database in the user’s home directory. Key material is encrypted by a passphrase, protected by the bcrypt hashing algorithm. Metadata (e.g. addresses, public keys, key storage details) is available in plain text. This is not desirable for a number of reasons. Perhaps the biggest reason is insufficient security protection of key material and metadata. Leaking the plain text allows an attacker to surveil what keys a given computer controls via a number of techniques, like compromised dependencies without any privileged execution. This could be followed by a more targeted attack on a particular user/computer. All modern desktop operating systems (Ubuntu, Debian, macOS, Windows) provide a built-in secret store that is designed to allow applications to store information that is isolated from all other applications and requires passphrase entry to access the data. We are seeking a solution that provides a common abstraction layer to the many different backends and reasonable fallback for minimal platforms that don’t provide a native secret store.

​
Decision

We recommend replacing the current Keybase backend based on LevelDB with Keyring by 99designs. This application is designed to provide a common abstraction and uniform interface between many secret stores and is used by the AWS Vault application by 99designs. This appears to fulfill the requirement of protecting both key material and metadata from rogue software on a user’s machine.

​
Status

Accepted

​
Consequences

​
Positive

Increased safety for users.

​
Negative

Users must manually migrate. Testing against all supported backends is difficult. Running tests locally on a Mac requires numerous repetitive password entries.

​
Neutral

No neutral consequences identified.

​
References

  • #4754 Switch secret store to the keyring secret store (original PR by @poldsam) [CLOSED]
  • #5029 Add support for github.com/99designs/keyring-backed keybases [MERGED]
  • #5097 Add keys migrate command [MERGED]
  • #5180 Drop on-disk keybase in favor of keyring [PENDING_REVIEW]
  • cosmos/gaia#164 Drop on-disk keybase in favor of keyring (gaia’s changes) [PENDING_REVIEW]