Patent Description:
Protecting users and their network devices from security breaches is an ever-present concern with computer systems. As computer system complexity and user reliance thereon increases, so to do the opportunities for security breaches and the risks associated therewith increase.

In the related art, encryption has been used to address some of these concerns. However, encryption as such presents a number of drawbacks. For example, encrypting data presents an overhead both when the data is encrypted, and anytime the data is used (as it must be decrypted) and modified (as the modified data must be re-encrypted). Moreover, encryption fails to protect sensitive data adequately in various circumstances. For example, encryption of data does not prevent spying when the computer system itself is compromised (e.g., compromised through a lack of data isolation). Thus, an application executing on user equipment (UE) can "eavesdrop" on information utilized by other applications. For instance, when one application decrypts data on the UE, other applications executing on the UE may copy or otherwise utilize the decrypted data. Additionally, even if you can guarantee the safety of your computer system, communicating with a third-party system leaves the data vulnerable to breaches in the third-party system.

Accordingly, there is a need for improved systems and methods for ensuring secure communication between remote devices. More specifically, a need exists for providing security that extends beyond encryption, and ensures communication endpoints are operating in a secure environment. Aspects of the present disclosure are related to these and other concerns.

<CIT> discloses a client system, such as a computer or a smartphone, which securely exchanges sensitive information with a remote service provider computer system such as a bank or an online retailer. The client system executes a commercially available operating system in an untrusted virtual machine (VM), which may be affected by malware. A hypervisor is configured to launch a trusted, malware-free VM from an authenticated image stored on computer-readable media used by the untrusted VM. The trusted VM executes a thin operating system with minimal functionality, to manage a secure communication channel with the remote server system, wherein sensitive communication is encrypted. Data from the trusted VM is forwarded via the hypervisor to a network interface driver of the untrusted VM for transmission to the remote service provider. The service provider may perform a remote attestation of the client system to determine whether it operates a trusted VM.

As discussed above, there is a persistent concern about securing sensitive information, especially when communicating with a remote device. The related art attempts to address these concerns with encrypted data and channels. However, as mentioned, encryption does not protect against eavesdropping or ensure that a third-party device is utilizing a secure operating environment.

Therefore, it is desirable to have an improved mechanism for providing device security and a secure connection. In some examples of the present disclosure, when secure communication is desired, a first device instantiates an isolated virtual machine (VM) instance, executes an application for communication in the VM instance, and attests to this arrangement to an attesting server. Then, before the first device connects with a second device, the first device requests from the attestation server whether the second device is likewise validly operating with the VM. If the server attests that the second device is validly operating, the first device will connect to the second device and communicate therewith. Once the communication is complete, the first device can close the application and delete the VM instance.

In some examples, a secure root certificate is used to guarantee the attestation. In some cases, upon closing of the communication, the user may be presented options for persisting information related to the communication. As a non-limiting example, a user may desire to save an image received by the application executed on the VM. When the connection is closed, the user may instruct the VM instance to persist the image in a cloud storage program, which may be accessed by the user after the VM instance is deleted.

Although aspects of the present disclosure are generally discussed with reference to UEs and service providers, these are merely examples. One of ordinary skill in the art will recognize that aspects of the present disclosure may be applied to various fields and challenges. As a non-limiting example, an unmanned aerial vehicle (UAV) and a monitoring station may communicate with video capture and streaming programs, respectively. Before establishing a connection, the UAV may require the monitoring station to execute the streaming program within a VM. Once the VM use is attested to, the UAV may provide its video stream to the monitoring station.

Reference will now be made in detail to aspects of the disclosed technology, examples of which are illustrated in the accompanying drawings and disclosed herein. Wherever convenient, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

As shown in <FIG>, an example of the present disclosure can comprise a system environment <NUM> in which endpoint connection and communication in accordance with some examples of the present disclosure may be performed. The components and arrangements shown in <FIG> are not intended to limit the disclosed embodiments as these components and features may vary. In <FIG>, the system environment <NUM> can include one or more Attestation Nodes 110A-<NUM>, one or more Providers 120A-120n, and one or more UEs 130A-130o. In some examples, Attestation Node <NUM>, Provider <NUM>, and UE <NUM> may communicate with one another. Additionally, one or more of Attestation Nodes 110A-<NUM><NUM><NUM>, one or more of Providers 120A-120n, and one or more of UEs 130A-130o may communicate with each other (e.g., UE 130A may communicate with UE 130B). Attestation Nodes 110A-<NUM>, the one or more Providers 120A-120n, and the one or more UEs 130A-130o may each include one or more processors, memories, root certificates, and/or transceivers. As non-limiting examples, the one or more UEs 130A-130o may be cell phones, smartphones, laptop computers, tablets, or other personal computing devices that include the ability to communicate on one or more different types of networks. Attestation Nodes 110A-<NUM> and/or the one or more Providers 120A-120n may include one or more physical or logical devices (e.g., servers, cloud servers, access points, etc.) or drives. Example computer architectures that may be used to implement UEs 130A-130o, Attestation Nodes 110A-<NUM>, and Providers 120A-120n are described below with reference to <FIG> and <FIG>.

When UE <NUM> and/or Provider <NUM> desire to communicate (e.g., by receiving an indication to launch an application or a communication request), a security process (e.g., executed by a hypervisor) may instantiate a VM instance and execute the application on the VM instance. UE <NUM> and/or Provider <NUM> create a certificate (e.g., a root certificate) for the VM instance and transmit the attestation to an attestation server <NUM>. Before UE <NUM> and/or Provider <NUM> connects with another device, it will request attestation of the other device from the Attestation Node <NUM>. If the other device is deemed to be executing within a secure VM environment, UE <NUM> and/or Provider <NUM> connects to the other device.

