CN110313005B

CN110313005B - 用于设备应用的安全性架构

Info

Publication number: CN110313005B
Application number: CN201880012994.5A
Authority: CN
Inventors: M·阿布艾尔恩宁; P·斯梅茨; M·沃德; D·A·罗伯茨
Original assignee: Mastercard International Inc
Current assignee: Mastercard International Inc
Priority date: 2017-02-21
Filing date: 2018-02-13
Publication date: 2024-01-30
Anticipated expiration: 2038-02-13
Also published as: WO2018156382A1; US20180240111A1; EP3364329A1; EP3364329B1; CN110313005A

Abstract

计算设备实施应用(42)的安全性架构。该安全性架构具有用于存储第一密码材料的非易失性存储装置(43)和用于存储第二密码材料的易失性存储装置(51)。第二密码材料在计算设备重新启动时丢失。至少第二密码材料可以从计算设备外部但能通过计算网络访问的源补充。还描述了由应用使用这种架构的方法。

Description

用于设备应用的安全性架构

相关申请的交叉引用

本申请要求于2017年2月21日提交的欧洲专利申请No.17157273.8的权益和优先权。上述申请的全部公开内容通过引用并入本文。

技术领域

本发明涉及用于在计算设备上执行的应用的安全性架构。在实施例中，它涉及移动应用安全性，以及移动应用对于敏感资产的使用，特别是用于移动支付应用的实施例。

背景技术

智能设备和智能电话正变得越来越普遍，全球智能电话销量从2009年的不足2亿增加到2015年的13亿以上。移动和通信技术的改进也允许智能设备和智能电话的新的和替代的使用。一个示例是近场通信(NFC)技术的发展及其在非接触式支付交易中的使用。许多智能电话及信用卡和借记卡(如果符合EMVCo在主要卡提供商的支持下开发的标准，那么通常称为“EMV卡”)现在配备了NFC芯片，使得能够安全地发送支付细节，因此用户只需向销售点终端“触摸”或“点击”电话或卡以处理支付交易。

以前，使用NFC通信进行支付交易需要设备具有安全元件(SE)芯片，其用于安全地存储支付凭证。这当然适于由发行方(诸如用户的银行)生产的EMV卡，因为发行方可以在SE芯片中使用他们的优选平台。但是，在移动设备的情况下，任何数量的发行方必须使用一个SE，这会在所有权和访问权限方面产生问题。此外，一些移动设备可能没有安全元件。因此，以其他方式配备用于非接触式支付或远程支付的移动设备将无法实施此类交易。

为移动设备中的支付交易提供安全元素的替代方案是使用受信执行环境(TEE)-这是由移动设备的主处理器提供的隔离的执行环境，其适于使得其中加载的代码和数据与主操作系统隔离。TEE与移动设备的主操作系统(有时称为富执行环境或REE)并行操作，并且处理TEE中的支付交易的某些方面提供了附加的安全性，例如因为代码受到完整性保护。

但是，在SE之外存储凭证需要替代方法来保护用于支付交易的凭证。例如，永久卡号(PAN)通常本地存储在移动应用中，这虽然方便，但不安全，因此这个数据元素常常被“标记化(tokenised)”，用非敏感值替换PAN并引入域限制，从而允许这个值仅在具体条件下使用。另一个示例是从远程安全数据存储库创建和传送单次使用交易密钥，而不是使用移动设备处的账户级别密钥。单次使用交易密钥使移动应用能够仅执行单个交易，而账户级别密钥允许它进行大量交易。

密码密钥的有效使用和管理一般而言对于交易系统是重要的，并且在卡或用户凭证存储在除SE以外的地方的情况下尤其相关-例如在申请人的早期WO2015/084755中讨论了解决方案。当移动设备需要在离线模式以及在线模式下操作时，交易系统中的密码密钥的管理和使用可能特别具有挑战性。期望用户能够在离线环境中尽可能地进行安全有效的交易，即使在外部系统元件不可用时。

发明内容

在第一方面，本发明提供了一种计算设备，实施用于应用的安全性架构，所述安全性架构包括用于存储第一密码材料的所述计算设备的非易失性存储装置和用于存储第二密码材料的所述计算设备的易失性存储装置，其中第二密码材料在计算设备重新启动时丢失。

这种方法允许灵活的方法，其允许应用在广泛的各种情况下使用，同时提供对子版本或攻击的有效保护。

在一种布置中，所述安全性架构适于使得至少第二密码材料从所述计算设备外部但能通过计算网络访问的源补充，其中所述应用适于使用第一密码材料以及在能使用的情况下的第二密码材料来执行动作，其中该动作的输出指示第二密码材料是否可用。

由于第二密码材料在重新启动时丢失，因此这种方法允许有效防御重新启动攻击，因为这些需要重新启动才能完成。

在另一种布置中，所述安全性架构适于使得第一密码材料包括第一部分和第二部分，其中所述应用适于使用第一密码材料执行动作，其中仅在满足使用条件的情况下才使用第一密码材料的第二部分，其中如果不满足使用条件，那么仅使用该密码材料的第一部分，其中该动作的输出指示使用第一密码材料的哪些部分。

当采用这种方法时，安全性架构可以提供移动计算设备处的用户的核实。如果是，那么第一密码材料可以包括完成的核实材料和未完成的核实材料，并且其中如果用户在移动计算设备处被核实，那么该动作使用完成的核实材料，并且如果用户在移动计算设备处未被核实，那么使用未完成的核实材料。这个完成的核实材料可以由所述计算设备的操作系统提供的密钥库以加密方式生成，并且其中密钥库可以被配置为仅在成功的用户核实之后执行密码操作。

这种方法保留了应用的可用性，同时允许其它方(诸如交易应用的发行方)有效地确定与用例相关联的风险。

