System and method for transaction security enhancement

0001The disclosure relates generally to online payment management and, more specifically, to payment security.

0002Online trading is becoming more and more common with an ever-growing number of online operators, who may or may not have physical real-world counterparts. In addition, the services provided to these online operators have also been improved. The prevalence of online trading is due, in part, to the ease and convenience of bringing transactions online, rather than trading in physical locations. However, payment security is one of the major concerns with online payment systems and methods. What is needed is a secure payment platform and technology that can adequately address user concerns about the security of processing.

0003One of the broader forms of the present disclosure includes a system. The system includes a computer memory storage component that is configured to store computer programming instructions and a computer processor component that is operably coupled to the computer memory storage component, which is the computer processor component. Configured to operate secure and non-secure operating systems in parallel, isolated from each other, the computer processor component is an application from an application operated by a non-secure operating system. An operation that receives an authentication request that includes proof and communicates with a secure applet that operates on a secure operating system, and this communication transfers the proof of the application to the secure applet. It is configured to execute code to perform operations that include, and operations that authenticate and audit the application based on the proof of the application.

0004Other forms of the broader form of the present disclosure include a device comprising a non-temporary tangible machine-readable storage medium that stores a computer program, which computer program is said to be electronically executed by a processor. It includes machine-readable instructions that do the following, but they receive an authentication request containing an application proof from an application that resides in the non-secure part of the electronic chip, and secure that resides in the secure part of the electronic chip. Based on the communication with the applet, where the secure part is separated from the non-secure part, and this communication involves transferring the proof of the application to the secure applet, and based on the proof of the application. Perform, certify and audit the application.

0005Other forms of the broader form of this disclosure include methods of performing certification and audit. This method involves receiving an authentication request containing an application proof from an application located in the non-secure part of the electronic chip and communicating with a secure applet existing in the secure part of the electronic chip. The secure part is separate from the non-secure part, and this communication involves transferring the application's certificate to a secure applet and authenticating and auditing the application based on the application's certificate. ..

0006<figref num="1">It is a schematic block diagram of the electronic chip by various aspects of this disclosure content.</figref><figref num="2">It is a diagram of a high-level architecture for performing certification and audit in various aspects of the present disclosure.</figref><figref num="3">It is a figure of the method of performing the certification and examination by various aspects of this disclosure content.</figref><figref num="4">FIG. 5 is a diagram of a computer for implementing various steps of the method of FIG. 3 according to various aspects of the present disclosure.</figref>

0007It should be understood that the following disclosures provide many different embodiments or examples for implementing the various features of the present disclosures. In order to simplify the contents of the present disclosure, specific examples of components and configurations will be described below. These are, of course, just examples and are not intended to be limiting. Various features may be arbitrarily drawn on different scales for simplification and clarification.

0008As mobile computing and communication technologies continue to evolve, transactions involving mobile devices are becoming more and more common. The widespread use of trading through mobile devices is, in part, trading through mobile devices as an alternative to traditional trading in physical locations with tangible financial certificates (eg cash or checks). Due to the ease and convenience of (eg online purchase). However, as mobile transactions become more widespread, attacks targeting these transactions are also increasing. These attacks may include attempting to steal a user's personal or financial information, or the villain may attempt to pretend to be a legitimate seller.

0009This specification discloses methods and systems for increasing the security of mobile transactions so that the attacks discussed above are substantially thwarted or reduced.

0010With reference to FIG. 1, a schematic block diagram of the electronic chip 100 is shown. The electronic chip 100 can be mounted on mobile devices such as mobile phone handsets, computer tablets and laptops. In some embodiments, the electronic chip 100 includes a computer processor, such as an Advanced RISC Machine (ARM®) processor. This computer process unit may include memory storage capable of storing computer instructions. In other embodiments, the electronic chip 100 is, for example, read-only memory (ROM), FLASH, random access memory (RAM), hard disk, optical disk, magnetic disk, or other suitable type of volatile memory. Includes computer memory storage devices such as devices and non-volatile memory devices.

