Terminal Hardware Configuration System

Abstract

The present disclosure relates to a terminal hardware configuration system, and the disclosed content is a method for installing and running an application program on a terminal, including uploading the application program to an application store; downloading the application program from the application store by the terminal, where the terminal is connected to the application store through a network; and authorizing the terminal to install and run the downloaded application program by a TMS coupled to the terminal and the application store through the network.

Description

[0001] This application is a divisional application of a Chinese patent application with an application date of May 9, 2019, an application number of 2019800461992, and an invention title of "Terminal Hardware Configuration System". Technical Field

[0002] This disclosure relates to the update of point-of-sale (PoS) terminals and payment terminals. Background Art

[0003] In recent years, mobile payment systems based on smart devices have become very common. These examples include electronic or digital wallets that store, for example, bank account information, membership cards, stored value payment information; and other payment methods such as QR code-based payment methods. Leaving aside these consumer-side payment applications, for payment purposes, in addition to traditional electronic funds transfer at the point of sale (EFTPOS) systems, merchants are increasingly using smart device-based systems. In addition to traditional EFTPOS systems, the use of mobile point-of-sale (MPOS) devices (such as card reader dongles) and other physical interfaces (such as cameras and near field communication (NFC)) is also increasing.

[0004] Payment applications or payment "apps" used in such smart device-based mobile payment systems are typically deployed and maintained through application stores or markets associated with the smart mobile device operating system (OS) platform. The security of these systems is a concern. The processing of sensitive information (such as account data, biometric data, passwords, and personal identification numbers (PINs)) within smart devices is a matter of concern. The reliability and integrity of payment applications are another matter of concern. Some issues that need to be addressed include:

[0005] - Determining whether an application downloaded from an application store or application market is trustworthy,

[0006] - Determining whether the application is running on a smart device that is acceptable for running such an application, and

[0007] - Ensuring that unknown applications (which may perform phishing) and non-payment applications cannot use sensitive services and sensitive data.

[0008] In addition, traditional EFTPOS is evolving into "smart" EFTPOS by using smart devices and hardware platform operating systems in order to take advantage of the rapid application development and application deployment of these platforms. Such smart EFTPOS systems help support alternative payment methods and other value-added services and enhance the user experience.

[0009] Typically, payment applications for such intelligent EFTPO systems are distributed and managed by payment platform owners, terminal vendors, or acquirers through a terminal management server (TMS) or a custom app store to fully control security. However, deploying and maintaining applications at a larger scale and in a timely manner with high quality of service (QoS) measures such as high uptime and guaranteed throughput means high operating costs. Generally, these parties do not have the resources and expertise of the intelligent device operating system platform owner to run the store and reduce design flaws and vulnerabilities in the store.

[0010] Therefore, there is a great need to use the app store provided by the intelligent device operating system platform owner to distribute and maintain these applications. In this case, the following security issues should be addressed:

[0011] - Additional verification requirements for applications and application data;

[0012] - Restricting payment applications so that these applications only run on authorized and intended EFTPOS or intelligent devices for payment purposes, rather than on general intelligent devices; and

[0013] - Allowing other applications to run securely on EFTPOS and intelligent devices for payment purposes.

[0014] Currently, basic verification measures are implemented for app stores on mobile platforms. Figure 1 The application verification process of the prior art is shown. In step 101, the application is published or uploaded to the app store. In step 102, the user requests to download the application from the app store. In step 103, the app image of the application is hashed using a hash function on the app store to create a hash value. Then the resulting hash value is signed with the private key of the app store. In step 104, the app image is bound to the signed app hash and sent to the user intelligent device. In step 105, the operating system on the user intelligent device verifies the downloaded application to determine if it is from the store. The encrypted app hash is decrypted using the public key of the app store, and the downloaded app image is hashed on the user intelligent device using the same hash function as on the app store. The decrypted hash and the hash corresponding to the downloaded app image are compared to verify whether the app image has

[0015] - Authenticity, that is, the app image is genuine, and

[0016] - Integrity, that is, the app image is good.

[0017] In step 106, a verification process is performed. If the downloaded application passes the verification process in step 106, the application is installed and executed in step 107. If it does not pass the verification process, the application is deleted in step 108.

