用于端到端密钥管理的系统和方法与流程

本申请要求于2016年7月25日提交的美国申请no.15/218,842的权益和优先权。上述申请的全部公开内容通过引用并入本文。

本文描述的示例性实施例一般地涉及用于支付商品和/或服务的交易，更特别地，涉及增强存储在移动设备上并在交易期间使用的密码密钥的安全性。

背景技术：

基于云的支付支持在移动设备中管理、生成和供应数字支付凭证，以实现更简单和更安全的数字支付体验。开发基于云的支付系统以使金融业从存储在传统支付卡上的消费者账户凭证过渡到供应给移动设备的数字凭证。数字化凭证使消费者的移动设备能够经由非接触式销售点系统和经由诸如应用内(in-app)支付的远程支付进行支付。可以使用安装在移动设备上的钱包应用将数字化凭证存储在数字钱包中。可以向数字钱包供应敏感资产，诸如卡简档以及交易和管理密钥集。

基于云的支付的安全模型依赖于一组对策和技术设计，包括贯穿数字钱包的生命周期的若干控制。风险管理在数字钱包、移动设备的各种级别以及在远程支付情况中在交易的在线授权期间进行。监控和交易分析被用于检测数字钱包的欺诈性使用，并采取可以导致交易被拒绝的动作，或者甚至暂停包含在数字钱包中的数字化卡或数字钱包本身。

与任何基于软件的技术一样，基于云的支付是若干种类型的攻击的目标，这些攻击试图以欺诈的方式提取敏感资产或使用数字钱包。此外，诸如数字钱包或移动银行应用的金融移动应用使用已经存在很长时间的安全编码技术。虽然还可以使用混淆和软件篡改开发工具来提高移动应用的安全级别，但是在用户设备的用户域中仍然存在导入、生成和使用加密密钥的许多漏洞，这使得这些密钥易于受到攻击。

最近，已经多次试图引入白盒密码术(wbc)的概念，以努力在基于软件的环境中提供对安全密码操作的支持。但是，wbc需要额外的成本，并且需要复杂的管理来在数字钱包的生命周期内管理白盒，诸如wbc的更新处理。

附图说明

参考以下结合附图的详细描述，示例性实施例的特征和优点以及实现它们的方式将变得更加明显，附图中：

图1是图示根据示例性实施例的令牌支付系统的示图。

图2是图示根据示例性实施例的包括用户域和系统域的移动操作环境的示图。

图3是图示根据示例性实施例的可由移动支付应用使用的加密密钥的示图。

图4是图示根据示例性实施例的可以在移动设备的系统域中使用的加密密钥的示图。

图5是图示根据另一个示例性实施例的可以在移动设备的系统域中使用的加密密钥的示图。

图6是图示根据示例性实施例的移动设备的示图。

图7是图示根据示例性实施例的在移动设备的多个域中执行的支付方法的示图。

在整个附图和详细描述中，除非另外描述，否则相同的附图标号将被理解为表示相同的元件、特征和结构。为了清楚、图示和/或方便起见，这些元件的相对尺寸和描绘可能被夸大或调整。

具体实施方式

在以下描述中，阐述了具体细节以便提供对各种示例性实施例的透彻理解。应该认识到的是，对于本领域技术人员来说，对实施例的各种修改是明显的，并且在不脱离本发明的精神和范围的情况下，本文定义的一般原理可以应用于其它实施例和应用。此外，在以下描述中，出于解释的目的阐述了许多细节。但是，本领域普通技术人员应该理解的是，可以在不使用这些具体细节的情况下实践实施例。在其它情况下，未示出或描述众所周知的结构和处理，以避免不必要的细节使描述模糊。因此，本公开不旨在限于所示的实施例，而是与符合本文公开的原理和特征的最宽范围相一致。

如本文所述，移动支付应用可以用于执行非接触式支付，诸如通过近场通信(nfc)、射频识别(rfid)等。当执行非接触式交易时，用户可以使移动设备轻击非接触式读取器并通过设备或pos(例如，在线pin或签名)或两者利用用户的认证或者使用nocvm(诸如用于低值交易)来继续进行该交易。此外，移动支付应用可以用于执行远程支付。当执行远程支付交易时，用户可以在商家在线站点购物或使用移动应用，并且在该处理的某个阶段可以被请求执行交易。因此，用户可以使用诸如数字钱包的移动支付应用来使用因特网连接(与在物理世界中用于非接触式所使用的相比)执行交易。

基于云的支付系统使持卡人能够在移动设备上下载和安装移动支付应用，以用于与商家的非接触式交易和远程交易。持卡人可以将一个或多个支付账户与移动支付应用相关联，并使用移动设备通过移动支付应用与商家进行交易。在交易期间，持卡人的设备可以使用多个加密密钥来保护敏感支付账户信息和在持卡人的移动设备与商家和/或支付网络之间传输的其它支付数据。

由于基于云的支付系统的原始设计，在由持卡人设备上的移动支付应用所使用的加密密钥的端到端管理中存在多个安全漏洞。如本文所描述的漏洞发生在诸如管理密钥或交易密钥之类的敏感资产以某种方式在用户设备的用户域内公开的时刻，用户设备的用户域与由操作系统(os)控制并且比用户域更安全的用户设备的系统域相比是不可信环境。近来，已经采取了大量措施来提高移动设备的安全级别并通过移动操作系统引入了新的安全特征。改进的移动设备安全性的示例是诸如密钥库的安全存储装置。作为示例，android操作系统中包括的android密钥库允许密码密钥被存储在用户设备上的安全数字容器中，以使得更难以从中提取密钥。一旦密钥在密钥库中，它们就可以用于密码操作。此外，密钥库可以提供限制何时以及如何可以使用密钥的规则，诸如对于密钥使用要求用户认证或将密钥限制于仅在某些密码模式中使用。

