地铁车辆段信号车间,凌晨两点的作业窗口。工班长把维护 UKey 插进 ATS 维护工作站,输入口令,屏幕弹出一个账号下拉框——这个账号是五家厂商驻场工程师共用的。旁边那台给车载 VOBC 灌升级包的电脑,U 盘拷进去直接刷,没人校验签名。信号是 SIL4 的安全系统,可管着它的人,认证还停在"共用口令 + 口口相传"。
这是不少线路信号机房的常态,直到密评专家把报告拍在桌上:设备和计算层面,身份鉴别不满足;应用和数据层面,软件完整性没有密码保护,限期六个月整改。
这次整改,答案通常落在一对组合上:安当 ASP 统一身份认证平台管"谁能进",KSP 密钥管理系统管"钥匙在哪"。后面所有章节,都是这对组合在信号系统里的具体展开。
这篇把"信号系统的身份认证与访问控制"讲透:从 CBTC 整体结构讲起,说到车载 ATP 为什么需要身份、轨旁怎么认证、密钥存在哪、升级包怎么签,最后给一套能直接对着验收的方法。
目录
- 01 CBTC 这张图:五子系统、三张网、SIL4
- 02 车载 ATP 的"身份"问题
- 03 轨旁这扇门:维护网、ATS 工作站与运维认证
- 04 密钥管住才叫真安全
- 05 升级包签名与配置防篡改
- 06 一个整改案例(已脱敏)
- 07 三种认证方式怎么选
- 08 验收清单:每条怎么证明做对了
- 09 往后五年信号安全往哪走
01 CBTC 这张图:五子系统、三张网、SIL4
先把 CBTC 的整体结构画出来,后文所有问题都落在这张图上。
CBTC(Communication Based Train Control)由五大子系统构成:
- ATS(列车自动监控):调度员的工作台,时刻表、进路、列车位置都汇到这里;
- ATP(列车自动防护):安全核心,超速防护、追踪间隔、冒进防护,防护逻辑不落地就直接紧急制动;
- ATO(列车自动运行):站间自动运行、停车对标;
- CBI / ZC(计算机联锁 / 区域控制器):联锁进路安全,并给列车计算移动授权 MA;
- DCS(数据通信系统):车地之间的无线通道。
按作用划分,信号系统内部通常分成三张网:承载安全控制的列车控制网、供运营调度的信息管理网、以及检修用的维护监测网。安全网和管理网、维护网之间靠安全网关隔开——这是第一个"边界"。设备内部,信号系统按 SIL4(安全完整性等级四级)设计,车载和轨旁设备双系冗余,单系故障不降级。
城市轨道交通信号系统通用技术条件(GB/T 12758-2023)、网络安全等级保护 2.0(GB/T 22239-2019)三级,以及密码应用基本要求(GB/T 39786-2021)里,针对信号系统的"认证与访问控制"大体落在四个层面:
| 层面 | 对应场景 |
|---|---|
| 网络和通信 | 车地无线通信、安全网与管理网互联、远程维护通道 |
| 设备和计算 | ATS 工作站、维护终端、车载调试口的身份鉴别 |
| 应用和数据 | 升级包完整性、配置文件防篡改、操作日志防抵赖 |
| 密钥管理 | 车载/轨旁密钥的生成、分发、存储、轮换 |
把密码组件放上去,整体拓扑是这样的:
后面的章节就按这个坐标展开。
02 车载 ATP 的"身份"问题
车载 ATP 和轨旁 ZC 之间是一条实时闭环:列车把自己的位置、速度报告上去,ZC 算好移动授权 MA 发下来,一个周期 100~300ms,量大、实时、延敏感。
这条闭环上的"身份",至少出现在四处:
- 列车报自己身份——“我是 0305 车”,ZC 凭什么相信?这是设备身份,靠车地共享密钥;
- ZC 下发移动授权——列车凭什么相信这条 MA 是合法 ZC 算的,不是伪基站伪造的?这是车地双向认证的另一半,最容易漏;
- 软件写进 VOBC——升级包要写进车载控制器 BOOT 区,凭什么证明这是厂商签过字的版本?这是软件完整性;
- 人接 VOBC 调试口——维护人员拿笔记本接车载调试口,凭什么证明这人有权限?这是人的身份。
双向认证这块,不少线路第一轮密评就栽在这:只做了"车认地",没做"地认车",或者两边会话密钥各自为政、从不轮换。标准的做法是:列车与 ZC 各持工作密钥,同一条线路、同一设备的密钥从 KSP 按规范派生,车地通信加密用 SM4 会话密钥,带版本号、按周期更新,旧版本归档、新版本上线。根密钥躺在硬件密码机里,工作密钥下到车载安全芯片这一段由密钥管理系统统一走,中间不出现任何明文交换——密钥泄漏的时间窗被压到可控范围。
一套这么跑下来的会话密钥模型,可以对照 GB/T 39786-2021 的"网络和通信安全"层面逐条核,密评专家挑不出毛病。
03 轨旁这扇门:维护网、ATS 工作站与运维认证
轨旁的认证问题比车载更常见,也更难管,因为人多人杂:信号维护员、ATS 值守、厂商驻场、项目调试,高峰期一个维护网里同时挂着几十个人。
现场最典型的三类问题:
- 共享账号:一个账号五个人用,离职了不销号;
- 默认口令:厂商交付时留下的口令没改,设备手册网上能搜到;
- U 盘拷升级包:维护网和互联网物理隔离,厂商工程师就靠 U 盘带软件,病毒和越权文件跟着一起进来。
密评的"设备和计算"层面,对管理终端和运维终端的要求很明确:身份鉴别要采用双因素,一个因素是口令,另一个必须是物理凭证。对信号维护这种场景,物理凭证基本就是 UKEY——国密 SM2/SM3/SM4 的智能密码钥匙,私钥固化在芯片里导不出来,人走钥走,即时吊销。
落地时的关键,是把"几把钥匙"变成"一套认证体系"。光发 UKey 不够,还要有个身份源把所有终端的登录统一管起来。安当 ASP 在这个位置干的活是:把 ATS 调度工作站、信号维护终端、车载调试口的登录全部收编,身份源对接 AD / 现有组织架构,人员离职、转岗、借调,账号跟着人事流程自动动,而不是靠人工删。
ATS 调度工作站走 OIDC 授权码流程,把登录交给 ASP:
# 1) 调度员浏览器跳转到 ASP 认证页 GET https://idp.local:8001/authorize ?response_type=code &client_id=ats-ws &redirect_uri=https://ats-ws.local/callback &state=nonce-20260831 # 2) 插 UKEY 双因素认证通过,ASP 回跳带着授权码 # callback?code=xxxx&state=nonce-20260831 # 3) 后端用授权码换 token POST https://idp.local:8001/token Content-Type: application/x-www-form-urlencoded grant_type=authorization_code&code=xxxx &client_id=ats-ws&client_secret=******维护终端这类老系统不好改的,用 RADIUS 对接或者表单代填。UKEY 那侧,签名挑战-应答是推荐方式:服务端下发随机数,钥匙用私钥签名,服务端用公钥验签。UKEY 的 RESTful 服务跑在终端本地 2300 端口,流程大致是这样(字段以接口文档 2.0.1 为准):
importrequests UK="http://127.0.0.1:2300/api/"defcall(interface,params=None):r=requests.post(UK,json={"interface":interface,"params":paramsor{}},timeout=5)returnr.json()# 1. 列出本机钥匙 -> 2. 校验 PIN -> 3. 对挑战随机数签名dev=call("GetDeviceList")["data"][0]call("VerifyUserPIN",{"pin":"******","key_id":dev["key_id"]})challenge="5f6a3c81..."# 服务端下发的随机数sig=call("GetECCSignData",{"key_id":dev["key_id"],"data":challenge,})["data"]# 服务端拿到公钥做 SM2 验签,通过才允许登录 ATS 工作站核心一点:私钥永远不离开钥匙本身,PIN 只负责"钥匙是本人在用"。几把钥匙、几十把钥匙的时候看不出差别,一条线路全线几百把钥匙,全靠身份源台账撑着。
04 密钥管住才叫真安全
认证解决"谁在操作",密钥解决"数据怎么保护"。信号系统里的密钥比想象中多:车地通信的会话密钥、车载/轨旁设备的工作密钥、升级包签名的签名密钥、证书体系的 CA 密钥。散在厂商手里各自保管,是最常见也最要命的问题——你问三家中标厂商密钥在哪、多久轮换、谁有导出权限,能收到三份互相打架的回答。
集中管理按三级密钥体系来拆,安当 KSP 就是这么组织的:
- 根密钥 KEK:只存在安当 HSM 硬件密码机里,永不明文导出,是整条信任链的根;
- 工作密钥 DEK:被 KEK 加密保护,按设备、按线路派生,一钥一用;
- 会话密钥:车地通信每次会话协商,用完即销毁。
车载和轨旁的工作密钥分开派生,同一条线的不同列车也用不同密钥,任何一把钥泄漏,炸开的范围可控,不会一路通到整条线的密钥体系。
密钥轮换要能落地而不是写在制度里:到期自动轮换、版本递增、旧版归档、轮换记录可审计。KSP 的 RESTful 接口响应在百毫秒级,对信号控制网是透明的——它管密钥,不碰 100ms 的实时控制回路。密钥操作日志逐条带数字签名防篡改,使用者、管理员、审计员三权分立,谁也别想偷偷导出一把钥。
铁路的 CTC(调度集中系统)在电务端遇到的是同一件事:CTC 中心机房的密码资源、电务检修终端、调度员工作站,密钥同样要集中管,别以为换了个系统就能绕开这一套。
05 升级包签名与配置防篡改
这是"应用和数据"层面的重灾区,也是整改里最好量化的部分。
车载 VOBC 和轨旁 ZC 的软件升级包,过去靠人工核对版本号、看 U 盘里的文件名。改名伪造的成本几乎为零。正确的做法是:厂商在 CI 流水线里用签名密钥对升级包做 SM2 签名,现场写入前验签,验签失败直接拒绝写入。证书与签名密钥由安当 KSP 内置的 CA 组件签发和托管,签名私钥存在 HSM 里,厂商自己的 CI 拿不到明文私钥,只能通过签名服务接口调用——"签名的资格"也被收编进密码体系了。
Go 实现直接用 tjfoc/gmsm 的包级接口,它按 GB/T 32918 自动把用户标识 ZA 拼进摘要,不用自己处理:
packagemainimport("encoding/hex""fmt""github.com/tjfoc/gmsm/sm2")// 厂商 CI 侧:对升级包做 SM2 签名(内部按 GB/T 32918 计算 ZA‖M 摘要)funcsignPackage(priv*sm2.PrivateKey,pkg[]byte)string{sig,err:=sm2.Sign(priv,pkg,[]byte("1234567812345678"))iferr!=nil{panic(err)}returnhex.EncodeToString(sig)}// 现场:验签,篡改一个字节即失败funcverifyUpdate(pub*sm2.PublicKey,pkg[]byte,sigHexstring)error{sig,err:=hex.DecodeString(sigHex)iferr!=nil{returnerr}if!sm2.Verify(pub,pkg,[]byte("1234567812345678"),sig){returnfmt.Errorf("upgrade package signature invalid")}returnnil}签名方和验签方必须用同一个用户标识,生产环境统一约定为 GB/T 32918 默认的1234567812345678。这段代码可以拿任意升级包本地跑一遍:哪怕只改一个字节,SM2 验签必然失败——这就是"可当场证明"的整改成果。
配置文件同理:线路电子地图、ATP 参数、ATS 时刻表,这类文件的完整性也要求密码保护。防篡改可以靠签名,也可以靠关键日志的数字签名:操作日志、密钥操作日志逐条签名,事后想抹掉一条记录改不出来,直接回应密评对"日志防抵赖、防篡改"的要求。
06 一个整改案例(已脱敏)
下面这条是近两年多条线路密评整改实践的整合,已做脱敏处理,别对号入座——但每个问题,你大概率在某条线路上见过。
背景:某已运营多年的地铁线路,2025 年密码应用安全性评估(密评)没有通过。问题高度集中在设备和计算、应用和数据两个层面:ATS 维护工作站与信号车间终端全部使用共享口令,无第二因素;车载 VOBC 与轨旁 ZC 的软件升级包上线不校验签名,靠人工核对;车载和轨旁密钥由各厂商分散保管,无集中管理台账,轮换靠口头约定。密评结论是多个"不符合",限期六个月整改。
实施分三步走:
- 终端认证:部署安当 ASP + 安当 UKEY,信号维护人员和厂商驻场工程师一人一证一钥,强制双因素登录 ATS 工作站与维护终端;身份源对接人事组织架构,离职、转岗即时销户,共享账号全部拆除;
- 密钥集中:KSP 对接 HSM 建立三级密钥体系,根密钥硬件化;车载与轨旁工作密钥按线路、按设备派生,一钥一用,到期自动轮换,密钥操作全量审计;
- 软件签名:车载 VOBC 软件与轨旁 ZC 配置包纳入 CA 签名,升级前 SM2 验签,验签失败拒绝写入;操作日志逐条签名防篡改。
结果:整改项全部闭环,密评复测通过。共享账号清零,身份台账和真实人员一一对应;一次厂商越权版本下发在测试环节被验签逻辑直接拦下,没有进到正线设备;密钥操作审计从"查无记录"变成"逐条可回溯"。
信号系统再特殊,把密评"不符合"项逐个改成"符合",走的就是这一套。数据口径来自整改汇报,最终验收以密评机构出具的报告为准。
07 三种认证方式怎么选
轨旁终端的认证方式,现场主要就三种,配上选择逻辑:
| 认证方式 | 安全性 | 成本 | 落地难度 | 适用场景 |
|---|---|---|---|---|
| 静态口令 | 低 | 最低 | 零 | 不再建议,仅作应急兜底 |
| 动态口令 OTP | 中 | 中 | 低 | 外部厂商临时接入、低频操作 |
| UKEY 双因素 | 高 | 中高 | 中 | 信号维护、ATS 调度核心终端 |
| UKEY + CA 证书 | 最高 | 高 | 较高 | 车载/轨旁关键操作、远程维护通道 |
一句话选型:核心终端上双因素,重要操作加证书,临时接入给动态口令,静态口令从制度上清掉。别在"认证强度"和"操作效率"之间反复纠结——维护窗口就几分钟,一把 UKey 插入、输 PIN、完事,多花的时间按秒计,换回来的是账号可审计。
08 验收清单:每条怎么证明做对了
信号系统密评整改到底做没做对,不用听谁讲,照着这几条当场验:
- 终端认证:抽查任意 10 台 ATS 工作站与维护终端,确认无共享账号、无默认口令,双因素强制生效;身份台账与在岗人员一一对应,离职账号已注销。
- 密钥管理:确认根密钥在 HSM 内、导出权限为 0;KSP 密钥操作日志逐条带数字签名,轮换记录可查时间、操作人、版本号。
- 升级包签名:拿任意升级包跑一遍 SM2 验签;手动改一个字节,验签必须失败——这一步 5 分钟就能演示。
- 车地通信:抓包确认会话密钥加密生效、密钥按周期更新,并确认加解密没有拖累列车控制周期。
- 审计与防抵赖:操作日志无法被修改或删除(签名防篡改),关键操作可追溯到人、钥匙、时间、终端四元组。
09 往后五年信号安全往哪走
几个趋势值得提前布局:
- 车地通信从 WLAN 向 LTE-M 演进,铁路侧则走向 5G-R,加密能力要从专用通道往标准化方向走,低时延和高安全要同时给;
- 一证一钥全面替代共享账号,零信任的思路会进到信号系统,"人-钥匙-终端-操作"全链路可审计成为标配;
- 密码服务集约化,多线路、多车站的密钥管理收敛到市级统一密码服务平台,复用 KSP/HSM 资源,降低每线建设成本;
- 后量子密码(PQC)预研,信号设备生命周期长(动辄十几年),现在上线的密码体系要留好算法迁移的口子;
- 密评常态化,密码应用从"补课整改"变成系统设计的内生约束,而不是验收前的最后一课。
铁路 CTC 前面已经提过,是同一套东西——调度员工作站认证、CTC 中心机房密码资源、电务检修终端管理,只是把 ATS 换成 CTC,把地铁场景换成铁路场景。轨交和铁路的信号安全,边界不同,底下的密码逻辑是通的。
这篇是「轨道交通信号安全」系列第一篇。下一篇《地铁 AFC 票卡密钥管理:从票卡密钥注入到清分系统数据安全全链路》会讲透票卡这条线——同样是密钥,票卡和信号是两种完全不同的玩法。
信号系统整改的清单就这几张表,收藏下来对表用。系列持续更新,关注不迷路。
文章作者:安当加密-焱垚