Attestation Nodes 110A-<NUM> may serve as an authority for secure operation. In some cases, Attestation Nodes 110A-<NUM> may be nodes of a private blockchain that stores attestations of the use of the VM environment by UE <NUM> and Provider <NUM>. The attestations may be received from UE <NUM> and Provider <NUM>. The attestations may be root attestations corresponding to a hardware root certificate of UE <NUM> and/or Provider <NUM>. When Attestation Node <NUM> receives a request for attestation information of a particular device, it refers to the previously received attestations to determine whether the particular device is validly executing in a virtual instance. Attestation Nodes 110A-<NUM> may be maintained by respective known/trusted entities. For example, in some embodiments, a plurality of cellular providers (who also maintain Providers 120A-120n) may each maintain one or more of Attestation Nodes 110A-<NUM>.

In some examples, Providers 120A-n provide one or more services to UE <NUM> and can communicate with one or more of Attestation Nodes 110A-<NUM>. Providers 120A-n may also communicate with UE <NUM>. For example, Providers 120A-n may serve as application servers corresponding to different applications (e.g., banking, mapping, web search, messaging, etc.). Providers 120A-n may attest to their execution of VMs to one or more of Attestation Nodes 110A-<NUM>. Provider <NUM> may utilize a hardware root certificate to generate an attestation of a VM instance running thereon, for example, when the VM is instantiated or when the application executes. Providers <NUM> may attest to one or more of Attestation Nodes 110A-<NUM> that Provider <NUM> is communicating within a secure VM instance.

When a first provider (e.g., Provider 120A) is to interact with a second provider (e.g., Provider 120B), the first provider will check with one or more of Attestation Nodes 110A-<NUM> to determine whether the second provider has attested to its execution within a VM instance. Likewise, the second provider will check with one or more of Attestation Nodes 110A-<NUM> to determine whether the first provider has attested to its execution within a VM instance. If both the first and second providers have attested accordingly to Attestation Nodes 110A-<NUM>, the first and second providers will connect to each other.

UE <NUM> may communicate with the at least one Attestation Node <NUM> and at least one Provider <NUM>. UE <NUM> may attest to its execution of VMs to one or more of Attestation Nodes <NUM>10A-<NUM><NUM>. UE <NUM> may utilize a hardware root certificate to generate an attestation of a VM instance running thereon, for example, when the VM is instantiated or when the application executes. UE <NUM> may attest to one or more of Attestation Nodes 110A-<NUM> that UE <NUM> is communicating within a secure VM instance.

When UE <NUM> wants to interact with a Provider <NUM> or another device (e.g., another UE <NUM>), such as in response to a request from a user, UE <NUM> will check with one or more of Attestation Nodes 110A-<NUM> to determine whether the provider or other device has attested to its execution within a VM instance. If the one or more of Attestation Nodes 110A-<NUM> confirms Provider <NUM> or other device has attested accordingly to Attestation Nodes 110A-<NUM>, UE <NUM> will connect to Provider <NUM> or other device. If the one or more of Attestation Nodes 110A-<NUM><NUM> indicates that Provider <NUM> or other device has not attested (or its attestation indicates that the other device is invalid), UE <NUM> will not connect to Provider <NUM> or other device. In some cases, UE <NUM> may output a notice (e.g., to a user of UE <NUM> via a graphical user interface) that Provider <NUM> or other device is potentially operating in a compromised environment. The user may be able to instruct or command UE <NUM> (e.g., through the graphical user interface) to connect to Provider <NUM> or other device despite the attestation of invalidity.

In some examples, Attestation Nodes 110A-<NUM>, Providers 120A-120n, and UEs 130A-130o may be associated with respective entities. For example, each Provider <NUM> may be a physical device (e.g., server, access point, or network node) controlled by a cellular provider of a plurality of cellular providers or one or more business entities. Similarly, each Attestation Node <NUM> may be maintained or associated with a cellular provider among the plurality of cellular providers, e.g., for cellular or data service. Each UE <NUM> may subscribe to a cellular provider among the plurality of cellular providers. Providers 120A-120n may communicate with Attestation Nodes 110A-<NUM> associated with a same cellular provider. UEs 130A-130o may likewise communicate with Attestation Nodes 110A-<NUM> associated with a same cellular provider. In this way, the authority of Attestation Nodes 110A-<NUM> may be established through the cellular provider (e.g., respective entities).

<FIG> illustrates a timing diagram for an example of a method 200a for providing secure endpoint communication in accordance with aspects of the present disclosure. The timing diagram illustrates a UE <NUM>, a Provider <NUM>, and an Attestation Node <NUM>. As a non-limiting example, UE <NUM>, Provider <NUM>, and Attestation Node <NUM> (or Node <NUM>) may all be associated with a same first cellular provider.

Referring to <FIG>, at 205a, UE <NUM> receives an indication to execute an application (e.g., a user instruction to launch an application). At 210a, UE <NUM> instantiates a VM instance and executes the application within the VM instance. For example, hypervisor executing on UE <NUM> may instantiate an isolated VM instance for the application. At 215a, UE <NUM> may then create an attestation to the application operating within the VM instance. For example, a root hardware certificate may be generated for the VM instance. At 220a, UE may attest to its security status to Node <NUM> (e.g., by sharing the generated root hardware certificate).

In an example, a hypervisor of UE <NUM> may instantiate the VM instance and allocate hardware resources (e.g., processor power, memory) to the VM instance. The VM instance may include a copy of a primary operating system of UE <NUM>. However, this is merely an example. In some cases, the hypervisor may instantiate the VM with a different operating system (e.g., type or version number), and/or a customized version of the operating system. For example, if certain functionality is known to be unneeded for an application executing within the VM instance, a hypervisor may select an operating system that does not provide those features. This can reduce overhead in instantiating and deleting the VM instance, as well as limiting the required hardware allocation.

