业务故事站
P5 Swift 已实现 PoC

安全体系：国密全链路

Swift 的国密全链路不是设计稿，而是可以真跑的代码：GAC 用 SM2 签名 + SM3 摘要 + SM4-GCM 加密把报文封成信封，HCC 验签解密；在链路中篡改任意字节，系统都会拒绝。本主题 3 个故事带你实际走一遍签名、加密、篡改拒绝与证书哈希链。

安全工程师 财务负责人 合规官 国密 篡改拒绝 端到端加密 共 3 个故事

能 / 不能速览

✅ 已实现
  • SM2 密钥对生成、签名/验签（GB/T 32918.2），SM3 摘要/HMAC，SM4-GCM 认证加密
  • 端到端加密信封：SM2 密钥协商派生 SM4 会话密钥，Seal 加密 / Open 验签解密
  • 篡改拒绝：翻转密文字节 → HCC 验签解密拒绝（SM4-GCM / SM2 / SM3 三重兜底）
  • 仿真 PKI：SM2 根 CA 签发 GAC-01 / HCC-01 / SSPM-01 证书，根公钥验签
  • 审计哈希链（SM3 链式）与报文签名/验签接口
⛔ 当前做不了
  • TLCP 传输层协议 / 双证书通道未实现
  • 真实 CA 体系（子 CA、CRL 吊销、密钥轮换、HSM 存储）未实现
  • 星上 FPGA 硬件加速、防流量分析、抗量子密码仅在设计
  • 证书为仿真载荷格式、密钥为内存级（重启重建）

适用角色

本主题面向三类角色：

  • 安全工程师 / 密码工程师：在「篡改拒绝演示」验证端到端加密对链路篡改的拦截能力。
  • 财务负责人：在「一键演示」查看自己发起的支付报文如何被签名、加密、送达、解密。
  • 合规官：用报文签名/验签接口与审计事件，向监管证明报文来源与完整性。

能力速览（已实现）

国密算法底座

platform/crypto 封装 SM3（摘要/HMAC）、SM2（密钥/签名验签）、SM4-GCM（认证加密），底层 emmansun/gmsm，全平台可复用。

端到端加密信封

GAC 用 HCC 公钥协商 SM4 会话密钥加密报文，附 SM3 哈希与 SM2 签名；HCC 验签解密，会话密钥不随信封传输。

篡改拒绝冒烟

/security/tamper-test：合法报文解密成功、篡改报文被拒绝，并证明链路帧 CRC 无法识别"篡改后重算"的恶意替换。

仿真 PKI

SM2 根 CA 自签根证书（10 年），为 GAC/HCC/SSPM 签发证书（2 年），根公钥验签证书有效性。

报文签名 / 验签

/messages/sign 对报文体 SM3 摘要 + SM2 签名；/messages/verify 公钥验签，返回 valid 布尔。

审计哈希链

SM3(prev‖data) 链式摘要：中间事件被篡改，重放校验整条链断裂即检出。

调整指南（怎么调整）

  • 调整加密范围：GAC 客户端 SetEncrRecipient 设置 HCC 公钥即启用全链路加密信封；传空串回退明文路径（兼容测试）。
  • 调整证书有效期：IssueCert 的 days 参数控制实体证书有效期；生产化建议叠加轮换与吊销（CRL）。
  • 调整演示场景：/demo/run 入参 amount_cents / svc_type / dbtr_acct / cdtr_acct / rmt_inf 可改变签名、加密、风控路径。
  • 调整篡改冒烟：tamper-test 翻转的是密文末字节；改翻其他位置或签名，Open 会在验签/完整性环节同样拒绝。
  • 调整签名职责：签名密钥与加密会话分离（SM2 身份密钥长期、SM4 会话密钥每次协商），生产化应入 HSM。

做得好的场景