根据示例性实施例，在移动支付处理或非接触式支付处理期间使用的密码密钥可以通过在交易期间在加密密钥的端到端管理内将来自移动操作系统(诸如来自android密钥库)的安全特征结合来进一步加以保护。移动支付应用通常默认在用户域中存储密钥。作为对照，示例性实施例在系统域中导入和操作密钥，以便增强移动设备的安全特征和减少密钥管理中的漏洞数量。例如，密钥可以被导入到可信执行环境或由系统域而不是用户域可用的硬件元件中并由其执行。

如本文所述，用户域是指其中诸如数字钱包的移动应用响应于来自用户的控制而执行和操作的环境，并且系统域是指在操作系统唯一控制下的更安全的环境。系统域可以访问低级功能，包括具有可由可信执行环境或基于硬件的机制提供的安全特征的接口。此外，在用户设备的用户域和系统域之间存在强隔离(例如，防火墙)，使得对系统域的访问受到限制。通常，攻击者将以用户域为目标，因为它更容易并且具有明显更多的访问机会，而只有高级的攻击者会试图访问需要明显更熟练的理解才能被破坏的系统域。

加密密钥(即密钥)可以从另一个设备导入或由该移动设备生成。密钥可以用于对移动设备和支付网络之间传输的数据执行各种操作，诸如加密、解密、签名等。根据各种示例性实施例，可以在系统域而不是用户域中执行密钥的导入和生成以及使用密钥的操作，从而防止密钥在用户域内暴露。此外，示例性实施例将用于管理操作系统内的密钥库的功能进行组合，以增加密钥的安全级别，使得在用户域内不存在管理密钥和交易密钥的泄漏。因此，从安全密钥导入开始到密钥的实际使用的所有密码操作可以在系统域中利用由操作系统提供的最先进的技术来执行，诸如可信执行环境或可以由操作系统以受限和受控方式使用的嵌入式安全元件。

示例性实施例可以限制在系统域中可以利用密钥执行的操作的类型，例如，系统域可以允许导入但不允许导出、允许加密但不允许解密(或反之亦然)，以及使用访问控制来限制对密钥的访问但利用密钥的密码属性(诸如非对称密钥)以便让任何人使用作为密钥一部分的公钥来加密数据。此外，涉及密钥的操作可以与附加级别的加密和解密相结合以实现附加控制。作为示例，密钥的传输或密钥的使用可以一经使用该密钥利用为其定义访问规则的另一个密钥来对那个密钥进行先前解密之时就被调节(conditioned)。

图1图示了根据示例性实施例的令牌支付系统100。参考图1，令牌支付系统100包括移动设备110、商家计算设备120、发行方计算设备130、移动应用服务器140以及管理服务器150、收单方160和支付网络170。还应该认识到的是，令牌支付系统100可以包括未示出的附加设备，例如支付网关等，或者示例性设备中的一个或多个可以彼此组合以及合并。还应该认识到的是，令牌支付系统100可以包括多个移动设备110、商家计算设备120、发行方计算设备130、移动应用服务器140、管理服务器150和收单方计算设备160。

令牌支付系统100可以是基于云的支付系统，其支持从移动设备110到商家120的非接触式支付和远程支付。例如，移动设备110可以从移动应用服务器140下载并安装移动支付应用。支付应用可以是基于发行方的支付应用、基于商家的应用、数字钱包等。在基于发行方的移动支付应用的示例中，支付能力可以被集成到移动设备110中作为发行方(诸如发行方130)的移动应用的一部分，从而向移动应用提供用于进行支付交易的凭证。在数字钱包的示例中，支付能力可以被集成为数字钱包的一部分，并且移动应用服务器140可以是能够将一个或多个支付卡数字化到相同数字钱包中的钱包提供者。

用户可以存储与安装在移动设备110上的移动支付应用相关联的一个或多个支付卡的令牌化支付账户信息。移动支付应用可以包括mastercardmasterpass、googlewallet、samsungpay、applepay等。支付账户信息可以包括来自由发行方130提供的支付卡的主账号(pan)、到期日期等，并且可以被令牌化并存储在移动设备110上。作为另一个示例，移动设备110可以存储数字钱包，该数字钱包其中存储有来自由任意数量的发行方、银行、金融实体等提供的、并且已经由用户与数字钱包相关联的一个或多个支付卡的令牌化支付信息。因此，移动设备110可以变换为既能够远程又能够现场向商家120进行支付的商用设备。

管理服务器150可以包括多个设备、模块、程序、软件等。例如，管理服务器150可以由诸如mastercard公司的金融实体控制，并且可以包括凭证管理系统(cms)、账户启用系统(aes)、交易管理系统(tms)、令牌库等。在这些示例中，管理服务器150可以包括或者可以连接到令牌服务提供设备。令牌服务提供设备可以生成令牌来代替支付卡信息，并存储和维护将令牌化的支付信息(诸如令牌化的pan)转换为实际支付信息所需的映射或信息表。根据各种示例性实施例，管理服务器150可以存储与存储在移动设备110上的移动支付应用一起使用的各种加密密钥，以在支付处理或交易期间使用。例如，密钥可以包括用于令牌的主密钥、用于在交易中使用的会话密钥、管理密钥等。可以在交易之前或交易期间将密钥从管理服务器150传送到移动设备。

