超越私钥风险:智能合约安全成熟度模型解析

本文深入分析智能合约私钥泄露风险,提出四级访问控制成熟度模型,涵盖多签钱包、时间锁、最小权限原则及完全去中心化设计,帮助开发者构建抗私钥泄露的健壮协议。

超越私钥风险:智能合约安全成熟度模型

“找出所有漏洞!”——这是大多数协议在部署前保护智能合约的主要口号。团队大量投入审计、竞赛、模糊测试和形式化验证,旨在检测每一个潜在漏洞。但如果我告诉你,去年加密货币黑客攻击的最大原因并非智能合约漏洞呢?

答案:私钥泄露!

私钥攻击(通过滥用密钥材料窃取资产)是一种新兴攻击向量, narrowly scoped 的智能合约审计和竞赛可能会忽略。协议对这些攻击的敏感性取决于其设计,尤其是访问控制的成熟度。本文将演示如何通过多签、时间锁、最小权限原则以及最小化私钥使用的设计方法,设计能够安全容忍私钥泄露的协议。

私钥泄露已成为最成功的攻击方式

根据 Chainalysis 2024 年报告,通过黑客攻击窃取的资金中,高达 43.8% 源于私钥泄露——比其他已验证攻击类型高出五倍。私钥泄露是每个工程师在设计新智能合约和协议时必须考虑的新兴威胁。

设计决定风险,历史上很少有区块链协议将认证智能合约访问视为重要风险向量。这种疏忽因区块链安全生态系统的运作方式而加剧:由区块链原生公司进行的审计很少将架构访问控制问题标记为正式发现,而竞赛平台积极 discourages 此类提交,偏向代码级漏洞。

这种 narrow focus 与其他行业 established 安全实践形成对比,在其他行业中,权限升级和访问控制设计等架构风险是安全参与过程早期解决的基本问题。

在 Trail of Bits,我们通过 Codebase Maturity Evaluation 标记架构访问控制问题。然而,大多数区块链协议仅在软件开发生命周期最后阶段寻求外部输入和审查,此时几乎没有时间和机会修复系统性访问控制问题。

这就是为什么我们需要在开发生命周期早期转变对话。本文旨在弥合这一差距,为开发人员提供所需的理解,以设计从第一天起就对私钥泄露更具弹性的系统。

案例研究:超额抵押借贷提供商

我们将使用一个理论上的超额抵押借贷提供商作为示例,说明不同级别的访问成熟度。对于不太熟悉借贷协议的人,以下功能通常需要某种级别的特权访问控制:

  • 列出/取消列出支持的资产(抵押品和可借资产)
  • 设置风险、利率参数和预言机源
  • 收取协议费用/储备金
  • 在紧急情况下暂停/恢复协议功能
  • 升级合约

然而,这些访问控制机制的具体设计将 drastically 改变整个系统对私钥攻击的脆弱性。

级别 1:高度暴露 - 单一 EOA 控制器

这是最不成熟、最基本的访问控制形式。在此设置中,单个 EOA 持有借贷协议所有管理功能的最高权限。根据此密钥的使用频率,或在紧急情况下必须使用的速度,它可能必须存在于连接到互联网的计算机上的软件钱包中。这至少不理想。

成熟度级别 1:单点故障,一个受损的 EOA 意味着协议完全妥协

此类系统的泄露风险巨大,泄露的影响是灾难性和立即的。一旦私钥泄露,攻击者可以升级合约、窃取抵押品并摧毁协议。没有人能得到兰博基尼。

如何改进到级别 2

缓解此单点故障的最直接步骤是过渡到使用多签钱包,要求任何操作都需要多个密钥持有者的共识。

注意:虽然此操作降低了泄露风险,但如果私钥泄露,它不会改变潜在的损害范围。

级别 2:基本缓解 - 集中式多签

认识到单个 EOA 控制器的极端危险,成熟度的下一步涉及将管理权转移给多签钱包,通常是 M-of-N Safe Wallet 或类似结构。

成熟度级别 2:集中式多签模型。需要多个签名者,但仍然存在单点控制

此设置肯定比级别 1 有所改进,因为泄露单个签名者的密钥不再足以让攻击者接管协议。然而,如果足够多的签名者被泄露、串通或被操纵签署恶意交易,仍然存在重大风险和潜在影响:

  • 执行速度:一旦获得第 M 个签名,恶意操作可以立即执行,没有时间进行安全响应。
  • 单点控制:虽然故障点现在分布在 M 个密钥上,但控制点仍然是单一的。多签作为一个实体仍然持有对协议的最终权力,甚至常规、低风险交易需要与协议升级相同的签名权限。