非易失性存储装置可以包括由计算设备的操作系统提供的密钥库，并且第一密码材料包括密码密钥。密码密钥可以包括一个或多个单次使用密钥和长期使用密钥中的一个或多个。

在这种配置中，当使用第一密码材料执行操作时，所述应用在能使用的情况下使用单次使用密钥之一，而在没有单次使用密钥能使用的情况下使用长期使用密钥。在这种情况下，如果在执行动作时使用长期使用密钥时，那么该动作的输出可以指示使用了长期使用密钥。

在使用这种配置的情况下，所述安全性架构可以适于仅在注入密钥库在预定时间内完成时才使用密码密钥。

第二密码材料可以包括为一次使用而生成的加密的易失性整数。如果是，那么计算设备可以适于在设备重新启动时请求一个或多个易失性整数。

在实施例中，计算设备是移动计算设备。用于在移动计算设备上执行的应用可以是支付应用，并且动作可以包括在执行交易时密码的生成。

在第二方面，本发明提供了一种在具有非易失性存储装置和易失性存储装置的计算设备上准备和执行应用的方法，所述方法包括：将第一密码材料存储在非易失性存储装置中并将第二密码材料存储在易失性存储装置中，其中第二密码材料在所述计算设备重新启动时丢失；从在所述计算设备外部但是能通过计算网络访问的源补充至少第二密码材料；以及所述应用使用第一密码材料以及在能使用的情况下的第二密码材料来执行动作，其中该动作的输出指示第二密码材料是否可用。

在第三方面，本发明提供了一种在具有非易失性存储装置和易失性存储装置的计算设备上准备和执行应用的方法，该方法包括：将第一密码材料存储在非易失性存储装置中并将第二密码材料存储在易失性存储装置中，其中第二密码材料在所述计算设备重新启动时丢失，并且其中第一密码材料包括第一部分和第二部分；所述应用使用第一密码材料执行动作，其中该密码材料的第一部分用于执行该动作并且在满足使用条件的情况下该密码材料的第二部分也用于执行该动作，其中该动作的输出指示使用第一密码材料的哪些部分。

附图说明

当结合附图阅读时，从以下对示例性实施例的详细描述中可以最好地理解本公开的范围。附图中包括以下图：

图1示意性地示出了适于实现本公开实施例的代表性交易系统的相关部分；

图2示出了适于与本发明实施例一起使用的移动支付基础设施的功能元件；

图3a、3b和3c示出了用于在图2的基础设施中的移动设备中运行移动支付应用的不同计算环境。

图4示出了移动支付应用与用于执行本发明实施例的合适操作环境的交互；

图5示出了用于图4的布置的安全性架构；

图6示出了用于图5的安全性架构的密钥库的示例性布置；

图7示出了与图5的安全性架构一起使用的密钥注入的示例性处理；

图8示出了用于图5的安全性架构的密钥的示例性组织；

图9示出了用于图5的安全性架构的示例性密钥交换和密钥注入代码；

图10A和10B分别示出了在用于M/芯片的示例性实施例中的字节1和字节2CDCVM数据；以及

图11示出了用于磁条(MagStripe)的示例性实施例中的CDCVM数据。

具体实施方式

下面将参考附图描述本发明的具体实施例。

图1示意性地示出了适于实现本公开实施例的代表性交易系统的相关部分。

向用户(未示出)提供有支付设备-在所示实施例中，这是通过使用支付应用来充当用于支付卡1的代理(代理可以针对物理卡，或支付卡可以仅仅是虚拟的-或者在下面将被称为“数字化卡”)的移动电话或其它移动计算设备(“移动设备”)2。在其它实施例中，其它类型的计算设备可以用作支付设备。这样的计算设备将具有处理器和用于存储包括由相应处理器运行的固件和应用的信息的存储器，在这种情况下，应用之一是支付应用。支付设备通常将配备有与支付基础设施的其它元件通信的手段。这些通信手段可以包括天线以及相关联的硬件和软件，以使得能够通过NFC和相关联的非接触式卡协议(诸如ISO/IEC14443中定义的那些协议)进行通信，或者这些通信手段可以包括天线以及相关联的硬件和软件，以允许使用802.11协议或任何适当的替代方案进行本地无线联网。

常规基础设施中的其它计算机装备通常是固定的，但是在感兴趣的交互点(POI)的情况下，终端4也可以是移动的。所示的示例是由与用户交互的商家使用的移动销售点(MPOS)终端。这种装备通常以安全的方式(或者通过专用信道或者通过公共或不安全信道上的安全通信机制)连接或可连接到收单银行6或其它系统。还可以存在允许用户计算机设备与卡发行银行5或与用户相关联的系统之间的连接的机制。银行基础设施7还将连接卡发行方5和收单银行6，从而允许在它们之间执行交易。

与银行基础设施7相关联的还有一个或多个基础设施服务器8(虽然在这里表示为单个服务器，但是这当然可以包括任何适当的计算机系统或计算机系统集合)。基础设施服务器8可以被认为是银行基础设施7的一部分-基础设施服务器8或者与其集成或者以紧密的信任关系与其绑定，使得银行基础设施7可以有效地保证其他方与基础设施服务器8的通信可以被信任。这意味着如果另一方信任银行基础设施7，那么该另一方也应当信任基础设施服务器8。基础设施服务器8被示为与用户移动电话2和银行基础设施的其它元件交互。

图2更详细地示出了用于使用数字化卡的移动支付的示例性互联网支持的(“基于云的”)基础设施中的系统部件所承担的功能角色。这些功能角色如下所述。

账户启用系统(AEnS)21可以由卡发行方或由与卡发行方相关联的服务提供。AEnS21负责在系统上设置和建立用户和卡-它负责用户(持卡人)登录(onboarding)处理、持卡人识别和核实处理(ID&V)以及卡数字化处理。

