Patent Description:
In some instances, a bad actor may attempt to modify an application running on a computing device so that it does not operate as intended by a developer. For example, an application may place restrictions on various functions supported by the application until the bad actor purchases a license. To avoid purchasing a license, a bad actor may modify the application to circumvent these restrictions. As another example, an application might provide various awards based on location data supplied by the device. A bad actor might then attempt to modify the application (or install a modified version of the application) that allows the bad actor to falsify location information in order to obtain additional rewards. <CIT> discloses a method to allow programs running within the application space of a device with a secure processor and a trusted computing base to flexibly use certificates that describe the required system state.

This disclosure includes references to "one embodiment" or "an embodiment. " The appearances of the phrases "in one embodiment" or "in an embodiment" do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.

Within this disclosure, different entities (which may variously be referred to as "units," "circuits," other components, etc.) may be described or claimed as "configured" to perform one or more tasks or operations. This formulation-[entity] configured to [perform one or more tasks]-is used herein to refer to structure (i.e., something physical, such as an electronic circuit). More specifically, this formulation is used to indicate that this structure is arranged to perform the one or more tasks during operation. A structure can be said to be "configured to" perform some task even if the structure is not currently being operated. A "secure circuit configured to generate an attestation" is intended to cover, for example, an integrated circuit that has circuitry that performs this function during operation, even if the integrated circuit in question is not currently being used (e.g., a power supply is not connected to it). Thus, an entity described or recited as "configured to" perform some task refers to something physical, such as a device, circuit, memory storing program instructions executable to implement the task, etc. This phrase is not used herein to refer to something intangible. Thus, the "configured to" construct is not used herein to refer to a software entity such as an application programming interface (API).

The term "configured to" is not intended to mean "configurable to. " An unprogrammed FPGA, for example, would not be considered to be "configured to" perform some specific function, although it may be "configurable to" perform that function and may be "configured to" perform the function after programming.