0011The electronic chip 100 is a TrustZone (registered trademark) compatible chip. TrustZone® is a technology developed by ARM Holdings® that provides a platform that supports a trusted environment in which applications can be run safely. More specifically, the electronic chip 100 includes a "normal world" 110A and a "secure world" 110B, which are separated from each other to prevent secure information from leaking from the secure world 110B to the normal world 110A. There is. These two worlds 110A and 110B operate in parallel with each other on the same electronic chip 100. Secure World 110B is preloaded and validated before the handset's main operating system launch time. In some embodiments, the World 110A typically operates the handset's main operating system and the Secure World 110B operates a different (more secure) operating system. Thus, the integrity of the components or applications that normally exist in the world 110A. Secure World 110B can be used to verify. In some embodiments, such integrity verification can be achieved by applying a set of control parameters to the latest known or privileged configuration.

0012The Normal World 110A and the Secure World 110B may each contain one or more software applications. In some embodiments, the software application that resides in Secure World 110B is sometimes referred to as an applet. For example, application 120 exists in the normal world and one or more secure applets 130 exist in the secure world. In some embodiments, Application 120 transfers money to or from a payment provider operator, such as PAYPAL, INC® in San Jose, Calif., Or a user's account. Includes parts of computer software programs developed by other suitable financial institutions possible. This application is available over the internet, for example GOOGLE PLAY® or APPLE APP It may be provided through STORE® and may be downloaded by the user. Application 120 may also include features and interfaces that help perform standard tasks that require a low level of security. For example, application 120 may include programming instructions that allow payment provider business entity users to use their accounts to perform standard administrative tasks such as searching their purchase history. In some other embodiments, application 120 may also be part of a computer software program developed by a third-party developer, such as a merchant who offers the sale of tangible or digital goods. .. In that case, application 120 from a third party developer, GOOGLE PLAY® or APPLE It can also be downloaded through the APP STORE®.

0013The secure applet 130, which exists in the secure world 110B, is a program module configured to perform secure tasks. In some embodiments, the secure applet 130 is another part of a computer software program developed by a payment provider operator. In other words, in that scenario, the secure applet 130 present in secure world 110B and the application 120 normally present in world 110A are two parts of a single downloadable application.

0014Application 120 resides in the normal world 110A, which has a lower level of security, so if a task that requires a higher level of security needs to be performed, application 120 may be an authentication service from the secure applet 130 or You may also request a review service. These secure tasks include certification entry service, secure identification entry service, secure user interface service, and key access (key). access) -Services, or encryption / decryption services, may be included, but not limited to these. Since the normal world 110A and the secure world 110B are separated, a software module known as the monitor 140 may be used to communicate between the normal world 110A and the secure world 110B. In some embodiments, the monitor 140 is the only means of communication between the normal world 110A and the secure world 110B. For example, monitor 140 can interface with application 120 without allowing application 120 to access any entity within secure world 110B. The monitor 140 can then relay the request from the application 120 to the target entity within the secure world 110B, such as the secure applet 130. Monitor 140 then feeds application 120, sometimes with required resources such as validation keys or tokens. Give back.

0015However, in the illustrated embodiment, the monitor 140 is largely (or at least partially) bypassed. Alternatively, the "hook" 150A normally present in the world 110A and the "hook" 150B present in the secure world 110B can be used to communicate between the normal world 110A and the secure world 110B. .. Hooks 150A and 150B can be software modules or logical functions running on monitor 140. The monitor 140 acts like a gateway between the two worlds 110A-110B, switching at the operating system level, and the hook 150A-150B effectively "opens" the gateway between the two worlds 110A-110B. Acts as a "door stop" to "leave" and switch at the application level. In some embodiments, hooks 150A-150B leave the gateway "keep open" for a single application. In other words, when used by one application, no other application that has not signed or approved hooks 150A-150B can drop its original application from the priority list. Each hook may be in its own space or in an application or applet within its respective world.

0016The hook 150B, which exists in the secure world 110B, is implemented by the resources of the monitor toolkit 160. The monitor toolkit 160 includes a complete set of monitor functions. For the first provisioning and activation, hook 150A and hook 150B may still pass through monitor 140, which is indicated by route 170. Direct communication can then be established between hook 150A and hook 150B, which is indicated by path 180. Thus, an entity that normally resides in world 110A, such as application 120, can also communicate with a trusted entity that resides in secure world 110B, such as a secure applet, through hooks 150A-150B, bypassing monitor 140.

