金融科技产品 相关标准笔记

JRT 0196 多方安全计算金融应用技术规范笔记

多方安全计算 secure multi-party computation；MPC一种基于多方数据协同完成计算目标，实现除计算结果及其可推导出的信息之外不泄漏各方隐私数据的密码技术。

注：多方安全计算常采用的技术有混淆电路、不经意传输、秘密分享、同态加密等。

计算因子 computation factor：基于多方安全计算输入数据产生的数据。

注：包括输入因子、输出因子和中间因子

元数据 metadata：定义和描述其他数据的数据。

安全参数 security parameter：用以衡量多方安全计算协议安全强度或破解难度的一组参数。

注：MPC安全参数主要包括不诚实门限、统计安全参数、计算安全参数。不诚实门限是多方安全计算协议允许合谋的不诚实参与方的最大值，当该值小于参与方数量的一半时称协议是诚实大多数的，否则称协议是不诚实大多数的；统计安全参数是一个整数l,根据输入数据产生的计算因子的概率分布，与不知道输入数据随机模拟的计算因子的概率分布，两者统计上不可区分（统计距离不高于2 -l）；计算安全参数是一个整数k，表示多项式时间攻击者破解多方安全计算协议的计算复杂度。

0.概述

参与方

任务发起方：触发MPC任务，在任务执行前完成任务资源配置，并对资源到位情况进行核实。

调度方：配置计算任务，管理和协调其他参与方执行任务。

算法提供方：为MPC提供计算逻辑和算法参数，当算法参数有保护要求时，应将该算法参数视为隐私数据，该算法提供方视为数据提供方。

数据提供方：为MPC提供所需隐私数据，通过MPC数据输入处理将隐私数据转化为输入因子并发送给计算方。一个MPC计算任务中数据提供方的数量大于等于2。

计算方：为MPC提供算力支持，计算方接收数据提供方的输入因子并进行计算，计算结束后将输出因子发送给结果使用方。一个MPC计算任务中计算方的数量应大于等于2，并不能由同一实体承担多个计算方角色。

结果使用方：接收MPC计算结果，一个MPC计算任务的结果使用方可以有1个或多个。

工作时序

a) 任务创建：

1）任务发起方配置、核实MPC任务计算所需资源，发起计算任务。

2）数据提供方对所有的数据使用进行授权，任务发起方和数据提供方为同一实体的情况除外。数据提供方可委托调度方对数据进行使用授权，也可在任务创建前对数据进行预授权。数据使用授权和后续任务分配阶段可合并执行。

b) 任务分配：

1）调度方验证任务请求信息的合法性，包括身份验证和数据授权的合法性。

2）验证通过后生成任务配置信息，发送给数据提供方、计算方和结果使用方。

3）数据提供方、计算方和结果使用方收到任务配置信息后进行验证。

4）各参与方保存收发的任务配置信息。

c) 数据输入：

1）数据提供方从数据源读取数据并生成输入因子，通过安全通道发送给指定计算方。

2）数据提供方保存任务配置信息，并对发送的输入因子进行存证。

d) 任务计算：

1）计算节点接收各数据提供方的输入因子，按照MPC协议进行协同计算生成输出因子。

2）将输出因子发送至结果使用方。

e) 结果解析：

1）结果使用方对输出因子进行解析得到计算结果。

2）对结果进行存证。

应用目标

数据隐私性、数据合法性、计算结果正确性、计算性能可接受性

总体要求

基础要求包括数据输入、算法输入、协同计算、结果输出及调度管理等要求，分别主要针对数据提供方、算法提供方、计算方、结果使用方、调度方。

安全要求包括协议安全、隐私数据安全、认证授权、密码安全、通信安全、存证与日志等要求。

性能要求对MPC金融应用提出了计算延时、吞吐量、计算精度等性能指标要求。

1.基础要求

1. 数据输入：

   1. 数据输入转化
   2. 数据源接入
   3. 数据集管理元数据管理
   4. 数据预处理
   5. 取消授权
   6. 存证

2. 算法输入

   1. 算法逻辑类型
   2. 算法输入方式
   3. 算法逻辑管理

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DDCZQCj9-1691111992060)(assets/image-20230718172515901-16897295817411.png)]

3. 协同计算

4. 结果输出

5. 调度管理

   1. 参与方管理
   2. 任务配置
   3. 任务执行

2.安全要求

1. 协议安全

   1. 基本安全要求
   2. 安全模型
   3. 安全参数

   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nBFTveSS-1691111992061)(assets/image-20230718172454443.png)]

