《sequoia-keystore》crate 实现了一个服务器，用于管理密钥材料。密钥材料可以存储在文件中，在如智能卡等硬件设备上，或通过网络访问。《sequoia-keystore》不实现这些访问方法。这些由各种后端处理。后端实现了一个通用接口，该接口由本crate定义。

lib.rs:

定义了存储后端需要实现的特剧行。

Sequoia的存储库是一个服务，用于管理和多路复用访问密钥材料。从概念上讲，密钥存在于设备上，设备由后端管理。设备可能只是一个磁盘上的文件，它可能是一张智能卡，或者它可能是通过网络访问的另一个存储库服务器。

后端实现了本crate中定义的特剧行。特剧行抽象出了各种设备的细节。它们主要关注枚举密钥和执行低级解密和签名操作。后端接口与应用程序暴露的通用接口不同，且更底层。

以下图展示了架构。方块代表不同的地址空间。

   +---------------+        +---------------+
   |  Application  |        |  Application  |
   +---------------+        +---------------+
                 \            /
+----------------------------------------------+
|                   Keystore                   |
|                /            \                |
|        soft key              openpgp card    |
|        backend                 backend       |
+----------------------------------------------+

存储库不必作为服务器运行；也可以将存储库与应用程序本地化，如图所示

+----------------------------------------------+
|                 Application                  |
|                      |                       |
|                   Keystore                   |
|                /            \                |
|        soft key              openpgp card    |
+----------------------------------------------+

使用守护进程而不是库或子进程，每次启动应用程序就生成一个守护进程，当应用程序终止时终止守护进程，这提供了几个优点。

主要用户可见的优势是守护进程能够保持状态。在软密钥的情况下，守护进程可以在内存中缓存未加密的密钥，这样用户就不必频繁解锁密钥。当命令行工具如 sq 连续多次执行且每次访问相同的密码保护密钥时，这尤其有用。同样，守护进程可以缓存访问HSM所需的PIN码。它还可以保持HSM打开状态，从而避免初始化开销。这也适用于远程密钥：例如，ssh隧道可以保持打开状态，并按需重用。

单独的守护进程还简化了重要的非功能性安全属性：进程分离。由于软密钥不是由应用程序管理，而是由守护进程管理，攻击者无法使用heartbleed风格的攻击来窃取密钥材料。

特质模型将后端视为设备集合，每个设备包含零个或多个密钥。以下图显示了可能的配置。密钥库使用两个后端，软密钥后端和openpgp卡后端，每个后端有两个设备。软密钥后端将证书建模为设备；openpgp卡后端为每个物理设备有一个设备。每个设备包含1到3个密钥。接口不对每个后端的设备数量或每个设备的密钥数量施加限制。因此，管理数千个密钥的TPM是可以想象的，也是可能的。

+----------------------------------------------------+
|                   Keystore                         |
|                /            \                      |
|        soft key              openpgp card          |
|       /        \            /            \         |
|   0x1234      0xABCE     Gnuk         Nitro Key    |
|   /    \        |      #123456         #234567     |
| 0x10  0x23     0x34   /   |   \       /   |   \    |
|                     0x31 0x49 0x5A  0x64 0x71 0x88 |
+----------------------------------------------------+

不同的设备可能在任何时候都不连接。例如，用户可能会移除智能卡，但如果后端已记录配置，密钥库仍然知道有关

当密钥库启动时，它会急切地初始化它所知道的各个后端。此时，后端是静态链接到密钥库的，必须在密钥库初始化函数中明确列出。

当后端初始化时，初始化函数会传递一个目录。后端应从名为后端的子目录中读取任何所需的状态。例如，软密钥后端使用“softkeys”子目录。

后端在使用存储在其他地方的状态时必须非常小心。如果用户选择不同的主目录，那么他们通常想要不同的配置，这与主要配置隔离开来。在后端使用物理资源的情况下，这并不完全可能。

密钥和设备

在最简单的情况下，设备包含零个或多个OpenPGP密钥。设备也可能被锁定或解锁、注册或未注册、可用或不可用。

如果设备被锁定，它必须首先解锁才能使用。有时可以通过通过DeviceHandle::unlock接口提供密码来解锁设备。其他时候，设备必须由用户手动解锁。如果设备被锁定，可能无法枚举设备上存储的密钥。

如果设备已注册，则设备的配置已本地缓存。在这种情况下，即使设备未连接到主机，也可以枚举设备上的密钥。例如，当OpenPGP卡被注册时，OpenPGP卡后端记录设备的序列号、存储在智能卡上的密钥列表及其属性。当用户枚举密钥库管理的密钥时，即使智能卡未连接，这些密钥也会返回。当然，用户不能使用这些密钥。

如果设备已注册但未连接到系统，则认为不可用。如果用户尝试在不可用设备上使用密钥，则会返回错误。在这种情况下，应用程序通常会提示用户使相应设备可用。

这些状态在DeviceHandle的文档中进行了更详细的说明。

密钥是否已注册或可用完全是设备的功能。如果一个设备包含多个密钥，并且它们可以独立于其他密钥注册或可用，则后端必须将密钥建模为独立的设备。