Patent Application
20230351377
This disclosure relates generally to mobile devices, and, more specifically, to authenticating a user with a mobile device.
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'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.
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.”
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'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
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's age or date of birth). In doing so, the mobile device is able to protect a user's identification information, yet still adequately answer the merchant's inquiry. Embodiments of these concepts are described in further detail below with respect to
Turning now to
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'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 is suing 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
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'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'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 260A such as voice recognition (identifying the particular user'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
Embodiments of the enrollment and authentication processes are described in further detail below with respect to
Turning now to
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 descried 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
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
Turning now to
As shown, process 300A 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
As shown, process 300B begins in a similar manner as process 300A 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 300A. 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 300A. 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
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
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
Turning now to
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
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.
The present application is a continuation of U.S. application Ser. No. 15/415,467, entitled “DOCUMENT IMPORTATION INTO SECURE ELEMENT,” filed Jan. 25, 2017, which claims priority to U.S. Provisional App. No. 62/286,944, entitled “DOCUMENT IMPORTATION INTO SECURE ELEMENT,” filed Jan. 25, 2016; the disclosures of each of the above-referenced applications are incorporated by reference herein in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| 62286944 | Jan 2016 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15415467 | Jan 2017 | US |
| Child | 18340654 | US |