2. 隐私数据安全

   1. 应用过程隐私安全要求
   2. 其他参与方安全要求
   3. 隐私数据获取安全要求
   4. 计算结果隐私安全要求
   5. 防单点故障扩散要求
   6. 模型隐私安全要求
   7. 算法逻辑安全要求
   8. 个人金融信息保护

3. 认证授权

   1. 身份认证要求
   2. 数据使用授权要求

4. 密码安全：国密

   1. 密码算法
   2. 密钥长度
   3. 密钥管理
   4. 密码产品

5. 通信安全：国密

   1. 通信双方的身份认证和密钥交换
   2. 安全通信通道的建立
   3. 通信数据的机密性和完整性保护和验证
   4. 通信数据被篡改后的识别和异常处理机制
   5. 通信延时、中断等异常情况的处理与恢复机制
   6. 重新获取信息的能力

6. 存证与日志

   1. 用户日志保存要求
   2. 存证要求
   3. 日志及存证审计要求
   4. 存证及溯源要求

3.性能要求

1. 资金实时类计算性能
2. 资金非实时类计算性能
3. 非资金实时类计算性能
4. 非资金非实时类计算性能
5. 总体处理时延

4.主要应用方向

1. 隐匿查询：PIR
2. 隐私求交
3. 联合统计
4. 联合建模：即联邦学习

---

JRT 185 商业银行应用程序接口安全管理规范笔记

api有内部（银行内部开发使用）、企业定制、外部（外部合作伙伴），本标准特指外部API

0.应用程序接口的类型与安全级别

接口类型

服务端对服务端集成方式 移动终端对服务端集成方式

两种实现方式，直接调用API和使用银行提供SDK间接访问API

安全级别

分两级，A2-A1

A2：资金交易与账户信息查询应用类，此类金融产品和服务与用户个体直接关联，实施高等级安全保护强度

A1：金融产品和服务信息查询应用类，此类金融产品和服务与用户个体并无直接关联，实施通用的安全保护强度

应用程序接口统一标识码

商业银行应用程序接口统一识别码（U_API_ID）编码格式为 ASCII 码，长度为 24 个字符

固定位	机构代码	接口类型	服务类别	顺序码	保留位
2 个字符	6 个字符	2 个字符	6 个字符	6 个字符	2 个字符

1.安全设计

1. 设计基本要求

   国密、安全编码、安全编码培训开发、第三方应用组件更新、代码专项审计、版本控制规范、银行向应用

2. 接口安全设计

   1. 身份认证安全
      1. 接口身份认证：App_ID+App_Secret / 数字证书 / 公私钥对 任意一个，A2时要使用后两种双向身份认证
      2. 用户身份认证：A2至少双因子
   2. 接口交互安全：连通有效性、完整性（A2加上数字签名保证不可抵赖）、机密性、结果不保存本地、结束后清除敏感信息

3. 服务安全设计

   1. 授权管理：最小授权
   2. 攻击防护：常见防护、SDK静态逆向防护、动态调试防护（宜选）
   3. 安全监控：完整记录接口访问情况；接口访问日志（交易流水号、应用唯一标识、接口唯一标识、调用耗时、时间戳、返回结果）；个人金融信息不应在应用方接口日志中记录
   4. 密钥管理：加密和签名使用不同密钥（宜选）、不以编码方式存储私钥在代码中、不存储在本地配置文件中、定期更新密钥

2.安全部署

商业银行应用程序接口网络部署示意图

商业银行应用程序接口服务层应部署流量控制、监控分析、认证鉴权、报文交换、服务组合等服务，

其中认证鉴权、报文交换、服务组合等服务也可部署在银行业务层。

商业银行应用程序接口服务层与银行业务层之间应部署如防火墙等具备相关访问控制、入侵防范安全防护能力的网络安全防护措施。

应用方服务器应部署在应用方互联网接入安全防护设备之后的逻辑隔离区域，通过互联网、移动互联网网络访问商业银行应用程序接口相关应用服务。

二级等保以上

3.安全集成

1. 应用方核准
   1. 应用方准入：不通过接口变相开展跨机构清算业务
   2. 应用方身份核验：合规性核验
2. 接入安全控制
   1. 身份认证：
      1. 身份声明：应用方唯一标识App_ID与鉴别密文App_Secret、数字证书
      2. 身份认证：App_ID+App_Secret / 数字证书 / 公私钥对 任意一个，A2时要使用后两种双向身份认证、连接时长限制、恶意连接主动处理
   2. 安全传输：A1用MAC、A2用数字签名、使用TLS1.2以上通信（宜选）
