PATENT DOCUMENT

Publication Number: US-10579997-B2
Application Number: US-201815941705-A
Country: US
Kind Code: B2

Title: Document importation into secure element

Abstract:
Techniques are disclosed relating to authenticate a user with a mobile device. In one embodiment, a computing device includes a short-range radio and a secure element. The computing device reads, via the short-range radio, a portion of credential information stored in a circuit embedded in an identification document issued by an authority to a user for establishing an identity of the user. The computing device issues, to the authority, a request to store the credential information, the request specifying the portion of the credential information. In response to an approval of the request, the computing device stores the credential information in the secure element, the credential information being usable to establish the identity of the user. In some embodiments, the identification document is a passport that includes a radio-frequency identification (RFID) circuit storing the credential information, and the request specifies a passport number read from the RFID circuit.

Claims:
What is claimed is: 
     
       1. A computing device, comprising:
 a short-range radio; 
 a secure circuit configured to authenticate of a user of the computing device; 
 a secure element that includes a first processor and a first memory; 
 a second processor; 
 a second memory having program instructions stored therein that are executable by the second processor to cause the computing device to perform operations including:
 reading, via the short-range radio, a portion of credential information stored in a circuit embedded in an identification document issued by an authority to the user for establishing an identity of the user; 
 issuing, to the authority, a request to store the credential information, wherein the request specifies the portion of the credential information; 
 in response to an approval of the request, storing the credential information in the secure element, wherein the credential information is usable to establish the identity of the user; 
 receiving, via the short-range radio, a request for the credential information in the secure element; 
 in response to the request for credential information, authenticating the user of the computing device via the secure circuit; and 
 in response to the authenticating, the secure element providing the requested credential information via the short-range radio. 
 
 
     
     
       2. The computing device of  claim 1 , wherein the identification document is a passport that includes a radio-frequency identification (RFID) circuit storing the credential information, and wherein the request specifies a passport number read from the RFID circuit. 
     
     
       3. The computing device of  claim 1 , further comprising:
 a biosensor configured to collect biometric information of the user, wherein the authenticating includes using the biosensor to authenticate the user. 
 
     
     
       4. The computing device of  claim 3 , wherein the secure circuit is configured to:
 store fingerprint information associated with the user; 
 perform a comparison of the fingerprint information with the biometric information collected by the biosensor to authenticate the user; and 
 indicate a result of the comparison to the secure element, wherein the secure element is configured to provide the requested credential information based on the indicated result. 
 
     
     
       5. The computing device of  claim 4 , wherein the secure element is configured to:
 in response to storing the credential information, store a unique value that associates a particular finger of the user with the credential information; 
 compare the stored unique value with a unique value specified in the indicated result from the secure circuit, wherein the specified unique value indicates a particular finger identified during performance of the comparison; and 
 provide the credential information in response to the stored unique value matching the specified unique value. 
 
     
     
       6. The computing device of  claim 1 , wherein the request for credential information includes a digital certificate indicating that an entity is permitted to receive the credential information, and wherein the secure element is configured to encrypt the requested credential information using a public key specified in the digital certificate prior to providing the requested credential information via the short-range radio. 
     
     
       7. The computing device of  claim 1 , wherein the secure element is configured to:
 generate a public-key pair usable to establish an identity of the user; 
 issue a certificate signing request (CSR) for the public-key pair to the authority; and 
 receive a certificate for the public-key pair in response to the authority granting the CSR. 
 
     
     
       8. The computing device of  claim 1 , wherein the operations include:
 in response to the approval of the request, receiving the credential information from the authority, wherein the received credential information is signed by the authority. 
 
     
     
       9. The computing device of  claim 1 , wherein the operations include:
 prior to storing the credential information, reading the credential information from the circuit embedded in the identification document via the short-range radio. 
 
     
     
       10. A method, comprising:
 a computer system issuing, via a short-range radio, a request for identity information stored in a secure element of a mobile device, wherein the secure element includes a processor distinct from a central processing unit of the mobile device and a memory distinct from a memory accessible to the central processing unit, and wherein at least a portion of the identity information has been extracted by the mobile device from circuitry included in an identification document issued to a user of the mobile device; 
 the computer system receiving the requested identity information in response to the mobile device performing an authentication of the user, wherein performing the authentication includes the mobile device using a secure circuit configured to authenticate of the user of the mobile device; and 
 the computer system using the received identity information to establish an identity of the user. 
 
     
     
       11. The method of  claim 10 , wherein the mobile device performs the authentication using a biosensor included in the mobile device. 
     
     
       12. The method of  claim 11 , wherein the secure element associates the stored identity information with a particular finger of the user when the identity information is stored in the secure element, and wherein the authentication includes verifying that biometric information collected by the biosensor corresponds to the particular finger. 
     
     
       13. The method of  claim 10 , further comprising:
 in response to the mobile device performing the authentication, the computer system receiving a digital certificate and a digital signature from the secure element of the mobile device, wherein the digital signature is generated by the secure element using a private key associated with the digital certificate, and wherein the digital certificate is generated by an authority that issued the identification document to the user; and 
 the computer system using the digital certificate and the digital signature to establish an identity of the user. 
 
     
     
       14. The method of  claim 10 , wherein the received identity information includes a picture of the user that is stored in the circuitry included in the identification document.

