
适用范围与技术基础
TSS 通常指门限签名方案:各参与方持有同一私钥的份额,达到规定门限后协作生成签名。NIST 门限密码学项目介绍将这类机制放在安全多方计算框架下,强调密码操作中的信任分散,研究范围也包括密钥生成等环节。这里讨论通用风险,不对任何具体钱包作安全结论。
检查门限与实际控制关系
RFC 9591 对 FROST 的介绍指出,门限方案通常假设攻击者控制的签名参与方数量严格少于门限。检查钱包时,需要明确总参与方数量、完成签名所需数量,以及每一方实际由谁控制。
份额分布在不同设备,并不能单独证明控制权相互独立。如果同一管理员或同一访问凭据能够控制足够多的参与方,信任分散的效果就会受到限制。还应区分两种风险:控制足够份额可能威胁签名安全,可用参与方不足则可能导致无法签名。
检查协议名称与适用条件
RFC 9591 描述的是两轮 Schnorr 门限签名协议 FROST,并列出具体密码套件。评估时应确认钱包实际采用的协议、套件和签名验证要求,不能仅凭“TSS”或“MPC”标签推断其安全性质,也不能把 FROST 的结论直接套用于其他门限签名方案。
检查随机数与签名状态管理
RFC 9591 特别说明,FROST 不能照搬单方 EdDSA 的确定性 nonce 生成方式,其 nonce 生成结合新鲜随机性与秘密输入。错误的 nonce 处理可能造成严重的密钥安全问题。
对应的检查问题包括:随机性如何产生,nonce 是否受到防重复使用保护,以及签名失败重试、设备恢复或并发请求时如何管理状态。仅确认使用了安全哈希函数,不能覆盖这些实现风险。
检查密钥生成与恢复边界
RFC 9591 的主体范围不包括 FROST 密钥生成,附录提供了可信分发者方式。这意味着符合某个签名协议,不能自动证明钱包的初始化、备份和恢复流程同样安全。应进一步核对份额生成者、备份访问权限,以及恢复流程是否改变原有门限控制关系。
常见问题:有 RFC 就代表钱包获认证吗
不能。RFC 9591 属于信息类文档,并非互联网标准轨道规范;NIST 开展门限密码学研究,也不等于为引用该研究的钱包背书。协议名称和文档引用可以帮助界定技术依据,具体钱包是否正确实现、参与方是否独立、恢复机制是否保留门限约束,仍需要对应的实现说明与验证证据。