[0018] In this case, the application vendor relies on the private key of the app store and the public key of the app store to ensure the authenticity of the application.

[0019] Alternatively, the application vendor can maintain the authenticity of the application by signing the application with the application vendor's own private key, and the corresponding public key of the application vendor is installed on the user's smart device. Figure 2 The prior art process using the private key and public key of the application vendor is shown. Figure 2 Steps 201–208 are similar to steps 101–108, except that:

[0020] - In step 203, the hash is signed using the private key of the application vendor, and

[0021] - In step 205, the user smart device OS decrypts the signed application using the public key of the application vendor.

[0022] Some app stores, such as the Android Play store, also provide a way for application vendors to sign their applications, rather than just being signed by the key.

[0023] In some cases, both the vendor and the app store owner require application verification before installation and execution. Then, the application hash is encrypted using both the vendor's private key and the app store's private key, and decrypted using both the vendor's public key and the app store's public key. Figure 3 The prior art process for this is shown. Figure 2 Steps 301 - 308 are similar to Figure 1 steps 101 - 108, except that:

[0024] - In step 303, the hash is encrypted using both the private key of the application vendor and the private key of the app store. For example, this is achieved by cascading the two encryption processes; and

[0025] - In step 305, the user smart device OS decrypts the signed application hash using the public key of the application vendor and the public key of the app store.

[0026] In other cases, more than two parties are required to sign the application. In these cases, the application is encrypted more than twice and verified more than twice, rather than Figure 3 exactly twice as shown. In all these cases, the verification requires the support from the app store and the operating system.

[0027] In addition to enabling the smart device to determine whether the downloaded application is a genuine and good application verification, there are also cases where the device needs to be further authorized to run the application. For example, some terminals may not be authorized to run certain applications. Therefore, in addition to the verification process, an authorization process is also required. The authorization process ensures that the terminal is authorized to install and run the application.

[0028] Such an authorization process (e.g., for licensing) is necessary. As part of the software registration process running on the user's smart device, the license key is usually delivered to the user device in an out-of-band channel, and the user is asked to enter the key to activate the application for use via the software vendor's remote license server. Then, the software vendor further binds the software license to the hardware address of the user's smart device (e.g., the network interface MAC address). Summary of the Invention

[0029] A system for installing and running an application for a terminal, the system comprising an app store; a terminal management server (TMS); wherein the TMS, the app store, and the terminal are coupled to each other via a network; wherein a vendor uploads the application to the app store, and the terminal downloads the application via the network; and wherein after the download by the terminal, the TMS authorizes the terminal to install and run the downloaded application.

[0030] A system for installing and running an application for a terminal, the system comprising an app store; a terminal management server (TMS); wherein the TMS, the app store, and the terminal are coupled to each other via a network; wherein a vendor uploads the application to the app store, and the terminal downloads the application via the network; wherein the downloaded application is classified into one of a plurality of categories, and each category of the plurality of categories corresponds to an application category sandbox; and the classification is performed based on an authorization level and an application type.

[0031] A system for installing and running applications for a terminal, the system including an app store; a Terminal Management Server (TMS); wherein the TMS, the app store, and the terminal are coupled to each other via a network; wherein a vendor uploads either a patch of an application or an upgrade of the application to the app store, and the terminal downloads the patch or the upgrade via the network; and wherein after the download by the terminal, the TMS authorizes the terminal to install and run the patch or the upgrade.

[0032] A method for installing and running applications for a terminal, including: uploading an application to an app store; downloading the application from the app store by a terminal, wherein the terminal is connected to the app store via a network; and authorizing the terminal to install and run the downloaded application by a TMS coupled to the terminal and the app store via the network.

[0033] A method for installing and running applications for a terminal, including: uploading an application to an app store by a vendor; downloading the application from the app store by a terminal, wherein the terminal is connected to the app store via a network; classifying the downloaded application into one of a plurality of categories, each category of the plurality of categories corresponding to an application category sandbox, and the classification being performed based on an authorization level and an application type.

