02 · 信任与身份模型

当前系统不是单一证书链，而是把传输身份、服务授权、Token 所有权和密钥托管分成多层。

信任面总览

层	证明什么	当前实现位置
Facade 请求签名	哪个银行 API client 发起请求、请求内容未被篡改	cbdc-facade/internal/auth/
gRPC mTLS	服务到服务连接方持有受信证书	BizHub/FSC server middleware 与 TLS 配置
BizHub 方法角色	mTLS 身份是否有权调用具体 runtime/management 方法	mtls.ServerIdentityMiddleware + RequireRoles
FSC 节点身份	View 会话中的节点身份与对端 resolver	cbdc-token/pkg/nodesdk/、各 Token main.go
Token owner 签名	钱包所有者授权花费	Panurus wallet/signer 与 SubmitSignatureView
Auditor/Endorser 签名	审计通过、网络背书	pkg/token/views/audit*、Panurus Fabric-X endorsement
Fabric MSP / TLS	网络成员与传输信任	Fabric-X 配置、CA 生成物

这些层不可互换：Facade 验签通过不等于 Token owner 已签名；mTLS 连接成功也不等于该方法已获角色授权。

Facade 的银行请求身份

Facade 除公开方法外要求：

• x-key-id
• x-timestamp
• x-signature

签名算法为 Ed25519。Facade 从 BizHub ClientAuthDataService 刷新客户端公钥与状态到内存 cache，再验证规范化请求。未知 key 与错误签名使用相同失败响应，避免形成 key-existence oracle。

BizHub 的 mTLS 与角色授权

BizHub 先从客户端证书提取服务身份，再按 RPC 方法执行 RequireRoles。runtime 与 management 服务面可通过 mode 分开启动；即使 TCP/mTLS 已建立，调用方仍可能因角色不足被拒绝。

Central 通过 management RPC 管理业务数据。Facade 主要消费面向运行时的身份和机构信息。两者不应通过直接共享 cbdc_biz 绕过服务授权。

FSC P2P 证书

Token 节点的 P2P transport 当前为 WebSocket + TLS。配置包含 serverRootCAs 与 clientRootCAs；证书生成脚本为节点证书加入：

• Extended Key Usage：clientAuth,serverAuth
• DNS SAN：节点域名、短名与 localhost

同一节点可同时作为 FSC client 和 server。开发控制器从宿主机启动节点时使用 localhost 地址，是为了让实际拨号 host 与证书 SAN 匹配。

Wallet Node 的统一节点证书还用于访问 BizHub 的 mTLS 身份，因此轮换时要同时验证 P2P 与 BizHub 两条链路。

Node Registry 不替代证书校验

BizHub Node Registry 分发可连接地址，但不成为新的信任根：

• Auditor、Endorser 注册自身地址；
• Issuer、Wallet Node 拉取快照并更新 resolver；
• TLS root CA、证书身份和 SAN 仍决定连接是否可信。

因此 registry 中有地址并不保证连接成功，也不代表该节点自动获得业务角色。

Token 身份与公共参数

Issuer、Auditor 等 Token 身份被公共参数引用。四个 FSC Token 节点必须使用一致的 TMS 与 pp 文件。

配置集	driver	pp
dev/config/token/*	zkatdlog	zkatdlognoghv1_pp.json
cbdc-token/conf/*	fabtoken	fabtoken1_pp.json

X.509 与 Idemix 的实际使用取决于钱包类型、driver 和公共参数，不能再用“当前系统固定 fabtoken，所以 Idemix 未启用”概括整个仓库。

私钥托管

节点配置支持通过 PKCS#11 接入 Sign-KMS，使签名在 KMS/HSM 边界内完成。实际部署仍需分别确认：

• 加载的 PKCS#11 library；
• KMS endpoint 与 namespace/access token；
• key label / key ID；
• session pool 与超时；
• 软件密钥回退是否被允许。

“配置了 KMS”不自动证明所有业务私钥都未落盘；要按每个 signer 的 BCCSP/wallet 配置核对。

开发环境证书生成

当前入口是 ./dev/cbdc-dev，证书和运行配置落在 dev/run/。相关实现位于：

• dev/internal/controller/
• dev/scripts/gen_crypto.sh
• dev/config/network/
• dev/config/token/

旧 scripts/start-kms-system.sh 不是当前开发基线，不应再作为命名空间、证书或网络启动的权威说明。

轮换与撤销检查

证书或密钥轮换时至少验证：

1. Facade auth cache 是否拿到新银行公钥；
2. BizHub 是否信任新 mTLS 证书及其角色；
3. FSC resolver 地址与新证书 SAN 是否匹配；
4. pp 内 Issuer/Auditor 身份是否需要重新生成与部署；
5. KMS key ID/namespace 是否与配置一致；
6. 旧证书或 access token 是否已撤销/禁用。

相关文档

• 部署拓扑
• 交易跨包全链路
• 配置参考
• Facade
• BizHub