合规实践|开放平台的多平台 SDK 方案-华夏银行

一、合规概况介绍

该技术方案主要体现了数据传输合规，《个人金融信息保护技术规范》要求金融机构在使用公共网络传输时需对 C2、C3 类信息进行加密传输。该方案采用在管理台配置的方式，设定各平台数据传输所使用的加解密技术，包括对称加密和非对称加密的国密算法等，并将各平台数据传输的加解密方式进行封装进 SDK，统一管控了加解密技术标准，并简化了日常项目开发的周期和成本，是以数据传输合规较成熟的落地实践方案。

二、背景

开放平台多平台 SDK 方案为接入方提供了封装的认证授权算法、加解密算法、国密算法支持、证书管理、token 管理、服务调用、结果解析等功能。通过提供支持服务器端、移动端、H5 端，多平台的 SDK 方案，既实现开放平台的安全接入、数据保护的统一管控的标准化方案，又大大简化了接入方的开发周期和成本，实现了对业务的快速相应和强力支撑。

三、方案

该方案支持多种加密算法包括多种国密算法，都可以通过平台进行配置，以下示例以常见的算法 AES256 等为例。

（1）Java SDK

Java SDK 封装的应用方服务器与服务提供方服务器直接交互的模式下，流程图如下：

应用服务器使用摘要算法对 APPID、随机数、设备标识等进行合并并生成摘要，使用密钥对摘要做签名；然后再对报文内容、签名、随机工作密钥等进行AES256 加密，生成数据密文；再使用非对称加密算法对随机密钥进行加密，生成密钥密文；将数据密文和密钥密文通过 HTTPS 方式发送到服务提供方。

服务提供方使用私钥解密密钥密文，获取随机密钥；然后随机密钥对数据密文进行AES256 解密， 并对签名字段做验签运算；成功后，生成 token。使用服务方私钥对token 和随机数进行签名运算，生成签名，并使用随机密钥对 token 和签名进行加密，将密文返回应用方。应用方使用随机密钥解密密文，然后使用 token 和随机数进行验签，成功后后续交易，在有效期内，基于 token 做安全通讯。

（2）移动端 SDK

移动端主要指分为 Android 和 iOS 的场景，使用移动端 SDK，封装的相关流程如下：

移动端 SDK 对 APPID、随机数、设备标识等进行摘要计算，并使用随机密钥对数据摘要进行 AES256 加密，生成数据密文；然后对随机密钥进行非对称加密，生成密钥密文；将数据密文和密钥密文以 HTTPS 方式发送到应用方服务器。

应用方服务器端对密钥密文进行解密，获取随机密钥；然后使用随机密钥对数据密文进行解密，获取数据摘要；然后再对数据摘要进行签名，并对签名进行AES256 加密，将签名密文返回给移动端 SDK。

移动端 SDK 对签名密文解密，获取签名；然后使用新的随机密钥对APPID、随机数、设备标识、随机工作密钥、签名等进行加密，生产密文数据；并对随机密钥进行非对称加密，生成密文密钥；将密文数据和密文密钥通过 HTTPS 的方式发送到服务提供方。

服务提供方对密文密钥进行解密，获取随机密钥；使用随机密钥解密密文数据，获取明文；然后使用 APPID、随机数、设备标识进行摘要运算，最后对摘要和签名进行验签运算；验签成功后生成 token。将 token 和随机数，进行签名，然后用随机密钥对token 和签名进行 AES256 加密，将密文返回移动端 SDK。 

移动端 SDK 使用随机密钥进行解密，并对随机数和 token 进行验签；成功后，则获取的 token 有效。后续所有交易，在有效期内，基于 token 来做安全通讯。

（3）JS SDK 

JS SDK 是基于浏览器客户端请求，H5 客户端不具备保存密钥的条件，流程图如下：

JS SDK 以 HTTPS 的方式传送设备标识到应用方服务器。

应用方服务器使用对 APPID、随机数、设备标识进行签名，然后使用随机密钥将APPID、随机数、设备标识、签名进行 AES256 加密，生成数据密文；并对随机密钥进行非对称加密，生成密钥密文；将数据密文和密钥密文以 HTTPS 方式发送到服务提供方。

服务提供方解密密钥密文，获取随机密钥；然后使用随机密钥对数据密文进行AES256 解密，获取数据明文；然后对 APPID、随机数、设备标识进行验签，成功后，生成 token。然后对 token 和随机数进行签名；将签名和 token 使用随机密钥进行AES256 加密，生成密文；返回给应用方服务器。

应用方服务器解密获得对 token 和随机数，并进行验签，通过后，证明token 安全可用，将 token 返回给 JS SDK。

JS SDK 收到 token 后，在有效期内，基于 token 做有安全通讯。

四、数据保护及合规情况梳理

该方案主要关注于数据传输阶段的数据安全的保护，通过上述的算法进行加密传输。

并且针对 SDK 本身的安全，进行规范化管理。确保 SDK 自身的安全性，SDK的使用模式导致其自身的安全问题会产生放大效应。需要在 SDK 的开发、使用、监测等全生命周期执行严格的安全标准，减少安全漏洞的产生，及时发现安全漏洞并立即修补，提升 SDK 的安全性。

（1）开发阶段

安全检测：首先需要参考安全基线，对外发 SDK 展开自动化测评和渗透测试，解决SDK 所面临的安全问题，如泄漏用户数据、自身存在安全漏洞、业务逻辑不完整、攻击面过多、第三方组件漏洞、不符合等保规范等。

（2）发布前

安全保护：外发的 SDK 可能会包含登录、支付、统计、监测、通讯、推送、验证等众多业务逻辑，可能被外部逆向破解，以分析、调试其中的业务逻辑。

因此需要比对安全检测的结果，对 SDK 实施安全加固等主动防护操作，保护其核心算法、密钥、后台 API 接口、业务逻辑等关键内容，增强 SDK 安全性、降低被攻击的可能。

（3）对外发布

安全管理：对需要集成调用的 SDK 登记应用包名、签名等信息，在SDK 调用过程中验证宿主 App 的包名、签名等信息，防止被非授权第三方非法集成和调用等问题的发生。同时通过接入管理，对存在重大安全隐患（安全威胁大、应用安全防护措施低、用户投诉多等）的 App 进行接入封禁，确保 SDK 的接入安全。

（4）运行过程中

运行监控：SDK 的运行环境具有不可控性，因此需要对 SDK 实施主动安全监控，实现对 SDK 威胁的感知、对宿主应用所在环境威胁的感知（如 SDK 的宿主App运行环境是否真实、安全；是否存在恶意攻击 SDK、通过 SDK 窃取敏感信息、扰乱正常的业务交易等风险问题），在风险发生时或发生前做到预警、阻断，在风险发生后可以进行追溯。

（5）面临风险时

安全响应：对 SDK 运行过程中遇到的各种安全威胁，需要借助SDK 威胁态势感知检测、SDK 渠道监测结果，分析各种安全威胁，通过业务控制、技术对抗及法律方法等，对安全风险及时的进行响应处理。

SDK 对个人信息及数据的收集和处理应符合国家法律、标准的规定。SDK 在嵌入APP 应用使用后，APP 以间接方式访问开放银行系统的接口服务，API 安全的内容也适用于 SDK 安全。

信息来源：中国银联技术管理委员会