At 225a, UE <NUM> sends a communication request to Provider <NUM>. The request may indicate that UE <NUM> requires Provider <NUM> to communicate with it from within an isolated VM instance (e.g., to prevent eavesdropping). In an example, the request may be directed to a subroutine of Provider <NUM>. In an example, the request may be directed to a communication application of Provider <NUM>, which may request the instantiation of a VM instance from a hypervisor. At 230a-245a, Provider <NUM> instantiates a VM instance (230a), executes the application within the VM instance for communication (235a), creates an attestation to the application operating within the VM instance (240a), and attests to its security status to Node <NUM> (245a). As will be understood by one of ordinary skill, these actions may be substantially similar to like actions performed by UE <NUM>. In some cases, instantiating the VM instance at 230a may be triggered by the request from UE <NUM>. For example, a hypervisor of Provider <NUM> may instantiate the VM instance and allocate hardware resources (e.g., processor power, memory) to the VM instance. The hypervisor may instantiate the VM instance with a same or different operating system (e.g., type or version number) as a primary operating system of Provider <NUM>, and/or a customized version of the operating system, for example, in a way that may reduce overhead or latency of the WM instance.

Prior to connecting, at 250a and 255a, each of UE <NUM> and Provider <NUM> request or "poll" Attestation Node <NUM> for attestation information indicating that the other is operating within a secure VM environment. For example, Provider <NUM> may poll Attestation Node <NUM> in response to receiving the request from UE <NUM>, and UE <NUM> may poll Attestation Node <NUM> in response to receiving a communication response indicating that Provider <NUM> wants to connect to UE <NUM>. At 260a Node <NUM> provides to UE <NUM> the attestation information that Provider 120B is operating a VM instance. Likewise, at 265a Node <NUM> provides to Provider <NUM> the attestation information that UE <NUM> is operating a VM instance. At 270a, after receiving the attestation, UE <NUM> and Provider <NUM> establish a connection and communicate through applications executing on the respective VM instances.

Once communication ceases (e.g., a user closes the application executing on UE <NUM>), at 275a the communication link is disconnected. At 280a and 285a, UE <NUM> and Provider <NUM> close the application. At 290a and 295a, UE <NUM> and Provider <NUM> delete the respective VM instances.

In some cases, prior to deleting the VM instance, UE <NUM> may provide an opportunity to save data from the communication link. For example, UE <NUM> may (e.g., under the direction of a user) store data (e.g., communication information) from the VM instance in a cloud service and/or encrypt the data on UE <NUM>. In some cases, when the connection is closed, the VM instance may connect to an operating system on UE <NUM> and provide the data to the operating system for persistence on UE <NUM>.

<FIG> illustrates a timing diagram for an example of a method <NUM> for providing secure endpoint communication in accordance with aspects of the present disclosure. The timing diagram illustrates a UE <NUM>, a Provider <NUM>, and an Attestation Node <NUM>.

Referring to <FIG>, at 205b, Provider <NUM> receives an indication to communicate with UE <NUM> (e.g., to send a notification to UE <NUM>). At 210b, Provider <NUM> sends a communication request to UE <NUM>. At 215b, UE <NUM> receives the communication request and instantiates a VM instance to execute an application for communicating with Provider <NUM> within the VM instance. For example, a hypervisor executing on UE <NUM> may instantiate an isolated VM instance for the application. At 220b, UE <NUM> may then create an attestation to the application operating within the VM instance. For example, a root hardware certificate may be generated for the VM instance. At 225b, UE <NUM> may attest to its security status to Node <NUM> (e.g., by sharing the generated root hardware certificate). In some cases, instantiating the VM instance at 230b may be triggered by the request from Provider <NUM> and/or identifying the application to communicate with Provider <NUM>.

Prior to connecting, at 235b, UE <NUM> requests or "polls" Attestation Node <NUM> for attestation information indicating that Provider <NUM> is operating within a secure VM environment. At 240b, Node <NUM> provides to UE <NUM> the attestation information that Provider 120B is not operating a VM instance. Accordingly, at 245b, UE <NUM> denies the request to communicate from Provider <NUM>. One of ordinary skill will recognize that this is merely an example. In some cases, prior to canceling the request, UE <NUM> may notify a user that Provider <NUM> is not operating a VM instance and shared data may be compromised. In response to receiving instructions from the user (e.g., input into UE <NUM>), UE <NUM> may establish a connection with Provider <NUM>. In some instances, before denying the request, UE <NUM> may notify Provider <NUM> that it requires Provider <NUM> to communicate with it from within an isolated VM instance (e.g., to prevent eavesdropping). Provider <NUM> may then be given an opportunity to instantiate a VM and execute a communication application therein.

In some cases, prior to instantiating a VM, UE <NUM> and/or Provider <NUM> may check the requisite application and/or security protocols. If and only if the application and/or security protocols require the application to execute within a VM instance will UE <NUM> and Provider <NUM> instantiate the VM instance. In an example, the types of applications necessary to be executed within a VM instance may be identified and/or selected by a user (e.g., pre-existing user selection). In some cases, different functionality or sessions of a same application may be required to execute within different VM instances. For example, a messaging application may require each message thread (e.g., each conversation with different contacts) to be executed within different VM instances.

<FIG> illustrates a timing diagram for an example of a method 200c for providing secure endpoint communication in accordance with aspects of the present disclosure. The timing diagram illustrates a UE <NUM>, a Provider <NUM>, and an Attestation Node <NUM>. As a non-limiting example, UE <NUM>, Provider <NUM>, and Attestation Node <NUM> may all be associated with a same first cellular provider.

