Patent Application
20230289787
This disclosure relates generally to processors, and, more specifically, to processors that use public key encryption.
Many people now prefer to visit online stores to make purchases because of the added convenience over visiting traditional brick and mortar stores. When visiting an online store, a user may view multiple items, which can be added to a shopping cart for later review and eventual check out. To expedite the purchasing process, an online store may maintain shipping information and/or payment information for a user, so that the user does not have to reenter this information for each purchase. In order to protect this information, a user is typically asked to authenticate by providing some user credential such as a user name and password.
In various embodiments, a computing device is disclosed that includes a secure circuit usable to facilitate authenticating a user. The secure circuit may be configured to generate a public key pair usable to authenticate a user of the computing device. The computing device may authenticate the user with a server system by sending authentication information supplied by the user to the server system. In response to the server system verifying the authentication information, the computing device may receive a first token usable to register the public key pair with the server system. The computing device may send, to the server system, a request to register the public key pair for authenticating the user, and the request may include the first token and identify a public key of the public key pair. In some embodiments, the computing device performs a subsequent authentication for the user that includes receiving a challenge from the server system, requesting that the secure circuit generate, with a private key of the public key pair, a digital signature for the challenge, and providing the digital signature to the server system in a response to the challenge.
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 perform a cryptographic operation” 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 35 U.S.C. § 112(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 112(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, in a processor having eight processing cores, the terms “first” and “second” processing cores can be used to refer to any two of the eight processing cores. In other words, the “first” and “second” processing cores are not limited to physical processing cores 0 and 1, for example.
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 is 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 present disclosure describes embodiments in which a user may authenticate with an entity via a digital signature generated by a secure circuit in the user's computing device (as opposed to repeatedly being required to enter a credential each time the user wants to authenticate with the entity). As will be described in greater detail below, in various embodiments, the computer device may perform a registration process for a public key pair generated by the secure circuit in order to begin authenticating using a digital signature generated by a private key of the pair. The process may begin with the computing device establishing trust with a server system of the entity by presenting authentication information of the user to the server system. After the server system successfully verifies this information, the server system may generate an indication that trust has been established with the computing device and, in some embodiments, may present the indication as a token to the computing device (or store it in the system in other embodiments). In response to receiving this token, the computing device submit a request to register a public key pair generated by the secure circuit in the device. This request may include the token and information indicative of the public key of the pair (e.g., the public key or a hash of the public key). After verifying the token, the server system may register the public key pair allowing the computing device to later generate a digital signature in order to authenticate the user.
In some embodiments, this registration process may be performed within the context of making a purchase using the computing device. That is, a user may establish trust with the server system when attempting to make a purchase, and the user's computing device may receive a token allowing the computing device to register a public key pair. In other words, the computing device may leverage the trust established to authorize a purchase in order to register a public key pair. This public key pair may then be used to authenticate for making future purchases.
In various embodiments, the computing device restricts access to generating digital signatures by using a biosensor included in the computing device. In such an embodiment, the biosensor may be configured to collect biometric information from a biometric credential presented by the user—e.g., fingerprint information from the user's finger. The biosensor may present this information to the secure circuit, which compares the information against previously stored biometric information of the user. If a match is detected, the secure circuit may generate a digital signature for authenticating the user. If a match is not detected, the secure circuit may decline a request to generate the digital signature.
Examples of the registration process is described in greater detail below with respect to
Turning now to
Payment application 122, in one embodiment, is an application that allows a user to request payments for various purchases. In some embodiments, application 122 may present a store front that offers products and/or services available for purchase. For example, in one embodiment, application 122 may present various digital content available for purchase such as music, videos, books, and/or applications. Once a user has selected a particular item for purchase, application 122 may communicate with payment system 140 in order to facilitate payment for the purchase.
Payment system 140, in one embodiment, is a server system (i.e., a collection of one or more server computers) that processes payment requests from an application 122. In various embodiments, system 140 may maintain various payment information about a user, such as a user's billing address and credit card information, in order to facilitate processing a payment request. When a user wants to submit payment for a purchase, an application 122 may present authentication information for the user in order to use the existing payment information stored in system 140. In some embodiments, this authentication information may include a user name and password entered into computing device 100 via a touch screen of device 100, keyboard, or other form of interface. If system 140 is able to successfully verify this information, system 140 may allow the previously stored payment information to be used in making a payment for a purchase. As will be discussed below, in various embodiments, system 140 may allow a payment application 122 to register a public key pair for authenticating instead of asking the user to renter his or her authentication information for each purchase.
Secure enclave processor (SEP) 114 is one embodiment of a secure circuit or a secure component configured to generate and maintain a public key pair, which may be used for authentication. As used herein, the term “secure circuit” refers to a circuit that protects an isolated, internal resource from being directly accessed by an external circuit. This internal resource may be memory that stores sensitive data such as personal information (e.g., biometric information, credit card information, etc.), encryptions keys, random number generator seeds, etc. This internal resource may also be circuitry that performs services/operations associated with sensitive data. As will be described below, these services may include various cryptographic services such as authentication, encryption, decryption, etc. Secure services may include secure key generation, which may include shared secret keys and asymmetric keys (i.e., public and private keys). In some embodiments, SEP 114 may determine whether to perform a requested operation, such as generating a digital signature, based on biometric information collected by biosensor 130 in order to confirm that the requested operation is associated with an authorized user.
Biosensor 130, in one embodiment, is configured to detect biometric data for a user of computing device 100. 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. For example, in some embodiments, sensor 130 is a finger print sensor that captures fingerprint data from the user. In one embodiment, SEP 114 may maintain previously captured fingerprint data of an authorized user and compare it against newly received fingerprint data from sensor 130 in order to authenticate a user. (In another embodiment, biosensor 130 may perform the comparison.) If the fingerprint data matches, SEP 114 may permit performance of a requested service. In some embodiments, communications between SEP 114 and biosensor 130 may be encrypted using a key shared between SEP 114 and biosensor 130 such that another circuit (e.g., CPU 112) is unable to view communicated fingerprint data. In some embodiments, other types of biometric data may be captured by sensor 130 such as voice recognition (identifying the particular user's voice), iris scanning, etc. It is noted that SEP 114 may also compare information collected from sources other than sensor 130 in order to verify the identity of a user, in some embodiments. Accordingly, computing device 100 may include other user interface circuits (e.g., a touch screen) configured to receive authentication information (e.g., a passcode or password) from a user, and SEP 114 may verify that the received authentication information is correct.
In various embodiments, payment application 122 may perform a registration process for a public key pair generated by SEP 114 in order to allow a user to subsequently authenticate with payment system 140 using a digital signature generated by a private key of the pair and without having to provide a user name and password. In the illustrated embodiment, this registration process includes the communication of elements 141-146 discussed below. It is noted, while various authentication techniques are described herein within the context of facilitating payment processing, these techniques may also be used in other embodiments in which authentication is used for some purpose other than making a purchase.
As shown, the registration process may begin with payment application 122 communicating user authentication information 141 to payment system 140 in order to establish trust between computing device 100 and payment system 140. As will be discussed below with respect to
Authenticated token 142, in one embodiment, is an indication that trust has been established with payment system 140—e.g., that the user has been authenticated. In some embodiments, token 142 may include a portion (or all) of information 141, which has been signed by system 140. Although shown in
In response to receiving a token 142 (or in conjunction with sending information 141), payment application 122 may issue a key request 143 to SEP 114 to generate a public key pair to be registered with payment system 140. In some embodiments, a key request 143 may be issued after a user has requested to authenticate with a biometric credential. In response to receiving a request 143, SEP 114 may generate the key pair and return the public key 144 of the pair. In some embodiments, SEP 114 may store the key pair with usage criteria indicating that the private key cannot be used to generate a digital signature without first confirming biometric information received from biosensor 130.
After receiving a public key 144 and a token 142, application 122 may issue a registration request 145 to payment system 140 in order to register the public key pair generated by SEP 114. In the illustrated embodiment, request 145 includes authenticated token 142 and public key 144. Notably, in including token 142, application 122 is leveraging the previous trust established earlier with the communication of information 141. In cases where information 141 was communicated to facilitate a purchase, application 122 does not have to ask the user to provide information 141 multiple times—e.g., once to initiate payment and again to register a public key pair. In some embodiments, request 145 may include (or be accompanied with) additional information such as a DSID, MID, a digital signature generated by a device key stored in SEP 114 that is separate from the public key pair, etc. In some embodiments, registration request 145 is a certificate signing request (CSR), which may be in compliance with a standard format such as defined by the public-key cryptography standards (PKCS) #10 specification. In such an embodiment, system 140 may act as a certificate authority (CA). In response to verifying the information in a request 145, payment system 140 may provide a corresponding registered key token 146.
Register key token 146, in one embodiment, indicates that a particular public key pair has been registered and may be used to verify a digital signature generated by the private key of the pair. As will be discussed below with
Turning now to
In the illustrated embodiment, the authentication process begins with a payment request 151 to initiate making payment for a purchase. In some embodiments, this request 151 may include the registration token 146 obtained during registration of the public key pair as discussed above. In other embodiments, this token may be submitted later such as with the challenge response 154. In response to receiving this request 151, payment system 140 may issue a corresponding challenge 152 to verify that device 100 is in possession of the previously registered public key pair. In some embodiments, this challenge includes random data, which may be derived using a pseudo-random number generator with the token 146 being used as a seed.
After receiving a challenge 152, payment application 122 may provide the challenge 152 to SEP 114 along with a request for SEP 114 to generate a signature 153 using the private key of the registered public key pair. Before generating the signature 153, SEP 114 may ask biosensor 130 to collect biometric information from a biometric credential supplied by the user in order to determine that an authorized user is present. Upon successfully confirming the biometric information, SEP 114 may generate the requested signature 153. Payment application 122 may then convey this signature 153 in a response 154 to the challenge 152. If payment system 140 is able to successfully determine that the signature 153 is valid, payment system 140 may authorize payment for the requested purchase and notify payment application 122 that payment has been authorized by providing an indication 155.
Turning now to
Turning now to
Turning now to
Turning now to
Turning now to
Turning now to
Filter 510 is circuitry configured to tightly control access to SEP 114 to increase the isolation of the SEP 114 from the rest of the computing device 100, and thus the overall security of the device 100. More particularly, in one embodiment, filter 510 may permit read/write operations from a CPU 112 (or other peripherals on a fabric coupling CPU 112 and SEP 114) to enter SEP 114 only if the operations address the secure mailbox 520. Other operations may not progress from the fabric 150 into SEP 114. Even more particularly, filter 510 may permit write operations to the address assigned to the inbox portion of secure mailbox 520, and read operations to the address assigned to the outbox portion of the secure mailbox 520. All other read/write operations may be prevented/filtered by the filter 510. In some embodiments, filter 510 may respond to other read/write operations with an error. In one embodiment, filter 510 may sink write data associated with a filtered write operation without passing the write data on to local interconnect 570. In one embodiment, filter 510 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 114. Filter 510 may supply any data as nonce data (e.g. all zeros, all ones, random data from a random number generator, data programmed into filter 510 to respond as read data, the address of the read transaction, etc.).
In various embodiments, filter 510 may only filter incoming read/write operations. Thus, the components of the SEP 114 may have full access to the other components of computing device 100 including CPU 112, memory 120, and biosensor 130. Accordingly, filter 510 may not filter responses from fabric 150 that are provided in response to read/write operations issued by SEP 114.
Secure mailbox 520 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 CPU 112. The outbox may store write data from write operations sourced by processor 530. (As used herein, a “mailbox mechanism” refers to a memory circuit that temporarily stores 1) an input for a secure circuit until it can be retrieved by the circuit and/or 2) an output of a secure circuit until it can be retrieved by an external circuit.)
In some embodiments, software executing on CPU 112 (e.g., application 122) may request services of SEP 114 via an application programming interface (API) supported by an operating system of computing device 100—i.e., a requester may make API calls that request services of SEP 114. These calls may cause corresponding requests to be written to mailbox mechanism 520, which are then retrieved from mailbox 520 and analyzed by processor 530 to determine whether it should service the requests. Accordingly, this API may be used to request the generation of a public key pair as well as generation of a signature 153. By isolating SEP 114 in this manner, secrecy of maintained keys 562 and 564 may be enhanced.
SEP processor 530 is configured to process commands received from various sources in computing device 100 (e.g. from processor 112) and may use various secure peripherals to accomplish the commands. In the case of operations that involve keys 562 and 564, SEP processor 530 may provide appropriate commands to cryptographic engine 550 in order to perform those operations. In various embodiments, SEP processor 530 may execute securely loaded software that facilitates implementing functionality descried with respect to SEP 114. This software may include encrypted program instructions loaded from a trusted zone in memory 120.
Secure ROM 540 is a memory configured to program instruction for booting SEP 114. In some embodiments, ROM 540 may respond to only a specific address range assigned to secure ROM 540 on local interconnect 570. The address range may be hardwired, and processor 530 may be hardwired to fetch from the address range at boot in order to boot from secure ROM 540. Filter 510 may filter addresses within the address range assigned to secure ROM 540 (as mentioned above), preventing access to secure ROM 540 from components external to the SEP 114. In some embodiments, secure ROM 540 may include other software executed by SEP processor 530 during use. This software may include the program instructions to process inbox messages and generate outbox messages, code to interface to the cryptographic engine 310, etc.
Cryptographic engine 550 is circuitry configured to perform cryptographic operations for SEP 114, including key generation as well as encryption and decryption using keys in storage 560. Cryptographic engine 550 may implement any suitable encryption algorithm such as DES, AES, RSA, etc. In some embodiments, engine 550 may further implement elliptic curve cryptography (ECC). In various embodiments, engine 550 is responsible for generating signatures 153 discussed above.
Key storage 560 is a local memory (i.e., internal memory) configured to store keys. As shown, storage 560 may include a public key pair 562, which may be generated by engine 550 in order to produce digital signatures 153. Storage 560 may also include a device key 564 that is associated with computing device 100 and may be used to sign registration request 145. In some embodiments, storage 560 may use different techniques for the storage of keys. For example, in some embodiments, storage 560 may include a non-volatile memory for the storage of a key pair 562. In some embodiment, storage 560 includes a set of fuses that are burnt during a fabrication of SEP 114 (or more generally device 100) in order to record key 564.
Turning now to
Turning now to
Turning now to
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.
The present application is a continuation of U.S. application Ser. No. 15/275,281, entitled “AUTHENTICATION USING A SECURE CIRCUIT,” filed Sep. 23, 2016 (now U.S. Pat. No. 11,593,797), which claims priority to U.S. Provisional App. No. 62/349,053, entitled “AUTHENTICATION USING A SECURE CIRCUIT,” filed Jun. 12, 2016; the disclosures of each of the above-referenced applications are incorporated by reference herein in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| 62349053 | Jun 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15275281 | Sep 2016 | US |
| Child | 18174414 | US |
