IOTA核心加密库Stronghold Alpha版本发布

Stronghold是一个开源软件库，最初是为了保护IOTA种子而建立的，但可以用来保护任何数字密钥。它是一个用于密码学工作的安全数据库，它确保密钥（如私钥）永远不会被泄露。它提供了自己的点对点通信层，因此不同的实例可以使用最先进的Noise协议进行安全通信。Stronghold将构成新的IOTA Firefly钱包的安全基础。

在智能设备日益互联的世界里，无论是电话、能源表、电视，甚至是信用卡，真正安全的重要性只会越来越高。物联网设备需要在充满危险的网络上安全地相互通信。读到这里的人一定很清楚，非常需要保证数据的安全，比如身份和数字许可证不被集中式黑客攻击。问题不在于这种风险是未知的。只是要正确地解决这个问题，是一个非常困难的挑战。我们接受了这个挑战，保护IOTA生态系统，并建立任何人都可以使用的库。

自Stronghold首次公布以来，我们一直在壮大团队，修改引擎的内部结构，并研究可以用Stronghold构建的应用。今天，我们很高兴地宣布Alpha版本，它将研究转向开发。我们将这个版本命名为 “Saint-Malo”，取自法国北部布列塔尼海岸的一座奇妙的堡垒城市，在第二次世界大战后重建。那个曾经的海盗藏身之地已经恢复并存活下来，它巨大的城墙保护着它免受海潮的巨大攻击。

你可能会问自己，”alpha “是什么意思？是什么让一些软件成为 “alpha”，而一些软件成为 “beta”–它什么时候才能成为 “稳定版”？软件开发中的这些阶段与代码稳定性有关，也与项目工程师与消费者的合同有关。以Stronghold为例，我们宣布我们的项目是 “alpha “级别，就是告诉你，我们认为它足够好，可以进行实验。我们已经将理论付诸实践，修改了我们的假设，并试图在最大的安全性和可用性之间找到平衡点。现在我们希望得到您的反馈，我们将把这些反馈纳入下一阶段的开发中。

在alpha阶段，您可以期待Stronghold将继续保持现在的功能。然而，我们将改变一些内部机制，也可能改变其暴露的API的一些小方面。我们不建议外部人员在生产中使用Stronghold，因为在我们进入测试阶段之前，情况可能会发生快速变化–特别是在Firefly的外部安全审计期间，以及它与Stronghold的集成期间。在测试阶段，我们将为Stronghold进行完整的安全审计做准备，之后我们将最终确定稳定版本的规范和文档。

不过，如果你想现在就动手，并且能熟练使用命令行，这里有一个快速测试Stronghold的方法。

访问GitHub的发布页面，下载预制的Stronghold命令行二进制文件，用于你的平台。如果你更有冒险精神，更精通Rust，你可以克隆GitHub repo，为你的系统在本地构建。

git clone git@github.com:iotaledger/stronghold.rs.git
cd stronghold.rs/products/commandline
cargo build –release

本文余下的部分将更深入地概述Stronghold的架构，技术性很强。

概述

• Stronghold与其他数据库有何不同？
• Stronghold引擎和内部角色模型
• 新的客户端界面
• 加固Stronghold
• 专用的密码学箱子 – crypto.rs
• 释放和安全地消耗Stronghold
• X-Teams

什么是Stronghold，它与其他数据库有什么不同？

Stronghold是一个用Rust编程语言编写的软件库。它提供了一个加密的、持久的数据库，用于在一个安全的计算区执行加密操作，可以分布在多个设备上。我们曾多次被问及Stronghold与其他数据库的区别。这可以归纳为三大区别。

1. Stronghold记录（及其文件备份）是 “自然加密 “的，用于缓解离线攻击。大多数其他数据库需要你自己通过库、插件或底层加密的文件系统来应用加密。
2. Stronghold允许您对这些存储的数字秘密进行操作，而不会将它们暴露给外部进程，并防止这些秘密以解密的形式输出。(参见下面的硬化堡垒)
3. 多个Strongholds可以像网络一样工作，以许可的、分散的方式进行沟通和协作。(将于2021年1月推出)。

