终端硬件配置系统的制作方法

[0001]
本公开涉及销售点(pos)终端和支付终端的更新。


背景技术：

[0002]
近年来，基于智能设备的移动支付系统变得非常普遍。这些示例包括存储例如银行账户信息、会员卡、储值支付信息的电子或数字钱包；以及其他支付方法，如基于二维码(qr code)的支付方法。且不说这些消费者端的支付应用，为了支付目的，除了传统的销售点电子资金转账(eftpos)系统之外，商家也越来越多地利用基于智能设备的系统。除了传统的eftpos系统外，移动销售点(mpos)设备(如读卡器电子狗)和其他物理接口(如摄像头和近场通信(nfc))的使用也在增加。
[0003]
此类基于智能设备的移动支付系统中使用的支付应用或支付“应用程序(apps)”通常通过与智能移动设备操作系统(os)平台相关的应用商店或市场进行部署和维护。这些系统的安全性令人担忧。智能设备内的敏感信息(如账户数据、生物特征数据、密码和个人识别码(pin))的处理，就是一个值得关注的问题。支付应用程序的可靠性和完整性是另一个值得关注的问题。一些需要处理的问题包括：-确定从应用商店或应用市场下载的应用程序是否可信，-确定应用程序是否运行在可接受运行这样的应用程序的智能设备上，以及-确保未知的应用程序(该应用程序可能执行网络钓鱼)以及非支付应用程序不能使用敏感服务和敏感数据。
[0004]
此外，，传统的eftpos正在通过使用智能设备和硬件平台操作系统演变为“智能”eftpos，以便利用这些平台的快速应用程序开发和应用程序的部署。这种智能eftpos系统有助于支持可替代的支付方法和其他增值服务，并增强用户体验。
[0005]
通常，用于此类智能eftpo系统的支付应用程序由支付平台所有者、终端供应商或收单机构通过终端管理服务器(tms)或自定义应用商店进行分发和管理，以完全控制安全性。然而，以高服务质量(qos)措施(如高运行时间并保证吞吐量)在更大规模上并以及时的方式部署和维护应用程序，意味着高运行成本。通常，这些参与方不具备智能设备操作系统平台所有者的资源和专业知识来运行商店以及减少商店的设计缺陷和漏洞。
[0006]
因此，非常需要使用由智能设备操作系统平台所有者提供的应用商店来分发和维护这些应用程序。在这种情况下，应解决以下安全问题：-应用程序和应用程序数据的额外验证要求；-限制支付应用程序，使得这些应用程序仅运行在授权的预期的eftpos或用于支付目的的智能设备上，而不在通用智能设备上运行；以及-允许其他应用程序在eftpos和用于支付目的的智能设备上安全运行。
[0007]
目前，对移动平台的应用商店都实施了基本的验证措施。图1示出了现有技术的应用程序验证过程。在步骤101中，将应用发布或上传到应用商店中。在步骤102中，用户请求从应用商店下载该应用程序。在步骤103中，使用应用商店上的散列函数对应用程序映像
(app image)进行散列处理(hash)，以创建散列值。然后用应用商店的私钥对所得的散列值进行签名。在步骤104中，应用程序映像与已签名的应用散列(application hash)绑定在一起，并被发送到用户智能设备。在步骤105中，用户智能设备上的操作系统对该下载的应用程序进行验证，以确定它是否来自商店。使用应用商店的公钥对加密的应用程序散列进行解密，并且使用与应用商店上相同的散列函数，在用户智能设备上对下载的应用程序映像进行散列处理。将已解密的散列和对应于下载的应用程序映像的散列进行比较，以核实(verify)应用程序映像是否具有-真实性，也就是说，应用程序映像是真的，以及-完整性，也就是说，应用程序映像是好的。
[0008]
在步骤106中，执行验证过程。如果下载的应用程序通过了步骤106中的验证过程，则在步骤107中安装并执行该应用程序。如果没有通过验证过程，则在步骤108中，删除该应用程序。
[0009]
在这种情况下，应用程序供应商依赖应用商店的私钥和应用商店的公钥来确保应用程序的真实性。
[0010]
可替代地，应用程序供应商可以通过使用应用程序供应商自己的私钥对应用程序进行签名来维护应用程序的真实性，而对应的应用程序供应商的公钥安装在用户智能设备上。图2示出了使用应用程序供应商的私钥和公钥的现有技术过程。图2的步骤201
–
208与步骤101
–
108相似，除了：-在步骤203中，使用应用程序供应商的私钥对散列进行签名，以及-在步骤205中，用户智能设备os使用应用程序供应商的公钥对已签名的应用程序进行解密。一些应用商店，如的安卓市场(play store)，也为应用程序供应商提供了一种对他们的应用程序进行签名的方法，而不是仅仅由密钥进行签名。
[0011]
在某些情况下，供应商和应用商店所有者都要求在安装和运行之前进行应用程序验证。然后，使用供应商的私钥和应用商店的私钥两者对应用程序散列进行加密，并使用供应商的公钥和应用商店的公钥两者进行解密。图3示出了对此的现有技术的过程。图2的步骤301-308与图1的步骤101-108相似，除了：-在步骤303中，使用应用程序供应商的私钥和应用商店的私钥两者对散列进行加密。例如，这通过将这两个加密过程级联来实现；以及-在步骤305中，用户智能设备os使用应用程序供应商的公钥和应用商店的公钥对已签名的应用散列进行解密。
[0012]
在其他情况下，需要两个以上的参与方对该应用程序进行签名。在这些情况下，应用程序经过两次以上的加密和两次以上的验证，而不是图3所示的正好两次。在所有这些情况下，验证需要来自应用商店和操作系统的支持。
[0013]
除了使智能设备能够确定下载的应用程序是否是真的和好的应用程序验证之外，还存在需要对设备进一步授权以运行应用程序的情况。例如，某些终端可能没有被授权运行某些应用程序。因此，除了验证过程之外，还需要授权过程。授权过程确保终端被授权以安装和运行该应用程序。
[0014]
这种授权过程(例如，对于许可)是必要的。作为在用户智能设备上运行的软件注
册过程的一部分，通常在带外信道中将许可密钥递送给用户设备，并让用户输入密钥以经由软件供应商的远程许可服务器来激活该应用程序以供使用。然后，软件供应商进一步将软件许可绑定到用户智能设备的硬件地址(例如网络接口mac地址)。