在图1的示例中，安装在移动设备110上的移动支付应用向持卡人提供前端接口并管理从签署支付服务到利用移动设备110交易的用户体验，并管理诸如更改个人识别码(pin)的功能。移动应用服务器140向持卡人提供前端接口并管理持卡人的用户账户，并且可以集成基于云的数字化服务，用于将支付卡数字化到移动支付应用中。

根据各种示例性实施例，对令牌支付系统100进行了多种改进，以努力进一步增强移动设备110和商家120之间的支付交易的安全性。第一波改进是通过将密钥导入、密钥存储和密钥操作结合到移动设备110的系统域中来对通过移动设备110进行的加密密钥的导入、存储和使用进行改进。第二波改进是通过将密钥的更改扩展到管理服务器150的凭证管理系统来进行。第三波改进是通过将管理服务器150的交易管理系统的交易密码迁移到不同的加密算法来进行，而第四波更改是通过对移动设备110的移动操作系统做出更改来进行。

管理服务器150可以包括许多不同的系统。例如，账户启用系统可以提供服务以检查支付卡和设备用于基于云的支付服务的资格、执行识别和验证来对持卡人进行认证、将支付卡数字化以及协调生命周期管理。令牌库(vault)可以将令牌维护到账户pan映射表中。数字化的支付卡可以被供应到凭证管理系统中。凭证管理系统可以存储用于令牌的主密钥，并且在交易期间生成可以被转换为交易凭证的会话密钥。凭证管理系统可以将会话密钥与移动pin组合以创建交易凭证并将它们提供给移动支付应用以使移动支付应用能够进行交易。交易管理系统可以处理交易、验证应用密码来对所使用的凭证进行认证，以及验证已输入了正确的移动pin。

移动设备110的用户可以试图对与商家120的交易进行支付。例如，移动设备110可以使用由数字钱包或其它移动支付应用提供的非接触式或远程支付能力来进行支付。当商家120从移动设备110接收支付数据时，商家120可以将支付数据发送到收单方160。收单方160可以将支付数据发送到支付网络170用于处理。如果支付数据包括令牌化的支付信息，那么支付网络170可以将令牌化的支付信息发送到发行方130和/或管理服务器150，用于转换为实际的支付信息。此外，发行方130可以验证与支付数据对应的支付账户是否具有足够的资金来涵盖从商家120的购买。授权的结果可以通过反向路径被发送回商家120。

虽然未在图1中示出，但是令牌支付系统100还可以包括远程通知服务，诸如google云消息传递、apple推送通知服务、microsoft推送通知服务等。远程通知服务可以与移动支付应用通信并提供各种通知。

图2图示了根据示例性实施例的包括用户域200和系统域300的移动操作环境。参考图2，用户域200是其中诸如移动支付应用、商家应用、数字钱包等移动应用可以操作的操作环境。用户域200是其中用户可以与在移动设备上运行的各种应用交互的域。当在用户域200中操作若干移动应用时，移动设备的操作系统可以在用户域200中的这些应用之间提供某种级别的沙盒化(sandboxing)，以便控制和/或限制可以由移动应用访问的区域。

系统域300是可以在移动设备的操作系统的唯一控制下的更安全的操作环境。在各种示例中，不允许用户或未授权的移动应用访问系统域300内的数据。系统域300可以访问低级功能，并且可以是与各种安全特征的接口，安全特征诸如可信执行环境(tee)316、基于硬件的机制314(例如，安全元件、存储装置、密码处理器)等。根据各种示例性实施例，密钥库310被包括在系统域300内，并且包括一个或多个密钥条目312以及tee316和基于硬件的机制314。密钥库310可以负责存储和维护具有对应的条目312和其所有者的标识的密码密钥。密钥可以从用户域200导入到系统域300的密钥库310中。密钥库的示例是由google设计的android移动操作系统中包括的android密钥库。在一些示例中，例如，在密钥被限制于用户域200内的具体类型的处理操作和/或条件的情况下，可以将密钥从系统域300导出到用户域200中。

在示例性实施例中，在用户域200和系统域300之间存在强隔离，例如防火墙。因此，对系统域300的访问非常有限。例如，系统域300可以在操作系统的唯一控制下，这可以防止应用、设备和用户访问系统域300和访问存储在系统域300中的加密密钥。此外，操作系统可以防止可以在系统域300中执行的操作的类型。由于系统域300的安全性强度，攻击者通常将以用户域200为目标，而只有最高级的攻击者会试图访问系统域300。此外，对由系统域300使用的诸如tee316和基于硬件的机制314之类的安全机制的访问可能需要甚至更多的技能才能使用或甚至破坏它们。

在图2的示例中，用户域200具有在其中安装和执行的移动支付应用210。例如，移动支付应用210可以是数字钱包、商家支付应用、基于发行方的支付应用等。用户域200还可以包括可以在其内执行的其它移动应用220。移动支付应用210包括多个处理(p1、p2、pn等)215。在一些示例中，移动支付应用210还可以包括在用户域200中操作的白盒密码术(wbc)组件。移动支付应用210可以将信息存储在用户域200的环境中操作的数据库中。根据各种示例性实施例，移动支付应用210可以在支付处理期间使用密钥库310并创建可以在支付处理期间使用的密钥库条目312。例如，密钥库310中的每个条目可以与密钥(及其别名)和诸如系统域300中允许的密码功能(诸如加密、解密、签名等)、加密算法(诸如aes、rsa、ecc...)以及访问规则之类的参数相关联。