Reciting in the appended claims that a structure is "configured to" perform one or more tasks is expressly intended not to invoke <NUM> U. § <NUM>(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section <NUM>(f) during prosecution, it will recite claim elements using the "means for" [performing a function] construct.

As used herein, the terms "first," "second," etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless specifically stated. For example, a mobile device may have a first user and a second user. The term "first" is not limited to the initial user of the device. The term "first" may also be used when only one user of the mobile device exists.

As used herein, the term "based on" is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect a determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase "determine A based on B. " This phrase specifies that B is a factor used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase "based on" is thus synonymous with the phrase "based at least in part on.

The invention is defined in the independent claims <NUM> and <NUM>. The present disclosure describes embodiments in which a computing device can provide an attestation indicative of an application's integrity/validity. As used herein, the term "integrity" is used to describe an application that has not been modified in an unauthorized manner. Accordingly, an application would be said to lack integrity if, for example, it has been modified by a bad actor to operate in a manner unintended by the developer. As will be discussed in greater detail below, an application executing on a computing device may connect to a remote service in order to perform some function. To attest to its integrity, in various embodiments, the application can request an attestation from the computing device that is provided based on a verification of the application. In some embodiments, this verification is performed in part by a secure circuit of the computing device. If the verification is successful, the secure circuit generates the requested attestation, which is signed with a cryptographic key maintained by the secure circuit. In various embodiments, this cryptographic key is specific to the application and/or the current user of the application. After the attestation has been issued by the secure circuit, the application may provide the attestation to the remote service in order to attest that the application has not been improperly modified. In other embodiments discussed below, the verification and attestation generation may be handled by an operating system of the computing device, a remote server, the secure circuit, or a combination thereof. In many instances, implementing a verification system in this manner can reduce the likelihood that a computing device is executing an improperly modified application.

Turning now to <FIG>, a block diagram of a verification system 10A is depicted. In the illustrated embodiment, system 10A includes a computing device <NUM>, which includes a central processing unit (CPU) <NUM>, memory <NUM>, and a secure enclave processor (SEP) <NUM> coupled together via an interconnect <NUM>. Memory <NUM> includes an application <NUM> and an operating system (OS) <NUM>. System 10A further includes a remote server <NUM>. In some embodiments, system 10A may be implemented differently than shown-e.g., system 10A may include an attestation server as discussed below with respect to <FIG>, computing device <NUM> may include one or more components discussed below with respect to <FIG>, etc..

Application <NUM>, in various embodiments, is executable to connect to a remote service, which, in the illustrated embodiment, is provided by remote server <NUM>. Application <NUM> may correspond to any suitable application, which is potentially vulnerable to undesired modification. Similarly, remote server <NUM> may correspond to any suitable computer system and may provide any suitable service. For example, application <NUM> may be an application attempting to retrieve content from server <NUM> in order to present that content to the user. As another example, application <NUM> may be a multiplayer game that is attempting to connect to server <NUM>, so a user can play against other users. In some embodiments, remote server <NUM> is operated by a developer of application <NUM>; in other embodiments, server <NUM> may be operated by some other entity.

As noted above, in various embodiments, application <NUM> can provide an attestation <NUM> to remote server <NUM> in order to attest to its integrity-e.g., that it has not been modified in some unauthorized manner. In some embodiments, remote server <NUM> may request an attestation <NUM> as a prerequisite to establishing a connection with application <NUM> (or providing any service requested by application <NUM>). As will be discussed below, in some embodiments, attestation <NUM> is a signed challenge issued by remote server <NUM> and signed using an application key <NUM> maintained by SEP <NUM>. After receiving an attestation <NUM>, remote server <NUM> may then attempt to verify attestation <NUM>. In some embodiments, remote server <NUM> may also perform a user authentication distinct from verification of the received attestation <NUM>. As shown, application <NUM> may issue a request <NUM> to OS <NUM> in order to have an attestation <NUM> generated.

OS <NUM>, in various embodiments, is executable to manage various operations of computing device <NUM>. In the illustrated embodiment, OS <NUM> facilitates interfacing application <NUM> and SEP <NUM>, which may be provided by an application programming interface (API) supported by OS <NUM>. Accordingly, application <NUM> may issue request <NUM> as an API call to OS <NUM>, which, in turn, may provide request <NUM> to SEP <NUM>. OS <NUM> may also return an attestation <NUM> generated by responsive to the request via the API to application <NUM> for delivery to remote server <NUM>. In some embodiments, OS <NUM> also participates in the verification of application <NUM> as will be discussed below and, in some embodiments, even generates attestation <NUM>.

SEP <NUM>, in various embodiments, is a secure circuit configured to perform cryptographic services for computing device <NUM>. As used herein, the term "secure circuit" refers to one of a class of circuits that is configured to perform one or more services and return an authenticated response to an external requester. A result returned by a secure circuit is considered to have indicia of trust exceeding that of a circuit that merely returns a result without any form of authentication. In some embodiments, responses from SEP <NUM> are authenticated through the use of cryptography such as providing a digital signature or encrypted data. In some embodiments, responses from SEP <NUM> are authenticated by being communicated through a trusted communication channel such as a dedicated bus between SEP <NUM> and the other party or a mailbox mechanism discussed below. In contrast, a circuit such as a hardware accelerator that merely operates on some received value and returns a result would not be considered a secure circuit within the meaning of this disclosure. By authenticating results that are returned, such as by signing with a verifiable digital signature, a secure circuit may thus provide anti-spoofing functionality. Additionally, in some cases, a secure circuit may be said to be "tamper-resistant," which is a term of art referring to mechanisms that prevent compromise of the portions of the secure circuit that perform the one or more services.

In some embodiments, SEP <NUM> is configured to generate an attestation <NUM> for an application <NUM> and to verify the application <NUM> prior to providing attestation <NUM>. As will be discussed in greater detail below with respect to <FIG>, this verification may include receiving various metadata from application <NUM> attesting the identity of application <NUM> and its integrity. In various embodiments, this metadata includes an application certificate supplied by a developer and including one or more signed hash values generated from a valid copy of application <NUM>. In some embodiments, the certificate may also include an identify of the application as well as various other criteria defined by the developer. Accordingly, in response to receiving this metadata, SEP <NUM> may verify the application certificate and verify that hash values generated from application <NUM> match those in the application certificate. In some embodiments, this verification may be performed in part (or entirely) by operating system <NUM>. For example, in one embodiment, OS <NUM> may generate one or more hash values from application <NUM> and supply them to SEP <NUM>, which compares them against the signed hash values supplied by the developer. In another embodiment, OS <NUM> performs the comparison and indicates a result of the comparison to SEP <NUM>, which verifies the result prior to generating an attestation <NUM>. (In still other embodiments, verification and/or generation may be handled by an attestation server as will be discussed below with respect to <FIG>. ) In various embodiments, this verification may be performed during an enrollment of application <NUM> and/or during generation of attestation <NUM>.

In some embodiments, before a request <NUM> for an attestation can be issued, application <NUM> may perform an initial enrollment in which SEP <NUM> generates an application key <NUM> for use in subsequent generations of attestations <NUM>. In some embodiments, this enrollment may be performed when application <NUM> is installed or updated (or if a new user is added). During the enrollment, SEP <NUM> may derive a public key pair having a public key and a private key corresponding to application key <NUM>. In some embodiments, these derived keys are unique to a given device <NUM> (or SEP <NUM>)-accordingly, two devices <NUM> would include different keys. In some embodiments, these derived keys are unique to an application <NUM> on device <NUM> (or even unique to the version of application <NUM>). In some embodiments discussed below, derived keys are also unique to a particular user-accordingly, an application <NUM> having two users would supply attestations <NUM> generated using separate keys <NUM>. In various embodiments, enrollment may also include SEP <NUM> generating a certificate for the public key pair-in doing so, SEP <NUM> may be acting as a certificate authority (CA). This certificate may include the pubic key and be conveyed to remote server <NUM> along with attestation <NUM> so that the public key can be used by remote server <NUM> to verify the attestation <NUM>. In some embodiments, this certificate may include additional content such as a reference to the developer certificate used in the verification, the signed hash values from the certificate, etc. In some embodiments, this certificate (as well as the other certificates described herein) is X. <NUM> compliant.

After enrollment, an application <NUM> may issue a request <NUM> for an attestation <NUM>-e.g., when it intends to establish a connection with remote server <NUM>. In response to a successful verification of application <NUM>, in some embodiments, SEP <NUM> is configured to retrieve the corresponding application key <NUM> and generate a correspond attestation <NUM>. As noted above, in some embodiments, this generation include signing a challenge issued by remote server <NUM>. SEP <NUM> may, however, sign other information to generate attestation <NUM> such as the hash values generated from application <NUM>, a timestamp, etc. Although not depicted in <FIG> for simplicity, SEP <NUM> may supply the attestation <NUM> via OS <NUM> to application <NUM>, which may deliver it to remote server <NUM> for verification. Application <NUM> may also supply a certificate obtained during enrollment and including the public key usable to verify attestation <NUM>. In some embodiments, the application certificate and/or a root certificate associated with manufacturer for device <NUM> may also be conveyed to remote server <NUM> to facilitate verification of the attestation <NUM>.

Turning now to <FIG>, a block diagram of a verification system 10B is depicted. As noted above, application verification and/or attestation generation may be performed by an external server. Accordingly, in the illustrated embodiment, verification system 10B includes elements <NUM>-<NUM> as discussed above with respect to <FIG> and further includes an attestation server <NUM> configured to perform application verification and/or attestation generation. In some embodiments, system 10B may be implemented differently than shown. Although labeled as a server, computing system <NUM> may correspond to any suitable computing device such a neighboring device to computing device <NUM>, a device associated to the same cloud-based account as device <NUM>, any of the computing devices listed below with respect to <FIG>, etc..

In embodiments in which attestation server <NUM> performs verification, attestation server <NUM> may receive a request <NUM> including metadata about application <NUM> to verified by server <NUM>. In the illustrated embodiment, SEP <NUM> signs the request <NUM> using a request key <NUM> in order to attest that the request <NUM> is coming from a valid device <NUM> (and also a device including SEP <NUM>). In such an embodiment, attestation server <NUM> verifies the signature of request <NUM> along with the accompanying metadata, which may be verified in a similar manner as discussed above and in greater detail below. In some embodiments, metadata provided to server <NUM> may be obfuscated such that server <NUM> is able to verify it without knowing the full content of the metadata. For example, the metadata in request <NUM> may include a hash value of application <NUM>'s name (rather than the actual name) in order to obfuscate the name to server <NUM>. In various embodiments, any metadata conveyed to server <NUM> is conveyed in a manner compliant with well-established privacy policies and/or privacy practices. A user may also "opt out" of participation such as discussed below. In some embodiments in which server <NUM> is not responsible for generating attestation <NUM>, server <NUM> may send a result of the verification to SEP <NUM> (or more generally device <NUM>), which may generate an attestation <NUM> based on the received result. In still other embodiments, SEP <NUM> (or OS <NUM>) may maintain application keys <NUM>, but server <NUM> may certify those keys <NUM> in response to receiving and verifying a request <NUM>. In particular, request <NUM> may be a certificate signing request (CSR) including a public key corresponding to an application key <NUM> (the key <NUM> being a private key in such an embodiment) along with a signature generated from key <NUM>. After verifying information in request <NUM>, server <NUM> may issue a corresponding certificate for the key <NUM>. This certificate may later be presented with an attestation <NUM> to server <NUM>, which may use the certificate to verify the attestation <NUM>.

In embodiments in which attestation server <NUM> performs generation of attestation <NUM>, attestation server <NUM> may retrieve an application key <NUM> and produce attestation <NUM> by generating a digital signature using key <NUM> as discussed above and in greater detail below. In embodiments in which server <NUM> performs application verification, this attestation <NUM> may be produced based a result of server <NUM>'s verification. In other embodiments, SEP <NUM> and/or OS <NUM> may perform the verification and indicate a result of the verification to server <NUM> to cause it to provide an attestation <NUM>. In still other embodiments discussed below with respect to <FIG>, server <NUM> may generate a public key pair and provide the pair to device <NUM> (specifically OS <NUM>) to enable it to generate attestations <NUM>.

Turning now to <FIG>, a block diagram of an interaction 200A to obtain an attestation <NUM> generated by SEP <NUM> is depicted. In the illustrated embodiment, application <NUM> includes program instructions <NUM>, data <NUM>, and metadata <NUM>, which may be used to verify application <NUM> and obtain attestation <NUM> as will be discussed below. In some embodiments, interaction 200A may be implemented differently-e.g., metadata <NUM> may not be included in application <NUM>, metadata <NUM> may include more (or less) elements, request <NUM> may include metadata <NUM>, etc..

Metadata <NUM>, in various embodiments, is information about application <NUM> and usable to verify application <NUM>. In the illustrated embodiment, metadata <NUM> includes an application identifier <NUM> and application certificate <NUM>, which includes one or more signed hash values <NUM> and a key threshold <NUM>. In various embodiments, application identifier <NUM> is a value that uniquely identifies application <NUM> such as a name of application <NUM>, a version number, a random value, or a combination thereof. In some embodiments, identifier <NUM> may be included in certificate <NUM>. In various embodiments, application certificate <NUM> is a certificate issued by a developer of application <NUM> (or an app. store selling application <NUM>) with hash values <NUM> generated by applying a hash function to program instructions <NUM> for a valid copy of application <NUM> and signing the hash values using a private key, which may have a corresponding public key included in certificate <NUM>. Accordingly, if program instructions <NUM> are subsequently modified, any subsequently generated hash values from instructions <NUM> may then deviate from signed hash values <NUM>.

Key threshold <NUM>, in various embodiments, is a set of one or more criteria pertaining to application keys <NUM>. As noted above, in some embodiments, an application key <NUM> may be generated for each user of a particular application <NUM>. In such an embodiment, key threshold <NUM> may limit the number of keys <NUM> that can be generated for users of application <NUM>. For example, threshold <NUM> may specify that keys <NUM> can be generated for up to five users. If a request <NUM> is received to generate a sixth key <NUM> for a sixth user, SEP <NUM> may deny this request (or replace one of the already generated keys <NUM> such as removing a particular user's previously generated key <NUM> in response to receiving a request to generate a new key for the particular user). In another embodiment, key threshold <NUM> may limit the number of keys <NUM> that can be generated based on the number of versions of an application <NUM>. For example, if a developer has released two versions of an application (e.g., version <NUM> and version <NUM>), key threshold <NUM> may indicate that up to two keys <NUM> may be generated-assuming that version <NUM> was initially installed and then updated to version <NUM>. In some embodiments, key threshold <NUM> may also be used to limit the number of issued certificates that are valid for application <NUM> at a given point in time. In some instances, placing restrictions on keys <NUM> (and/or certificates <NUM>) may prevent a malicious actor from achieving some benefit by creating multiple keys <NUM> such as those tied to fraudulent user accounts versions, etc..

As noted above, enrollment exchange 202A may be performed to establish an application key <NUM> usable to generate a subsequent attestation <NUM>. As shown, exchange 202A may be include application <NUM> sending an enrollment request <NUM> to SEP <NUM>. In the illustrated embodiment, this request <NUM> includes metadata <NUM> and a user identifier <NUM>. In some embodiments, user identifier <NUM> is an index value used to look up what key <NUM> should be used for a given application <NUM> when multiple keys have been generated for multiple users. Accordingly, user identifier <NUM> may correspond to any suitable value usable to distinguish one user's key <NUM> from another's key <NUM>. For example, in one embodiment, identifier <NUM> is a random value assigned to a user to distinguish it from other users. In other embodiments, identifier <NUM> may be some value known to server <NUM>. For example, in one embodiment, identifier <NUM> is a hash value of a user account used by the user of application <NUM> to access remote server <NUM>. In other embodiments, other types of index values may be used for looking up a key <NUM> associated with a particular application <NUM>. In response to receiving metadata <NUM>, SEP <NUM> may verify that it correctly corresponds to application <NUM>. As noted above, this may include SEP <NUM> (or OS <NUM>) reading program instructions and/or data <NUM> to generate one or more hash values, which are compared against signed hash values <NUM>. In some embodiments, SEP <NUM> may also confirm that generating a new key <NUM> complies with key threshold <NUM>. If the verification is successful, SEP <NUM> may generate a public key pair and return a corresponding key certificate <NUM>. In various embodiments, key certificate <NUM> includes the public key of the public key pair and a signature generated with the private key, which is application key <NUM>. In some embodiments, key certificate <NUM> may further include at least a portion of metadata <NUM> such as application identifier <NUM> and/or signed hash values <NUM>. In some embodiments, certificate <NUM> may include a reference to application certificate <NUM> such as the digital signature from certificate <NUM>. In some embodiments, certificate <NUM> may include user identifier <NUM>-e.g., to enable remote server <NUM> also rely on attestation <NUM> to authenticate a particular user associated with application key <NUM>. In many instances, enrollment 202A may be performed only once in order to allow many subsequent performances of usage exchanges 204A.

Once enrollment exchange 202A has been performed, application <NUM> may perform a usage exchange 204A when it wants an attestation <NUM>. In some embodiments, exchange 202A may begin with application receiving a challenge <NUM>, which may include random data or some other value supplied by remote server <NUM> in order to prevent a potential replay attack. As shown, application <NUM> may then convey the challenge <NUM> along with the user identifier <NUM> in a request <NUM> to obtain an attestation <NUM>. In the illustrated embodiment, request <NUM> does not include metadata <NUM> as this was verified in enrollment. In other embodiments, however, metadata <NUM> may be included in request <NUM> and verified by SEP <NUM>. In response to receiving request <NUM>, SEP <NUM> may retrieve the appropriate key <NUM> for application <NUM> based on user identifier <NUM> (or some other type of key index). SEP <NUM> may then use the key <NUM> to generate a digital signature from challenge <NUM> and provide the signature as attestation <NUM> to application <NUM>. Application <NUM> may then provide key certificate <NUM> and attestation <NUM> to remote server <NUM>, which verifies attestation <NUM> using key certificate <NUM>. If the verification is successful (meaning that application <NUM> has been verified by SEP <NUM> as corresponding to application certificate <NUM>), remote server <NUM> may proceed to provide a requested service to application <NUM>.

Turning now to <FIG>, a block diagram of an interaction 200B to obtain an attestation <NUM> generated by server <NUM> is depicted. As discussed above with interaction 200A, interaction 200B may include an enrollment exchange 202B and one or more usage exchanges 204B. In the illustrated embodiment, enrollment exchange 202B includes application <NUM> sending an enrollment request <NUM> to SEP <NUM>, which signs the request <NUM> using a request key <NUM> and sends the request on to server <NUM>. As shown, in some embodiments, request <NUM> includes metadata <NUM> and a user identifier <NUM>, which are verified by server <NUM>. As noted above, in some embodiments, metadata <NUM> and/or user identifier <NUM> may be obfuscated (e.g., through hashing this information) to prevent server <NUM> from knowing, for example, application identifier <NUM>. In response to a successful verification, server <NUM> may return a key certificate <NUM> to application <NUM>. In the illustrated embodiment, usage exchange 204B includes application <NUM> sending a request <NUM> to SEP <NUM>, which signs the request using a request key <NUM> and sending it on to server <NUM>. In some embodiments, this request <NUM> includes user identifier <NUM> and challenge <NUM> (and metadata <NUM> in some embodiments, which may be obfuscated). In response to receiving request <NUM> (and performing another verification in some embodiments), server <NUM> may generate an attestation <NUM> by signing challenge <NUM> (or information included challenge <NUM>). Server <NUM> may then return the generated attestation <NUM> to application <NUM>, which may deliver the attestation <NUM> along with the key certificate <NUM> to remote server <NUM>.

Turning now to <FIG>, a block diagram of an interaction 200C to obtain an attestation <NUM> generated by SEP <NUM> and associated with an application generated key is depicted. In the illustrated embodiment, interaction 200C includes an enrollment exchange 202C in which application <NUM> sends an enrollment request <NUM> as discussed above, and SEP <NUM> uses key request <NUM> to sign content in request <NUM>, such as metadata <NUM> and user ID <NUM>. This signed content may then be conveyed to server <NUM> for verification. In response to a successful verification, server <NUM> may issue a certificate certifying application key <NUM>. As part of performing enrollment exchange 202C, however, application <NUM> may also generate a cryptographic key (shown as application generated key <NUM>), which it may use in its interaction with remote server <NUM>. In the illustrated embodiment, application <NUM> further sends a certificate request <NUM> asking SEP <NUM> to issue a corresponding certificate <NUM> for application generated key <NUM>. (Although depicted separately for illustration purposes, certificate request <NUM> may be a part of enrollment request <NUM> or sent in conjunction with enrollment request <NUM> in some embodiments. ) In some embodiments, SEP <NUM> uses newly certified application key <NUM> to sign requested key certificate <NUM>. During usage exchange 204C, SEP <NUM> may use application key <NUM>, as discussed above, to generate an attestation <NUM> for an issued challenge <NUM>. Usage exchange 204C, however, may further include application <NUM> providing certificate <NUM> for application generated key <NUM> and using key <NUM> for some purpose. In the illustrated embodiment, application generated key <NUM> is used to establish a secure exchange <NUM> with remote server <NUM>, such as using key <NUM> in an elliptic-curve Diffie-Hellman (ECDH) exchange to establish a shared key; however, in other embodiments, application generated key <NUM> may be used by application <NUM> for various other purposes.

Turning now to <FIG>, a block diagram of an interaction 200D to obtain an attestation <NUM> generated by OS <NUM> is depicted. In the illustrated embodiment, attestation server <NUM> performs the verification of metadata <NUM>, but OS <NUM> generates attestation <NUM>. As shown, interaction 200D may include an enrollment exchange 202D, which may proceed in a similar manner as exchange 202B with the conveyance of request <NUM> and key certificate <NUM>. In the illustrated embodiment, however, attestation server <NUM> generates a public key pair and provides the private application key <NUM> for use in a subsequent usage exchange 204D. Accordingly, when application <NUM> issues a subsequent request <NUM> in exchange 204D, OS <NUM> uses the private key <NUM> to generate attestation <NUM> such as discussed above.

Turning now to <FIG>, a block diagram of an interaction 200E to obtain an attestation <NUM> generated by OS <NUM> and using a certified application key <NUM> is depicted. In the illustrated embodiment, OS <NUM> (or SEP <NUM> in other embodiments) generates a public key pair such that application key <NUM> is the private key of the pair. During exchange 202E, OS <NUM> includes, in request <NUM>, the public key <NUM> of the pair in request <NUM> and a signature generated from private application key <NUM>. Although not shown, this request <NUM> may be further signed by SEP <NUM>. Server <NUM> may then verify the request <NUM> and issue a corresponding certificate <NUM> for the application <NUM> in response to the verification being successful. This verification may be implemented in a similar manner as discussed above with respect to other figures. In some embodiments, server <NUM> limits the number of valid certificates <NUM> issued to device <NUM> for a particular application <NUM> at a given time. As such, this verification may include verifying that the number of issued certificates <NUM> does not exceed a threshold (such the one identified by key threshold <NUM>) before issuing a new certificate <NUM>. In some embodiments, certificates <NUM> may be assigned a short validity period when application private keys <NUM> are maintained by OS <NUM> to further limit the number of valid certificates <NUM>. When a usage exchange 204E is later performed, OS <NUM> uses the certified application key <NUM> to generate attestation <NUM> and provides it along with the certificate <NUM> to server <NUM> for verification.

In various embodiments, an enrollment exchange <NUM> may be performed on demand as an application <NUM> issues a request <NUM> and/or an older issued key certificate <NUM> expires. In some instances, this may result in a large number of requests <NUM> being sent to server <NUM> when multiple applications <NUM> on multiple devices <NUM> are requesting attestations <NUM>. In other embodiments, multiple requests <NUM> may be grouped together and issued as a periodic batch request to server <NUM>. For example, OS <NUM> may convey a single batch request once a day for all key certificates <NUM> requested by applications <NUM>. This asynchronous approach may result in fewer requests being received by server <NUM>. In some embodiments, OS <NUM> may further track when an attestation <NUM> associated with a particular application key <NUM> was last generated. If a particular amount of time (e.g., thirty days) has passed since an attestation <NUM> associated with the particular application key <NUM> was issued, OS <NUM> may forgo asking for a renewal of a certificate <NUM> in an upcoming batch request. If the corresponding application <NUM> later asks for an attestation <NUM> after the certificate <NUM> has expired and/or its corresponding private key <NUM> has potentially been deleted, OS <NUM> may issue a request <NUM> on demand for a renewed certificate <NUM> (or, in another embodiment, plan to include the request in the next batch request sent to server <NUM>). In some embodiments, rather than generate a new application key <NUM>, OS <NUM> may request a renewed certificate <NUM> for an already existing, previously certified application key <NUM> in order to reduce the number of instances in which new keys <NUM> are generated-assuming that such a key <NUM> is still available and has not been deleted. If, however, a key <NUM> is has been deleted, OS <NUM> may generate a new key <NUM> and request a new certificate <NUM>.

Turning now to <FIG>, a block diagram of SEP <NUM> is depicted. In the illustrated embodiment, SEP <NUM> includes a filter <NUM>, secure mailbox mechanism <NUM>, processor <NUM>, secure ROM <NUM>, cryptographic engine <NUM>, a key storage <NUM>, and a biosensor pipeline <NUM> coupled together via an interconnect <NUM>. In some embodiments, SEP <NUM> may include more (or less) components than shown in <FIG>. As noted above, SEP <NUM> is a secure circuit having tamper resistance. As discussed below, SEP <NUM> implements tamper resistance through the use of filter <NUM> and secure mailbox <NUM>.

Filter <NUM> is circuitry configured to tightly control access to SEP <NUM> to increase the isolation of the SEP <NUM> from the rest of computing device <NUM>, and thus the overall security of the device <NUM>. More particularly, in one embodiment, filter <NUM> may permit read/write operations from a CPU <NUM> (or other peripherals coupled to interconnect <NUM>) to enter SEP <NUM> only if the operations address the secure mailbox <NUM>. Other operations may not progress from the interconnect <NUM> into SEP <NUM>. Even more particularly, filter <NUM> may permit write operations to the address assigned to the inbox portion of secure mailbox <NUM>, and read operations to the address assigned to the outbox portion of the secure mailbox <NUM>. All other read/write operations may be prevented/filtered by the filter <NUM>. In some embodiments, filter <NUM> may respond to other read/write operations with an error. In one embodiment, filter <NUM> may sink write data associated with a filtered write operation without passing the write data on to local interconnect <NUM>. In one embodiment, filter <NUM> may supply nonce data as read data for a filtered read operation. Nonce data (e.g., "garbage data") may generally be data that is not associated with the addressed resource within the SEP <NUM>. Filter <NUM> may supply any data as nonce data (e.g. all zeros, all ones, random data from a random number generator, data programmed into filter <NUM> to respond as read data, the address of the read transaction, etc.).

In various embodiments, filter <NUM> may only filter incoming read/write operations. Thus, the components of the SEP <NUM> may have full access to the other components of computing device <NUM> such as memory <NUM>. Accordingly, filter <NUM> may not filter responses from interconnect <NUM> that are provided in response to read/write operations issued by SEP <NUM>.

Secure mailbox <NUM> is circuitry that, in some embodiments, includes an inbox and an outbox. Both the inbox and the outbox may be first-in, first-out buffers (FIFOs) for data. The buffers may have any size (e.g. any number of entries, where each entry is capable of storing data from a read/write operation). Particularly, the inbox may be configured to store write data from write operations sourced from interconnect <NUM>. The outbox may store write data from write operations sourced by processor <NUM>. (As used herein, a "mailbox mechanism" refers to a memory circuit that temporarily stores <NUM>) an input for a secure circuit until it can be retrieved by the circuit and/or <NUM>) an output of a secure circuit until it can be retrieved by an external circuit.

In some embodiments, software executing on CPU <NUM> may request services of SEP <NUM> via an application programming interface (API) supported by OS <NUM>-i.e., a requester may make API calls that request services of SEP <NUM>. These calls may cause corresponding requests to be written to mailbox mechanism <NUM>, which are then retrieved from mailbox <NUM> and analyzed by processor <NUM> to determine whether it should service the requests. Accordingly, this API may be used to facilitate, for example, exchanges <NUM> and <NUM> via mailbox <NUM>. By isolating SEP <NUM> in this manner, integrity of SEP <NUM> may be enhanced.

SEP processor <NUM> is configured to process commands received from various sources in computing device <NUM>. Processor <NUM> may then execute instructions stored in ROM <NUM> in order to implement functionality described herein with respect to SEP <NUM>, which may include use various secure peripherals to accomplish the commands. Accordingly, ROM <NUM> may include program instructions executable to performing operations using keys <NUM> or <NUM> discussed above. For example, ROM <NUM> may program instructions executable to verify application <NUM> and/or generate attestation <NUM>. In the illustrated embodiment, SEP processor <NUM> may execute an authentication application <NUM> to perform an authentication of a user and to provide appropriate commands to biosensor sensor pipeline <NUM> in order to verify biometric data <NUM> collected by a biosensor of device <NUM>. Such an authentication may be performed, for example, to unlock device <NUM>, authenticate a user of device <NUM> to application <NUM>, etc. In program instructions executable to some embodiments, program instructions executed by SEP processor <NUM> are signed by a trusted authority (e.g., device <NUM>'s manufacturer) in order to ensure their integrity.

Secure ROM <NUM> is a memory configured to store program instruction for booting SEP <NUM>. In some embodiments, ROM <NUM> may respond to only a specific address range assigned to secure ROM <NUM> on local interconnect <NUM>. The address range may be hardwired, and processor <NUM> may be hardwired to fetch from the address range at boot in order to boot from secure ROM <NUM>. Filter <NUM> may filter addresses within the address range assigned to secure ROM <NUM> (as mentioned above), preventing access to secure ROM <NUM> from components external to the SEP <NUM>. In some embodiments, secure ROM <NUM> may include other software executed by SEP processor <NUM> during use. This software may include the program instructions to process inbox messages and generate outbox messages, etc..

Cryptographic engine <NUM> is circuitry configured to perform cryptographic operations for SEP <NUM>, including key generation as well as encryption and decryption using keys in key storage <NUM>. Cryptographic engine <NUM> may implement any suitable encryption algorithm such as Data Encryption Standard (DES), Advanced Encryption Standard (AES), Rivest Shamir Adleman (RSA), etc. In some embodiments, engine <NUM> may further implement elliptic curve cryptography (ECC). In some embodiments, engine <NUM> is configured to use keys <NUM> to generate attestation <NUM>. In other embodiments, engine <NUM> is configured to use keys <NUM> to sign requests <NUM> and/or <NUM> as discussed above.

Key storage <NUM> is a local memory (i.e., internal memory) configured to store cryptograph keys. As shown, in some embodiments, storage <NUM> includes keys <NUM> or <NUM>. Storage <NUM> may also include various metadata <NUM> about keys <NUM> or <NUM> and usable to retrieve keys <NUM> or <NUM> such as their associated application identifiers, user identifiers, etc. Key storage <NUM> may include any type of memory such as the various examples of volatile or non-volatile memory listed below with respect to <FIG>. In some embodiments, storage <NUM> may also include a set of fuses that are burnt during a fabrication of SEP <NUM> (or more generally device <NUM>) in order to record keys such as a UID key. Although depicted as residing in storage <NUM>, keys <NUM> or <NUM> may be stored externally to SEP <NUM>, but encrypted by one or more keys maintained by SEP <NUM>, which may be stored in storage <NUM>.

Biosensor sensor pipeline <NUM>, in one embodiment, is circuitry configured to compare biometric data <NUM> captured by a biosensor from a user being authenticated with biometric data <NUM> of an authorized user. (In another embodiment, data <NUM> and <NUM> may be compared by software such as authentication application <NUM>. ) Biometric data may be data that uniquely identifies the user among other humans (at least to a high degree of accuracy) based on the user's physical or behavioral characteristics. In some embodiments in which data <NUM> is collected from a user's face, pipeline <NUM> may perform the comparison using a collection of neural networks included in pipeline <NUM>, each network being configured to compare biometric data <NUM> captured in a single frame with biometric data <NUM> captured in multiple frames for an authorized user. As shown, pipeline <NUM> may be configured to read, from memory <NUM>, biometric data <NUM>, which may be protected by encryption in some embodiments and/or be stored in an associated part of memory <NUM> that is only accessible to SEP <NUM>. (In another embodiment, SEP <NUM> may store data <NUM> internally. ) Based on the comparison of biometric data <NUM> and <NUM>, SEP <NUM> may provide an authentication result indicating whether the authentication was successful or failed.

Turning now to <FIG>, a flow diagram of a method <NUM> is depicted. Method <NUM> is one embodiment of a method performed by a computing device executing an application such as a computing device <NUM>. In many instances, performance of method <NUM> may ensure execution of valid applications.

In step <NUM>, the computing device receives, from an application (e.g., application <NUM>), a request (e.g., request <NUM>) for an attestation (e.g., attestation <NUM>) usable to confirm an integrity of the application.

In step <NUM>, the computing device instructs a secure circuit (e.g., SEP <NUM>) to use one (e.g., an application key <NUM> or a request key <NUM>) of a plurality of maintained cryptographic keys to supply the attestation for the application. In some embodiments, the secure circuit verifies received metadata (e.g., metadata <NUM>) pertaining to the integrity of the application and uses the cryptographic key to generate the attestation indicative of the integrity of the application. In various embodiments, the metadata includes a certificate (e.g., application certificate <NUM>) identifying a hash value (e.g., hash value <NUM>) signed by a developer of the application. In some embodiments, the secure circuit performs a comparison of the signed hash value and a hash value generated from the application in response to the received request. In some embodiments, the secure circuit generates a public key pair unique to the application such that the cryptographic key is a private key of the public key pair. In some embodiments, the secure circuit provides, to the application, a certificate (e.g., key certificate <NUM>) including a public key of the public key pair, the public key being usable by the remote computing system to verify the attestation. In some embodiments, the certificate includes an identifier of the application (e.g., application identifier <NUM>) and a hash value (e.g., hash value <NUM>) generated from the application. In some embodiments, the secure circuit receives a challenge (e.g., challenge <NUM>) issued by the remote computing system to the application to authenticate the application and generates the attestation by signing the challenge with the private key. In some embodiments, the public key pair is for a particular user of the computing device, and the request for an attestation identifies the particular user. In some embodiments, the secure circuit receives an application certificate (e.g., application certificate <NUM>) from a developer of the application, and the application certificate identifies a threshold number of users (e.g., key threshold <NUM>) for which public key pairs are permitted to be generated. In such an embodiment, the secure circuit verifies that generating the public key pair complies with the threshold number of users. In some embodiments, an operating system verifies metadata (e.g., metadata <NUM>) obtained from the application and pertaining to the integrity of the application, and the operating system performs the instructing based on the verified metadata. In some embodiments, the secure circuit uses the cryptographic key to establish a connection (e.g., by signing request <NUM>) with a server configured to generate the attestation and receives the generated attestation from the server.

In step <NUM>, the computing device provides the attestation to a remote computing system (e.g., remote server <NUM>) in communication with the application.

Turning now to <FIG>, a flow diagram of a method <NUM> is depicted. Method <NUM> is one embodiment of a method performed by an application attesting to its validity such as application <NUM>. In many instances, performance of method <NUM> may ensure execution of valid applications.

In step <NUM>, the application sends a request (e.g., request <NUM>) for an attestation (e.g., attestation <NUM>) indicating that the application has been verified.

In step <NUM>, the application supplies metadata (e.g., metadata <NUM>) indicative of an identity of the application. In some embodiments, the metadata is supplied to a secure circuit (e.g., SEP <NUM>), and the secure circuit is configured to verify the metadata in response to the request. In some embodiments, the supplying includes supplying a signed hash value (e.g., signed hash value <NUM>) generated by a developer for an authorized copy of the application, and the secure circuit is configured to verify the hash value prior to generating the attestation.

In step <NUM>, the application receives the requested attestation from a secure circuit of the computing device, the secure circuit being configured to provide the requested attestation based on a verification of the supplied metadata. In some embodiments, the received attestation is signed using a cryptographic key (e.g., application key <NUM>) maintained by the secure circuit for the application. In some embodiments, the cryptographic key is one of a plurality of keys maintained by the secure circuit, and the request for the attestation includes an index value (e.g., user identifier <NUM>) usable by the secure circuit to identify the cryptographic key.

In step <NUM>, the application uses the received attestation to establish a connection with a remote server (e.g., remote server <NUM>).

Turning now to <FIG>, a flow diagram of a method <NUM> is depicted. Method <NUM> is one embodiment of a method performed by a server system generating an attestation for an application such as attestation server <NUM>. In many instances, performance of method <NUM> may ensure execution of valid applications.

In step <NUM>, the server system receives, from a secure circuit (e.g., SEP <NUM>) in a computing device (e.g., device <NUM>), a signed request (e.g., signed request <NUM>) to provide an attestation (e.g., attestation <NUM>) for an application (e.g., application <NUM>) executing on the computing device. In various embodiments, the attestation is usable to confirm that the application is valid. In various embodiments, the server system maintains a plurality of cryptographic keys (e.g., application keys <NUM>) for generating attestations for the computing device. In some embodiments, each of the plurality of cryptographic keys is associated with a respective application executing on a computing device. In some embodiments, the server system receives, from the secure circuit, a request (e.g., a signed request <NUM>) to generate the cryptographic key for the application and, prior to generating the cryptographic key, the server system verifies that generating the cryptographic key complies with a limit set by a developer of the application. In such an embodiment, the limit (e.g., key threshold <NUM>) is a number of cryptographic keys permitted to be generated for the application.

In step <NUM>, the server system generates the requested attestation using a cryptographic key maintained by the server system. In some embodiments, prior to generating the requested attestation, the server system verifies metadata (e.g., metadata <NUM>) supplied with the request and pertaining to an identity of the application. In some embodiments, the server system receives, from the secure circuit, an indication that metadata supplied by the application pertaining to an identity of the application has been verified and generates the attestation in response to the indication.

In step <NUM>, the server system sends the generated attestation to the computing device. In various embodiments, the attestation is used by the application to establish a communication with service (e.g., provided by remote server <NUM>).

Turning now to <FIG>, a flow diagram of a method <NUM> is depicted. Method <NUM> is one embodiment of a method performed by a computing device generating an attestation using a key certified by another computer system. In many instances, performance of method <NUM> may ensure execution of valid applications.

In step <NUM>, the computing device receives, from a first computing system (e.g., attestation server <NUM>), a certificate (e.g., certificate <NUM>) for a cryptographic key (e.g., application key <NUM>) usable to generate an attestation (e.g., attestation <NUM>) indicating that an application (e.g., application <NUM>) has been verified. In various embodiments, the computing device performs an enrollment (e.g., enrollment <NUM>) for the application including generating, for the application, a public key pair including the cryptographic key as a private key of the public key pair and sending a request for the certificate to the first computing system, the request including a public key (e.g., public key <NUM>) of the public key pair and a signature generated by the private key. In some embodiments, the performing includes requesting a secure circuit (e.g., SEP <NUM>) to sign the request (e.g., using a request key <NUM>) prior to sending the request to the first computing system.

In step <NUM>, the computing device receives, from the application, a request (e.g., request <NUM>) to generate the attestation.

In step <NUM>, in response to a verification of the application, the computing device uses the cryptographic key to generate the requested attestation. In some embodiments, the attestation is generated by an operating system (e.g., OS <NUM>) of the computing device. In some embodiments, the attestation is generated by a secure circuit (e.g., SEP <NUM>) of the computing device.

In step <NUM>, the computing device provides the generated attestation and the received certificate to a second computing system (e.g., remote system <NUM>) interfacing with the application. In some embodiments, method <NUM> includes generating a plurality of cryptographic keys usable to generate attestations for the application, each of the plurality of cryptographic keys being associated with a respective user of the application. In some embodiments, the computing device limits a number of cryptographic keys generated for users of the application based on a threshold value (e.g., key threshold <NUM>) specified by a developer of the application. In some embodiments, the limiting includes removing a previously generated key for a particular user in response to determining to generate a new key for the particular user. In some embodiments, the computing device (or the first computing system) limits a number of certificates issued with respect to the application at a given time.

Turning now to <FIG>, a block diagram illustrating an exemplary embodiment of a computing device <NUM>, which may implement functionality of computing device <NUM>, server <NUM>, and/or server <NUM>, is shown. Device <NUM> may correspond to any suitable computing device such as a server system, personal computer system, desktop computer, laptop or notebook computer, mainframe computer system, tablet computer, handheld computer, workstation, network computer, a mobile phone, music player, personal data assistant (PDA), wearable device, internet of things (IoT) device, etc. In some embodiments, elements of device <NUM> may be included within a system on a chip (SOC). In the illustrated embodiment, device <NUM> includes fabric <NUM>, processor complex <NUM>, graphics unit <NUM>, display unit <NUM>, cache/memory controller <NUM>, input/output (I/O) bridge <NUM>.

Fabric <NUM> may include various interconnects, buses, MUX's, controllers, etc., and may be configured to facilitate communication between various elements of device <NUM>. In some embodiments, portions of fabric <NUM> may be configured to implement various different communication protocols. In other embodiments, fabric <NUM> may implement a single communication protocol and elements coupled to fabric <NUM> may convert from the single communication protocol to other communication protocols internally. As used herein, the term "coupled to" may indicate one or more connections between elements, and a coupling may include intervening elements. For example, in <FIG>, graphics unit <NUM> may be described as "coupled to" a memory through fabric <NUM> and cache/memory controller <NUM>. In contrast, in the illustrated embodiment of <FIG>, graphics unit <NUM> is "directly coupled" to fabric <NUM> because there are no intervening elements.

In the illustrated embodiment, processor complex <NUM> includes bus interface unit (BIU) <NUM>, cache <NUM>, and cores 526A and 526B. In various embodiments, processor complex <NUM> may include various numbers of processors, processor cores and/or caches. For example, processor complex <NUM> may include <NUM>, <NUM>, or <NUM> processor cores, or any other suitable number. In one embodiment, cache <NUM> is a set associative L2 cache. In some embodiments, cores 526A and/or 526B may include internal instruction and/or data caches. In some embodiments, a coherency unit (not shown) in fabric <NUM>, cache <NUM>, or elsewhere in device <NUM> may be configured to maintain coherency between various caches of device <NUM>. BIU <NUM> may be configured to manage communication between processor complex <NUM> and other elements of device <NUM>. Processor cores such as cores <NUM> may be configured to execute instructions of a particular instruction set architecture (ISA), which may include operating system instructions for OS <NUM> and user application instructions for application <NUM>. These instructions may be stored in computer readable medium such as a memory coupled to memory controller <NUM> discussed below. In some embodiments, complex <NUM> corresponds to CPU <NUM>.

Graphics unit <NUM> may include one or more processors and/or one or more graphics processing units (GPU's). Graphics unit <NUM> may receive graphics-oriented instructions, such as OPENGL®, Metal, or DIRECT3D® instructions, for example. Graphics unit <NUM> may execute specialized GPU instructions or perform other operations based on the received graphics-oriented instructions. Graphics unit <NUM> may generally be configured to process large blocks of data in parallel and may build images in a frame buffer for output to a display. Graphics unit <NUM> may include transform, lighting, triangle, and/or rendering engines in one or more graphics processing pipelines. Graphics unit <NUM> may output pixel information for display images.

Display unit <NUM> may be configured to read data from a frame buffer and provide a stream of pixel values for display. Display unit <NUM> may be configured as a display pipeline in some embodiments. Additionally, display unit <NUM> may be configured to blend multiple frames to produce an output frame. Further, display unit <NUM> may include one or more interfaces (e.g., MIPI® or embedded display port (eDP)) for coupling to a user display (e.g., a touchscreen or an external display).

Cache/memory controller <NUM> may be configured to manage transfer of data between fabric <NUM> and one or more caches and/or memories. For example, cache/memory controller <NUM> may be coupled to an L3 cache, which may in turn be coupled to a system memory. In other embodiments, cache/memory controller <NUM> may be directly coupled to a memory. In some embodiments, cache/memory controller <NUM> may include one or more internal caches. Memory coupled to controller <NUM> may be any type of volatile memory, such as dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR3, etc.) SDRAM (including mobile versions of the SDRAMs such as mDDR3, etc., and/or low power versions of the SDRAMs such as LPDDR4, etc.), RAMBUS DRAM (RDRAM), static RAM (SRAM), etc. One or more memory devices may be coupled onto a circuit board to form memory modules such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc. Alternatively, the devices may be mounted with an integrated circuit in a chip-on-chip configuration, a package-on-package configuration, or a multi-chip module configuration. Memory coupled to controller <NUM> may be any type of non-volatile memory such as NAND flash memory, NOR flash memory, nano RAM (NRAM), magneto-resistive RAM (MRAM), phase change RAM (PRAM), Racetrack memory, Memristor memory, etc. As noted above, this memory may store program instructions executable by processor complex <NUM> to cause device <NUM> to perform functionality described herein.

I/O bridge <NUM> may include various elements configured to implement universal serial bus (USB) communications, security, audio, and/or low-power always-on functionality, for example. I/O bridge <NUM> may also include interfaces such as pulse-width modulation (PWM), general-purpose input/output (GPIO), serial peripheral interface (SPI), and/or inter-integrated circuit (I2C), for example. Various types of peripherals and devices may be coupled to device <NUM> via I/O bridge <NUM>. For example, these devices may include various types of wireless communication (e.g., wifi, Bluetooth, cellular, global positioning system, etc.), additional storage (e.g., RAM storage, solid state storage, or disk storage), user interface devices (e.g., keyboard, microphones, speakers, etc.), etc..

Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

Various embodiments described herein may gather and/or use data available from specific and legitimate sources to improve the delivery to users of invitational content or any other content that may be of interest to them. The present disclosure contemplates that, in some instances, this gathered data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data can include demographic data, location-based data, online identifiers, telephone numbers, email addresses, home addresses, data or records relating to a user's health or level of fitness (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information.

The present disclosure recognizes that the use of such personal information data, in the present technology, can be used to the benefit of users. For example, the personal information data can be used to deliver targeted content that may be of greater interest to the user in accordance with their preferences. Accordingly, use of such personal information data enables users to have greater control of the delivered content. Further, other uses for personal information data that benefit the user are also contemplated by the present disclosure. For instance, health and fitness data may be used, in accordance with the user's preferences to provide insights into their general wellness, or may be used as positive feedback to individuals using technology to pursue wellness goals.

Despite the foregoing, the present disclosure also contemplates embodiments in which users selectively block the use of, or access to, personal information data. That is, the present disclosure contemplates that hardware and/or software elements can be provided to prevent or block access to such personal information data. For example, in the case of advertisement delivery services, the present technology can be configured to allow users to select to "opt in" or "opt out" of participation in the collection of personal information data during registration for services or anytime thereafter. In another example, users can select not to provide mood-associated data for targeted content delivery services. In yet another example, users can select to limit the length of time mood-associated data is maintained or entirely block the development of a baseline mood profile. In addition to providing "opt in" and "opt out" options, the present disclosure contemplates providing notifications relating to the access or use of personal information. For instance, a user may be notified upon downloading an app that their personal information data will be accessed and then reminded again just before personal information data is accessed by the app.

Claim 1:
A computing device (<NUM>), comprising:
a secure circuit (<NUM>) configured to maintain a plurality of cryptographic keys (<NUM>, <NUM>) of the computing device (<NUM>);
a processor (<NUM>);
memory (<NUM>) having program instructions stored therein that are executable by the processor (<NUM>) to cause the computing device (<NUM>) to perform operations including:
receiving (<NUM>), from an application (<NUM>), a request (<NUM>) for an attestation (<NUM>) usable to confirm an integrity of the application;
instructing (<NUM>) the secure circuit (<NUM>) to use one of the plurality of cryptographic keys (<NUM>, <NUM>) to supply the attestation (<NUM>) for the application (<NUM>) based on verification of the integrity of the application (<NUM>),
wherein the verification includes:
the secure circuit receiving an application certificate identifying a hash value generated from program instructions of a valid copy of the application and signed by a developer of the application; and
the secure circuit performing a comparison of the signed hash value and a hash value generated from program instructions of the requesting application in response to the received request; and
providing (<NUM>) the attestation (<NUM>) to a remote computing system (<NUM>) in communication with the application (<NUM>).