非银支付国密算法改造探索

 

一、改造背景

早在2012年，工信部和公安部通告了RSA1024算法被破解的风险，为保证金融行业各基础信息系统安全，中国人民银行要求各银行对网上银行等信息系统进行国产密码算法改造。2012年，中国人民银行向多家银行发布了《银行业国产密码应用总体规划》及《总体方案》征求意见稿；同年，人民银行转发了发改委的试点通知并建议网银用户5000万以上的银行参与网银系统国密算法改造试点项目。2014年国务院转发了多部门联合制定的《金融领域密码应用指导意见》（国办发【2014】6号），要求各金融机构5年内完成在网上银行、移动支付、网上证券等重点领域国产密码算法的全面应用。

经过几年的推进，银行业基本完成国密的改造，金融其他行业陆续进行中，近期人行又发布了相关通知，要求非银支付机构2022年10月完成相关国密改造，作者所在公司为非银支付行业，已经开始了完成部分国密改造项，记录此文作为探讨分享，不足指出请多多指教。

 

二、改造要求

人行发布的改造项，强制项为必须改造完成，否则造成监管合规问题，会给公司带来不可预期的后果，改造要求如下：

2.1、已完成：数据原发抗抵赖和数据接收的抗抵赖项，即交易抗抵赖

改造方案架构图：

改造业务调用流程：

改造后的效果（国密SM2算法）

国密改造是个漫长且对业务侵入较大的工作，需要公司多个部门配合，可以由风险与合规部门牵头负责与监管部门沟通，负责上报进度和合规事项确认，架构组和安全团队对技术方案评估评审，讨论出既合规又对业务影响较小的方案，以及后续推进工作，当然也需要厂商的支持。

2.2、敏感信息国密算法存储，即内部系统存储机密性项，作者公司目前正在改造。

如果说CA证书国密改造难度是个小儿科，那敏感信息国密算法存储改造难度就是个大boss，刚开始我以为国密存储改造只要使用国密算法加密完成改造不就完了？事实证明太年轻，由于之前推动完成了公司敏感信息存储项目，所以我单纯的认为国密改造无非就是换个加密算法嘛，于是兴高采烈的拉上架构组开会商讨，让架构组开发一套支持国密算法的sdk，架构组很快完成了，那接下来推动各业务整改呗。按照惯例，在开始推动之前，要找检测机构确认我们的方案是否可行，不能上去就是干啊，于是向监管老师介绍方案，哪知方案还没介绍完，老师得知是软加密的方式，直接当头一棒说你们这方案肯定不行，说数据加密一定要通过硬件加密机和管理秘钥。

因为要用硬加密的方式，按照监管老师的说法，数据加密的动作也要在加密机里完成，这对解密机性能要求和高可用就非常高，因为一个QPS过来，如果牵涉数据查询，关联查询，数据加密，都是对加密机的考验，虽说都是C3/C4的数据，这个量也是很大的，更不用说活动的峰值了。

通过与各个业务、架构、厂商的讨论，认为采用硬件加密机进行数据加密动作风险太高，于是又反复向监管老师确认，能否加密机只做秘钥的管理，加密的动作在应用本地完成。通过多番多方确认，确定可行。

于是出现了以下方案，架构图如下：

到此算是完成了架构方案的设计，部署加密机，封装服务，完成整个项目的30%，接下来推动业务整改，真正的挑战才刚开始。

首先、整改要明确整改范围，一般为监管上报的核心支付相关系统，建议可由风险合规部门确认，其次，要确认有哪些敏感加密字段，大家可以参考《金融数据安全分级指南》敏感数据定义去梳理公司的敏感数据，由于作者之前作为owner推动整改过加密项目，已经梳理过各个系统的敏感字段，所以这部分工作轻松完成。接下来，就是推动各个业务排期改造，此过程最消耗精力，因为各个业务数据调用上下游依赖程度不同，有的直接通过数据库调用，如大数据，TIDB，需要制定不同的推动方案进行区别推动，目前进行中。

 

三、一些感悟

金融作为受强监管的行业，各种合规的改造项目不得不进行，这其中有容易的，也有很难改造的，比如像国密改造项目对业务侵入大，涉及部门多，周期长，改造难度阻力非常大。不过，随着数据安全法，个人信息保护法，以及关基认定的实施，还有滴滴事件的发生，相信各个公司已经越来越重视数据安全，合规安全，大多公司领导的已经改变了重业务，轻安全的认识，使得项目的推动也变得顺利，按时完成。除此同时，建议时刻保持与监管检测机构的紧密沟通，因为最终改造项是否合规，能否通过，由他们进行测评和判定，切勿闭门造车，以免重复劳动。