PSD2支持：为什么使用FIDO（一）
发布时间:2021-02-24 07:52:37|浏览次数：1661
在之前几个系列的分享中，我们从多个角度介绍了FIDO，以及FIDO在多个企业的实践；最近的一个系列中，介绍了开放银行。在今天和下周的分享中，我们将两者结合，探讨开放银行怎样做认证。
一、概述
早在几年前，欧洲的银行业已经部署了认证解决方案。这些解决方案在安全登录方面很好的服务了客户。在金融数字化发展的今天，这些方案也可以用于应对支付欺诈。
PSD2（第二代支付服务指南Second Payment Services Directive）和相关的RTS（技术规范），改变了支付的场景。之前的认证方式是否满足现在的要求，成为一个值得思考的问题：
必须使用强身份认证方式、多因子身份认证
TPP（Third Party Providers第三方服务）通过开放接口访问账户
用户的体验，决定了PSD2的成功与否，也决定了基于PSD2的电子商务的发展水平。提升用户体验的同时保证安全是一个挑战；同样银行也需要评估，之前的认证方式能否满足新的需求。
FIDO认证标准提供了新的回答，但将之前的认证方式进行升级也是全新的挑战。本文将从FIDO认证原则、传统认证方式优缺点，以及他们同FIDO的比较等方面陆续展开，向银行业介绍FIDO、提供决策建议。
二、FIDO的本质
2.1 FIDO认证
下图列举了FIDO的双因素验证机制，也将PSD2的概念同FIDO标准进行了对照。
使用FIDO认证时，支付用户（PSU，Payment Service User）必须拥有一个FIDO认证器，它可以集成在用户常用设备中（比如手机、PC机），也可以是独立的设备（比如安全密钥、智能卡）。
用户验证
FIDO认证的第一步是在认证器中进行本地、离线的用户验证。验证过程如下：
通过动作验证用户存在（比如触碰安全密钥、使用NFC贴近读卡器等）；
认证器校验PIN码或者生物特征验证。在这种场景中，本地用户验证成为了用户认证的一个因子，属于RTS强制且认可的因子。
用户验证的数据（PIN码或者生物特征数据）是FIDO认证中的关键资源，它存储在认证器中，在本地验证，绝不会传输或分享到服务端。通过这种形式，FIDO满足了GDPR对隐私的要求。
本地验证通过，成为线上验证的先决条件。
线上验证
线上验证步骤证明了用户对FIDO认证器的所有权，PSD2强制要求多因子认证。在这一步骤中，账户支付服务提供商（ASPSP，Account Servicing Payment Service Providers）发送挑战值到认证器，之后使用认证器中的私钥对其签名。签名值返回到ASPSP，验证通过则代表所属权验证完毕。 FIDO标准基于公私钥验证。私钥是RTS中定义的个人安全凭据（Personalized Security Credential）。它在认证器中随机创建，对其它应用隔离。在生成阶段，对应的公钥会安全的发送到ASPSP。 认证器将私钥隔离保护。例如，用户在ASPSP1和ASPSP2都有账户，认证器必须要对应生成、存储不同的私钥，每个私钥只能被对应的ASPSP使用。 2.2 认证器 认证器有多种形式，下表进行了归纳。
2.3 FIDO的标准
FIDO UAF（Universal Authentication Framework）是FIDO中完全替代口令的标准。FIDO UAF认证器支持PIN码、生物特征等本地验证方式。典型的UAF可以在手机中实现，比如指纹登录、支付。 FIDO U2F（Universal Second Factor）是FIDO增加一个认证因子的标准，证明所有权，算是对传统用户名口令新增一个因子。典型的U2F设备是USB安全密钥。 FIDO2标准包含两部分，WebAuthn是web API接口规范，由W3C和FIDO联盟一起制定，在主流浏览器中已经实现；CTAP是FIDO通信规范接口，用于同认证器通信。与UAF一样，FIDO2支持完全替代口令，支持移动设备、台式机和笔记本设备。另外 ，U2F设备可以完全兼容CTAP。总结下来，WebAuthn和CTAP规范了通过浏览器访问认证器的标准。 更详细的协议介绍，可以在在 https://fidoalliance.org/download/ 进行下载。
三、口令+短信验证码
短信验证码（OTP，One Time Passwords）也是一种口令，比较典型的是4-6位短信验证码，通过短信服务下发到用户手机。短信验证码是银行应用中最常见的二因子登录要素。当业界发现用户名口令无法完全满足用户账户保护、敏感数据资源访问的问题时，短信验证码就开始被飞速部署到银行应用中。
操作流程如下：
1. 用户在一些基础KYC后，在银行应用中绑定手机号；
2. 当用户要访问银行线上服务或者转账交易时，银行需要生成一个OTP并通过短信发送到用户手机。对于支付而言，OTP的生成需要关联交易数量和机构标识；
3. 用户得到短信验证码，把其输入到银行app或对应网页的输入框中；
4. 当输入的数字同生成OTP匹配时，当前用户验证成功。
短信验证码需要限制有效时间，超时则需要重新请求。
这种认证方式需要一些备案，比如短信验证码发送失败时，通过呼叫中心（IVR，Interactive Voice Response）发送OTP，即进行语音验证码备份。但是语音验证码存在被攻击的威胁，攻击者可以使用用户手机号、弱口令或重复口令登录账号，再将手机号更改为攻击者使用的号码，这种情况下攻击者可以收到OTP码，并且不再发送到用户侧。
PSD2的要求 欧盟银行组（EBA，European Banking Authority）发布了一份确认书，认可短信验证码是可接受的认证因子，OTP的验证最终可以证明SIM卡所属；是一个可以证明所属的因子，但并不满足SCA强制的多因子认证要求。 即，不可单独使用短信验证码来认证用户、必须要使用第二因子，最典型的就是口令+OTP。 OTP可以是RTS描述的认证码（authentication code）。对于支付而言，RTS强制要求支持动态连接性，比如，生成的认证码可以通过数字签名、交易金额和被支付人信息获得。OTP需要在生成阶段使用交易信息，以此来满足动态连接的要求。然而，需要注意短信的缺点，短信中的转账金额、被支付人信息可能被篡改。 使用短信验证码结合口令的验证方式需要用户进行多步操作，会带来较差的用户体验。 口令+短信验证码认证的优点 口令+短信验证码认证被广泛使用的主要原因： 这是一种简单的证明所属权、且能够对用户名口令体系增加认证因子的方式； 它依赖于用户身边的设备：如手机。当然不一定是智能手机，任何手机都可以； 易于扩展：无需软硬件部署； 账户恢复操作简单，通常延续认证器丢失的逻辑，如手机：用户向运营商要求停卡，申请重新发卡。账户恢复不再需要银行单独处理； 应用方架构无需大的改造； 管理简单，比如，应用方可以自行选择短信供应商。 口令+短信验证码认证的缺点 口令+短信验证码认证方式的缺点主要是较差的用户体验和固有漏洞。 口令有很多众所周知的缺点（难于记忆，多个服务共用一个口令等）和安全隐患（易于被钓鱼，数据泄漏等）。 实际上额外添加短信验证码并不能解决口令固有的问题，且要求用户查收、输入验证码降低了便捷性。电子商务领域，额外的操作会制约用户增长，短信验证码+口令相对电商的快速发展，成为了明显的倒退。 从弱点来看，针对短信验证码的专业攻击正在增加，短信验证码并不像预期的那样安全。我们将主要的弱点总结如下： 国际电信标准No.7（SS7）对运营商移动网络异常重要，但它的弱点使攻击者能够以便宜的价格购买设备来截取短信验证码； 使用第三方短信服务增加了黑客的攻击面。此外，谷歌Hangouts等应用程序可以阅读短信，这些应用程序可以访问手机用户的收件箱，这就不能实现第二因素认证，因为它不能保证“您拥有的东西”，即注册手机； 短信验证码很容易受到钓鱼攻击，用户可能会被欺骗将验证码输入到假网站中；之后验证码则会被黑客用来对银行账户获取未授权访问； 一种相当常见的针对手机的攻击形式是SIM卡替换。黑客劫持用户的电话账户，让他们的运营商将电话号码移动到一个新设备上。然后黑客可以访问该用户的账户并接收短信OTP以进行欺诈活动。 NIST特别指出，SMS OTP作为身份验证机制的使用应受到“限制”，因为存在增加风险的固有安全漏洞。 四、硬件OTP生成器 硬件OTP生成器是一种专门的设备，它有一个显示器，有时还会有键盘、或者扫描二维码的小摄像头。 它们被植入加密密钥，用于生成不可预测的一次性口令（OTP，One Time Password），该口令在银行界面中显示并由用户手动输入。银行验证OTP服务的过程，保障了设备的唯一性，最终证明用户所有。 一些OTP生成器简单要求用户按键来生成OTP，但是在PSD2中，银行更倾向于用户首先在设备上输入PIN码，验证通过后再生成OTP。 还有一些OTP生成器会有较大的显示器，可以通过扫码方式，展示交易详情。 PSD2的规范 硬件OTP生成器符合身份验证过程中对“所有”因子的要求。那些带有键盘并要求用户输入PIN码的系统符合多因子认证要求。不带键盘的，用户则需要在另一个独立步骤中输入口令（或其它基于“所知”、“所是”的因子），来验证“所知”这一因子。 OTP的产生应遵循RTS要求的认证码形式。它符合唯一性和不可伪造的要求。为了实现动态连接性，用户必须在设备上输入金额和客户编码，稍显笨重。 那些可以联网或允许用户扫码的设备，可以将认证码同交易详情自动关联。 硬件OTP生成器的优点 这些设备通常具有安全芯片，比如单独的硬件模块，用来存储密钥、生成OTP。安全性是硬件OTP生成器最关键的优点。 此外，这些设备是由银行发放给用户的。银行对认证方案完全把控，不会委托给第三方。 硬件OTP生成器的缺点 ● 用户体验差：如上文所说，硬件OTP生成器需要用户进行大量操作，这不利于流畅的客户旅程。在许多情况下，用户必须同时输入口令和OTP。 对于用户常用的服务，必须携带设备、手动输入OTP和口令是很大的麻烦； ● OTP设备必须在用户需要时随时可用。如果用户将设备遗漏在家，则无法在工作时访问账户； ● OTP仍然会受到钓鱼攻击。OTP尽管具有唯一性，但仍然需要用户在界面上手动输入。这时，用户有可能会被巧妙设计的钓鱼活动欺骗，在钓鱼网页中输入OTP，攻击者获取OTP并使用它访问服务； ● 部署和扩展：硬件OTP生成器无法自行购买，只能由银行生成种子数据，再交给用户。这个过程成本高且灵活度低； ● 账户恢复：OTP生成器一旦丢失，用户将无法使用服务。由于设备必须通过银行购买，这并不是一个快速、简单的流程。