一种支持HCE-NFC的电子钱包银行Android应用程序的安全性评估外文翻译资料
2021-12-12 22:21:32
英语原文共 6 页
一种支持HCE-NFC的电子钱包银行Android应用程序的安全性评估
Ratinder Kaur, Yan Li, Junaid Iqbal, Hugo Gonzalez, Natalia Stakhanova
计算机科学学院
新布伦斯威克大学
弗雷德里克顿,加拿大
电子邮件:{ rkaur1, liyan.168, junaid.iqbal, hugo.gonzalez, natalia.stakhanova}@ Unb.ca
中文摘要
电子钱包已经开始流行起来,其使用在某些国家已达到临界点。这是因为规模适中的零售商对支付设备的全球性使用和对电子钱包接受的广泛性。随着越来越多的顾客使用电子钱包,他们也可能成为网络犯罪的一大目标。电子钱包通过智能手机促进金融交易,这是网络罪犯的一个有利可图的机会。本文对加拿大多家主要银行的 Android 电子钱包应用进行了安全性评估。
关键词:电子钱包,HCE-NFC 技术,移动支付,移动安全,Android
Abstract
E-wallets have started to grow in popularity, reaching a tipping point in some countries. This can be attributed to the worldwide use of payment-enabled devices and ubiquity of e-wallet acceptance by larger and smaller retailers. As more customers adopt e-wallets they may also becomeabigtargetofcybercrime.E-walletsfacilitatesfinancial transactions via smartphones which is a lucrative opportunity forcybercriminals.Thispaperpresentsasecurityassessmentof the Android e-wallet apps of several Canadian leading banks.
Keywords:E-Wallets, HCE-NFC Technology, Mobile Payments, Mobile Security, Android
目录
1.引言
传统的智能卡银行服务现在正在转向智能手机。近距离通信(Near Field Communication,NFC)技术促进了这一转变,该技术使智能手机能够使用电子钱包应用模拟信用卡。这种模拟通常由“安全单元(Secure Element,SE)”硬件或使用主机卡仿真(Host Card Emulation,HCE)提供保障。SE 移动支付解决方案依赖于高度安全的防篡改芯片,该芯片以加密的形式在设备上本地存储信用卡数据;而另一方面,HCE解决方案只使用软件,并允许NFC应用程序在云端托管数据。在这个背景下,我们定义电子钱包为:一种通过在设备或云端存储客户的信用卡信息和其他支付数据来方便商业交易(通过NFC通道)的软件应用。
与智能手机上的其他应用相比,电子钱包移动应用的本质决定它需要更高级别的安全性,这一点是显而易见的。虽然目前没有指导银行移动应用开发的具体法规出台,但各种金融机构经常向客户提供如何确保交易安全的建议。在2012年,加拿大银行家协会(Canadian Bankers Association,CBA)发布了《NFC移动支付参考模型》,为移动支付提供了一套自愿指导方针。在 2015,他们向银行社区提出了一个题为“移动支付安全白皮书”的更专业的方针[1]。
随着移动支付越来越受欢迎,他们也吸引了网络罪犯的注意。在2017中,趋势科技(Trend Micro)[2]在移动银行恶意软件样本中发现了94%的异常增长。这些样品的建立伴随了更为复杂的功能,用以躲过雷达的监测。它们通常与合法流程混合或冒充为一体,窃取的不仅仅是信用卡数据,并绕过安全机制。
普通的安全社区最近才开始以整体的角度关注与移动支付系统相关的风险,其重点是防范支付网络中的交易欺诈,或者防范NFC攻击。不幸的是,安全工作似乎分散了,移动支付应用程序的基本安全性似乎经常被忽视。移动设备上金融数据的安全性是人们关注的主要问题之一,基于此,一些研究人员对不同移动支付应用程序(特定国家的)进行了安全性评估,并且发现这些应用程序的开发并没有考虑到足够的安全性。
本文提出了一套电子钱包应用安全的建议,该建议主要针对Android平台。根据F-secure的评估,99%的现有移动恶意软件以Android设备为目标[3]。这主要是由于Android平台对于应用程序开发的开放性。我们提出的安全建议是基于CBA[1]提供的安全指南和OWASP“移动风险前十排行榜(Top 10 Mobile Risks)”。根据提出的指南中的内容,我们进一步评估加拿大主要银行的电子钱包银行应用程序的安全性。在我们的分析中,我们发现所有参与评估的应用都是脆弱的。
该论文的提醒组织如下:第二节介绍了相关工作;第三节讨论了所获得的安全规则进行分析;第四节解释所提出的方法和所使用的数据集;第五节突出说明进行安全评估的结果;第六节提供总结意见。
2.相关工作
本节简要回顾了对不同国家不同类型移动支付应用程序进行的现有安全评估。Filiol和Irolla[4]对50个Android移动银行应用程序进行了静态和动态分析。在静态分析方面,他们通过探索未知软件与已知的恶意软件行为相似之处来检测恶意软件的方法开发了一个原型,这种检测主要基于应用程序特性,如权限,调用API(Application Programming Interface,应用程序编程接口),入口点,恶意字符字符串,操作码等——以用于在动态分析运行时对网络通信进行检查。其报告称,几乎所有的应用程序都危及用户隐私。Reaves等[5]对七个Android移动货币应用程序进行了广泛的手动分析——包括AirtelMoney、mPay(支付宝)、OxigenWallet、Gcash、Zuum、MOM和mCoin。他们检查了这些应用程序的SSL/TLS漏洞、加密、访问控制和信息泄漏几个方面。为了识别SSL/TLS漏洞,作者将他们的手动分析结果与Mallodroid2和QualysSSL服务器测试工具3结合;Chothia等[6]报道了英国主要银行提供的移动应用的安全审查,作者分析了来自15家英国银行的Android和iOS应用。他们的主要重点是识别这些应用程序在TLS实现中的漏洞。他们报告说,应用程序没有正确实施证书锁定和主机名验证技术,因此容易受到中间人和钓鱼攻击;Kim等人[7]专注于应用程序安全,调查在韩国76个金融Android应用程序中所使用的运行时完整性保护机制。作者开发了一个名为MERCIDroid的工具,从运行时API跟踪记录中提取一个迷你调用图,以定位应用程序用来保护它们的自卫机制。提取的API调用属于用于检查设备最高管理员权限root,应用程序完整性和停止应用程序执行的代码。作者报告说,在Android金融应用中使用的自我防御机制是无效的,可以被很容易地绕过;另一方面,Nguyen-Vu等人[8]关注设备安全,研究了不同的方法来检测植根于Java和本地代码级别的设备。他们在韩国测试了18个银行和金融移动应用。他们发现,在18个应用程序中就有10个可以通过静态文件重命名被轻松回避。应用程序只使用本机代码来检查是否存在关闭二进制文件和其他系统包名称。这个检查通过简单的重命名技术就被绕过,而不需要拦截任何本地调用;Yang等人[9]研究了嵌入第三方支付功能的中国移动应用程序。作者研究了四家主流第三方移动支付收银设备。调查显示,其第三方SDK设计不当,且有脆弱的样本代码。Rajchada等[10]对泰国的7个Android移动银行应用程序进行了取样分析和安全评估。研究人员发现,这些应用程序分析了泄露的个人用户信息,如账号、账户余额、公民身份、出生日期、用户PIN码等。此外,据报道,一半的应用程序没有实现根设备检测、不加密用户数据以致容易被修改和重新包装。
前人在这方面的研究重点是Android移动支付应用程序在不同市场的安全问题,如英国、科雷亚、中国、泰国,其评估工作是孤立的、有针对性的,处于应用程序级别、设备级别或通信级别。以往的研究都没有提供一个综合的安全观,而这正是我们研究的重点。此外,本文也是第一篇评估电子钱包在加拿大市场的文章。根据统计信息,加拿大各地的移动支付者正在稳步成为移动钱包用户4。为了帮助移动支付用户过渡到移动钱包用户,电子钱包应用程序开发人员和所有者应该通过展示移动钱包中运用的安全和隐私证明来缓解用户的担忧。因此,我们的主要目标是评估电子钱包银行应用程序在加拿大市场的安全性。
3.安全特性
为了对NFC-HCE电子钱包Android应用程序进行安全评估,我们首先定义了特定的安全规则集。首先,我们从应用程序中提取一个最小特征集。此初始集将应用程序定义为可能的电子钱包。如果不满足主要特性,我们就放弃这个应用程序。在这里我们主要寻找NFC-HCE的使用权限,然后我们提取其余的特征,以确定电子钱包应用程序是否符合最佳安全实践。从CBA和OWASP“前十移动风险排行榜”提供的安全建议中获取的建议的安全集合和规则构成了我们评估的核心。
根据CBA的白皮书[1],一个安全的HCE解决方案需要多个安全层。分层的安全设计使得攻击者很难从设备上窃取令牌,并在其被盗后重新使用它们。包括以下四个安全层:应用安全、设备安全、通信安全和动态数据。前三层对于保护设备上令牌的存储和防止令牌盗窃至关重要。在令牌盗窃事件中,动态数据对于防止令牌被使用和/或限制它们的使用方式至关重要。
应用程序安全:确保电子钱包应用程序没有被损坏。它包括正确使用混淆,白盒加密和可信执行环境(Trusted Execution Environment,TEE)。它的目标是保护存储在设备上的支付密钥和其他敏感数据。
设备安全:确保设备没有被损坏。检测机制包括root、调试和仿真检测。这些场景通过暴露通常受保护的设备区域来降低HCE解决方案的安全性。
通信安全:确保电子钱包应用程序与支付网络之间通信的安全和保密性。如果通信被截获和破解,就有可能窃取动态数据提供给设备和执行假交易。
动态数据:确保防范与可能的盗窃和拦截支付凭证有关的风险。HCE使用不断变化的支付数据。因此,动态凭据在过期之前可能会受到使用次数、时间段或两者的限制。
另一方面,OWASP“前十移动风险排行榜”(M1至M10)在移动应用程序开发过程中提供了更好的安全指南。因此,我们编译了来自CBA的安全层和来自OWASP的安全实践,以获得一组广泛的规则来审查电子钱包应用程序的安全性,如表I所示。部分规则用OWASP移动风险号标记{M1、M2、M3、M5、M8、M9、M10},表明它们直接对应于特定的移动风险。
表1 评估一个电子钱包应用程序的安全规则
资料编号:[5538]
分类 |
派生安全规则 |
最小原则:把这个应用程序定义为一个可能的电子钱包应用程序的一类原则。 |
bull;安卓4.4或更高版本 bull;使用NFC-HCE权限 bull;没有第三方广告库 |
设备安全规则:这一系列的规则确定设备是否被破坏。 |
bull;无根设备{M8} bull;不能在模拟器上运行 |
应用程序安全规则:这套规则用于证明应用程序是否受信任 |
bull;自验证完整性{M8} bull;受保护的应用程序(模糊或包装) bull;没有可调试标志{M10} bull;没有旧版本 |
通信安全与动态数据规则:这套规则确保了传输中应用数据的保密性。 |
bull;Https强制{M3} bull;固定正确证书{M3} bull;没有弱加密{M5} bull;正确的密钥管理流程{M1},{M9} |