换一块燃气表,接线、通气、激活,现场十分钟;但真正把一块表"接入"企业的不是管道,是密钥。旧表号不吊销,新表随便发号就入网,那么远程调价、远程关阀、用气量上报这些"城市生命线"末梢动作,就都建立在一层纸糊的信任上。
智能燃气表早已不是一块"抄表工具":它装上物联网远传模块后,既能上报用气量、管网压力这类感知数据,又能接收平台下发的远程调价、阀门控制、固件升级指令——它既是城市生命线的感知末梢,又是一台可被远程寻址并执行动作的设备。城市基础设施生命线安全工程把供气作为其中一环,各地在把燃气监测(管网压力、阀井浓度、户内报警、智能表计)纳入"物联感知+智能预警+闭环处置";而《关键信息基础设施安全保护条例》(国务院令第 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 MK=bytes.fromhex("3f2a1c9e5b7d4f6a8c0e2d4b6a9c1e3f")# 16B 主密钥,锁在 HSM/KSPdefsm4_block(key:bytes,blk:bytes)->bytes:"""原始单块 SM4-ECB:blk 恰 16 字节(padding_mode=None 不做 PKCS7 填充)"""c=sm4.CryptSM4(mode=sm4.SM4_ENCRYPT,padding_mode=None)c.set_key(key,sm4.SM4_ENCRYPT)returnc.crypt_ecb(blk)def_pkcs7(msg:bytes)->bytes:pad=16-(len(msg)%16)returnmsg+bytes([pad])*paddef_chain(key:bytes,msg:bytes)->bytes:"""CBC 链式处理:逐块 异或-加密,输出最后一块(整段输入都影响结果)"""pre=bytes(16)data=_pkcs7(msg)foriinrange(0,len(data),16):blk=bytes(a^bfora,binzip(data[i:i+16],pre))pre=sm4_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_serial="GAS-A2026-008877"# 在装旧表(示例表号)new_serial="GAS-B2026-012345"# 换表后的新表old_key=derive_meter_key(MK,old_serial)new_key=derive_meter_key(MK,new_serial)print(" 旧表号",old_serial,"-> 表密钥 =",old_key)print(" 新表号",new_serial,"-> 表密钥 =",new_key)print(" 两把密钥整段不同 -> 泄一把不泄全部,可单表吊销")# ---- ② 上线认证:平台下发一次性挑战,表端 SE 用表密钥应答 MAC ----challenge=bytes.fromhex("3c2a9d1e8f4b6a7c0d5e9f1a2b3c4d5e")# 演示固定;真实=时间戳+随机print("[② 挑战下发] 平台为本次上线生成一次性挑战 =",challenge.hex())tag=cbc_mac(old_key,challenge)print("[③ SE 应答] 表内 SE 用表密钥对挑战算 MAC =",tag,"(表密钥不出芯片)")used=set()print("[④ 平台校验] 平台用同把派生表密钥重建 MAC")ok=cbc_mac(old_key,challenge)==tag used.add(challenge.hex())print(" 重算一致 -> 放行 =",ok," (证明来者持有该表密钥=真表)")# ---- ③ 防重放:截获的同一份(挑战,MAC)原样再发一次 ----print("[⑤ 防重放] 攻击者把 ②③ 截获报文原样重放")mac_ok=cbc_mac(old_key,challenge)==tag replay_denied=mac_okand(challenge.hex()inused)print(" MAC 重算仍相等 =",mac_ok,"; 但挑战台账已命中 -> 重放被拒 =",replay_denied)# ---- ④ 防克隆:抄走表硬件与固件,抄不走 SE 里的表密钥 ----print("[⑥ 防克隆] 攻击者复制表硬件固件(同表号),用自己猜的密钥应答")fake=cbc_mac("0"*32,challenge)print(" 伪表 MAC =",fake)print(" 与真表 MAC 不一致 -> 克隆被拒 =",fake!=tag)# ---- ⑤ 数据帧防伪:上行抄表帧同样挂 MAC,改一比特即露馅 ----frame=("读数:000123|瞬时流量:1.8|表号:"+old_serial).encode()tag_f=cbc_mac(old_key,frame)forged=cbc_mac(old_key,frame[:-1]+b"9")# 攻击者把末位读数 7 改成 9print("[⑦ 帧防伪] 上行抄表帧 MAC =",tag_f)print(" 篡改末位读数后 MAC 不一致 -> 篡改被拒 =",forged!=tag_f)# ---- ⑥ 换表吊销:旧表密钥作废,新表重新签发入网 ----print("[⑧ 换表吊销] 2026-09-03 更换表计/停用:平台将旧表号置为 revoked 并出审计")revoked={old_serial}ch_new=bytes.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 组件),统一签发、统一吊销、统一审计- 物的密钥:平台侧 KSP+HSM 管主密钥、派生与吊销;表端 SE 管存储与运算。两端是"管"与"守"的分工,缺一端,一表一密都不成立。
- 人的入口:表计再智能,运维、换表、抄表异常处置终究是人在操作。操作人登录平台若还是弱口令,前面建的物信任链等于留了条人走的后门——公共事业线前两篇(水务篇的 UKEY 人机认证、燃气篇的身份统一治理)已经把"人"这一环收住,本篇不再重复。
- 数据的落点:抄表数据、监测数据进了营收库/预警库,要防止库文件被拖走后明文裸奔,落库加密与访问控制是数据面的事,和本文密钥面互补。
把物、人、数据收进同一个密钥与证书中枢,最大的收益不是"买一套系统",而是让"这块表是谁的、这条指令谁发的、这批数据改没改"在整条链上能用一个信任源回答——这正是密评和关基检查要的自证能力。
回到检查视角,等保/密评/关基检查现场,测评师对表计这类设备通常按下面几层往下问,可以当验收自查表用:
| 层 | 自查问题 | 过了的标准 |
|---|---|---|
| 密钥分层 | 每块表是不是独立密钥(一表一密)? | 泄一把只伤一块,可单表吊销 |
| 密钥保管 | 主密钥/根密钥在哪? | 在 HSM/受控密钥库,不明文导出、有授权审批 |
| 存储介质 | 表端密钥放哪? | SE/安全芯片不可读区,芯片有商用密码检测资质 |
| 接入认证 | 表计上线认不认身份、用没用密码技术? | 挑战-应答类机制 + 防重放(一次性挑战/帧序号) |
| 生命周期 | 换表/销户有没有吊销动作与台账? | 吊销有记录、可审计、认证入口实时查状态 |
这五条从"密钥哪来、放哪、怎么用、怎么吊销"把整条链串起来——也是复盘一个燃气物联密码方案时,最不容易漏的检查顺序。
08 | 边界与后续:公共事业线的"物"与"人"已经成链
写到这里,公共事业线(燃气/水务)在 CSDN 这条系列里已经拼出三块:
- D3-1《水务SCADA密钥管理实战》:把"操作员插 Key 登录"的人机 SM2 挑战-应答拆到芯片层,并立起"人、密钥统一平台"的信任源;
- D3-2《燃气工控安全防护实战》:横向把燃气企业"人-账号-Key"收口,做身份全生命周期与审计到人;
- 本篇 D3-3:把主角换成"物",从主密钥分散、出厂注入、上线认证到换表吊销,拆完一块智能燃气表的密钥一生。
人、物、数据三条链,底层都是同一套"密钥/证书中枢 + 硬件根 + 一物一证/一人一证 + 全生命周期审计"。这篇之后,若把表计域换成水表、并对上具体行标(户用计量仪表数据传输的 CJ/T 188 帧结构),就是姊妹篇《智能水表密钥注入实战》(D4-2);若想回到合规视角看"水务密评三级与等保到底区别在哪",可等《水务密评三级达标解读》(D4-1)。公共事业这条线,从人的双因子、到人的身份治理、再到物的密钥分发,一个"可信接入"的骨架就算立住了。
文章作者:安当加密-焱垚