0017It is possible to use the system described in Figure 1 to increase security within mobile device transactions. For example, if an application requesting authentication cannot seek validation by a remote secure entity (this may be due to a lost network connection or other reason), then secure in a secure world. You can also use applet 130 to authenticate or audit this application. This is possible even if the secure world 110 is local to the mobile device itself, but is already secure because the secure applet 130 (and other entities) resides in the secure world 110B. This is because the validity is recognized as. In this sense, the Secure World 110B of the Electronic Chip 100 is designed to perform tasks with increased security.

0018For example, a payment provider operator can allow a partner of this payment provider operator to develop applications for various plot forms where security validation is performed by the payment provider operator as well from the secure world. Developer kits can be provided to partners. Providing developers with a way to verify that their applications are legitimate not only reassures the end user about the integrity of the transaction, but also allows the developer to see fraudulent transactions. Limit the risk of doing so. This can be done by creating a subset of features that have been made to sign applications from third-party developers from the payment provider entity's mobile library. These third parties can take advantage of application programming interfaces (APIs) from payment providers to provide their own anti-spoofing / anti-phishing user experience.

0019At least two use cases apply. The "In App Payment" use case allows payment providers to provide their libraries to third-party developers, such as merchants. Applications developed by this third-party developer (eg, application 120) can also contain a library from the payment provider, but this will put the payment provider's secure world module (eg, application 120) in its own library. For example, a code string that is understood only by the secure applet 130) that exists in the secure world 110B is embedded. If a spoofed application attempts to imitate a legitimate application from a third-party developer, it will fail at the start of the payment module.

0020In the "In Flow Payment" user case, applications from third-party developers as well as applications from third-party payment providers are in stand-alone mode. At the time of payment, there is a transfer from one application to the other. A validation mechanism that validates the payment provider application's call by the third party application can be stored in Secure World 110B.

0021As an example to illustrate the above use case, suppose a merchant named "Big Mart" develops a shopping application that can be downloaded to a user's mobile device. "Big Mart" may be one of the partners of the payment provider business entity. Therefore, the payment provider business entity may provide its own library to "Big Mart". This library has embedded security mechanisms, such as keys that can be matched to corresponding keys. In fact, payment providers can assign different sets of keys to their multiple partner developers. Payment providers can keep a record of which keys are assigned to which developers and keep that information within their downloadable application.

0022Payment provider users download applications from payment providers as well as applications from "Big Mart" to their mobile devices. Users can make online purchases by using the application from "Big Mart". At this time, the "Big Mart" application may ask the user for confidential information such as the user's name, address, and credit card information. In traditional payment scenarios, the user cannot know that the application from "Big Mart" is legitimate or trustworthy. Here, "Big The Mart application can be authenticated or audited by a secure applet that exists in the secure world of the user's mobile device. In some embodiments, authentication may be the process of verifying the validity and / or security validity of a particular application for itself, and what is vetting? , May be the process of verifying the validity and / or security of a particular application against others. In other words, reviewing a particular application means that others can trust this. means and. Returning to the example, authentication and / or auditing of the "Big Mart" application can be done with the secure applet of a payment provider that exists in the secure world. Specifically, the "Big Mart" application presents its proof of authentication or proof of audit to the secure applet through a hook. The certification or examination certificate is "Big" by the payment provider business entity. May contain the key given to the "Mart" application. The secure applet looks up the key and attempts to pair it with the corresponding key stored in the secure world. If the key pairing is successful, this is "B It means that the "ig Mart" application is legitimate and credible, thus the "Big Mart" application is certified and audited. If the key pairing is not successful, this indicates that the "Big Mart" application may be a fake application and it will not be authenticated or audited.

0023In some embodiments, the authentication or audit of the "Big Mart" application may be communicated to the user in visible and / or audio representation on a mobile device. For example, the display screen of a mobile device tells the user that the "Big Mart" application can be authenticated and audited and that the user can proceed and provide sensitive information to the "Big Mart" application without fear of theft or data loss. A specific pattern can be displayed to inform the user.

0024FIG. 2 is a simplified high-level architecture 200 showing various aspects of the present disclosure. Architecture 200 includes a payment provider 210. The payment provider may be a business entity such as PAYPAL, INC® in San Jose, CA, or any other suitable financial institution capable of sending money to and from your account. There may be. Payment provider 210 has servers located remotely in the "cloud", with mutual authentication enablement services, post / pre-provisioning services, and remote enablement. (remote enablement) -Configured to provide services such as services and wireless (OTA) services.

