Terminal hardware configuration system

Abstract

The invention relates to a terminal hardware configuration system, and discloses a method for installing and running an application program for a terminal, which comprises the following steps: uploading the application program to an application store; downloading, by a terminal, the application from an application store, wherein the terminal is connected to the application store over a network; and authorizing the terminal to install and run the downloaded application program by a TMS coupled to the terminal and an application store through a network.

Description

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

[0002] The present disclosure relates to the updating of point of sale (PoS) terminals and payment terminals. Background Art

[0003] In recent years, smart device-based mobile payment systems have become very common. 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 those based on QR codes. Apart from these consumer-side payment applications, for payment purposes, merchants are also increasingly utilizing smart device-based systems in addition to the traditional Electronic Funds Transfer at Point of Sale (EFTPOS) system. In addition to the traditional EFTPOS system, 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] The 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 handling of sensitive information within smart devices, such as account data, biometric data, passwords, and personal identification numbers (PINs), is a concern. The reliability and integrity of payment applications is another concern. Some issues that need to be addressed include:

[0005] - Determine whether the application downloaded from the app store or app market is trustworthy,

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

[0007] - Ensure 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 to take advantage of the rapid application development and deployment of applications on these platforms. This smart EFTPOS system helps support alternative payment methods and other value-added services and enhance the user experience.

[0009] Typically, payment applications for such smart EFTPO systems are distributed and managed by payment platform owners, terminal vendors or acquirers through terminal management servers (TMS) or custom application stores to fully control security. However, deploying and maintaining applications on 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. Typically, these parties do not have the resources and expertise of smart device operating system platform owners to run the store and reduce the store's design flaws and vulnerabilities.

[0010] Therefore, it is highly desirable to use an app store provided by the smart device OS platform owner to distribute and maintain these apps. In this case, the following security issues should be addressed:

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

[0012] - restrict payment applications so that they only run on authorised intended EFTPOS or smart devices for payment purposes and not on general purpose smart devices; and

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

[0014] Currently, basic verification measures are implemented on application 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 application store. In step 102, the user requests to download the application from the application store. In step 103, the application image is hashed using the hash function on the application store to create a hash value. The resulting hash value is then signed with the private key of the application store. In step 104, the application image is bound to the signed application hash and sent to the user's smart device. In step 105, the operating system on the user's smart device verifies the downloaded application to determine whether it is from the store. The encrypted application hash is decrypted using the public key of the application store, and the downloaded application image is hashed on the user's smart device using the same hash function as on the application store. The decrypted hash is compared with the hash corresponding to the downloaded application image to verify whether the application image has

[0015] - authenticity, that is, the application image is genuine, and

[0016] - Integrity, that is, the application 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 app vendor relies on the app store's private key and the app store's public key to ensure the authenticity of the app.

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

[0020] - in step 203, the hash is signed using the application vendor's private key, and

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

[0022] Some app stores, such as The Android Market (Play store) also provides a way for application vendors to sign their applications, rather than just Key for signing.

[0023] In some cases, both the vendor and the app store owner require application verification before installation and running. The application hash is then 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 A prior art process for this is shown. Figure 2 Steps 301-308 and Figure 1 Steps 101-108 are similar, except:

[0024] - In step 303, the hash is encrypted using both the application vendor's private key and the app store's private key. This is achieved, for example, by cascading these two encryption processes; and

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

[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, instead of Figure 3 In all of these cases, validation requires support from both the app store and the operating system.

[0027] In addition to application verification, which enables smart devices to determine whether a downloaded application is genuine and good, there are also situations where further authorization of the device is required 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] This authorization process (e.g., for licensing) is necessary. As part of the registration process for software running on a user's smart device, a license key is typically delivered to the user's device in an out-of-band channel and the user enters the key to activate the application for use via the software vendor's remote licensing server. The software vendor then further binds the software license to the hardware address (e.g., network interface MAC address) of the user's smart device. Summary of the invention

[0029] A system for installing and running an application for a terminal, the system comprising an application store; a terminal management server (TMS); wherein the TMS, the application store and the terminal are coupled to each other via a network; wherein a supplier uploads an application to the application store, and the terminal downloads the application via the network; and wherein after the download is performed 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 application store; a terminal management server (TMS); wherein the TMS, the application store and the terminal are coupled to each other via a network; wherein a supplier uploads an application to the application store, and the terminal downloads the application 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 category sandbox; and the classification is performed based on an authorization level and an application type.

