分类: 开放银行参考

  • 硬件加密卡测试(1):设备安装与验证

    LINUX下安装设备驱动

    操作系统基础信息:centos 7 X64

    本次测试加密卡设备:SJK1828(三未信安)

    一.编译驱动


    1.在root用户权限执行:./INSTALL swcsm.drv
    2.正常完后会产生文件swcsm.ko 以及Module.symvers文件,Module.symvers文件记录了驱动导出接口(默认不导出)。
    编译过程如果出错,请参考出错提示信息进行处理。
    3.加载驱动使用insmod命令,卸载使用rmmod命令。

    二.复制动态库

    cp libswsds_2008.so_v5.6.9.0_x64 /lib64/libswsds_2008.so
    cp libswsds.so_Convert_v3.1.0_x64 /lib64/libswsds.so

    三.加载模块

    insmod swcsm.ko VFnum=-1

    最后一个参数要带着,否则后面会有莫名其妙的错误。

    如果需要卸载模块,rmmod swcsm.ko

    四.测试验证

    ./swcsmmgmt_GM0018_v5.4.0_x64

    <-----------------------三未信安密码卡管理程序 [v5.4.0]----------------------->
    
    欢迎使用:
    ----------
    
    欢迎使用三未信安密码卡产品,该设备由三未信安科技股份有限公司研制。
    更多产品信息可参考:http://www.sansec.com.cn
    请选择要执行的功能。
    
     ->1|初始化设备
        |    销毁密码设备内的所有密钥、用户数据及权限等信息。
    
       2|RSA密钥管理
        |    查看RSA密钥信息,产生、删除密钥对等管理功能。
    
       3|SM2密钥管理
        |    查看SM2密钥信息,产生、删除密钥对等管理功能。
    
       4|SM9密钥管理
        |    查看SM9密钥信息,产生、删除密钥等管理功能。
    
       5|对称密钥管理
        |    查看对称密钥信息,产生、删除密钥等管理功能。
    
       6|备份恢复
        |    将密钥信息等备份到文件中保存,或从文件恢复到密码卡中。
    
       7|检测密码卡
        |    对系统中的密码卡进行基本功能测试。
    
    
    选择要执行的功能 或 [退出(Q)] [下一步(N)]>
    

    五.故障排查

    查看设备安装情况

    dmesg | grep SanSec

    [root@00-1E-10-1F-00-00 driver]# dmesg | grep SanSec
    SanSec PCIe Card module ok!
    SanSec swcsm-00 Card POLLING Driver Installed! driver ver: 3.1.1
    SanSec swcsm-01 Card POLLING Driver Installed! driver ver: 3.1.1
    SanSec swcsm-02 Card POLLING Driver Installed! driver ver: 3.1.1
    SanSec swcsm-03 Card POLLING Driver Installed! driver ver: 3.1.1
    SanSec PCIe Card module ok!

    查看PCI设备

    lspci|grep 7011

    [root@00-1E-10-1F-00-00 driver]# lspci|grep 7011
    02:00.0 Multimedia video controller: Device 1ed5:7011 (rev 07)
    02:00.1 Multimedia video controller: Device 1ed5:7011
    02:00.2 Multimedia video controller: Device 1ed5:7011
    02:00.3 Multimedia video controller: Device 1ed5:7011

    如有问题,检查下自己的步骤是否有漏掉,搞不定就联系厂家支持人员吧。

  • 打通对公零售,平安银行开放银行组织架构变阵,方案浮出水面

    可能成为开放银行发展历程中重要的里程碑事件,后续将持续进行跟踪。

    券中社3月13日讯,证券时报记者独家获悉,为打通对公零售、加强公私联动,平安银行正从总行层面成立开放银行事业群,按照六大职能分设六大中心。

    据记者了解,去年末平安银行开始传出管理层欲推动“公私联动”的意图,今年开年后,该意图就迅速以可行性方案在开放银行板块落地,力度很大。这个组织架构改动的特别之处在于:跨条线、涉及多职能部门,这在其他银行没有先例。

    平安银行在昨日举办的开放日活动上,以“打通对公零售优势,打造市场独一无二的开放银行队伍”来介绍新成立的开放银行事业群。在高层定位里,这支队伍将覆盖各产业生态B2B2C全链条,即服务由核心企业、平台组成的大B端客户;由商户、供应商、经销商组成的中小B端客户;由企业主、雇员、消费者构成的C端客户。

    据记者深入了解,开放银行架构变动方案已经成型,并传达给该行所涉员工。

    在成立开放银行事业群之前,平安银行零售条线和对公条线均各有一个负责开放银行业务的组织:零售条线是由原基础零售事业部下的开放银行中心负责,对公条线则是由原交易银行部负责。

    而现在,原基础零售事业部辖下的支付结算中心和开放银行中心的相关团队,都将被整合到新成立的开放银行事业群。

    具体来看,新成立的开放银行事业群将包括以下六大中心:

    首先是开放平台中心。该中心的主要职能是:负责基础平台建设,包括建立开放银行统一门户、合作伙伴联盟平台、低代码平台等;进行合作伙伴联盟管理,以及金融、非金融服务输出联调测试等。

    第二是支付结算中心。该中心负责将对公零售支付结算产品体系打通并进行统一管理;进行支付结算产品创新和研发;输出开放银行场景支付结算一体化解决方案。

    第三是数字融资中心。该中心将联动交易银行,进行开放银行下数字融资产品研发、打通、优化;连接零售智贷等借贷产品,提供开放银行场景下融资综合解决方案等。

    第四是线上运营中心。该中心负责客群线上经营、ATO统筹管理(AI+T+Offline简称,即AI银行、远程银行和线下银行统筹管理)以及科技驱动下的集团中小微客群运营。

    第五是大数据应用中心,主管数据打通、数字营销、大数据风控和企划管理等。

    第六是营销推动中心,主管分行营销推动和合规内控等。

    在昨日平安银行开放日上,平安银行总行公司业务总监、交易银行事业部总裁、创新委秘书长李跃在其演讲中,透露了总行对开放银行事业群的定位:一个相对独立,同时服务和助力零售和对公业务条线的子条线。该事业群的最终目的,是推动平安银行大零售战略升级。

    原文链接:https://qzs.stcn.com/article/detail/246557.html

  • 国密算法+国际算法=双算法SSL证书

    一、国密算法缘起

    原创性密码学算法是信息安全保障的基石,在我国是由国家密码管理局来负责进行密码法规的起草与解释,密码算法标准的制定与实施指导。金融行业中常用的对称加密,非对称加密等算法,国际上有DES,AES,RSA。国密也有对应的SM4,SM2算法。2010年12月17日,SM2算法发布;2012年3月21日,SM2,SM3,SM4国密算法作为国家标准获批发布。

    标题日期
    国家密码管理局关于发布《SM2椭圆曲线公钥密码算法》公告(国密局公告第21号)2010-12-17
    国家密码管理局关于发布《祖冲之序列密码算法》等6项密码行业标准公告(国密局公告第23号)2012-03-21
    《信息系统密码应用测评要求》等5项 密码应用与安全性评估指导性文件发布2020-12-16
    国家密码管理局公告(第43号)《信息系统密码应用测评要求》等以国家标准形式发布2021-10-19
    国密算法重要时间节点

    于此同时,在国密算法发布之初,银行等国家重要的行业基础设施,就已经开始了国密试点以及国密的改造工作。而国密算法的应用,涉及到方方面面。客户密码保存,用到密码算法,关键信息摘要,用到密码算法,数字签名,用到密码算法,通道传输,也用到密码算法。所以,如果一个完整的系统,要在所有的密码算法应用方面应用国密算法,是一件非常浩大的工程。比如,你现在正在浏览的这个网站,其HTTPS通道的建立,如果要应用国密算法,就是一件非常麻烦的事情。

    二、HTTPS通道的国密算法应用

    为什么说HTTPS通道建立如果要应用国密算法是一件非常麻烦的事情呢?因为如果是内部系统的两端之间,要应用国密算法,只要两个系统协商完,两个开发团队做改造就好了,再复杂些,比如中国银联的联网联合收单转接网络要进行国密改造,其改造数量约等于银行的数量再乘以一个比较小的系数,因为一家银行可能有不止一个系统要改造,但这种复杂度依然是可以接受的,因为数量可控。但是网站的HTTPS通道的国密改造非常麻烦呢?因为HTTPS通道,是客户的浏览器与服务器之间的通讯,所以不光服务器端要改造,关键是浏览器,而浏览器属于客户方设备,如果客户方设备不支持,你改完又咋样?至于所有客户浏览器都升级一遍,这个难度在互联网上有多大,不言而喻了。

    但这个事情,也不是没有解决方法,方法就是双算法证书。HTTPS通道的建立中的一个关键,是网站的SSL证书,平常证书的申请,其加密算法都是国际算法,RSA。而要面对几乎无法全面升级的浏览器,需要有同时支持RSA+SM2国密算法的SSL证书。这样的SSL证书,面对已经支持国密的浏览器时,使用的国密算法,而面对未升级过的浏览器,则使用的是国际算法。算是比较优雅的解决了以上问题。

    目前双算法SSL证书的供应商,CFCA和天威诚信都有成熟方案。

    CFCA SSL证书:国产国际双算法,应用切换自适应

    天威诚信 SSL证书:国密国际双算法

  • JWS与JWE

    RFC清单

    http://www.rfc.ac.cn/rfcindex8000.html

    JWT handbook

    https://auth0.com/resources/ebooks/jwt-handbook

    https://auth0.com/

    JWT官网

    https://jwt.io/

    JWT的库支持情况。

    https://jwt.io/#libraries-io

    JSON Web Signature 规范解析

    https://www.cnblogs.com/read-the-spring-and-autumn-annals-in-night/p/12041911.html

    base64

    https://baike.baidu.com/item/base64/8545775?fr=aladdin

    RS256加密JWT生成、验证

    https://blog.csdn.net/u011411069/article/details/79966226?utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control

    Java实现JWS生成与验签

    https://blog.csdn.net/tcctcszhanghao/article/details/103610087

    Open Banking安全性前瞻【重要】

    https://blog.csdn.net/systemino/article/details/108218085

    英文原文:https://www.contextis.com/en/blog/open-banking-read-write-api-tooling

    基于JWT规范的JWS实现token认证过程,采用JWT库jose4j,附springboot项目 demo源码下载

    https://blog.csdn.net/a704397849/article/details/98692032

    各类JWT库(java)的使用与评价

    https://blog.csdn.net/a704397849/article/details/98686964

    JWT token调试工具,JWT Debugger

    https://blog.csdn.net/a704397849/article/details/98736873

    Burp Suite使用介绍

    https://www.cnblogs.com/nieliangcai/p/6692296.html

  • 开放银行新闻报道

    移动支付网(开放银行)

    BBVA相关链接

    BBVA launches first BaaS platform in the U.S.

    https://bbvaopenplatform.com/

    https://www.bbva.com/en/bbva-launches-first-baas-platform-in-the-u-s/

    中国银联受邀参加山东城商行联盟开放银行交流会

    2022年4月14日,中国银联受邀参加山东城商行联盟举办的开放银行线上业务交流会,会议围绕开放银行的建设规划和推进思路进行了探讨。山东城商行联盟18家成员行(齐商银行、潍坊银行、莱商银行、长安银行、枣庄银行、德州银行、日照银行、泰安银行、东营银行、济宁银行、烟台银行、威海市商业银行、临商银行、齐鲁银行、宁波东海银行、威海蓝海银行、内蒙古银行、鄂尔多斯银行)、中国银联、平安银行、中国金融认证中心、山东城商行联盟领导及相关部门负责人,共计150余人参加会议。

    https://mp.weixin.qq.com/s/fR-qe-_stv9VyYVNQkm0CQ

  • 国密算法家族简介


    国密算法是国家商用密码管理办公室指定的一系列的密码标准,即已经被国家密码局认定的国产密码算法,又称商用密码(是指能够实现商用密码算法的加密,解密和认证等功能的技术),保障在金融,医疗等领域的信息传输安全。

    国密算法可分为对称算法和非对称算法,对称算法包括了SM1,SM4,SM7,祖冲之密码(zuc),非对称算法包括SM2,SM9。还有SM3是哈希算法,SM1和SM7对外是不公开的,想要调用的话,需要通过加密芯片的接口才可以。

    SM1对称密码
    SM1 算法是分组对称算法,分组长度为128位,密钥长度都为 128 比特,算法安全保密强度及相关软硬件实现性能与 AES 相当,算法不公开,仅以 IP 核的形式存在于芯片中。采用该算法已经研制了系列芯片、智能 IC 卡、智能密码钥匙、加密卡、加密机等安全产品,广泛应用于电子政务、电子商务及国民经济的各个应用领域(包括国家政务通、警务通等重要领域)。

    SM2椭圆曲线公钥密码算法
    SM2为非对称加密,基于ECC。该算法已公开。由于该算法基于ECC,故其签名速度与秘钥生成速度都快于RSA。ECC 256位(SM2采用的就是ECC 256位的一种)安全强度比RSA 2048位高,但运算速度快于RSA。它是一种先进安全的公钥密码算法,在我们国家商用密码体系中被用来替换RSA算法。SM2算法就是ECC椭圆曲线密码机制,但在签名、密钥交换方面不同于ECDSA、ECDH等国际标准,而是采取了更为安全的机制。另外,SM2推荐了一条256位的曲线作为标准曲线。

    SM3杂凑算法
    SM3是一种哈希算法,其算法本质是给数据加一个固定的长度的指纹,这个固定指纹长度就是256bit,用于密码应用中的数字签名和验证,消息认证码的生成与验证以及随机数的生成,可满足多种密码应用的安全需求。可以在SM2,SM9标准中使用

    SM4对称算法
    SM4算法是一种分组密码算法,用于无限局域网产品,该算法的分组长度为128bit,加密算法与密钥扩展算法都采用32轮非线性迭代结构。解密算法与加密算法的结构相同,只是轮密钥的使用顺序相反,解密轮密钥是加密轮密钥的逆序。

    SM7对称密码
    SM7算法是一种分组密码算法,分组长度为128比特,密钥长度为128比特。SM7适用于非接触式IC卡,应用包括身份识别类应用(门禁卡、工作证、参赛证),票务类应用(大型赛事门票、展会门票),支付与通卡类应用(积分消费卡、校园一卡通、企业一卡通等),其跟SM1一样,是不被公开的,想要使用,需要添加加密芯片才能调用。

    SM9标识密码算法
    为了降低公开密钥系统中密钥和证书管理的复杂性,以色列科学家、RSA算法发明人之一Adi Shamir在1984年提出了标识密码(Identity-Based Cryptography)的理念。标识密码将用户的标识(如邮件地址、手机号码、QQ号码等)作为公钥,省略了交换数字证书和公钥过程,使得安全系统变得易于部署和管理,非常适合端对端离线安全通讯、云端数据加密、基于属性加密、基于策略加密的各种场合。2008年标识密码算法正式获得国家密码管理局颁发的商密算法型号:SM9(商密九号算法),为我国标识密码技术的应用奠定了坚实的基础。

    SM9算法不需要申请数字证书,适用于互联网应用的各种新兴应用的安全保障。如基于云技术的密码服务、电子邮件安全、智能终端保护、物联网安全、云存储安全等等。这些安全应用可采用手机号码或邮件地址作为公钥,实现数据加密、身份认证、通话加密、通道加密等安全应用,并具有使用方便,易于部署的特点,从而开启了普及密码算法的大门。

    与SM2类似,包含四个部分:总则,数字签名算法,密钥交换协议以及密钥封装机制和公钥加密算法。在这些算法中使用了椭圆曲线上的对这一个工具,不同于传统意义上的SM2算法,可以实现基于身份的密码体质,也就是公钥与用户的身份信息即标识相关,从而比传统意义上的公钥密码体质有许多优点,省去了证书管理等。

    现在越来越多行业要求使用国密算法对数据做加解密保护,而国密算法也不像以前那般神秘,集成有国密算法的产品也越来越普遍。武汉瑞纳捷是国密定点生产单位,其国密安全芯片RJMU401,硬件集成国密算法SM1、SM2、SM3、SM4,也集成国际算法3DES、AES、RSA2048、SHA256,芯片具有18KB 的RAM和550KB的FLASH,支持ISO7816和SPI接口。RJMU401已获得国密密码局颁发的国密型号资质。

    ZUC祖冲之算法
    祖冲之序列密码算法是中国自主研究的流密码算法,是运用于移动通信4G网络中的国际标准密码算法,该算法包括祖冲之算法(ZUC)、加密算法(128-EEA3)和完整性算法(128-EIA3)三个部分。目前已有对ZUC算法的优化实现,有专门针对128-EEA3和128-EIA3的硬件实现与优化。

    密码算法作为国家战略资源,比历史上任何时候都显得更为关键。在大数据和云计算的时代,关键信息往往通过数据挖掘技术在海量数据中获得,所以每一个人的信息保护都非常重要。

    密码术语:http://www.gmbz.org.cn/main/viewfile/20180117172138101893.html

    国密算法特性表

    国密算法类型算法是否公开用途密钥长度(bit)对比国际算法
    SM1分组对称密码硬件芯片128AES
    SM2椭圆曲线公钥密码算法数字签名、密钥交换256RSA
    SM3杂凑算法数字签名256MD5、SHA1、SHA2
    SM4分组密码算法对称加密128DES
    SM7分组密码算法非接触式IC卡、电子标签128AES
    SM9标识密码算法IBC、CL-PKC
    ZUC流密码算法RC4

    转载自:https://blog.csdn.net/The_Reader/article/details/83991287

  • RSA算法和SM2算法对比

    SM2算法和RSA算法都是公钥密码算法,SM2算法是一种更先进安全的算法,在安全性能、速度性能等方面都优于RSA算法,在我国商用密码体系中被用来替换RSA算法。国家密码管理局于2010年12月17日发布了SM2算法,并要求现有的基于RSA算法的电子认证系统、密钥管理系统、应用系统进升级改造,使用SM2算法。

    SM2算法和RSA算法简介

    RSA公钥加密算法是美国计算机学家Ron Rivest、AdiShamir和Leonard Adleman于1977年提出,是最早的公钥加密算法之一,在全球范围被广泛使用。随着密码技术和计算机技术的发展,目前1024位RSA算法已经被证实存在被攻击的风险,美国NIST(国家标准技术研究院)在2010年要求全面禁用1024位RSA算法,升级到2048位RSA算法。此外,斯诺登事件爆发后,其泄露出的机密文档显示,RSA算法中可能存在NSA的预置后门,对RSA算法的安全性产生巨大影响。

    SM2算法由国家密码管理局于2010年12月17日发布,是我国自主设计的公钥密码算法,基于更加安全先进的椭圆曲线密码机制,在国际标准的ECC椭圆曲线密码理论基础上进行自主研发设计,具备ECC算法的性能特点并实现优化改进。

    SM2算法和RSA算法性能对比

    SM2算法和RSA算法都属于公钥加密算法,但两者分别基于不同的数学理论基础。与RSA算法相比,SM2算法具有抗攻击性强、CPU 占用少、内容使用少、网络消耗低、加密速度快等特点。

    1.SM2算法与RSA算法安全性能对比

    RSA算法是基于大整数因子分解数学难题(IFP)设计的,其数学原理相对简单,在工程应用中比较易于实现,但它的单位安全强度相对较低。对大整数做因子分解的难度决定了RSA算法的可靠性,随着计算机运算速度的提高和分布式计算的发展,加上因子分解方法的改进,对低位数的密钥攻击已成为可能。

    ECC(EllipticCurves Cryptography,椭圆曲线密码编码学)是由Koblitz和Miller两人于1985年提出,其数学基础是基于椭圆曲线上离散对数计算难题(ECDLP)。ECC算法的数学理论非常深奥和复杂,在工程应用中比较难以实现,但它的单位安全强度相对较高。用国际上公认的针对ECC算法最有效的攻击方法——Pollard rho方法去破译和攻击ECC算法,它的破译或求解难度基本上是指数级的。

    因此,ECC算法的单位安全强度远高于RSA算法,可以用较少的计算能力提供比RSA算法更高的安全强度,而所需的密钥长度却远比RSA算法低。目前,基于ECC的SM2证书普遍采用256位密钥长度,加密强度等同于3072位RSA证书,远高于业界普遍采用的2048位RSA证书。

    此外,为了提高安全强度必须不断增加密钥长度,ECC算法密钥长度增长速度较慢(例如:224-256-384),而RSA算法密钥长度则需呈倍数增长(例如:1024-2048-4096)。

    2.SM2算法与RSA算法速度性能对比

    在TLS握手过程中,更长的密钥意味着必须来回发送更多的数据以验证连接,产生更大的性能损耗和时间延迟。因此,ECC算法能够以较小的密钥和较少的数据传递建立HTTPS连接,在确保相同安全强度的前提下提升连接速度。经国外有关权威机构测试,在Apache和IIS服务器采用ECC算法,Web服务器响应时间比RSA算法快十几倍。

    SM2算法的优化和先进性

    SM2算法是我国基于ECC椭圆曲线密码理论自主研发设计,由国家密码管理局于2010年12月17日发布,在密码行业标准GMT 0003.1-2012 SM2 总则中推荐了一条256位曲线作为标准曲线,数字签名算法、密钥交换协议以及公钥加密算法都根据SM2总则选取的有限域和椭圆曲线生成密钥对;在数字签名、密钥交换方面区别于ECDSA、ECDH等国际算法,而是采取了更为安全的机制,提高了计算量和复杂性;在数字签名和验证、消息认证码的生成与验证以及随机数的生成等方面,使用国家密管理局批准的SM3密码杂凑算法和随机数生成器。SM3杂凑算法是我国自主设计的密码杂凑算法,安全性要高于MD5算法(128位)和SHA-1算法(160位),SM3算法的压缩函数与SHA-256具有相似结构,但设计更加复杂;SM4分组密码算法是我国自主设计的分组对称密码算法,与AES算法具有相同的密钥长度128位,在安全性上高于3DES算法,在实际应用中能够抵抗针对分组密码算法的各种攻击方法。

    SM2算法的应用推广

    密码算法的安全性是信息安全保障的核心,通过自主可控的国产密码技术保护重要数据的安全,是有效提升我国信息安全保障水平的重要举措。我国大力推动SM2国产密码算法替换目前所采用的RSA算法,一方面规避RSA算法存在的脆弱性和“预置后门”等安全风险,另一方面确保密码算法这一关键环节的自主可控,保障我国信息安全基础设施的安全可信。中办2018年36号文件《金融和重要领域密码应用与创新发展工作规划(2018-2022年)》以及相关法规文件均要求我国金融和重要领域密码应用采用SM2国产密码算法体系。

    由于国密算法尚未实现广泛兼容,在主流浏览器、操作系统等终端环境中不受信任,面向互联网的产品应用中采用国产密码算法将无法满足可用性、易用性和全球通用性的需求,在实际应用中很难真正落地实施。那么面对这个难题,其实我国早有企业已制定比较完美的部署行动,成功帮助政企实现国密合规。

    转载自:https://www.sohu.com/a/421927733_188485

  • 开放银行资料汇集

    将平时阅览的开放银行相关资料,整理汇总,省得以后丢了,或者到处乱翻。

    一、海外监管与市场规范相关资料

    序号主题链接备注
    1The Open Banking Standard链接英国,开放银行标准框架
    2Open Banking Read-Write API Profile – v3.1.8链接英国,开放银行API标准
    3Open API Framework for the Hong Kong Banking Sector链接香港,Open API框架
    4境外API Bank监管政策解析链接业界分析
    5OpenAPI Specification链接swagger OAS

    二、国内监管部门相关发文

    序号主题链接备注
    1中国人民银行关于发布金融行业标准加强商业银行应用程序接口安全管理的通知链接2020年2月13日 JRT 0185
    2北京金融科技创新监管试点正式启动链接2020年1月22日
    3中国人民银行关于印发《金融科技(FinTech)发展规划(2019-2021年)》的通知链接2019年8月23日
    4香港金管局APIDoc链接香港金管局API门户

    三、国内金融机构开放银行官方发布

    序号主题链接备注
    1浦发银行推出业内首个API Bank无界开放银行 重构银行业务和服务模式链接2018年7月12日
    2麦肯锡:开放银行的全球实践与展望——打破藩篱,合作共赢链接2019年6月17日
    3浦发银行:开放金融之全景银行系列蓝皮书正式发布链接2020年9月25日
    4平安银行:中国开放银行白皮书2021链接2021年4月18日
    5中国银联携各商业银行发布开放银行、乡村振兴金融科技研究成果链接2021年10月21日
    6中国银联受邀参加山东城商行联盟开放银行交流会链接2022年4月19日
    7中国银联技术管理委员会开放银行工作组2022年研究工作全面启动
    新增证券场景行业课题组、场景安全技术课题组
    链接2022年4月26日
    8共建开放合作共赢生态 银联助力推进开放银行生态场景建设链接2022年11月14日
    9民生银行举办开放银行“民生云”系列产品发布会链接2022年6月15日
    10平安银行发布《中国开放银行白皮书2022》链接2022年7月8日
    11《2022开放银行生态金融白皮书》重磅发布链接2022年12月7日
    12交通银行钱江:以开放银行为契机搭建多元联动生态圈链接2022年12月7日
    13CFCA助力中国银联开放银行服务接口安全测评业务落地链接2022年12月28日

  • 境外API Bank监管政策解析

    引言

    本文是我们推出的API Bank开放银行法律合规系列问题专题讨论之二。上一篇文章我们讨论了API Bank在金融数据合规方面需要关注的几个问题,包括银行在开展API Bank业务首先需要对金融数据进行划分以实施差异化的数据保护措施,需要全面评估第三方合作机构的数据来源、数据保护能力等以防止银行金融数据泄露风险以及目前国内关于金融数据出境的监管政策等。鉴于目前国内尚未出台API Bank相关的监管和指引文件,本文在研究分析有关国家和地区的API Bank监管政策的基础上,试图对国内未来可能出台的监管政策做一些展望,以期能为国内商业银行提供一些防范和化解API Bank法律合规风险的思路。后续我们还会就API Bank相关的其他法律合规问题推出专题讨论文章。

    一 英国

    (一)英国监管政策简介

    英国是最早开展对金融数据共享及API Bank研究的国家之一,早在2014年英国财政部和内阁就已要求Open Data Institute和监管政策咨询机构Fingleton Associates对商业银行数据共享进行调查研究,并发布了名为《数据分享和银行的开放数据》的报告,也称为“Fingleton Report”。该报告认为,进一步的数据开放将促进英国银行业的竞争,建议制定银行数据共享标准,以便为第三方提供标准、统一的API。

    2015年8月英国财政部开放银行工作组成立(“The Open Banking Working Group”,简称“OBWG”)旨在研究并制定详尽的开放银行框架与标准。OBWG的成员是多元化的,成员来自于银行业、技术业、消费者、商会等从业者。

    2016年3月,OBWG正式对外发布了《开放银行标准框架》(“The Open Banking Standard”,简称“《标准框架》”)。《标准框架》根据英国银行金融业的商业实践,以此为基础并考虑了欧盟隐私和数据保护的相关规则,就开放API的架构、运作、标准等各方面提出了建议。

    《标准框架》由三大标准以及一个治理模式组成。三大标准是指数据标准、API标准与安全标准,底层的治理模式则是维系开放银行标准有效运行的基石。

    1.数据标准

    开放银行中的数据标准,主要是数据描述、记录的规则,包括对数据展现、格式、定义、结构的共识。OBWG将数据分为五类,分别为开放数据、客户交易数据、客户参考数据、聚合数据、商业敏感数据。不同层次的数据所包含的信息不尽相同,通过数据划分,对不同的第三方合作机构匹配不同的数据共享权限。第三方企业对银行数据的权限有两种:一种是读取权限,即第三方可以读取银行提供的数据和文件,但不能对其进行修改。另一种是与之相反的写入权限,即第三方有权对银行提供的数据和文件进行修改、执行等操作。这两类权限均需通过开放API向第三方机构开放[1]

    2.API标准

     API标准是关于开放API设计、开发和维护的准则,主要涉及架构风格、资源格式、版本控制等各个方面。OBWG将API标准纳入框架的目的是为了统一开发者从不同提供者处获取数据的体验。

    3.安全标准

    安全标准是指API规范的安全性,目的是为了保护消费者的数据安全。OBWG在用户同意、身份认证、欺诈监控、用户授权四个方面提出了相关意见。如下所示:

    (1)用户同意。为保障用户利益,银行与第三方共享数据的过程必须征得用户同意。用户需清楚了解的授权条件,具体包括:向谁授权、第三方征得授权以后的目的、授权持续的时间。

    (2)身份认证。身份认证需要数据提供者和第三方共同合作,严格掌控验证方法。并建议使用OAuth2.0与Open ID connect相协同的身份认证协议。

    (3)欺诈监控。开放银行API应支持带外管理(Out-of-band,简称“OOB”)认证,以确保当发生变更情况(如收款人的改变)时,用户可以收到提醒。未来也可以尝试建立一种在第三方API返回消息中嵌入欺诈相关信息(如IP地址等)的机制。

    (4)用户授权。为防范用户授权的恶意使用情况,建议:给予用户及数据提供者撤销数据授权的选择;要求数据提供者设立一种可让用户阅览与取消所有授权的机制;为授权划分风险等级;对授权的持续时间进行约束;API连接和数据传输需加密,至少满足TLSv1.2(传输层安全性协定1.2)的要求。

    4.治理模式

    为确保开放银行标准的落实和推进,OBWG呼吁采用一个有效的治理模式来统筹全局,具体包含五条措施[2]

    (1)设立一个独立的机构。其职责包含跟踪并监督开放银行标准的落实和部署进程,处理客户纠纷,确保数据安全性,维护API的可靠性与可拓展性以及其他开放银行框架下提出的要求。

    (2)赋予独立机构审查第三方的权力。独立机构可能会在未来选择授权其他组织进行审查和/或认证,包括平台,行业协会或孵化器。这将减少独立机构的的工作量并开放对Open Banking API的访问权限。

    (3)要求第三方机构持有保险。考虑到开放银行潜在的风险隐患,金融市场行为监管局(The Financial Conduct Authority,简称“FCA”)有责任指导第三方机构购买相应的保险,并评估与之相对应的风险程度。

    (4)创建事故处理机制。当用户遭遇API相关事故之时,有权利联系第三方或者数据提供者来协商解决问题,如果逾期未处置,就可以启动下一事故处理流程,交由独立机构处理。

    (5)分阶段逐步引入治理模式。OBWG并不要求一蹴而就建立一个完善的治理模式,而是提倡循序渐进分阶段进行。治理模式应遵循PSD2的要求,但也不应仅限于此。另外,也需要考虑资金成本相关问题。

    6410_副本.jpg

    ▲图表1英国开放银行标准网站

    (二)评析

    英国是最早开展API Bank监管研究的国家之一。其对API Bank采取的是开放、包容的态度,并自上而下推动监管部门主动研究、出台相关监管指引政策。英国API Bank核心监管指引文件《标准框架》的核心表现为三大标准和治理模式。通过三大标准将银行机构开展API Bank业务的核心内容统一起来。其中,数据标准提出的最重要的关键词在于“划分”和“权限”,根据数据的来源、重要性、涉密性等因素综合考量,对银行金融数据进行分层,进而再通过对第三方数据保护能力和合作深度的评估,共享不同层次的数据,开放不同的权限。此外提到的技术标准是为开发者所设置的有关API技术层面的内容,囊括了大量包括架构、计算机协议、资源格式等内容。为充分保障金融消费者的个人数据安全,《标准框架》的安全标准提出了4大方式,其中核心的关键词在于“同意”、“授权”,其一是要求银行向第三方共享数据必须取得用户的明示同意,将授权对象、授权目的、授权期限明确的告知用户;其二是为了防止授权滥用,赋予用户对数据共享许可的任意撤销权,并为用户撤销授权提供相应的便利。

    在治理模式上,《标准框架》提出的更多是倡议性的建议,例如设置独立的机构负责标准落实和推进、赋予独立机构监管权限等,要求第三方机构开展风险评估和购入保险等。

    总体而言,英国作为世界上最早对API Bank制定标准框架的国家之一,提出的监管倡议具有很强的导向型。其中关于数据和安全的两大标准,成为其他国家制定API Bank监管政策的重要参考和借鉴。

    二 新加坡

    (一)新加坡监管政策简介

    新加坡也是较早开始API Bank监管研究的国家之一。2016年11月,新加坡金融管理局联合新加坡银行协会发布API指导手册(“Finance-as-a-Service:API Playbook”,简称“playbook”),提供了API的选择、设计、使用环节指导,以及相应的数据和安全标准建议。

    1.API分类与执行指南

    playbook在这部分内容中不仅对API的分类进行了详细的阐述,还围绕API经济中的参与方——API提供者、API消费者、金融科技公司、开发者社区提供角色指导与执行指南。

    API分类方面,playbook基于银行、保险机构、资产管理公司、监管机构的5600多条既有流程,根据重要性筛选了411个API(对应700多个业务流程),跨越产品、市场、销售、服务、支付、监管价值链,并对每一个API提供了详细的功能说明。

    playbook对每一类API参与者的定义以及与其相对应的操作指南也做了详尽的说明。

    第一类是API提供者,即通过API将数据共享出去的组织;

    第二类是API消费者,即使用API来访问或发送数据的组织或个人;

    第三类是作为行业创新先锋的金融科技公司;

    第四类是开发者社区,该类参与者从API提供者和金融科技公司处获取与它们商业需求相符的API创建要求。

    2.标准和治理模式

    和英国的《标准框架》近似的是,在playbook中也有关于API Bank的三大标准,从内容上看与英国的《标准框架》内容基本一致,在数据标准上playbook除了吸纳《标准框架》的规定外,还强调最终应基于交换数据的类型、涉及的行业、区域差异这三种不同的条件确定最终要采纳的数据标准。

    playbook也提议建立一个具备新加坡金融市场特色的治理模式,旨在确保API使用的一致性、有效性、安全性。具体而言,playbook设计的治理模式由上至下分为四部分:API治理框架、API治理参考架构、API生命周期治理、API风险治理。

    64011.jpg

    ▲图表2新加坡“API playbook”

    (二)评析

    新加坡对API Bank的监管指引很大程度上参考了英国的《标准框架》,并进行了进一步的细化和完善,其中将API参与者分为四类,不同类的参与者介入API的环节也不尽相同,操作指南也不同。

    三 我国香港地区

    (一)我国香港地区监管政策简介

    2017年9月,香港金融管理局(“the Hong Kong Monetary Authority”,简称“HKMA”)宣布了七项行动,帮助香港迎接银行和科技融合的“Smart Banking”时代,Open API行动是其中之一。

    2018年1月,HKMA发布《香港银行业Open API框架咨询文件》(“Consultation Paper on Open API Framework for the Hong Kong Banking Sector”,简称“咨询文件”),旨在推动银行通用API的广泛使用,促进银行和科技公司的创新融合,提升银行业竞争力。

    2018年7月,HKMA发布《香港银行业Open API框架》(“Open API Framework For The Hong Kong Banking Sector”,简称“《香港API框架》”)。据《香港API框架》介绍,文件包含了对咨询文件充分协商后的必要修改。

    1.《香港API框架》指导性原则

    (1)受控下的业务推进。HKMA明确Open API业务的推进是富有成效的,将根据银行业对Open API 框架的反馈,按照框架时间表的规定执行。HKMA将密切监控业务的执行,确保市场接纳度和鼓励新型案例的运用。

    (2)视香港地区Open APIs业务推进情况采纳或开发必要管控措施。HKMA熟悉世界其他国家和地区的强监管措施,但针对香港地区仍采取协作性、阶段性的措施,并将根据Open API 在香港地区的执行情况采取进一步的必要管控措施。

    (3)不干预政策。为保证香港地区银行业将Open API作为其战略组成部分,并得以有效执行,HKMA无意就各银行如何采用Open API作出规定。

    (4)高级Open API功能优先确认。将以对银行和消费者的潜在效益为基础,筛选高等级Open API功能,并对其优先确认。

    (5)国际或行业惯例的运用。为确保Open API的有效实施和快速发展,香港API框架中囊括了国际及行业对此业务运用的惯例与实践。

    2.Open API的分类与部署时间

    Open API的分类将优先考虑其内容、前景、风险划分为以下4类:

    (1)产品与服务信息。银行提供的包含产品和服务细节的“只读”类信息。

    (2)产品与服务的订阅与申请。消费者通过访问,允许以网络进行信用卡、贷款或其他银行服务的提交或申请。

    (3)账户信息。对经认证客户单独或聚合账户信息(余额,交易记录,限额,支付日程等)的检索与修改。(须申请)

    (4)交易。经客户认证的并由其发起的银行交易与支付或预先安排的支付或交易。

    针对四大类Open API分类《香港API框架》也提供了保护性要求,诸如银行地址确认,数据完整性,TSPs认证等措施。

    在部署时间表上,由于不同种类的Open API对保护措施的要求越来越复杂,HKMA认为逐步开放是合适的。对第一阶段的产品与服务信息与之相对应的信息技术产业已经十分成熟,对其部署相对简单和快捷。此后的三阶段涉及到复杂的技术、安全、认证基础设施需要各方倾注更多的努力。通过银行在先前阶段积累的经验,可以预计此后几个阶段的部署时间将不会持续很久。

    阶段开放API种类本文件公布后的开放时间表
    1产品与服务信息6个月
    2产品/服务的订阅与新应用12-15月
    3账户信息未来12个月内启动
    4交易未来12个月内启动

    ▲图表3香港地区开放银行业务推进时间表

    值得注意的是,HKMA在规定API分类和部署时间的同时,也要求银行对不同阶段应当采取与之相匹配的保护等级和适当的传输层安全协定安排,并在合同中明确责任承担、归责、管控和消费者保护等内容。

    3.架构、安全与数据标准

    目前,日本、新加坡、英国等国家为了保证银行及其分支机构Open API在全球的顺利开展,已经在架构、安全上达成了共识。HKMA认为香港地区为推进金融建设,对此类行业共识性内容只需要直接借鉴采用即可。架构标准更多的涉及计算机技术层面的内容,诸如编程语言、数据格式、传输协议的统一。在安全标准上,HKMA要求开放的四大分类都必须使认证、完整性、保密性和授权得到充分的保证。保证银行网站和传输数据的完整性和保密性检查,使用X.509数字证书,确保银行地址的真实性。

    4.第三方治理模式

    HKMA在文件中提出,为保证创新和消费者保护,银行需要采纳一个正式的第三方治理方式。第三方认证模式涵盖了尽职调查、端口接入、管控、身份与责任、消费者保护、数据保护、基础设施恢复能力、事故处理等一系列活动。就目前来看,有三种认证模式可供参考:

    一是双边模式,由银行自己根据与第三方的合作性质进行风险评估和尽职调查,制定政策和流程;

    二是中央实体模式,中央实体由所有相关银行共同出资和组建,制定一套统一的TSP治理标准和评估服务,从而简化流程并提高效率;

    三是基于一定基准的双边模式,一系列TSP治理基准由双边共同制定和同意,银行可增加自己独特的要求,以基准模式使接入程序流程化。

    HKMA建议初期采纳相对灵活的双边模式,待开放银行业务逐渐成熟后,可考虑建立中央机构统一管辖。如若能够得到银行业的支持,HKMA也可以考虑第三种模式,与各个银行一同制定基准条例。

    64011.png

    ▲图表4《香港 API框架》

    (二)评析

    我国香港地区关于API Bank的监管政策和业务指引,虽然起步晚于其他国家和地区,但是在内容上对其他国家和地区的监管政策都有所借鉴和改善,并充分考虑了香港地区的业务情况。其中逐步推进银行业务开放的时间表,由易到难防控风险,以及提出的三种类型的第三方治理模式,在原英国API Bank监管模式的基础上进一步创新,值得借鉴。

    四 美国

    (一)美国监管政策简介

    截至目前,美国并未发布专门针对API Bank的监管文件,但美国联邦金融消费者保护局(Consumer Fincial Protection Bureau ,简称“CFPB”)发布了金融行业开展数据共享业务必须遵循的9大原则,译文[3]

    消费者保护原则:经消费者授权的金融数据共享和整合

    (Consumer Protection Principles :Consumer-Authorized Financial Data Sharing and Aggregation)。

    1.获取

    消费者有权在要求后从产品和服务提供方处获得自己对金融产品和服务所有权和使用情况的信息。此类信息应该实时提供。通常来说,消费者能授权受信任的第三方为了消费者的利益,以安全的方式从消费者账户提供方获取此类信息来代表消费者使用它们。

    金融账户协议和条款支持安全的、经过消费者授权的获取、有利于消费者利益,并且不寻求阻止消费者获取或授权获取消费者的账户信息。这种获取不要求消费者向第三方共享账户凭证。

    2.数据范围和使用

    消费者和经消费者授权可以获得的金融数据包括任何交易、连续交易或者与消费者使用情况相关的其他方面;任何账户的条款,例如一份收费价目表;已经完成的消费者支出,例如支付的费用或利息;和已经完成的消费者福利,例如挣到的利息或奖励。信息应该以能直接被消费者或消费者授权的第三方使用的形式呈现。获得消费者授权的第三方只能获取与消费者选定的产品与服务相关的数据,这种第三方可以保存此类数据,但只能是在必要的情况下。

    3.控制和同意

    当消费者能控制和自己账户以及与金融服务使用相关的信息时,他们能改善自己的金融生活。经消费者授权获取、存储、使用和散布消费者数据的条款要能充分并高效地披露给消费者,要让消费者理解上述用途,要对消费者对他们选定的产品或服务的合理的期待相一致,不要过于宽泛。数据获取的条款包括获取的频率、数据范围和保存期限。消费者不是被强迫授权给第三方自己的数据的。消费者理解数据共享废止条款,并能有准备地、轻松地废止对数据获取、使用或储存的授权。如果消费者要求被授权的服务商删除个人可识别信息,服务商应及时、高效地废止相关行为。

    4.授权支付

    经过授权的数据获取本身不是支付的授权。经过消费者授权的产品和服务提供商要发起支付需要获取消费者另外的和明确的授权。想要获取消费者信息和发起支付的服务商应该合理地要求消费者提供其欲获取服务应提供的两种授权。

    5.安全性

    应该安全地获取、储存、使用和分发消费者数据。消费者数据应该以能保护消费者免于遭受数据泄露的方式保存。获取(账户凭证)同理。所有与获取、储存、传输或处理数据相关的方面应能采取强有力的保护措施和高效的流程来降低识别、有效应对、解决和消除数据泄露、传输错误、未经授权即获取和欺诈的风险,并应仅向同样有保护措施和流程的第三方传输数据。安全防护措施应能高效应对新威胁。

    6.获取的透明性

    消费者应能了解,或易于查明,他们授权过的第三方如何获取并使用与他们账户和金融服务使用情况相关的信息。在消费者数据被获取、使用或储存期间,消费者应能查明类似机构的身份和安全性、它们获取的数据、它们对这些数据的事情情况和它们获取数据的频率。

    7.准确性

    消费者能预期他们获取的数据或授权他方获取或使用的数据是准确和及时的。如果数据不准确,不管不准确如何以及在哪发生,消费者应当有合理的方式来提出异议并解决这一不准确性。

    8.对非授权获取提出异议和解决争议

    消费者应当有合理和可操作的方式对未经授权获取和共享数据、与授权或者未经授权的数据共享获取相关的或导致的未经授权的支付、未满足其他合规要求(包括未满足消费者授权相关的条款)的实践提出异议和解决争议。消费者无须指明谁未经其授权即获取其数据以及谁让其他方面未获取其授权即获取其数据的相关方即应获得适当救济。未经消费者授权而获取了消费者数据的相关方面承担此种数据获取的责任。

    9.有效的、切实可行的问责机制 

    使相关方面可以获取、使用、储存、重新分发和处理消费者数据的目标和动机是使消费者能安全地获取(相关产品和服务),应当防止误用。具备商业性质的相关参与方对为消费者带来的风险、伤害和成本负责。这些参与方同样被要求高效地防范、识别和解决未经授权获取和共享数据、与授权或者未经授权的数据共享获取相关的或导致的未经授权的支付、数据不准确、数据不安全以及未满足其他合规要求(包括未满足消费者授权相关的条款)。

    640_副本1.jpg

    ▲图表5 CFPB网站

    (二)评析

    从美国的监管可以看出,虽然没有直接出台对API Bank的监管文件,但CFPB直接把API Bank的核心数据共享提炼出来作为监管的重点。某种程度上,是从更高层面对全行业所有涉及到金融数据共享的新业务、新技术进行监管。

    这9大原则囊括了数据范围、用户授权与同意、安全保障、授权撤回等内容。虽然不是直接对API Bank作出的规定,但完全适用于该业务。解决了新型互联网金融业务的关键性问题。但相比英国、新加坡和我国香港地区具体的监管规则,没有直接针对API Bank的详细规定还是略显不足,但也不排除未来出台专门的API Bank监管政策的可能性。

    五 我国API Bank监管政策展望

    纵观各个国家和地区API Bank监管趋势以及考虑到银行等金融机构的重度监管属性。我们认为,我国出台专门的API Bank开放银行监管政策应该是大概率事件。结合其他国家和地区已经出台的监管政策,监管重点应该会包含以下几个方面:

    第一,个人信息保护将会成为监管强调的核心内容。信息科技时代是对数据充分利用的时代,共享数据、挖掘数据价值成为各商业主体的一大课题。API Bank的核心和基本要求就是数据共享。由于金融数据的高敏感性和高安全性要求,尤其涉及个人金融信息的高保密要求。监管应该会把对个人金融信息的保护放在首位,要求银行依法、合规的收集、使用、共享个人金融信息。

    第二,第三方数据共享平台的金融数据保护能力会成为监管关注的重点。金融数据共享就意味着被共享主体也知晓银行存储的个人金融信息,被共享主体泄密也就意味着银行泄密。所以,被共享方也需要承担和银行一样的保密义务。但是,API Bank合作平台分属各行各业,多数往往不属于金融机构这样的重度监管行业,个人信息保护意识淡薄。并且若第三方合作平台若不属于金融机构,金融监管机构也不可能跨行业监管。所以,第三方合作平台的数据保护能力的评估和约束控制将会成为API Bank监管的重点和难点。

    第三,对金融数据进行数据划分可能会是监管政策的基本要求。数据划分是目前几乎所有已出台API Bank监管政策国家和地区对API Bank的基本要求。我国香港地区更是从金融数据划分的基础上,根据数据内容、关联性、重要性逐步开放,制定明确的开放时间表,并要求银行根据数据划分的结果匹配不同的合作权限。通过这种根据金融数据的划分等级进行逐级开放的最大好处就是可以控制风险,监管部门可以根据各级开放的实际情况及时做出调整。

    参考文献

    [1]参见兴业数字金融服务(上海)股份有限公司战略与研究团队,《开放银行系列之监管篇》

    [2]参见前引[1]

    [3]CFPB:消费者金融数据共享和整合原则,https://www.sohu.com/a/200151114_649029

    微信图片_201903051049491.png


    戴祥

    合伙人(非权益) / 律 师

    戴祥,德恒上海办公室业务合伙人、律师;主要执业领域为公司首发上市,上市公司再融资、并购重组,商业银行科技金融、金融市场,争议解决等。

    邮箱:daixiang@dehenglaw.com

    微信图片_201903051049491.png


    胡承浩

    实习生

    胡承浩,胡承浩,德恒上海办公室实习生。

    邮箱:huch@dehenglaw.com

    声明:

    本文由德恒律师事务所律师原创,仅代表作者本人观点,不得视为德恒律师事务所或其律师出具的正式法律意见或建议。如需转载或引用本文的任何内容,请注明出处。

    转载自:http://www.dhl.com.cn/CN/tansuocontent/0008/014244/7.aspx