密钥库310可以在系统域300中操作，并且可以利用来自可信执行环境316和/或可用硬件组件314的安全性。在该示例中，在用户域200中的应用之间存在第一级别的隔离。此外。在用户域200和系统域300之间存在另一个级别的隔离。因此，用户域200和系统域300可以像洋葱或俄罗斯套娃的层一样起作用，在俄罗斯套娃中，每个套娃形成另一层保护。在该示例中，存储在系统域300中的数据具有比存储在用户域200中的数据更多层的保护。在一些示例中，对密钥库310的调用可能不允许调用者在系统域300内的密钥库条目312组件中执行一系列操作，并且仅将最终结果从系统域300返回给用户域200。作为示例，当在系统域300中执行密码操作时，对其的响应可能被发送回用户域200并且可能潜在地暴露给以用户域200为目标的攻击者。因此，密钥库310可以是仅能够一次执行一个操作而没有存储任何临时结果或值的功能的硬件安全模块。

根据各个方面，系统域300可以是用户域200的从属(slave)。在图2的示例中，钱包210(包括移动支付应用)的业务逻辑在用户域200中执行。但是，密码操作可以在系统域300中执行。因此，作为从用户域200到系统域300的应用编程接口(api)调用等的结果，可以在系统域300中执行密码操作。这里，例如，在用户域200中执行的钱包210的处理(p2)使用fn(ks,data)调用系统域300，其中fn()是密码函数，ks是密钥库310的别名，并且data是要处理的一些数据。接下来，从系统域300向用户域200传送响应(resp)。在该示例中，密钥库310是在用户域200中操作的处理的从属，并且可以根据需要由钱包210中包括的处理来调用它。密钥库310内包括的密钥可以由密钥库310响应于来自用户域200的调用而生成，或者可以从用户域200导入到密钥库310。根据各个方面，密钥可以在用户域200中时(或者在从用户域200导入之前或者在从系统域导出到用户域中之后)被加密，并且因此被进一步保护。

图3图示了根据示例性实施例的可以由移动支付应用210使用的加密密钥。参考图3，移动支付应用210包括导入到用户域200中或在用户域200中生成并且在用户域200中使用的多个密钥，而系统域300是空的。在该示例中，移动支付应用210可以在支付处理期间使用多个加密密钥350。在本文的示例中，术语(mk)是指移动密钥，(msk)是指移动会话密钥，(icc)密钥是指集成电路卡密钥，和(lde)密钥是指本地数据库加密密钥。此外，aes、rsa、3des等是指本领域中加密的类型。

当使用移动支付应用210时，基于云的支付系统可以使用在用户域200中执行的各种安全服务。图3中所示的基于云的支付加密服务的示例包括移动支付应用210的随机密钥生成(rgk)，以及rgk导出到凭证管理系统(cms)，其中rgk可以使用由cms提供的rsa公钥进行加密。例如，cms可以被包括或连接到图1中所示的管理服务器150。基于云的支付加密服务可以包括诸如消息认证码(mac)移动密钥、传输密钥(tk)以及可以从cms递送并在rgk下加密的数据加密密钥(dek)之类的移动密钥、使用移动密钥(mac和tk)和会话信息作为分散器由移动支付应用210生成的移动会话密钥(mac和tk-aes密钥)、作为移动支付应用和cms之间的消息传递协议的一部分由移动支付应用使用的移动会话密钥(mac和tk)、可用于保护由cms供应的密钥容器中的卡简档(icckek)或密钥集(会话密钥和单次使用密钥)中的敏感资产的移动密钥(dek)、由移动支付应用生成的并用于保障数据的存储(加密和解密)的本地数据库加密(lde)密钥(aes密钥)、使用(代理)移动pin的单次使用密钥(3des密钥)到会话密钥(3des密钥)的转换。基于云的支付系统还可以使用会话密钥(3des密钥)执行ac/cvc密码生成、使用icckek(aes密钥)执行icc私钥解密以及使用icc密钥对(rsa密钥)执行cda签名生成。

但是，在图3中，加密密钥被导入到用户域200内的移动支付应用210中并由其使用。因此，密钥可能受到获得对用户域200的访问的入侵者的攻击。图4图示了根据示例性实施例的可以在系统域300中使用的加密密钥。在图4的示例中，与图3的系统相比支持了移动设备内的附加安全性改进。移动设备的操作系统可以用于基于在执行用户域200中的移动支付应用时发生的动作来控制系统域300。

参考图4，根据各种示例性实施例，移动密钥410(mac、tk和dek-aes密钥)可以被导入到系统域300内的密钥库310中并由其使用，并且可以具有标准设备访问控制。在该示例中，标准设备访问控制可能未与用户身份认证链接。例如，移动密钥410可以从连接到或被包括在图1的管理服务器150内的cms导入。此外，可以在系统域300的密钥库310中管理在移动密钥(dek)下加密的资产。

