运营商密评GB/T39786合规解读:密评整改与国密算法改造如何落地一份密评报告摆在桌上,不符合项列了三页。运营商的安全负责人看完只说了一句话:这些问题,大半是同一件事——系统里跑的还是国际算法。真正让项目组头疼的不是要不要换,而是换的过程:计费系统 7×24 在跑,信令面不能断,网管平台的接口被十几个上下游系统调用。算法迁移本身是一次可控的技术改造,难的是换到一半的时候业务还得照常跑,历史数据还得能读,新老系统还得能互通。坐标先立:密评的依据是 GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》,评估从4 个技术层面(物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全)与4 个管理层面(管理制度、人员管理、建设运行、应急处置)展开,判据是三性:合规性(用的是不是合规的算法与产品)、正确性(用得对不对)、有效性(是否真的起了作用)。运营商场景的特殊性在于:系统多、算法存量杂、多厂商分治,而且几乎没有停机窗口。01 | 运营商密评,难在哪儿同样一套密评要求,放在运营商网络里,难度会被放大好几倍。原因集中在这五点上:系统数量多、算法栈杂。计费、账务、网管、信令、短信中心、云平台各是一套系统,有的用国际算法,有的用早年自研的加密模块,还有的干脆靠内网可信不做密码保护。清点一遍算法资产,本身就是一项工程。改造量按系统 × 接口放大。一套系统对外可能有十几个接口,每个接口都涉及通信加密与签名验签。算法替换不是改一处配置,而是沿调用链一路捋过去。没有停机窗口。计费与账务 7×24 运行,月度出账更是高压期;信令面一旦中断影响面极广。任何要求停两小时统一割接的方案,在实际环境里都排不进去。多厂商分治,密钥归属不清。系统由不同厂商建设,密码模块各用各的,密钥有的写在配置文件里、有的散落在各系统的数据库表里。密评问密钥由谁生成、由谁保管、多久轮换、谁能使用,往往没人能完整回答。云化之后,密码资源跟着虚机漂移。网络功能虚拟化后,网元不再固定在某台物理机上,密码资源如果还绑在某台机器的某个文件上,虚机一迁移就失效。这五点决定了运营商密评整改的基本姿势:不能靠推倒重来,只能靠沿链路分阶段替换 密码资源统一纳管。02 | 四层面逐层对照:要求、常见不符合项、整改动作把 GB/T 39786 的四个技术层面摊开,对照运营商环境里的典型情况:技术层面密评关注点运营商常见不符合项整改动作物理和环境安全门禁、视频等物理访问控制记录的完整性门禁记录、视频记录未做密码保护,可被删改对门禁与视频记录做完整性保护并留痕网络和通信安全通信双方身份真实性、数据机密性与完整性网管网与运维通道使用国际算法,或只做单向认证双向证书认证 国密算法加密通道设备和计算安全设备身份真实性、日志完整性、访问控制设备用默认口令,系统日志可被本地修改以证书标识设备身份,日志签名留痕应用和数据安全身份鉴别、访问控制、数据机密性、完整性、不可否认关键数据明文存储,签名仍用国际算法存储加密 算法替换 签名验签改造管理层面的四项(管理制度、人员管理、建设运行、应急处置)则主要落在文档与流程上:密钥管理制度是否成文、岗位是否分离、建设运行阶段是否同步考虑密码应用、密钥泄露与设备故障是否有应急预案。技术层面改得再好,管理规定和操作记录缺失,一样会在评估中被扣分。算法迁移到底在改什么很多人把国密改造理解成把 RSA 换成 SM2、把 AES 换成 SM4。这只说对了三分之一。真正的迁移是三件事一起动:【改造前】 应用 ──RSA / AES / SHA──► 数据与服务 密钥:写在配置文件、代码或数据库表里,谁都能看 【改造后】 应用 ──SM2 / SM4 / SM3──► 数据与服务 密钥:统一由密钥管理系统托管,明文不出硬件 密文:每份密文携带算法标识与密钥版本,可追溯、可轮换 迁移 算法替换 密钥管理方式重构 密文可追溯性建设第三件事最容易被忽略,却是密评现场最容易被问到的一条:你怎么证明这份数据是用合规算法加密的?如果密文里没有任何算法标识与密钥版本信息,运维只能靠记忆和文档回答,一旦经历几轮人员变动,这条链路就断了。让密文自己带着我是谁、用哪把密钥、哪个版本的信息,整改成果才是可核查的。03 | 先跑通:一次算法迁移的五个环节下面这段用国密算法把迁移过程中的五个关键环节跑一遍:算法替换的等价性、签名验签、密钥分层、算法留痕、轮换与过渡(演示用固定密钥与合成数据):# -*- coding: utf-8 -*- # 运营商密评整改演示:国密算法迁移 签名验签 密钥分层 算法留痕 轮换过渡 import json, hashlib from gmssl import sm2, sm3, sm4, func def sm3h(b: bytes) - str: return sm3.sm3_hash(func.bytes_to_list(b)) def digest(b: bytes) - bytes: return bytes.fromhex(sm3h(b)) def sm4_enc(k: bytes, b: bytes) - bytes: c sm4.CryptSM4(); c.set_key(k, sm4.SM4_ENCRYPT); return c.crypt_ecb(b) def sm4_dec(k: bytes, b: bytes) - bytes: c sm4.CryptSM4(); c.set_key(k, sm4.SM4_DECRYPT); return c.crypt_ecb(b) def pub_of(p: str) - str: return sm2.CryptSM2(private_keyp, public_key00)._kg(int(p, 16), sm2.default_ecc_table[g]) def line(t: str, ok: bool): print(f[{t}] {True if ok else False}) # 签名私钥(实际存于签名验签服务器/HSM 内,永不明文出硬件) SIGN_P 3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b K_SIGN 20240601123456789abcdef0123456789abcdef0123456789abcdef012345678 SIGNER sm2.CryptSM2(private_keySIGN_P, public_keypub_of(SIGN_P)) VERIFIER sm2.CryptSM2(private_keyNone, public_keypub_of(SIGN_P)) # 验签方只持公钥 MSG json.dumps({acct: 1001, fee: 128.50, ts: 2026-09-14T09:00:00}, ensure_asciiFalse).encode(utf-8) print( 环节1:算法迁移(SM4/SM3 替换国际算法) ) DATA (计费话单|账号1001|金额128.50|时间2026-09-14T09:00:00).encode(utf-8) K_V1 bytes.fromhex(11 * 16) ct sm4_enc(K_V1, DATA) line(SM4 加密后可完整还原, sm4_dec(K_V1, ct) DATA) line(SM3 摘要长度固定 256 位, len(sm3h(DATA)) 64) line(同一数据的摘要在迁移后确实改变, sm3h(DATA) ! hashlib.sha256(DATA).hexdigest()) print( 环节2:签名验签(SM2 替换 RSA 签名) ) sig SIGNER.sign(digest(MSG), K_SIGN) line(SM2 签名验签通过, VERIFIER.verify(sig, digest(MSG))) line(报文被篡改 验签失败, not VERIFIER.verify(sig, digest(MSG.replace(b128.50, b9999.50)))) print( 环节3:密钥分层(根密钥保护工作密钥) ) KEK bytes.fromhex(22 * 16) # 根密钥,存于 HSM DEK bytes.fromhex(33 * 16) # 工作密钥,用于业务加密 dek_env sm4_enc(KEK, DEK) # 工作密钥以密文形态落库 line(工作密钥 以密文形态存储, dek_env ! DEK) line(有根密钥 可还原工作密钥, sm4_dec(KEK, dek_env) DEK) STRANGER bytes.fromhex(44 * 16) # 越权者手中的另一把密钥 line(无根密钥 解不出工作密钥, sm4_dec(STRANGER, dek_env) ! DEK) print( 环节4:算法标识与操作留痕 ) ENV {alg: SM4-ECB/PKCS7, keyId: telecom-bss-01, keyVersion: v1, ct: ct.hex()} line(密文信封带算法与密钥版本, ENV[alg].startswith(SM4) and ENV[keyVersion] v1) def audit(rec: dict, prev: str) - str: return sm3h((prev json.dumps(rec, ensure_asciiFalse, sort_keysTrue)).encode(utf-8)) a1 audit({op: encrypt, key: telecom-bss-01, v: v1}, 0 * 64) a2 audit({op: rotate, key: telecom-bss-01, v: v2}, a1) line(审计哈希链 校验通过, audit({op: rotate, key: telecom-bss-01, v: v2}, a1) a2) line(篡改审计记录 校验失败, audit({op: rotate, key: telecom-bss-01, v: v9}, a1) ! a2) print( 环节5:密钥轮换与双算法过渡 ) K_V2 bytes.fromhex(55 * 16) ct_v2 sm4_enc(K_V2, DATA) line(轮换后 新数据用 v2 加密, sm4_dec(K_V2, ct_v2) DATA) line(历史数据 仍可用归档 v1 解密, sm4_dec(K_V1, ct) DATA)跑起来,五个环节的结论如下: 环节1:算法迁移(SM4/SM3 替换国际算法) [SM4 加密后可完整还原] True [SM3 摘要长度固定 256 位] True [同一数据的摘要在迁移后确实改变] True 环节2:签名验签(SM2 替换 RSA 签名) [SM2 签名验签通过] True [报文被篡改 验签失败] True 环节3:密钥分层(根密钥保护工作密钥) [工作密钥 以密文形态存储] True [有根密钥 可还原工作密钥] True [无根密钥 解不出工作密钥] True 环节4:算法标识与操作留痕 [密文信封带算法与密钥版本] True [审计哈希链 校验通过] True [篡改审计记录 校验失败] True 环节5:密钥轮换与双算法过渡 [轮换后 新数据用 v2 加密] True [历史数据 仍可用归档 v1 解密] True逐段注解:环节 1 是迁移的等价性验证——换算法不能换来数据解不开。同一份数据用 SM4 加密后必须能完整还原;摘要长度固定 256 位,说明算法确实换成了 SM3;第三条对比的是迁移前后的摘要值不同,佐证算法真的换了,而不是只改了配置里的名字。环节 2 处理签名:签名方持有私钥、验签方只持公钥,报文被改动一个字符验签即失败——这是不可否认的技术底座,也是密评在应用和数据安全层面的关注点。环节 3 是密钥关系的核心:工作密钥不以明文形态存储,而是被根密钥加密后落库;有根密钥才能还原它,手里只有别的密钥的人拿到的是一堆解不开的字节。环节 4 回应如何证明这个问题:密文信封里写着算法标识与密钥版本,同时每一次密钥操作都进入哈希链——链上任何一条记录被改动,校验就会失败,这是审计留痕不可篡改的实现方式。环节 5 是迁移能否平稳落地的分水岭:新数据用新密钥,历史数据仍能用归档的旧密钥解开,两者并存,业务不中断。验证点(现场怎么演):取一条历史数据,分别用新旧密钥解密,应都能还原;改动一条审计记录后重新校验哈希链,应当报不一致;查看密文信封,应当能看到算法标识与密钥版本;把密钥存储位置找出来,应当落在密钥管理系统或硬件密码模块内,而不是应用配置文件里。双算法过渡:为什么不能一次切完整改最容易出事的做法,是定一个割接日,当天全量切换。真实环境里,新旧系统、上下游接口、历史数据三者不可能同步完成切换。可行的方式是设一个过渡期,让新旧算法并存一段时间:过渡期设计做法退出条件密文带算法标识密文自描述用哪个算法、哪个密钥版本全部密文完成识别与分类新旧并存解密解密侧同时支持新旧算法,按标识选择历史数据完成重加密或确认归档策略新数据只用新算法新增与变更的数据一律走国密覆盖全部写入路径旧算法只读旧算法降级为只能解密、不能加密无新增旧算法密文过渡期的关键是把切换从一次性动作变成可观测的过程:哪些数据还在用旧算法、还有多少、由谁负责,这些都能从密文的算法标识里统计出来。等旧算法的写入路径全部清零,再正式下线,而不是靠拍脑袋定日期。方案评估与系统评估:两次评估分别在评什么密评不是一次性动作,而是分两次:方案评估与系统评估。搞清楚两者的差别,整改排期才不会做反。维度方案评估系统评估评估对象密码应用方案的设计已建成系统的实际运行状态时间点系统建设或改造之前系统上线运行之后主要依据设计文档、密码应用方案现场配置、运行记录、测试结果典型问题方案未覆盖某个层面、算法选型不合规设计与实际不一致、密钥未按方案管理整改空间改动成本低,改设计即可改动成本高,涉及停机与业务系统实际项目里最常见的问题是跳过方案评估直接做系统评估:改造已经做完了,才发现在设计阶段就没把某个层面考虑进去,此时再补,代价是停机与返工。正确的顺序是先做方案设计与评估、再动手改造、最后做系统评估,把可以改的地方留在成本最低的阶段改。04 | 整改怎么排:三步法与优先级把整改当成一个项目来排,顺序大致是三步:第一步:差距评估(清点)。按四个技术层面逐项对照,产出一张清单:系统清单(有哪些系统涉及密码应用)、算法清单(每套系统用了什么算法、在哪些环节)、接口清单(哪些接口需要加密与签名)、密钥位置清单(密钥存在哪、谁管、是否轮换)。这一步是后面所有工作量的来源,也是密评方案评估阶段的核心交付。第二步:分阶段改造(替换)。优先级建议按这个顺序:对外接口与跨域通信 → 关键数据的存储加密 → 内部系统间通信 → 管理与审计类功能。理由很直接:越靠外、越接近数据出口的地方,风险越高、密评关注度也越高;先把这些改完,评估的大头就解决了。第三步:统一纳管与复测(收口)。把散落在各系统的密钥收拢到统一的密钥管理系统,建立轮换与审计机制,然后按层面复测并留存记录。收口这一步做不好,前面改造得再规范,密钥谁在管这个问题仍然答不上来。需要提醒的是,密码资源统一纳管不是再买一套系统,而是把已有的密码能力集中起来。运营商往往已经有硬件密码模块,缺的是密钥全生命周期怎么管、谁能用、用了几次、什么时候轮换这一层的统一视图。算法清点怎么做:一张表管到底差距评估里最耗时的是算法清点。与其按系统逐个翻文档,不如先定好一张表的字段,所有系统都往这张表里填:字段填什么用途系统名称涉及的每个系统界定改造范围使用环节传输 / 存储 / 签名 / 鉴别对应到具体技术层面现用算法国际算法或国密算法判断是否需要替换密钥位置配置文件 / 代码 / 数据库 / 密码模块判断密钥管理风险密钥管理方谁生成、谁保管、是否轮换对应管理层面要求改造优先级高 / 中 / 低排期依据这张表填完,改造工作量、优先级和风险点一目了然,也给评估提供了我们清楚自己的密码资产的直接证据。清单本身不是形式主义——被问到有多少套系统用到密码技术时,能当场拿出一张表,和临时翻文档,是两种完全不同的评估体验。责任分工也要写进方案:系统的密码应用通常涉及三方——业务系统的建设方(改应用)、密码产品与服务方(提供算法与密钥能力)、运营方(定策略与验收)。三者边界不清时,最典型的后果是密码改造没人认领:应用厂商说算法不是我们的事,密码厂商说业务系统我们进不去,最后卡在中间。一个整改样本:从三页不符合项到按期复测某省级运营商在一次密评中拿到三页不符合项,其中六成指向同一类问题:对外接口仍使用国际算法、密钥分散在各系统的配置文件里、审计记录存在本地且可被修改。项目组最初按逐系统替换排期,一算工期要跨两个季度,而且计费系统的停机窗口根本申请不下来。调整后的路径是先清点、再分层、后收口:先用两周做算法清点,把涉及密码应用的系统、接口、密钥位置列成表;再按对外接口 → 关键数据存储 → 内部系统间通信的优先级分批替换,替换期间新旧算法并存,历史数据保持可解;最后把散落在各系统的密钥收拢到统一的密钥管理系统,建立轮换机制与防篡改的审计留痕。结果:改造全程未申请停机窗口,业务没有中断;复测时,密钥由谁管理数据是否加密存储审计是否可追溯这三个高频问题都能当场给出记录。项目组自己的总结是:最难的不是换算法,而是先把自己手上有什么数清楚。05 | 避坑清单:8 条最容易踩的坑#坑后果怎么验证避开了1只做算法替换,不管密钥存哪密评问密钥谁管答不上来追问密钥存放位置与责任人2密钥写死在配置文件或代码里拿到主机即拿到密钥检索配置文件与代码,应无密钥明文3一次性全量割接无停机窗口,割接失败即业务中断检查是否有过渡期方案与回退预案4历史数据没考虑兼容切换后旧数据读不出来用旧密钥解密历史数据,应能还原5加密了但密文不带算法与版本标识无法统计改造进度、无法追溯查看密文结构,应含算法与密钥版本6审计日志本地存储、可被删改事后无法追溯尝试删改审计记录,应被发现7云化环境仍把密码资源绑在单机虚机迁移后密码服务不可用迁移一次虚机,验证密码能力是否跟随8只改技术不改管理制度与记录缺失,评估仍扣分对照管理层面四项,查制度与操作记录第 3 条是运营商场景里代价最高的一条:在不能停机的系统上做全量割接,等于把业务当赌注。凡是排期里出现某日凌晨统一切换的方案,都要问一句:切换失败的回退路径是什么、多久能退回来。06 | 合规视角:运营商要对上哪些要求GB/T 39786-2021 与密评:四技术层面 四管理层面逐项对照,评估按合规性、正确性、有效性三性判定;方案评估看设计,系统评估看落地,两者都过才算走完流程(GB/T 39786 的逐层落地框架详见 D6-1)。等保 2.0:电信行业核心系统普遍按等保三级及以上定级,密码应用是其明确的测评项;等保与密评的关注点不同但相互引用,整改时可以合并推进。关键信息基础设施保护要求:电信网络属关基范畴,运营者需履行相应的安全保护义务并对密码应用提出更高要求。电信行业主管部门的现行安全规范:运营商需按行业主管部门发布的数据安全与网络安全要求落实分类分级与安全评估,具体条目以现行有效文件为准。云化与虚拟化环境:网络功能虚拟化后,密码资源的使用者从固定设备变成会漂移的网元,密码服务需要以服务化方式提供,而不是绑定在某台机器上。07 | 落地答案:证书、密钥与算法迁移怎么承接把整改落到组件上,安当体系里对应 CAS-KMS、HSM 与 KSP 三件:CAS-KMS 密码应用系统:提供证书与密钥的统一管理,支撑设备与系统身份的证书签发、更新与吊销;固件与软件签名能力可解决设备和计算安全层面的身份与完整性要求。对应四层面里设备和计算安全这条线。HSM 硬件密码模块:密钥的生成与运算在硬件内完成,根密钥不以明文形态离开硬件;支持签名验签、加密解密等密码运算。对应避坑第 2 条与密钥分层要求。KSP 密钥管理系统:三级密钥体系、版本化轮换、归档与销毁,密钥操作全程留痕且记录防篡改(全生命周期做法详见 D6-2)。对应密钥统一纳管这一步。算法迁移的落点:新老算法并存解密、密文携带算法标识与密钥版本,是过渡期能平稳推进的技术前提;这套机制由密钥管理系统统一提供,而不是在每个业务系统里各写一套。一句话:这套组合要解决的是算法换成合规的、密钥收到硬件里、每份密文能说清自己是谁加密的——三件事同时成立,密评现场才有得答。08 | 验收清单与下一步检查项当场动作应得结果算法合规检查加密配置与密文算法标识全部为国密算法数据可还原加密后立即解密比对与原文一致签名可用篡改报文后验签验签失败密钥不入应用检索配置文件与代码无密钥明文密钥分层查看密钥存储结构工作密钥以密文形态存在密文可追溯查看密文结构含算法标识与密钥版本轮换不中断轮换后读取历史数据仍可解密审计防篡改改动一条审计记录哈希链校验失败过渡期方案查改造排期有并存期与退出条件趋势:密评整改正在从一次性过评走向持续合规——算法会更新、系统会上云、密钥需要轮换,一次整改的结果如果不能在日常运维中持续保持,下一轮评估又要重来。把密钥管理、算法标识与审计留痕做成常态能力,后面无论是扩容、上云还是迎接新一轮评估,都是叠加而不是返工。下一篇预告:算法与密钥的合规底座建好之后,我们把视角转向 5G 网络内部——核心网网元之间的认证与授权怎么做:网元凭什么互相信任、服务化接口调用如何授权、用户标识在空口上怎么保护。这是电信线里技术密度最高的一环。文章作者:安当加密-焱垚 运营商密评GB/T39786合规解读:密评整改与国密算法改造如何落地
运营商密评GB/T39786合规解读:密评整改与国密算法改造如何落地一份密评报告摆在桌上,不符合项列了三页。运营商的安全负责人看完只说了一句话:这些问题,大半是同一件事——系统里跑的还是国际算法。真正让项目组头疼的不是要不要换,而是换的过程:计费系统 7×24 在跑,信令面不能断,网管平台的接口被十几个上下游系统调用。算法迁移本身是一次可控的技术改造,难的是换到一半的时候业务还得照常跑,历史数据还得能读,新老系统还得能互通。坐标先立:密评的依据是 GB/T 39786-2021《信息安全技术 信息系统密码应用基本要求》,评估从4 个技术层面(物理和环境安全、网络和通信安全、设备和计算安全、应用和数据安全)与4 个管理层面(管理制度、人员管理、建设运行、应急处置)展开,判据是三性:合规性(用的是不是合规的算法与产品)、正确性(用得对不对)、有效性(是否真的起了作用)。运营商场景的特殊性在于:系统多、算法存量杂、多厂商分治,而且几乎没有停机窗口。01 | 运营商密评,难在哪儿同样一套密评要求,放在运营商网络里,难度会被放大好几倍。原因集中在这五点上:系统数量多、算法栈杂。计费、账务、网管、信令、短信中心、云平台各是一套系统,有的用国际算法,有的用早年自研的加密模块,还有的干脆靠内网可信不做密码保护。清点一遍算法资产,本身就是一项工程。改造量按系统 × 接口放大。一套系统对外可能有十几个接口,每个接口都涉及通信加密与签名验签。算法替换不是改一处配置,而是沿调用链一路捋过去。没有停机窗口。计费与账务 7×24 运行,月度出账更是高压期;信令面一旦中断影响面极广。任何要求停两小时统一割接的方案,在实际环境里都排不进去。多厂商分治,密钥归属不清。系统由不同厂商建设,密码模块各用各的,密钥有的写在配置文件里、有的散落在各系统的数据库表里。密评问密钥由谁生成、由谁保管、多久轮换、谁能使用,往往没人能完整回答。云化之后,密码资源跟着虚机漂移。网络功能虚拟化后,网元不再固定在某台物理机上,密码资源如果还绑在某台机器的某个文件上,虚机一迁移就失效。这五点决定了运营商密评整改的基本姿势:不能靠推倒重来,只能靠沿链路分阶段替换 密码资源统一纳管。02 | 四层面逐层对照:要求、常见不符合项、整改动作把 GB/T 39786 的四个技术层面摊开,对照运营商环境里的典型情况:技术层面密评关注点运营商常见不符合项整改动作物理和环境安全门禁、视频等物理访问控制记录的完整性门禁记录、视频记录未做密码保护,可被删改对门禁与视频记录做完整性保护并留痕网络和通信安全通信双方身份真实性、数据机密性与完整性网管网与运维通道使用国际算法,或只做单向认证双向证书认证 国密算法加密通道设备和计算安全设备身份真实性、日志完整性、访问控制设备用默认口令,系统日志可被本地修改以证书标识设备身份,日志签名留痕应用和数据安全身份鉴别、访问控制、数据机密性、完整性、不可否认关键数据明文存储,签名仍用国际算法存储加密 算法替换 签名验签改造管理层面的四项(管理制度、人员管理、建设运行、应急处置)则主要落在文档与流程上:密钥管理制度是否成文、岗位是否分离、建设运行阶段是否同步考虑密码应用、密钥泄露与设备故障是否有应急预案。技术层面改得再好,管理规定和操作记录缺失,一样会在评估中被扣分。算法迁移到底在改什么很多人把国密改造理解成把 RSA 换成 SM2、把 AES 换成 SM4。这只说对了三分之一。真正的迁移是三件事一起动:【改造前】 应用 ──RSA / AES / SHA──► 数据与服务 密钥:写在配置文件、代码或数据库表里,谁都能看 【改造后】 应用 ──SM2 / SM4 / SM3──► 数据与服务 密钥:统一由密钥管理系统托管,明文不出硬件 密文:每份密文携带算法标识与密钥版本,可追溯、可轮换 迁移 算法替换 密钥管理方式重构 密文可追溯性建设第三件事最容易被忽略,却是密评现场最容易被问到的一条:你怎么证明这份数据是用合规算法加密的?如果密文里没有任何算法标识与密钥版本信息,运维只能靠记忆和文档回答,一旦经历几轮人员变动,这条链路就断了。让密文自己带着我是谁、用哪把密钥、哪个版本的信息,整改成果才是可核查的。03 | 先跑通:一次算法迁移的五个环节下面这段用国密算法把迁移过程中的五个关键环节跑一遍:算法替换的等价性、签名验签、密钥分层、算法留痕、轮换与过渡(演示用固定密钥与合成数据):# -*- coding: utf-8 -*- # 运营商密评整改演示:国密算法迁移 签名验签 密钥分层 算法留痕 轮换过渡 import json, hashlib from gmssl import sm2, sm3, sm4, func def sm3h(b: bytes) - str: return sm3.sm3_hash(func.bytes_to_list(b)) def digest(b: bytes) - bytes: return bytes.fromhex(sm3h(b)) def sm4_enc(k: bytes, b: bytes) - bytes: c sm4.CryptSM4(); c.set_key(k, sm4.SM4_ENCRYPT); return c.crypt_ecb(b) def sm4_dec(k: bytes, b: bytes) - bytes: c sm4.CryptSM4(); c.set_key(k, sm4.SM4_DECRYPT); return c.crypt_ecb(b) def pub_of(p: str) - str: return sm2.CryptSM2(private_keyp, public_key00)._kg(int(p, 16), sm2.default_ecc_table[g]) def line(t: str, ok: bool): print(f[{t}] {True if ok else False}) # 签名私钥(实际存于签名验签服务器/HSM 内,永不明文出硬件) SIGN_P 3c4d5e6f708192a3b4c5d6e7f8091a2b3c4d5e6f708192a3b4c5d6e7f8091a2b K_SIGN 20240601123456789abcdef0123456789abcdef0123456789abcdef012345678 SIGNER sm2.CryptSM2(private_keySIGN_P, public_keypub_of(SIGN_P)) VERIFIER sm2.CryptSM2(private_keyNone, public_keypub_of(SIGN_P)) # 验签方只持公钥 MSG json.dumps({acct: 1001, fee: 128.50, ts: 2026-09-14T09:00:00}, ensure_asciiFalse).encode(utf-8) print( 环节1:算法迁移(SM4/SM3 替换国际算法) ) DATA (计费话单|账号1001|金额128.50|时间2026-09-14T09:00:00).encode(utf-8) K_V1 bytes.fromhex(11 * 16) ct sm4_enc(K_V1, DATA) line(SM4 加密后可完整还原, sm4_dec(K_V1, ct) DATA) line(SM3 摘要长度固定 256 位, len(sm3h(DATA)) 64) line(同一数据的摘要在迁移后确实改变, sm3h(DATA) ! hashlib.sha256(DATA).hexdigest()) print( 环节2:签名验签(SM2 替换 RSA 签名) ) sig SIGNER.sign(digest(MSG), K_SIGN) line(SM2 签名验签通过, VERIFIER.verify(sig, digest(MSG))) line(报文被篡改 验签失败, not VERIFIER.verify(sig, digest(MSG.replace(b128.50, b9999.50)))) print( 环节3:密钥分层(根密钥保护工作密钥) ) KEK bytes.fromhex(22 * 16) # 根密钥,存于 HSM DEK bytes.fromhex(33 * 16) # 工作密钥,用于业务加密 dek_env sm4_enc(KEK, DEK) # 工作密钥以密文形态落库 line(工作密钥 以密文形态存储, dek_env ! DEK) line(有根密钥 可还原工作密钥, sm4_dec(KEK, dek_env) DEK) STRANGER bytes.fromhex(44 * 16) # 越权者手中的另一把密钥 line(无根密钥 解不出工作密钥, sm4_dec(STRANGER, dek_env) ! DEK) print( 环节4:算法标识与操作留痕 ) ENV {alg: SM4-ECB/PKCS7, keyId: telecom-bss-01, keyVersion: v1, ct: ct.hex()} line(密文信封带算法与密钥版本, ENV[alg].startswith(SM4) and ENV[keyVersion] v1) def audit(rec: dict, prev: str) - str: return sm3h((prev json.dumps(rec, ensure_asciiFalse, sort_keysTrue)).encode(utf-8)) a1 audit({op: encrypt, key: telecom-bss-01, v: v1}, 0 * 64) a2 audit({op: rotate, key: telecom-bss-01, v: v2}, a1) line(审计哈希链 校验通过, audit({op: rotate, key: telecom-bss-01, v: v2}, a1) a2) line(篡改审计记录 校验失败, audit({op: rotate, key: telecom-bss-01, v: v9}, a1) ! a2) print( 环节5:密钥轮换与双算法过渡 ) K_V2 bytes.fromhex(55 * 16) ct_v2 sm4_enc(K_V2, DATA) line(轮换后 新数据用 v2 加密, sm4_dec(K_V2, ct_v2) DATA) line(历史数据 仍可用归档 v1 解密, sm4_dec(K_V1, ct) DATA)跑起来,五个环节的结论如下: 环节1:算法迁移(SM4/SM3 替换国际算法) [SM4 加密后可完整还原] True [SM3 摘要长度固定 256 位] True [同一数据的摘要在迁移后确实改变] True 环节2:签名验签(SM2 替换 RSA 签名) [SM2 签名验签通过] True [报文被篡改 验签失败] True 环节3:密钥分层(根密钥保护工作密钥) [工作密钥 以密文形态存储] True [有根密钥 可还原工作密钥] True [无根密钥 解不出工作密钥] True 环节4:算法标识与操作留痕 [密文信封带算法与密钥版本] True [审计哈希链 校验通过] True [篡改审计记录 校验失败] True 环节5:密钥轮换与双算法过渡 [轮换后 新数据用 v2 加密] True [历史数据 仍可用归档 v1 解密] True逐段注解:环节 1 是迁移的等价性验证——换算法不能换来数据解不开。同一份数据用 SM4 加密后必须能完整还原;摘要长度固定 256 位,说明算法确实换成了 SM3;第三条对比的是迁移前后的摘要值不同,佐证算法真的换了,而不是只改了配置里的名字。环节 2 处理签名:签名方持有私钥、验签方只持公钥,报文被改动一个字符验签即失败——这是不可否认的技术底座,也是密评在应用和数据安全层面的关注点。环节 3 是密钥关系的核心:工作密钥不以明文形态存储,而是被根密钥加密后落库;有根密钥才能还原它,手里只有别的密钥的人拿到的是一堆解不开的字节。环节 4 回应如何证明这个问题:密文信封里写着算法标识与密钥版本,同时每一次密钥操作都进入哈希链——链上任何一条记录被改动,校验就会失败,这是审计留痕不可篡改的实现方式。环节 5 是迁移能否平稳落地的分水岭:新数据用新密钥,历史数据仍能用归档的旧密钥解开,两者并存,业务不中断。验证点(现场怎么演):取一条历史数据,分别用新旧密钥解密,应都能还原;改动一条审计记录后重新校验哈希链,应当报不一致;查看密文信封,应当能看到算法标识与密钥版本;把密钥存储位置找出来,应当落在密钥管理系统或硬件密码模块内,而不是应用配置文件里。双算法过渡:为什么不能一次切完整改最容易出事的做法,是定一个割接日,当天全量切换。真实环境里,新旧系统、上下游接口、历史数据三者不可能同步完成切换。可行的方式是设一个过渡期,让新旧算法并存一段时间:过渡期设计做法退出条件密文带算法标识密文自描述用哪个算法、哪个密钥版本全部密文完成识别与分类新旧并存解密解密侧同时支持新旧算法,按标识选择历史数据完成重加密或确认归档策略新数据只用新算法新增与变更的数据一律走国密覆盖全部写入路径旧算法只读旧算法降级为只能解密、不能加密无新增旧算法密文过渡期的关键是把切换从一次性动作变成可观测的过程:哪些数据还在用旧算法、还有多少、由谁负责,这些都能从密文的算法标识里统计出来。等旧算法的写入路径全部清零,再正式下线,而不是靠拍脑袋定日期。方案评估与系统评估:两次评估分别在评什么密评不是一次性动作,而是分两次:方案评估与系统评估。搞清楚两者的差别,整改排期才不会做反。维度方案评估系统评估评估对象密码应用方案的设计已建成系统的实际运行状态时间点系统建设或改造之前系统上线运行之后主要依据设计文档、密码应用方案现场配置、运行记录、测试结果典型问题方案未覆盖某个层面、算法选型不合规设计与实际不一致、密钥未按方案管理整改空间改动成本低,改设计即可改动成本高,涉及停机与业务系统实际项目里最常见的问题是跳过方案评估直接做系统评估:改造已经做完了,才发现在设计阶段就没把某个层面考虑进去,此时再补,代价是停机与返工。正确的顺序是先做方案设计与评估、再动手改造、最后做系统评估,把可以改的地方留在成本最低的阶段改。04 | 整改怎么排:三步法与优先级把整改当成一个项目来排,顺序大致是三步:第一步:差距评估(清点)。按四个技术层面逐项对照,产出一张清单:系统清单(有哪些系统涉及密码应用)、算法清单(每套系统用了什么算法、在哪些环节)、接口清单(哪些接口需要加密与签名)、密钥位置清单(密钥存在哪、谁管、是否轮换)。这一步是后面所有工作量的来源,也是密评方案评估阶段的核心交付。第二步:分阶段改造(替换)。优先级建议按这个顺序:对外接口与跨域通信 → 关键数据的存储加密 → 内部系统间通信 → 管理与审计类功能。理由很直接:越靠外、越接近数据出口的地方,风险越高、密评关注度也越高;先把这些改完,评估的大头就解决了。第三步:统一纳管与复测(收口)。把散落在各系统的密钥收拢到统一的密钥管理系统,建立轮换与审计机制,然后按层面复测并留存记录。收口这一步做不好,前面改造得再规范,密钥谁在管这个问题仍然答不上来。需要提醒的是,密码资源统一纳管不是再买一套系统,而是把已有的密码能力集中起来。运营商往往已经有硬件密码模块,缺的是密钥全生命周期怎么管、谁能用、用了几次、什么时候轮换这一层的统一视图。算法清点怎么做:一张表管到底差距评估里最耗时的是算法清点。与其按系统逐个翻文档,不如先定好一张表的字段,所有系统都往这张表里填:字段填什么用途系统名称涉及的每个系统界定改造范围使用环节传输 / 存储 / 签名 / 鉴别对应到具体技术层面现用算法国际算法或国密算法判断是否需要替换密钥位置配置文件 / 代码 / 数据库 / 密码模块判断密钥管理风险密钥管理方谁生成、谁保管、是否轮换对应管理层面要求改造优先级高 / 中 / 低排期依据这张表填完,改造工作量、优先级和风险点一目了然,也给评估提供了我们清楚自己的密码资产的直接证据。清单本身不是形式主义——被问到有多少套系统用到密码技术时,能当场拿出一张表,和临时翻文档,是两种完全不同的评估体验。责任分工也要写进方案:系统的密码应用通常涉及三方——业务系统的建设方(改应用)、密码产品与服务方(提供算法与密钥能力)、运营方(定策略与验收)。三者边界不清时,最典型的后果是密码改造没人认领:应用厂商说算法不是我们的事,密码厂商说业务系统我们进不去,最后卡在中间。一个整改样本:从三页不符合项到按期复测某省级运营商在一次密评中拿到三页不符合项,其中六成指向同一类问题:对外接口仍使用国际算法、密钥分散在各系统的配置文件里、审计记录存在本地且可被修改。项目组最初按逐系统替换排期,一算工期要跨两个季度,而且计费系统的停机窗口根本申请不下来。调整后的路径是先清点、再分层、后收口:先用两周做算法清点,把涉及密码应用的系统、接口、密钥位置列成表;再按对外接口 → 关键数据存储 → 内部系统间通信的优先级分批替换,替换期间新旧算法并存,历史数据保持可解;最后把散落在各系统的密钥收拢到统一的密钥管理系统,建立轮换机制与防篡改的审计留痕。结果:改造全程未申请停机窗口,业务没有中断;复测时,密钥由谁管理数据是否加密存储审计是否可追溯这三个高频问题都能当场给出记录。项目组自己的总结是:最难的不是换算法,而是先把自己手上有什么数清楚。05 | 避坑清单:8 条最容易踩的坑#坑后果怎么验证避开了1只做算法替换,不管密钥存哪密评问密钥谁管答不上来追问密钥存放位置与责任人2密钥写死在配置文件或代码里拿到主机即拿到密钥检索配置文件与代码,应无密钥明文3一次性全量割接无停机窗口,割接失败即业务中断检查是否有过渡期方案与回退预案4历史数据没考虑兼容切换后旧数据读不出来用旧密钥解密历史数据,应能还原5加密了但密文不带算法与版本标识无法统计改造进度、无法追溯查看密文结构,应含算法与密钥版本6审计日志本地存储、可被删改事后无法追溯尝试删改审计记录,应被发现7云化环境仍把密码资源绑在单机虚机迁移后密码服务不可用迁移一次虚机,验证密码能力是否跟随8只改技术不改管理制度与记录缺失,评估仍扣分对照管理层面四项,查制度与操作记录第 3 条是运营商场景里代价最高的一条:在不能停机的系统上做全量割接,等于把业务当赌注。凡是排期里出现某日凌晨统一切换的方案,都要问一句:切换失败的回退路径是什么、多久能退回来。06 | 合规视角:运营商要对上哪些要求GB/T 39786-2021 与密评:四技术层面 四管理层面逐项对照,评估按合规性、正确性、有效性三性判定;方案评估看设计,系统评估看落地,两者都过才算走完流程(GB/T 39786 的逐层落地框架详见 D6-1)。等保 2.0:电信行业核心系统普遍按等保三级及以上定级,密码应用是其明确的测评项;等保与密评的关注点不同但相互引用,整改时可以合并推进。关键信息基础设施保护要求:电信网络属关基范畴,运营者需履行相应的安全保护义务并对密码应用提出更高要求。电信行业主管部门的现行安全规范:运营商需按行业主管部门发布的数据安全与网络安全要求落实分类分级与安全评估,具体条目以现行有效文件为准。云化与虚拟化环境:网络功能虚拟化后,密码资源的使用者从固定设备变成会漂移的网元,密码服务需要以服务化方式提供,而不是绑定在某台机器上。07 | 落地答案:证书、密钥与算法迁移怎么承接把整改落到组件上,安当体系里对应 CAS-KMS、HSM 与 KSP 三件:CAS-KMS 密码应用系统:提供证书与密钥的统一管理,支撑设备与系统身份的证书签发、更新与吊销;固件与软件签名能力可解决设备和计算安全层面的身份与完整性要求。对应四层面里设备和计算安全这条线。HSM 硬件密码模块:密钥的生成与运算在硬件内完成,根密钥不以明文形态离开硬件;支持签名验签、加密解密等密码运算。对应避坑第 2 条与密钥分层要求。KSP 密钥管理系统:三级密钥体系、版本化轮换、归档与销毁,密钥操作全程留痕且记录防篡改(全生命周期做法详见 D6-2)。对应密钥统一纳管这一步。算法迁移的落点:新老算法并存解密、密文携带算法标识与密钥版本,是过渡期能平稳推进的技术前提;这套机制由密钥管理系统统一提供,而不是在每个业务系统里各写一套。一句话:这套组合要解决的是算法换成合规的、密钥收到硬件里、每份密文能说清自己是谁加密的——三件事同时成立,密评现场才有得答。08 | 验收清单与下一步检查项当场动作应得结果算法合规检查加密配置与密文算法标识全部为国密算法数据可还原加密后立即解密比对与原文一致签名可用篡改报文后验签验签失败密钥不入应用检索配置文件与代码无密钥明文密钥分层查看密钥存储结构工作密钥以密文形态存在密文可追溯查看密文结构含算法标识与密钥版本轮换不中断轮换后读取历史数据仍可解密审计防篡改改动一条审计记录哈希链校验失败过渡期方案查改造排期有并存期与退出条件趋势:密评整改正在从一次性过评走向持续合规——算法会更新、系统会上云、密钥需要轮换,一次整改的结果如果不能在日常运维中持续保持,下一轮评估又要重来。把密钥管理、算法标识与审计留痕做成常态能力,后面无论是扩容、上云还是迎接新一轮评估,都是叠加而不是返工。下一篇预告:算法与密钥的合规底座建好之后,我们把视角转向 5G 网络内部——核心网网元之间的认证与授权怎么做:网元凭什么互相信任、服务化接口调用如何授权、用户标识在空口上怎么保护。这是电信线里技术密度最高的一环。文章作者:安当加密-焱垚