[0031] A system for installing and running an application for a terminal, the system comprising an application store; a terminal management server (TMS); wherein the TMS, the application store and the terminal are coupled to each other via a network; wherein a supplier either uploads a patch of the application to the application store or uploads an upgrade of the application to the application store, and the terminal downloads the patch or the upgrade via the network; and wherein after the terminal performs the downloading, the TMS authorizes the terminal to install and run the patch or the upgrade.

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

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

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

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

[0036] Figure 1 The application verification process of the prior art is shown;

[0037] Figure 2 A prior art process for signing an application using the application vendor's private and public keys is shown;

[0038] Figure 3 The prior art process of signing an application using a private key of an application provider, a private key of an application store, a public key of an application provider, and a public key of an application store is shown;

[0039] Figure 4 Embodiments of systems and methods for distribution of payment terminal software are shown;

[0040] Figure 5 An example embodiment of a terminal is shown;

[0041] Figure 6 An embodiment of a process for a vendor to distribute an application is shown;

[0042] Figure 7 An embodiment of a further measure to prevent sensitive portions of an application from running on unauthorized devices is shown;

[0043] Figure 8 An example embodiment of an application that separates applications into different categories for application category sandboxing based on authorization level and application type is shown; and

[0044] Fig. 9 An embodiment of a method for a vendor to upload an application including a classification of the application in order to determine an associated application category sandbox is shown. DETAILED DESCRIPTION

[0045] Referring now to the drawings, in which like reference numerals are used throughout to represent like elements, various views and embodiments of systems and methods for the distribution of payment terminal software are shown and described, and other possible embodiments are described. The drawings are not necessarily drawn to scale, and in some cases, the drawings have been exaggerated and / or simplified in some places for the purpose of illustration. Based on the following possible embodiments, those of ordinary skill in the art will appreciate many possible applications and variations.

[0046] The system and method that is the subject 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 payments via the application store of the smart device operating system platform, while alleviating the following problems:

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

[0048] - ensure that the payment application is only run on the intended EFTPOS device or smart device used for payment purposes and not on generic smart devices; and

[0049] - Allows other applications to run on the intended EFTPOS device or smart device for payment purposes.

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

[0051] -EFTPOS terminal, or

[0052] -Smart devices used as MPOS devices.

[0053] The terminal management server (TMS) 402 performs the functions of acquiring 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 communication between the TMS 402 and the terminal 401. The application store 403 stores one or more applications for suppliers 404 to upload to the application store. The application is distributed from the application store 403 to the terminal 401. All of these are coupled to each other through a 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 technologies: local area network (LAN), campus 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, network 405 is composed of one or more subnets. In some of these embodiments, some of the subnets are private. In some of these embodiments, some of the subnets are public. In some embodiments, communications within network 405 are encrypted.

[0054] Figure 5 An example embodiment of a 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 data before sending and decrypting data after receiving.

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

[0056] - symmetric cryptographic techniques, such as those based on shared secrets, and

[0057] -Asymmetric encryption technology.

[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 the application. The TMS 402 then performs the following functions:

[0059] - granting the terminal 401 permission to install and run applications, and

[0060] - Vendor-based authentication of the terminal 401 to install and run the application.

[0061] As previously stated, the communications necessary to perform these functions are encrypted.

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

[0063] Figure 6 4 shows an embodiment of a process for a vendor to distribute an application, the process including TMS 402 providing authentication to terminal 401 before installing and running the application. Steps 601 to 606 and 608 are similar to Figure 1 Steps 101 to 106 and 108 in are identical. However, instead of using Figure 3 Steps 611 to 617 are performed using the application provider's private key and the application provider's public key as shown in FIG. Figure 6 In step 611 , the application installation controller 505 on the terminal 401 calculates a hash value of the application image. This is performed using a hash function stored in the memory 503 of the terminal 401 , for example.

[0064] Then, in step 612, the terminal 401 signs the application image before sending to the TMS 402. This step includes encrypting the resulting hash by a unique-per-device key and submitting the signature to the TMS 402 along with the application image. 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, the signature then utilizes a symmetric key or some method based on a shared secret to 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 the TMS 402 uses a different key for decryption than the terminal 401. An exemplary embodiment may be a case where the 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 it to verify the signature.

[0066] Steps 613-617 involve 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 a 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] While the above describes the key being unique per device, there are other possibilities. For example, the key could be unique per account, unique per session, or unique per download. This provides stronger security than the prior art where the key is limited to being unique per application image.

