开放银行和交易API协议的安全性分析
2020-10-23 21:50 文章来自: 人大金融科技研究所 收藏(0) 阅读(1460) 评论(0)

为应对金融服务业缺乏竞争和创新的问题,欧盟发布了《第二次支付服务指令》(Second Payment services Directive, PSD2),鼓励账户服务支付服务提供商共享数据。与其他欧洲国家一样,英国也推广了一种用于数据共享的标准API:开放银行标准(Open Banking standard)。来自英国Newcastle大学和Teesside大学的研究人员对API进行了正式的安全性分析,重点关注银行帐户和交易API协议的正确性。这项工作依赖于先前提出的一种方法,它为协议建模和验证提供了一种实用的方法。中国人民大学金融科技研究所(微信ID:ruc_fintech)对报告核心内容进行了编译。

来源 School of Computing, Newcastle University, UK

编译 王皓月

引言

金融服务业缺乏竞争一直是导致欧盟引入第二版《支付服务指令》(PSD2)的主要因素之一,该指令旨在通过鼓励银行账户持有人以受控且安全的方式分享他们的帐户数据。这种方法以及经济机会显然也具有重要的隐私和安全隐患,在构建允许如此规模的数据共享的系统时必须仔细考虑。

为了提供标准的API以在不同银行之间共享客户数据,英国(与其他欧洲国家类似)引入了开放银行标准。该法规包含一些适用于不同第三方提供商(TPP)的API规范,这些提供商旨在为同意共享数据的消费者提供服务。采用标准化接口可以实现互操作性,并简化了银行和TPP之间共享数据的系统的实施。

在本文中,作者对开放银行标准API进行了正式的安全性分析,重点验证了帐户和交易API协议的正确性。这项工作依赖于先前提出的一种方法,该方法为协议建模和验证提供了一种实用的方法。该方法利用Alice和Bob符号(AnB)来指定协议的形式化模型,可以通过OFMC模型检查器进行正式验证,该模型检查器已被用于建模和验证大量的安全协议,例如AVANTSSAR等项目。

作者形式化并验证了许多隐含在需求中的安全目标。尽管在作者的分析中,大多数目标都得到了满足,但标准中缺乏对安全性属性的严格定义可能会造成歧义,从而可能导致在实现过程中对安全性需求的不同解释。此外,该标准似乎依赖于许多当前的网络技术,而这些技术对于未来的技术和安全需求可能会变得过时。

就作者所知,本文的正式模型代表了正式分析开放银行协议的第一次尝试。最近,其他作者根据OWASP十大网络应用程序安全风险列表,对网络应用程序与丹麦Nordea开放银行API的集成进行了评估,主要考虑底层技术的安全威胁。然而,他们没有分析开放银行本身的安全性考虑和评估安全目标。因此,作者认为正式的分析对于考虑采用对金融部门的效率和安全有重大和长期影响的标准的利益相关者是有价值的。

背景

开放银行标准概述

支付服务指令(PSD)是一项欧洲立法,旨在提高整个欧盟的支付服务的安全性和创新性。第一个版本的PSD在2007年被采用,但随着经济的数字化发展和新的支付服务的出现,它变得过时,不足以确保提供消费者保护和充分的行业竞争。因此,在2015年11月通过了一份修订本,试图:

-确保所有付款服务供应商拥有平等的经营条件;

-扩大新支付手段市场;

-确保使用支付服务的消费者安全。

为了提供标准,开放银行实施实体在2016年由英国竞争和市场管理局(CMA)成立。开放银行工作小组(OBWG)发表了一份关于开放银行标准的报告,其中概述了两项主要成果:

-开放API,用以分享帐户服务付款服务供应商(例如银行)所提供服务的资料;

-开放API,用以分享由ASPSPs提供的付款服务用户的帐户数据。

开放银行不仅关注API端点(例如第三方,如开发人员,用于构建银行和金融应用程序的可访问资源的位置),还关注数据和安全标准。数据标准为API数据格式提供数据模型。API标准涵盖了API的操作要求。安全标准涵盖了API安全要求。

开放银行标准已于2018年9月与最新标准分阶段发布。到2019年10月,该标准已被65家规范的ASPSP和123家提供服务的TPPs采用。这说明了开放银行对金融服务业的意义,从而验证其标准正确性的重要性。

帐户资讯服务供应商(AISP)

帐户和事务API协议(ATP)流允许AISPs访问PSUs帐户数据,如图1所示。AISP是一个被ASPSP允许访问PSU账户数据的受监管实体,如果PSU提供了他们的同意。这种类型的访问是只读的,因为预期AISP不会直接影响允许它们访问的支付帐户。然后,AISP可以提供具有PSU帐户和交易数据的不同服务,包括提供PSU持有的不同支付帐户状态的用户友好视图的应用程序、预算建议、价格比较和产品推荐。



协议初始化时,PSU向AISP请求关于其支付账户的信息(步骤1),然后根据与PSU商定的访问权限,尝试与相应的ASPSP创建账户访问许可。首先,AISP通过客户机凭据授权向ASPSP验证自己,这是一种机器对机器身份验证的方法。然后,ASPSP向AISP提供一个访问令牌,用于请求创建同意资源(第2步)。此时,创建的帐户访问同意必须得到授权,以便AISP访问PSU的帐户数据。这要求PSU向ASPSP认证自己,然后授权同意。在此阶段,PSU必须选择所选权限应该应用的支付帐户。然后,AISP获得帐户数据的访问令牌(第3步)。有了这个令牌,AISP必须首先通过账户端点检索可访问的帐户,包括它们的惟一ID。稍后,可以使用ID请求特定账户的数据(步骤4)。为了检索特定的PSU账户数据(例如,余额、交易、直接借记、受益人等),AISP将不得不通过适当的链接使用正确的端点和方法从ASPSP请求数据。


