ETC不停车收费密钥管理：OBU密钥注入与路侧设备密钥分发

ETC不停车收费密钥管理里最容易被低估的环节，不是算法选型，而是"密钥怎么安全地到达它该到的那台设备里"。一次省界站拆除后的系统改造中，施工方把一批新装的 RSU 直接接进收费网络，设备上电后能读卡、能写交易，却始终无法通过清算对账------原因是 PSAM 卡里的分散密钥还是出厂默认值，没人知道那批卡在哪个环节、由谁写入。这类问题的共同点是：功能跑通了，密钥链路是断的。

全文结构：

先定边界：三层密钥体系与四类密钥
第一步：产线侧 OBU 密钥注入
第二步：发行激活与"一设备一密"
第三步：路侧设备 RSU 密钥分发
第四步：与上级密钥体系对接
第五步：运营期轮换与应急
第六步：退役与销毁
常见问题（FAQ）
三种落地路线对比
落地验收清单
相关阅读

一、先定边界：三层密钥体系与四类密钥

1.1 三层：全国清分级、省级、路段与发行方

收费公路的密钥体系通常是分层的，理解层级才能理解"哪一层该由谁管"：

层级	承载对象	主要职责	典型载体
全国清分级	根密钥、跨省清分结算	跨省互认、争议裁决	密码机、离线密钥分量
省级	省级主控密钥	省内发行、跨路段互认	密码机 + 密钥管理系统
路段／发行方	设备级分散密钥	OBU、RSU、PSAM 的日常使用	ESAM 芯片、PSAM 卡

层级之间靠分散而不是靠"复制"：上级密钥与设备专属标识做分散运算，得到该设备的专属密钥。这样上级不需要知道每台设备的密钥是什么，却能推导出它------这是整条链路可以被规模化管理的根本原因。

1.2 四类密钥，各管一段

主控密钥（MK）：处在层级顶端，负责派生下级密钥。它一旦外泄，影响面是整层，因此必须在密码机内生成、存储与使用。
分散密钥（DK）：由主控密钥按设备标识分散得到，一设备一密，写入 OBU 的 ESAM 或 RSU 的 PSAM 卡。
认证密钥：用于车道设备与车载单元之间的双向身份鉴别，以及交易报文的完整性校验。
会话密钥：单次或短周期有效，用于交易的加密传输，用后即废。

1.3 "一设备一密"为什么是硬要求

如果一批 OBU 共用同一把分散密钥，那么其中任何一台被拆解分析，等于这一批全部失守------而且无法通过"吊销单台"来止损，只能整批更换。分散机制的价值就在于把影响面收敛到单台：一台出问题，只废一台。

工程上要保证这一点，靠的是注入环节的可审计：每一次注入都记录设备序列号、注入的密钥版本号、操作人、时间与工位，且这些记录不可被操作者本人修改。没有这一条，"一设备一密"只是设计文档里的一句话。

二、ETC不停车收费密钥管理第一步：产线侧 OBU 密钥注入

2.1 注入之前，先准备好三样东西

设备清单：OBU 的 ESAM 序列号区间、批次号、对应车型与发行方，必须与生产工单一致。
密钥版本：明确本次使用的分散密钥版本号，旧版本何时停用、新版本何时启用。
工位权限：产线工位只能发起注入请求，不能自行生成密钥；密钥生成在密码机内完成。

2.2 ETC不停车收费密钥管理中的注入流程

bash 复制代码

# 1) 产线工位向密钥管理系统申请本次批次的注入任务（占位示例）
curl -sS -X POST "$KSP_API/v1/injection/tasks" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "batch_id": "OBU-2026-0911",
        "key_version": "v7",
        "device_count": 5000,
        "esam_range": ["A1000001", "A1005000"],
        "operator": "line-03"
      }'

# 2) 工位按任务逐台请求分散密钥；密钥由密码机内部分散，只返回密文信封
curl -sS -X POST "$KSP_API/v1/injection/derive" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"task_id":"$TASK_ID","esam_sn":"A1000001"}'

# 3) 写入 ESAM 后回执验签，未完成回执的设备不计入"已注入"
curl -sS -X POST "$KSP_API/v1/injection/ack" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"task_id":"$TASK_ID","esam_sn":"A1000001","result":"ok","signature":"$SIG"}'

关键点在第二步：工位拿到的不是明文密钥，而是被保护密钥加密的信封。明文只在 ESAM 芯片内部解封并写入安全区，产线的工控机、网络、日志里都不出现明文。这样即使产线网络被监听，也拿不到可用的密钥材料。

2.3 三个高频坑

