矿山安全监测数据防篡改：防爆区密钥存储到CCC Ex认证

某矿瓦斯监测数据抽查，地面调度中心一份瓦斯超限记录，和井下监测分站的原始记录对不上------超限值差了一个数量级。井下传感器传上来的数被改过。没有签名链，改没改过、在哪一环改的、谁改的，统统验不出来。

# 现场复现：同一时刻的瓦斯数据，井下与地面两个数对不上（示意）
# 1) 井下监测分站原始记录
tail -1 /var/log/mine/ch4_raw.log
# → 2026-08-20 10:32:07 ch4=0.90%   ← 超限

# 2) 地面入库记录
mysql --table -e "SELECT ts, val FROM gas_hist ORDER BY ts DESC LIMIT 1"
# → | 2026-08-20 10:32:07 | 0.40 |   ← 被"改回"正常值

# 3) 全程没有签名，改动验不出
find /data/gas/signed -name 'ch4_*.sig' | wc -l
# → 0 → 无签名可验，追不到源头

矿山安全监测数据（瓦斯、煤尘、一氧化碳、风速、温度）不是普通报表，是安全红线------瓦斯超限记录一旦被改，就可能把一次真实的超限事故改"正常"。这篇按「防篡改落地六步」拆：从监测数据在井下怎么签名、怎么加密，到防爆区密钥怎么存、设备怎么过 CCC Ex 认证，一步一步给你可执行的命令和验收项。

---

一、矿山安全监测数据有哪些、为什么防篡改是红线

数据	监管锚点	被改的后果
瓦斯浓度超限记录	《煤矿安全规程》	掩盖真实超限，瓦斯爆炸隐患
煤尘浓度数据	《煤矿安全规程》	掩盖粉尘超标
一氧化碳/温度	气体监测规范	误判自燃/火灾征兆
人员定位/超时	人员定位规范	掩盖超时作业、失联

关键认知：这些数据一旦成为检查/事故调查的证据，就要**"改不动 + 改了能发现 + 追得到源头"**------靠的不是权限，是签名链。这正是密评 GB/T 39786"应用和数据安全"里的数据完整性要求。

---

二、防篡改落地六步：从签名到密钥存储

第1步：数据完整性建模------先定哪些字段要签

不是整条报文都签，先定核心防篡改字段：超限值、时间戳、传感器编号、报警状态。组态一个"签名字段清单"，签名只覆盖这些关键字段，验签效率高、误伤小。

第2步：采集侧签名------在井下源头就签名

监测分站/传感器网关在数据产生时，用SM3 摘要 + SM2 签名打上"指纹"。签名密钥存在防爆区设备里，私钥不出设备：

# 模拟监测分站对一条瓦斯数据签名（密钥路径以实际部署为准；OpenSSL 3.x 默认支持 SM2/SM3）
openssl dgst -sm3 -sign /etc/mine/keys/sm2_sign.key -out ch4_001.sig ch4_001.json
openssl dgst -sm3 -verify /etc/mine/keys/sm2_verify.pub -signature ch4_001.sig ch4_001.json
# → Verified OK → 数据未被篡改 ✓

第3步：传输加密------井下到地面别裸奔

监测数据从井下环网/4G-5G 上传，走 SM4/TLS 加密通道，抓包不是明文；环网内按区段隔离，防止中间人改写：

# 验证上传通道已加密（抓井下→地面出口，应无明文监测帧；KJ 监控多为私有/帧协议，按监测网段抓包）
tcpdump -i eth0 -n -X 'net 10.20.0.0/16' -c 10
# → 无明文帧 → 通道已加密 ✓

第4步：地面验签与落库防篡改------接收端验签 + 存储防篡改

地面服务器收到数据先验签 ，验签失败直接告警；入库数据再做摘要签名链（前一条摘要进后一条签名），历史库透明加密（TDE）：