这套安全体系真实可跑，最擅长"在物理透明的链路载荷上守住报文安全"：
  • 篡改即拒绝：改一个字节，SM4-GCM 认证或 SM2 验签或 SM3 完整性必有一层拒绝。
  • 防抵赖可验：每笔报文有 SM2 签名，谁签的、改没改过，验签接口一查便知。
  • 国密一步到位：SM2/SM3/SM4-GCM 作为底座能力从第一天实现，不做"先国际后改造"返工。
  • 审计可防篡改：SM3 哈希链让审计事件不可悄悄修改。

限制与不足

以下是明确的边界，先知道再读故事：
  • 仿真域：PKI 为仿真简化证书（单层根 CA、无子 CA/CRL），密钥为内存级，重启重建。
  • TLCP 未做：传输层密码协议（GB/T 38636）与双证书通道是规划项。
  • 硬件加速未做：星上 FPGA 加解密、防流量分析、抗量子密码仅在设计。
  • 哈希链已接全局审计：audit 服务对每条事件先 linkHash（取上一条 Hash 作 PrevHash）再落库，VerifyChain 可检出篡改；但完整性校验无公开 REST 端点。

场景故事

故事 1 蓝箭给 EuroSat 付 5000 万发射费：GAC 签名加密、HCC 验签解密，全程密文
场景：端到端加密 角色：财务负责人 链路：demo/run 第 2/3/5 步
背景
2026 年 8 月 10 日，蓝箭航天财务负责人陈芸要给 EuroSat 运营付一笔 5000 万欧元的发射服务费（LAUNCH）。这笔钱走 Swift 的仿真星地链路，她最担心报文在路上被监听、被篡改。她在 HCC 管控台点了「运行合规演示」，真实代码把她的报文从头到尾保护了一遍。
传统做法对比
传统银行电汇靠封闭专线（如 SWIFT FIN 网），加密依赖线路封闭，覆盖不了发射场、测控船这些地面金融网到不了的地方，改造费用还高。Swift 走开放的卫星链路（仿真），信号可被截获，所以必须在应用层做端到端加密 + 签名，靠算法而不是线路来保安全。
角色
GAC 客户端（蓝箭侧发起，SM2 签名 + SM4-GCM 加密）；HCC 结算中心（收帧后验签解密再进结算链路）。
操作步骤
  1. GAC 生成 pacs.008 XML（蓝箭→EuroSat，EUR 5000 万分 = 5000000000）
  2. 国密签名：security.SignPayload 对报文体做 SM3 摘要 + SM2 签名
  3. 端到端加密：SM2 密钥协商派生 SM4 会话密钥，SM4-GCM 加密成信封（security.Seal）
  4. 打包链路帧经星地网关发送（含一次断链恢复补发）
  5. HCC 收帧：Open 验签 → 解密 → 明文 SM3 比对 → 解析 pacs.008 进后续合规/风控/结算
系统响应
真实返回（/demo/run）：
// 第 2 步签名
{"signature":"30450221...","hash":"d4c9...","record_id":"sign-..."}
// 第 3 步加密信封
{"ciphertext_len":1234,"nonce_hex":"...","hash_hex":"d4c9...","pub_key_hex":"04..."}
// 第 5 步 HCC 解密验签通过
{"msg_id":"GAC-CN-BJ-...","amount":"50000000.00","ccy":"EUR",
 "dbtr_acct":"LS-CN-0001-BJ","cdtr_acct":"LS-FR-0003-PAR","ue_tr":"..."}