[0034] A method for installing and running applications for a terminal, including: either uploading a patch of an application or an upgrade of the application to the app store by a vendor; downloading the patch or the upgrade from the app store by a terminal, wherein the terminal is connected to the app store via a network; and authorizing the terminal to install and run the patch or the upgrade by a TMS coupled to the terminal and the app store via the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] For a more complete understanding, reference is now made to the following description taken in conjunction with the accompanying drawings:

[0036] Figure 1 Shows an application verification process of the prior art;

[0037] Figure 2 Shows a prior art process for signing an application using a private key and a public key of an application vendor;

[0038] Figure 3 Shows a prior art process for signing an application using a private key of an application vendor, a private key of an app store, a public key of an application vendor, and a public key of an app store;

[0039] Figure 4 Illustrates an embodiment of a system and method for the distribution of payment terminal software;

[0040] Figure 5 Illustrates an example embodiment of a terminal;

[0041] Figure 6 Illustrates an embodiment of a process for vendor distribution of an application;

[0042] Figure 7 Illustrates an embodiment of further measures to prevent sensitive portions of an application from running on unauthorized devices;

[0043] Figure 8 Illustrates an example embodiment of an application that segregates an application into different categories for an application category sandbox based on authorization level and application type; and

[0044] Figure 9 Illustrates an embodiment of a method for a vendor to upload an application containing a classification of an application in order to determine a relevant application category sandbox. Detailed Description

[0045] Referring now to the drawings, in which like reference numerals are used throughout herein to denote like elements, various views and embodiments of a system and method for the distribution of payment terminal software are shown and described, and other possible embodiments are described. The drawings are not necessarily to scale, and in some instances, the drawings have been enlarged and / or simplified in some places for purposes of illustration. Based on the following possible embodiments, those of ordinary skill in the art will understand many possible applications and variations.

[0046] The system and method as the subject matter of the following disclosure solves the problems outlined above. It enables EFTPOS systems and smart devices to be configured with new payment applications. For example, the system and method enables the distribution of payment applications to EFTPOS systems and smart devices for mobile payment via an application store of a smart device operating system platform, while alleviating the following problems:

[0047] - Additional verification requirements associated with such applications;

[0048] - Ensuring that payment applications run only on intended EFTPOS devices or smart devices for payment purposes and not on general-purpose smart devices; and

[0049] - Allowing other applications to run on intended EFTPOS devices or smart devices for payment purposes.

[0050] Figure 4 An embodiment of a system and method 400 of the presently disclosed subject matter is shown. The terminal 401 is a device for processing payments, for example,

[0051] - an EFTPOS terminal, or

[0052] - a smart device used as an MPOS device.

[0053] The Terminal Management Server (TMS) 402 performs the functions of obtaining and processing payment transactions from the terminal 401 and communicates with the terminal 401 to perform identification, verification, authorization, and authentication functions. The TMS 402 has the ability to receive and send information and also performs encryption and decryption when necessary. In some embodiments, an encrypted channel is used to perform the communication between the TMS 402 and the terminal 401. The Application Store 403 stores one or more applications for the vendor 404 to upload to the application store. The applications are distributed from the application store 403 to the terminal 401. All of these are coupled to each other via the network 405. The network 405 is constructed using one or more communication technologies known to those skilled in the art. These communication technologies include, for example, technologies related to the following: Local Area Network (LAN), Campus Area Network (CAN), Metropolitan Area Network (MAN), fiber optic network, wireless network, satellite communication link, terrestrial communication link, communication link, or Near Field Communication (NFC) link. In some embodiments, the network 405 consists of one or more subnets. In some of these embodiments, some of the subnets are private. In some of those embodiments, some of the subnets are public. In some embodiments, the communication within the network 405 is encrypted.

[0054] Figure 5 An example embodiment of the terminal 401 is shown. The terminal 401 includes a processor 501, an OS 502, a memory 503, a display 504, an application installation controller 505, an input device 506, and a communication module 507. Examples of the input device 506 include a keypad, a keyboard, an audio input device, a camera, etc. The communication module 507 is capable of encrypting the data before sending and decrypting the data after receiving.

[0055] As described above, in some embodiments, the TMS 402 and the terminal 401 communicate with each other via the network 405 using an encrypted channel. Examples of the encryption techniques used include:

