换一块燃气表,接线、通气、激活,现场十分钟;但真正把一块表接入企业的不是管道,是密钥。旧表号不吊销,新表随便发号就入网,那么远程调价、远程关阀、用气量上报这些城市生命线末梢动作,就都建立在一层纸糊的信任上。智能燃气表早已不是一块抄表工具:它装上物联网远传模块后,既能上报用气量、管网压力这类感知数据,又能接收平台下发的远程调价、阀门控制、固件升级指令——它既是城市生命线的感知末梢,又是一台可被远程寻址并执行动作的设备。城市基础设施生命线安全工程把供气作为其中一环,各地在把燃气监测(管网压力、阀井浓度、户内报警、智能表计)纳入物联感知智能预警闭环处置;而《关键信息基础设施安全保护条例》(国务院令第 745 号,2021 年 9 月 1 日起施行)把能源行业的基础网络与系统纳入关基保护视野——供气企业被认定为关基后,网络与系统的密码应用要能自证身份真实、数据可信。本文不是全景综述,而是沿一条链拆到底:一把主密钥 → 按表号分散出一表一密 → 出厂写进安全芯片 → 上线挑战-应答 → 数据帧防伪 → 换表吊销。交通线前几篇的主角是离线票卡、有部省体系的车载单元;公共事业线前两篇的主角是操作员(人的 UKEY、人的账号)。这一篇,主角换成海量、固定位置、低功耗、还会被更换的燃气表——物的设备身份。01 | 先立场景:燃气表为什么要证明我是我表还是那块表,但它的安全边界在变:燃气表安全边界的三次前移 ① 机械/IC卡表:离线单机,攻击者要接触表才能动手 前移 - 抄表的人(内部人) ② 远传表(抄表为主):数据上传,单向报数 前移 - 中间能听/能改信道的人(链路) ③ 物联网表(可寻址执行):平台能下发调价/阀控/升级指令 前移 - 任何能伪造平台或伪造表的人(网络) 到第 ③ 阶段,问题不再是表准不准,而是: 「这块正在上报数据的表,是不是我那块真表?」 「这条让我调价/关阀的指令,是不是真平台发的?」表计从计量设备变成身份与指令都要校验的接入设备,威胁跟着变。业内对燃气物联网安全风险的描述,长期指向几个固定模式:攻击/风险发生方式后果拆表抄密钥密钥若用软件存在 MCU/Flash,拆表、读芯片、逆向固件即可拿走一把密钥被复制,伪表横行信道绕过认证只认表发的帧,不校验来源,中间层转发/注入命令直接执行非法指令甚至开关阀门重放录一段合法指令(如关阀)反复发送业务被重复执行、状态失真伪表/设备冒用复制硬件与固件,冒充真表上报用气量/监测数据失真,预警失真一型一密同型号共一把密钥,泄一把 全型号沦陷破损半径从一个设备扩散到一批落到合规上,表计这类感知节点有明确的密码要求:等保 2.0 对物联网系统的扩展要求里,感知节点设备接入网络应进行身份鉴别、具备防伪能力;GB/T 39786-2021 密评要求应用系统的身份鉴别、数据真实性要用密码技术实现。落到表计上就是一句话:**设备必须拥有一把只有它自己和授权平台知道的密钥,并靠这把密钥证明身份、保住数据。**这就是本文整条链的出发点。02 | 密钥从哪来:主密钥锁根,表密钥按表号分散先回答最底层的问题:几十万块表,密钥怎么给?三个候选方案,一对比就看出问题:方案做法为什么不行一把总密钥所有表共用一把泄一把 全城表计可仿冒,单点崩塌一型一密同型号一把破损半径 一个型号批次,仍太大一表一密(分散)每块表一把,主密钥按表号分散派生泄一块只伤一块,可单表吊销“一表一密听起来是给每块表灌一把随机密钥”——那意味着产线要管理几十万个明文密钥,出厂要登记、换表要同步,泄露面巨大。更聪明的做法是就地重建:平台只保管一把主密钥,任何一块表的表密钥 以主密钥为密钥、以该表表号为输入算出来的一个值。要哪块表,现场现算,不需要存全城密钥库。表计场景下密钥层级的落法 根密钥(HSM 内,永不导出) ........... 全平台可信之根 │ 只做一件事:保护下面的主密钥 ▼ 主密钥 MK(KSP 管理) ........... 可派生、可版本化、可审计 │ 派生是纯函数:同 MK 同表号 同 key ├─ 表号 A ── key_A(烧进 A 表的 SE) ├─ 表号 B ── key_B(烧进 B 表的 SE) └─ 表号 C ── key_C(烧进 C 表的 SE) 表号是公开的(印在表上、贴在表箱里),key 却推不出来 安全性全部押在主密钥保密上 - 主密钥必须锁硬件、少露面这套设计背后的三个为什么,才是机制的内核:为什么平台能重建任意表的密钥却还是安全的?因为表密钥的机密性不靠藏密钥,而靠藏主密钥。主密钥锁在 HSM(服务器密码机)里、永不明文导出,派生请求走受控接口并全程审计——主密钥不泄露,派生再多把表密钥都只伤单表。为什么按表号派生,而不是把表号也做成密钥的一部分写死?表号是天然唯一的业务标识,派生用它,等于把密钥和这块表绑定:换表 换表号 重新派生一把新密钥,旧的那把自然作废,吊销逻辑变得极简单。为什么把管密钥从用密钥里拆出来?产线、抄表平台、预警平台都在用表密钥,但它们不该都碰主密钥。密钥管理层(KSP)把派生、签发、吊销、审计收在一个点,使用者只拿到各自那一把,权限最小化——这正是等保/密评里密钥管理要单独立项的机制原因。随之而来的一个张力要正视:主密钥是这套体系的超级信任点——它一旦泄露,一表一密里的一表就名存实亡,全城表计都能被仿。所以对主密钥的做法高度一致:分层保护、分权使用、全程留痕。根密钥只做保护下级密钥一件事、永不明文出硬件;能触发派生的角色被区分开(产线按批次领、平台按业务领、应急恢复单独授权),每次派生记下谁、为哪张表、什么时候;密钥带版本,轮换时旧版本可作废。这套把管钥的权力本身也管起来的思路,和金融领域按主密钥分散因子管理交易密钥是同族——主密钥不出硬件,业务方拿到的永远是派生后的工作密钥,平台能重建任意表密钥不是漏洞,而是换表补发、坏表恢复时的运维必需,关键是把这份特权收口、留痕、可审计。验证点:让平台用同一把主密钥、对两张不同表号做派生,看结果是否整段不同(见下文 04 脚本第①步输出)。03 | 出厂那一秒:一表一密是怎么进表的密钥派生出来了,怎么安全地放进表?这一步叫产线安全发行(也叫密钥注入/写号),它决定了伪表能不能仿出密钥。出厂/换表发行链 KSP/HSM(主密钥 锁根) │ ① 受控领取该表的派生密钥(谁领的、领哪张表,全程记账) ▼ 注入/写号设备(与 KSP 证书互认的可信客户端) │ ② 经安全通道把该表 key 下发 ▼ 表计 SE 安全芯片:key 写入不可读区 │ ③ 本地自检:用 key 完成一次挑战(密钥全程不出芯片) ▼ 出厂登记:表号 | 密钥版本 | 批次 - 同步回平台密钥台账关键在表的存储介质。同样是把密钥放进表,两种放法安全等级完全不同:存储方式密钥放在哪被拆表后软加密单片机程序/普通 Flash,软件算 SM4读 Flash、逆向固件即可抄走密钥 → 伪表可复制安全芯片(SE)专用安全芯片不可读区,密码运算在芯片内完成芯片防拆(电压/频率/温度/光照监测),暴力读取触发错误锁定/自毁,密钥抄不走表端放 SE、密钥不可读,是设备身份能成立的物理前提:**表的外壳、固件、PCB 都能被复制,唯独 SE 里那把密钥复制不出来——伪表可以长得和真表一模一样,却在认证这一步答不上来。**这也是为什么行业把 SE 方案普遍定义为接入层身份认证 安全启动 安全 OTA 安全参数管理的底座,并让安全芯片通过商用密码产品检测、内置 SM2/SM3/SM4。安当侧在这条链上承担的,是主密钥与派生签发这一层:KSP(密钥管理系统)做主密钥管理、按表号派生、密钥版本与吊销台账;HSM 做根密钥底座;产线注入工位作为 KSP 的可信客户端领取密钥,全过程留审计。表计 SE 的具体选型与芯片资质属于表厂/整机侧,这里不展开——平台侧把密钥从哪来、给谁、何时作废管住,产线侧把密钥进 SE、不出芯片做扎实,两端合起来,一表一密才真正成立。验证点:出厂抽检时,对刚注入的表发起导出密钥命令,SE 应拒绝(命令报错),而平台密钥台账里能查到这张表号、密钥版本、注入时间——密钥进得去、出不来、有记录。04 | 上线那一下:SM4 挑战-应答的完整链路表装到用户家、首次联网,平台怎么知道来者是真表?机制上就是一次挑战-应答:平台发一个一次性随机挑战,表端 SE 用自己那把密钥对它算一个校验值(MAC)回传;平台用同一把表密钥重算一遍,一致才放行。为什么用对称 SM4 而不是 SM2 签名——表计海量、低功耗、成本敏感,对称 MAC 运算轻、足够证明持有该表密钥;而不可抵赖、跨机构取证价值高的关键指令,可再叠加公钥签名(见 05)。人用签名、物用轻量 MAC,两类机制各安其位。下面这份代码可整段复制运行(gmssl 实现国密 SM4),把 ①一表一密 → ⑨换表吊销整条链跑一遍:# -*- coding: utf-8 -*-# 智能燃气表设备身份演示:一表一密 上线挑战认证 防重放/防克隆 帧防伪 换表吊销# 主密钥/挑战取固定值仅便于复现;真实环境每次真随机、用完即弃。fromgmsslimportsm4 MKbytes.fromhex(3f2a1c9e5b7d4f6a8c0e2d4b6a9c1e3f)# 16B 主密钥,锁在 HSM/KSPdefsm4_block(key:bytes,blk:bytes)-bytes:原始单块 SM4-ECB:blk 恰 16 字节(padding_modeNone 不做 PKCS7 填充)csm4.CryptSM4(modesm4.SM4_ENCRYPT,padding_modeNone)c.set_key(key,sm4.SM4_ENCRYPT)returnc.crypt_ecb(blk)def_pkcs7(msg:bytes)-bytes:pad16-(len(msg)%16)returnmsgbytes([pad])*paddef_chain(key:bytes,msg:bytes)-bytes:CBC 链式处理:逐块 异或-加密,输出最后一块(整段输入都影响结果)prebytes(16)data_pkcs7(msg)foriinrange(0,len(data),16):blkbytes(a^bfora,binzip(data[i:i16],pre))presm4_block(key,blk)returnpredefderive_meter_key(master:bytes,serial:str)-str:一表一密:主密钥按表号分散出该表唯一表密钥(演示等价物)。return_chain(master,serial.encode()).hex()defcbc_mac(key_hex:str,msg:bytes)-str:SM4-CBC-MAC(教学示意):表密钥对消息做来源完整性校验。 真实产品按规范用标准 MAC(CMAC/SM4-GCM);原理一致:改一比特,末块全变。return_chain(bytes.fromhex(key_hex),msg).hex()# ---- ① 一表一密:同一把主密钥,两张表号分散出两把互不相同的表密钥 ----print([① 一表一密] KSP/HSM 锁主密钥 MK(永不明文出硬件);密钥按表号就地重建)old_serialGAS-A2026-008877# 在装旧表(示例表号)new_serialGAS-B2026-012345# 换表后的新表old_keyderive_meter_key(MK,old_serial)new_keyderive_meter_key(MK,new_serial)print( 旧表号,old_serial,- 表密钥 ,old_key)print( 新表号,new_serial,- 表密钥 ,new_key)print( 两把密钥整段不同 - 泄一把不泄全部,可单表吊销)# ---- ② 上线认证:平台下发一次性挑战,表端 SE 用表密钥应答 MAC ----challengebytes.fromhex(3c2a9d1e8f4b6a7c0d5e9f1a2b3c4d5e)# 演示固定;真实时间戳随机print([② 挑战下发] 平台为本次上线生成一次性挑战 ,challenge.hex())tagcbc_mac(old_key,challenge)print([③ SE 应答] 表内 SE 用表密钥对挑战算 MAC ,tag,(表密钥不出芯片))usedset()print([④ 平台校验] 平台用同把派生表密钥重建 MAC)okcbc_mac(old_key,challenge)tag used.add(challenge.hex())print( 重算一致 - 放行 ,ok, (证明来者持有该表密钥真表))# ---- ③ 防重放:截获的同一份(挑战,MAC)原样再发一次 ----print([⑤ 防重放] 攻击者把 ②③ 截获报文原样重放)mac_okcbc_mac(old_key,challenge)tag replay_deniedmac_okand(challenge.hex()inused)print( MAC 重算仍相等 ,mac_ok,; 但挑战台账已命中 - 重放被拒 ,replay_denied)# ---- ④ 防克隆:抄走表硬件与固件,抄不走 SE 里的表密钥 ----print([⑥ 防克隆] 攻击者复制表硬件固件(同表号),用自己猜的密钥应答)fakecbc_mac(0*32,challenge)print( 伪表 MAC ,fake)print( 与真表 MAC 不一致 - 克隆被拒 ,fake!tag)# ---- ⑤ 数据帧防伪:上行抄表帧同样挂 MAC,改一比特即露馅 ----frame(读数:000123|瞬时流量:1.8|表号:old_serial).encode()tag_fcbc_mac(old_key,frame)forgedcbc_mac(old_key,frame[:-1]b9)# 攻击者把末位读数 7 改成 9print([⑦ 帧防伪] 上行抄表帧 MAC ,tag_f)print( 篡改末位读数后 MAC 不一致 - 篡改被拒 ,forged!tag_f)# ---- ⑥ 换表吊销:旧表密钥作废,新表重新签发入网 ----print([⑧ 换表吊销] 2026-09-03 更换表计/停用:平台将旧表号置为 revoked 并出审计)revoked{old_serial}ch_newbytes.fromhex(9d1e8f4b6a7c0d5e3f2a1c9e8b4d6f0a)# 旧表再次上线,平台下发新挑战try_old(cbc_mac(old_key,ch_new)cbc_mac(old_key,ch_new))and(old_serialinrevoked)try_new(cbc_mac(new_key,ch_new)cbc_mac(new_key,ch_new))and(new_serialnotinrevoked)print( 旧表密钥数学上仍可验 MAC,但状态已 revoked - 旧表被拒 ,try_old)print( 新表未进吊销清单 - 新表放行 ,try_new)print([⑨ 审计留痕] 2026-09-03 09:47:21 | 表号,new_serial,| 换表上线 | 挑战认证通过 | KSP 台账)把代码从头读一遍,关键在三个点:一表一密是纯函数派生:derive_meter_key用同一把MK、对不同的表号串做链式 SM4,表号一个字节不同,整把密钥就不同(①输出的两把 key 整段不一样)。平台不需要存全城密钥库,要哪块表现算;密钥的机密性全部转移到MK上——这就是MK必须锁在 HSM/KSP 的原因。应答必须用密钥、不出密钥:cbc_mac的_chain是 CBC 链式——每块密文参与下一块异或,最后一块受整段输入影响。表端 SE 只把这个 MAC 值传出来,old_key本身永远不出芯片。⑥ 里伪表用猜的密钥(0*32)算 MAC,和真表对不上,认证立刻被拒。防重放靠一次性,不靠密码学:⑤ 的关键不是 MAC 对不上,而是 MAC 明明对得上、却因为挑战用过而被台账拦下——同一个 challenge 只放行一次。密码学只能证明这把密钥在场,防重放必须靠业务侧把 challenge 做成一次性、用过即焚。这正是表计安全里最容易漏、也最廉价的一层防线。诚实地说,这段代码是教学等价物,离能直接商用的实现还隔着几层,别照抄去接产线:演示里简化了什么真实实现会怎么做派生用 SM4 链式示意按采用的密钥管理规范/标准 KDF 实现分散,输入含密钥版本、随机因子MAC 用手工 CBC-MAC用标准 SM4-CMAC / SM4-GCM 等带认证的模式challenge 用固定值真随机 时间戳,防重放落到帧序号/时间窗 台账长期表密钥直接用认证通过后协商一次性会话密钥,批量数据改用会话密钥只有一把主密钥生产/测试/灾备环境主密钥隔离,轮换按版本推进这张表的每一行,都是一个可以在方案评审里追问对方的问题——表计厂商说有加密,到底做到了哪一行,一问便知。脚本(存为d33_meter_auth.py)运行输出应为:[① 一表一密] KSP/HSM 锁主密钥 MK(永不明文出硬件);密钥按表号就地重建 旧表号 GAS-A2026-008877 - 表密钥 004bc1bff99f760dc78491dbde287aa0 新表号 GAS-B2026-012345 - 表密钥 540e347f1f5ab8496f8411ff853c788f 两把密钥整段不同 - 泄一把不泄全部,可单表吊销 [② 挑战下发] 平台为本次上线生成一次性挑战 3c2a9d1e8f4b6a7c0d5e9f1a2b3c4d5e [③ SE 应答] 表内 SE 用表密钥对挑战算 MAC 239cf41655c4cf6d8fbecd99c4e6a97e (表密钥不出芯片) [④ 平台校验] 平台用同把派生表密钥重建 MAC 重算一致 - 放行 True (证明来者持有该表密钥真表) [⑤ 防重放] 攻击者把 ②③ 截获报文原样重放 MAC 重算仍相等 True ; 但挑战台账已命中 - 重放被拒 True [⑥ 防克隆] 攻击者复制表硬件固件(同表号),用自己猜的密钥应答 伪表 MAC d3837b0c39c7fde26fd339b91a7093e4 与真表 MAC 不一致 - 克隆被拒 True [⑦ 帧防伪] 上行抄表帧 MAC fcbc4a6a1e8d28ba30be690828227ca4 篡改末位读数后 MAC 不一致 - 篡改被拒 True [⑧ 换表吊销] 2026-09-03 更换表计/停用:平台将旧表号置为 revoked 并出审计 旧表密钥数学上仍可验 MAC,但状态已 revoked - 旧表被拒 True 新表未进吊销清单 - 新表放行 True [⑨ 审计留痕] 2026-09-03 09:47:21 | 表号 GAS-B2026-012345 | 换表上线 | 挑战认证通过 | KSP 台账# 六个关键断言全部命中 一表一密成立 / 放行 / 防重放 / 防克隆 / 防篡改 / 换表吊销生效python3 d33_meter_auth.py|grep-E放行 True|重放被拒 True|克隆被拒 True|篡改被拒 True|旧表被拒 True|新表放行 True输出里的六个 True是这条链每个环节的验证点:漏掉任何一个,都说明对应环节的机制没走通——这也是把演示脚本直接当产线/平台联调自测脚本用的检查项。05 | 数据与指令:一表一密还能护住什么先看表计到平台的数据怎么走——拓扑决定了密钥放在哪。真实燃气物联网抄表大体两种:拓扑一:表直连平台(NB-IoT/4G) 拓扑二:表经集中器转发(本地组网) 表 ────────────────── 平台 表 x N ──┐ 一表一密:表 SE - 平台 两端 各表 ────┼── 集中器 ── 平台 表即网元,点对点,04 链路直接成立 (集中器也要有身份和密钥: 否则伪集中器可把一溜表的帧都翻译走)直连拓扑里,04 的链路直接成立;有集中器/采集终端的拓扑里,集中器是转发中继,不是透明管道——它自己也要有设备身份与密钥、与平台双向认证,否则中间插一台伪集中器,就能把一溜表的帧都翻译走。判断方案时先问一句:你们是哪种拓扑,集中器认不认身份?同一把表密钥,不只是上线认证那一下用。表计和平台之间的日常流量,按重要度套用不同强度的密码保护:流量方向/内容典型例子需要护住什么常用手段上行·普通数据抄表读数、瞬时流量完整性 来源帧挂 MAC(04 ⑦已演示)上行·结算敏感用气量(用于计费)完整 保密加密 MAC / 会话密钥下行·普通校时、参数下发防伪、防重放会话密钥 计数器/挑战下行·关键远程调价、阀控、固件升级防伪 防重放 不可抵赖平台侧 SM2 签名,表端验签两个工程要点:认证与数据用同一把长期密钥要克制:上线认证、抄表帧、指令都拿一把出厂密钥直接用,时间一长泄露面累积。更稳妥的是先认证、再协商——上线时用表密钥完成认证后,双方协商一把会话密钥用于后续批量数据加解密,MAC 也用会话密钥算。04 的代码演示的是持钥证明这一层,会话密钥协商是它的自然延伸。关键下行指令建议上签名:远程关阀、调价、固件升级一旦被伪平台冒发,后果直接作用在物理侧。这类指令价值高、频率低,值得用 SM2 签名让表端验平台身份——人机侧的 SM2 挑战-应答签名链,我们在水务篇《水务SCADA密钥管理实战》(D3-1)已拆到芯片层,这里不再展开,只点明:人的签名和物的验签,用的是同一类公钥密码,信任源可以收到同一个平台。验证点:抓平台与表计之间两轮上线报文,比对两轮的 challenge 是否不同;再对同一帧做逐字节篡改后重发,看平台是否拒收。06 | 换表与吊销:密钥生命周期的最后一环,也是最容易漏的一环密钥不是发出去就结束了。表计生命周期里最常发生、也最常被遗忘的动作是换表:到期轮换、故障更换、用户搬迁停用。换表如果只做物理更换,而旧表那套密钥还在平台台账里有效,会留下什么?——旧表(或其密钥被抄走后的仿冒者)仍能通过认证继续上报假数据、继续被当成有效设备。所以吊销必须和发一样纳入密钥管理体系:吊销是状态,不是删除:KSP 把旧表号置为revoked(而非直接删掉),保留表号、吊销时间、经办人等审计信息;每次认证入口先查状态,revoked一律拒。⑧ 的输出就是这个状态机——旧表的 MAC 数学上仍然验得过,是状态机把它拦下的。换表即换号换密钥:新表用新表号走 03 的发行链重新派生、重新签发入网(⑧ 里新表放行 True)。表号与密钥绑定,换表动作天然让旧密钥失去意义。远程改密(二次发行):对在网旧表做密钥轮换时,可通过安全通道对表端 SE 下发新密钥并递增密钥版本——SE 普遍支持更新密钥指令。这一步的前提仍是表端当前密钥有效、能完成认证,否则远程改密就变成远程开锁。落到日常,值得盯的换表不止一种:换表场景不做吊销的后果故障换表旧表密钥仍有效,被拆走的坏表可被仿冒到期轮换整批旧表退网,凭据没清 一批活口留在网上搬迁/销户人走了表还挂着有效身份,表号可被冒用上报批量置换(整小区/老旧改造)量大最容易换了就算完,正是吊销台账最能体现价值处这类换表,靠密钥管理平台按批次吊销、按表号单吊销来批量处理,而不是依赖人工逐台想起,才不会漏。为什么把吊销看得这么重?因为换表是城市里每天都在发生、却最不设防的一环。相比之下,交通线的票卡(AFC)与车载单元(ETC)也都做密钥注入,但票卡离线近距离、车载单元有部级密钥体系兜底;燃气表是低功耗广域网里的海量在网设备,生命周期管理(远程重建、远程改密、单表吊销)的权重比一次性发卡高得多——密钥工程的重心,从怎么发下去转移到怎么管一生。验证点:模拟一次换表——平台将旧表号置revoked后,用旧密钥再次发起上线,认证服务日志应出现明确的拒绝记录,而不是密钥不匹配的笼统报错(后者无法区分吊销与故障)。07 | 汇进城市生命线:物、人、数据收进同一个信任源一块表的密钥链讲完,它只是城市生命线全景的一小格。燃气平台要同时面对三类信任对象,它们的密码底座应当收到同一个源头:城市生命线(供气侧)的一张信任收口图 物:智能燃气表 / 管网监测 / 阀井感知 凭据:一表一密(SE 内),由主密钥派生、可吊销 - 本篇 人:调度值班 / 场站运维 / 第三方施工 凭据:UKEY 双因子(ASP 统一入口) - 前篇(D3-1/D3-2) 数据:抄表营收库 / 监测预警库 / GIS 凭据:落库加密与访问控制(TDE 透明加密) - 机制一致,收口同一信任源 底层共用:KSP/HSM 做密钥与证书中枢(内置 CA 组件),统一签发、统一吊销、统一审计物的密钥:平台侧 KSPHSM 管主密钥、派生与吊销;表端 SE 管存储与运算。两端是管与守的分工,缺一端,一表一密都不成立。人的入口:表计再智能,运维、换表、抄表异常处置终究是人在操作。操作人登录平台若还是弱口令,前面建的物信任链等于留了条人走的后门——公共事业线前两篇(水务篇的 UKEY 人机认证、燃气篇的身份统一治理)已经把人这一环收住,本篇不再重复。数据的落点:抄表数据、监测数据进了营收库/预警库,要防止库文件被拖走后明文裸奔,落库加密与访问控制是数据面的事,和本文密钥面互补。把物、人、数据收进同一个密钥与证书中枢,最大的收益不是买一套系统,而是让这块表是谁的、这条指令谁发的、这批数据改没改在整条链上能用一个信任源回答——这正是密评和关基检查要的自证能力。回到检查视角,等保/密评/关基检查现场,测评师对表计这类设备通常按下面几层往下问,可以当验收自查表用:层自查问题过了的标准密钥分层每块表是不是独立密钥(一表一密)?泄一把只伤一块,可单表吊销密钥保管主密钥/根密钥在哪?在 HSM/受控密钥库,不明文导出、有授权审批存储介质表端密钥放哪?SE/安全芯片不可读区,芯片有商用密码检测资质接入认证表计上线认不认身份、用没用密码技术?挑战-应答类机制 防重放(一次性挑战/帧序号)生命周期换表/销户有没有吊销动作与台账?吊销有记录、可审计、认证入口实时查状态这五条从密钥哪来、放哪、怎么用、怎么吊销把整条链串起来——也是复盘一个燃气物联密码方案时,最不容易漏的检查顺序。08 | 边界与后续:公共事业线的物与人已经成链写到这里,公共事业线(燃气/水务)在 CSDN 这条系列里已经拼出三块:D3-1《水务SCADA密钥管理实战》:把操作员插 Key 登录的人机 SM2 挑战-应答拆到芯片层,并立起人、密钥统一平台的信任源;D3-2《燃气工控安全防护实战》:横向把燃气企业人-账号-Key收口,做身份全生命周期与审计到人;本篇 D3-3:把主角换成物,从主密钥分散、出厂注入、上线认证到换表吊销,拆完一块智能燃气表的密钥一生。人、物、数据三条链,底层都是同一套密钥/证书中枢 硬件根 一物一证/一人一证 全生命周期审计。这篇之后,若把表计域换成水表、并对上具体行标(户用计量仪表数据传输的 CJ/T 188 帧结构),就是姊妹篇《智能水表密钥注入实战》(D4-2);若想回到合规视角看水务密评三级与等保到底区别在哪,可等《水务密评三级达标解读》(D4-1)。公共事业这条线,从人的双因子、到人的身份治理、再到物的密钥分发,一个可信接入的骨架就算立住了。文章作者:安当加密-焱垚
城市生命线密钥安全实战:智能燃气表密钥分发与关键基础设施密码防护
换一块燃气表,接线、通气、激活,现场十分钟;但真正把一块表接入企业的不是管道,是密钥。旧表号不吊销,新表随便发号就入网,那么远程调价、远程关阀、用气量上报这些城市生命线末梢动作,就都建立在一层纸糊的信任上。智能燃气表早已不是一块抄表工具:它装上物联网远传模块后,既能上报用气量、管网压力这类感知数据,又能接收平台下发的远程调价、阀门控制、固件升级指令——它既是城市生命线的感知末梢,又是一台可被远程寻址并执行动作的设备。城市基础设施生命线安全工程把供气作为其中一环,各地在把燃气监测(管网压力、阀井浓度、户内报警、智能表计)纳入物联感知智能预警闭环处置;而《关键信息基础设施安全保护条例》(国务院令第 745 号,2021 年 9 月 1 日起施行)把能源行业的基础网络与系统纳入关基保护视野——供气企业被认定为关基后,网络与系统的密码应用要能自证身份真实、数据可信。本文不是全景综述,而是沿一条链拆到底:一把主密钥 → 按表号分散出一表一密 → 出厂写进安全芯片 → 上线挑战-应答 → 数据帧防伪 → 换表吊销。交通线前几篇的主角是离线票卡、有部省体系的车载单元;公共事业线前两篇的主角是操作员(人的 UKEY、人的账号)。这一篇,主角换成海量、固定位置、低功耗、还会被更换的燃气表——物的设备身份。01 | 先立场景:燃气表为什么要证明我是我表还是那块表,但它的安全边界在变:燃气表安全边界的三次前移 ① 机械/IC卡表:离线单机,攻击者要接触表才能动手 前移 - 抄表的人(内部人) ② 远传表(抄表为主):数据上传,单向报数 前移 - 中间能听/能改信道的人(链路) ③ 物联网表(可寻址执行):平台能下发调价/阀控/升级指令 前移 - 任何能伪造平台或伪造表的人(网络) 到第 ③ 阶段,问题不再是表准不准,而是: 「这块正在上报数据的表,是不是我那块真表?」 「这条让我调价/关阀的指令,是不是真平台发的?」表计从计量设备变成身份与指令都要校验的接入设备,威胁跟着变。业内对燃气物联网安全风险的描述,长期指向几个固定模式:攻击/风险发生方式后果拆表抄密钥密钥若用软件存在 MCU/Flash,拆表、读芯片、逆向固件即可拿走一把密钥被复制,伪表横行信道绕过认证只认表发的帧,不校验来源,中间层转发/注入命令直接执行非法指令甚至开关阀门重放录一段合法指令(如关阀)反复发送业务被重复执行、状态失真伪表/设备冒用复制硬件与固件,冒充真表上报用气量/监测数据失真,预警失真一型一密同型号共一把密钥,泄一把 全型号沦陷破损半径从一个设备扩散到一批落到合规上,表计这类感知节点有明确的密码要求:等保 2.0 对物联网系统的扩展要求里,感知节点设备接入网络应进行身份鉴别、具备防伪能力;GB/T 39786-2021 密评要求应用系统的身份鉴别、数据真实性要用密码技术实现。落到表计上就是一句话:**设备必须拥有一把只有它自己和授权平台知道的密钥,并靠这把密钥证明身份、保住数据。**这就是本文整条链的出发点。02 | 密钥从哪来:主密钥锁根,表密钥按表号分散先回答最底层的问题:几十万块表,密钥怎么给?三个候选方案,一对比就看出问题:方案做法为什么不行一把总密钥所有表共用一把泄一把 全城表计可仿冒,单点崩塌一型一密同型号一把破损半径 一个型号批次,仍太大一表一密(分散)每块表一把,主密钥按表号分散派生泄一块只伤一块,可单表吊销“一表一密听起来是给每块表灌一把随机密钥”——那意味着产线要管理几十万个明文密钥,出厂要登记、换表要同步,泄露面巨大。更聪明的做法是就地重建:平台只保管一把主密钥,任何一块表的表密钥 以主密钥为密钥、以该表表号为输入算出来的一个值。要哪块表,现场现算,不需要存全城密钥库。表计场景下密钥层级的落法 根密钥(HSM 内,永不导出) ........... 全平台可信之根 │ 只做一件事:保护下面的主密钥 ▼ 主密钥 MK(KSP 管理) ........... 可派生、可版本化、可审计 │ 派生是纯函数:同 MK 同表号 同 key ├─ 表号 A ── key_A(烧进 A 表的 SE) ├─ 表号 B ── key_B(烧进 B 表的 SE) └─ 表号 C ── key_C(烧进 C 表的 SE) 表号是公开的(印在表上、贴在表箱里),key 却推不出来 安全性全部押在主密钥保密上 - 主密钥必须锁硬件、少露面这套设计背后的三个为什么,才是机制的内核:为什么平台能重建任意表的密钥却还是安全的?因为表密钥的机密性不靠藏密钥,而靠藏主密钥。主密钥锁在 HSM(服务器密码机)里、永不明文导出,派生请求走受控接口并全程审计——主密钥不泄露,派生再多把表密钥都只伤单表。为什么按表号派生,而不是把表号也做成密钥的一部分写死?表号是天然唯一的业务标识,派生用它,等于把密钥和这块表绑定:换表 换表号 重新派生一把新密钥,旧的那把自然作废,吊销逻辑变得极简单。为什么把管密钥从用密钥里拆出来?产线、抄表平台、预警平台都在用表密钥,但它们不该都碰主密钥。密钥管理层(KSP)把派生、签发、吊销、审计收在一个点,使用者只拿到各自那一把,权限最小化——这正是等保/密评里密钥管理要单独立项的机制原因。随之而来的一个张力要正视:主密钥是这套体系的超级信任点——它一旦泄露,一表一密里的一表就名存实亡,全城表计都能被仿。所以对主密钥的做法高度一致:分层保护、分权使用、全程留痕。根密钥只做保护下级密钥一件事、永不明文出硬件;能触发派生的角色被区分开(产线按批次领、平台按业务领、应急恢复单独授权),每次派生记下谁、为哪张表、什么时候;密钥带版本,轮换时旧版本可作废。这套把管钥的权力本身也管起来的思路,和金融领域按主密钥分散因子管理交易密钥是同族——主密钥不出硬件,业务方拿到的永远是派生后的工作密钥,平台能重建任意表密钥不是漏洞,而是换表补发、坏表恢复时的运维必需,关键是把这份特权收口、留痕、可审计。验证点:让平台用同一把主密钥、对两张不同表号做派生,看结果是否整段不同(见下文 04 脚本第①步输出)。03 | 出厂那一秒:一表一密是怎么进表的密钥派生出来了,怎么安全地放进表?这一步叫产线安全发行(也叫密钥注入/写号),它决定了伪表能不能仿出密钥。出厂/换表发行链 KSP/HSM(主密钥 锁根) │ ① 受控领取该表的派生密钥(谁领的、领哪张表,全程记账) ▼ 注入/写号设备(与 KSP 证书互认的可信客户端) │ ② 经安全通道把该表 key 下发 ▼ 表计 SE 安全芯片:key 写入不可读区 │ ③ 本地自检:用 key 完成一次挑战(密钥全程不出芯片) ▼ 出厂登记:表号 | 密钥版本 | 批次 - 同步回平台密钥台账关键在表的存储介质。同样是把密钥放进表,两种放法安全等级完全不同:存储方式密钥放在哪被拆表后软加密单片机程序/普通 Flash,软件算 SM4读 Flash、逆向固件即可抄走密钥 → 伪表可复制安全芯片(SE)专用安全芯片不可读区,密码运算在芯片内完成芯片防拆(电压/频率/温度/光照监测),暴力读取触发错误锁定/自毁,密钥抄不走表端放 SE、密钥不可读,是设备身份能成立的物理前提:**表的外壳、固件、PCB 都能被复制,唯独 SE 里那把密钥复制不出来——伪表可以长得和真表一模一样,却在认证这一步答不上来。**这也是为什么行业把 SE 方案普遍定义为接入层身份认证 安全启动 安全 OTA 安全参数管理的底座,并让安全芯片通过商用密码产品检测、内置 SM2/SM3/SM4。安当侧在这条链上承担的,是主密钥与派生签发这一层:KSP(密钥管理系统)做主密钥管理、按表号派生、密钥版本与吊销台账;HSM 做根密钥底座;产线注入工位作为 KSP 的可信客户端领取密钥,全过程留审计。表计 SE 的具体选型与芯片资质属于表厂/整机侧,这里不展开——平台侧把密钥从哪来、给谁、何时作废管住,产线侧把密钥进 SE、不出芯片做扎实,两端合起来,一表一密才真正成立。验证点:出厂抽检时,对刚注入的表发起导出密钥命令,SE 应拒绝(命令报错),而平台密钥台账里能查到这张表号、密钥版本、注入时间——密钥进得去、出不来、有记录。04 | 上线那一下:SM4 挑战-应答的完整链路表装到用户家、首次联网,平台怎么知道来者是真表?机制上就是一次挑战-应答:平台发一个一次性随机挑战,表端 SE 用自己那把密钥对它算一个校验值(MAC)回传;平台用同一把表密钥重算一遍,一致才放行。为什么用对称 SM4 而不是 SM2 签名——表计海量、低功耗、成本敏感,对称 MAC 运算轻、足够证明持有该表密钥;而不可抵赖、跨机构取证价值高的关键指令,可再叠加公钥签名(见 05)。人用签名、物用轻量 MAC,两类机制各安其位。下面这份代码可整段复制运行(gmssl 实现国密 SM4),把 ①一表一密 → ⑨换表吊销整条链跑一遍:# -*- coding: utf-8 -*-# 智能燃气表设备身份演示:一表一密 上线挑战认证 防重放/防克隆 帧防伪 换表吊销# 主密钥/挑战取固定值仅便于复现;真实环境每次真随机、用完即弃。fromgmsslimportsm4 MKbytes.fromhex(3f2a1c9e5b7d4f6a8c0e2d4b6a9c1e3f)# 16B 主密钥,锁在 HSM/KSPdefsm4_block(key:bytes,blk:bytes)-bytes:原始单块 SM4-ECB:blk 恰 16 字节(padding_modeNone 不做 PKCS7 填充)csm4.CryptSM4(modesm4.SM4_ENCRYPT,padding_modeNone)c.set_key(key,sm4.SM4_ENCRYPT)returnc.crypt_ecb(blk)def_pkcs7(msg:bytes)-bytes:pad16-(len(msg)%16)returnmsgbytes([pad])*paddef_chain(key:bytes,msg:bytes)-bytes:CBC 链式处理:逐块 异或-加密,输出最后一块(整段输入都影响结果)prebytes(16)data_pkcs7(msg)foriinrange(0,len(data),16):blkbytes(a^bfora,binzip(data[i:i16],pre))presm4_block(key,blk)returnpredefderive_meter_key(master:bytes,serial:str)-str:一表一密:主密钥按表号分散出该表唯一表密钥(演示等价物)。return_chain(master,serial.encode()).hex()defcbc_mac(key_hex:str,msg:bytes)-str:SM4-CBC-MAC(教学示意):表密钥对消息做来源完整性校验。 真实产品按规范用标准 MAC(CMAC/SM4-GCM);原理一致:改一比特,末块全变。return_chain(bytes.fromhex(key_hex),msg).hex()# ---- ① 一表一密:同一把主密钥,两张表号分散出两把互不相同的表密钥 ----print([① 一表一密] KSP/HSM 锁主密钥 MK(永不明文出硬件);密钥按表号就地重建)old_serialGAS-A2026-008877# 在装旧表(示例表号)new_serialGAS-B2026-012345# 换表后的新表old_keyderive_meter_key(MK,old_serial)new_keyderive_meter_key(MK,new_serial)print( 旧表号,old_serial,- 表密钥 ,old_key)print( 新表号,new_serial,- 表密钥 ,new_key)print( 两把密钥整段不同 - 泄一把不泄全部,可单表吊销)# ---- ② 上线认证:平台下发一次性挑战,表端 SE 用表密钥应答 MAC ----challengebytes.fromhex(3c2a9d1e8f4b6a7c0d5e9f1a2b3c4d5e)# 演示固定;真实时间戳随机print([② 挑战下发] 平台为本次上线生成一次性挑战 ,challenge.hex())tagcbc_mac(old_key,challenge)print([③ SE 应答] 表内 SE 用表密钥对挑战算 MAC ,tag,(表密钥不出芯片))usedset()print([④ 平台校验] 平台用同把派生表密钥重建 MAC)okcbc_mac(old_key,challenge)tag used.add(challenge.hex())print( 重算一致 - 放行 ,ok, (证明来者持有该表密钥真表))# ---- ③ 防重放:截获的同一份(挑战,MAC)原样再发一次 ----print([⑤ 防重放] 攻击者把 ②③ 截获报文原样重放)mac_okcbc_mac(old_key,challenge)tag replay_deniedmac_okand(challenge.hex()inused)print( MAC 重算仍相等 ,mac_ok,; 但挑战台账已命中 - 重放被拒 ,replay_denied)# ---- ④ 防克隆:抄走表硬件与固件,抄不走 SE 里的表密钥 ----print([⑥ 防克隆] 攻击者复制表硬件固件(同表号),用自己猜的密钥应答)fakecbc_mac(0*32,challenge)print( 伪表 MAC ,fake)print( 与真表 MAC 不一致 - 克隆被拒 ,fake!tag)# ---- ⑤ 数据帧防伪:上行抄表帧同样挂 MAC,改一比特即露馅 ----frame(读数:000123|瞬时流量:1.8|表号:old_serial).encode()tag_fcbc_mac(old_key,frame)forgedcbc_mac(old_key,frame[:-1]b9)# 攻击者把末位读数 7 改成 9print([⑦ 帧防伪] 上行抄表帧 MAC ,tag_f)print( 篡改末位读数后 MAC 不一致 - 篡改被拒 ,forged!tag_f)# ---- ⑥ 换表吊销:旧表密钥作废,新表重新签发入网 ----print([⑧ 换表吊销] 2026-09-03 更换表计/停用:平台将旧表号置为 revoked 并出审计)revoked{old_serial}ch_newbytes.fromhex(9d1e8f4b6a7c0d5e3f2a1c9e8b4d6f0a)# 旧表再次上线,平台下发新挑战try_old(cbc_mac(old_key,ch_new)cbc_mac(old_key,ch_new))and(old_serialinrevoked)try_new(cbc_mac(new_key,ch_new)cbc_mac(new_key,ch_new))and(new_serialnotinrevoked)print( 旧表密钥数学上仍可验 MAC,但状态已 revoked - 旧表被拒 ,try_old)print( 新表未进吊销清单 - 新表放行 ,try_new)print([⑨ 审计留痕] 2026-09-03 09:47:21 | 表号,new_serial,| 换表上线 | 挑战认证通过 | KSP 台账)把代码从头读一遍,关键在三个点:一表一密是纯函数派生:derive_meter_key用同一把MK、对不同的表号串做链式 SM4,表号一个字节不同,整把密钥就不同(①输出的两把 key 整段不一样)。平台不需要存全城密钥库,要哪块表现算;密钥的机密性全部转移到MK上——这就是MK必须锁在 HSM/KSP 的原因。应答必须用密钥、不出密钥:cbc_mac的_chain是 CBC 链式——每块密文参与下一块异或,最后一块受整段输入影响。表端 SE 只把这个 MAC 值传出来,old_key本身永远不出芯片。⑥ 里伪表用猜的密钥(0*32)算 MAC,和真表对不上,认证立刻被拒。防重放靠一次性,不靠密码学:⑤ 的关键不是 MAC 对不上,而是 MAC 明明对得上、却因为挑战用过而被台账拦下——同一个 challenge 只放行一次。密码学只能证明这把密钥在场,防重放必须靠业务侧把 challenge 做成一次性、用过即焚。这正是表计安全里最容易漏、也最廉价的一层防线。诚实地说,这段代码是教学等价物,离能直接商用的实现还隔着几层,别照抄去接产线:演示里简化了什么真实实现会怎么做派生用 SM4 链式示意按采用的密钥管理规范/标准 KDF 实现分散,输入含密钥版本、随机因子MAC 用手工 CBC-MAC用标准 SM4-CMAC / SM4-GCM 等带认证的模式challenge 用固定值真随机 时间戳,防重放落到帧序号/时间窗 台账长期表密钥直接用认证通过后协商一次性会话密钥,批量数据改用会话密钥只有一把主密钥生产/测试/灾备环境主密钥隔离,轮换按版本推进这张表的每一行,都是一个可以在方案评审里追问对方的问题——表计厂商说有加密,到底做到了哪一行,一问便知。脚本(存为d33_meter_auth.py)运行输出应为:[① 一表一密] KSP/HSM 锁主密钥 MK(永不明文出硬件);密钥按表号就地重建 旧表号 GAS-A2026-008877 - 表密钥 004bc1bff99f760dc78491dbde287aa0 新表号 GAS-B2026-012345 - 表密钥 540e347f1f5ab8496f8411ff853c788f 两把密钥整段不同 - 泄一把不泄全部,可单表吊销 [② 挑战下发] 平台为本次上线生成一次性挑战 3c2a9d1e8f4b6a7c0d5e9f1a2b3c4d5e [③ SE 应答] 表内 SE 用表密钥对挑战算 MAC 239cf41655c4cf6d8fbecd99c4e6a97e (表密钥不出芯片) [④ 平台校验] 平台用同把派生表密钥重建 MAC 重算一致 - 放行 True (证明来者持有该表密钥真表) [⑤ 防重放] 攻击者把 ②③ 截获报文原样重放 MAC 重算仍相等 True ; 但挑战台账已命中 - 重放被拒 True [⑥ 防克隆] 攻击者复制表硬件固件(同表号),用自己猜的密钥应答 伪表 MAC d3837b0c39c7fde26fd339b91a7093e4 与真表 MAC 不一致 - 克隆被拒 True [⑦ 帧防伪] 上行抄表帧 MAC fcbc4a6a1e8d28ba30be690828227ca4 篡改末位读数后 MAC 不一致 - 篡改被拒 True [⑧ 换表吊销] 2026-09-03 更换表计/停用:平台将旧表号置为 revoked 并出审计 旧表密钥数学上仍可验 MAC,但状态已 revoked - 旧表被拒 True 新表未进吊销清单 - 新表放行 True [⑨ 审计留痕] 2026-09-03 09:47:21 | 表号 GAS-B2026-012345 | 换表上线 | 挑战认证通过 | KSP 台账# 六个关键断言全部命中 一表一密成立 / 放行 / 防重放 / 防克隆 / 防篡改 / 换表吊销生效python3 d33_meter_auth.py|grep-E放行 True|重放被拒 True|克隆被拒 True|篡改被拒 True|旧表被拒 True|新表放行 True输出里的六个 True是这条链每个环节的验证点:漏掉任何一个,都说明对应环节的机制没走通——这也是把演示脚本直接当产线/平台联调自测脚本用的检查项。05 | 数据与指令:一表一密还能护住什么先看表计到平台的数据怎么走——拓扑决定了密钥放在哪。真实燃气物联网抄表大体两种:拓扑一:表直连平台(NB-IoT/4G) 拓扑二:表经集中器转发(本地组网) 表 ────────────────── 平台 表 x N ──┐ 一表一密:表 SE - 平台 两端 各表 ────┼── 集中器 ── 平台 表即网元,点对点,04 链路直接成立 (集中器也要有身份和密钥: 否则伪集中器可把一溜表的帧都翻译走)直连拓扑里,04 的链路直接成立;有集中器/采集终端的拓扑里,集中器是转发中继,不是透明管道——它自己也要有设备身份与密钥、与平台双向认证,否则中间插一台伪集中器,就能把一溜表的帧都翻译走。判断方案时先问一句:你们是哪种拓扑,集中器认不认身份?同一把表密钥,不只是上线认证那一下用。表计和平台之间的日常流量,按重要度套用不同强度的密码保护:流量方向/内容典型例子需要护住什么常用手段上行·普通数据抄表读数、瞬时流量完整性 来源帧挂 MAC(04 ⑦已演示)上行·结算敏感用气量(用于计费)完整 保密加密 MAC / 会话密钥下行·普通校时、参数下发防伪、防重放会话密钥 计数器/挑战下行·关键远程调价、阀控、固件升级防伪 防重放 不可抵赖平台侧 SM2 签名,表端验签两个工程要点:认证与数据用同一把长期密钥要克制:上线认证、抄表帧、指令都拿一把出厂密钥直接用,时间一长泄露面累积。更稳妥的是先认证、再协商——上线时用表密钥完成认证后,双方协商一把会话密钥用于后续批量数据加解密,MAC 也用会话密钥算。04 的代码演示的是持钥证明这一层,会话密钥协商是它的自然延伸。关键下行指令建议上签名:远程关阀、调价、固件升级一旦被伪平台冒发,后果直接作用在物理侧。这类指令价值高、频率低,值得用 SM2 签名让表端验平台身份——人机侧的 SM2 挑战-应答签名链,我们在水务篇《水务SCADA密钥管理实战》(D3-1)已拆到芯片层,这里不再展开,只点明:人的签名和物的验签,用的是同一类公钥密码,信任源可以收到同一个平台。验证点:抓平台与表计之间两轮上线报文,比对两轮的 challenge 是否不同;再对同一帧做逐字节篡改后重发,看平台是否拒收。06 | 换表与吊销:密钥生命周期的最后一环,也是最容易漏的一环密钥不是发出去就结束了。表计生命周期里最常发生、也最常被遗忘的动作是换表:到期轮换、故障更换、用户搬迁停用。换表如果只做物理更换,而旧表那套密钥还在平台台账里有效,会留下什么?——旧表(或其密钥被抄走后的仿冒者)仍能通过认证继续上报假数据、继续被当成有效设备。所以吊销必须和发一样纳入密钥管理体系:吊销是状态,不是删除:KSP 把旧表号置为revoked(而非直接删掉),保留表号、吊销时间、经办人等审计信息;每次认证入口先查状态,revoked一律拒。⑧ 的输出就是这个状态机——旧表的 MAC 数学上仍然验得过,是状态机把它拦下的。换表即换号换密钥:新表用新表号走 03 的发行链重新派生、重新签发入网(⑧ 里新表放行 True)。表号与密钥绑定,换表动作天然让旧密钥失去意义。远程改密(二次发行):对在网旧表做密钥轮换时,可通过安全通道对表端 SE 下发新密钥并递增密钥版本——SE 普遍支持更新密钥指令。这一步的前提仍是表端当前密钥有效、能完成认证,否则远程改密就变成远程开锁。落到日常,值得盯的换表不止一种:换表场景不做吊销的后果故障换表旧表密钥仍有效,被拆走的坏表可被仿冒到期轮换整批旧表退网,凭据没清 一批活口留在网上搬迁/销户人走了表还挂着有效身份,表号可被冒用上报批量置换(整小区/老旧改造)量大最容易换了就算完,正是吊销台账最能体现价值处这类换表,靠密钥管理平台按批次吊销、按表号单吊销来批量处理,而不是依赖人工逐台想起,才不会漏。为什么把吊销看得这么重?因为换表是城市里每天都在发生、却最不设防的一环。相比之下,交通线的票卡(AFC)与车载单元(ETC)也都做密钥注入,但票卡离线近距离、车载单元有部级密钥体系兜底;燃气表是低功耗广域网里的海量在网设备,生命周期管理(远程重建、远程改密、单表吊销)的权重比一次性发卡高得多——密钥工程的重心,从怎么发下去转移到怎么管一生。验证点:模拟一次换表——平台将旧表号置revoked后,用旧密钥再次发起上线,认证服务日志应出现明确的拒绝记录,而不是密钥不匹配的笼统报错(后者无法区分吊销与故障)。07 | 汇进城市生命线:物、人、数据收进同一个信任源一块表的密钥链讲完,它只是城市生命线全景的一小格。燃气平台要同时面对三类信任对象,它们的密码底座应当收到同一个源头:城市生命线(供气侧)的一张信任收口图 物:智能燃气表 / 管网监测 / 阀井感知 凭据:一表一密(SE 内),由主密钥派生、可吊销 - 本篇 人:调度值班 / 场站运维 / 第三方施工 凭据:UKEY 双因子(ASP 统一入口) - 前篇(D3-1/D3-2) 数据:抄表营收库 / 监测预警库 / GIS 凭据:落库加密与访问控制(TDE 透明加密) - 机制一致,收口同一信任源 底层共用:KSP/HSM 做密钥与证书中枢(内置 CA 组件),统一签发、统一吊销、统一审计物的密钥:平台侧 KSPHSM 管主密钥、派生与吊销;表端 SE 管存储与运算。两端是管与守的分工,缺一端,一表一密都不成立。人的入口:表计再智能,运维、换表、抄表异常处置终究是人在操作。操作人登录平台若还是弱口令,前面建的物信任链等于留了条人走的后门——公共事业线前两篇(水务篇的 UKEY 人机认证、燃气篇的身份统一治理)已经把人这一环收住,本篇不再重复。数据的落点:抄表数据、监测数据进了营收库/预警库,要防止库文件被拖走后明文裸奔,落库加密与访问控制是数据面的事,和本文密钥面互补。把物、人、数据收进同一个密钥与证书中枢,最大的收益不是买一套系统,而是让这块表是谁的、这条指令谁发的、这批数据改没改在整条链上能用一个信任源回答——这正是密评和关基检查要的自证能力。回到检查视角,等保/密评/关基检查现场,测评师对表计这类设备通常按下面几层往下问,可以当验收自查表用:层自查问题过了的标准密钥分层每块表是不是独立密钥(一表一密)?泄一把只伤一块,可单表吊销密钥保管主密钥/根密钥在哪?在 HSM/受控密钥库,不明文导出、有授权审批存储介质表端密钥放哪?SE/安全芯片不可读区,芯片有商用密码检测资质接入认证表计上线认不认身份、用没用密码技术?挑战-应答类机制 防重放(一次性挑战/帧序号)生命周期换表/销户有没有吊销动作与台账?吊销有记录、可审计、认证入口实时查状态这五条从密钥哪来、放哪、怎么用、怎么吊销把整条链串起来——也是复盘一个燃气物联密码方案时,最不容易漏的检查顺序。08 | 边界与后续:公共事业线的物与人已经成链写到这里,公共事业线(燃气/水务)在 CSDN 这条系列里已经拼出三块:D3-1《水务SCADA密钥管理实战》:把操作员插 Key 登录的人机 SM2 挑战-应答拆到芯片层,并立起人、密钥统一平台的信任源;D3-2《燃气工控安全防护实战》:横向把燃气企业人-账号-Key收口,做身份全生命周期与审计到人;本篇 D3-3:把主角换成物,从主密钥分散、出厂注入、上线认证到换表吊销,拆完一块智能燃气表的密钥一生。人、物、数据三条链,底层都是同一套密钥/证书中枢 硬件根 一物一证/一人一证 全生命周期审计。这篇之后,若把表计域换成水表、并对上具体行标(户用计量仪表数据传输的 CJ/T 188 帧结构),就是姊妹篇《智能水表密钥注入实战》(D4-2);若想回到合规视角看水务密评三级与等保到底区别在哪,可等《水务密评三级达标解读》(D4-1)。公共事业这条线,从人的双因子、到人的身份治理、再到物的密钥分发,一个可信接入的骨架就算立住了。文章作者:安当加密-焱垚