在该示例中，移动支付应用可以使用系统域300中的密钥库310以便存储移动密钥410，并且使用移动密钥410执行密码操作。移动支付应用可以接收在rgk密钥下加密的移动密钥410。在这些示例中，移动支付应用可以创建具有参数的mac密钥库条目，参数诸如加密算法为aes、访问控制为没有用户认证的标准设备以及功能限于签名(用于推导移动会话密钥的hmac生成)和系统域300内的“签名”(mac检验)。移动支付应用也可以创建具有参数的tk密钥库条目，参数诸如加密算法为aes、访问控制为没有用户认证的标准设备以及功能限于签名(用于推导移动会话密钥的hmac生成)和解密。移动支付应用也可以创建具有参数的dek密钥库条目，参数诸如加密算法为aes、访问控制为没有用户认证的标准设备以及功能限于解密和加密。

移动密钥mac、tk和dek410可以被导入(以明文)到密钥库310中。移动密钥mac(ksmkmac)可以用于在递送关于要由移动支付应用建立的会话的信息时检验在由cms发送的远程通知消息上计算出的mac。此外，可以允许移动密钥mac(ksmkmac)生成mac移动会话密钥，该mac移动会话密钥在支付处理期间被返回到在用户域200中执行的移动支付应用210。移动密钥tk(ksmktk)可以用于在递送关于要由移动支付应用建立的会话的信息时解密由cms发送的远程通知消息的加密内容。此外，移动密钥tk(ksmktk)可以用于生成返回到用户域200的tk移动会话密钥。可以允许移动密钥dek在字段级别解密和/或加密数据。

在图4的示例中，移动密钥410的解密可以由在用户域200中执行的移动支付应用来执行，但是移动密钥410可以被立即导入到使用ks别名识别出的系统域300的密钥库310中。当导入处理完成时，可以从用户域200擦掉或擦除移动密钥410。从那时起，可以使用系统域300中的密钥库310来使用移动密钥(mac、tk和dek)410执行所有密码操作。当移动密钥mac和移动密钥tk用于在系统域300中生成移动会话密钥时，移动会话密钥可以被返回到用户域200的移动支付应用210。使用移动会话密钥的密码操作可以在用户域200中执行，并且因此可能潜在地暴露给以用户域200为目标的攻击者。但是，移动会话密钥可以仅对移动支付应用和cms之间使用由cms定义的会话标识符的一个会话有效。此外，在集成本文描述的安全性改进列表时，移动会话密钥的角色可能变得不太重要，并因此，即使攻击者能够以移动会话密钥为目标，也需要击败附加安全对策以便获得对诸如交易密钥(在移动密钥dek下加密)的敏感资产的访问。

根据各种示例性实施例，可以在系统域300的密钥库310中生成并使用lde密钥420。例如，移动支付应用可以将lde密钥420的生成委托给密钥库310，并且所有密码操作可以在系统域300中执行，而不是实现定义lde密钥420并在用户域200中执行所有操作的处理。lde密钥420可以由系统域300中的密钥库310随机生成。从那时起，使用lde密钥420完成的所有密码操作都可以使用系统域300中的密钥库310来执行，而不会将lde密钥420暴露给用户域200(即，用户域200中的移动支付应用)。lde密钥420可以包括具有用户访问控制的lde密钥(ldeusr密钥)。ldeusr密钥可以由密钥库310随机生成，并且可以具有提供给在用户域200中运行的移动支付应用的公钥。ldeusr密钥可以用于解密存储在本地数据库中由移动支付应用使用的数据。加密处理可以由移动支付应用使用公钥在用户域200中执行，而不需要对密钥库310的加密特征的任何访问。

根据各种示例性实施例，icc密钥对430可以被导入到系统域300的密钥库310中并由其使用。移动支付应用可以从cms接收icc密钥对430及其组件(p、q、dp、dq和u)作为与移动支付应用对应的持卡人的卡简档的一部分。重建密钥对所需的组件可以在密钥icckek下加密。icckek可以是持卡人的卡简档的一部分，并且可以在移动密钥(dek)下加密。移动支付应用可以在系统域300中使用密钥库310来存储icc密钥对430并执行cda签名的生成。

基于云的支付系统可以通过设计集成作为cda的变体的本地数据认证(lda)的概念，以便防止icc密钥对430的任何误用来执行成功的离线交易。icc密钥对430的保护的附加级别在诸如转接(transit)的环境中尤其相关，其试图防止可以在支持延迟在线授权的概念的模型中使用的敏感资产的任何不受控制的导出或泄漏(即，交易密码在交易时未进行实时检验)。当使用转接时，可以使用有效的cda签名(即使具有错误的交易密码)，以便在与数字化卡相关联的pan由于检验交易密码时的失败将被列入黑名单之前通过转接门。

移动支付应用可以创建具有参数的icc密钥对密钥库条目，参数诸如加密算法为rsa、访问控制为没有用户认证的标准设备以及功能限于签名(cda生成)。移动支付应用可以使用移动密钥dek来解密icckek。使用icckek对每个crt组件的解密可以在用户域中执行，并且icc密钥对430可以被立即导入到密钥库310。一旦导入处理完成，icckek和crt组件就可以从用户域200中被擦掉。从那时起，可以使用系统域300中的密钥库310来执行使用icc密钥对430完成的密码操作(即生成cda签名)。