0025Architecture 200 also includes a normal world 220A and a secure world 220B that operate in parallel with each other but are separated from each other. Trustlet (Secure Applet) 230 exists in Secure World 220B. The trustlet 230 may be an application trusted by the payment provider 210 (for example, the trustlet 230 may be an application developed by the payment provider 210). The trustlet 230 can communicate directly with the payment provider 210. App 240 (which can contain one or more applications) exists within Secure World 220A. App 240 communicates with an external entity 250 that needs to be operated securely, so it needs to switch to Secure World 220B. These secure operations may include certificate entry services, secure identity services, secure user interface services, key access services, or encryption / decryption services.

0026The normal operating system 260 normally operates the world 220A, and the secure operating system 270 operates the secure world. The Secure Monitor 280 normally acts as the default gateway between World 220A and Secure World 220B. However, operating system 260 is implemented to be able to control and maintain "hook" 290 within itself, and operating system 270 is capable of controlling and maintaining "hook" 295. Implemented in, in this case hooks 290-295 can be used to establish communication with Secure World 220B. In addition, the normal operating system 260 and secure operating system 270 respond to applications from trusted applications (eg, trustlet 230) that reside in secure world 220B and applications that normally reside in world 220A (eg, trustlet 230). Implemented so that the same hook 290-295 can be used to prove credit / review for app 240). In this way, there is usually an open flow between the World 220A and the payment provider 210. That is, monitor 280 does not block communication and manages applets and applications from the "cloud" (in other words, the remote server of payment provider 210). be able to.

0027Uses TrustZone®-enabled ARM® core processor 300 to execute instructions for normal operating system 260 and secure operating system 270. TrustZone®-enabled ARM® core processor 300 includes a secure vault 310. Both the private key 320 and the public key 330 can be stored in the secure vault 310. The private key 340 can also be stored remotely within the payment provider 210's server. These private and public keys can be used to perform authentication and / or audit tasks, for example for App 240.

0028It is understood that the high-level architecture 200 described above is just one of many examples of implementations of the concepts in this disclosure. Other embodiments may have details of various implementations without departing from the spirit and scope of the present disclosure.

0029FIG. 3 is a flowchart of a method 400 for performing an authentication task and an audit task according to various aspects of the present disclosure. Method 400 includes step 410, in which an authentication request is received from an application that resides in the non-secure portion of the electronic chip. In some embodiments, the electronic chip includes computer memory on a mobile electronic device. In other embodiments, the electronic chip includes a computer processor on a mobile electronic device. The authentication request includes proof of application. In some embodiments, such certification includes a certificate assigned to the developer of the application. For example, a certificate may contain a key.

0030Method 400 includes step 420, in which communication is made with a secure applet that resides in the secure portion of the electronic chip. The secure part is separated from the non-secure part. This communication involves transferring the application's proof to a secure applet. In some embodiments, the application is a software program from a third party developer and the secure applet is part of a software program from a payment provider. In other embodiments, both the application and the secure applet are part of a software program from the payment provider. Communication also occurs, at least in part, by bypassing at least partly the monitor configured as a gateway between the secure part of the electronic chip and the non-secure part of the electronic chip.

0031Method 400 includes step 430, in which the application is certified and audited based on the application's proof. In certain embodiments, authentication and auditing is done without accessing a remote server.

0032It can be seen that additional method steps can be performed before, during, or after steps 410-430 discussed above. However, for the sake of brevity, these additional steps are not specifically described or discussed herein.

0033FIG. 4 is a block diagram of a computer system 600 suitable for implementing the various methods and devices described herein, for example, the various method steps of method 400. Devices that can perform these steps in various implementations include network communication devices (eg mobile phones, laptops, personal computers, tablets, etc.), network computing devices (eg, networks). -Server, TrustZone (registered trademark) compatible computer processor, electronic network It may also include (such as a communication interface) or other suitable device. Therefore, it should be understood that a device on which Method 400 can be implemented can be implemented as Computer System 600 as follows.