Referring to <FIG>, at 205c, UE <NUM> instantiates a VM instance and executes an application within the VM instance. For example, hypervisor executing on UE <NUM> may instantiate an isolated VM instance for the application. At 210c, UE <NUM> may then create an attestation to the application operating within the VM instance. For example, a root hardware certificate may be generated for the VM instance. At 215c, UE may attest to its security status to Node <NUM> (e.g., by sharing the generated root hardware certificate). The features may be substantially similar to corresponding features discussed above with reference to <FIG>.

At 220c, UE <NUM> sends a communication request to Provider <NUM>. The request may indicate that UE <NUM> requires Provider <NUM> to communicate with it from within an isolated VM instance (e.g., to prevent eavesdropping). In an example, the request may be directed to a subroutine of Provider <NUM>. In an example, the request may be directed to a communication application of Provider <NUM>, which may request the instantiation of a VM instance from a hypervisor.

At 225c, Provider <NUM> requests or "polls" Attestation Node <NUM> for attestation information indicating that UE <NUM> is operating within a secure VM environment. For example, Provider <NUM> may poll Attestation Node <NUM> in response to receiving the request from UE <NUM>. At 230c Node <NUM> provides to Provider <NUM> the attestation information that UE <NUM> is operating a VM instance.

At 235c-250c, Provider <NUM> instantiates a VM instance (235c), executes the application within the VM instance for communication (240c), creates an attestation to the application operating within the VM instance (245c), and attests to its security status to Node <NUM> (250c). As will be understood by one of ordinary skill, these actions may be substantially similar to like actions performed by UE <NUM>. In some cases, instantiating the VM instance at 235c may be triggered by the request from UE <NUM>. Then, at 255c, Provider <NUM> indicates to UE <NUM> (e.g., through the application executing on its VM instance) that it approves the request to communicate.

Prior to connecting, at 260c, UE <NUM> requests or "polls" Attestation Node <NUM> for attestation information indicating that Provider <NUM> is operating within a secure VM environment. For example, UE <NUM> may poll Attestation Node <NUM> in response to receiving the communication response indicating that Provider <NUM> wants to connect to UE <NUM>. At 265c Node <NUM> provides to UE <NUM> the attestation information that Provider 120B is operating a VM instance. At 270c, after receiving the attestation, UE <NUM> and Provider <NUM> establish a connection and communicate through applications executing on the respective VM instances.

Once communication ceases (e.g., a user closes the application executing on UE <NUM>), at 275c the communication link is disconnected. At 280c and 285c, UE <NUM> and Provider <NUM> may close the application. At 290c and 295c, UE <NUM> and Provider <NUM> may delete the respective VM instances.

One of ordinary skill will recognize that the descriptions of methods 200a, 200b, and 200c are merely examples, and various changes, alterations, additions and/or subtractions may be made without departing from the scope of the present disclosure.

<FIG> illustrates a flowchart for an example of a method <NUM> for providing secure endpoint communication in accordance with aspects of the present disclosure. The flowchart illustrates method <NUM> from the perspective of UE <NUM> (e.g., UE 130A-130o or a local system). UE <NUM> may communicate with a remote system (e.g., Provider <NUM>) to, for example, access and/or modify a user account. Further, UE <NUM> may communicate with one or more Attestation Nodes <NUM> (e.g., Nodes 110A-<NUM>) to attest to its own use of VM instances.

At <NUM>, UE <NUM> instantiates a VM instance. The instantiation may be, for example, in response to a user request to execute an application and/or in response to receiving a communication request from a remote system (e.g., Provider <NUM> or another UE 130A-130o). In some cases, instantiation of a VM instance may only occur if the application is designated to require isolation.

At <NUM>, UE <NUM> generates a certificate for the VM instance. The certificate may be based on a root certificate for the underlying hardware of UE <NUM>. As a non-limiting example, the root certificate may be an unalterable characteristic of a processor executing on UE <NUM>.

At <NUM>, UE <NUM> executes the application on or within the VM instance on UE <NUM>. By operating within the VM instance, the application may be isolated from vulnerabilities of UE <NUM> caused by other applications. At <NUM>, UE <NUM> attests to its use of VM instance to execute the application to a server (e.g., Attestation Node <NUM>). For example, UE <NUM> may share its certificate for the VM instance with the server. At <NUM>, UE <NUM> may then accept the request to communicate and establish a communication link with a remote system and, at <NUM>, communicate with the remote system through the communication link.

Once communication ceases (e.g., a user closes the application executing on UE <NUM>), the communication link is disconnected, and UE <NUM> may close the application and delete the VM instance.

Although the method <NUM> has been discussed with reference to a UE <NUM>, this is merely an example. One of ordinary skill will recognize in light of the present disclosure that aspects of the present disclosure may be implemented by Provider <NUM> and/or other systems or devices.

<FIG> is a flowchart of an example of a method <NUM> for providing secure endpoint communication in accordance with aspects of the present disclosure. The flowchart is from the perspective of a UE <NUM> (e.g., UE 130A-130o or a local system) in communication with an Attestation Node <NUM> (e.g., one or more of Nodes 110A-<NUM>) and a remote system (e.g., Provider 120A-120n). UE <NUM> may receive an indication to connect with Provider <NUM>, and, prior to connection, determine whether Provider <NUM> is communicating through a VM instance.

At <NUM>, UE <NUM> instantiates a VM instance. The instantiation may be, for example, in response to a user request to execute an application and/or in response to receiving a communication request from a remote system (e.g., Provider <NUM> or another UE 130A-o), hereafter referred to as Provider <NUM> in the discussion of <FIG>. In some cases, instantiation of a VM instance may only occur if the application is designated to require isolation.