凭证管理系统(CMS)22负责移动支付应用(MPA)23的远程管理。这涵盖支付凭证(诸如支持交易所需的卡简档和密钥之类)的递送。它还覆盖可以在内部或由其它系统元素触发的远程管理功能。CMS 22还负责补充MPA 23(例如，确保其具有足够的单次使用密钥供应以允许其继续执行支付交易)。

交易管理系统(TMS)24由交易基础设施的元件提供，一起负责使用数字化卡进行交易的分析和随后的批准。TMS 24以与常规交易基础设施相同的方式针对授权处理的金融部分与发行方5交互，发行方负责交易的批准。

MPA 23使用户能够与数字化卡交互，既用于卡管理又用于在POS终端处执行非接触式交易或使用其上安装有MPA的移动设备的网络连接性来执行远程支付交易。支付凭证以数字化形式接收并且在移动设备上加密存储。

在CMS 22和TMS 24之间存在同步链路以监视在系统上执行的交易。这个链路还可以用于支持欺诈检测，并可能阻止数字化卡进一步交易。

如上所述，移动设备2可以是能够执行用于执行交易的所需功能的任何类型的移动计算设备。移动设备可以包括或可以不包括安全元件，即使在不用于密钥管理的情况下，该安全元件也可以用于附加的安全性。移动设备可以是智能电话、可穿戴智能设备或诸如平板电脑之类的移动计算机。移动支付应用23被下载并在移动设备2上运行。移动支付应用23可以由发行方5提供，或者替换地可以由第三方提供。如上所述，移动设备2有可能包括多个移动支付应用23，所有这些应用都与安全的存储器区域通信(如下面所讨论的)。以这种方式，移动设备2的用户可以选择最适于特定交易的移动支付应用23。此外，移动支付应用23可以存储与用户或用户账户相关联的信息，例如用户帐单地址和标记化的主帐号(PAN)。此外，在本发明的布置中，移动支付应用23可以存储具有与每个单次使用交易密钥相关联的值的应用交易计数器(ATC)-这提供了对在移动设备2上发起的每个交易的唯一引用。作为这种布置的进一步扩展，移动支付应用23可以维护其应用交易计数器(ATC)，以便在其用完单次使用交易密钥和相关联的ATC值时使用。

移动支付应用23与CMS 24进行双向通信，并且可以使用多个通信信道，诸如增加数据传输的安全性并确保数据被递送到预期设备的双信道通信。

TMS 24可以包括接收和发送单元、处理器、账户数据库以及存储器存储单元。TMS24可以被配置为使用接收并存储的数据处理授权请求并执行诸如欺诈分析和密码验证之类的功能。TMS 24可以被配置为在账户数据库中存储与用户账户相关联的接收数据，包括密钥、交易数据或个人信息，以及从账户数据库中回调(recall)数据。账户数据库被配置为存储用于多个用户账户的信息。

发行方5可以是机构，通常是诸如银行之类的金融机构，其向与该机构注册的交易账户相关联的消费者发行支付凭证。发行方5至少包括发行方服务器，以执行如本文所述的用于处理支付交易所需的动作。应该理解的是，这不是限制性的，并且发行方服务器还可以执行本文所述的支付交易或者交易的替代可能实施例(包括基于云的交易)不需要的多个附加动作。发行方5可以向TMS 24或CMS22供应支付凭证。发行方服务器还可以包括用户账户数据库，其中存储用户和用户设备信息、数据和支付交易信息。这可以是TMS 24上的账户数据库的补充，或者两者可以在TMS 24中组合在一起。

CMS 22适于执行各种功能，包括用于生成单次使用交易密钥所需的功能，如将进一步讨论的。CMS 22可以包括接收和发送单元、处理器和存储器存储单元。CMS 22可以被配置为安全地存储支付凭证和密码密钥，并在需要时将这些提供给TMS 24。可替代地，TMS 24可以直接从账户启用系统(AEnS)接收相关的安全材料。CMS 22还将支付凭证和密码密钥安全地直接传送到诸如移动密钥库之类的安全存储器区域，如下面进一步讨论的。

TMS 24、发行方服务器和CMS 22都可以被实现为经由硬件和软件提供的一个或多个计算设备，以执行相关功能，包括密码功能，如上面一般性描述并在下面更详细描述的。TMS 24、发行方服务器和CMS 22可以通过适当的且可能多个通信信道彼此(并且在适当的情况下，与移动支付应用)通信。支付凭证可以包括与支付交易有关和/或在支付交易中使用的任何数据或信息，并且可以包括密码、密码密钥和通知消息，其中示例是主帐号(PAN)、卡安全性代码(CSC)和卡到期日期。

在图3a、3b和3c中功能性地图示了如图2所示的移动支付应用(MPA)，其图示了用于实现本发明实施例的替代计算环境。这些计算环境由存储在移动设备的存储器中的合适软件提供，并由具有相关联硬件的移动设备的处理器执行。

中央业务逻辑31负责数字化卡的整体管理。敏感数据可以存储在或者安全元件(SE)37(图3a)或者受信执行环境38(图3b)中的安全存储器区域32中，或者可以被实现为受信结构，诸如在主操作环境30(图3c)中维护的密钥库39。核心支付功能33在这里由适当的软件提供，其中支付能力库34也由移动应用提供以支持远程支付。

MPA在本地存储单次使用支付凭证，从而允许其进行非接触式交易而无需在交易时连接到CMS。MPA确实具有远程管理系统35，用于在需要管理时与CMS通信，并且还支持MPA的业务逻辑以回答来自CMS的任何回叫请求。这种交互当然需要适当的网络连接性。用户体验36包括用户界面。