坑一：回执丢了，台账对不上。 注入成功但回执未上报，系统里这台设备仍是"未注入"。处理办法是以回执为准做对账，差异设备单独隔离复测，不允许人工改台账。

坑二：版本混用。 新旧版本密钥并行期间，同一批次里混进两种版本，上线后部分车道认证失败。处理办法是批次与版本强绑定，一批只允许一个版本。

坑三：工位权限过大。 工位账号能直接导出密钥，等于把整条产线变成风险点。处理办法是工位只申请、不生成、不导出，导出动作单独授权并双人复核。

三、第二步：发行激活与"一设备一密"

OBU 在产线完成注入后处于未激活状态，发行环节把它与具体车辆、账户绑定：

车辆绑定：写入车牌、车型、用户类型，并与分散密钥一起做完整性保护；
激活指令：由发行方密钥签发，OBU 验签通过后才进入可用状态；
激活留痕：激活时间、网点、操作员进入审计台账，与生产台账可互查。

这里要注意的是激活与注入的解耦：注入在产线完成，激活在发行网点完成，两段各自留痕，才能回答"这台设备的密钥是谁写进去的、又是谁启用它的"。

四、第三步：路侧设备 RSU 密钥分发

4.1 现场分发的两种形态

RSU 与 PSAM 卡的密钥分发有两条路：

形态	做法	优点	局限
离线分发	密钥分量由专人携带至现场，双人现场合成并写入	不依赖现场网络，安全边界清晰	人力成本高，大规模建设期吃力
在线分发	现场设备接入后通过安全通道远程请求	效率高，适合批量开通	依赖现场网络与设备身份预置

实际项目里通常混用：建设期用在线批量开通，关键站点与应急补点用离线分发。

4.2 分发流程

bash 复制代码

# 1) RSU 上电后向密钥管理系统注册，提交设备证书（占位示例）
curl -sS -X POST "$CKMS_API/v1/devices/register" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"device_type":"rsu","sn":"RSU-4601-0037","cert":"$DEV_CERT"}'

# 2) 申请 PSAM 分散密钥，返回信封密文
curl -sS -X POST "$CKMS_API/v1/keys/wrap" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"device_sn":"RSU-4601-0037","key_version":"v7","usage":"psam_auth"}'

# 3) 写入 PSAM 后上报状态；未上报的站点在清算侧自动标记为不可用
curl -sS -X POST "$CKMS_API/v1/devices/status" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"device_sn":"RSU-4601-0037","psam_state":"provisioned"}'

4.3 最容易出错的地方

设备身份没有预置。 在线分发的前提是设备出厂时已有可信身份（设备证书或预置密钥）。如果现场设备没有身份，在线分发就退化成"谁申请给谁"，与文章开头那个案例是同一类问题。

PSAM 卡插拔无管控。 PSAM 卡可以物理拔插，如果卡座与设备没有绑定关系，卡被换到别的设备上也能工作。处理办法是把 PSAM 卡序列号与 RSU 设备号在密钥侧绑定，换卡即失效。

应急补点绕过流程。 抢工期时现场直接把默认值投入使用，事后忘了换。处理办法是让"未注入密钥的设备在清算侧不可用"------用业务规则兜住流程漏洞，比反复强调流程有效。

五、第四步：与上级密钥体系对接

路段侧的密钥管理系统要向上级（省级／全国清分级）对接，主要做三件事：

接收上级密钥分量：分量以密文形式交付，在密码机内合成，合成过程留痕且需多人参与；
上报本级设备台账：已注入设备的序列号、密钥版本、状态，按周期上报；
同步吊销列表：上级下发的吊销列表要在规定时间内生效，并回执确认。

这里的技术重点是分量合成：任何单一人员都不应掌握完整密钥。常见做法是密钥分量分由不同人保管，合成在密码机内完成，合成过程的每一步都有见证人与影像记录。

安当的 KSP 密钥管理系统在这一层承担密钥的集中编排：三级密钥体系（根密钥在密码机内、工作密钥由根密钥保护、会话密钥动态生成），配合 10 余种角色与三权分立，把"谁能生成、谁能分发、谁能审计"拆开；对外通过 Restful API 与 Java／Go／C SDK 对接路段侧的发行系统与车道软件。面向多地部署的场景，安当的 CKMS 提供跨云的密钥管理与信封加密能力，便于省级与路段侧分域部署时保持一致策略。

六、第五步：运营期轮换与应急

6.1 轮换的三条原则