[0056] - symmetric encryption techniques, such as techniques based on a shared secret, and

[0057] - asymmetric encryption techniques.

[0058] In some embodiments, the terminal 401 communicates with the TMS 402 to indicate to the TMS 402 that the terminal 401 wants to install and run an application. Then the TMS 402 performs the following functions:

[0059] - Grants the terminal 401 the permission to install and run the application, and

[0060] - Performs a vendor-based verification on the terminal 401 to install and run the application.

[0061] As mentioned above, the communication necessary to perform these functions is encrypted.

[0062] Therefore, since only authorized devices can communicate with the TMS 402 using the encrypted channel, this alleviates the concern of running payment applications on unauthorized devices such as general intelligent devices. This also eliminates the need for additional authorization mechanisms such as out-of-band license keys.

[0063] Figure 6 An embodiment of a process for vendor distribution of an application is shown, which includes the TMS 402 providing verification for the terminal 401 before installing and running the application. Steps 601 to 606 and 608 are identical to steps 101 to 106 and 108 in Figure 1 However, instead of using the private key of the application vendor and the public key of the application vendor as shown in Figure 3 Steps 611 to 617 are performed. In step 611 of Figure 6 The application installation controller 505 on the terminal 401 calculates the hash value of the application image. This is performed using a hash function stored, for example, in the memory 503 of the terminal 401.

[0064] Then, in step 612, before sending to the TMS 402, the terminal 401 signs the application image. This step includes encrypting the hash obtained by a unique-per-device key pair and submitting the signature together with the application image to the TMS 402. In one embodiment, a symmetric key scheme is used, that is, where the TMS 402 uses the same key as the terminal 401 for decryption. In one embodiment, then the signature uses a symmetric key or some way based on a shared secret with the TMS 402 to derive such a symmetric key. An example is where the TMS 402 derives the symmetric key from a base-key and a unique number from the terminal 401.

[0065] In another embodiment, an asymmetric key scheme is used, that is, where TMS402 decrypts using a different key than terminal 401. An exemplary embodiment could be a situation where terminal 401 has a private key and sends a signature of a certificate with its public key, so the TMS can verify and extract the terminal public key and use that terminal public key to verify the signature.

[0066] Steps 613 - 617 relate to the authorization and verification steps performed by TMS 402. In step 613, TMS 402 receives the signed application image and decrypts the received encrypted hash. In step 614, TMS 402 calculates a hash for the received application image using the stored hash function. In step 615, TMS 402 compares the two hash values. If the two hash values match each other, then in step 616, TMS 402 verifies the application and authorizes terminal 401 to install and run the application. If the two hash values do not match each other, then in step 617, TMS 402 indicates to terminal 401 that the application is invalid.

[0067] Although the keys for each device are described as unique above, there are other possibilities. For example, the keys can be unique for each account, unique for each session, or unique for each download. This provides stronger security compared to the prior art where the keys are limited to being unique for each application image.

[0068] Since the signature for vendor application verification no longer needs to be bound to the application download package, the application is transparent to a standard app store. This is because the process of downloading the application is similar to the process of downloading other non - payment applications. This makes it easier for an app store using a smart device operating system to be used for the purpose of distributing and managing payment applications for the terminal.

[0069] Since the applications for the terminal are expected to be distributed in a normal smart device platform app store (such as Playstore), other devices can also download and run these applications, except for the terminals expected to be used for payment. This is not desirable. As described above, a security measure is needed to communicate with TMS 402 through an encrypted channel. Figure 7 An embodiment showing a further security measure to prevent sensitive parts of an application from running on unauthorized devices is shown. In Figure 7 :

[0070] - As shown in step 701, before uploading the application to the app store, vendor 404 encrypts one or more parts of the application code that handle sensitive operations, and

[0071] - InFigure 6 After the process of Figure 6 , once the TMS 402 verifies and authorizes the installation and execution of the application on the terminal 401, in step 702, the terminal 401 obtains a decryption key from the TMS 402 to decrypt one or more parts of the encrypted application image.

[0072] Steps 701 and 702 serve to prevent the protected code segment from being exposed outside the trusted terminal execution environment, and the protected code segment prevents the application from performing critical / sensitive operations on devices or platforms other than the expected terminal with the expected EFTPOS platform.