MPA可以是移动设备上的若干支付应用之一-这些支付应用可以共享公共安全存储器区域，或者每个支付应用可以具有其自己的安全存储器区域。每个MPA适于优选地根据提供行业标准的相关的EMVCo规范执行与另一方的交易(例如，与POS终端或自动售货机的非接触式交易)。相关标准在https://www.emvco.com/specifications.aspx上找到-例如，非接触式交易标准在https://www.emvco.com/specifications.aspx？id＝21找到。在执行交易时，MPA将需要在卡动作分析期间生成至少一个密码(参见https://en.wikipedia.org/wiki/EMV#First_card_action_analysis)。用于不同目的的密码通常将包含或保护不同的内容，但是将包含或保护相关方的交易细节和凭证(或使用此类凭证的指示)，所有这些都利用适当的密钥保护完整性和真实性。对于根据EMV标准及其使用来创建密码的一般方法，技术人员将参考在https://www.emvco.com/specifications.aspx上找到的标准以及与根据这些标准的密码创建相关的材料，并且密码创建和使用将不在这里详细讨论。关于与这种架构相关的密码创建的更多讨论可以在申请人的同一日期的共同未决的申请中找到，该申请的名称为“Transaction Cryptogram”，其内容在适用法律允许的范围内通过引用并入。本公开一般而言涉及使用密钥的风险管理，以及适用于与风险评估相关的交易的因素的指示。

MPA与用于执行本发明实施例的适当操作环境的交互在图4中示出，对应的安全性架构在图5中示出。在图4的布置中，Android用作操作系统，并且使用Android术语描述某些具体特征。技术人员将认识到的是，可以使用或适于以类似方式使用在其它操作系统中或与其它操作系统一起提供的等价功能。