按版本而不是按批次：引入密钥版本号，新旧版本并行一段时间，设备侧逐步迁移；
先灰度后全网：先在单个收费站验证，确认交易成功率与对账无异常后再推全网；
随时可回退：旧版本在并行期内保持可用，一旦新版本异常立即回退。

6.2 应急场景

场景	处置	关键动作
单台设备密钥疑似外泄	吊销该设备，重新注入	吊销列表同步到清算侧
批次密钥疑似受影响	整批降级为"待复核"，限制交易额度	交易侧限流 + 复核通过解除
上级密钥更新	接收新分量、合成新版本	双人以上参与、全程留痕
密码机故障	切备用机，恢复备份密钥	备份密钥同样在密码机内，不以明文落地

6.3 与标准的对齐

ETC 相关的通信与设备要求见 GB／T 20851 系列《电子收费专用短程通信》，其中第 1 部分物理层、第 2 部分数据链路层、第 3 部分应用层、第 4 部分设备应用、第 5 部分物理层主要参数测试方法，均为 2019 年 5 月 10 日发布、2019 年 12 月 1 日实施；停车场等扩展场景可参考 GB／T 35070 系列。密码应用侧要求对应 GB／T 39786-2021，测评方法对应 GB／T 43206-2023。

七、第六步：退役与销毁

退役环节常被忽略，但它是密钥全生命周期闭环的最后一环：

设备下线登记：OBU 注销、RSU 拆除，登记原因与时间；
密钥状态变更：从"在用"改为"已停用"，保留解密历史交易所需的元数据；
物理销毁：PSAM 卡与 ESAM 芯片按流程物理破坏，销毁过程留痕；
台账对账：注销数量、销毁数量、库存数量三方对账一致。

需要保留历史交易验签能力时，不要销毁密钥本身，而是把它置为"仅验签"状态------既能验证历史交易，又不能再用于签发新交易。

八、常见问题（FAQ）

Q：ETC不停车收费密钥管理第一步应该做什么？

A：第一步是划定密钥层级与版本，而不是先买设备。先明确全国清分级、省级、路段与发行方三层各自的职责边界，确定主控密钥与分散密钥的版本策略，再据此设计注入与分发流程，否则设备到货后往往要返工。

Q：ETC不停车收费密钥管理中 OBU 和 RSU 的密钥怎么区分管理？

A：OBU 的密钥写入 ESAM 芯片，随车流动，重点是批次与版本可追溯；RSU 的密钥写入 PSAM 卡，固定在站点，重点是与设备绑定、防换卡。两者共用同一套分散体系，但台账维度不同：OBU 按批次管，RSU 按站点管。

Q：ETC不停车收费密钥管理多久轮换一次密钥合适？

A：分散密钥建议按年度评估、按事件启动轮换；会话密钥按交易或按小时自动生成。真正需要立即轮换的是发现单台设备密钥疑似外泄或上级密钥更新时，此时应走应急流程而不是等周期。

九、三种落地路线对比

路线	做法	优点	局限	适用
设备厂商自带密钥工具	用厂商工具写入，台账在厂商侧	上手快、成本低	台账不可控、跨厂商难统一	小规模试点
路段自建密钥管理系统	自建 KMS + 密码机	台账自主、策略统一	需自行维护与对接上级	单一路段运营方
分层统一编排（省级---路段一体）	统一密钥管理平台 + 密码机 + 跨云密钥管理	上下级策略一致、可审计可回退	建设周期 2-3 个月	省级改造、多路段并存

十、落地验收清单

#	验收项	判定标准	检查方式
1	层级划分	三层职责与边界有书面定义并被执行	文档 + 密钥台账抽查
2	一设备一密	同批次设备分散密钥互不相同	抽样比对密钥密文
3	注入可审计	每次注入记录 SN、版本、操作人、工位，且不可改	台账导出 + 权限核查
4	明文不出模块	产线网络、工控机、日志中无明文密钥	抓包 + 日志检索
5	回执对账	注入数与回执数一致，差异设备已隔离	对账报表
6	RSU 设备身份	出厂预置可信身份，无身份设备无法申请密钥	现场注册测试
7	PSAM 绑定	卡序列号与设备号绑定，换卡即失效	换卡测试
8	版本策略	一批一版本，并行期可回退	版本台账 + 回退演练
9	分量合成	需多人参与，全程留痕	合成记录与影像
10	吊销时效	吊销列表在规定时间内生效并回执	吊销演练计时
11	退役销毁	注销、停用、销毁三方对账一致	库存与台账比对
12	密码应用合规	对照 GB／T 39786-2021 与 GB／T 43206-2023 备齐证据	条款对照表

十一、相关阅读

文章作者：安当加密技术负责人