附加的密钥库310条目(rsa密钥)可以用于提供利用对密钥的特定访问控制来加强存储的手段。使用该改进，对umd密钥的访问可能需要使用移动设备对持卡人进行认证(诸如当使用设备cdcvm作为使用指纹的设备解锁处理的一部分时)。该可选特征为umd会话密钥添加了某个级别的加密，以便将对umd密钥的访问调节成移动设备上(使用设备cdcvm)持卡人的成功认证。钱包可以创建具有参数的ldeusr密钥密钥库条目，参数诸如算法为rsa(或ecc)、访问控制为用户认证(设备解锁)以及功能限于解密。ldeusr密钥可以由系统域300中的密钥库310随机生成。公钥组件可以被检索并被存储在用户域200中。

移动支付应用可以存储加密的md会话密钥(sk_xx_md)和加密的idn值。加密的umd单次使用密钥(suk_xx_umd)(在移动密钥dek下加密)可以在存储在本地加密数据库中之前由移动支付应用使用rsa公用组件(pk)进行加密。这里，公钥可以在用户域200中可用，并且可以由移动支付应用随时使用而无需任何用户访问控制。在交易时对umd单次使用密钥的访问可以受与rsa私有组件(sk)相关联的访问控制规则的保护，因为只有在移动设备(设备cdcvm)的级别上已执行了持卡人的成功认证时，才可以使用rsa私有组件(sk)在系统域300中解密umd密钥。可以使用移动密钥dek执行第二解密，以便检索由诸如umd和md密钥以及idn值之类的移动密钥dek保护的资产。

图5图示了根据另一个示例性实施例的可在系统域300中使用的加密密钥。在该示例中，可以根据各种示例性实施例更新网络管理服务器150的cms，并且可以在图1的令牌支付系统100中实现第二波改进。参考图5，根据各种示例性实施例为移动支付应用新创建的移动密钥(移动密钥dekusr510)被导入到系统域300的密钥库310中，并用于在移动支付应用的执行期间加密和解密数据。为了使用移动密钥dekusr510，可以请求用户认证。

在该示例中，移动支付应用和cms之间的通信可以使用消息传递协议，其中使用传输级别的移动会话密钥(mac和tk)410和用于字段加密的移动密钥(dek)410来保护数据。已经分析了若干选项来集成与用户访问控制链接的字段加密的概念。使用非对称密码术的解决方案由于对系统性能的潜在影响而被丢弃，其利益有限，因为当今没有定义安全密钥导入来与密钥库通信。根据各种示例性实施例，当使用该安全性改进时，引入移动密钥dekusr510，以便在cms的级别上移动用户访问控制的集成，从而在供应处理中预先加强访问控制的规则。由于移动密钥dekusr510的引入，可以不使用ldeusr密钥420，并且可以不再在移动支付应用的级别使用相关联的处理。在图5的示例中，移动支付应用可以为移动密钥dekusr510创建密钥库310条目，其中加密算法被设置为aes，访问控制被设置为用户认证(设备解锁)以及功能被设置用于加密和解密。

在图5的示例中，用于密码生成的白盒密码术(wbc)存在可选的用途。愿意扩展交易会话密钥的端到端保护的发行方或钱包提供者(即移动支付应用提供者)可以将wbc视为改进基于云的支付系统的安全级别的选项并使用其自身定制版本的软件开发工具包(sdk)。目的是减少在用户域200中交易密钥的暴露并利用在用户域200中执行的wbc来解密密钥和使用在wbc组件中实现的处理来生成交易密码。在这种情况下，cms需要知道钱包的wbc组件与cms之间共享的传输密钥(aes)的值。cms-d的定制版本将需要加密交易会话密钥，并且这些加密密钥将使用本文描述的改进机制被递送到钱包。在该示例中，钱包中的wbc组件可以使用对wbc组件的单个调用来实现一系列操作，以便解密该加密的交易会话密钥并保持交易会话密钥的短暂值并使用交易会话密钥密钥生成交易密码。在这种情况下，由cms执行使用wbc密钥的附加加密以准备将由钱包的wbc组件使用的数据。每条记录可以存储和在lde密钥420下被加密。wbc的支持可以由wbc供应商提供作为发布的定制sdk的一部分，而安全性改进的优先级可以在密钥库310上(这是移动设备的操作系统的标准特征)。

可以对包括在管理服务器150中或连接到管理服务器150的交易管理系统(tms)进行第三波安全性改进。在一些情况下，密钥库310可以不包括3des作为支持的算法列表的一部分。因此，可能难以使用能够从密钥库(系统域300)生成交易密码而不是使用潜在地暴露给以用户域200为目标的攻击者的交易会话密钥从用户域200生成交易密码的密钥库来递送用于密钥管理的端到端解决方案。根据各种示例性实施例，解决该问题的另一种方式是使用如在android密钥库中定义的aes支持并从3des迁移到aes交易密码生成(在钱包级别)和检验(在tms级别)。当使用aes作为交易密码管理的算法时，预期以下操作将保持不变，以避免对负责数据准备的cms进行附加更改：用于磁条ivcvc3值生成的算法保持不变并使用具有3des密钥(cmk_cl_umd)的mac，使用卡主密钥(cmk_cl_md或cmk_cl_umd)和atc作为分散器的会话密钥生成(sk_cl_md或sk_cl_umd)的算法保持不变并且使用具有3des密钥的emvcsk方法而不对推导出的密钥进行任何调整用于奇偶校验，并且交易会话密钥(sk_xx_md和sk_xx_umd)的长度是16字节并且在使用aes(16字节)而不是3des(使用8字节的两个密钥)时保持不变。用于emv和用于磁条交易的密码生成(和检验)处理是和谐的，并且使用使用16字节分组密码(aes)的mac算法的一个公共处理可以用于ac或cvc3生成。emv与磁条交易之间的差异是用于定义要被mac的消息(msg)的数据列表。消息的准备(包括填充处理)在用户域200中完成，而密码的生成是使用系统域300中的密钥库来执行，而不会将交易密钥暴露给用户域200。当可以交易密钥的安全密钥导入到密钥库是可用的之时，将实现该解决方案的全部优势。在检验交易时，tms将必须识别支持aes而非3des的钱包(例如使用特定的pan范围)用于密码生成。必须更新由tms使用的硬件安全模块，以便使用使用16字节分组密码(aes)的mac算法而不是使用使用8字节分组密码(3des)的mac算法来支持mac检验。