会话密钥不随信封传输，链路载荷全程为密文信封。
结果洞察
报文在"卫星"上全程密文：SM4 会话密钥由双方私钥/公钥各自算出同一把（发送私钥×接收公钥 == 接收私钥×发送公钥），第三方拿不到；SM2 签名保证来源真实、SM3 完整性保证内容没被改。10 步演示中第 2/3/5 步全部 success。
调整建议
会话密钥每次交互独立协商，无需预分发，适合大规模终端；生产化方向是证书带有效期自动轮换 + 吊销列表（CRL），签名私钥入 HSM 防导出。
动手试一试
启动服务后浏览器访问 http://127.0.0.1:18084，登录 admin / admin1 → Swift → HCC 管控台 →「风控/合规」→「运行合规演示」，看第 2 步签名、第 3 步加密、第 5 步解密验签的明细数据。
限制提示
仿真域：星地链路为 sspm 仿真模型（延迟/丢包/断链），非真实卫星；证书为仿真载荷、密钥内存级；TLCP、HSM、CRL 未实现。金额字段为定点分 int64，页面展示为元。
故事 2 链路篡改冒烟：CRC 防"原样修改"，端到端国密信封才防得住"恶意替换"
场景：篡改拒绝 角色：安全工程师 端点：POST /security/tamper-test
背景
安全工程师李工负责验收 Swift 的篡改防线。他先怀疑：链路帧不是有 CRC 校验吗，篡改会被发现吧？他在 HCC 管控台点了「篡改拒绝演示」——真实代码告诉他，CRC 和端到端国密信封能拦的东西不一样。
传统做法对比
链路层 CRC 只能发现"帧载荷被原样改动"，但攻击者可以篡改后重算 CRC、重新打包帧，链路层校验照样通过——CRC 不是防篡改手段，只是防传输误码。要防恶意篡改，必须靠应用层认证加密（SM4-GCM 带认证标签）+ SM2 验签 + SM3 完整性比对。
角色
安全工程师（验收）；GAC-01 / HCC-01 证书对（PKI 预签，demo 组装时注入）；HCC 接收侧（Open 验签解密）。
操作步骤
  1. 构造合法报文，GAC-01 私钥签名 + 加密成信封（security.Seal）
  2. 正查控制组：HCC-01 私钥 Open 解密验签 → 应成功
  3. 模拟链路篡改：翻转密文末字节，按篡改后载荷重算帧 CRC、重新打包
  4. HCC 再 Open 解密验签 → 应拒绝
系统响应
真实返回：
{"control":{"opened":true,"amount_str":"50000000.00"},
 "tampered":{"rejected":true,"frame_crc_ok":true,
   "error":"security: 解密信封失败: security: 发送方签名无效（来源不可信或密文被篡改）"},
 "conclusion":"篡改报文已被拒绝（SM4-GCM 认证失败 / SM2 验签失败 / SM3 完整性校验兜底）"}
关键：frame_crc_ok=true——链路层 CRC 通过了，但端到端国密信封仍然拒绝。
结果洞察
帧 CRC 通过不代表安全：它校验的是"是否原样"，挡不住"篡改后重算"的恶意替换。真正兜底的是应用层端到端国密信封——密文字节一变，SM4-GCM 认证标签或 SM3 完整性立刻失败，HCC 直接拒绝。这解释了为什么 Swift 必须做应用层加密而不仅仅靠链路层。
调整建议
篡改冒烟可扩展为"篡改签名、篡改哈希、篡改密文头部"三个子用例，分别验证 Open 的三条拒绝路径；生产化方向再叠加防重放（时间戳 + 序号窗口）与防流量分析。
动手试一试
HCC 管控台「风控/合规」标签页点「篡改拒绝演示」，对比左右两张卡片：左"合法报文解密成功"，右"篡改报文已被拒绝 + 帧 CRC 通过"。演示后审计事件出现 TAMPER_TEST 记录。
限制提示
仿真域：篡改模拟为代码内翻转密文字节，非真实攻击流量；演示用演示 PKI 密钥对；TLCP 通道、防重放序号窗口、防流量分析未实现。
故事 3 合规官要"验来源、验完整、审计不可改"：仿真 PKI 证书 + 报文验签 + 哈希链
场景：证书与审计 角色：合规官 端点：/messages/sign、/messages/verify
背景
合规官高小姐要向监管说明"每一笔报文都能验来源、验完整性，审计记录不可篡改"。Swift 用三件真实可跑的武器回答她：SM2 根 CA 签发的仿真证书（谁是谁）、报文签名/验签接口（改没改过）、审计哈希链（全局审计流水已接链，记录赖不掉、改不了）。
传统做法对比
传统靠纸质凭证 + 事后人工核对，一笔大额交易要 2~3 天，出了纠纷追不到"谁签的、改没改"。Swift 用 SM2 数字签名（不可否认）实时固化每一笔报文，用 SM3 哈希链让审计事件一动就断链，都是即时、自动、可复现的。
角色
合规官（验签与审计核验）；报文实验室操作员（生成报文、签名、验签）；PKI（根 CA 预签 GAC-01/HCC-01/SSPM-01 三张证书）。
操作步骤
  1. 报文实验室生成 pacs.008（或用 /messages/generate）
  2. POST /messages/sign 传 content + priv_key_hex → 返回 signature/hash/record_id
  3. POST /messages/verify 传 content + pub_key_hex + signature → valid:true
  4. 查看审计事件与篡改演示留痕（/admin/audit），确认 HashChain 链式摘要校验逻辑