Stronghold引擎和内部角色模型

https://github.com/iotaledger/stronghold.rs/tree/dev/engine

在我们深入了解客户端界面的细节之前，必须先简单讨论一下底层架构。

Strongholds由一个二进制文件持久化，我们称之为 “快照”。这些文件在静止状态下是加密的，可以在设备和不同的操作系统之间传输。一旦快照被解密，它就会作为一个金库（或多个金库）存在于内存中。为了访问内存中的记录并解密它，你需要知道它的路径。一旦你有了记录内容，你就可以对该记录进行操作并返回结果。这一切都非常复杂，如果操作不当，就会有泄密的风险，这也是我们使用Stronghold首先要避免的。

行动者模式是一种架构，在这种架构中，各个 “行动者 “之间相互发送消息，而不是直接调用函数和传递内存。这是一种很好的模式，不仅提供了进程隔离，还允许我们向其他设备发送消息。我们已经设计了接口，正如你将在下面看到的那样，你不会被迫在你的代码中使用actor模型，但如果你愿意，它是可用的。

新的客户端界面

https://github.com/iotaledger/stronghold.rs/tree/dev/client

自从我们最初的实施以来，整个客户端界面已经被重建，使用Riker角色模型和 “ask模式”。这使得Stronghold能够隔离其内部架构，而不需要强迫任何更高级别的库或应用程序使用Riker（或任何actor模型）。

• 该接口可以被附加在Stronghold对象上的异步方法调用。
• 在每次方法调用时，都会创建一个临时的actor，并将未来传回给消费库。
• 调用完成后，角色会被垃圾回收，未来会被解析。

这一切都得益于Riker的轻量级actor抽象。

Stronghold对象在内部创建了多个actor系统，这些系统是使用客户端路径标识符定义的。这些系统中的每一个至少由2个actor组成：一个快照actor和一个内部Stronghold actor，每个actor都有来自客户端路径的唯一标识符。一个快照行为体被旋转起来，因此当一个快照被写入时，它将所有相关的客户端系统中的数据封装在一起。相反，当一个快照被读入系统时，它将为每个缓存/内部作用器对分别进行缓存和读取，从而使消费者能够确保数据以可预测的方式进行布局。通过这种方式，可以读取快照的一部分或全部快照。

在客户端抽象下，有基本的Stronghold引擎–一个安全的版本化键值存储协议。这个系统和分区运行时一起存活在内部行为者内部。版本化已经通过一个位置API成为一个选择功能。每个位置定义了每个客户端系统和其中的金库和记录之间的关系。一个客户端就是一个金库的集合，而一个金库就是一个记录的集合，每个记录都拥有一条数据。

位置API允许消费者指定一个通用位置或计数器位置。通用位置定义了一个固定的库和记录路径。这些通用位置不使用版本管理，可以被覆盖。而位置计数器则利用计数器来定义记录索引。当消费者使用位置计数器时，他们可以直接指定计数器的值，也可以让系统为他们指定。如果没有明确提供计数器，系统将默认为金库的 “Head”。金库的Head是根据操作来定义的，如果操作是读，Head将是金库中最后写入的记录，如果操作是写，Head则是根据线性计数器的值来写下一条记录。

除了基本的数据库式操作，Stronghold还通过其运行时提供了大量的加密操作。每一个加密操作都被定义为一个过程。具体的输入和输出是根据需要为每个过程指定的。例如，比如像Firefly这样的调用程序想要使用一个记号来生成一个加密种子，然后用这个种子推导出Ed25519密钥对来签署一段数据，他们可以通过调用相应的程序来实现。”BIP39 Generate “可以被调用，以从所提供的口令中生成一个种子。”SLIP10 Derive “可以在这个种子位置上调用，以创建一个密钥，这个密钥又存储在Stronghold中。 现在可以在这个密钥位置上调用 “Ed25519公钥 “来导出所需的公钥，然后调用 “Ed25519签名 “来签署数据。在这个操作中，从Stronghold返回的数据只有签名和公钥。 其他所有数据都会被保存在Stronghold内部的指定位置，以保证安全。

加固Stronghold