3. 运行安全
   1. 用户身份认证：本地不留敏感信息、认证在银行完成、会话有效期
   2. 权限控制：最小授权、调用接口明示同意且内容包含授权有效期、应为用户提供关闭接口申请渠道
   3. 数据安全：完整性、机密性、抗抵赖性A2、数据删除和销毁、建立数据备份管理和应急灾备
   4. 应用方安全能力：等保、安全设计、日志保存不少于半年
   5. 应用方接口集成
4. 应用方退出

4.安全运维

1. 安全监测
   1. 运维监测：交易系统日志不少于1年
   2. 异常监测
2. 风险控制
   1. 服务风险控制
   2. 交易流程控制
   3. 交易风险监控
3. 变更控制：商业银行变更接口应告知应用方，制定变更方案和应急预案；应用方接口使用发生重大变更应告知银行，银行制定变更方案、应急预案、风险评估；
4. 运维巡检
5. 事件处理

5.服务终止与系统下线

• 提前告知相关方，向相关平台提交有关接口统一识别码注销申请；
• 服务终止后遗留问题达成一致，明确责任
• 下线前明示服务终止
• 数据归档处理

6.安全管理

1. 管理制度

   1. 接口实行SLC纳入银行管理体系
   2. 接口采用统一识别码并注册登记
   3. 建立信息公告制度，发布接口内容
   4. 建立接口SLC和有效性验证
   5. 提供开发手册

2. 应用安全责任

   明示责任、最少够用原则收集、应用方不得以任何方式把接口得到的金融服务能力和数据转移、共享或分包；

3. 安全审计

   商业银行：完整记录接口访问日志、最少够用适当保留信息、日志完整性保护

   应用方：接口日志、完整性保护、提供查询应用方用户商业银行应用程序接口相关登录、授权、交易等历史操作日志功能

---

JRT 184 193 金融分布式账本 区块链 笔记

完整性、保密性、不可链接性、一致性、终局性、原子性、去中心化

基础硬件

1. 基本要求：等保三级物理和网络要求

2. 物理安全

   1. 场地安全：上云数据中心位于高安全区、共识节点或记账节点位于中国（宜选）
   2. 硬件设备：监控
   3. 节点部署安全：冗余
   4. 硬件加密设备安全：国密

3. 网络安全

   1. 网络架构安全：较大局部聚集系数
   2. 通信传输安全：安全传输通道、防护措施、密码技术、VPN或网络访问控制（可选）

基础软件

1. 基本要求：等保三级 主机安全、应用安全、数据安全及备份恢复相关要求
2. 账本结构：哈希嵌套防篡改性、数据校验功能
3. 共识模块：数据一致性
4. 分布式组网：节点物理分离、网络无中心节点、任意节点至少与两个节点连接、各节点独立存储
5. 数据存储：账本数据按类别独立存储 管理 操作、敏感信息加密存储且有访问控制、数据库
6. 智能合约：可信计算环境（宜选）、运行时有安全保护、数据向前兼容、运行机制向前后兼容（宜）、智能合约审核
7. 接口设计：扩展性和兼容性
8. 数据传输：国密
9. 时间同步：经过认证的中心化时间同步源（可选）
10. 操作系统：不同操作系统不同软件，三种以上操作系统或版本（宜）

密码算法

1. 基本要求
2. 保密性：通信过程随机数填充、敏感数据密码技术加密
3. 完整性：
4. 真实性：用非对称加密、动态口令或数字签名
5. 不可否认性：数字签名（可）
6. 随机性
7. 密钥管理：秘密分享将密钥分别存储或传输（可）

节点通信

1. 基本要求：节点授权准入
2. 节点身份验证
3. 通信完整性：国密
4. 通信保密性：建立连接前使用国密密钥交换技术并双向认证、使用工作密钥对报文加密、使用国密建立安全通信通道

账本数据

1. 完整性
2. 一致性
3. 保密性：
4. 有效性
5. 账本数据冗余
6. 访问与使用
7. 安全审计：账本数据提供安全审计、数据变更提供审计，包括失败

共识协议

1. 基本要求于：工作量证明、权益证明、授权股权证明、拜占庭容错等
2. 合法性
3. 正确性：协议算法公开、测试通过形式化验证或代码审计（宜）、可信节点提供可信计算环境
4. 终局性：有限时间内达成一致
5. 一致性
6. 不可伪造性
7. 可用性：有一定主动防御能力
8. 健壮性
9. 容错性
10. 可监管性：共识历史可审计可监管
11. 低延迟
12. 激励相容
13. 可拓展性