[0073] In some embodiments, an application category sandbox is used to protect system resources and applications from unauthorized access. In one embodiment, applications are divided into 3 categories, each category having a corresponding application category sandbox to achieve application separation based on the authorization level and application type. In some embodiments, an application category sandbox is also used in addition to, for example, existing Linux / Android sandboxes.

[0074] Figure 8 An example embodiment showing such separation into different categories and subsequently using an application-level sandbox is shown. Figure 8 Shows the attributes of each category in Table 800. Figure 8 Row 801 of Figure 8 corresponds to Category A, Figure 8 Row 802 of Figure 8 corresponds to Category B, and row 803 corresponds to Category C. Column 804 describes the application types covered by each category, column 805 describes the security objectives of each category, and column 806 describes the control method. For the remainder of this description, each cell of Table 800 is represented by (row, column). For example, the cell indicating the type of application covered in Category A is in the cell within row 801 and column 804, and will thus be represented as (801, 804).

[0075] Category A covers authorized payment applications, as shown in cell (801, 804). Category B covers authorized non-payment applications, as shown in cell (802, 804). Category C covers unauthorized applications, as shown in cell (803, 804).

[0076] The security objectives for each category are different. For Class A applications: as shown in cells (801, 805), since these are authorized payment applications, the operating system (OS) does not restrict these applications' access to sensitive data and functions. Thus, these applications are placed in a relatively loose application category sandbox, the restrictions of which are similar to, for example, the application sandbox in Security-Enhanced Linux (SE-Linux), as shown in cells (801, 806).

[0077] For Class B applications, as shown in cells (802, 805), the operating system (OS) restricts these applications' access to sensitive data and functions (such as the function of reading financial card data and certain related functions for encryption operations). Therefore, these applications will not be able to affect such sensitive assets. This significantly reduces the workload of the application approval process. Thus, in addition to the restrictions of the application category sandbox for Class A applications, the application category sandbox for Class B applications also has restrictions on access to sensitive data and functions, as shown in cells (802, 806).

[0078] For Class C applications, as shown in cells (803, 805), since these applications are not authorized by the vendor, in addition to the security objectives of Class B applications that restrict access to sensitive functions and sensitive data, the operating system (OS) also prevents these applications from requesting data from consumers and merchants, which may cause security issues. Specifically, for EFTPOS, the risk of an unknown application is that the application may request the user to enter verification information, such as a personal identification number (PIN) or a bank card account number. In one embodiment, a combination of one or more techniques is used to warn the user not to enter such information when running a Class C application. These warning techniques operate independently of the application and have the following effect: if an unauthorized application displays a misleading message that requests the input of sensitive information (such as payment data) into the application, then since the application has no control over the operation of these techniques, the user will be warned not to enter sensitive information into the application. These methods include, for example:

[0079] - Screen watermark,[

[0080] - Screen flitter,[

[0081] - Screen status bar,[

[0082] - Screen border,[

[0083] - Screen overlay,[

[0084] - Dedicated indicator light,[

[0085] - Warning sound, and

[0086] - Warning vibration.

[0087] Therefore, compared with the restrictions of the application category sandbox of Class B applications, the application category sandbox of Class C applications has additional restrictions.

[0088] Those skilled in the art should know that the above-mentioned and Figure 8 the methods described in can be generalized to more than 3 categories.

[0089] In some embodiments, the operating system determines the category of the application being installed. This determination is based on, for example:

[0090] - The property field of the application,

[0091] - The signature key of the application, or

[0092] - When verifying the application, the information from TMS 402.

[0093] Figure 9 Illustrates an embodiment of a method for a vendor to upload an application that includes a classification of the application to determine the relevant application category sandbox. Steps 901 to 906 and 908 are exactly the same as Figure 6 steps 601 to 606 and 608. If the application downloaded in step 906 passes the verification process, then in step 907, it is determined whether the application is an EFTPOS vendor application. If it is not an EFTPOS vendor application, then in step 908, the application is installed as a Class C application. If it is an EFTPOS vendor application, step 911 is executed. Steps 911 to 917 are exactly the same as Figure 6 steps 611 to 617. In step 918, it is determined whether the application is a payment application. If it is a payment application, then in step 919, the application is installed as a Class A application. If not, then in step 920, the application is installed as a Class B application.

[0094] Generally, applications may require patches, upgrades for program defects and vulnerabilities, and the introduction of new features. For EFTPOS vendors, usually these updates are released by the terminal vendor, the acquirer, or other third parties certified by the electronic payment industry standards. However, due to the scale of the new operating system, the size of updates and patches is significantly larger than that of ordinary EFTPOS firmware and programs, which means an excessive load on traditional terminal management systems or other traditional distribution channels, which is highly undesirable.

[0095] In one embodiment, the above-mentionedFigure 6 and Figure 9 The process outlined in Figure 6 can be generalized to other processes. Since the app stores of most smart device operating systems are well-equipped for the maintenance and update of applications, this also makes the maintenance and update of such applications easier. In addition, since the app stores of smart device operating systems have established procedures for improving the quality of service (QoS), this makes it easier to improve the quality of service. In this way, the authenticity, authority, integrity of the code and the privacy of sensitive code can be ensured through these methods.

[0096] An exemplary embodiment includes a system for installing and running an application for a terminal, the system including an app store and a Terminal Management Server (TMS), wherein the Terminal Management Server (TMS), the app store and the terminal are coupled to each other via a network, wherein a vendor uploads the application to the app store, and the terminal downloads the application via the network, and wherein after the download by the terminal, the TMS authorizes the terminal to install and run the downloaded application.

[0097] In one or more examples herein, after the terminal downloads the application, the TMS verifies the application.

[0098] In one or more examples herein, before the upload, the vendor encrypts one or more parts of the application, and the terminal obtains a decryption key from the TMS to decrypt the encrypted one or more parts after the verification and authorization.

[0099] In one or more examples herein, the encryption is operable to prevent the one or more parts of the application from being exposed outside a trusted environment.

[0100] In one or more examples herein, the decryption is operable to prevent the application from performing important or sensitive operations within an unauthorized platform.

[0101] In one or more examples herein, the decryption is operable to prevent the application from performing important or sensitive operations within an unauthorized platform.

[0102] An exemplary embodiment includes a system for installing and running applications for a terminal, the system including an app store, a Terminal Management Server (TMS), wherein the TMS, the app store, and the terminal are coupled to each other via a network, wherein a vendor uploads an application to the app store, and the terminal downloads the application program via the network, wherein the downloaded application is classified into one of a plurality of categories, each of the plurality of categories corresponding to an application program category sandbox, and the classification is performed based on an authorization level and an application type.

[0103] In one or more examples herein, the classification is based on at least one of the following: an attribute field within the application program, a signature key associated with the application program, and information from the TMS when the application is being verified.

[0104] In one or more examples herein, at least one of the plurality of categories includes non-payment-related applications.

[0105] In one or more examples herein, a first category of the plurality of categories includes unauthorized and non-payment-related application programs, wherein the first category is associated with an application program category sandbox having restrictions on a user inputting one or more sensitive information.

[0106] In one or more examples herein, one or more warning techniques are associated with the first category, wherein the one or more warning techniques run independently of the application programs included in the first category, and wherein the one or more warning techniques are used to warn a user not to input the one or more sensitive information.

[0107] In one or more examples herein, the classification is performed after the download.

[0108] An exemplary embodiment includes a system for installing and running applications for a terminal, the system including an app store, a Terminal Management Server (TMS), wherein the TMS, the app store, and the terminal are coupled to each other via a network, wherein a vendor either uploads a patch of an application program to the app store or uploads an upgrade of the application program to the app store, wherein the terminal downloads the patch or the upgrade via the network, and wherein after the download by the terminal, the TMS authorizes the terminal to install and run the patch and the upgrade.

[0109] An exemplary embodiment includes a method for installing and running an application for a terminal, the method including uploading the application to an application store, downloading the application program by the terminal from the application store, wherein the terminal is connected to the application store via a network, and authorizing, by a TMS coupled to the terminal and the application store via the network, the terminal to install and run the downloaded application program.

[0110] In one or more examples herein, the method further includes verifying the application program by the TMS after the downloading.

[0111] In one or more examples herein, the method further includes encrypting, by a vendor, one or more parts of the application program before the uploading, and obtaining a decryption key from the TMS to decrypt the encrypted one or more parts after the verification and authorization.

[0112] In one or more examples herein, the encryption is operable to prevent the one or more parts of the application program from being exposed outside a trusted environment.

[0113] An exemplary embodiment includes a method for installing and running an application for a terminal, the method including uploading, by a vendor, the application to an application store, downloading the application program by the terminal from the application store, wherein the terminal is connected to the application store via a network, and classifying the downloaded application program into one of a plurality of categories, each of the plurality of categories corresponding to an application program category sandbox, and the classification being performed based on an authorization level and an application type.

[0114] In one or more examples herein, the classification is based on at least one of the following: an attribute field within the application program, a signature key associated with the application program, and information from the TMS when the application program is being verified.

[0115] In one or more examples herein, at least one of the plurality of categories includes non-payment-related applications.

[0116] In one or more examples herein, a first category of the plurality of categories includes unauthorized and non-payment-related applications, wherein the first category is associated with an application program category sandbox having restrictions on a user inputting one or more sensitive information.

[0117] In one or more examples herein, the classification is performed after the downloading.

[0118] An exemplary embodiment includes a method for installing and running an application for a terminal, the method including, by a vendor, either uploading a patch of the application to an application store or uploading an upgrade of the application to the application store, and downloading, by the terminal, either the patch or the upgrade from the application store, wherein the terminal is connected to the application store via a network, and authorizing, by a TMS coupled to the terminal and the application store via the network, the terminal to install and run the patch or the upgrade.

[0119] It should be understood that the drawings and detailed description herein are to be regarded in an illustrative rather than a restrictive manner, and are not intended to be limited to the particular forms and examples disclosed. On the contrary, any further modifications, changes, rearrangements, substitutions, alternatives, design choices, and embodiments that are obvious to those skilled in the art as defined by the following claims are included without departing from the spirit and scope herein. Accordingly, the following claims are intended to be construed to include all such further modifications, changes, rearrangements, substitutions, alternatives, design choices, and embodiments.

Claims

1. A method for managing the verification of an application for installation and execution on a terminal, comprising: Receiving, by a server computer system, an image of a downloaded application and a signature generated by the terminal from the image from the terminal, wherein the signature includes an encryption of a hash value computed by the terminal for the downloaded application, wherein the image of the downloaded application is received by the server computer system from the terminal after a first verification of the downloaded application by the terminal using a public key of an application store, wherein the downloaded application is uploaded by a vendor to the application store, and one or more portions of the downloaded application that process sensitive information are encrypted by the vendor before the upload; Decrypting, by the server computer system, the encryption of the hash value to generate a received hash value; Generating, by the server computer system, a hash value from the image using a hash function; Comparing, by the server computer system, the generated hash value with the received hash value; In response to determining that the generated hash value matches the received hash value, authorizing, by the server computer system, the terminal to install and execute the downloaded application; and After the authorization, providing, by the server computer system, a decryption key of the vendor to the terminal for decrypting the one or more portions of the downloaded application so that the downloaded application can process the sensitive information when executed by the terminal.

2. The method according to claim 1, characterized in that, Further comprising: Receiving, by the server computer system, the decryption key of the vendor from the vendor.

3. The method according to claim 1, characterized in that, The encryption of the hash value computed by the terminal is computed using a symmetric encryption key of the terminal, and the method further comprises: Accessing, by the server computer system, a copy of the symmetric encryption key associated with the terminal; and Decrypting, by the server computer system, the encryption of the hash value using the accessed copy of the symmetric encryption key.

4. The method according to claim 3, wherein The accessing includes: Uploading, from a memory coupled to the server computer system, the copy of the symmetric encryption key; or Obtaining, based on a shared secret known to the server computer system and the terminal, the copy of the symmetric encryption key.

5. The method according to claim 1, wherein The encryption of the hash value computed by the terminal is computed using an asymmetric encryption key of the terminal, the method further comprising: Accessing, by the server computer system, a public key of the terminal; and Decrypting, by the server computer system, the encryption of the hash value using the public key of the terminal.

6. The method according to claim 1, wherein The server computer system communicates with the terminal via an encrypted communication channel of a communication network.

7. The method according to claim 1, characterized in that The server computer system is a payment processing server computer system, wherein the terminal includes a point-of-sale device, and wherein the server computer system is configured to process payment transactions received from the downloaded application.

8. The method according to claim 1, characterized in that, The authorization further includes: Transmitting information to the terminal via the server computer system, the information causing the terminal to classify the downloaded application as a payment processing application at least in part based on the information.

9. A non-transitory computer-readable storage medium storing instructions that, when executed by one or more processors of a server computer system, cause the server computer system to perform operations for managing the verification of applications to be installed and run on a terminal, the operations including: Receiving, via the server computer system, an image of a downloaded application from the terminal and a signature generated by the terminal from the image, where the signature includes an encryption of a hash value computed by the terminal for the downloaded application, where the image of the downloaded application is received by the server computer system from the terminal after a first verification of the downloaded application by the terminal using a public key of an application store, where the downloaded application is uploaded by a vendor to the application store, and one or more portions of the downloaded application that process sensitive information are encrypted by the vendor prior to the upload; Decrypting, via the server computer system, the encryption of the hash value to generate a received hash value; Generating, via the server computer system, a hash value from the image using a hash function; Comparing, via the server computer system, the generated hash value with the received hash value; In response to determining that the generated hash value matches the received hash value, authorizing, via the server computer system, the terminal to install and run the downloaded application; and After the authorization, providing, via the server computer system, a decryption key of the vendor to the terminal for decrypting the one or more portions of the downloaded application so that the downloaded application can process the sensitive information when executed by the terminal.

10. The non-transitory computer-readable storage medium according to claim 9, wherein Further including: Receiving, via the server computer system, the decryption key of the vendor from the vendor.

11. The non-transitory computer-readable storage medium according to claim 9, wherein The encryption of the hash value computed by the terminal is computed using a symmetric encryption key of the terminal, and the operations further include: Accessing, via the server computer system, a copy of the symmetric encryption key associated with the terminal; and Decrypting, via the server computer system, the encryption of the hash value using the accessed copy of the symmetric encryption key.

12. The non-transitory computer-readable storage medium according to claim 11, wherein The accessing includes: Uploading, from a memory coupled to the server computer system, the copy of the symmetric encryption key; or Obtaining, based on a shared secret known to the server computer system and the terminal, the copy of the symmetric encryption key.

13. The non-transitory computer-readable storage medium according to claim 9, wherein The encryption of the hash value computed by the terminal is computed using an asymmetric encryption key of the terminal, and the operations further include: Accessing, via the server computer system, the public key of the terminal; and Decrypt the encryption of the hash value using the public key of the terminal by the server computer system.

14. The non-transitory computer-readable storage medium according to claim 9, wherein The server computer system is a payment processing server computer system, where the terminal includes a point-of-sale device, and where the server computer system is configured to process payment transactions received from the downloaded application.

15. A server computer system, comprising: A memory; And One or more processors, coupled to the memory, configured to: Receive from a terminal an image of a downloaded application and a signature generated by the terminal from the image, where the signature includes an encryption of a hash value computed by the terminal of the downloaded application, where the image of the downloaded application is received by the server computer system from the terminal after the terminal uses the public key of an app store to perform a first verification of the downloaded application, where the downloaded application is uploaded to the app store by a vendor, and where one or more portions of the downloaded application that process sensitive information are encrypted by the vendor prior to the upload; Decrypt the encryption of the hash value to generate a received hash value; Generate a hash value from the image using a hash function; Compare the generated hash value with the received hash value; In response to determining that the generated hash value matches the received hash value, authorize the terminal to install and run the downloaded application; and After the authorization, provide the terminal with a decryption key of the vendor for decrypting the one or more portions of the downloaded application so that the downloaded application can process the sensitive information when executed by the terminal.

16. The server computer system according to claim 15, wherein The server computer system is a payment processing server computer system, where the terminal includes a point-of-sale device, and where the server computer system is configured to process payment transactions received from the downloaded application.

Images