# 1) 验签接收（地面端）
openssl dgst -sm3 -verify /etc/mine/keys/sm2_verify.pub -signature ch4_001.sig ch4_001.json
# → Verified OK → 该条未被篡改

# 2) 历史库落盘加密标志（以 MySQL 8.0 为例）
SELECT TABLESPACE_NAME, ENCRYPTION FROM information_schema.innodb_tablespaces
  WHERE TABLESPACE_NAME IN ('gas_hist','pos_hist');
# → ENCRYPTION = 'Y' → 落盘已加密 ✓

第5步：防爆区密钥存储------私钥要锁进防爆密码模块

这是矿山场景最容易被忽略的一环：签名私钥、加密密钥存哪？ 答案是存进防爆认证的密码模块/密码机里，锁在井下防爆区：

• 私钥在防爆密码设备内生成、永不出设备
• 设备本身过防爆认证，密钥随设备锁在防爆区
• 密钥全生命周期的签发、轮换、审计由统一密钥平台管、双人授权------具体见下一章

# 验证防爆密码模块内主密钥不可导出（libwhsm.so 为示例驱动库，以实际为准）
pkcs11-tool --module /usr/lib/libswhsm.so -l --pin 12345678 --extract --id 01
# → error: CKR_ATTRIBUTE_READ_ONLY → 主密钥硬件内不可导出 ✓

第6步：设备防爆合规------密钥存储设备也要过 CCC Ex

防爆区放任何 带电子元件的设备（包括签名模块、密钥存储设备、监测分站），都要过防爆认证：

• CCC Ex：防爆电气产品国家强制认证（GB 3836 系列），分防爆型式（隔爆 Ex d、本安 Ex ia/ib 等）
• MA：矿用产品安全标志（针对矿用设备）
• 密钥存储设备选型时先确认防爆认证，按现场分区（井下一类、危险区域等）匹配防爆等级------设备无证，检查直接不符合

---

三、密钥管理答案：防爆区里的签名钥匙谁管

• 签名/加密密钥存哪？ 存防爆密码模块内，主密钥锁 HSM 密码机，均不出硬件
• 由谁统一管？ KSP 密钥管理系统统一生成、签发、轮换、审计，双人授权
• 多久轮换一次？ 签名密钥按策略轮换（一般短于业务密钥），轮换留痕
• 监测设备怎么接？ 监测分站/地面服务器通过统一密码服务接口调用签名验签，不各自实现算法

安当 HSM（密码机）+ KSP（密钥管理系统）在矿山监测场景的落点：防爆区签名私钥由防爆密码模块保护，密钥全生命周期由 KSP 统一管理，主密钥锁 HSM------数据防篡改从源头（井下）到地面，密钥始终在密码设备里。复核、签发这类高权限操作的人员身份，统一走安当 ASP 发证 + UKEY（SM2 证书）认证------数据要防篡改，人也要"验得出是谁"。

---

四、验收清单：逐项验证做对了

#	验收项	验证方法	达标判定
1	采集侧签名	改动一条监测数据后验签	验签失败并告警
2	传输加密	抓井下→地面通道	无明文监测帧
3	地面验签生效	篡改数据重传	地面拒绝入库并告警
4	历史库落盘加密	查 innodb_tablespaces + strings	ENCRYPTION='Y'，数据文件无明文串
5	签名链完整	抽查连续 N 条记录摘要链	链完整，无断点
6	私钥不可导出	pkcs11-tool --extract	报错 CKR_ATTRIBUTE_READ_ONLY
7	防爆合规	核对签名/密钥设备 CCC Ex / MA 证书	认证等级与井下分区匹配
8	密钥统一管理	查 KSP 审计日志	签发/轮换全程留痕

---

对着这份清单把你矿的监测数据过一遍：改动一条瓦斯数据验一次签、抓一次上传通道、核对一次密钥设备的防爆证书。防篡改从井下到地面，你卡在哪一步------是源头没签名，还是防爆区密钥没存好？评论区说出来，一起拆。

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