图4示出了MPA 42与Android操作环境41交互，在这种情况下是Android“M”(Marshmallow)或更高版本。这一代Android支持对称密钥加密及其与密钥库的使用。图4图示了由Android M提供的某些功能，这些功能在图5的安全性架构中使用。Android操作环境41能够提供供应用使用的密钥库43-可以在一个操作环境中或针对单个应用提供多个密钥库实例。密钥库(例如在https://developer.android.com/training/articles/ keystore.html中讨论的)是密码密钥的容器，其允许使用密钥而不会使密钥本身易于导出。

图4还示出了生物识别应用44与MPA 42交互。Android操作环境还支持生物测定应用所需的功能-例如，FingerprintManager作为API提供，以支持利用指纹扫描进行用户认证(参见https://developer.android.com/about/versions/marshmallow/android-6.0.html)。此外，MPA 42可以访问通信接口45以允许它与交易网络中的其它元素建立连接-对于安全性架构和密钥的补充以及凭证的管理，与CMS的连接特别重要。

图5图示了系统的基本安全性架构。MPA 42可以访问多个密钥库43(如下面更详细地讨论的)，每个密钥库保持MPA 42使用的一个或多个密钥。这些密钥库43是非易失性的并且因此将在断电时保持状态-将密钥注入密钥库将在下面更详细地描述。附加的密码材料52可以存储在易失性存储器51中(在这种情况下，它需要在重新启动或电源循环时补充)，但是将在适当的密钥(包装密钥)下受到保护，如下面所讨论的。在需要时以及在可能时将建立安全信道53，以允许CMS与MPA 42连接以管理凭证，以及管理密钥库中的密钥(特别是用于一次密钥的补充)。CMS包括密钥54(具有为由MPA 42使用的密钥库43创建新密钥的能力)和用于MPA 42的凭证材料55。

用于MPA的密钥库的示例性布置在图6中示出。MPA 42可以表示已经数字化到MPA42中的多个卡61(或者虚拟卡或者物理卡的代理)，并且为每个卡61提供两个密钥库，在这里称为CAMGuard 62和CVMGuard 63。使用两个密钥库作为MPA 42适于在两种不同的交易机制中起作用。用于消费者设备的移动支付应用通常采用由设备支持并且由交易网络允许的一种或多种类型的消费者设备持卡人核实方法(CDCVM)-根据EMV协议使用CDCVM在下面进一步讨论(包括在附录中)，并且在https://developer.android.com/training/articles/keystore.html中讨论相关的密钥库实现。典型的CDCVM类型是PIN和用户生物测定。在这种布置中，某些密码材料只能在成功的CDCVM之后被访问-例如，因此CDCVM可以对于更高价值的交易是必需的。在这种情况下，只能以CDCVM为条件被访问的材料受CVMGuard 63保护，不以CDCVM为条件的材料受CAMGuard 62保护。在实施例中，还可以提供密钥库的主实例MPAGuard 64-下面讨论使用和不使用MPAGuard 64的两种布置。

如在上面识别出的EMV规范中所讨论的，交易涉及由卡(或代表卡的移动支付应用)创建应用密码(AC)作为交易处理的一部分。AC可以取决于交易的性质而不同地构建，但重要的是表明交易是正确形成且合法的，并且它提供信息以允许卡发行方做出授权决定并且可以用于清算。在下面的表1中指示在这里描述的实施例中使用的安全性模型中在交易处理中，特别是在AC的生成中，使用的密码和其它材料。

表1

下面将简要描述典型的交易处理以提供实施例中描述的安全性架构的上下文-进一步的细节可以在本说明书中其它地方讨论的附加材料中找到。CMS为MPA提供密钥(通常是一次性使用密钥)以在会话(通常是交易)中使用–在必要时以及在CMS和移动设备之间存在连接时，这些密钥将得到补充。如下面参考实施例所讨论的，这种材料以适当的安全方式保持，并且可能需要用户认证以释放以供MPA使用。然后，移动支付应用使用这种材料产生应用密码(AC)，从而充当用于交易信息的消息认证代码的形式。因此，交易消息的真实性由仅由发送方和接收方知道的密钥保护。在这种情况下，所采用的方法允许由TMS或发行方在必要时确定消息内容。在从发送方接收到AC时，接收方执行验证/认证处理，其中使用密钥材料来重新计算AC。如果从移动设备接收的AC与接收方生成的交易密码匹配，那么接收方可以确保在传输期间没有更改该消息。

应当注意的是，存在可以潜在地用于创建应用密码-OTUK和LTUK的两种密钥类型。通常的方法将是使用OTUK，但这只有在移动设备或者存在OTUK或者从CMS补充其供应时才有可能。如果由于任何原因这是不可能的话，LTUK充当后备，尽管在处理交易时可以考虑使用LTUK而不是OTUK。如下面所讨论的，在本发明的实施例中使用的密钥交换和密钥注入方法可以用于LTUK或用于OTUK，但是注入密钥的情形将有所不同-当移动设备已经或很快就会耗尽时将提供OTUK，而LTUK将根据适当的密钥刷新标准(诸如总使用周期或支付应用已被使用的次数)进行刷新。

在这里描述的实施例中，密钥交换和密钥注入涉及CMS和密钥库之间的协作。在需要移动应用和CMS之间的公共对称密钥的具体布置中，这种对称密钥可以由CMS生成并在由密钥库生成的公钥下加密。

密钥注入所采取的方法将取决于操作系统-从Android“O”开始，将可以安全注入到密钥库(和从密钥库导出)，但在此之前需要采用实际的风险管理方法。可以通过移动支付应用和CMS处理的设计和实现来减轻风险，例如通过确保CMS只能在清楚解密和注入之间经过的时间非常短时(通过检查形式“经过的时间<允许的时间”)才可以使用密钥。如果不是这种情况，那么必须利用新密钥重复该处理。

用于这个处理的示例性代码示于附录A中，消息流程如图7所示。

如上所述，在实施例中所示的布置中，由MPA使用的一些密码材料将保持在非易失性存储器中，并且一些密码材料保持在易失性存储器中。由于密钥库使用非易失性存储器，因此存储在密钥库中的密码材料在断电和重新启动时幸免。但是，这也意味着如果设备已启动，那么存在未经授权使用的某种可能性。

但是，这种布置中的一些密码材料存储在密钥库之外，受到由密钥库管理的包装密钥的保护。由于存储在RAM中，因此这种材料将在断电时被擦除-这可能在启动后发生，或者可以只是夜间断电。在实施例中，这种材料的重新供应的条件是使用Google的SafetyNet设备兼容性检查成功通过远程证明。如果缺乏数据连接性(例如，漫游)，那么可能无法总是及时完成重新供应-因此，期望提供允许在重新供应能够发生之前使用一些MPA的后备场景。

在图8所示的实施例中，存在一个“主”AES密钥和三个特定于卡的AES密钥。所有密钥都注入密钥库的实例。它们使用上面的密钥注入协议被放入密钥库中，并且如果由于或者MAC或者定时失败而导致注入失败，那么在不使用密钥的情况下丢弃密钥并生成新密钥。如上所述，使用“主”AES密钥是可选的。这种布置在下表2中总结。

表2

一旦注入所有密钥，则不同(AES)密钥的组织就如图8所示。要注意的是，未示出由密钥库的不同实例针对对称密钥交换生成和使用的公钥。如前面所提到的，这些密钥的注入应当是时间界定的，具有在之前和之后使用的证明。如果发现任何问题，那么应当丢弃该密钥，并利用新密钥重新运行该处理。

在使用MPAKey的实施例中，可以使用如下布置：所述布置使用在不同时间注入的密钥之间的依赖性的创建：MPAKey密钥可以在实例化和激活移动支付应用时被注入MPAGuard，特定于卡的密钥在卡数字化时被注入CAMGuard和CVMGuard。

如前所述，密码通常将包含或保护不同的内容。在这种情况下，除了其它数据之外，密码还可以包括CDN或VI。CDN和VI的目的是不同的。

如前所述，VI由CMS利用CAM Key的副本加密。这个特定于卡的密钥注入CAMGuard并且用于解密用于计算用于卡认证的应用密码的OTUK和VI。由于VI是易失性的，因此在断电时被擦除。由于必须断电以开启设备，因此VI是用于设备启动的保护/检测工具。VI的可用性不以成功的持卡人核实为条件。

M/芯片和非接触式磁条二者在密码计算中包括CDN作为CDCVM的证据。CDN(消费者设备持卡人核实方法动态号)是根据密钥库中保持的材料(具体而言是为此目的注入CVMGuard的CVMKey)与ATC组合创建的，并在成功核实时发布。与CAMKey相比，CVM Key以成功的CDCVM为条件。密钥库将仅在CDCVM成功时计算新的CDN(用于ATC)，并且仅用于放置CVM密钥的应用。与CVM密钥类似，CAMKey是非易失性的。相关讨论可以在申请人的同一日期的共同未决的申请中找到，该申请的名称为“Transaction Cryptogram”。

对于不同的交易类型，这种布置(这里在没有MPAKey的情况下进行描述)的功能如下所述。讨论了两种交易类型：M/芯片(MasterCard专有的EMV解决方案，用于支付卡上的芯片)和非接触式磁条(特别是在美国使用，以使用来自磁条协议的数据启用非接触式交易)。

应用交易计数器(ATC)是M/芯片和非接触式磁条解决方案之间的通用元素。M/芯片和非接触式磁条都使用ATC作为用于应用密码的输入。如果OTUK可用-每个OTUK链接到ATC–那么使用来自OTUK的(最低)ATC，并且随后使这个OTUK失效。如果没有可用的OTUK，那么应用取最后一个OTUK的ATC并且为每个交易将其递增1。当CMS最终再次联系时，移动支付应用通知CMS其使用的最新ATC。CMS将从移动设备在其ATC使用中达到的点开始递送新的OTUK。

M/芯片实现-M/芯片发布有用于应用密码和发行方动态号的OTUK和VI，以包括在CDA签名中并用于RRP(中继电阻协议)中。CDA(组合的DDA/生成应用密码)是密码卡验证检查，其中动态数据认证(DDA)与应用密码的生成相结合(这在EMV标准中进一步详细描述)。

例如，从ATC＝1开始：

·{1，OTUK_CL1，OTUK_RP1，IDN1，VI1}

·…

·{n，OTUK_CLn，OTUK_RPn，IDNn，VIn}

每次发起M/芯片交易时，OTUK和VI都被解密并用于计算应用密码。ATC值以明文形式可用。如果使用CDCVM完成交易，那么使用与交易相同的ATC来计算CDN值。如果未执行成功的CDCVM，那么密码输入中不存在CDN。包括/排除CDN由附加认证数据中的位来指示。

当设备重新启动并且VI值已被擦除时，密码输入中不存在VI。OTUK在重新启动后仍然存在，因为它们存储在永久存储器中。VI的包括/排除由附加认证数据中的位来指示，使得TMS可以调整其加密处理并在其欺诈检测引擎中引发必要的标记。缺少VI还会触发移动设备联系CMS以发起远程证明并请求重新供应OTUK和VI。

直到OTUK和VI被递送之前，移动应用继续使用可用的OTUK进行非接触式交易，但没有VI。在没有VI的情况下不允许远程交易。要注意的是，只要移动应用使用OTUK(有或没有VI)，CVN(密码版本号-可以从中推断出相关的处理步骤)就指示会话密钥的使用。

如果移动应用耗尽OTUK，那么它代替地使用LTUK密钥。对于具有这个LTUK密钥的每个交易，ATC递增。从OTUK到LTUK的切换由CVN指示，因此TMS可以再次调整其密码处理并在欺诈检测引擎中引发附加的标记。当使用LTUK时，CVN指示“无会话密钥导出”。

在替代布置中，M/芯片实现可以使用LTUK代替OTUK。为了允许旋转从相同IMK导出的各LTUK，可以引入新的数据对象，称为卡导出计数器(CDC)。这可以是递增计数器，从而允许使用相同IMK进行256次旋转。

非接触式磁条实现-在这种情况下，应用密码是使用LTUK CVC3Key计算的，这与现有非接触式磁条解决方案中使用的方法相同。没有使用OTUK或VI-其中一个因素是，对于非接触式磁条解决方案，存在可用于附加数据的最小空间，并且因此没有空间向TMS发信号通知不同选项。

TMS将需要知道计算密码所采取的选项-这在下面的表3中进行总结。

表3

如上所示，可以使用不同的机制向TMS发信号通知应用密码中包括VI和/或CDN以及是否使用OTUK或LTUK。一种机制使用上表中用于区分OTUK与LTUK的密码版本号(CVN)的不同值。另一种机制是附加认证数据，以指示在应用密码中包括/排除VI和/或CDN。包括或排除CDN由CDCVM信息指示，该信息包括在用于M/芯片的附加认证数据中，并且限于用于非接触式磁条的轨道DD中的1数位值。

通过授权请求中的信息，例如在(包括在发行方应用数据中的)附加认证数据和CDCVM信息中，发行方主机被通知密钥的可信度或支付应用本身的沙箱的有效性。这些在下面进一步讨论，参考附录B中提供的示例性CDCVM信息和码本以及附录C中提供的与计算环境(特别是Android计算环境)的完整性有关的可获得信息的讨论。

如果远程证明失败或未执行，那么沙箱可能受到影响-这由缺少VI来指示。VI的存在-因为它们保持在易失性存储器中–指示自移动设备操作环境的上次启动以来在支付应用和CMS之间存在有效交互并且远程证明被成功执行。

为了评估缺少VI-因此缺乏远程证明-的影响，交易的上下文和移动的连接性起着重要作用。

可能缺少VI的合理原因有很多，诸如以下：

·消费者为长时间飞行而关闭设备，并且在重新启动后没有建立连接

·消费者在夜间关闭设备并刚好在进行交易之前重新启动

·电池电量低或耗尽并且消费者处于没有网络覆盖的农村环境中，

·应用在执行交易之前仅几分钟崩溃。

在所有这些场景中，可能期望允许进行本地交易，而不是简单地禁止所有交易直到从CMS获得VI为止。有可能通过可以存储以供将来参考的历史数据点来标记这样的事件，如下面的表4所示。

重新启动的原因	移动历史数据点
		消费者将设备断电	检测到关机
电池电量低或耗尽	检测到电池电量低
		应用崩溃	检测到崩溃

表4

如果在重新启动或交易时捕获，那么可以提供有用信息的其它相关数据点如下：

·在重新启动时

ο飞行模式已开启

ο数据漫游已关闭，并且网络与惯常网络不同

ο自上次启动以来的距离>1000公里

ο没有检测到网络

·在交易时：

ο自上次重新启动以来的时间非常近。

这些数据点可以作为授权请求的一部分包括在内，并且与从终端接收的数据点交叉引用。示例性场景列于下表5中。

/>

表5

在实施例中，这个信息作为新数据对象的一部分被发送，代号为“设备状态的卡评估”并缩写为CADS。

下面提供了CADS中这些数据点的示例性编码，包含三类信息：

-当前状态(B1)

-历史(B2)

-设备上下文(B3)

B1-当前状态

b8	飞行模式开启/关闭
		b7	是否检测到电信网络。
b6	电信网络与已经用于数据漫游/连接性的其它电信网络不同
		b5	数据漫游已开启或关闭
b4	是否检测到Wifi网络
		b3	Wifi网络与已经用于数据通信的其它wifi网络不同
b2	RFU
		b1	RFU

B2-历史

/>

B3-设备上下文

b8	自上次重新启动以来的时间不到5分钟
		b7	自上次启动以来的距离>1000公里
b5	RFU
		b4	RFU
b3	RFU
		b2	RFU
b1	RFU

这个信息可以作为交易数据的一部分在适当的数据字段中传送。在当前的EMV实现中，如果现有的自由格式字段提供的空间不足，那么可能需要重新利用现有的EMV数据字段来提供这种数据。例如，可以通过子版本DE55字段的发行方应用数据(IAD)的一部分来包括CADS信息。CADS信息可以用于修改通用持卡人认证字段(UCAF^TM)-申请人已将UCAF开发作为标准，用于收集和运输由发行方和账户持有人安全性解决方案生成的账户持有人认证数据。

表6A-发行方应用数据

/>

表6B-用于IAD子版本0和1的“其它数据”

表6C-用于UCAF格式2子版本0的“其它数据”

如上表6B中所指示的交易上下文信息可以包括现有卡核实结果(CVR)信息的部分。以下表7中提供了示例性编码。

表7-交易上下文

如上所述，消费者设备持卡人核实方法(CDCVM)是用于在移动设备(或任何其它消费者计算设备)上运行的应用的客户核实方法(CVM)。在本布置的实施例中，可以在交易授权请求中提供与CDCVM有关的信息。芯片交易和非接触式磁条交易采用不同的方法：通过用于芯片交易的(2字节)CDCVM信息和用于非接触式磁条交易的CDCVM码本，包括持卡人核实方法、强度和类型。附录B中详细描述了编码。用于CDCVM方法的编码、强度和类型以及应用于每个的信息的来源在下面讨论。

方法-CDCVM字节2b4b3b2b1设置如下，

这些设置可能基于Android支持的检查，如下所示。

来自：

https://developer.android.com/reference/android/security/keystore/Ke yGenParameterSpec.Builder.html#setUserAuthenticationRequired(boolean)

在API级别23中添加了函数“KeyGenParameterSpec.BuildersetUserAuthenticationRequired(boolean required(要求布尔型))”。

如果被设置为“是”，那么仅在用户已被认证时才允许使用密钥。要注意的是，默认情况下，无论用户是否已被认证，都可以使用密钥。当需要用户认证时：

·只有在设置安全锁定屏幕时才能生成密钥(参见isDeviceSecure())。此外，如果密钥要求每次使用密钥时都进行用户认证(参见setUserAuthenticationValidityDurationSeconds(int))，那么必须注册至少一个指纹(参见hasEnrolledFingerprints())。

·用户必须通过使用其安全锁定屏幕凭证(诸如密码/PIN/模式或指纹)的子集对这个Android设备进行认证来授权密钥的使用。

·一旦禁用了安全锁定屏幕(重新配置为无、滑动或其它不认证用户的模式)或者当强制重置安全锁定屏幕时(例如，由设备管理员)，密钥将变为不可逆转地失效。此外，如果密钥要求每次使用密钥时都进行用户认证，那么一旦注册了新指纹或者一旦不再注册更多指纹，密钥将变为不可逆转地失效，除非使用setInvalidatedByBiometricEnrollment(boolean)来允许注册后的有效性。尝试使用此类密钥初始化密码操作将抛出KeyPermanentlyInvalidatedException。

与强度相关，DevicePolicyManager通过调用setPasswordQuality(ComponentName,int)来设置关于密码质量的策略-并定义不同的常量，如下所述。

如果应用没有设备管理员权限，那么它仍然可以获得关于密码质量的信息。下面给出一些示例：

·Int getPasswordMaximumLength(int quality)，返回设备支持的针对特定密码质量的最大密码长度。

·Int getPasswordMinimumLength(ComponentName admin)，检索对这个用户及其参与简档设置限制的特定管理员或所有管理员的当前最小密码长度。

·Int getPasswordMinimumNumeric(ComponentName admin)，检索对这个用户及其参与简档设置限制的特定管理员或所有管理员的密码中所需的当前数字位数。

·Int getPasswordQuality(ComponentName admin)，检索对这个用户及其参与简档设置限制的特定管理员或所有管理员的当前最低密码质量。

强度-CDCVM字节1b6b5设置如下：

/>

类型-CDCVM字节1，b4b3设置如下：

类型涉及认证是持久的、延长的还是即时的。可通过Android获得的信息参见https://developer.android.com/training/articles/keystore.html# UserAuthentication。当仅当用户已被认证才授权使用密钥时，密钥被配置为以下列两种模式之一操作：

·用户认证授权在一段时间内使用密钥。一旦用户解锁安全锁定屏幕或使用

KeyguardManager.createConfirmDeviceCredentialIntent流确认其安全锁定屏幕凭证，就授权使用这个模式下的所有密钥。授权保持有效的持续时间特定于每个密钥，如在密钥生成或导入期间使用

setUserAuthenticationValidityDurationSeconds指定的。

·用户认证授权与一个密钥相关联的具体密码操作。在这种模式下，涉及这种密钥的每个操作须由用户单独授权。目前，这种授权的唯一手段是指纹认证：FingerprintManager.authenticate。

虽然上面已经描述了所公开的系统和方法的各种示例性实施例，但是应当理解的是，它们仅出于示例的目的而呈现，并且不应当被视为限制。以上描述并非详尽的并且不将本公开限制于所公开的确切形式。根据上述教导，修改和变化是可能的，或者可以在不脱离广度或范围的情况下从本公开的实践中获得。

附录A-示例性密钥交换和密钥注入代码

图9A和9B一起图示了用在实施例中的示例性密钥交换和密钥注入代码。如上所述，图7图示了相关联的消息流。

附录B-CDCVM信息和CDCVM码本

本节描述CDCVM信息和CDCVM码本的布局。

对于M/芯片(DE55或UCAF)，要填充的信息在图10A和10B中指出。

对于磁条，要填充的信息在图11中指出。

附录C-系统状态意识

从Android ConnectivityManager和Setting中检索关于网络连接性的信息。ConnectivityManager的主要职责是：

·监视网络连接(Wi-Fi、GPRS、UMTS等)

·在网络连接性改变时发送广播意图

·当与网络的连接性丢失时，尝试“故障转移”到另一个网络

·提供允许应用查询可用网络的粗粒度或细粒度状态的API

·提供允许应用为其数据流量请求和选择网络的API

特别相关的是应用于具有互联网能力的网络(NetworkCapabilities NET_CAPABILITY_INTERNET)的信息以及关于对此类网络的请求接收到的响应。另一个感兴趣的主题是设置，因为这允许应用检测到飞行模式已开启。

本附录列出了用于获得相关状态信息的Android函数。

设置

/>

可用的网络

连接的网络

/>

距离

重新启动的原因

/>

定时

·自上次重新启动以来的时间(以毫秒为单位)：SystemClock.elapsedRealtime()

·关闭时的时间(以毫秒为单位)：System.currentTimeMillis()

·重新启动时的时间(以毫秒为单位)：System.currentTimeMillis()

Claims

1.一种计算设备，实施用于支付应用的安全性架构，所述安全性架构包括用于存储第一密码材料的所述计算设备的非易失性存储装置和用于存储第二密码材料的所述计算设备的易失性存储装置，

其中所述非易失性存储装置包括由所述计算设备的操作系统提供的密钥库，并且第一密码材料包括密码密钥，其中第二密码材料包括为一次使用而生成的加密的易失性整数，其中第二密码材料在所述计算设备重新启动时丢失并且所述计算设备适于在所述计算设备重新启动时请求一个或多个易失性整数，以及

其中所述支付应用适于生成用于使用所述计算设备执行的交易的应用密码，其中在生成所述应用密码时使用第一密码材料并且在易失性整数可用的情况下在生成所述应用密码时还使用该易失性整数，其中在接收到所述应用密码时能够确定是否在所述应用密码的生成中使用了易失性整数。

2.如权利要求1所述的计算设备，其中所述安全性架构适于使得至少第二密码材料从所述计算设备外部但能通过计算网络访问的源补充。

3.如权利要求1或权利要求2所述的计算设备，其中所述安全性架构适于使得第一密码材料包括第一部分和第二部分，其中所述支付应用适于使用第一密码材料执行动作，其中仅在满足使用条件的情况下才使用第一密码材料的第二部分，其中如果不满足使用条件，那么仅使用该密码材料的第一部分，其中该动作的输出指示使用第一密码材料的哪些部分。

4.如权利要求1所述的计算设备，其中密码密钥包括一个或多个单次使用密钥和长期使用密钥中的一个或多个。

5.如权利要求1所述的计算设备，其中当使用第一密码材料生成所述应用密码时，所述支付应用在能使用的情况下使用单次使用密钥之一，并且在没有单次使用密钥能使用的情况下使用长期使用密钥，并且其中当在生成所述应用密码时使用长期使用密钥时，所述应用密码指示使用了长期使用密钥。

6.如权利要求1或权利要求2任一项所述的计算设备，其中所述安全性架构适于仅在注入密钥库在预定时间内完成时才使用密码密钥。

7.如权利要求1或权利要求2所述的计算设备，其中所述计算设备是移动计算设备。

8.如权利要求3所述的计算设备，其中所述安全性架构提供在移动计算设备处对用户的核实，并且其中第一密码材料包括完成的核实材料和未完成的核实材料，并且其中如果用户在移动计算设备处被核实，那么该动作使用完成的核实材料，并且如果用户在移动计算设备处未被核实，那么该动作使用未完成的核实材料。

9.如权利要求8所述的计算设备，其中完成的核实材料由所述计算设备的操作系统提供的密钥库以加密方式生成，并且其中密钥库被配置为仅在成功的用户核实之后执行密码操作。

10.一种在具有非易失性存储装置和易失性存储装置的计算设备上准备和执行支付应用的方法，所述方法包括：

将第一密码材料存储在非易失性存储装置中并将第二密码材料存储在易失性存储装置中，所述非易失性存储装置包括由所述计算设备的操作系统提供的密钥库，并且第一密码材料包括密码密钥，其中第二密码材料包括为一次使用而生成的加密的易失性整数，其中第二密码材料在所述计算设备重新启动时丢失并且所述计算设备适于在所述计算设备重新启动时请求一个或多个易失性整数；

从在所述计算设备外部但是能通过计算网络访问的源补充至少第二密码材料；以及

所述支付应用生成用于使用所述计算设备执行的交易的应用密码，其中在生成所述应用密码时使用第一密码材料并且在易失性整数可用的情况下在生成所述应用密码时还使用该易失性整数，其中在接收到所述应用密码时能够确定是否在所述应用密码的生成中使用了易失性整数。

11.一种在具有非易失性存储装置和易失性存储装置的计算设备上准备和执行支付应用的方法，该方法包括：

将第一密码材料存储在非易失性存储装置中并将第二密码材料存储在易失性存储装置中，所述非易失性存储装置包括由所述计算设备的操作系统提供的密钥库，并且第一密码材料包括密码密钥，其中第二密码材料包括为一次使用而生成的加密的易失性整数，其中第二密码材料在所述计算设备重新启动时丢失并且所述计算设备适于在所述计算设备重新启动时请求一个或多个易失性整数，并且其中第一密码材料包括第一部分和第二部分；

所述支付应用生成用于使用所述计算设备执行的交易的应用密码，其中在生成所述应用密码时使用第一密码材料并且在易失性整数可用的情况下在生成所述应用密码时还使用该易失性整数，其中在接收到所述应用密码时能够确定是否在所述应用密码的生成中使用了易失性整数；以及

所述支付应用使用第一密码材料执行动作，其中该密码材料的第一部分用于执行该动作并且在满足使用条件的情况下该密码材料的第二部分也用于执行该动作，其中该动作的输出指示使用第一密码材料的哪些部分。