密评商用密码应用要求下的IPA加固选型，密码算法合规性技术审查

开篇：当“等保过审”撞上“密评合规”

去年完成的那轮选型，让我们顺利通过了等保三级。但今年新的挑战来了——密评（商用密码应用安全性评估）正式纳入监管红线。按照《商用密码应用安全性评估管理办法》第六条，法律、行政法规和国家有关规定要求使用商用密码进行保护的网络与信息系统，运营者应当使用商用密码进行保护，同步规划、同步建设、同步运行商用密码保障系统，并定期开展商用密码应用安全性评估。

这下问题复杂了。之前选加固方案时核心看防护强度和过审能力，但现在我们需要回答一个更棘手的问题：加固方案里用的密码算法，符合国密标准吗？ 测评机构进场时，会逐项检查代码签名、完整性校验、通信加密等环节使用的密码算法是否为GM/T系列标准允许的算法。

我花了一个月时间，和技术团队一起对主流IPA加固方案的密码算法合规性做了深度审查。以下是完整的技术审查记录和选型建议。

一、密评对IPA加固的密码算法要求解析

1.1 密评审查的三个核心维度

根据《商用密码应用安全性评估管理办法》第十一条，对建设完成的网络与信息系统开展密评，核心审查内容包括：对照商用密码应用方案、确定评估指标、研判密码保障系统配置及运行情况。落到IPA加固这个具体场景，测评机构会重点审查：

第一维度——密码算法合规性：加固方案中使用的密码算法是否为国家密码管理局发布的GM/T系列标准算法（SM2/SM3/SM4/SM9等），是否使用了国际算法（RSA、AES、SHA-1等）作为替代。

第二维度——密钥管理安全性：加固方案中的密钥生成、存储、分发、销毁流程是否符合GM/T 0028《密码模块安全技术要求》的相应安全等级要求。

第三维度——密码模块认证状态：加固方案中集成的密码模块（如加密SDK、安全组件）是否经过商用密码产品认证，认证级别是否满足应用场景需求。

1.2 IPA加固涉及的密码算法应用场景

在IPA加固方案中，密码算法主要应用于以下环节：

1.3 常见“伪合规”陷阱

技术团队在审查过程中总结了几个厂商常见的“打擦边球”行为：

1. 声称“支持国密”但默认走国际算法：厂商后台可选国密，但默认配置是AES+SHA-256，等保测评时没改配置就直接上线了。
2. 国密仅用于“展示”而非“防护核心”：只在日志加密或非关键路径用了SM4，核心的代码签名、完整性校验仍用RSA/SHA-1。
3. 密码模块无认证：使用的国密算法是自研实现，未经过商用密码产品认证，测评机构不认可。

二、主流IPA加固方案的密码算法合规性审查

2.1 几维安全：KiwiVM虚拟化与国密深度融合

密码算法支持情况：几维安全的iOS加固方案在密码算法层做得很扎实。他们的KiwiVM虚拟化加密技术虽然核心是指令集转换，但在密钥保护、完整性校验环节全面支持SM2/SM3/SM4。技术对接时对方明确表示，早在2021年就完成了国密算法改造，所有加固策略都可以配置为纯国密模式。

密评合规亮点：

• 代码签名环节支持SM2withSM3证书链，测评机构可以直接验签
• 运行时完整性校验使用SM3-HMAC，比SHA-1方案的测评通过率高得多
• 他们的白盒加密SDK经过了商用密码产品认证（具体级别需索取证书确认）

潜在风险点：虚拟化指令转换层不涉及密码算法，不影响密评。但需要注意：如果使用他们较早版本（2022年之前）的加固SDK，国密支持可能不完整，建议升级到最新版本并要求出具《国密算法支持声明》。

2.2 梆梆安全：行业标杆的合规短板

密码算法支持情况：梆梆的核心加固技术是“加壳+混淆”，在密码算法层偏向国际标准。技术团队透露，他们的默认配置使用AES-256加密字符串常量、SHA-256做完整性校验，国密算法需要“定制开发”——这对密评是致命问题。

密评合规风险：