可以使用更新后的移动操作系统进行第四波改进。例如，当使用如在androidmarshmallow(androidm-api23+)中定义的android密钥库时，密钥可以由密钥库随机生成或者被导入到密钥库中。当使用导入特征时，在密钥被加载到系统域300中的密钥库之前，密钥在用户域200中是明文可用的。有资格导入到密钥库中的密钥(诸如移动密钥或交易密钥)潜在地暴露于以用户域为目标的攻击者，并且当今没有可以在系统域300中的cms-d和android密钥库之间部署的端到端密钥管理。根据各种示例性实施例，可以使用由操作系统提供商定义的机制来支持安全密钥导入。如果需要，管理服务器150的提供商(诸如mastercard公司)可以为要使用的处理提供一些选项，但是期望将他们的处理(诸如由cms完成的密钥的供应)调整到预期通过新的api可用的解决方案。

图6图示了根据示例性实施例的移动设备600。参考图6，移动设备600包括处理器610、输入单元620、导入器630和发送器640。作为非限制性示例，移动设备600可以是移动电话、平板电脑、膝上型计算机、平板电话、个人计算机、电器、电视等。而且，移动设备600可以包括实现本文描述的一个或多个示例性实施例的移动操作系统或操作系统。移动设备600可以对应于图1中所示的移动设备110。移动设备600还可以包括图6中未示出的一个或多个组件，例如，接收器、网络接口、输出单元等。

根据各种示例，移动设备600可以下载并安装移动支付应用，诸如图2中所示的移动支付应用210。作为非限制性示例，移动支付应用可以是数字钱包、商家应用、基于发行方的支付应用等。移动设备600的用户可以使用输入单元620输入命令并将用户的身份验证为与移动支付应用中包括的支付账户对应的持卡人。输入单元620可以包括键盘、触摸板、鼠标、言语识别模块、运动识别模块等，用于接收来自用户键入、触摸、输入、说出或捕获的输入。

响应于接收到用户通过输入单元620输入的命令，处理器610可以在移动设备600的用户域中执行移动支付应用。如本文所述，用户域可以包括其中移动设备的用户执行和可访问移动应用的操作环境。导入器630可以将用于由移动支付应用使用的多个加密密钥导入到移动设备600的系统域中。例如，导入器630可以将密钥导入到系统域中包括的密钥库中。根据各个方面，系统域可以具有比用户域更受限制的操作环境，并且可以由移动设备600的操作系统控制。例如，系统域可能无法被移动设备600的用户访问并且可以在操作系统的唯一控制下。操作系统的示例包括googleandroid、appleios、windowsphoneos等。

处理器610可以在用户域中执行移动支付应用时，使用一个或多个导入的密钥对系统域中的移动支付应用的支付信息进行加密。例如，处理器610可以对来自与移动支付应用相关联的一个或多个支付卡的支付信息进行加密。作为示例，加密的支付信息可以包括主账号(pan)、到期日期、卡安全码、pin、令牌化的支付信息等。作为另一个示例，加密的支付信息可以包括支付数据，诸如在移动设备600和支付网络、cms、管理服务器等之间传输的消息。因此，通过将密钥导入到系统域中并加密系统域中的支付信息，可以防止敏感的持卡人信息和敏感的支付应用信息(即密钥、加密操作、支付信息等)在用户域中暴露，并且可以将这些信息限于系统域。此外，系统域可以包括来自用户域的保护的附加层。例如，可以在用户域和系统域之间实现防火墙，从而在攻击者获得对用户域的访问时进一步保护系统域。

发送器640可以将加密的支付信息发送给商家(即商家服务器或其它计算设备)，以便为商品和/或服务支付与商家的交易。根据各种示例性实施例，发送器640可以将加密的支付信息从系统域直接发送到商家，而不通过用户域传送加密的支付信息。因此，可以防止敏感的加密的数据在移动设备600的用户域内暴露，并且可以限制在系统域内导入和操作敏感的加密的数据。

由导入器630导入到系统域中(例如，由系统域接收)的多个加密密钥可以包括各种密钥，诸如公钥、私钥、移动密钥、移动会话密钥、随机生成的密钥等。例如，加密密钥可以包括用于解密从凭证管理系统(cms)接收到的内容并加密要发送到cms的内容的至少一个移动密钥。作为另一个示例，多个加密密钥可以包括用于生成cda签名的集成电路卡(icc)密钥对。除了将密钥导入到系统域中之外，处理器610还可以在系统域中生成加密密钥用于与移动支付应用一起使用，并将生成的加密密钥存储在系统域的密钥库中。例如，处理器610可以生成本地数据库加密(lde)密钥，用于解密和加密存储在本地数据库中由移动支付应用使用的数据。