https://github.com/iotaledger/stronghold.rs/tree/dev/runtime

一些操作系统和硬件平台为增强运行时的安全性提供了独特的机会。因此，我们在Stronghold中开发了一个安全的计算区，它使用进程沙盒和syscall过滤来做一个计算飞地。我们还利用了一个带有防护页的自定义内存分配器，允许我们在不使用时限制对内存的访问。这些飞地工具可以被其他项目使用，即使它们不需要完整的Stronghold特性集。

对于不熟悉的人来说：syscall过滤使得一个进程放弃访问操作系统资源的权利成为可能。举个例子：为什么加密算法需要访问文件系统，甚至是文件描述符（记住：在Unix中一切都是文件）？为了应用这些限制，包装器从主进程（例如，包含UI和网络代码的钱包应用程序）分叉，然后执行敏感操作。这也为内存隔离和抵御潜在的恶意派生线程增加了额外的好处。

安全区属性

为了增加系统整体安全的防御深度，应用了安全区的以下功能（如果操作系统提供的话）。

1. 进程隔离：分叉到安全区(运行时)，并应用一个具有非常限制性的允许系统调用集的acceptlist。
2. 内存管理：在安全区内部，只能使用带有防护页和限制性内存保护的分配方式。
3. 通信：传入的请求(TX)从继承的父内存中读取，传出的结果(RX)使用分叉前生成的短暂密钥进行加密和认证。

还可以指出的是，这些措施使得已经被入侵的系统更难被探查，也就是说，这是深度防御而不是完美安全。为此，我们需要在专用硬件上生产和分发Strongholds，比如USB Armory Mk-II。

crypto.rs

https://github.com/iotaledger/crypto.rs

随着2019年IOTA基金会决定过渡到Rust编程语言，基金会的很多软件库和产品都在使用Rust。一直以来，人们越来越需要一个经过适当审核和维护的密码学库，收集IOTA中应用所需的密码学基元和算法。密码学必须经过审核、维护和适当的审查。

不幸的是，密码学很容易出错，错误可能会产生非常真实的影响。事实上，这也是IOTA Stronghold项目的主要目标之一。让安全使用密码学变得容易–所以我们在狗食我们自己的哲学。

为此，我们已经整合了IOTA所需的整个密码学家族。

来源：https://github.com/iotaledger/crypto.rs/blob/dev/README.md

发布和安全验证

对于任何一个关注安全保障的库来说，拥有一个可靠的发布策略是非常重要的。像许多其他现代的包发布系统一样，Rust拥有Cargo Crates生态系统。我们使用Tauri社区开发的covector polyglot changelog和发布工作流自动发布到crate.io。Covector实现了一个交钥匙的发布流程，只需最少的人工干预和一个经过审核的管道，用于测试、构建、过滤、审计、变更日志、合并到主分支、创建git发布标签、制造工件（如命令行二进制）、在Github上发布新版本，然后发布到crates.io。

然而，在Stronghold和Crypto.rs稳定下来之前，所有资源都可以纯粹从crate.io（而不是git）获得，我们的资源将只能在GitHub上获得。我们深表歉意，但正在夜以继日地工作，以使 crates 及其文档能够正常使用。

虽然crates.io很强大，而且一般来说比NPM更稳定，但crates.io仍然是集中式的，这使得验证远程crates具有挑战性。为此，我们建议你的Rust项目总是通过git哈希来验证Stronghold，因为这样你可以绝对验证你所接收的代码是你所期望的。

[dependencies.iota-stronghold]
git = “https://github.com/iotaledger/stronghold.rs”
rev = “fdff9f22c087f0c027e4aaa5a8dbc40218e6cf52”
Trust, but verify.

X-Teams

你是了不起的，因为你读完了整篇文章，这就是为什么我们希望你能与我们紧密合作，帮助发展Stronghold的未来。

无论你是否认为自己是IOTA社区的成员，我们都邀请你为Stronghold带来你的经验。为此，请通过此表格申请加入X-Team，并加入将于2021年1月举行的启动会议。

你可以通过以下网址关注进度：https://github.com/iota-community/X-Team_IOTA_STRONGHOLD。