智能合约

1. 基本要求：支持图灵完备智能合约和非图灵
2. 版本控制：源代码、配置文件、部署或升级、智能合约升级要在分布式账本中保存前一版本、交易明确调用合约版本
3. 访问控制：限制错误智能合约的感染、控制智能合约对外部环境访问、提供隔离执行环境（宜）
4. 复杂度限制：代码复杂度（宜）
5. 原子性：支持回滚
6. 一致性
7. 安全审计：智能合约设计与业务逻辑安全、源代码安全审计、编译环境审计及相关的应急响应机制等
8. 生命周期管理：部署、冻结、升级、废止、迁移、原始解析
9. 攻击防范
10. 安全验证：源码和字节码安全扫描、自动生成智能合约模板、形式化验证（宜）

身份管理

1. 基本要求

2. 身份定义

3. 身份注册

4. 身份核实：前台自愿、后台实名

5. 账户管理

   1. 账户创建：普通用户、管理员、其他特定权限
   2. 账户授权
   3. 凭证签发
   4. 账户冻结和解冻
   5. 账户锁定和恢复：锁定窗口期
   6. 账户注销：永久保留身份标识

6. 凭证生命周期管理

   1. 基本要求
   2. 产生
   3. 发放
   4. 存储：存储方法评估（宜）
   5. 流转
   6. 验证
   7. 更新
   8. 终止

7. 身份鉴别

8. 节点标识管理

9. 身份更新和撤销

10. 身份信息安全性

    1. 基本要求
    2. 密钥安全性
    3. 安全加密

11. 身份监管审计要求

    1. 监管：采用共识策略（宜）
    2. 审计

隐私保护

1. 隐私保护原则

2. 隐私保护内容

3. 隐私保护策略

   1. 概述
   2. 信息公开可验证
   3. 信息加密可验证
   4. 信息由交易验证节点验证

4. 隐私保护技术要求

5. 隐私保护监控与审计

监管支撑

1. 基本要求
2. 系统监管
3. 信息管理
4. 事件处理
5. 交易干预
6. 智能合约监管

运维要求

1. 基本要求
2. 设备管理
3. 节点监控
4. 节点版本升级
5. 漏洞修复
6. 备份与恢复
7. 应急预案管理
8. 权限管理
9. 议案机制

治理机制

1. 基本要求
2. 治理结构
   1. 组织架构
   2. 管理职责
3. 管控重点
   1. 节点管理：三种或以上版本
   2. 干预机制

区块链分层

1. 网络层：网络层是区块链的基础架构，它负责节点之间的通信和数据传输。在网络层，常见的技术包括点对点网络通信、TCP/IP协议、UDP协议等。节点之间通过这些技术建立连接，进行区块和交易的传播。
2. 共识层：共识层确保网络中的所有节点就区块链的状态达成一致。常见的共识算法包括工作量证明（Proof of Work，PoW）、权益证明（Proof of Stake，PoS）、权威证明（Proof of Authority，PoA）等。这些算法通过不同的方式选择出生成区块的节点，并确保区块链的安全性和可靠性。拜占庭将军协议是一种容错算法，可以应对节点之间可能存在的恶意行为或故障。它通过节点之间的相互通信和消息传递来达成共识，确保网络中的大多数节点能够就区块链的状态达成一致。
3. 数据层：数据层负责存储和管理区块链中的数据。区块链使用分布式数据库来存储交易记录和区块数据。常见的技术包括分布式哈希表（Distributed Hash Table，DHT）、默克尔树（Merkle Tree）等。这些技术可以确保数据的完整性和可验证性。
4. 智能合约层：智能合约层是区块链的核心功能之一，它允许开发者编写和执行自动化的合约。智能合约可以在区块链上执行代码逻辑，并实现自动化的交易和业务逻辑。常见的智能合约平台包括以太坊（Ethereum）、EOS等，它们使用不同的编程语言和虚拟机来支持智能合约的开发和执行。
5. 应用层：应用层是区块链的最上层，它是用户与区块链交互的接口。应用层可以包括各种基于区块链的应用，如加密货币钱包、去中心化交易所、供应链管理系统等。应用层的技术和工具根据具体的应用需求而定，可以使用Web开发框架、移动应用开发技术等。