0034According to various embodiments of the present disclosure, a computer system 600, such as a network server or mobile communication device, includes a bus component 602 or other communication mechanism for information communication, which is a TrustZone. Trademarks Corresponding Processing Component 604 (eg Processor, Micro Controller, Digital Signal Processor (DSP), etc.), System Memory Component 606 (eg RAM), Static Storage Component 608 (eg ROM), Disk Drive Component 610 (eg, magnetic or optical), Network Interface Component 612 (eg, modem or Ethernet card), Display Component 614 (eg, Cathode Ray Tube (CRT) Display or LCD Display (LCD)), Interconnect subsystems and components such as input component 616 (eg keyboard), cursor control component 618 (eg mouse or trackball), image capture component 620 (eg analog or digital camera). In one implementation, disk drive component 610 may include a database with one or more disk drive components.

0035According to an embodiment of the present disclosure, in a computer system 600, a TrustZone®-enabled processor 604 executes one or more sequences of one or more instructions contained in system memory component 606. To perform a specific operation. These instructions can be read into system memory component 606 from other computer-readable media such as static storage component 608 and disk drive component 610. In other embodiments, hard-wired circuits may be used instead of (or in combination with) software instructions to achieve this disclosure.

0036The logic can also be encoded in a computer-readable medium, which medium may also refer to any medium involved in providing instructions to the TrustZone®-enabled processor 604 for execution. Such media can take many forms, including non-volatile and volatile media, but are not limited to non-volatile and volatile media. In one embodiment, the computer-readable medium is a non-transient medium. In various embodiments, the non-volatile medium includes an optical disc or magnetic disk such as disk drive component 610, and the volatile medium includes dynamic memory such as system memory component 606. In one aspect, data and information related to execution instructions are transmitted to computer system 600 via transmission media such as those in the form of sound waves or light waves, including those generated during radio and infrared data communications. can do. In various implementations, the transmission medium may include coaxial cables, copper wire, and fiber optics, including wires with bus 602.

0037Some common forms of computer-readable media include, for example, floppy disks, flexible disks, hard disks, magnetic tapes, any other magnetic medium, CD-ROM, any other optical medium, punches. Cards, papertapes, any other physical medium with a pattern of holes, RAM, PROM, EPROM, FLASH-EPROM, any other memory chip or memory cartridge, carrier, or computer to read. Includes any other medium made.

0038In various embodiments of the present disclosure, the computer system 600 may execute the instruction sequence to realize the disclosure. Various other contents of this disclosure In embodiments, a plurality connected by communication links 630 (eg, communication networks such as LANs, WLANs, PTSNs and various other wired or wireless networks including telecommunications networks, mobile networks and mobile phone networks). Computer systems 600 may work together to execute instruction sequences to achieve this disclosure.

0039The computer system 600, including one or more programs (ie, application code), can transmit and receive messages, data, information and instructions through communication link 630 and communication interface 612. The received program code is TrustZone® compliant when it is accepted for execution in disk drive component 610 or some other non-volatile storage component and / or when it is stored there. May be executed by processor 604.

0040Where applicable, the various embodiments provided by the present disclosure may also be implemented using hardware, software, or a combination of hardware and software. Also, where applicable, the software, hardware, and / or a combination of the various hardware and / or software components described herein, without departing from the spirit of this disclosure. It can also be a composite component with both. Where applicable, the various hardware and / or software components described herein, without departing from the scope of this disclosure, may be subordinate to software, hardware, or both. -It can also be separated into components. Further, if applicable, software components can be implemented as hardware components and vice versa.

0041Software according to this disclosure, such as computer program code or computer program data, may be stored on one or more computer-readable media. It is also contemplated that the software specified herein may be implemented by using one or more networked and / or non-networked general purpose or purpose-built computers and / or computer systems. Will be done. Where applicable, to achieve the features described herein, the various steps described herein may be reordered, combined with compound steps, and / or in multiple substeps. Can be separated.

0042It should be understood that similar reference numerals are used to identify similar elements shown in one or more of the drawings. These labeled drawings are intended to illustrate embodiments of the present disclosure and are not intended to limit them.

0043The aforementioned disclosures are not intended to limit this disclosure to the exact form of disclosure or specific field of use. Accordingly, it is contemplated that various alternative embodiments and / or modifications to the disclosure may be available in light of the disclosure, whether they are express or implied herein. .. It will be appreciated by those skilled in the art that with the embodiments of the present disclosure described in this manner, changes can be made in form and details without departing from the scope of the disclosure. Therefore, the content of the present disclosure is limited only by the scope of claims.