一些利用高度保护的单点控制的黑客攻击示例包括 Bybit hack、WazirX 和 Radiant Capital。在这些攻击中,攻击者能够 compromise 单一关键控制点(多签),尽管风险分布在多个故障点上。

如何改进到级别 3

如果你对级别 2 不印象深刻,我不怪你。从级别 2 移动到级别 3 是真正成熟之旅的开始。要达到下一个成熟度级别,需要实施两组控制:时间锁和最小权限原则(PoLP)。

时间锁是可以在操作批准和执行之间创建“延迟”的合约,允许时间进行审查和事件响应。

最小权限原则涉及逻辑上分离角色和职责,授予每个角色仅其特定功能所需的最低权限。这确保如果一个控制点被泄露,潜在损害被遏制,并且不授予攻击者访问无关关键系统功能的权限。

级别 3:增强控制 - 时间锁和角色分离

此级别通过解决级别 2 的核心弱点,代表了成熟度的显著飞跃:执行的即时性(使用时间锁解决)和控制的集中性(使用 PoLP 解决)。一些级别 3 协议示例包括 Aave、Compound Finance 和 Lido。

成熟度级别 3:时间锁和角色分离为智能合约创建深度防御

当批准的操作可以立即在链上执行时,社区,更重要的是你的安全团队,没有时间响应。使用时间锁合约允许你创建一个新的、重叠的控制:取消已批准交易的能力。

当已批准交易在时间锁中等待时,团队可以使用 Tenderly 等链下工具监控它,并根据预期批准进行审查。如果签署了意外请求,时间锁给你的事件响应团队时间审查、取消并启动事件响应过程。

适当监控和警报时间锁至关重要;没有它,控制毫无价值,如 Beanstalk hack 所示,其中一天的时间锁未被监控,导致可预防的黑客攻击。

通过遵循最小权限原则,我们可以识别系统中至少需要四个角色,将不同风险级别的职责分离到不同的桶中:

  • 核心系统角色:此角色是系统中最特权的,因此具有较大的多签阈值和时间锁延迟。由于此角色仅限于单一职责(升级合约),它不太可能经常使用,减少了多签钱包用于其他活动的操作风险。
  • 操作角色:此角色用于日常协议操作和配置。它使用中等长度的时间锁和中等多签阈值,以反映潜在泄露的较低影响。
  • 暂停守护角色:此角色负责在紧急情况下暂停协议。它不应 behind 任何类型的时间锁,其多签阈值应相对较低,以允许在紧急情况下快速响应。
  • 取消守护角色:此角色可以取消在时间锁中挂起的已批准交易。你的安全团队应使用此角色取消未经授权的批准。根据你的事件响应过程设计,它可能是低阈值多签钱包或 EOA。

与级别 2 相比,级别 3 架构的风险 drastically 降低。我们已成功从一个控制点迁移到四个,并使用 PoLP 减少了由泄露控制点引起的影响。现在,你的事件响应团队实际上可以在多签泄露事件中停止事件。

然而,风险仍然存在:

  • 复杂性风险:引入多个角色、多个多签钱包和多个时间锁增加了系统复杂性,如果未仔细实施和彻底测试,会创建新的错误或错误配置途径。
  • 过度依赖暂停:暂停守护角色虽然对紧急情况必要,但不是万能药。攻击者已变得更先进,攻击通常在私有内存池中进行,以防止主动识别。随着攻击者变得更先进,暂停作为减少攻击影响机制的效力可能会随时间下降。

如何改进到级别 4

虽然大多数协议通常对级别 3 满意,但复杂性风险和紧急暂停效力的下降 necessitates 更高级别的访问成熟度。级别 4 代表任何成熟协议的最终目标,其成熟度特征是完全不需要强大操作,协议变得真正去中心化。

级别 4:最终目标:完全不可变性和用户主权

级别 4 代表访问控制设计成熟度的顶峰:完全消除管理操作的需要。这是协议可以做出的对去中心化和信任最小化的最极端承诺,其好处是从协议威胁模型中 categorically 消除访问控制。

成熟度级别 4:系统不可变,控制点很少(如果有)