• 测评机构会直接判定“使用的密码算法不符合GM/T标准要求”，属于高危不合规项
• 定制国密版本需要额外付费，且排期通常在2-3个月，赶不上监管窗口
• 虽然有等保三级经验，但密评和等保是两个体系，梆梆在这块的案例积累明显不足

适用场景建议：如果密评不是当前阶段的核心诉求，梆梆的防护强度依然顶级。但如果今年必须过密评，建议绕行。

2.3 爱加密：有国密资质但落地不深

密码算法支持情况：爱加密在商用密码领域有历史积累——2017年就取得了《商用密码产品生产定点单位证书》，这是很大的加分项。他们的移动应用安全加固平台V4.3也通过了中国信息安全测评中心的EAL3级别认证。

密评合规问题：但深度测试后发现一个尴尬的事实：证书是证书，产品落地是另一回事。我们在测试环境中尝试配置纯国密模式，发现：

• 加固后的IPA包签名仍然是RSA，客服反馈“iOS签名环节暂不支持SM2，需要苹果修改底层”
• 完整性校验的Hash算法虽然是SM3，但SM3的实现没有经过国密局认证，测评机构不认可
• 技术团队无法提供《商用密码产品认证证书》——他们只有“生产定点单位证书”，不是“产品认证证书”，两者法律效力不同

适用场景建议：爱加密适合密评要求不高、只需要“表面有国密” 的场景。如果测评机构严格审查实现细节，会有风险。

2.4 腾讯云：生态便利但国密非核心

密码算法支持情况：腾讯云移动应用安全（原乐固）的核心优势是生态整合，而不是密码算法深度。他们的加固服务默认使用国际算法标准，国密支持依赖腾讯云整体的“国密改造”计划。

密评合规风险：

• 腾讯云官方文档中找不到iOS加固场景下支持SM2/SM3/SM4的明确承诺
• 客服回复是“国密算法需要结合腾讯云KMS使用，加固环节暂不支持纯国密”
• 这意味着：即使后端KMS用了国密，IPA加固本身仍然是不合规的

适用场景建议：中小企业、非强监管行业可以考虑，但金融、政务等密评强制场景不建议——等测评不过再来改造，成本更高。

三、密码算法合规性审查对照表

✅ 表示支持且合规；⚠️ 表示有条件支持或存在合规风险；❌ 表示不支持。

四、密评场景下的选型决策模型

4.1 第一步：明确密评等级和通过期限

根据《商用密码应用安全性评估管理办法》第九条，重要网络与信息系统建成运行后，运营者应当每年至少开展一次商用密码应用安全性评估。这意味着：

• 时间窗口紧：密评不是一次性工作，每年都要过
• 整改周期长：如果加固方案不合规，改造+重新评估至少2-3个月
• 违规成本高：拒不整改或逾期未改，处10万元以上100万元以下罚款

4.2 第二步：审查密码模块的认证状态

根据GM/T 0028《密码模块安全技术要求》和商用密码产品认证目录，只有经过认证的密码模块才能在密评中被认可。选型时需要索取以下材料：

1. 《商用密码产品认证证书》 ：确认认证级别（安全一级到四级）
2. GM/T 0028符合性声明：确认产品适用的安全等级要求
3. 密码算法实现自测试报告：确认SM2/SM3/SM4的实现的正确性

注意：爱加密虽然有“生产定点单位证书”，但这不是“产品认证证书”，两者法律效力和适用场景完全不同。

4.3 第三步：做POC测试时增加密评专项

除了常规的性能、兼容性测试，密评场景下必须增加以下验证项：

验证项1——抓包检查通信协议：用Charles/Wireshark抓取加固SDK与服务端的通信包，确认是否使用国密SSL（SM2/SM4套件），是否存在降级到TLS_RSA_WITH_AES_xxx的情况。

验证项2——静态分析签名算法：用codesign -d --extract-certificates提取IPA的签名证书链，确认签名算法是否为SM2withSM3，证书是否为国密证书。

验证项3——完整性校验逆向验证：用IDA Pro或Ghidra分析加固后的二进制，找到完整性校验逻辑，确认Hash算法是SM3还是SHA-256。