Description:
The present application is a continuation of U.S. application Ser. No. 15/415,467, filed Jan. 25, 2017, which claims priority to U.S. Prov. Appl. No. 62/286,944, filed Jan. 25, 2016, which is incorporated by reference herein in its entirety. 
    
    
     BACKGROUND 
     Technical Field 
     This disclosure relates generally to mobile devices, and, more specifically, to authenticating a user with a mobile device. 
     Description of the Related Art 
     Various governments are now issuing various forms of identification that are capable of storing identification information that can be used to authenticate a user. For example, modern passports (called e-Passports) may include an electronic chip that stores a passport holder&#39;s name, date of birth, and other forms of information. When a person is passing through customs, the person may present the passport to a customs officer, who places the passport on a reader to extract information stored in the passport. Upon verifying the information printed on the passport against the internally stored information, the officer may confirm the identity of the holder and allow the holder passage through customs. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block diagram illustrating one embodiment of system for authenticating a user with a mobile device. 
         FIG. 2  is a block diagram illustrating one embodiment of the mobile device. 
         FIGS. 3A-3C  are communication diagrams illustrating embodiments of enrollment and authentication processes used by the authentication system. 
         FIG. 4  is a block diagram illustrating another embodiment of a system for authenticating a user with a mobile device. 
         FIGS. 5A and 5B  are communication diagrams illustrating embodiments of enrollment and authentication processes used by the authentication system. 
     
    
    
     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 “biosensor configured to collect biometric information” 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 logical 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.” 
     DETAILED DESCRIPTION 
     The present disclosure describes embodiments in which a person may present identification information through a mobile device instead of presenting a traditional form of identification. As will be described below, in various embodiments, a mobile device includes a short-range communication interface (e.g., a near-field communication (NFC) radio) and a secure element configured to store identification information of a user. As used herein, the term “secure element” is to be interpreted according to its understood meaning in the art, and refers to circuitry that is configured to store information in a tamper-resistant manner that resists unauthorized extraction of that information. In such an embodiment, when the user presents the mobile device to a corresponding reader attempting to authenticate the user, the mobile device may attempt to verify the identity of the user (e.g., via a biosensor in the mobile device in some embodiments) before permitting the secure element to provide the identification information to the reader. For example, in one embodiment, the secure element is configured to store information present in a passport issued to the user. Accordingly, when the user is passing through a customs checkpoint, the user may present the mobile device to a reader operated by a customs agent. After the mobile device authenticates the user&#39;s identity, the secure element may convey the passport information to the reader. In some instances, being able to authenticate using a mobile device may help expedite establishing an identity of user and provide the convenience of performing an authentication without presenting the identification document. 
     In various embodiments, the mobile device may receive authorization to store the identification information captured in an enrollment process with the authority that issued the identification document. In some embodiments, this process may include the mobile device using the short-range communication interface to read information stored in circuitry included in the identification document—e.g., identification information stored in a radio-frequency identification (RFID) tag embedded in a passport. The secure element may then issue a request to the authority for permission to store the identification information, the request specifying at least portion of the read information—e.g., a passport number. The authority may then validate the request and permit the secure element to store the information, which may be signed by the authority in order to ensure validity of the information. In some embodiments, the enrollment process also includes the secure element generating a public-key pair and issuing a certificate signing request (CSR) to the authority in order to receive a corresponding digital certificate and register the public-key pair with the authority. (As used herein, the term “digital certificate” (or “certificate”) is to be interpreted according to its understood meaning in the art, and refers to an electronic document that is usable to prove ownership of a public key and is signed by a trusted certificate authority (CA).) In some embodiments, the CSR is signed by a trusted key, which is stored in the secure element during fabrication and may be a certified private key having its own certificate signed by a trusted authority attesting to the validity of the stored key. In various embodiments, once the certificate has been issued for the newly generated key pair, the private key of the pair may be used to generate digital signatures to authenticate a user in lieu of a private key stored in circuitry of the identification document. Embodiments of these concepts are described in further detail below with respect to  FIGS. 1-3C . 
     In some embodiments, the mobile device may perform an authentication that includes the secure element confirming whether a holder of an identification document has an attribute satisfying some criterion without providing that attribute (or at least providing some information about that attribute without providing all information about that attribute). For example, in one embodiment, a person may be attempting to purchase an item that requires the merchant to confirm whether an age of the person satisfies some threshold value. In such an embodiment, rather than having the user present the identification document (e.g., a driver license), the reader of the merchant may ask the secure element to confirm whether the user of the mobile device is old enough to purchase the item. Based on a stored date of birth and a successful authentication of the user (e.g., via a biosensor), the secure element may then answer in the affirmative or the negative (as opposed to actually communicating the user&#39;s age or date of birth). In doing so, the mobile device is able to protect a user&#39;s identification information, yet still adequately answer the merchant&#39;s inquiry. Embodiments of these concepts are described in further detail below with respect to  FIGS. 4-5B . 
     Turning now to  FIG. 1 , a block diagram of an authentication system  100  is depicted. In the illustrated embodiment, authentication system  100  includes an identification document  110 , a verification system  120 , mobile device  130 , and authorization system  140 . As shown, document  110  may include an RFID tag  112 . Verification system  120  may include a reader  122  and backend  124 . Mobile device  130  may include a near-field communication (NFC) interface  132 , a secure element (SE)  134 , and a biosensor  138 . In some embodiments, system  100  may be arranged differently than shown. For example, in some embodiments, reader  122  and backend  124  may be located in distinct systems. In some embodiments, document  110  may include no RFID tag  112  or embed circuitry other than an RFID tag  112 . In some embodiments, SE  134  may be external to NFC interface  132 . 
     Identification document  110  corresponds to any suitable form physical identification usable to establish an identity of a holder such as a passport, driver license, government-issued ID, student ID, etc. Accordingly, document  110  presents various forms of information about a user including, for example, a user&#39;s name, date of birth, place of residence, etc. Document  110  may include a photograph of the document holder. Document  110  may also include a unique identification number such as passport number, driver license number, etc. Document  110  may also identify the issuing authority such as the particular country, government, university, etc. In various embodiments, document  110  may not only depict this information on the face of the document, but also store this information in circuitry or a magnetic strip embedded in the document  110  shown as identification information  114 . For example, in the illustrated embodiment, document  110  includes RFID tag  112  for storing this information  114 . In such an embodiment, document  110  may store information in compliance with known standards such as the ISO/IEC 18000 standards and/or ISO/IEC 14443 standards. In other embodiments, document  110  includes other forms of circuitry such as a smart card chip compliant with ISO/IEC 7816, a Bluetooth™ enabled chip, etc. In some embodiments, information stored in this circuitry may be signed by the issuing authority in order to prevent modification; the embedded circuitry may also include a digital certificate usable to verify the digital signature. In some embodiments, the circuitry embedded in document  110  is configured to store a private key and to generate digital signatures with the key in order to authenticate the holder. 
     Verification system  120 , in one embodiment, is a computer system configured to authenticate a person that presents identification document  110 . In various embodiments, system  120  uses reader  122  for extracting information  114  stored in document  110 . Accordingly, reader  122  may include a short-range radio for communicating with the RFID tag  112  in order to read the identification information stored in the tag  112 . In some embodiments, reader  122  may also include a display that presents the information  114  to a reviewer such as a customs agent attempting to verify passport information. In various embodiments, verification system  120  confirms information read by reader  122  against a backend system  124 , which may be implemented by one or more computer systems located elsewhere from reader  122 . In some embodiments, backend  124  maintains a database, which may include the information stored in document  110 , an indication of whether document  110  is still valid (e.g., has not been reported as being lost), etc. In some embodiments, backend  124  implements a certificate authority (CA) capable of issuing certificates for received certificate signing requests (CSRs). In some instances, reader  122  and/or backend  124  are operated by the authority that issued the identification document  110 . In other instances, reader  122  may be operated by another entity such as a customs agent located in another country, a merchant (as discussed with respect to  FIG. 4 ), etc. In some embodiments, backend  124  may be operated by a third-party interacting with the issuing authority. 
     Mobile device  130  corresponds to any suitable form of device such as mobile phone, tablet, wearable device (e.g., a watch), laptop, etc. As noted above, in various embodiments, mobile device  130  is configured to store identification information  114  from document  110  and present that to verification system  120  in order to authenticate a user of mobile device  130 , which is also a holder of document  110 . In the illustrated embodiment, mobile device  130  (or more specifically SE  134 ) interacts with identification document  110 , verification system  120 , and/or authorization system  140  via NFC interface  132 . 
     Near-field communication (NFC) interface  132 , in one embodiment, is a short-range radio circuit configured to implement one or more NFC standards such as those defined by ISO/IEC 18000. In other embodiments, interface  132  may implement other short-range radio access technologies (RATs) such as Bluetooth™, ZigBee™, Wi-Fi™, etc. In some embodiments, mobile device  130  may also include a long-range radio for interacting with systems  120  and  140  such one supporting various cellular RATs. 
     Secure element (SE)  134 , in one embodiment, is a secure element configured to store identity information  114 , which is also stored in RFID  112 . Accordingly, SE  134  employs various techniques to resistant extraction of information  114  such as using strong encryption, having a restricted access interface, attempting to destroy information  114  in response to tamper detection, etc. In some embodiments, SE  134  is configured to store all information  114  that is also stored in RFID tag  112 . In other embodiments, SE  134  is configured to store a token that is usable to retrieve some or all of this information  114  from backend  124 . For example, in one embodiment, rather than store a photograph that is stored in tag  112 , SE  134  stores a token that is usable to retrieve this photograph—thus enabling SE  134  to conserve memory. In various embodiments, when a user presents mobile device  130  to a reader  122 , NFC interface  132  presents SE  134  with a request for information from reader  122 . Upon receiving the request, SE  134  may verify that the user has been authenticated by mobile device  130  before providing information  114  to reader. As will be discussed below, in some embodiment, this authentication may be performed using biosensor  138 . In other embodiments, the user may be authenticated differently such as, in one embodiment, being presented with a prompt on a touch screen of mobile device  130  and asked to enter a passcode. Upon a successful authentication of the user, in various embodiments, SE  134  communicates information  114  to reader  122  via an encrypted connection established through NFC interface  132 . Prior to interacting with verification system  120 , mobile device  130  may perform an enrollment process in order for SE  134  to be permitted to store information  114  and interact with verification system  120 . 
     Authorization system  140 , in one embodiment, is a computer system configured to facilitate enrollment of mobile device  130 . In some embodiments, authorization system  140  is operated by the authority that issued document  110  (or a third party that interacts with the issuing authority). In various embodiments, mobile device  130  begins enrollment by reading at least a portion of information  114  stored in identification document  110 , such as the identification number and the name of the person that holds document  110 . In the illustrated embodiment, mobile device  130  reads this information from RFID tag  112  via NFC interface  132 ; in other embodiments, this information may be extracted differently such as using a camera of device  130  to capture information from document  110 , having a user manually enter this information, etc. Upon reading this information, SE  134  may encrypt this information and communicate it in an enrollment request  136  to system  140 . Although depicted as being communicated via NFC interface  132 , in some embodiment, this request  136  via another interface of mobile device  130  such a cellular interface. Authorization system  140  may then attempt to validate this request  136 —i.e., confirm that the request  136  is coming from a phone operated by the holder of document  110 . 
     In some embodiments, authorization system  140  validates the request  136  through one or more back channels. For example, in one embodiment, authorization system  140  may rely on a trusted person, such a customs agent, to confirm that device  130  is in possession of document  110 &#39;s holder at the time of enrollment. In other embodiments, authorization system  140  may present a website usable to assist in validating a request  136 . For example, in one embodiment, this website may allow a user to validate the request via the Global Online Enrollment System (GOES) operated by the U.S. Department of Homeland Security. In another embodiment, authorization system  140  may be able to sufficiently validate the request  136  by verifying its information against information stored in backend  124 . 
     In various embodiments, once the authentication system  140  has successfully validated the request  136 , authorization system  140  is configured to provide an authorization indication  142  to SE  134  in order to indicate that SE  134  has been authorized to store identification information  114 . In various embodiments, this indication  142  includes a signed copy of the information  114  that is stored in document  110  (and/or a signed copy of a token stored in lieu of storing information  114  in in some embodiments). In some embodiments, system  140  obtains information  114  by querying backend  124  using the information provided in request  136  such as an identification number of document  110 . In other embodiments, SE  134  may be able to successfully read all information  114  from RFID tag  112  and is configured to include this information in its request  136 . In such an embodiment, system  140  may merely sign the request  136  including the information  114  within it and provide this signed request as the authorization indication  142 . In another embodiment, indication  142  includes a token generated by system  140  that can be presented to verification system  120  in order to retrieve information  114  from backend  124 . 
     In some embodiments, the enrollment process also includes SE  134  establishing a private key that can be used to generate digital signatures to authenticate a user. In such an embodiment, SE  134  is configured to generate a public-key pair and to issue a CSR to receive a corresponding certificate. In some embodiments, SE  134  issues the CSR to backend  124  and includes the received authentication indication  142  in the CSR. Backend  124  acting as a certificate authority may then issue the corresponding certificate to SE  134  for storage. In some embodiments, backend  124  may also store a copy of certificate and associate it the information that it maintains on the holder of document  110 . In other embodiments, this CSR may be sent as part of request  136  (or in conjunction with request  136 ) to authorization system  140 . 
     As noted above, in some embodiments, biosensor  138  is used to authenticate a user of mobile device  130  before SE  134  provides identification information  114  to reader  122 . Biosensor  138  corresponds to any suitable sensor configured to detect biometric data for a user of mobile device  130 . Biometric data is data that uniquely identifies the user among other humans (at least to a high degree of accuracy) based on the user&#39;s physical or behavioral characteristics. For example, in some embodiments, biosensor  138  is a finger print sensor that captures fingerprint data from the user. In some embodiments, other types of biometric data may be captured by sensor  260 A such as voice recognition (identifying the particular user&#39;s voice), facial recognition; iris scanning, etc. 
     In various embodiments, SE  134  is configured to associate identification information  114  with biometric data captured by biosensor  138  when enrollment is performed in order to ensure that a person later attempting to authenticate with mobile device  130  is the same person during enrollment. In some embodiments, SE  134  associates information  114  with the biometric data by storing a unique index value that corresponds with the captured biometric data. SE  134  may also cryptographically bind this value to information  114  by encrypting them together. As will be described with respect to  FIG. 2 , in some embodiments, a separate circuit (referred to below as a secure enclave processor) is configured to store previously captured biometric data and compare it against newly acquired biometric during an authentication. In some embodiments, when this circuitry detects a match, it indicates to SE  134  not only that a match was detected, but also provides a unique index value associated with the match. In such an embodiment, SE  134  uses the index value to look up stored information  114 . For example, in one embodiment, a user may register multiple fingers during an enrollment process, where each finger is assigned a unique index value that is associated with the newly stored information  114 . When a user later attempts to authenticate with a reader  122  and uses one of the previously registered fingers (or a combination of the fingers in some embodiments), the secure enclave processor may provide the corresponding unique index value (or values), which is used by SE  134  to lookup the information  114  and provide to reader  122 . If, however, the user (or another user) attempts to register another finger after enrollment, the secure enclave processor may provide a unique index value, which may result in SE  134  being unable to look up the previously stored information  114 —thus, preventing SE  134  from providing the requested information  114 . 
     Embodiments of the enrollment and authentication processes are described in further detail below with respect to  FIGS. 3A-3C . 
     Turning now to  FIG. 2 , a block diagram of a mobile device  130  is depicted. As noted above, mobile device  130  may include NFC interface  132 , SE  134 , and biosensor  138 . In the illustrated embodiments, mobile device  130  further includes a secure enclave processor (SEP)  210 , cellular interface  220 , CPU  230 , memory  240 , peripherals  250  coupled via a communication fabric  260 . As shown, SEP  210  may include one or more processors P  212 , a secure memory  214 , and one or more security peripherals  216 . SE  134  may include one or more processors P  222  and a memory  224 . CPU  320  may include one or more processors P  322 . Memory  240  may store an interface application  242 . In some embodiments, mobile device  130  may be implemented differently from shown. 
     As noted above, in some embodiments, SEP  210  is configured to maintain previously captured biometric data of an authorized user and compare it against newly received data captured by biosensor  138  in order to authenticate a user. (In another embodiment, biosensor  138  or SE  134  may perform the comparison.) In the illustrated embodiment, SEP  210  is configured to store biometric data collected from fingerprints as fingerprint templates  218 . In such an embodiment, each template  218  may correspond to a particular registered finger and be assigned a unique index value. As noted above, in some embodiments, if fingerprint data received from biosensor  138  matches the fingerprint data stored in a template  218 , SEP  210  is configured to provide the unique index value associated with the matching template  218  to SE  134 , which, in turn, uses the index value to look up the corresponding identification information  114  associated with that value. In some embodiments, SEP  210  may store multiple templates  218  associated with a set of identification information  114 , where each finger individually or a combination of fingers may be used to enable the release of identification information  114 . In various embodiments, communications between SEP  210 , SE  134 , and biosensor  138  are encrypted such that another entity, such as CPU  230 , is unable to view their communications. 
     In various embodiments, SEP  210  implements a secure element, distinct from SE  134 , in order to securely store biometric data. Accordingly, in various embodiments, SEP  125  is isolated from the rest of the mobile device  130  except for a carefully controlled interface (thus forming a secure enclave for SEP processor  212 , secure memory  214 , and security peripherals  216 ). Because the interface to SEP  210  is carefully controlled, direct access to SEP processor  212 , secure memory  214 , and security peripherals  216  may be prevented. In one embodiment, a secure mailbox mechanism may be implemented. In the secure mailbox mechanism, external devices may transmit messages to an inbox. SEP processor  212  may read and interpret the message, determining the actions to take in response to the message. Response messages from the SEP processor  212  may be transmitted through an outbox, which is also part of the secure mailbox mechanism. Other interfaces that permit only the passing of commands/requests from the external components and results to the external components may be used. No other access from the external devices to SEP  210  may be permitted, and thus the SEP  210  may be “protected from access”. More particularly, software executed anywhere outside SEP  210  may be prevented from direct access to the secure components with the SEP  210 . SEP processor  212  may determine whether a command is to be performed. In some cases, the determination of whether or not to perform the command may be affected by the source of the command. That is, a command may be permitted from one source but not from another. 
     In some embodiments, SEP processor  212  may execute securely loaded software that facilitates implementing functionality described with respect to SEP  210 . For example, a secure memory  214  may include software executable by SEP processor  212 . One or more of the security peripherals  216  may have an external interface, which may be connected to a source of software (e.g. a non-volatile memory such as Flash memory). In another embodiment, the source of software may be a non-volatile memory coupled to another peripheral  216 , and the software may be encrypted to avoid observation by a third party. The software from the source may be authenticated or otherwise verified as secure, and may be executable by SEP processor  212 . In some embodiments, software may be loaded into a trust zone in memory  214  that is assigned to the SEP  210 , and SEP processor  212  may fetch the software from the trust zone for execution. The software may be stored in the memory  240  in encrypted form to avoid observation. Despite the steps taken to ensure security of the secure software, the secure software may still be prevented from directly accessing/obtaining stored private keys. Only hardware may have access to private keys, in an embodiment. 
     Security peripherals  216  may be hardware configured to assist in the secure services performed by SEP  210 . Accordingly, security peripherals  216  may include authentication hardware implementing/accelerating various authentication algorithms, encryption hardware configured to perform/accelerate encryption, secure interface controllers configured to communicate over a secure interface to an external (to mobile device  130 ) device, etc. 
     In some embodiments, SE  134  may implement similar functionality as SEP  210  in order to restrict access to confidential information stored in memory  224  such as identification information  114  and public-key information  228 . For example, SE  134  may implement a mailbox to restrict access to processor  222  and memory  224 . In various embodiments, SE processor  222  also executes securely loaded software in order to implement functionality described herein such as applets  226  stored in memory  224 . 
     Applets  226 , in one embodiment, are executable to perform enrollment of mobile device  130  and authentication with a reader  122 . With respect to enrollment, applets  226  may be executable to extract information  114  from an RFID tag  112  and issue a corresponding enrollment request  136 . In some embodiments, applets  226  are executable to generate public-key pairs and obtain corresponding certificates, which may be stored in memory  224  as public-key information  228 . With respect to authentication, applets  226  may service requests from information  114  from readers  122  and may process comparison results indicated by SEP  210 . In some embodiments, if a particular comparison performed by SEP  210  does not result in a match, SE  134  may be configured to restrict (or stop) execution an applet  226  in order to prevent it from servicing a request from information  114  from a reader  122 . 
     Interface application  242 , in one embodiment, is executable to facilitate interfacing between SEP  210 , SE  134 , and a user of mobile device  130  when enrollment and authentication are performed. Accordingly, application  242  may provide various prompts to the user instructing the user to perform various actions during these processes. Application  242  may also activate biosensor  138 , SEP  210 , and/or SE  134  when appropriate during these processes. Various actions performed by application  242  are described in further detail below with respect to  FIGS. 3A-3C . 
     Cellular Interface  220 , in one embodiment, is a long-range radio configured to facilitate interaction between mobile device  130  and one or more external systems such as systems  120  and  140 . Cellular link  220  may include suitable circuitry for interfacing with long-range networks such as a baseband processor, analog RF signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), digital processing circuitry (e.g., for digital modulation as well as other digital processing), one or more antennas, etc. Cellular interface  220  may be configured to communicate using any of multiple radio access technologies/wireless communication protocols such as GSM, UMTS, CDMA2000, LTE, LTE-A, etc. 
     As mentioned above, CPU  230  may include one or more processors  232 . Generally, a processor may include circuitry configured to execute instructions defined in an instruction set architecture implemented by the processor. Processors  232  may include (or correspond to) processor cores implemented on an integrated circuit with other components as a system on a chip (SOC) or other levels of integration. Processors  232  may further include discrete microprocessors, processor cores and/or microprocessors integrated into multichip module implementations, processors implemented as multiple integrated circuits, etc. 
     Processors  232  may execute the main control software of the system, such as an operating system. Generally, software executed by CPU  230  during use may control the other components of the system to realize the desired functionality of the system. The processors may also execute other software. These applications may provide user functionality, and may rely on the operating system for lower-level device control, scheduling, memory management, etc. Accordingly, processors  232  (or CPU  230 ) may also be referred to as application processors. CPU  230  may further include other hardware such as an L2 cache and/or an interface to the other components of the system (e.g. an interface to the communication fabric  260 ). 
     Memory  240  may generally include the circuitry for storing data. For example, memory  240  may be static random access memory (SRAM), dynamic RAM (DRAM) such as synchronous DRAM (SDRAM) including double data rate (DDR, DDR2, DDR3, DDR4, etc.) DRAM. Low power/mobile versions of the DDR DRAM may be supported (e.g. LPDDR, mDDR, etc.). Device  130  may include a memory controller (not shown) that may include queues for memory operations, for ordering (and potentially reordering) the operations and presenting the operations to the memory  240 . The memory controller may further include data buffers to store write data awaiting write to memory and read data awaiting return to the source of the memory operation. In some embodiments, the memory controller may include a memory cache to store recently accessed memory data. In some embodiments memory  330  may include program instructions, such as instructions of application  242 , that are executable by one or more processors  232  to cause device  130  to perform various functionality described herein with respect to device  130 . 
     Peripherals  250  may be any set of additional hardware functionality included in device  130 . For example, peripherals  340  may include video peripherals such as an image signal processor configured to process image capture data from a camera or other image sensor, display controllers configured to display video data on one or more display devices, graphics processing units (GPUs), video encoder/decoders, scalers, rotators, blenders, etc. Peripherals  250  may include audio peripherals such as microphones, speakers, interfaces to microphones and speakers, audio processors, digital signal processors, mixers, etc. Peripherals  250  may include interface controllers for various interfaces including interfaces such as Universal Serial Bus (USB), peripheral component interconnect (PCI) including PCI Express (PCIe), serial and parallel ports, etc. Peripherals  250  may include networking peripherals such as media access controllers (MACs). Any set of hardware may be included. 
     Communication fabric  360  may be any communication interconnect and protocol for communicating among the components of device  130 . Communication fabric  360  may be bus-based, including shared bus configurations, cross bar configurations, and hierarchical buses with bridges. Communication fabric  360  may also be packet-based, and may be hierarchical with bridges, cross bar, point-to-point, or other interconnects. 
     Although  FIG. 2  depicts components within mobile device  130 , it is noted that similar components may exist in computer systems used to implement other functionality described herein such as functionality described with respect to verification system  120  and authorization systems  140 . Accordingly, these systems may also include CPUs, memory, various network interfaces, and peripherals such as those described above. 
     Turning now to  FIG. 3A , a communication diagram of an enrollment process  300 A is depicted. As discussed above, in various embodiments, enrollment process  300 A may be performed by mobile device  130  in order to obtain authorization to store identification information  114  from an identification document  110 . 
     As shown, process  300 A begins at  302  with application  242  issuing a request to read an identification number, such as a passport number or other portion of information  114 , via NFC interface  132 . In response to receiving the number at  304 , application  242  activates biosensor  306  to collect biometric data from the user before providing the identification number to SE  134  at  308 . In the illustrated embodiment, SE  134  then issues an enrollment request  136  at  310  that includes the number, a nonce, and a digital signature. (As used herein, the term “nonce” is to be interpreted according to its understood meaning in the art, and includes an arbitrary number that is only used once in a cryptographic operation.) In some embodiments, the digital signature is generated using a trusted key (e.g., a certified private key) stored in SE  134  during fabrication, and authentication system  140  may include the corresponding certificate. At  312 , authentication systems  140  validates the request by verifying the identification number and the digital signature. In some embodiments, the validation may also include verifying the request via one or more back channels as discussed above. Upon a success validation, authentication system  140  provides an authorization indication  142  at  314  to SE  134 . At  316 , SE  134  generates a public-key pair to be associated with the identification information  114  and usable to authenticate the user. At  318 , SE  134  then issues, to verification system  120 , a certificate signing request (CSR) that, in the illustrated embodiment, includes the previous enrollment request  136 , the received authentication indication  142 , a public key of the generated pair, and a digital signature generated by the corresponding private key. In various embodiments, the CSR is signed using the trusted key stored in SE  134  during fabrication as mentioned above. After successfully validating the CSR at  320 , verification system  120  issues the corresponding certificate to SE  134  for storage at  322 . 
     Turning now to  FIG. 3B , a communication diagram of another enrollment process  300 B is depicted. Enrollment process  300 B is another embodiment of an enrollment process in which a unique index value is associated with the stored identification information  114 . 
     As shown, process  300 B begins in a similar manner as process  300 A with application  242  issuing a request at  302  to read the identification number (or some other portion of information  114  in some embodiments) and application  242  receiving it at  304 . At  336 , application  242  then issues, to SEP  210 , a request to collect biometric data along with the identification number. At  338 , SEP  210  may instruct biosensor to collect biometric data, which SEP  210  stores the data with a unique index value. At  340 , SEP  210  then provides this unique index value and the identification number to SE  134 . Steps  310 - 316  may then performed in a similar manner as discussed above with respect process  300 A. After generating a public-key pair at  316 , SE  134  issues, to validation system  120 , a CSR that, in the illustrated embodiment, includes the unique index value along with the additional information discussed above with respect process  300 A. Upon a successful validation, SE  134  receives a corresponding certificate certifying the public key pair at  344  and including the unique index value. 
     Turning now to  FIG. 3C , a communication diagram of an authentication process  350  is depicted. In various embodiments, authentication process  350  may be performed when a user of mobile device  130  attempts to authenticate with a reader  122  in order to prove an identity of the user. 
     As shown, authentication process  350  begins at  352  with reader  122  issuing a request for identity information  114  to application  242  via NFC interface  132 . At  354 , application  242  issues a request to SEP  210  to check the identity of the user of mobile device  130 . SEP  210  then instructs biosensor  138  to collect biometric data, which is compared by SEP  210  at  356  against stored biometric data from the previous enrollment process. If a match is detected, SEP  210  provides the corresponding unique index value to SE  134  at  358 . Upon receiving the unique index value, SE  134  verifies that the unique index value matches the unique index value associated with the stored identification information  114  at  360  and issues, at  362 , the requested information  114 , which, in the illustrated embodiment, is signed using the private key generated during the enrollment process. If, however, the index value does not match the index value associated with the previously stored information  114 , then SE  134  may signal an error and not respond at  360 . 
     Turning now to  FIG. 4 , a block diagram of an authentication system  400  is depicted. As noted above, in various embodiments, mobile device  130  is configured to perform an authentication that includes SE  134  confirming whether a holder of an identification document  110  has an attribute satisfying some criterion without providing that attribute. For example, as noted above, a mobile device  130  may be used to confirm that a user is old enough to purchase a particular product (e.g., alcohol) without providing the user&#39;s date of birth to the merchant. In some embodiments, device  130  also may provide addition information, but not all information present on an identification document  110 . For example, in such an embodiment, device  130  may also provide a photograph of the user, but not the user&#39;s driver license number. In some embodiments, mobile device  130  may also perform such an authentication when conducting a transaction via an authentication system such as system  400 . In the illustrated embodiment, authentication system  400  includes mobile device  130 , a merchant system  410 , and an authorization system  420 . As shown, merchant system  410  may include a reader  412  and a backend  414 . 
     Merchant System  410 , in one embodiment, includes one or more computer systems configured to facilitate a financial transaction between a user of mobile device  130  and a merchant. In illustrated embodiment, merchant system  410  interacts with mobile device  130  via a reader  412 , which may implement functionality described above with respect to reader  122 . Accordingly, as shown, reader  412  may be configured to issue a request  426  for SE  134  to confirm some aspect about information  114  and receiving a corresponding confirmation  428 . In various embodiments, backend  414  of merchant system  410  is a computer system configured to authorize a transaction and facilitate interfacing with a transaction instrument provider such as Visa™, American Express™, MasterCard™, etc. Accordingly, in some embodiments, backend  414  may also verify a confirmation  428  when determining to authorize a transaction. In some embodiments, backend  414  is also configured to perform an enrollment process for merchant system  410  in order to enable merchant system  410  to communicate with a mobile device  130 . 
     Authorization system  420 , in one embodiment, is a computer system to facilitate enrolling a merchant system  410 . In some embodiments, authorization system  420  may be operated by an authority that issues identification document  110  or a trusted third-party that interacts with the issuing authority. In some embodiments, merchant system  410  may begin an enrollment by having backend  414  generate a public-key pair and issuing an enrollment request  422  that includes a CSR for the key pair. In some embodiments, enrollment request  422  may also specify what attribute or attributes that merchant wants SE  134  to confirm. For example, in one embodiment, the request  422  may specify that a merchant wants to 1) know whether a user exceeds a particular age threshold (e.g., is over 21 years of age) and 2) be provided with a corresponding photograph of the user that is present on identification document  110 . Authorization system  420  may then validate this request  422 , which, in some embodiments, may be performed in a similar manner as discussed above with respect to request  136 . In response to a successful validation the request, in various embodiments, authorization  420  issues a corresponding digital certificate  424  indicating that merchant system  410  is authorized to receive the request information specified in its enrollment request  422 . In some embodiments, upon merchant system  410  receiving certificate  424 , backend  414  may distribute the certificate to readers  412  in order to enable them to issue requests  426 . In another embodiment, rather than providing a merchant system  410  with a certificate, authorization system  420  is configured to make backend  414  an intermediate certificate authority, which has the ability to issue certificates to readers  412  for public key pairs generated by the readers  412 . 
     When a transaction is conducted after enrollment, a reader  412  is configured to issue a request  426  that specifies that certificate  424  indicating that a merchant system  410  is authorized to obtain the requested information specified in the certificate  424 . In various embodiments, upon receiving a request  426 , SE  134  is configured to validate the certificate, which may include issuing a challenge to reader  412  and having backend  414  (or readers  412  in some embodiments) generate a corresponding response. In other embodiments, SE  134  may merely validate the certificate using the digital signature and public key specified in the certificate as communication between SE  134  and reader  412  is encrypted in order to prevent a third party from obtaining to certificate  424 . After successfully verifying the certificate, SE  134  may confirm the identity of the user via biosensor  138  as discussed above and issue a confirmation  428  providing the requested information  114  specified in the certificate  424 . Upon receiving this information, in some embodiments, reader  412  may present this information on a display to a sells representative operating a reader  412 . Reader  412  may also present a prompt asking the representative to approve the information before enabling backend  414  to communicate with a transaction instrument provider. 
     Enrollment and authentication processes are described in further detail below with respect to  FIGS. 5A and 5B . 
     Turning now to  FIG. 5A , a communication diagram of an enrollment process  500  is depicted. As noted above, in various embodiments, process  500  may be performed in order to enable a merchant system to interface with mobile device  130 . 
     As shown, enrollment process  500  begins at  504  with backend  414  generating a public key pair to be used in encrypting communications between mobile devices  130  and reader  122  as well as verifying a corresponding certificate  424 . At  504 , backend  414  then issues an enrollment request  422  to authorization system  420 , where the enrollment request includes a CSR for the generated public-key pair. After receiving the request  422 , authorization system  420  validates the request at  506  and issues a corresponding certificate  424  at  508  upon successful validation. 
     Turning now to  FIG. 5B , a communication diagram of an authentication process  550  is depicted. As noted above, in some embodiments, an authentication processor  550  may be performed to authenticate some aspect about a person such as during a financial transaction. 
     As shown, authentication process  550  begins at  552  with reader  412  issuing a request  426  for authenticating one or more attributes about a user via an NFC interface to application  242 . Upon receiving and validating the request, Application  242  issues a request to SEP  210  at  554  to ask SEP  210  to check the identity of the user. At  556 , SEP  210  activates biosensor  138  and receives corresponding biometric data, which SEP  210  compares against biometric data previously stored in SEP  210  during the enrollment of mobile device  130 . In response to a successful match, SEP  210  indicates the corresponding unique index value to SE  134  at  558 . At  560 , SE  134  verifies the unique index value against the value previously associated with the identification information  114 . After successful verification, SE  134  determines what is to be provided to the reader  412  based on the information specified in the received certificate  424  and issues, at  562 , the corresponding information, which may be signed by the private key established during enrollment of the mobile device  130 . 
     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.