实现级别 4 需要 drastically 不同的设计方法,与迄今为止任何其他级别相比,大多数针对级别 4 的协议不是“纯”级别 4 协议。Uniswap 和 Liquity 是一些 strive for 级别 4 的最佳示例:它们不需要任何管理来促进操作,但确实有一些极其有限的管理控制以允许费用/激励分配。

不要将级别 4 的哲学与简单地将控制委托给 DAO 或其他官僚实体混淆;级别 4 协议不需要任何类型的管理控制即可成功运行。

对于许多用例,级别 3 和级别 4 之间的设计转变几乎不可逾越。考虑中心化交易所冷钱包:除非整个交易所成为去中心化协议,否则必须对钱包有某种级别的管理访问以将资金转移给用户。

对于完全链上协议,级别 4 是可能的但仍然 daunting;对于我们的超额抵押借贷系统,我们需要 fundamentally 重构系统设计。对于每个先前需要管理的组件,我们必须设计一个完全不需要管理的替代方案:

  • 可升级性:在级别 3 及以下,系统的智能合约可以升级以修复错误或添加新功能。在级别 4 协议中,系统的智能合约完全不可变。要向协议添加新功能,必须部署一套全新的合约,用户必须手动将资金转移到新系统。由于升级无法修复安全错误,系统的合约必须简单、简洁、经过 extremely well 测试、验证和审查。
  • 列出/取消列出资产:在大多数超额抵押借贷协议中,列出和取消列出资产是管理操作,因为如果添加抵押品是无许可的,恶意代币可能被利用来窃取抵押品。对于实现级别 4 的借贷协议,它可能支持自包含市场部署。在此系统中,要添加对新资产的支持,必须部署一个全新的、独立的借贷协议版本,并 explicitly 为该新资产或资产集配置。用户然后必须选择与此单独部署或具有不同资产的另一个部署交互。
  • 风险参数代表另一个通常由管理员管理的配置。在级别 4 借贷协议中,这些参数要么在新资产部署时永久设置,要么永久设置为遵循某种算法参数。由于这些值将永久设置,通过 rigorous 建模、测试和验证 well-characterized 其行为至关重要。

设计级别 4 协议有 significant tradeoffs:紧急干预不可能;系统一旦部署就不灵活;并且有巨大的初始负担来验证设计的安全正确性和经济稳健性。

尽管有这些权衡,此设计范式 categorically 消除访问控制风险,并且级别 4 协议中使用的许多设计模式可以改进系统安全性的其他方面。

级别 4 体现了去中心化赛博朋克精神的纯粹主义愿景,优先考虑不可变性和用户主权 above 管理灵活性。

为弹性设计,不仅仅是反应

当我们遍历访问控制成熟度级别,从单个 EOA 控制器的 degen 简单性到级别 4 的激进赛博朋克不可变性时,一个单一真理变得清晰:你设计协议的方式 fundamentally 决定其对私钥泄露的脆弱性。

随着 2024 年 43.8% 的被盗资金源于私钥泄露,忽略架构访问控制不再可接受。虽然传统错误搜寻仍然 essential,但这些设计决策必须在开发更早阶段做出才能有效。

以下是一些你今天可以采取的主动步骤:

  • 根据成熟度框架评估你的协议。诚实地看待你的立场。大多数项目从级别 1 或 2 开始。
  • 为你的最高风险管理功能实施时间锁合约。即使此单一更改也 significantly 改善你的安全状况。确保这些时间锁合约得到充分监控,以确保你可以在未批准交易排队时响应。
  • 映射你协议的特权功能,并根据最小权限原则将它们分离到逻辑角色中。
  • 考虑你系统的哪些组件可以从级别 4 不可变性模式中受益,即使你的整体设计需要管理控制。

在 Trail of Bits,我们倡导这种整体安全观。这就是为什么我们提供设计审查和设计阶段咨询等服务,专门针对开发生命周期早期的项目。这些服务允许团队接收专家指导和建议,以主动解决这些基本问题,补充 later on 关注实现漏洞的传统代码审计。

最终,构建安全去中心化系统需要的不仅仅是搜寻错误。它要求从第一天起就致力于为操作弹性设计。通过理解成熟度模型并有意识地选择最小化信任和限制泄露潜在影响的设计模式,你可以构建不仅创新而且真正健壮对抗去中心化世界 evolving 威胁的协议。

comments powered by Disqus
使用 Hugo 构建
主题 StackJimmy 设计