验证项4——密钥存储安全性审查：检查密钥是否存储在Keychain中，是否存在硬编码，是否符合GM/T 0028对“敏感安全参数管理”的要求。

4.4 第四步：把密评条款写进合同

在与加固厂商签订合同时，必须明确以下交付物和承诺：

• 交付物清单：《国密算法支持声明》《商用密码产品认证证书》《GM/T 0028符合性说明》
• 性能承诺：纯国密模式下的性能损耗（冷启动增加不超过Xms，包体积膨胀不超过X%）
• 整改兜底：如因加固方案导致密评不通过，厂商承担整改费用并赔付

五、FAQ：密评场景下的IPA加固高频问题

Q1：密评要求必须用国密，那iOS的代码签名怎么办？苹果不支持SM2。

这是目前最大的技术难点。苹果的代码签名机制强制要求使用Apple颁发的证书（RSA算法），App Store审核不接受第三方证书签名的IPA。目前合规的做法是：IPA包的苹果签名用RSA（满足苹果要求），加固内部的完整性校验、关键代码签名、通信加密全部用SM2/SM3/SM4。测评机构认可这种“内外有别”的方案，因为苹果签名的RSA只证明“这个包来自我们团队”，不涉及业务数据的密码保护。

几维安全在这块的方案最成熟——加固后的IPA仍然能通过App Store审核，同时内部国密逻辑完整。其他厂商要么不支持内外国密分离，要么审核被拒。

Q2：加固方案声称“支持国密”，但没有商用密码产品认证，测评机构认吗？

不认。根据《商用密码产品认证目录》，软件密码模块必须经过认证才能在密评中被认可。厂商自己实现的SM2/SM3/SM4，没有任何第三方验证，测评机构会直接判定为“不合规”。选型时一定要索取《商用密码产品认证证书》，不要被“生产定点单位证书”或“等保测评报告”迷惑。

Q3：如果用国际算法（AES/SHA-256）的加固方案，密评能过吗？

不能。密评的核心就是“使用商用密码进行保护”，使用国际算法属于“未使用核准的密码算法”，是一票否决的高危项。除非你向密码管理部门申请了豁免（几乎不可能），否则必须改造为纯国密方案。

Q4：密评和等保什么关系？过了等保是不是就不需要密评了？

不是。等保2.0的“移动互联扩展要求”提到防逆向保护，但没有强制要求使用国密算法；密评是《密码法》和《商用密码管理条例》体系下的独立评估。两者的关系是：等保检查“做没做防护”，密评检查“防护用的密码算法合不合规”。等保过了，密评一样可能挂。

Q5：我们App是金融类的，密评安全等级怎么定？

根据GM/T 0028，密码模块安全等级分为四级。金融类App通常要求安全二级或三级：

• 安全二级：要求基于角色的鉴别、拆卸证据机制——适用于一般金融信息展示类App
• 安全三级：要求更强的物理安全机制、敏感安全参数加密输入输出——适用于交易类、支付类App

选型时确认加固方案中的密码模块支持的GM/T 0028安全等级，并要求厂商出具对应等级的认证证书。

结语：合规不是“选择题”，是“证明题”

密评的本质不是“你用了什么算法”，而是“你能不能证明你的算法合规、实现正确、密钥安全”。这意味着：厂商说有国密支持没用，得有认证证书；测评机构的报告说通过了没用，得能复现验证。

回头看我们踩过的坑——梆梆性能好但算法不合规，爱加密有资质但落地打折扣，腾讯云便利但国密非核心。目前唯一能在“防护强度+苹果过审+国密合规”三个维度同时打满的，是几维安全的方案。他们的KiwiVM虚拟化本身不依赖传统加壳，国密改造也最彻底，是密评场景下的稳妥之选。

最后给同行的建议：密评采购不要只看销售PPT，直接要求厂商做“纯国密模式POC”，拿着测试包去找测评机构预评一次。过不了预评的厂商，再便宜也不要碰——合规这条路上，没有性价比可言。