Metadata:
Filing Date: 20180330
Publication Date: 20200303
Grant Date: 20200303
Priority Date: 20160125
Inventors: SIBERT, HERVE
TACKIN, ONUR E.
LERCH, MATTHIAS
KHAN, Ahmer A.
RAKOTOMALALA, FRANCK
ELRAD, Oren M.
Assignee: APPLE INC
CPC Classifications: [{"code": "H04L9/3263", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3829", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L2463/082", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q20/3278", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3263", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3231", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3247", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/083", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0894", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q2220/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q20/3825", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/40145", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/405", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3227", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/4014", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3278", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/385", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/40145", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/204", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q2220/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q20/3829", "inventive": true, "first": true, "tree": "[]"}, {"code": "H04L2209/805", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L63/0861", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3829", "inventive": true, "first": true, "tree": "[]"}, {"code": "G06Q20/385", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/204", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3231", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/405", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3825", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q2220/00", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L63/0861", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/4014", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3247", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/40145", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3227", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/083", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0894", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2209/805", "inventive": false, "first": false, "tree": "[]"}, {"code": "G06Q20/3278", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2463/082", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04W12/06", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3263", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/069", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04W12/069", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3825", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/3231", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/4014", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/405", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/3227", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/204", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L63/083", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2463/082", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L63/0861", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L2209/805", "inventive": false, "first": false, "tree": "[]"}, {"code": "H04L9/3247", "inventive": true, "first": false, "tree": "[]"}, {"code": "G06Q20/385", "inventive": true, "first": false, "tree": "[]"}, {"code": "H04L9/0894", "inventive": true, "first": false, "tree": "[]"}]
Family ID: 59359587