方法和规范语言

本工作中介绍的开放银行 API的正式验证基于其中提出的协议验证方法。该方法利用Alice和Bob表示法(AnB)来指定协议的正式模型,该模型可以通过信息流(保密性和真实性)目标来正式验证。这种表示法抽象了实现细节,但允许协议的安全相关特征的形式化表示和分析。

AnB规范由几个部分组成。类型部分声明协议中使用的不同标识符。这包括代理、常数和变量(随机)数字和透明函数。透明函数是用户通过其签名定义的,因此从其实现细节中抽象出来(例如,它们是未解释的)。知识部分描述了每个代理在运行协议之前拥有的初始数据。信息流在“操作”部分中进行了描述,其中指定了有关代理交换的消息的详细信息。此外,该模型还可用于验证特定的安全属性,如(弱)认证和保密目标:

– A对M进行弱认证:代理A有证据表明消息M已被代理B认可,目的是将其发送给A(即非注射协议);

– A在M上对B进行身份验证:身份验证较弱,加上消息M新鲜度的证明(即内射协议);

– A,B之间的M保密:消息M在列出的代理之间是保密的。

正式模型捕获协议需求。虽然开放银行API详细描述了信息流,但它缺乏安全目标的定义,而安全目标是代理之间的交换所要传达的。因此,作者的部分工作包括为协议模型确定合适的目标。

为了进行验证,作者使用了开源定点模型检查器(OFMC),它是支持AnB表示法的符号模型检查器。此外,使用AnBx编译器和代码生成器对模型进行预处理,以从更严格的类型系统中受益,并支持对AnB的扩展,该扩展允许命名表达式抽象(定义部分)。

实现过程

作者定义了帐户和交易API协议(ATP)的AnBx模型,以准确地分析和验证其信息流。作者从中提取并且不直接指定开放式银行安全配置文件中定义的相关技术(例如OAuth 2.0)。

机密信息在因特网上交换。因此,该规范要求在各方之间使用传输层安全(TLS),就像在Financial API规范中一样。验证TLS并不是我们的重点:我们通过使用AnB子弹通道,用机密和真实的通信部分模拟TLS来假定它的安全保证。例如,->表示一个安全通道(经过身份验证的和机密的),可以用作具有相互身份验证的TLS的合适抽象。

作者也对交换的有效载荷进行了抽象。作者的目标是为规范所允许的最弱版本建模,因为它可能是最脆弱的。因此,由于附加的加密层是可选的,所以我们不在模型中讨论它,而可能是未来工作的一部分。为了帮助解释这个模型,图2给出了一个包含AnBx操作标签的序列图。下面我们将描述AnBx模型的每个部分。

角色和职责

参与协议的代理有四种。PSU发起协议,旨在授予AISP对其帐户数据的有限访问权。AISP的目的是获得对PSU帐户数据的访问,从而为用户提供服务。ASPSP有两个独立的角色:授权服务器(aspspA),对AISPs进行身份验证,PSUs生成令牌,使AISPs能够访问端点;和资源服务器(aspspR),维护资源,如同意和PSU帐户数据。


通过观察每个代理的职责,授权服务器和资源服务器必须是可信任的方:如果它们中的任何一个恶意行为,协议可能会被轻易破坏。AnB中的可信代理由以小写字母开头的标识符表示。

基本知识

PSU和AISP知道彼此,因为在协议执行之前,PSU已经与AISP联系,交换权限,并告知ASPSP联系意图。假定AISP标识ASPSP的相应授权和资源服务器。因此,AISP知道这两台服务器的身份。授权和资源服务器彼此已知,PSU也知道它们的身份。


图2  模型序列图

相关知识:


PSU/AISP。身份验证要求PSU和AISP与授权服务器共享一个秘密。这个秘密是预先知道的,通过透明的函数调用fPSUSecret(PSU)和fAISPSecret(AISP)来表示,这允许我们从秘密协议机制中抽象。


授权和资源服务器。授权服务器通过透明的函数在协议执行过程中执行大量的状态更改操作:fClientCredToken生成一个通过客户证书授予获得的令牌;fAuthCode生成授权代码;fAuthCodeToken生成通过授权代码获得的令牌。授权服务器也知道它的PSU和AISP秘密,以便对它们进行身份验证。资源服务器通过透明函数fCreateIntent和fGetIntent执行状态改变操作,分别创建和检索同意资源;fFetchAccounts检索所有PSU帐户的列表;fAuthoriseIntent更新同意授权;和fAccountsEndpoint返回PSU帐户数据。


角色限制。为了使作者的模型更现实,作者对不同代理执行的角色施加了限制。要声明不允许哪个代理充当另一个代理,可以在“知识”部分的末尾使用where关键字。例如,PSU不能充当AISP,这是不现实的,因为在英国,AISP受英国金融行为监管局(FCA)监管。作者还排除了PSU充当授权服务器或资源服务器的可能性,因为这些服务器被认为是受信任的。