Patent Application
20250036750
The present invention generally relates to digital security. More particularly, the present invention relates to technical improvements to prevent fraudulent use by cloning of a trusted application executable in a secure execution environment of a host device. Even more particularly, the present invention relates to a method, host device, trusted application and computerized backend resource for such prevention of fraudulent use.
Digital security is a collective term for the protection of functionality and data from unwarranted information disclosure, theft or damage. Digital security broadly relates to the protection of hardware, software and data. A host device, also known as a network host, is a hardware device being adapted to communicate with other hosts on a network. Host devices in a network may comprise clients and servers that send or receive data, services or applications.
In line with the rapidly expanding information technology development of the recent decades, software is consistently becoming more and more complex. It is not uncommon that software projects can comprise millions of lines of code. A downside of this is that every line of code could potentially be associated with a bug caused by, for instance, a programming error. Each bug is a potential attack vector for e.g. a person or script with malicious intent. Clearly, different bugs may expose different security vulnerabilities. Some bugs can easily be detected, while others are not so easily identified. Operating system kernel bugs are particularly crucial to manage, because if bugs are exploited in the kernel there is a risk of compromising the security of the entire system.
In order to securely execute protected functionality and data within the host device, the host device is thus commonly configured with a variety of different computerized security arrangements. Security arrangements may serve different purposes, wherein one purpose is to manage execution privileges of certain protected functionality and data. The protected functionality and data may be maintained in various physical or virtual locations of the security arrangement. Known security arrangements in the art typically involve hardware-based protection, software-based protection, or combinations, for providing a secure execution environment for the protected functionality and data.
Hardware-based protection involves partitioning a traditional kernel execution environment into two separate and respectively isolated execution environments, commonly referred to as a rich execution environment, REE, and a trusted execution environment, TEE. The TEE provides security features that isolate the integrity of applications executing within the TEE, along with confidentiality of their resources. Applications being executed in the TEE are therefore typically associated with a higher level of security compared to applications being executed in the REE. Hence, the applications being executed in the TEE are commonly being referred to as trusted applications. Although trusted applications are running in the TEE, they will still need to access protected functionality and data maintained by hardware resources. Accordingly, the requested hardware is typically supported by various hardware support which assures that the trusted applications can securely access the protected hardware resources.
Software-based protection involves providing a virtual execution environment within the software of the host device. The trusted applications are only allowed to be executed in the virtual execution environment. A virtual storage is provided within the virtual execution environment, wherein the trusted applications running in the virtual execution environment are configured to access protected functionality and data in the virtual storage.
Even if one of the security arrangements mentioned above are in place, the host device may still be prone to one or more security vulnerabilities.
Particularly, security vulnerabilities may be exposed when cloning is performed. Cloning is a technique wherein an additional identical instance of, for instance, the entire host device or the trusted application running therein, depending on the security arrangement, is created. The clone may escalate system privileges for a user by acting as the original trusted application or host device. Accordingly, cloning techniques aim to overcome computer system limitations being deliberately (or possibly unintentionally) placed there for security, administrative, marketing or other reasons. Escalating system privileges may be done with malicious intent, e.g. by a malicious user attempting to hack the host device, or with the intent of being able to fully access all of the functionality of the host device. As an example, Apple do not provide a “developer-mode” for operating systems in their devices, nor any other mechanism for selectively bypassing the established security model. Hence, in order for e.g. researchers to fully explore the device, they are forced to disassemble one or more security layers of the device. This is called jailbreaking. Other cloning techniques exist for other devices having other operating systems, for instance rooting of Android devices.
Cloning a host device may give rise to some critical security vulnerabilities relating to fraudulent use by cloning of a trusted application (either being cloned in isolation, or as a result of a cloning of the entire host device). For instance, one such security vulnerability is related to the double-spending problem. The double-spending problem may occur for a secure digital wallet being executed as a trusted application in a secure execution environment. If a clone of the trusted application is generated and continues to operate in an offline mode for which no instant online payment verification can be made, digital currency can be consumed from the secure digital wallet of the clone. If the currently executing trusted application is subsequently switched from the clone back to the original trusted application instance, while the secure digital wallet is still offline, the original trusted application instance may once more consume the same digital currency already consumed by the cloned instance. The same digital currency is thus consumed twice, i.e. double-spending. Clearly, triple-spending, or practically any multi-spending is also a possibility in the case wherein a plurality of trusted application instances are generated by cloning. Other related security vulnerabilities may be realized in other scenarios, for instance multi-usage of any finite resource, exploiting license timers for e.g. subscriptions or accounts or exploiting expiry timers, to name a few.
In line with the observations above, the present inventor has made valuable technical insights to solve or at least mitigate one or more of the problems or drawbacks identified in the background section.
A first inventive aspect is a method of preventing fraudulent use by cloning of a trusted application which is executable in a secure execution environment of a host device. According to this method, the trusted application starts in a locked mode in which access to protected functionality and data of the trusted application is prohibited. The trusted application performs a handshake procedure with a computerized backend resource to verify that a current execution state of the trusted application has not already been occupied by another instance of the trusted application. Only upon successful verification by the handshake procedure, the trusted application switches to an unlocked mode in which access to the protected functionality and data is permitted.
A second inventive aspect is a host device for preventing fraudulent use by cloning of a trusted application, the host device being configured for running the trusted application in a secure execution environment of the host device. The host device is configured to start the trusted application in a locked mode in which access to protected functionality and data of the trusted application is prohibited. The host device is further configured to perform a handshake procedure for the trusted application with a computerized backend resource to verify that a current execution state of the trusted application has not already been occupied by another instance of the trusted application. Moreover, the host device is configured, only upon successful verification by the handshake procedure, to switch the trusted application to an unlocked mode in which access to the protected functionality and data is permitted.
A third inventive aspect is a trusted application for preventing fraudulent use by cloning of the trusted application, the trusted application comprising computer program code being executable in a secure execution environment of a host device. The trusted application is configured to start in a locked mode in which access to protected functionality and data of the trusted application is prohibited, perform a handshake procedure with a computerized backend resource to verify that a current execution state of the trusted application has not already been occupied by another instance of the trusted application, and, only upon successful verification by the handshake procedure, switch to an unlocked mode in which access to the protected functionality and data is permitted.
A fourth inventive aspect is a computerized backend resource for preventing fraudulent use by cloning of a trusted application executable in a secure execution environment of a host device. The computerized backend resource is configured to participate in a handshake procedure with the trusted application starting in a locked mode in which access to protected functionality and data of the trusted application is prohibited. Participation in the handshake procedure seeks to verify that a current execution state of the trusted application has not already been occupied by another instance of the trusted application and to enable the trusted application, only upon successful verification by the handshake procedure, to switch to an unlocked mode in which access to the protected functionality and data is permitted.
These inventive aspects introduce functionality which can be seen as a logical lock feature: trusted applications are logically locked at start-up, until being unlocked through a successful handshake procedure with a trusted network resource (i.e. the computerized backend resource). The logical lock feature provides enhanced protection against fraudulent use by cloning of a trusted application which is executable in a secure execution environment, such as a hardware-based trusted execution environment or a software-based virtual execution environment. Hence, the logical lock feature can be seen as an add-on security level which provides further security to existing solutions for secure execution environments.
Other aspects, objectives, features and advantages of the inventive aspects will appear from the following detailed disclosure as well as from the claims and the drawings. Generally, all terms used herein are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein.
In this document, the terms “clone” and “copy” are used interchangeably when described together with a trusted application. An “instance” is in this setting referring to one instance of the trusted application. An instance may therefore be either one of the original trusted application or any one of the existing clones thereof. An instance, clone or copy of the trusted application is to be interpreted as an identical copy of the trusted application that can be executed in a similar way as the original trusted application, although not simultaneously. Clones, instances or copies of the trusted application may be generated as a result of e.g. rooting, jailbreaking, or other such mechanisms with the objective of escalating access privileges of a device (i.e. software or hardware thereof).
It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps, or components, but does not preclude the presence or addition of one or more other features, integers, steps, components, or groups thereof. All terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to “a/an/the [element, device, component, means, step, etc]” are to be interpreted openly as referring to at least one instance of the element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.
Expressions like “[entity] is configured for . . . [performing activity]” or “[entity] is configured to . . . [perform activity]” will include typical cases where a computerized entity (having one or more controllers, processing units, programmable circuitry, etc.) executes software or firmware installed in the computerized entity, wherein the execution occurs in order to perform the activity in question.
The foregoing will be apparent from the following more particular description of the example embodiments, as illustrated in the accompanying drawings. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the example embodiments.
Embodiments of the invention will now be described with reference to the accompanying drawings. The invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. The terminology used in the detailed description of the particular embodiments illustrated in the accompanying drawings is not intended to be limiting of the invention. In the drawings, like reference signs refer to like elements.
The following disclosure is related to fraudulent use by cloning. In view of the foregoing Background discussion and in light of the following disclosure, it is understood that not all types of cloning, per se, involve security risks, such as jailbreaking or rooting. Cloning of trusted applications is thus not necessarily indicative of fraudulent behaviour. It is only the fraudulent use by cloning, for instance a use relating to fraudulent switching between clones or fraudulent generation of a plurality of clones, of trusted applications that may involve security risks. The present disclosure is directed at prevention of such fraudulent use as accomplished by various cloning techniques.
With reference to
For reasons of brevity,
As seen in
The host device HD is a device that may be e.g. jailbroken or rooted such that instances thereof can be cloned. Jailbreaking or rooting, as was discussed in the background section of this document, may allow a user to take full or at least partial control of functionality and data protected by computer security layers of varying privilege levels, including software and/or hardware resources. Technical details of the host device HD will now be thoroughly provided for, with reference to the embodiments of
The host device HD shown in
The normal execution environment NEE is a non-secure world in the sense that one or more untrusted “normal” applications NA can be executed in a rich execution environment REE. The rich execution environment REE is adapted to run any type of embedded operating system or a general-use operating system, such as Android, iOS, Linux or Windows. Although not shown, it is implicit that the rich execution environment REE may access the normal applications NA through one or more application programming interfaces (APIs). The normal applications NA may thus be any type of web, native or hybrid applications being provided by an application service provider that is not trusted by the host device HD. The rich execution environment REE is adapted to access hardware resources (including firmware resources) 12 of the host device HD through, for instance, a hypervisor (not shown). Hardware resources 12 may include processing units, DRAMs, drivers, and so forth.
A normal application NA may be an application 16 requiring secure operating system support. This application 16 cannot be securely executed in the rich execution environment REE. For instance, the application 16 requiring secure OS support may be an application that comprises information that has to be protected against unwarranted disclosure, i.e. comprising data pertaining to e.g. monetary means, confidentiality information, or some other sensitive data. Alternatively, a computer program may require the execution of two different applications, one being a normal application NA and the other being an application 16 requiring secure OS support. An example of this may be a payment application service (normal application NA) being in communication with a secure digital wallet (application 16 requiring secure OS support). Execution of the application 16 requiring secure OS support involves separating it from the normal execution environment NEE and maintaining it in the secure execution environment SEE as a trusted application TA. The trusted application TA may be a secure digital wallet for a payment application service. One example of a digital payment system for such purposes will be described later with reference to
The secure execution environment SEE is a secure world in the sense that the trusted application TA can be executed in a trusted execution environment 14. The trusted execution environment 14 is adapted to access and execute protected functionality and data which are maintained by protected hardware resources 18, e.g. buses, peripherals, memory regions, interrupts, and so forth. The trusted execution environment 14 may be implemented in any trusted execution environment technology known in the art, including but not limited to Samsung TEEGRIS, Qualcomm TEE, Huawei iTrustee, Trustonic Kinibi, Google Open Source Trusty, Open Portable TEE, Nvidia's Trusted Little Kernel for Tegra, Sierra TEE, ProvenCore TEE, Trusty TEE for Android, or TrustKernel T6. The protected hardware resources 18 may be protected by any hardware support technologies known in the art, including but not limited to Arm's TrustZone, MultiZone Security, AMD Platform Security Processor, Intel Software Guard Extensions, Apple's Secure Enclave Processor, or Google's Titan M.
As further seen in
An execution state of an application is, as such, a concept known to the person skilled in the art. The skilled person knows that computerized execution is the process of, by for instance a computer or virtual machine, reading and acting on instructions of a computer program. In this case the computer program is the trusted application TA. Each instruction (or statement, expression, etc.) of the trusted application TA is an action being carried out by the computer in order to solve a task, and a control unit of the computer sequentially performs cycles of fetching, decoding and executing said instructions. The execution state thus dynamically changes as the program runs. To this end, the trusted application TA will transition between states for each step during these sequentially performed cycles. During the time in which a handshake procedure is carried out (as will be thoroughly explained later on in this disclosure), it is thus realized that current execution states of the trusted application TA are verified, which means that it is determined whether access to the protected functionality and data of the protected hardware resources is permitted.
In view of the above explanation of the (current) execution state, it is also realized that different execution states may be temporally compared to one another for determining statuses, i.e., which execution state is the current execution state, of the trusted application TA. Such temporal comparisons may identify older execution states, i.e., previous execution states of the trusted application TA that were active at some point in time in the past. When comparing an older execution state to a current execution state, the older state may thus be used as a reference point to analyze how the program has changed over time. In this case, that would correspond to determining whether a current execution state of the trusted application TA has not already been occupied by another instance of the trusted application TA that has been executed in the place of the original instance. Further details of the verification procedure will be described later on with reference to
Communication between the host device HD and the backend resource BE may be via a cloud network (such as, for instance, WAN network 510 in
The backend resource BE may be maintained as a cloud-based server implemented using any commonly known cloud-computing platform technologies, such as e.g. Amazon Web Services, Google Cloud Platform, Microsoft Azure, DigitalOcean, Oracle Cloud Infrastructure, IBM Bluemix or Alibaba Cloud. The cloud-based server may be included in a distributed cloud network that is widely and publically available, or alternatively limited to an enterprise. Alternatively, the server may in some embodiments be locally managed as e.g. a centralized server unit.
Other alternative server configurations may be realized, based on any type of client-server or peer-to-peer (P2P) architecture. Server configurations may thus involve any combination of e.g. web servers, database servers, email servers, web proxy servers, DNS servers, FTP servers, file servers, DHCP servers, to name a few.
An example of the operation of a mobile payment application will now be described. The mobile payment application is a normal application NA. In order to perform a payment operation, the normal application NA is running together with an application 16 that requires secure OS support, for instance a secure digital wallet. A mechanism for communication between the normal execution environment NEE and the secure execution environment SEE is therefore solicited by the host device HD. Accordingly, the normal application NA goes through a process to load and communicate with the trusted application TA corresponding to the secure digital wallet. The trusted application TA is located within the secure execution environment SEE and communication thereto can be established through specific communication channels and APIs available to both the normal execution environment NEE and the secure execution environment SEE. Moreover, interface(s) is/are also provided in order to perform the access verification procedure with the computerized backend resource BE, for instance the Internet.
These communication channels and APIs are indicated by the arrows in
Critical privilege escalation attacks may thus be introduced to the host device HD via one or more of the Man-in-the-Middle layers. Data being sent within, from or to the host device HD has to be verified. However, the execution of a verification procedure has to be performed in a safe way. Performing an execution verification procedure involves introducing a plurality of additional attack vectors, including at least an access request signal and an access response signal. If one or more clones of the trusted application TA are generated, it is possible to accomplish fraudulent use by manipulating one or more of the request or response signals associated with any of the clones and/or by switching between clone instances.
To summarize, communication to, from and within the host device HD can be targeted by Man-in-the-Middle MM attacks. Using the implementation shown in
The host device HD shown in
The normal execution environment NEE is a non-secure world in the sense that one or more untrusted “normal” applications NA can be executed in a rich execution environment REE. The rich execution environment REE is adapted to run any type of embedded operating system or a general-use operating system, such as Android, iOS, Linux or Windows. Although not shown, it is realized that the rich execution environment REE may access the normal applications NA through one or more application programming interfaces (APIs). The normal applications NA may thus be any type of web, native or hybrid application being provided by an application service provider that is not trusted by the host device HD. The rich execution environment REE is adapted to access hardware resources (including firmware resources) 12 of the host device HD, for instance through a hypervisor (not shown). Hardware resources 12 may include processing units, DRAMs, drivers, and so forth.
The secure execution environment SEE is a secure world in the sense that the trusted application TA can be executed in a secured virtual execution environment 24. The trusted application TA is thus protected by software. The virtual execution environment 24 is adapted to access and execute protected functionality and data which is maintained in an encrypted virtual storage 25. Any suitable virtual execution environment technologies known in the art may be implemented. For instance, the virtual execution environment 24 may be implemented generally according to subject-matter disclosed in the European patent EP 2 795 829 B1. The referenced patent discloses a mapping between each trusted application TA and a combination of an application domain name and a device identifier being represented as a unique fingerprint. If the trusted application TA is cloned into another device, or the application domain name is being changed for some reason, the virtual execution environment 24 will not allow execution thereof. Accordingly, computer systems implementing a software-based virtual execution environment 24, at least according to the referenced patent application, restrict cloning of hardware resources. However, protection cannot be guaranteed for clones of the trusted application TA in the same host device HD that uses the same application domain name. It is therefore possible to generate one or more clones of the trusted application TA in the same host device HD and switch between the clones to accomplish fraudulent use of the clones.
As further seen in
Similar to the subject-matter discussed with reference to
To summarize, clones of the trusted application TA can be generated by software-based cloning.
It was described with reference to
A handshake procedure is, as such, well known to the person skilled in the art. The skilled person understands that the term handshake procedure inherently implies technical implications involving a series of steps for establishing a connection between parties. In this case, the parties are represented by the trusted application TA and the computerized backend resource BE. A conventional handshake procedure sometimes, involves authentication, exchange of keys, and negotiated parameters to be used for encryption or decryption of data transmitted between said parties, thereby assisting in ensuring that the communication between the parties is secure, private and protected from unauthorized access and/or tampering. In the following example with reference to
It is recalled that if the security of the host device HD has been jeopardized by activities such as jailbreaking or rooting, the trusted application TA may have been cloned for malicious purposes. To prevent fraudulent use by such cloning activities, after having started at 310, the trusted application TA performs a handshake procedure 320 with the computerized backend resource BE to verify that a current execution state of the trusted application TA has not already been occupied by another instance of the trusted application TA. Only upon successful verification by the handshake procedure 320 will the trusted application TA switch 330 to an unlocked mode. In the unlocked mode, access to the protected functionality and data is permitted, as can be seen at 332. Hence, the method made up of steps 310, 320 and 330 introduces novel and inventive functionality which can be seen as a logical lock feature—trusted applications are logically locked at start-up, until being unlocked through a successful handshake procedure with a trusted network resource (i.e. the computerized backend resource BE).
From a host device perspective,
From a trusted application perspective,
Finally, from a backend perspective,
In some embodiments of the aforementioned method, host device, trusted application and computerized backend resource, the computerized backend resource BE maintains a record BE_rec (seen at 304 in
In some embodiments, the trusted application TA maintains a representation of its execution state. The representation is a monotonic function of execution progress, and the trusted application TA will report the current execution state to the computerized backend resource BE during the handshake procedure 320 by communicating a current value of this representation. The record BE_rec as maintained by the computerized backend resource BE will contain a corresponding value of the aforesaid representation at the most recently reported execution state of the trusted application TA. Representing execution states as a monotonic function of execution progress will in effect mean that a current execution state will be “younger” or “newer” than an execution state that has occurred previously during the execution progress of the trusted application TA.
Advantageously, the representation of execution state as maintained by the trusted application TA comprises a trusted application counter value wallet_counter being incremented during the handshake procedure 320. The record BE_rec as maintained by the computerized backend resource BE will then comprise a corresponding backend counter value wallet_instance_counter for the trusted application TA. A particularly refined example of such a counter mechanism will now be described with reference to
Hence, in
A prerequisite of the handshake procedure 400 is that the trusted application TA is starting in a locked mode in which access to the protected functionality and data is prohibited. This is the case for the original trusted application TA as well as any additional number of trusted application instances possibly being generated as a result of cloning.
The term “starting” is referring to a state between a terminated mode and an executing mode. The trusted application TA may be starting for a variety of reasons, for instance during reboot of the associated host device, when the trusted application TA is awaken from an idle mode, when the trusted application TA has crashed and is restarting, and so forth.
The objective of the handshake procedure 400 is to verify that a current execution state of the trusted application TA has not already been occupied by another instance of the trusted application TA. Only upon successful verification as reported by the handshake procedure 400, the trusted application TA is allowed to switch to an unlocked mode in which access to the protected functionality and data is permitted. The present inventor has realized three important aspects that have been taken into consideration in the following implementation of the handshake procedure 400.
First, it has been realized that inherent behavior of the secure execution environment (cf. the aforementioned trusted application fingerprints) does not allow more than one instance of the trusted application TA to be executed at a particular point in time. It can therefore be established that each step in the handshake procedure 400 can only be performed by one instance of the trusted application TA at a time. Analogously, even if an arbitrary number of trusted application instances are generated, the operating system would only allow a single instance to be verified as a response to successful verification by the handshake procedure 400. This implies that if some additional trusted application instance, or even the original trusted application TA, attempts to be verified by means of the handshake procedure 400, it can be identified that fraudulent use by cloning has occurred and action can thus be taken. Moreover, the problems discussed in the background section, for instance the double-spending problem, are addressed since the handshake procedure 400 will not allow multiple verified instances of the trusted application TA.
Secondly, it has been realized that upon a clone of the trusted application TA being generated, it always restarts. Hence, upon executing the trusted application TA as a new instance, it has just been restarted. This behavior is utilized in order to verify that the current execution state of the trusted application TA has not already been occupied by another instance thereof upon startup of the trusted application TA or an execution switch thereto, or any trusted application instance, the handshake procedure 400 is therefore triggered.
Thirdly, it has been realized that care needs to be taken in view of potential Man-in-the-Middle MM attacks that can manipulate requests or responses associated with the handshake procedure 400. Manipulation can involve, for instance, intercepting and injecting scripts or removing code from the data, blocking message transmission, performing one or more retransmissions of any of the messages being sent, or any other type of Man-in-the-Middle MM exploit.
At least the insights discussed above enable the following implementation of the handshake procedure 400. The computerized backend resource BE is, for brevity reasons, hereinafter simply being referred to as “backend”. In light of the insights as discussed above, it is understood that each additional cloned instance of the trusted application TA will, when it is restarting (i.e. as caused by its generation), have the exact same handshake data as the trusted application instance used as a source of the cloning. Moreover, it is understood that each act performed by the trusted application TA is performed in the same way for any of the trusted application instances that is currently being executed.
As seen at initial steps 402, 404 of the handshake procedure 400, respective handshake data are set and maintained for the trusted application TA at 402, and for the backend BE at 404. For the trusted application TA, the handshake data may be part of the protected functionality and data thereof. Observe that the handshake data is typically only generated one time for the trusted application TA in preparation for the handshake procedure 400. Upon a trusted application clone being created, the handshake data of said trusted application clone will correspond to the handshake data of the source from which the clone was generated.
Switches between already generated trusted application instances will not reset the handshake data as defined at 402 and 404. Accordingly, the step 402 is only performed once for the original trusted application TA, and the step 404 is only performed once for the backend BE.
In one embodiment, the handshake data of the trusted application TA comprises a trusted application counter value wallet_counter. The trusted application counter value wallet_counter is set to an arbitrary starting value, for instance 0. Moreover, the handshake data of the backend BE comprises a backend counter value wallet_instance_counter for the trusted application TA. The backend counter value wallet_instance_counter is set to be equal or less than the trusted application counter value wallet_counter. As this procedure is done for each trusted application instance, the backend BE is configured to maintain a record BE_rec (also seen at 304 in
In some embodiments, the handshake data comprises additional data. Additional data may include a unique identifier wallet_instance_id of the trusted application TA (cf. the aforementioned trusted application fingerprint). The unique identifier wallet_instance_id may be mapped to a corresponding identifier wallet_instance_context maintained by the backend BE. Alternatively or additionally, the additional data may comprise a respective private cryptographic key priv_key_wallet, priv_key_backend for the trusted application TA and the backend BE. The private cryptographic key priv_key_wallet of the trusted application TA may be used for signing data of handshake requests sent from the trusted application TA, for instance the trusted application counter value wallet_counter and the unique identifier wallet_instance_id. The private cryptographic key priv_key_backend of the backend BE may be used for signing data of handshake responses sent from the backend BE, for instance the backend counter value wallet_instance_counter and the unique identifier wallet_instance_id. The additional data may further comprise a root certificate cert_root issued by a root certificate authority, as well as a wallet certificate cert_wallet for containing a public encryption key corresponding to the private cryptographic key priv_key_wallet of the trusted application TA. The authenticity of the wallet certificate cert_wallet can be verified by the root certificate cert_root. The additional data may moreover comprise a backend certificate cert_backend for containing a public encryption key corresponding to the private cryptographic key priv_key_backend of the backend BE. The authenticity of the backend certificate cert_backend can be verified by the root certificate cert_root.
All of the additional data stored in the backend BE may be maintained in the record BE_rec. Accordingly, the backend BE is configured to map handshake data for each one of the trusted application instances.
As seen at step 406, the trusted application TA is configured to be started in a locked mode. For instance, the trusted application TA may store an access mode identifier being set to a logic FALSE during startup.
The handshake procedure 400 involves performing a first handshake HS1. At 408, the first handshake HS1 involves a first handshake request HS1_Req. The first handshake request HS1_Req comprises the trusted application counter value wallet_counter. Moreover, the first handshake request HS1_Req comprises the unique identifier wallet_instance_id and a one-time arbitrary number, for instance a cryptographic nonce nonce1. All of the data included in the first handshake request HS1_Req is signed using the private key priv_key_wallet of the trusted application TA.
At 410, the backend BE first verifies the signature of the trusted application TA using the wallet certificate cert_wallet (preferably after having verified the wallet certificate cert_wallet using the root certificate cert_root). If the signature is successfully verified, the backend BE then checks that the trusted application counter value wallet_counter is greater than or equal to the backend counter value wallet_instance_counter. If this is true, the backend counter value wallet_instance_counter is set to be equal to the trusted application counter value wallet_counter and the first handshake request HS1_Req is confirmed at 412 by setting a status indicator status to an affirmative value, such as TRUE or OK.
Observe that it is a deliberate design choice to not only confirm the first handshake request HS1_Req upon the trusted application counter value wallet_counter being greater than the backend counter value wallet_instance_counter, but also equal thereto. This relates to the design choice for the backend counter value wallet_instance_counter as discussed at 404. The consequence of also confirming the first handshake request HS1_Req upon the counters being equal is that retransmission of the first handshake request HS1_Req is possible. The skilled person knows that access request and response messages may be lost for a variety of reasons, e.g. due to timeouts, network issues, incorrect package sizes, and so forth. This particular design choice therefore makes it possible for the trusted application TA to retransmit the messages in case of said messages being dropped, while at the same time preventing another trusted application instance from unlocking.
Once having passed the check at 410, the first handshake HS1 further involves sending a first handshake response HS1_Resp at 412 to the trusted application TA. The first handshake response HS1_Resp is a message to the trusted application TA, i.e., a confirmation that the first handshake request HS1_Req has validly passed. It is recalled that in data networking, a passed handshake response corresponds to an acknowledgement (ACK) and an erroneous handshake response corresponds to a negative acknowledgement (NACK). The data of the first handshake response HS1_Resp is signed with the private key priv_key_backend of the backend BE.
Upon receiving the first handshake response HS1_Resp 412 (i.e. the confirmation) at 414, the trusted application TA first verifies the signature of the backend BE using the backend certificate cert_backend (preferably after having verified the backend certificate cert_backend using the root certificate cert_root). Moreover, it is confirmed that the value of status is affirmative, as was discussed above. If the signature is successfully verified, the trusted application TA then increments the trusted application counter value wallet_counter, in this example by one. Other granularities can of course be realized. It is important that the trusted application counter value wallet_counter is not incremented until the response 412 is received. If the trusted application counter value wallet_counter would instead be incremented at some other time, for instance upon sending the first handshake request HS1_Req, sophisticated switching between trusted application instances could potentially cause more than one trusted application instance to be verified, i.e. accomplishing unwanted behavior. If step 414 executes, the first handshake HS1 is completed successfully.
The handshake procedure 400 further involves performing a second handshake HS2. The steps 416, 420 and 422 of the second handshake HS2 are similar to the corresponding steps 408, 412, 414 of the first handshake HS1. However, one important difference between the first and second handshakes HS1, HS2 can be seen in step 418. In order to confirm a second handshake request HS2_Req sent from the trusted application TA to the backend BE, the trusted application counter value wallet_counter must be strictly greater than the backend counter value wallet_instance_counter. The second handshake request HS2_Req thus cannot be confirmed if it is established that the currently executing trusted application instance is older than a most recent execution state of the trusted application TA according to the record BE_rec maintained by the backend BE.
The handshake procedure 400 further involves performing a third handshake HS3. The steps 424, 426, 428 and 430 of the third handshake HS3 are identical to the corresponding steps 416, 418, 420 and 422 of the second handshake HS2, with the only exception that the data comprises different values. In the present implementation, the third handshake HS3 effectively prevents fraudulent use by cloning mid-way in the handshake procedure 400.
Some implementations or device infrastructures comprise rules that only allow cloning before the handshake procedure 400 is initiated. For such implementations or infrastructures, the third handshake HS3 may not be necessary. The third handshake HS3 effectively prevents fraudulent use of clones being created somewhere during the execution of the handshake procedure 400.
Upon incrementing the trusted application counter value wallet_counter at 430, the handshake procedure 400 further involves a final step 432 of unlocking the trusted application TA. At this time, it is certain that only one trusted application instance, be it the original trusted application TA or be it any clone thereof, has been successfully verified. In this embodiment, successful verification by the handshake procedure 400 thus requires completion of the first, second and third handshakes HS1, HS2, HS3. The access mode identifier may be set to a logic TRUE value, thereby switching the trusted application TA to an unlocked mode in which access to the protected functionality and data is permitted. Hence, when the trusted application TA has been unlocked at 432, a completion of the handshake procedure 400 has been achieved. As is also evident given the foregoing disclosure, the handshake procedure 400 would also be completed upon reaching step 414, 422 or 430, but said steps 414, 422 or 430 would not execute. In this case, however, the handshake would be completed in an unsuccessful manner. A reason for this could, for example, be that the signature would not match, the status would not be “Ok”, and/or the wallet counter would not match an expected wallet counter value caused by e.g., fraudulent use by cloning of the trusted application TA.
In one embodiment, the second and third handshakes HS2, HS3 may be associated with response or request timeout periods. For instance, the trusted application TA may require that, after having sent a handshake request HS2_Req, HS3_Req, a corresponding response HS2_Resp, HS3_Resp is solicited within a certain time period. If a response is not received within said certain time period, it may be an indication of fraudulent behavior. Alternatively, it may be an indication of a temporary transmission problem in the communication between the trusted application TA and the backend BE, as mentioned above for step 410. To this end, in embodiments of the invention, when performing the second or the third handshake HS2, HS3, the trusted application TA is configured for detecting the lapse of said certain timeout period between the reporting of the trusted application counter value wallet_counter to the backend BE (step 416 or 424) and the receiving of the confirmation from the backend BE (step 420 or 428). Upon detecting such a timeout, the trusted application TA may be configured for aborting the handshake procedure 400, or reverting to the first handshake HS1 of the handshake procedure 400.
Throughout the entire handshake procedure 400, either one of the trusted application TA or the backend BE may report unexpected requests or responses. An unexpected request or response may be an unsuccessful verification of a trusted application instance. Unexpected requests or responses may be an indication that fraudulent behavior is occurring. For instance, if some data of the requests or responses is not corresponding to a particular value that is expected, fraudulent behavior might be the cause. This may be the case when one or more instances of the trusted application TA has been generated and execution status is continuously switched therebetween. Alternatively, if one or more additional requests or responses are received somewhere in the flow which should not be received at that particular time, this may indicate that the Man-in-the-Middle MM has intercepted the message and potentially attempting to exploit the system. Other such scenarios will be understood by the skilled person. The reports as discussed above may, for instance, be reported to a master user. A master user may be an application provider service of the trusted application TA.
Note that the handshake procedure 400 of the flow diagram being described with reference to
It has been discussed that the subject-matter of this document aims to prevent fraudulent use of cloning of a trusted application TA, wherein clones can be generated at any time during a lifetime of the trusted application TA. This will now be shown in three different examples of handshake procedures. The following examples are derived directly from the handshake procedure 400 according to
A first example is shown in Table 1. Table 1 represents a basic procedure wherein no trusted application clone is generated throughout the handshake procedure. Accordingly, the counter value associated with the (non-existing) trusted application clone remains undefined (“undef”). Following Table 1, first execution steps 402, 404 are to set the handshake data. Herein the counters of the original trusted application and the backend, respectively, are set to an arbitrary value, in this example 0, and the access mode is set to locked. Following the execution steps 414, 422, 430, it is seen that the trusted application counter value is progressively being incremented by one at each execution step. Moreover, following the execution steps 410, 418, 426, it is seen that the backend counter value assumes the current value of the trusted application counter value at the corresponding execution steps. At step 432, the handshake procedure for the trusted application TA is verified. Hence, the access mode is switched to unlocked, thereby allowing access to the protected functionality and data of the trusted application TA.
A second example is shown in Table 2. In this example, a trusted application clone is created one time and an execution switch thereto occurs at the same time, as indicated by “GEN/SW” in the “current execution” column. When the cloned trusted application instance is generated, the counter value of the clone is assuming the same handshake data as the original trusted application instance, in this example counter value=1 and access mode=locked. Since no additional switches occur during the handshake procedure, the clone will continue to execute generally according to the first example shown in Table 1 albeit for the clone instead of the original trusted application. The clone is ultimately being unlocked and thus given access to the protected functionality and data of the trusted application TA.
A third example is shown in Table 3. In this example, a cloned trusted application instance is generated and a switch thereto is performed, as indicated by “GEN/SW”. After the first handshake performed by the clone, i.e. at step 414, another switch “SW” is performed such that the currently executing trusted application instance is once again the original instance. Since the counter value of the original trusted application instance is 1, and the backend counter value is still 1, the original trusted application instance can continue to execute through the steps 410, 414, 418, 422, 426 and 430. Now, an additional switch “SW” is performed such that the currently executing trusted application instance is once more the clone, as seen in the table. The counter value of the clone is, however, still 2, since no further handshakes have been performed for the clone but only for the original trusted application instance. Accordingly, at the subsequent execution step 410 for the clone, the backend BE notes that the check is unsuccessful due to the clone counter value=2 being less than the backend counter value=3 for the most recent execution state of the trusted application, i.e. the original instance. The handshake procedure is thus aborted, and unsuccessful verification of the trusted application instance may be reported, for instance to an application provider service or, in the case of
In the examples presented in Tables 1-3 above, as well as for other alternative handshake procedures, the original trusted application instance and the cloned trusted application instance maintain a representation of its execution state in the form of the counters. The representation is a monotonic function of execution progress, wherein the current execution state is reported to the backend BE during the handshake procedure. The reporting of current execution state corresponds to the point in time wherein the handshake requests are received by the backend BE and the backend counter value is assuming the value of the currently executing trusted application instance. The backend BE thereby maintains a record BE_rec of most recently reported execution state for each one of the trusted application instances.
Other examples of clone generation and/or switching than the ones presented in Tables 1-3 can be derived from
The mobile communication device 520 has an interface WAN I/F for wide area network data communication via a wide area network 510, as well as an interface S-R I/F for short-range wireless data communication. Moreover, the mobile communication device 520 has a processing device Cr that serves as a controller of the mobile communication device 520 and that may be implemented in any known controller technology, including but not limited to microcontroller, processor (e.g. PLC, CPU, DSP), FPGA, ASIC or any other suitable digital and/or analog circuitry capable of performing the intended functionality. The mobile communication device 520 further has a memory Mem that may be implemented in any known memory technology, including but not limited to ROM, RAM, SRAM, DRAM, CMOS, FLASH, DDR, SDRAM, SSD or magnetic hard disk, or some other memory technology. In some embodiments, the memory or parts thereof may be integrated with or internal to the processing device Ctrl. The memory Mem may store program instruction for execution by the processing device Ctrl, as well as temporary and permanent data for use by the processing device Ctrl.
The mobile communication device 520 has a user interface UI, as is commonplace in the art. The user interface UI comprise an input device and a presentation device. The input device and the presentation device may be constituted by one common physical device, such as for instance a touch screen (touch-sensitive display screen), implemented in for instance resistive touch technology, surface capacitive technology, projected capacitive technology, surface acoustic wave technology or infrared technology.
As has been explained above, the mobile communication device 520 is configured for enabling the payer P1 to make digital payments by any or all of the available communication channels, i.e. using any or all of the wide area network data communication (cf. interface WAN I/F) and short-range wireless data communication (cf. interface S-R I/F).
The short-range data communication interface S-R I/F may be configured for Bluetooth communication, or any other radio-based short-range wireless data communication such as, for instance, Bluetooth Low Energy, RFID, WLAN, WiFi, mesh communication or LTE Direct, without limitation, or any non-radio-based short-range wireless data communication such as, for instance, magnetic/inductive communication (such as NFC), (ultra)sound communication, or optical communication (such as IrDA) without limitation. In some embodiments, the short-range data communication interface S-R I/F comprises equipment and functionality for presenting and/or scanning a QR code.
The wide area network communication interface WAN I/F may be configured for wide area network communication compliant with, for instance, one or more of W-CDMA, GSM, UTRAN, HSPA, LTE, LTE Advanced or 5G, and TCP/IP, and/or WLAN (WiFi), without limitation.
To support digital payments, the mobile communication device 520 has a secure digital wallet OW, implemented as a trusted application TA executable in a secure execution environment, SEE, as described above. The mobile communication device 520 will typically also have a payment application executing as a normal application NA (cf. the preceding description with reference to
Through the payment application, the payer P1 can make digital payments from the secure digital wallet OW as online payments 570 by communicating with other entities like a point-of sales, POS, terminal 530, another mobile communication device, MCD, 540, or directly with a payment service provider PSP that provides a payment application service. Such digital payment are online in the sense that the performance thereof will involve instant communication with cloud-based resources like the payment service provider PSP, bank services BS1 . . . BSn, etc., for payment verification, clearing and settlement.
The payer P1 can furthermore make digital payments from the secure digital wallet OW as offline payments 580 by short-range wireless communication with another nearby device (exemplified as a point-of-sales terminal 550) when being in physical proximity 560. Unlike the online digital payments 570, the offline digital payment 580 does not require momentary access to any of the cloud-based resources PSP, BS1 . . . BSn at the time of making the offline digital payment. The offline digital payment may be buffered at the POS 550 (and/or the mobile communication device 520) and subsequently communicated to the cloud-based resources PSP, BS1 . . . BSn when communication over the WAN 510 is available. This is indicated by a broken line between the POS 550 and WAN 510 in
Every offline digital payment of the payer P1 (as well as every online digital payment unless being made by directly charging an account of the payer P1 held at any of the cloud-based resources PSP, BS1 . . . BSn) will be made against a local balance balance_dw of the secure digital wallet/trusted application TA in the mobile communication device 520. Hence, the local balance balance_dw is an example of protected data of the trusted application TA.
Typically, the local balance balance_dw will be reduced by an amount identical to or at least corresponding to the payment amount of the digital payment made. When the local balance balance_dw has been consumed, the payer P1 may make a replenishment by requesting a top-up of the secure digital wallet at the cloud-based resources PSP, BS1 . . . BSn. Examples of protected functionality of the trusted application TA are, hence, the procedures for reducing the local balance balance_dw at offline digital payment and for topping-up the secure digital wallet.
However, and needless to say, if clones of the secure digital wallet/trusted application TA were allowed to execute in the mobile communication device 520, there could be highly undesired situations of double-spending. This is particularly so for offline digital payments 580, since there is no online payment verification being made at the time of offline payment. The present invention presents advantageous fraud-prevention measures in this regard.
Some non-limiting examples of suitable technology for digital payments are described in the present applicant's PCT applications PCT/SE2020/051251, PCT/SE2021/050556, PCT/SE2022/050090 and PCT/SE2022/050152, as well as Swedish applications SE 2151401-3 and SE 2250076-3.
The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2250289-2 | Mar 2022 | SE | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2023/050188 | 3/2/2023 | WO |