系统响应
真实返回：
// POST /messages/sign
{"signature":"3045022100...","hash":"d4c9...","record_id":"sign-150405-8f2a1b3c"}
// POST /messages/verify
{"valid":true}
证书由根 CA 签发（Subject=GAC-01/HCC-01/SSPM-01，Issuer=LS-ROOT-CA），根公钥验签证书有效性；全局审计哈希链（platform/audit，SHA-256 底）对每条事件算 Hash(prev‖data) 回填 PrevHash/Hash，中间事件被改整条链 VerifyChain 即失败。
结果洞察
验签通过 = 报文由对应 SM2 私钥持有者签发且未被篡改（防抵赖 + 防篡改）；证书验签确认"签发者是真的"；哈希链让审计记录不可悄悄修改。三件事都是代码级的真实能力，可直接向监管演示。
调整建议
生产化方向：证书加有效期自动轮换与吊销（CRL）、签名私钥入 HSM 不可导出、审计哈希链接入全局审计流水并定期出链尾摘要备案。当前演示私钥在内存中，重启重建。
动手试一试
Swift「报文实验室」生成报文 → 点"国密签名"→ 点"验签"看 valid:true；再跑一次「篡改拒绝演示」，到「风控/合规」标签页下方审计事件表里找 TAMPER_TEST 记录（含 control_opened / tamper_rejected / frame_crc_ok 详情）。
限制提示
仿真域：PKI 为单层根 CA 简化证书（无子 CA、无 CRL、无证书链），证书载荷为仿真格式；密钥内存级；哈希链已接全局审计流水但完整性校验无公开端点；TLCP 未实现。

常见问题

为什么链路层有 CRC 还要做应用层加密？

CRC 只校验帧载荷"是否原样"，攻击者篡改后重算 CRC 就能骗过链路层（tamper-test 里 frame_crc_ok=true）。端到端国密信封（SM4-GCM 认证 + SM2 验签 + SM3 完整性）才是防恶意篡改的最后防线。

SM4 会话密钥是怎么共享的？

SM2 密钥协商：发送方用"自己的私钥 × 接收方公钥"、接收方用"自己的私钥 × 发送方公钥"得到同一个共享点，SM3 派生 16 字节会话密钥。会话密钥不随信封传输，第三方算不出。

证书体系是真实 CA 吗？

不是。PoC 是仿真简化 PKI：SM2 根 CA 自签根证书 + 签发实体证书，证书载荷为仿真格式，密钥内存级。子 CA、CRL 吊销、密钥轮换、HSM 存储均为规划中。

国密算法是真实实现吗？

是。SM3/SM2/SM4-GCM 封装在 platform/crypto，底层是成熟库 emmansun/gmsm，有单测与真实签名/加密/解密验证，非占位桩。

TLCP 双证书什么时候有？

当前未实现（规划中）。现在走的是算法级端到端加密信封；TLCP（GB/T 38636 传输层密码协议）与信创适配属于后续阶段，见 XINCHUANG.md P5 行。

主题小结

一句话：Swift 安全体系 = 国密全链路（SM2 签名 / SM3 摘要 / SM4-GCM 加密）真实可跑 + 仿真 PKI 证书 + 篡改拒绝冒烟 + 审计哈希链。已实现边界清楚：算法与信封是硬能力，TLCP、真实 CA/HSM、星上加速仍是规划项——读故事时记得这是仿真域，卫星链路与密钥管理都还不是生产形态。