技术实现要素：

[0015]
一种用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店；终端管理服务器(tms)；其中所述tms、应用商店和终端经由网络相互耦合；其中，供应商将应用上传到所述应用商店，所述终端经由所述网络下载所述应用；并且其中在由所述终端进行所述下载后，所述tms授权所述终端安装并运行所下载的应用。
[0016]
一种用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店；终端管理服务器(tms)；其中所述tms、应用商店和终端经由网络相互耦合；其中供应商将应用上传到所述应用商店，所述终端经由所述网络下载所述应用；其中将所下载的所述应用分类为多个类别之一，所述多个类别中的每一个类别对应于应用程序类别沙盒(sandbox)；以及所述分类基于授权级别和应用类型来执行。
[0017]
一种用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店；终端管理服务器(tms)；其中所述tms、应用商店和终端经由网络相互耦合；其中，由供应商或者将应用程序的补丁上传到所述应用商店，或者将应用程序的升级上传到所述应用商店，并且所述终端经由所述网络下载所述补丁或所述升级；以及其中在由所述终端进行所述下载后，所述tms授权所述终端安装并运行所述补丁或所述升级。
[0018]
一种用于安装和运行用于终端的应用程序的方法，包括：将应用上传到应用商店；由终端从所述应用商店下载所述应用，其中所述终端通过网络连接到所述应用商店；以及由经由所述网络耦合到所述终端和所述应用商店的tms授权所述终端安装并运行所下载的所述应用。
[0019]
一种用于安装和运行用于终端的应用程序的方法，包括：由供应商将应用上传到应用商店；由终端从所述应用商店下载所述应用，其中所述终端通过网络连接到所述应用商店；将所下载的所述应用分类为多个类别之一，所述多个类别中的每一个类别对应于应用程序类别沙盒，并且所述分类基于授权级别和应用类型来执行。
[0020]
一种用于安装和运行用于终端的应用程序的方法，包括：由供应商或者将应用程序的补丁上传到所述应用商店，或者将应用程序的升级上传到所述应用商店；由终端从所述应用商店下载所述补丁或所述升级，其中所述终端通过网络连接到所述应用商店；由经由所述网络耦合到所述终端和所述应用商店的tms授权所述终端安装和运行所述补丁或所述升级。
附图说明
[0021]
为了更全面地理解，现参考以下结合附图进行的描述：
[0022]
图1示出了现有技术的应用程序验证过程；
[0023]
图2示出了用于使用应用程序供应商的私钥和公钥对应用程序进行签名的现有技术的过程；
[0024]
图3示出了使用应用程序供应商的私钥、应用商店的私钥、应用程序供应商的公钥
和应用商店的公钥对应用进行签名的现有技术的过程；
[0025]
图4示出了用于支付终端软件的分发的系统和方法的实施例；
[0026]
图5示出了终端的示例实施例；
[0027]
图6示出了用于供应商分发应用程序的过程的实施例；
[0028]
图7示出了防止应用程序的敏感部分在未授权的设备上运行的进一步措施的实施例；
[0029]
图8示出了，基于授权级别和应用类型，将应用程序分离(segregation)为不同类别以用于应用程序类别沙盒的应用的示例实施例；以及
[0030]
图9示出了用于供应商上传包含应用程序的分类的应用程序，以便确定相关的应用程序类别沙盒的方法的实施例。
具体实施方式
[0031]
现在参考附图，其中在本文通篇使用相同的参考编号来表示相同的元件，示出和描述了用于支付终端软件的分发的系统和方法的各种视图和实施例，并且描述了其他可能的实施例。附图不一定按比例绘制，在某些情况下，为了说明的目的，在某些地方对附图进行了放大和/或简化。基于以下可能的实施例，本领域普通技术人员将理解许多可能的应用和变化。
[0032]
作为以下公开主题的系统和方法解决了前面概述的问题。它使得eftpos系统和智能设备能够被配置有新的支付应用程序。例如，该系统和方法使得能够经由智能设备操作系统平台的应用商店将支付应用程序分发到eftpos系统和用于移动支付的智能设备，同时缓解了以下问题：-与此类应用程序相关联的额外验证要求；-确保支付应用程序仅在预期的eftpos设备或用于支付目的的智能设备上运行，而不在通用智能设备上运行；以及-允许其他应用程序在预期的eftpos设备或用于支付目的的智能设备上运行。
[0033]
图4示出了当前公开主题的系统和方法400的实施例。终端401是用于处理支付的设备，例如，-eftpos终端，或-被用作mpos设备的智能设备。
[0034]
终端管理服务器(tms)402执行从终端401获取和处理支付交易的功能，并与终端401通信，以执行识别、核实、授权和验证功能。tms402具有接收和发送信息的能力，并且在必要时也执行加密和解密。在一些实施例中，使用加密信道来执行tms 402和终端401之间的通信。应用商店403存储一个或多个应用程序，供供应商404上传到该应用商店。将应用程序从应用商店403分发到终端401。所有这些通过网络405相互耦合。网络405使用本领域技术人员已知的一种或多种通信技术来构造。这些通信技术包括例如与以下技术相关的技术：局域网(lan)、校园网(can)、城域网(man)、光纤网络、无线网络、卫星通信链路、地面通信链路、通信链路或近场通信(nfc)链接。在一些实施例中，网络405由一个或多个子网组成。在这些实施例中的一些实施例中，一些子网是私有的。在其中一些实施例中，其中一些子网是公共的。在一些实施例中，在网络405内的通信是加密的。
[0035]
图5示出了终端401的示例实施例。终端401包括处理器501、os 502、存储器503、显示器504、应用程序安装控制器505、输入设备506和通信模块507。输入设备506的示例包括小键盘、键盘、音频输入设备、摄像机等。通信模块507能够在发送之前对数据进行加密，并在接收之后对数据进行解密。
[0036]
如上所述，在一些实施例中，tms402和终端401使用加密信道通过网络405相互通信。所使用的加密技术的示例包括：-对称加密技术，例如基于共享秘密的技术，以及-非对称加密技术。
[0037]
在一些实施例中，终端401与tms402通信以向tms402指示终端401想要安装和运行应用程序。然后tms402执行以下功能：-授予终端401安装和运行应用程序的权限，以及-对终端401进行基于供应商的验证以安装和运行应用程序。如前所述，执行这些功能所必需的通信是加密的。
[0038]
因此，由于只有授权的设备才能使用加密的信道与tms402通信，这缓解了在未授权的设备(如通用智能设备)上运行支付应用程序的担忧。这也消除了对额外授权机制(如带外许可密钥)的需要。
[0039]
图6示出了用于供应商分发应用程序的过程的实施例，该过程包括在安装和运行应用程序之前tms 402为终端401提供验证。步骤601到606以及608与图1中的步骤101到106及108完全相同。然而，不是使用如图3中所示的应用程序供应商的私钥和应用程序供应商的公钥来执行步骤611到617。在图6的步骤611中，终端401上的应用程序安装控制器505计算应用程序映像的散列值。使用例如存储在终端401的存储器503中的散列函数来执行。
[0040]
然后，在步骤612中，在发送到tms 402之前，终端401对应用程序映像进行签名。该步骤包括通过每个设备独特的(unique-per-device)密钥对得到的散列进行加密，并将签名与应用程序映像一起提交给tms402。在一个实施例中，使用对称密钥方案，也就是说，其中tms402使用与终端401相同的密钥进行解密。在一个实施例中，然后该签名利用对称密钥或基于对tms 402的共享秘密的某些方式来导出这种对称密钥。一个示例是其中tms 402从基础密钥(base-key)导出对称密钥，以及从终端401导出独特编号(unique number)。
[0041]
在另一实施例中，使用非对称密钥方案，也就是说，其中tms402使用与终端401不同的密钥进行解密。示例性实施例可以是这样的情况，其中终端401具有私钥并发送带有其公钥的证书的签名，所以tms可以核实和提取终端公钥，并使用该终端公钥来核实签名。
[0042]
步骤613-617涉及由tms 402执行的授权和验证步骤。在步骤613中，tms 402接收已签名的应用程序映像，并对接收到的加密散列进行解密。在步骤614中，tms 402使用存储的散列函数为接收到的应用程序映像计算散列。在步骤615中，tms 402比较两个散列值。如果两个散列值相互匹配，则在步骤616中，tms 402验证该应用程序并授权终端401安装和运行该应用程序。如果两个散列值相互不匹配，则在步骤617中，tms 402指示终端401该应用程序无效。
[0043]
虽然上面描述了每个设备的密钥是独特的，但是还有其他的可能性。例如，密钥可以是对于每个帐户独特的，对于每个会话独特的，或者对于每次下载独特的。与密钥仅限于对于每个应用程序映像是独特的现有技术相比，这提供了更强的安全性。
[0044]
由于用于供应商应用程序验证的签名不再需要与应用程序下载包绑定在一起，因此该应用程序对标准的应用商店是透明的。这是因为下载该应用程序的过程与下载其他非支付应用程序的过程类似。这使得使用智能设备操作系统的应用商店更容易用于分发和管理终端的支付应用程序的目的。
[0045]
由于用于终端的应用程序预期在正常的智能设备平台应用商店(如play store)中分发，除了预期用于支付的终端，其他设备也可以下载和运行这些应用程序。这并不是所期望的。如上所述，需要一种安全措施通过加密信道与tms 402通信。图7示出了防止应用程序的敏感部分在未授权的设备上运行的进一步安全措施的实施例。在图7中：-如步骤701所示，在将应用程序上传到应用商店之前，供应商404对处理敏感操作的应用程序代码的一个或多个部分进行加密，以及-在图6的过程之后，一旦tms 402验证并授权在终端401上安装和运行应用程序，则在步骤702中，终端401从tms402获得解密密钥，以对已加密的应用程序映像的一个或多个部分进行解密。步骤701和702起防止受保护的代码段被暴露在受信任的终端执行环境之外的作用，并且该受保护的代码段防止应用程序在具有预期eftpos平台的预期终端以外的设备或平台中执行重要/敏感操作。
[0046]
在一些实施例中，应用程序类别沙盒用于保护系统资源和应用程序不被未授权的应用程序访问。在一个实施例中，应用程序被分为3个类别，每个类别具有对应的应用程序类别沙盒，以便基于授权级别和应用类型来实现应用分离。在一些实施例中，还使用除了例如现有的linux/android沙盒之外的应用程序类别沙盒。
[0047]
图8示出了这种分离为不同的类别，随后使用应用程序级别沙盒的示例实施例。图8示出了表800中每个类别的属性。图8的行801对应于类别a，图8的行802对应于类别b，行803对应于类别c。列804描述了每个类别所涵盖的应用程序类型，列805描述了每个类别的安全性目标，列806描述了控制方式。对于本说明的其余部分，表800的每个单元格用(行、列)表示。例如，指示类别a中所涵盖的应用程序的类型的单元格在行801和列804内的单元格中，因此将被表示为(801，804)。
[0048]
类别a涵盖已授权的支付应用程序，如单元格(801，804)所示。类别b涵盖已授权的非支付应用程序，如单元格(802，804)所示。类别c涵盖未授权的应用程序，如单元格(803，804)中所示。
[0049]
每个类别的安全性目标是不同的。对于a类应用程序：如单元格(801，805)中所示，由于这些是已授权的支付应用程序，操作系统(os)不会限制这些应用程序对敏感数据和功能的访问。从而，这些应用程序被放在一个相对宽松的应用程序类别沙盒中，其限制类似于例如在安全增强型linux(se-linux)中的应用程序沙盒，如单元格(801，806)中所示。
[0050]
对于b类应用程序，如单格元(802，805)中所示，操作系统(os)限制这些应用程序对敏感数据和功能(例如读取金融卡数据的功能，以及用于加密操作的某些相关功能)的访问。因此，这些应用程序将无法影响此类敏感资产。这显著地减少了应用程序审批过程的工作量。因此，除了a类应用程序的应用程序类别沙盒的限制外，b类应用程序的应用程序类别沙盒对敏感数据和功能的访问也有限制，如单元格(802，806)中所示。
[0051]
对于c类应用程序，如单元(803，805)中所示，由于这些应用程序未经供应商授权，
除了限制访问敏感功能和敏感数据的b类应用程序的安全性目标外，操作系统(os)还阻止这些应用程序向消费者和商家请求数据，这些请求可能会导致安全问题。具体地，对于eftpos，未知应用程序的风险在于，该应用程序可能要求用户输入验证信息，例如个人识别号(pin)或银行卡帐号。在一个实施例中，使用一种或多种技术的组合来警告用户在运行c类应用程序时不要输入此类信息。这些警告技术独立于应用程序来运行，并具有以下效果：如果有未授权的应用程序显示误导性消息，该误导性消息请求向应用程序输入敏感信息(例如支付数据)，那么由于该应用程序无法控制这些技术的操作，用户将被警告不要向应用程序中输入敏感信息。这些方法包括，例如：-屏幕水印，-屏幕飞印，-屏幕状态栏，-屏幕边界，-屏幕覆盖(screen overlay)，-专用指示灯，-警告声，以及-警告振动。因此，与b类应用程序的应用程序类别沙盒的限制相比，c类应用程序的应用程序类别沙盒具有额外的限制。
[0052]
本领域技术人员应当知道，上述以及图8中描述的方法可推广到3个以上的类别。
[0053]
在一些实施例中，操作系统确定正在安装的应用程序的类别。该确定基于，例如：-应用程序的属性字段，-应用程序的签名密钥，或-当正在验证应用程序时，来自tms 402的信息。
[0054]
图9示出了用于供应商上传应用程序的方法的实施例，该应用程序包含应用程序的分类以便确定相关的应用程序类别沙盒。步骤901到906和908与图6的步骤601到606和608完全相同。如果在步骤906中下载的应用程序通过验证过程，那么在步骤907中，判定该应用程序是否是eftpos供应商应用程序。如果不是eftpos供应商应用程序，则在步骤908中，该应用程序被安装为c类应用程序。如果是eftpos供应商应用程序，则执行步骤911。步骤911到917与图6的步骤611到617完全相同。在步骤918中，判定应用程序是否是支付应用程序。如果是支付应用程序，在步骤919中，则该应用程序被安装为类别a应用程序。如果不是，则在步骤920中，该应用程序被安装为b类应用程序。
[0055]
通常，应用程序可能需要用于程序缺陷和漏洞的补丁、升级以及新功能的引入。对于eftpos供应商，通常这些更新是由终端供应商、收单机构或经电子支付行业标准认证的其他第三方发布。但是，由于新的操作系统的规模，更新和补丁的大小都明显大于普通的eftpos固件和程序的大小，这意味着对于传统的终端管理系统或其他传统的分发渠道的负载过重，这是非常不期望的。
[0056]
在一个实施例中，上述图6和图9中概述的过程可以泛化到其他过程。因为大多数智能设备操作系统的应用商店对于应用程序的维护和更新都装备得较好，这也使得这类应用程序的维护和更新变得更加容易。此外，由于智能设备操作系统应用商店已经建立了提
高服务质量(qos)的程序，这使得提高服务质量变得更容易。这样，通过这些方法就可以保证代码的真实性、权威性、完整性以及敏感代码的隐私性。
[0057]
一个示例性实施例包括用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店和终端管理服务器(tms)，其中所述终端管理服务器(tms)、应用商店和终端经由网络相互耦合，其中供应商将应用程序上传到所述应用商店，并且所述终端经由所述网络下载所述应用程序，并且其中在由所述终端进行所述下载后，所述tms授权所述终端安装和运行所下载的应用程序。
[0058]
在本文的一个或多个示例中，在所述终端下载所述应用程序之后，所述tms验证所述应用程序。
[0059]
在本文的一个或多个示例中，在所述上传之前，所述供应商对所述应用程序的一个或多个部分进行加密，并且所述终端从所述tms获得解密密钥以在所述验证和授权之后对所加密的一个或多个部分进行解密。
[0060]
在本文中的一个或多个示例中，所述加密可操作以防止所述应用程序的所述一个或多个部分暴露在可信任的环境外。
[0061]
在本文的一个或多个示例中，所述解密可操作以防止所述应用程序在未授权的平台内执行重要操作或敏感的操作。
[0062]
在本文的一个或多个示例中，所述解密可操作以防止所述应用程序在未授权的平台内执行重要操作或敏感的操作。
[0063]
一个示例实施例包括用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店、终端管理服务器(tms)，其中所述tms、应用商店和终端经由网络相互耦合，其中供应商将应用上传到所述应用商店，并且所述终端经由所述网络下载所述应用程序，其中将所下载的应用分类为多个类别中的一个类别，所述多个类别中的每一个类别对应于应用程序类别沙盒，并且所述分类基于授权级别和应用程序类型来执行。
[0064]
在本文的一个或多个示例中，分类为基于以下项中的至少一个：所述应用程序内的属性字段、与所述应用程序相关联的签名密钥，以及当所述应用正在被验证时，来自tms的信息。
[0065]
在本文的一个或多个示例中，所述多个类别中的至少一个类别包含与支付无关的应用。
[0066]
在本文的一个或多个示例中，所述多个类别中的第一类别包含未授权的且与支付无关的应用程序，其中第一类别与具有对输入一个或多个敏感信息的用户的限制的应用程序类别沙盒相关联。
[0067]
在本文中的一个或多个示例中，一个或多个警告技术与所述第一类别相关联，其中所述一个或多个警告技术独立于包含在所述第一类别中的所述应用程序来运行，其中，所述一个或多个警告技术用于警告用户不要输入所述一个或多个敏感信息。
[0068]
在本文的一个或多个示例中，所述分类在所述下载之后执行。
[0069]
一个示例性实施例包括用于安装和运行用于终端的应用程序的系统，所述系统包括应用商店，终端管理服务器(tms)，其中所述tms、应用商店和终端经由网络相互耦合，其中供应商或者将应用程序的补丁上传到所述应用商店，或者将应用程序的升级上传到所述应用商店，其中所述终端经由所述网络下载所述补丁或所述升级，并且其中在由所述终端
进行所述下载后，所述tms授权所述终端安装和运行所述补丁和所述升级。
[0070]
一个示例性实施例包括用于安装和运行用于终端的应用程序的方法，该方法包括将应用上传到应用商店，由终端从所述应用商店下载所述应用程序，其中所述终端通过网络连接到所述应用商店，以及由经由所述网络耦合到所述终端和所述应用商店的tms授权所述终端安装并运行所下载的应用程序。
[0071]
在本文的一个或多个示例中，该方法还包括在所述下载之后由所述tms验证所述应用程序。
[0072]
在本文的一个或多个示例中，所述方法还包括在所述上传之前由供应商对所述应用程序的一个或多个部分进行加密，以及从所述tms获得解密密钥以在所述验证和授权之后对所加密的一个或多个部分进行解密。
[0073]
在本文中的一个或多个示例中，所述加密可操作以防止所述应用程序的所述一个或多个部分暴露在可信任的环境外。
[0074]
一个示例性实施例包括用于安装和运行用于终端的应用程序的方法，所述方法包括由供应商将应用上传到应用商店，由终端从所述应用商店下载所述应用程序，其中所述终端通过网络连接到所述应用商店，以及将所下载的应用程序分类为多个类别之一，所述多个类别中的每一个类别对应于应用程序类别沙盒，并且所述分类基于授权级别和应用程序类型来执行。
[0075]
在本文中的一个或多个示例中，分类基于以下项中的至少一个：所述应用程序内的属性字段、与所述应用程序相关联的签名密钥，以及当所述应用程序正在被验证时，来自tms的信息。
[0076]
在本文的一个或多个示例中，所述多个类别中的至少一个类别包含与支付无关的应用。
[0077]
在本文的一个或多个示例中，所述多个类别中的第一类别包含未授权的且与支付无关的应用，其中第一类别与具有对输入一个或多个敏感信息的用户的限制的应用程序类别沙盒相关联。
[0078]
在本文的一个或多个示例中，所述分类在所述下载之后执行。
[0079]
一个示例性实施例包括用于安装和运行用于终端的应用程序的方法，所述方法包括由供应商或者将应用程序的补丁上传到应用商店，或者将应用程序的升级上传到所述应用商店，并由终端从所述应用商店下载或者所述补丁或者所述升级，其中所述终端通过网络连接到所述应用商店，并且由经由所述网络耦合到所述终端和所述应用商店的tms授权所述终端安装和运行所述补丁或所述升级。
[0080]
应当理解，本文中的附图和详细描述将被视为以说明性的方式而不是限制性的方式，并且不旨在限制于所公开的特定形式和示例。相反，如以下权利要求所定义，对本领域技术人员来说明显的任何进一步的修改、改变、重新排列、替换、替代、设计选择和实施例都包括在内，而不超出本文的精神和范围。因此，以下权利要求旨在被解释为包含所有此类进一步的修改、改变、重新排列、替换、替代、设计选择和实施例。