十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

Zcash 安全警告全解析:钱包加密、侧信道攻击与链重组风险的实战防护指南

Zcash 安全警告全解析:钱包加密、侧信道攻击与链重组风险的实战防护指南 Zcash 安全警告全解析钱包加密、侧信道攻击与链重组风险的实战防护指南【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash本文档以仓库内 用户安全警告 为骨架系统梳理 Zcash 节点运营者与持币用户必须了解的安全边界钱包加密为何默认禁用、侧信道攻击面何在、REST/RPC 接口的暴露风险、JoinSplit 锚定机制下的链重组差异以及z_*系列 RPC 调用日志的隐私泄露面。阅读本文后你将掌握 Zcash 的安全模型限制与可落地的加固措施并能在部署zcashd时做出符合隐私预期的配置决策。官方安全审计与信息渠道Zcash 在上线前接受过正式的第三方安全审查Security Audit。与安全性相关的公告、审计报告及其他通用安全信息统一汇总在 z.cash 官网的 Security 支持页面即官方文档中引用的https://z.cash/support/security.html对应内容包括漏洞披露、升级建议与审计结论。需要强调的是第三方审计并不等于零漏洞。本仓库 安全警告文档 明确指出审计之外仍存在几类已知风险钱包加密缺失、侧信道泄露、REST 未审查等运营者应持续关注官方安全公告而不是把一次审计当作永久的安全保证。钱包加密为何在 Zcash 中默认禁用Zcash 沿用了 Bitcoin 的wallet.dat架构但钱包加密Wallet Encryption在默认情况下是禁用的原因有三层层层都与屏蔽交易shielded transactions的隐私模型冲突原因一加密钱包无法正确检测屏蔽花费JoinSplit 的不可链接性unlinkability决定了加密钱包在锁定时无法识别屏蔽花费从而可能错误地显示偏大的可用屏蔽余额直到钱包下一次被解锁。更严重的是这个问题不只是“漏认一笔花费”那么简单余额可能因为一次花费的找零而增加却未扣除已花费的金额导致显示余额虚高。原因二加密无法维持屏蔽属性加密钱包虽然能阻止资金被花费但无法维持 JoinSplit 的屏蔽属性——因为钱包必须解密检测花费锁定时持有的加密wallet.dat反而给了拥有者对你整个交易图谱的完整可见性除了受上述问题困扰的新检测花费之外。也就是说加密钱包在“防窃取”与“保隐私”之间两头不讨好。原因三密钥派生算法对字典攻击的抵抗性存疑钱包加密密钥的派生算法继承自 Bitcoin作者担心其面对强力攻击者发起的字典攻击dictionary attack时抵抗性不足。文档明确表示若将来重新启用钱包加密大概率会采用现代基于口令的密钥派生算法例如Argon2i以提供更强的抗字典攻击能力。源码佐证加密功能被实验性开关封锁从源码结构看钱包加密并未从代码中删除而是被实验性特性开关严格限制src/experimental_features.cpp 中定义fExperimentalDeveloperEncryptWallet只有同时开启-experimentalfeatures与-developerencryptwallet两个参数才会置真src/wallet/rpcwallet.cpp 的encryptwalletRPC 在该开关未开启时直接抛出Error: wallet encryption is disabled.帮助文本也反复标注 “Wallet encryption is experimental, and this API should be used with caution”。因此官方建议的静置保护方案是使用全盘加密full-disk encryption或主目录加密来保护钱包并且默认假设同一操作系统上运行的其他即使无特权的用户都能读取你的wallet.dat文件。侧信道攻击屏蔽证明的隐私泄洪口本实现对侧信道攻击不具备抵抗力。任何能在zcashd所在硬件上执行代码的用户即使无特权或物理上靠近该硬件的用户都可能通过观察 JoinSplit 操作期间的缓存cache侧信道确定你的私密花费密钥secret spending keys值以及你正在花费哪些 note——文档归因于 libsnark 证明机制proving machinery中可能的侧信道泄露通过观察增量见证incremental witnesses随新 note 更新时的缓存侧信道信息泄露确定你拥有哪些 note通过观察链上每个 note 密文的试解密trial decryption过程确定你拥有哪些 note。这些攻击不需要突破密码学本身而是利用现代 CPU 缓存时序这一物理层信息。因此文档给出的结论性建议是在这些漏洞被完全分析与修复之前应确保没有任何其他用户即使无特权能在你运行zcashd的硬件上执行代码。对于云主机、共享服务器或多用户环境这意味着需要专用的隔离环境独立实例、硬件隔离或受信执行环境。REST 接口默认关闭的继承特性REST 接口是从上游 Bitcoin 继承的功能默认情况下处于禁用状态。文档不建议在其通过安全审查前启用。源码印证了这一默认策略src/init.cpp 中DEFAULT_REST_ENABLE定义为falsesrc/init.cpp 中 REST 服务仅在GetBoolArg(-rest, DEFAULT_REST_ENABLE)为真时才启动即必须显式传入-rest1才会打开。由于 REST 接口以公开 HTTP 方式暴露链上数据且未经过与 RPC 同级别的审查日常运营中保持默认关闭即可除非你有明确的只读查询需求并已完成风险评估。RPC 接口密码强度、绑定范围与委托攻击RPC 接口是节点管理的核心入口也是攻击面最大的部分文档给出三条铁律1. 必须设置强 RPC 密码用户应选择强 RPC 密码。如果未设置 RPC 用户名和密码zcashd将拒绝启动并打印错误信息同时附带一个强随机密码建议。原因在于只要客户端知道 RPC 密码就至少拥有节点的完整访问权此外某些 RPC 命令可被滥用去覆盖文件甚至接管运行zcashd的账户。从源码看现代 Zcash 还提供了更安全的认证路径src/httprpc.cpp 的InitRPCAuthentication()在未设置-rpcpassword时自动启用随机 cookie 认证cookie-based auth无需手工配置密码同时支持-rpcauthusername:salt$hash这种不落盘明文密码的 HMAC 认证方式src/init.cpp配套的生成脚本位于 share/rpcuser/rpcuser.py它会使用系统加密随机源生成 16 字节 salt 与 32 字节随机密码输出可直接追加到zcash.conf的rpcauth行。2. 保持仅允许 localhost 连接用户不应修改“仅允许来自 localhost 的 RPC 连接”这一默认设置。允许远程主机连接会使中间人MITM能够执行任意 RPC 命令进而可能危及运行zcashd的账户并导致资金损失。对应参数为-rpcbind与-rpcallowipsrc/init.cpp除非经过严格网络隔离否则不要开放。3. 防范“混淆代理”攻击Confused Deputy对于在后端使用一个或多个zcashd实例的多用户服务必须严格控制用户传入的参数防止 confused-deputy 攻击——即攻击者诱导后端进程以其持有的密钥代为执行花费操作从该zcashd持有的任何密钥中盗取资金。文档还提示未来虽可能限制部分高危命令但只要钱包方法未被禁用拥有完整节点访问权依然意味着能够花费钱包中的资金、导出密钥。链重组Reorg的主要差异JoinSplit 锚定的脆弱性Zcash 在链重组行为上与 Bitcoin 存在显著差异理解这点对接收资金的安全阈值设定至关重要Bitcoin 的 coinbase 成熟期规则保证任何短于成熟区间的重组都不会使被回滚的交易失效Zcash 保留了100 区块的 generation 交易成熟期对应 src/consensus/consensus.h 中的COINBASE_MATURITY 100但由于JoinSplit 必须锚定anchored在某个区块内这一保护对交易失效的防护作用更为有限发生链重组时所有锚定在重组区间内的 JoinSplit 及其依赖交易都会失效交易被回滚、资金退回原所有者从 Bitcoin 继承的交易重播rebroadcast机制无法成功重播依赖失效 JoinSplit 的交易当锚需要改变时。因此失效 JoinSplit 的创建者以及所有依赖它的交易的创建者必须自行重播交易。缓解手段提高最小确认数JoinSplit 的收款方可以通过提高minconf最小确认数来缓解“依赖可能被回滚交易”的风险。在调用z_*系列收款与转账命令时应结合链重组窗口合理设置确认数要求避免在重组高发期基于未确认或低确认资金做进一步操作。记录 z_* RPC 调用日志即隐私泄露面z_*系列调用z_sendmany、z_mergetoaddress、z_shieldcoinbase等是隐私操作的核心入口其调试日志按敏感程度分为两级-debugzrpc常规级别覆盖z_*调用的常规日志会揭示关于私密 note 的信息例如调用z_sendmany创建屏蔽交易时输入 note 被消耗、输出 note 被新建的过程。适合日常排查调用是否正确执行。-debugzrpcunsafe敏感级别覆盖z_*调用中仅调试与审计才需要的敏感信息例如检查被花费 note 的 memo 字段内容。该选项隐含启用zrpc源码中 src/init.cpp 明确处理了这一参数联动setting -debugzrpcunsafe - -debugzrpc。关键边界z 地址的私密花费密钥永远不会被记录源码中LogInputs等路径也只输出 note 的 txid、索引与金额见 src/wallet/wallet.cpp。源码中的分级日志实践从实现看两类日志的区分非常细致例如 src/wallet/asyncrpcoperation_sendmany.cpp 在zrpcunsafe级别记录完整调用参数params%s在zrpc级别仅记录“已初始化”金额汇总中透明部分走zrpc屏蔽输入/输出与请求费率走zrpcunsafe同文件 L164-L180z_mergetoaddress、z_shieldcoinbase与 Sapling 迁移操作也遵循同一模式底层 src/transaction_builder.cpp 在构建 JoinSplit 时找零 note、输入输出金额、memo 等均以zrpcunsafe记录。运营建议生产环境默认不要开启-debugzrpcunsafe仅在进行受控的审计排查时临时开启并在日志轮转与访问控制上按敏感数据处理。可能缺失的必需修改留给用户的核查清单Zcash 是在 Bitcoin Core 基础上深度改造的产物其安全性取决于三个层面新增代码的正确性、对 Bitcoin Core 修改的正确性以及那些“本应修改却可能遗漏”的变更——可能是因为从未考虑过也可能因为时间不足而未完成。社区已在仓库的 issue文档中引用的 GitHub issue #826中头脑风暴并记录了多种此类可能性并认为 1.0.0 发布所需的变更已全部完成。文档建议用户自行查阅该清单结合自己的使用场景判断风险。这也再次印证了 Zcash 安全模型的核心理念隐私保护不能只依赖默认配置节点运营者需要理解每项安全边界并主动决策。总结一份可执行的安全检查清单将本文要点浓缩为部署与使用zcashd时的行动项关注点官方立场推荐动作钱包静置保护钱包加密默认禁用使用全盘加密/主目录加密保护wallet.dat侧信道攻击不具备抵抗性隔离硬件执行环境禁止他人在同一硬件上运行代码REST 接口默认关闭、未经审查保持-rest关闭RPC 认证强密码或 cookie/rpcauth使用-rpcauth或 cookie 认证保持仅 localhost 监听RPC 多用户服务防 confused-deputy严格校验用户传入参数链重组JoinSplit 锚定失效风险提高 minconf自行重播失效交易调试日志zrpcunsafe泄露敏感信息默认关闭审计时临时开启关于钱包备份与更详细的文件布局可进一步阅读仓库内 钱包备份指南 与 文件说明本文的全部结论均可回溯至 安全警告文档 及上述标注的源码文件。【免费下载链接】zcashZcash - Internet Money项目地址: https://gitcode.com/GitHub_Trending/zc/zcash创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表