地铁车辆段信号车间,凌晨两点的作业窗口。工班长把维护 UKey 插进 ATS 维护工作站,输入口令,屏幕弹出一个账号下拉框——这个账号是五家厂商驻场工程师共用的。旁边那台给车载 VOBC 灌升级包的电脑,U 盘拷进去直接刷,没人校验签名。信号是 SIL4 的安全系统,可管着它的人,认证还停在共用口令 口口相传。这是不少线路信号机房的常态,直到密评专家把报告拍在桌上:设备和计算层面,身份鉴别不满足;应用和数据层面,软件完整性没有密码保护,限期六个月整改。这次整改,答案通常落在一对组合上:安当 ASP 统一身份认证平台管谁能进,KSP 密钥管理系统管钥匙在哪。后面所有章节,都是这对组合在信号系统里的具体展开。这篇把信号系统的身份认证与访问控制讲透:从 CBTC 整体结构讲起,说到车载 ATP 为什么需要身份、轨旁怎么认证、密钥存在哪、升级包怎么签,最后给一套能直接对着验收的方法。目录01 CBTC 这张图:五子系统、三张网、SIL402 车载 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 工作站、维护终端、车载调试口的身份鉴别应用和数据升级包完整性、配置文件防篡改、操作日志防抵赖密钥管理车载/轨旁密钥的生成、分发、存储、轮换把密码组件放上去,整体拓扑是这样的:轨旁车载SM4 会话加密双向认证工作密钥下发车载 VOBCATP / ATO车载安全芯片存工作密钥区域控制器 ZCATS 调度工作站维护终端ASP统一身份认证UKEYKSP密钥管理系统HSM信任根KSP 内置 CA 组件升级包签名后面的章节就按这个坐标展开。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_typecode client_idats-ws redirect_urihttps://ats-ws.local/callback statenonce-20260831 # 2) 插 UKEY 双因素认证通过,ASP 回跳带着授权码 # callback?codexxxxstatenonce-20260831 # 3) 后端用授权码换 token POST https://idp.local:8001/token Content-Type: application/x-www-form-urlencoded grant_typeauthorization_codecodexxxx client_idats-wsclient_secret******维护终端这类老系统不好改的,用 RADIUS 对接或者表单代填。UKEY 那侧,签名挑战-应答是推荐方式:服务端下发随机数,钥匙用私钥签名,服务端用公钥验签。UKEY 的 RESTful 服务跑在终端本地 2300 端口,流程大致是这样(字段以接口文档 2.0.1 为准):importrequests UKhttp://127.0.0.1:2300/api/defcall(interface,paramsNone):rrequests.post(UK,json{interface:interface,params:paramsor{}},timeout5)returnr.json()# 1. 列出本机钥匙 - 2. 校验 PIN - 3. 对挑战随机数签名devcall(GetDeviceList)[data][0]call(VerifyUserPIN,{pin:******,key_id:dev[key_id]})challenge5f6a3c81...# 服务端下发的随机数sigcall(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/hexfmtgithub.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 票卡密钥管理:从票卡密钥注入到清分系统数据安全全链路》会讲透票卡这条线——同样是密钥,票卡和信号是两种完全不同的玩法。信号系统整改的清单就这几张表,收藏下来对表用。系列持续更新,关注不迷路。文章作者:安当加密-焱垚