At <NUM>, UE <NUM> executes the application within the VM instance on UE <NUM>. By operating within the VM instance, the application may be isolated from vulnerabilities of UE <NUM> caused by other applications. At <NUM>, UE <NUM> attests to its use of a VM instance to execute the application to a server (e.g., Attestation Node <NUM>). For example, UE <NUM> may share its certificate for the VM instance with the server.

At <NUM>, UE <NUM> requests an attestation of Provider <NUM> from Attestation Node <NUM>. Node <NUM> may be a node from a plurality of Attestation Nodes 110A-<NUM> that are related to a same entity (e.g., cellular service provider), hardware provider (e.g., make of a processor of UE <NUM>), or account manager (e.g., bank account manager) as UE <NUM>. The request for attestation may include an address of Provider <NUM>. Node <NUM> may then look up the provider's <NUM> attestation based on its address, and provide the attestation to UE <NUM>. In some cases, such a request may only be made if the application executing on UE <NUM> requires Provider <NUM> to communicate through a VM instance (e.g., based on application and/or security rules).

At <NUM>, UE <NUM> determines whether the provider is validly communicating through a VM instance. For example, UE <NUM> determines whether the attestation from Node <NUM> indicates that Provider <NUM> is potentially compromised.

If Provider <NUM> is determined to be communicating through a VM instance (<NUM>-Yes), then, at <NUM>, UE <NUM> establishes a connection with Provider <NUM>. UE <NUM> and Provider <NUM> may then exchange data. However, if Provider <NUM> is determined to not be communicating through a VM instance (<NUM>-No), then, at <NUM>, UE <NUM> denies the request for connection with Provider <NUM>. In some cases, UE <NUM> may output a notice that Provider <NUM> is potentially compromised. A user of UE <NUM> may, in some implementations, override the decision and instruct UE <NUM> to connect to Provider <NUM>.

<FIG> is described in terms of UE <NUM> connecting with a Provider <NUM>. However, this is merely an example. In light of the present disclosure, one of ordinary skill will recognize that various other systems (e.g., UEs 130A-130o and/or Providers 120A-120n) can perform a similar method when connecting to a device as described above, so long as a connecting device has attested to their implementation of VM instances consistent with this application.

At <NUM>, UE <NUM> receives a communication request from a remote system (e.g., from Provider <NUM> or another UE 130A-o). The communication request may indicate an application that is to be used to communicate with the remote system, hereafter referred to as Provider <NUM> in the discussion of <FIG>. In some cases, the request may indicate that a VM instance is required for the communication.

At <NUM>, UE <NUM> requests an attestation of Provider <NUM> from Attestation Node <NUM>. Node <NUM> may be a node from a plurality of Attestation Nodes 110A-<NUM> that are related to a same entity (e.g., cellular service provider), hardware provider (e.g., make of a processor of UE <NUM>), or account manager (e.g., bank account manager) as UE <NUM>. The request for attestation may include an address of Provider <NUM>. Node <NUM> may then look up the provider's <NUM> attestation based on its address, and provide the attestation to UE <NUM>. In some cases, such a request may only be made if UE <NUM> requires Provider <NUM> to communicate through a VM instance (e.g., based on application and/or security rules).

At <NUM>, UE <NUM> determines whether the provider is validly communicating through a VM instance. For example, UE <NUM> determines whether the attestation from Node <NUM> indicates that Provider <NUM> is potentially compromised. If Provider <NUM> is determined to not be communicating through a VM instance (<NUM>-No), then, at <NUM>, UE <NUM> denies the request for connection with Provider <NUM>. In some cases, UE <NUM> may output a notice that Provider <NUM> is potentially compromised. A user of UE <NUM> may, in some implementations, override the decision and instruct UE <NUM> to connect to Provider <NUM>. In some cases, UE <NUM> may notify Provider <NUM> that communication must be performed through a secure VM instance (i.e., before or with the denial).

If Provider <NUM> is determined to be communicating through a VM instance (<NUM>-Yes), then, at <NUM>, UE <NUM> instantiates a VM instance. In some cases, instantiation of a VM instance may only occur if the application is designated to require isolation, or if the request indicates that Provider <NUM> requires communication through an isolated VM instance.

At <NUM>, UE <NUM> executes the application on or within the VM instance on UE <NUM>. By operating within the VM instance, the application may be isolated from vulnerabilities of UE <NUM> caused by other applications. At <NUM>, UE <NUM> attests to its use of the VM instance to execute the application to a server (e.g., Attestation Node <NUM>). For example, UE <NUM> may share its certificate for the VM instance with the server. At <NUM>, UE <NUM> may then accept the request to communicate and establish a communication link with remote system and, at <NUM>, communicate with the remote system through the communication link.