图7图示了根据示例性实施例的在移动设备的多个域中执行的支付方法700。参考图7，在710中，在移动设备内建立用户域和系统域。用户域可以包括其中移动设备的用户执行和可访问移动应用的操作环境。系统域可以具有比用户域更受限制的操作环境，并且可以由移动设备的操作系统控制。根据各种示例性实施例，系统域可以是比用户域更严格控制的操作环境。系统域可以具有对其的有限访问以及对可以在其中执行的操作类型的限制。作为示例，系统域可以由操作系统调控或以其它方式控制。

在720中，该方法包括在移动设备的用户域中执行移动支付应用，而在730中，该方法包括将用于由移动支付应用使用的多个加密密钥导入到移动设备的系统域中。虽然执行移动支付应用的步骤在导入之前，但是应该认识到的是，示例性实施例不限于此。例如，可以在执行移动支付应用之前导入加密密钥。作为另一个示例，可以在移动支付应用正在执行的同时导入加密密钥。在740中，该方法还包括在用户域中执行移动支付应用时，使用一个或多个导入的密钥对系统域中的移动支付应用的支付信息进行加密。根据各种示例性实施例，可以由移动设备的操作系统防止或限制可以由每个密钥执行的操作或功能的类型。例如，密钥可以被限制为仅用于加密，而不用于解密(反之亦然)。作为另一个示例，可以将密钥导入到系统域中，但不导出。在750中，该方法还包括将加密的支付信息发送到商家，诸如运行商家网站的商家服务器或第三方服务器。这里，该发送可以包括将加密的支付信息从系统域直接发送到商家，而不通过用户域传送加密的支付信息。

在图7的示例中，导入可以包括将多个加密密钥导入到在系统域中操作的密钥库中。在这种情况下，用户域和系统域之间可以存在防火墙，从而为存储在系统域中的数据添加了另一层保护。而且，系统域可以不被移动设备的用户访问，并且可以在操作系统的唯一控制下。因此，在支付处理期间可以使用在用户域中执行的移动支付应用在更安全的环境中存储和操作加密密钥。例如，多个加密密钥可以包括用于解密从凭证管理系统(cms)接收到的内容的至少一个移动密钥、用于生成cda签名的集成电路卡(icc)密钥对等。而且，可以在系统域中生成一个或多个加密密钥，并将其存储在系统域中，诸如存储在密钥库中。作为示例，可以生成本地数据库加密(lde)密钥，用于解密和加密存储在本地数据库中由移动支付应用使用的数据。

根据各种示例性实施例，本文描述的是用于保护移动支付应用的加密密钥的系统和方法。示例性实施例通过移动设备的系统域导入、执行、逐出、以及发送和接收由支付应用使用的加密密钥。系统域可以在移动操作系统的唯一控制下，从而限制对加密密钥的访问，并且限制能够使用加密密钥执行的操作。

如本文所使用的，术语“卡”、“交易卡”、“金融交易卡”、“支付卡”等是指任何合适的交易卡，诸如信用卡、借记卡、预付卡、收费卡、会员卡、促销卡、常旅客卡、身份证、礼品卡等。作为另一个示例，术语可以指可以持有支付账户信息的任何其它设备或介质，诸如移动电话、智能电话、个人数字助理(pda)、钥匙扣、计算机等。交易卡可以用作执行交易的支付方法。

如基于前述说明书将认识到的，可以使用计算机编程或工程技术来实现本公开的上述示例，计算机编程或工程技术包括计算机软件、固件、硬件或其任何组合或子集。具有计算机可读代码的任何这样得到的程序可以在一个或多个非瞬态计算机可读介质内实施或提供，从而根据本公开所讨论的示例制作计算机程序产品，即制造品。例如，非瞬态计算机可读介质可以是但不限于：固定驱动器、软盘、光盘、磁带、闪存、诸如只读存储器(rom)的半导体存储器，和/或诸如因特网或其它通信网络或链路的任何发送/接收介质。包含计算机代码的制造品可以通过执行直接来自一个介质的代码、通过将代码从一个介质复制到另一个介质或通过在网络上发送代码来制造和/或使用。

计算机程序(也被称为程序、软件、软件应用、“应用”或代码)可以包括用于可编程处理器的机器指令，并且可以以高级过程式和/或面向对象的编程语言和/或以汇编/机器语言来实现。如本文所使用的，术语“机器可读介质”和“计算机可读介质”是指用于向可编程处理器提供机器指令和/或数据的任何计算机程序产品、装置和/或设备(例如，磁盘、光盘、存储器、可编程逻辑设备(pld))，包括将机器指令作为机器可读信号接收的机器可读介质。但是，“机器可读介质”和“计算机可读介质”不包括瞬态信号。术语“机器可读信号”是指可以用于向可编程处理器提供机器指令和/或任何其它种类数据的任何信号。

以上对本文的处理的描述和说明不应被视为暗示用于执行处理步骤的固定顺序。相反，可以以任何可行的顺序执行处理步骤，包括同时执行至少一些步骤。

虽然已经结合特定的示例性实施例描述了本发明，但是应该理解的是，在不脱离如所附权利要求中阐述的本发明的精神和范围的情况下，可以对所公开的实施例进行对本领域技术人员来说明显的各种更改、替换和变更。