[0068] Since the signature used for vendor application verification no longer needs to be bundled with the application download package, the application is transparent to standard application stores. This is because the process of downloading the application is similar to the process of downloading other non-payment applications. This makes it easier to use application stores using smart device operating systems for the purpose of distributing and managing payment applications for terminals.

[0069] Since applications for terminals are expected to be available in normal smart device platform application stores (such as Playstore), other devices besides the intended payment terminals can also download and run these applications. This is not desirable. As mentioned above, a security measure is required to communicate with the TMS 402 through an encrypted channel. Figure 7 An embodiment of a further security measure to prevent sensitive portions of an application from running on unauthorized devices is shown. Figure 7 middle:

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

[0071] -exist Figure 6 After the process, once TMS 402 verifies and authorizes the installation and running of the application on terminal 401, in step 702, terminal 401 obtains a decryption key from 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 important / sensitive operations in a device or platform other than the intended terminal having the intended EFTPOS platform.

[0073] In some embodiments, application category sandboxes are used to protect system resources and applications from being accessed by unauthorized applications. In one embodiment, applications are divided into three categories, each with a corresponding application category sandbox, so as to achieve application separation based on authorization level and application type. In some embodiments, application category sandboxes other than, for example, existing Linux / Android sandboxes are also used.

[0074] Figure 8 An example embodiment of this separation into different categories followed by the use of application level sandboxing is shown. Figure 8 The attributes of each category in table 800 are shown. Figure 8 Row 801 of corresponds to category A, Figure 8 Row 802 of table 800 corresponds to category B, and row 803 corresponds to category C. Column 804 describes the types of applications covered by each category, column 805 describes the security goals for each category, and column 806 describes the control methods. For the remainder of this description, each cell of table 800 is represented by (row, column). For example, a cell indicating the types of applications covered in category A is in a cell within row 801 and column 804, and therefore would be represented as (801, 804).

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

[0076] The security goals for each category are different. For Category 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 permissive application category sandbox, whose restrictions are similar to the application sandbox in, for example, 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 (e.g., functions to read financial card data, and certain related functions for cryptographic operations). Therefore, these applications will not be able to affect such sensitive assets. This significantly reduces the workload of the application approval process. Therefore, 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 units (803, 805), since these applications are not authorized by the vendor, in addition to the security goal 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 requests may cause security issues. Specifically, for EFTPOS, the risk of unknown applications is that the application may require 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 sensitive information (such as payment data) to be entered into the application, then since the application cannot control 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 printing,

[0081] -Screen status bar,

[0082] - screen borders,

[0083] - screen overlay,

[0084] - Dedicated indicator light,

[0085] - warning sound, and

[0086] -Warning vibration.

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

[0088] Those skilled in the art should know that the above and Figure 8 The method 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 application's properties fields,

[0091] - the application's signing key, or

[0092] - Information from the TMS 402 when the application is being authenticated.

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

[0094] Typically, applications may require patches, upgrades for bugs and vulnerabilities, and the introduction of new features. For EFTPOS vendors, typically these updates are issued by the terminal vendor, acquirer, or other third party certified to the electronic payment industry standard. However, due to the size of the new operating system, the size of updates and patches is significantly larger than the size of normal EFTPOS firmware and programs, which means that the load on traditional terminal management systems or other traditional distribution channels is too heavy, which is highly undesirable.

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

[0096] An exemplary embodiment includes a system for installing and running an application for a terminal, the system including an application store and a terminal management server (TMS), wherein the terminal management server (TMS), the application store, and the terminal are coupled to each other via a network, wherein a vendor uploads an application to the application store, and the terminal downloads the application via the network, and wherein after the downloading 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, the provider encrypts one or more parts of the application before the uploading, and the terminal obtains a decryption key from the TMS to decrypt the encrypted one or more parts after the authentication and authorization.

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

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

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