Additionally, although methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> have generally been described in regard to communication between UE <NUM> and Provider <NUM>, these are merely examples. One of ordinary skill will recognize that aspects of the present disclosure may be implemented in communication protocols for various devices and device pairs (e.g., one or more UEs 130A-o, Providers 120A-m, and/or other devices or systems.

As shown in <FIG>, some, or all, of the system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> may be performed by, and/or in conjunction with, UE <NUM>. For clarity, UE <NUM> is described herein generally as a cell phone or smartphone. One of skill in the art will recognize, however, that the system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> may also be used with a variety of other electronic devices, such as, for example, tablet computers, laptops, desktops, and another network (e.g., cellular or IP network) connected devices from which a call may be placed, a text may be sent, and/or data may be received. These devices are referred to collectively herein as UE <NUM>. UE <NUM> may comprise a number of components to execute the above-mentioned functions and apps. As discussed below, UE <NUM> may comprise memory <NUM> including many common features such as, for example, contacts <NUM>, a calendar <NUM>, a call log (or, call history) <NUM>, operating system (OS) <NUM>, and one or more applications, such as connection app <NUM>, and a hypervisor <NUM>.

UE <NUM> may also comprise one or more root certificates <NUM> and one or more system processors <NUM>. In some implementations, the system processor(s) <NUM> can include a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or any other sort of processing unit. UE <NUM> may also include one or more of removable storage <NUM>, non-removable storage <NUM>, one or more transceiver(s) <NUM>, output device(s) <NUM>, and input device(s) <NUM>.

The root certificate <NUM> may be used to provide a means for attesting to VM instance utilization. For example, when a VM instance is instantiated, the VM instance may be hashed with the root certificate to generate an attestation certificate.

System processor <NUM> may be configured to receive a request to connect to an external device (e.g., another UE <NUM> or a Provider <NUM>). The request may be received through input device <NUM> and/or through automatic routing. System processor <NUM> may request (e.g., from Node <NUM>) attestation of the external device. The attestation may attest to the external device's use of VM instances, for example, on a ledger of the Attestation Node <NUM>. Based on the attestation, the system processor <NUM> may either establish a connection with the external device (if the external device is determined to be communicating through a VM instance), or deny the request to connect to the external device (if the external device is determined to be potentially compromised).

In various implementations, the memory <NUM> may be volatile (such as random-access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. The memory <NUM> may include all, or part, of the functions <NUM>, <NUM>, <NUM>, <NUM>, and the OS <NUM> for UE <NUM>, among other things.

The memory <NUM> may also comprise contacts <NUM>, which can include names, numbers, addresses, and other information about the user's business and personal acquaintances, among other things. In some examples, the memory <NUM> may also include a calendar <NUM>, or other software, to enable the user to track appointments and calls, schedule meetings, and provide similar functions. In some examples, the memory <NUM> may also comprise the call log <NUM> of calls received, missed, and placed from UE <NUM>. As usual, the call log <NUM> may include timestamps for each call for use by the system environment <NUM>. Of course, the memory <NUM> can also include other software such as, for example, e-mail, text messaging, social media, and utilities (e.g., calculators, clocks, compasses, etc.).

The memory <NUM> may also include the OS <NUM>. Of course, the OS <NUM> varies depending on the manufacturer of UE <NUM> and currently comprises, for example, iOS <NUM>. <NUM> for Apple products and Pie for Android products. The OS <NUM> contains the modules and software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.

As mentioned above, UE <NUM> may also include the connection app <NUM> and a hypervisor <NUM>. The connection app <NUM> and hypervisor <NUM> may perform some, or all, of the functions discussed above with respect to the methods 200a, 200b, 200c, <NUM>, <NUM>, and <NUM> for interactions occurring between UE <NUM> and an external device (e.g., another UE <NUM>, Provider <NUM>, and/or Attestation Nodes <NUM>). For example, when the connection app <NUM> is selected, hypervisor <NUM> may instantiate a VM instance, and connection app <NUM> may be executed within the VM instance. The connection app <NUM> may then communicate with Provider <NUM> without fear that other application on UE <NUM> will eavesdrop on connection app <NUM>.

In some cases, the hypervisor may be a native hypervisor executing outside of OS <NUM>. However, this is merely an example and, in an example, hypervisor <NUM> is hosted by OS <NUM>.

UE <NUM> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. The removable storage <NUM> and non-removable storage <NUM> can store some, or all, of the functions <NUM>, <NUM>, <NUM>, <NUM>, and the OS <NUM>.

Non-transitory computer-readable media may include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, removable storage <NUM>, and non-removable storage <NUM> are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, electronically erasable programmable ROM (EEPROM), flash memory or other memory technology, compact disc ROM (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which can be used to store the desired information and which can be accessed by UE <NUM>. Any such non-transitory computer-readable media may be part of UE <NUM> or may be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s) <NUM> may include any sort of transceivers known in the art. In some examples, the transceiver(s) <NUM> can include a wireless modem to facilitate wireless connectivity with the other UEs, the Internet, and/or an intranet via a cellular connection. Further, the transceiver(s) <NUM> may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna (e.g., Wi-Fi or Bluetooth®). In other examples, the transceiver(s) <NUM> may include wired communication components, such as a wired modem or Ethernet port, for communicating with the other UE or the provider's Internet-based network. In this case, the transceiver(s) <NUM> can also enable UE <NUM> to communicate with the Nodes <NUM> and Providers <NUM>, as described herein.

In some implementations, output device(s) <NUM> includes any sort of output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display, speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, output device(s) <NUM> can play various sounds based on, for example, whether UE <NUM> is connected to a network, the type of call being received (e.g., video calls vs. voice calls), the number of active calls, etc. In some examples, output device(s) <NUM> can play a sound or display a graphic when a new connection (e.g., with Provider <NUM>) is requested, a Provider <NUM> is determined to be compromised, a connection is successful, etc. Output device(s) <NUM> also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s) <NUM> includes any sort of input devices known in the art. The input device(s) <NUM> may include, for example, a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad may be a standard pushbutton alphanumeric, multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen, or one or more other types of keys or buttons, and may also include a joystick, wheel, and/or designated navigation buttons, or the like.

As shown in <FIG>, the system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> may also be used in conjunction with a server <NUM> (e.g., Provider <NUM> and/or Attestation Node <NUM>). The server <NUM> can comprise, for example, a desktop or laptop computer, a server, bank of servers, or cloud-based server bank. Thus, while the server <NUM> is depicted as single standalone servers, other configurations or existing components could be used. In some examples, the server <NUM> may comprise existing network entities such as, for example, a home location register (HLR), home subscriber service (HSS), a third-generation partnership project authentication, authorization and accounting (3GPP AAA) server, or another server or component. The server <NUM> may implement aspects of Provider <NUM> and/or Node <NUM>.

The server <NUM> may comprise a number of components to execute the above-mentioned functions and apps. As discussed below, the server <NUM> may comprise memory <NUM> including many common features such as, for example, the OS <NUM>. In various implementations, the memory <NUM> may be volatile (such as random access memory (RAM)), non-volatile (such as read-only memory (ROM), flash memory, etc.), or some combination of the two. The memory <NUM> may include all, or part, of the functions of a connection app <NUM> and hypervisor <NUM>, among other things.

The memory <NUM> may also include the OS <NUM>. Of course, the OS <NUM> varies depending on the manufacturer of the server <NUM> and the type of component. Many servers, for example, run Linux or Windows Server. Dedicated cellular routing servers may run specific telecommunications OS <NUM>. The OS <NUM> contains the modules and software that supports a computer's basic functions, such as scheduling tasks, executing applications, and controlling peripherals.

A connection app <NUM> may provide communication between the server <NUM> and external systems (e.g., UE <NUM>, other Providers <NUM>, and/or Nodes <NUM>). Hypervisor <NUM> may instantiate, manage, and delete VM instances and/or applications (e.g., connection app <NUM>) executing thereon.

The server <NUM> may also comprise one or more boot processor(s) <NUM> and system processors <NUM>. Boot processor <NUM> may aid in system start-up. In some implementations, the system processor(s) <NUM> can include a central processing unit (CPU), a graphics processing unit (GPU), or both CPU and GPU, or any other sort of processing unit. The server <NUM> may also include one or more of removable storage <NUM>, non-removable storage <NUM>, one or more transceiver(s) <NUM>, output device(s) <NUM>, and input device(s) <NUM>.

System processor <NUM> may be configured to receive a request to connect to an external device (e.g., UE <NUM> or another server <NUM>). System processor <NUM> may request (e.g., from Node <NUM>) attestation of the external device. For example, attestation may be a self-attestation stored on a ledger of the Attestation Node <NUM>. Based on the attestation, the system processor <NUM> may either establish a connection with the external device (if the external device is determined to be valid), or deny the request to connect to the external device (if the external device is determined to be compromised).

The server <NUM> may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in <FIG> by removable storage <NUM> and non-removable storage <NUM>. The removable storage <NUM> and non-removable storage <NUM> may store some, or all, of the OS <NUM>, hypervisor <NUM>, and connection app <NUM>.

Non-transitory computer-readable media may include volatile and nonvolatile, removable and non-removable tangible, physical media implemented in technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The memory <NUM>, removable storage <NUM>, and non-removable storage <NUM> are all examples of non-transitory computer-readable media. Non-transitory computer-readable media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, DVDs or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other tangible, physical medium which may be used to store the desired information, and which can be accessed by the server <NUM>. Any such non-transitory computer-readable media may be part of the server <NUM> or may be a separate database, databank, remote server, or cloud-based server.

In some implementations, the transceiver(s) <NUM> include any sort of transceivers known in the art. In some examples, the transceiver(s) <NUM> may include a wireless modem to facilitate wireless connectivity with UEs <NUM>, additional servers, the Internet, and/or an intranet via a cellular connection. Further, the transceiver(s) <NUM> may include a radio transceiver that performs the function of transmitting and receiving radio frequency communications via an antenna (e.g., Wi-Fi or Bluetooth®). In other examples, the transceiver(s) <NUM> may include wired communication components, such as a wired modem or Ethernet port, for communicating with the other UEs or the provider's Internet-based network. The transceiver(s) <NUM> may transmit requests to and receive attestation information from Attestation Node(s) <NUM>, and send messages to UEs <NUM>, among other things.

In some implementations, the output device(s) <NUM> may include any sort of output devices known in the art, such as a display (e.g., a liquid crystal or thin-film transistor (TFT) display), a touchscreen display, speakers, a vibrating mechanism, or a tactile feedback mechanism. In some examples, the output devices may play various sounds based on, for example, whether the server <NUM> is connected to a network, the type of data being received (e.g., a match vs. a request for service listings), when SIM-OTA messages are being transmitted, etc. Output device(s) <NUM> may also include ports for one or more peripheral devices, such as headphones, peripheral speakers, or a peripheral display.

In various implementations, input device(s) <NUM> includes any sort of input devices known in the art. For example, the input device(s) <NUM> may include a camera, a microphone, a keyboard/keypad, or a touch-sensitive display. A keyboard/keypad may be a standard pushbutton alphanumeric, multi-key keyboard (such as a conventional QWERTY keyboard), virtual controls on a touchscreen, or one or more other types of keys or buttons, and may also include a joystick, wheel, and/or designated navigation buttons, or the like.

<FIG> depicts a conventional cellular network <NUM> including <NUM> <NUM>, <NUM> <NUM>, <NUM> long-term evolution (LTE) <NUM>, and <NUM> <NUM> components. Of course, future technologies, such as, for example, <NUM> and device-to-device (D2D) components could also be included and are contemplated herein. Many of the "back-end" components of network <NUM> could handle some, or all, of system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> associated with remote device security attestation and manipulation detection.

As is known in the art, data may be routed from the Internet or other sources using a circuit switched modem connection (or non-3GPP connection), which provides relatively low data rates, or via IP based packet switched <NUM> connections, which results is higher bandwidth. LTE system <NUM>, which is purely IP based, essentially "flattens" the architecture, with data going straight from the internet to service architecture evolution gateway (SAE GW) <NUM> to evolved Node B transceivers <NUM>, enabling higher throughput. UE <NUM> also has wireless local area network (WLAN) <NUM> capabilities, in some cases enabling even higher throughput. In some cases, cellular carriers may use WLAN communications in addition to, or instead of, cellular communications to supplement bandwidth.

Serving GPRS support node (SGSN) <NUM> is a main component of the general packet radio service (GPRS) network, which handles all packet switched data within the network <NUM> (e.g., the mobility management and authentication of the users). MSC <NUM> essentially performs the same functions as SGSN <NUM> for voice traffic. MSC <NUM> is the primary service delivery node for global system for mobile communication (GSM) and code division multiple access (CDMA), responsible for routing voice calls and short messaging service (SMS) messages, as well as other services (such as conference calls, fax, and circuit switched data). MSC <NUM> sets up and releases the end-to-end connection, handles mobility and hand-over requirements during the call, and takes care of charging and real-time pre-paid account monitoring.

Similarly, mobility management entity (MME) <NUM> is the key control-node for <NUM> LTE network <NUM> and <NUM> <NUM>. It is responsible for idle mode UE <NUM> paging and tagging procedures including retransmissions. MME <NUM> is involved in the bearer activation/deactivation process and is also responsible for choosing SAE GW <NUM> for UE <NUM> at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation (i.e., switching from one cell tower to the next when traveling). MME <NUM> is responsible for authenticating the user (by interacting with the HSS <NUM> discussed below). The Non-Access Stratum (NAS) signaling terminates at the MME <NUM> and it is also responsible for generation and allocation of temporary identities to UE <NUM>. The MME <NUM> also checks the authorization of UE <NUM> to camp on the service provider's HPLMN or VPLMN and enforces UE <NUM> roaming restrictions on the VPLMN. MME <NUM> is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. MME <NUM> also provides the control plane function for mobility between LTE <NUM> and <NUM> <NUM>/<NUM> <NUM> access networks with an S3 interface terminating at MME <NUM> from SGSN <NUM>. MME <NUM> also terminates an S7a interface towards home HSS <NUM> for roaming UE <NUM>.

Referring to <NUM> <NUM>, MME <NUM> may be configured to respond to an initial attach request by sending a create session request to a network slice selector, also referred to herein as a slice selector and/or a network selector. The create session request may be sent over a logical communication interface that is referred to as an NG4 interface. The NG4 interface typically is used for messaging between the control plane function and the user plane forwarding function of a <NUM> network. Aspects of the present disclosure may be implemented within containerization of Software Defined Networks (SDN) of <NUM> nodes, and/or Network Function Virtualization (NfV). As will be understood by one of ordinary skill, SDN decouples traditionally decentralized network control from the physical devices, enabling programmatic control and infrastructure abstraction.

In response to receiving a create session request, the network slice selector may determine which of the available network slices should be used to provide services for UE <NUM> and may redirect the create session request to the selected network slice. For example, the create session request may be directed to a gateway component of the selected network slice. Specific for a <NUM> network, the gateway component may comprise a user plane forwarding function.

HSS/HLR <NUM> is a central database that contains user-related and subscription-related information. The functions of HSS/HLR <NUM> include functionalities such as mobility management, call and session establishment support, user authentication and access authorization. HSS, which is used for LTE connections, is based on the previous HLR and Authentication Center (AuC) from CGMA and GSM technologies, with each serving substantially the same functions for their respective networks.

The policy and charging rules function (PCRF) <NUM> is a software node that determines policy rules in network <NUM>. PCRF <NUM> generally operates at the network core and accesses subscriber databases (e.g., HSS/HLR <NUM>) and other specialized functions, such as enhanced e911 call handling, in a centralized manner. PCRF <NUM> is the main part of network <NUM> that aggregates information to and from network <NUM> and other sources (e.g., IP networks <NUM>). PCRF <NUM> may support the creation of rules and then may automatically make policy decisions for each subscriber active on network <NUM>. PCRF <NUM> may also be integrated with different platforms like billing, rating, charging, and subscriber database or may also be deployed as a standalone entity.

Finally, 3GPP AAA server <NUM> performs authentication, authorization, and accounting (AAA) functions (e.g., call routing <NUM> and/or white listing <NUM>) and may also act as an AAA proxy server. For WLAN <NUM> access to (3GPP) IP networks <NUM>3GPP AAA Server <NUM> provides authorization, policy enforcement, and routing information to various WLAN components. 3GPP AAA Server <NUM> may generate and report charging/accounting information, performs offline charging control for WLAN <NUM>, and perform various protocol conversions when necessary.

While several possible examples are disclosed above, examples of the present disclosure are not so limited. While the system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> above are discussed with reference to use with cellular communications, for instance, the system environment <NUM> and methods 200a, 200b, 200c, <NUM>, <NUM>, <NUM> can be used for other types of wired and wireless communications. In addition, while various functions are discussed as being performed on UE <NUM>, by Provider <NUM>, or Nodes <NUM>, other components could perform the same or similar functions without departing from the scope of the present invention as defined by the apended claims.

Claim 1:
A user equipment, UE, (<NUM>) comprising:
a processor (<NUM>);
a transceiver (<NUM>); and
a memory (<NUM>) storing instructions that, when executed by the processor (<NUM>), control the processor (<NUM>) to:
receive (210b), through the transceiver (<NUM>) and from a remote system (<NUM>), a communication request to communicate with the remote system (<NUM>), the communication request indicating that the remote system (<NUM>) requires the application for processing the communication request must be executed within an isolated virtual machine instance;
instantiate (215b), in response to receiving the communication request, a UE virtual machine instance on the UE (<NUM>), the UE virtual machine instance being hashed with a root certificate when the UE virtual machine instance is instantiated, the root certificate certifying underlying hardware of the UE virtual machine instance;
execute, on the UE virtual machine instance, an application for processing the communication request;
transmit (220a), through the transceiver and to an attestation server (<NUM>), the root certificate to attest to the execution of the application within the UE virtual machine instance;
establish (270a) a communication link between the application and the remote system (<NUM>); and
communicate, via the transceiver, with the remote system (<NUM>) across the communication link.