签名购买授权(Mandate)原理详解：ed25519与一次性nonce如何守护你的钱包

签名购买授权(Mandate)原理详解ed25519与一次性nonce如何守护你的钱包【免费下载链接】northcinderBuyer-run, ad-neutral shopping-agent MCP software with deterministic ranking, signed purchase mandates, and a local audit trail.项目地址: https://gitcode.com/gh_mirrors/no/northcindernorthcinder 是一款由买家自己掌控、天然屏蔽广告干扰的购物Agent软件它的核心承诺只有一条任何一笔购买都必须经过你本人的签名购买授权Mandate。这份授权以 ed25519 密码学签名作为防伪印章以一次性 nonce 作为一次性凭证从密钥生成、授权签发到逐项验证全链路本地完成、可审计、可验证。接下来我们一起拆解这套签名购买授权机制是如何一步步守护你的钱包的。购物Agent为何需要签名购买授权先看懂Mandate是什么传统购物助手替你下单时通常只有你点了确认这一层薄弱的信任。而 northcinder 把信任升级成了可验证的密码学承诺每一次结账前软件会在你本机生成一份结构化的授权文件——Mandate。这份 Mandate 明明白白写清了五件事买什么对应的商品 offerId从哪买目标商家 merchantId最多花多少包含运费的金额硬上限maxAmount多久有效签发时间与过期时间默认 15 分钟是否唯一一个随机生成的一次性 nonce只要其中任何一项在签名之后被人篡改验证环节就会立刻判它无效。这份数据结构的定义位于packages/protocol/src/schemas/core.ts而签发与验证逻辑全部封装在packages/checkout/src/mandate/目录下。ed25519密钥对私钥永不出本机的本地签名方案签名购买授权靠的是 ed25519 非对称加密——一把私钥负责签字一把公钥负责验签。northcinder 采用了一个对钱包非常友好的设计私钥永远不出你的电脑。首次运行时软件在配置目录自动生成 ed25519 密钥对见packages/checkout/src/mandate/keystore.ts私钥文件权限被强制设为0600即仅本人可读写因为它直接关系到花钱授权代码中私钥被封装成sign()闭包任何其他模块都无法直接读取私钥内容生成的公钥Base64 编码会随 Mandate 一起提供给商家侧或验证方用于核对签名真伪。也就是说签名是你本机私钥的专属动作全世界只有你的电脑能签出这份授权。规范化签名载荷一份顺序固定的防篡改清单密码学签名有个关键细节签名是针对一串字节算出来的如果同一份内容换一种排列顺序签名就会对不上。为了避免同一个授权被重排字段后仍然有效的漏洞northcinder 在packages/checkout/src/mandate/canonical.ts中把待签内容规范化为固定字段顺序的 JSON 数组先是版本化域名标记northcinder.purchase-mandate.v1用于区分不同版本的协议再按固定顺序排列授权 ID、意图描述、offerId、商家、金额上限、币种、签发时间、过期时间、nonce签名时签的就是这份标准清单验证时也按同一份清单重新计算。任何字段的增删改都会导致签名校验失败——这就是防篡改的第一道闸门。代码还保留了旧版本域名如brier、thenagain、emptor前缀保证升级前签发的历史授权仍可验证。一次性nonce如何拦截重放攻击文件锁定的原子魔法签名能证明这份授权确实是你签的却无法证明这份授权只被用一次。想象一下如果一份有效授权可以反复提交攻击者截获后就能不断用它下单。这就是重放攻击Replay Attack而拦截它的武器就是一次性 nonce。每个 Mandate 都携带一个随机生成的 nonce至少 16 位随机字符并且遵循一条铁律一个 nonce 只能被消费一次。packages/checkout/src/mandate/nonce-ledger.ts实现了一次性台账其核心机制非常巧妙用 SHA-256 把 nonce 哈希成一个固定文件名在台账.markers/目录下以O_EXCL原子方式创建对应的标记文件权限0600文件创建成功 这个 nonce 被我烧掉了文件已存在EEXIST 这个 nonce 已经被用过由于O_EXCL创建在文件系统层面是原子操作哪怕多个进程同时提交同一个 nonce也只有一个能赢。这样的设计保证了跨进程、跨实例都无法重复使用同一份授权同时所有消费记录会以 JSONL 追加写入审计日志随时可查。验证全流程签名校验、金额比对与nonce消费的先后次序签名购买授权最终要经过packages/checkout/src/mandate/verify.ts这道硬门禁所有检查按严格顺序执行检查项作用结构校验授权格式是否符合协议 Schema密钥信任签名公钥是否来自你本机的受信任密钥签名校验ed25519 签名是否与规范化载荷匹配时效校验是否仍在 15 分钟有效期内商品匹配offerId 与当前商品是否一致商家匹配merchantId 与当前商家是否一致金额上限含运费总价是否超出签名的 maxAmountnonce 消费最后一步才烧掉一次性 nonce注意这里的顺序大有讲究所有校验通过后才在最后一步消费 nonce。这样设计意味着——如果验证失败nonce 不会被浪费授权还可以修正后重试而一旦验证成功nonce 立即被消费绝不给二次使用留机会。任何异常都会返回结构化的拒绝原因如signature_invalid、expired、amount_exceeded、replayed并且永远不会抛出未处理的异常。15分钟有效期金额上限给钱包上的双重保险即使签名真实无误你的钱包还需要两道保险丝⏰ 时效保险Mandate 默认签发后 15 分钟过期见issue.ts中的DEFAULT_MANDATE_TTL_MS。过期即作废即使授权文件被窃取攻击者也无法隔夜使用。 金额保险签名时的maxAmount是包含运费的硬性消费上限。下单时如果实际总价含税、含运费超过了授权上限验证直接拒绝。哪怕商家结算时偷偷加价也过不了这道坎。这两道保险配合签名与 nonce构成了签名防伪造、nonce 防重放、时效防拖延、上限防超支的四重防线。一次Mandate只允许一次购买编排器的Fail-safe设计最后packages/checkout/src/orchestrator.ts把整个结账流程编排成三步顺序不可颠倒选择结算通道按商品能力匹配合适的结算方式纯函数不产生副作用通过 Mandate 硬门禁只有验证通过的授权才能进入下一步执行结算调用结算通道完成购买并把 Mandate 全文与凭证写入订单记录供日后审计这里有一个宁可保守不可冒进的设计哲学一份 Mandate 只对应一次购买尝试。如果验证通过后结算通道执行失败nonce 不会退还——你需要重新发起一次授权。这种失败安全fail-safe策略杜绝了一次授权被反复尝试直至成功的双花风险宁可在便利性上让步也绝不在资金安全上妥协。想亲手体验源码位置与快速上手如果你也想看看这份授权机制的真实模样可以按下面方式获取项目并阅读核心源码git clone https://gitcode.com/gh_mirrors/no/northcinder关键代码路径如下建议按顺序阅读可以完整串起签名购买授权的全链路packages/checkout/src/mandate/keystore.ts—— ed25519 密钥对生成与保管packages/checkout/src/mandate/issue.ts—— 授权签发与金额计算packages/checkout/src/mandate/canonical.ts—— 规范化签名载荷packages/checkout/src/mandate/verify.ts—— 验证硬门禁packages/checkout/src/mandate/nonce-ledger.ts—— 一次性 nonce 台账packages/checkout/src/orchestrator.ts—— 结账编排器docs/TRUST.md—— 项目的信任模型说明写在最后总结一下northcinder 的签名购买授权机制可以浓缩成一句话用 ed25519 证明是你签的用一次性 nonce 证明只用一次用 15 分钟有效期证明没有过期用金额上限证明没有超支。四者环环相扣、层层设防让购物Agent替你下单这件事第一次变得像银行卡签名一样——可追溯、可验证、不可抵赖。如果你是注重支付安全的网购用户或开发者这套设计值得仔细品味。【免费下载链接】northcinderBuyer-run, ad-neutral shopping-agent MCP software with deterministic ranking, signed purchase mandates, and a local audit trail.项目地址: https://gitcode.com/gh_mirrors/no/northcinder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考