[0102] An example embodiment includes a system for installing and running an application for a terminal, the system including an application store, a terminal management server (TMS), wherein the TMS, application store, and terminal are coupled to each other via a network, wherein a vendor uploads an application to the application store, and the terminal downloads the application 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 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: an attribute field within the application, a signing key associated with the application, and information from a TMS when the application is being authenticated.

[0104] In one or more examples herein, at least one of the plurality of categories includes applications that are not related to payment.

[0105] 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 category sandbox having restrictions on users entering 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 operate independently of the applications included in the first category, wherein the one or more warning techniques are used to warn a user not to enter the one or more sensitive information.

[0107] In one or more examples herein, the classifying is performed after the downloading.

[0108] An exemplary embodiment includes a system for installing and running an application for a terminal, the system including an application store, a terminal management server (TMS), wherein the TMS, the application store, and the terminal are coupled to each other via a network, wherein a supplier either uploads a patch of an application to the application store, or uploads an upgrade of an application to the application store, wherein the terminal downloads the patch or the upgrade via the network, and wherein after the downloading 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 an application to an application store, downloading the application from the application store by a terminal, wherein the terminal is connected to the application store via a network, and authorizing the terminal to install and run the downloaded application by a TMS coupled to the terminal and the application store via the network.

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

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

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

[0113] An exemplary embodiment includes a method for installing and running an application for a terminal, the method including uploading an application to an application store by a vendor, downloading the application from the application store by a terminal, wherein the terminal is connected to the application store via a network, and classifying the downloaded application into one of a plurality of categories, each of the plurality of categories corresponding to an application category sandbox, and the classification is 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: an attribute field within the application, a signing key associated with the application, and information from a TMS when the application is being verified.

[0115] In one or more examples herein, at least one of the plurality of categories includes applications that are not related to payment.

[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 category sandbox having restrictions on users entering one or more sensitive information.

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

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

[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, as defined by the following claims, any further modifications, changes, rearrangements, substitutions, alternatives, design options, and embodiments obvious to those skilled in the art are included without departing from the spirit and scope of this document. Therefore, the following claims are intended to be interpreted as including all such further modifications, changes, rearrangements, substitutions, alternatives, design options, and embodiments.

Claims

1. A method for managing authentication of an application for installation and operation on a terminal, comprising: receiving, by a server computer system, from the terminal an image of a downloaded application and a signature generated by the terminal from the image, wherein the signature comprises an encryption of a hash value calculated by the terminal of the downloaded application, wherein the image of the downloaded application is received by the server computer system from the terminal after the terminal first authenticates the downloaded application using a public key of an application store, wherein the downloaded application is uploaded to the application store by a vendor and one or more portions of the downloaded application that handle sensitive information are encrypted by the vendor prior to said uploading; 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, a hash value generated from the image with the received hash value; In response to determining that the hash value generated from the image matches the received hash value, authorizing the terminal, by the server computer system, to install and run the downloaded application; and After the authorization, the vendor's decryption key is provided to the terminal by the server computer system 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 Also includes: The decryption key of the vendor is received from the vendor by the server computer system.

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

4. The method according to claim 3, characterized in that The visit includes: uploading said copy of said symmetric encryption key from a memory coupled to said server computer system; or The copy of the symmetric encryption key is obtained based on a shared secret known to the server computer system and the terminal.

5. The method according to claim 1, characterized in that The encryption of the hash value calculated by the terminal is calculated using an asymmetric encryption key of the terminal, the method further comprising: accessing the public key of the terminal through the server computer system; and The encryption of the hash value is decrypted by the server computer system using the public key of the terminal.

6. The method according to claim 1, characterized in that 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 comprises 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 also includes: Information is transmitted to the terminal by the server computer system, the information causing the terminal to classify the downloaded application as a payment processing application based at least in part on the information.

9. A non-transitory computer-readable storage medium having instructions stored thereon, which, when one or more processors of a server computer system execute the instructions, causes the server computer system to execute the method for managing the verification of applications installed and run on a terminal according to any one of claims 1 to 8.

10. A server computer system comprising: Memory; and One or more processors, coupled to the memory, configured to execute the method according to any one of claims 1 to 8.

Images