WO2019046406A1

WO2019046406A1 - System for secure network enrollment

Info

Publication number: WO2019046406A1
Application number: PCT/US2018/048515
Authority: WO
Inventors: David Michael WESTERHOFF; William Christopher SUMMERLIN; Timothy Chiheng CO
Original assignee: Westerhoff David Michael; Summerlin William Christopher; Co Timothy Chiheng
Priority date: 2017-08-29
Filing date: 2018-08-29
Publication date: 2019-03-07

Abstract

A method of securely enrolling a user onto a network, includes obtaining identification data indicative of the user's identity, the identification data being acquired via a user's device; linking the user's identity with a hardware identifier uniquely associated with the user's device; requesting verification of the user's identity by a third party; and upon receiving the verification, enrolling the user's identity and linked hardware identifier onto the network. Other methods and systems for securely enrolling a user onto a network are also disclosed.

Description

SYSTEM FOR SECURE NETWORK ENROLLMENT

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U. S. Provisional Application Serial No. 62/551 ,651, filed August 29, 2017 and to U. S. Provisional Application Serial No. 62/583,665, filed November 9, 2017. The entire contents of each of the foregoing applications is hereby incorporated by reference.

BACKGROUND

Privacy and data security is a growing problem in today's world, where most data is transferred and stored using the internet. In an attempt to protect user data from unauthorized access, entities with an online presence, such as financial institutions and government agencies, commonly require users to create usemames and passwords to gain access to their online accounts. These entities sometimes also rely on access methods with additional security, such as requiring multi-factor authentication ("MFA") in which a user is granted access only after successfully presenting several separate pieces of evidence to

an authentication mechanism.

Current systems may be onerous and/or vulnerable to attack. For example, a user may be forced to maintain a myriad of usernames and passwords and share private information with a large number of entities. With MFA security, users also undergo additional steps to gain access to their account. Moreover, because all of these entities separately collect user information, they all need to protect this data from unauthorized access independently.

Current methods of authentication may also be vulnerable to fraudulent access. Most access points to a network only require knowledge of a username or password. MFA may additionally require access to the user's mobile device or computer. However, none of these methods actually verify that the person accessing the account is the registered user. Even biometrics, such as retinal scans or fingerprints, which are unique to a user and are required by certain entities, may be spoofed.

SUMMARY

Systems and methods for secure network enrollment are described. In order for a user to gain access, via the user's mobile device, to a secure network administered by a trusted identity provider ("TidP"), the user is prompted by the TidP to undergo a multistep enrollment process. To initiate the enrollment process, the user's mobile device needs to meet security-focused hardware requirements established by the TidP.

The multi-step enrollment process involves the user providing identification information to the TidP and undergoing a separate screening by a third party or an authorized agent of the TidP. Once TidP gathers all necessary information to uniquely identify the user, the user is enrolled on the network and may request access to the network via the device used by the user for enrollment. The enrollment process allows TidP to make certain that the user's digital identity on the secure network, tied to the user's mobile device, is unique and matches a single, verified person's actual identity.

After enrollment, every time the user requests to access or use the secure network, the TidP may prompt the user's device to authenticate the user's identity before granting access to the network. An enrolled user may request that additional user devices are linked with the user's identity on the secure network, providing multiple access points for the user onto the network.

The user may interact with other users and entities enrolled on the secure network. The TidP may provide any verifications or authorizations requisite for such interactions, such as verifying the user's identity to their bank or providing the bank authority from the user to perform a transaction on the user's account.

In general, in a first aspect a method of securely enrolling a user onto a network includes obtaining identification data indicative of the user's identity, the identification data being acquired via a user's device; linking the user's identity with a hardware identifier uniquely associated with the user's device; requesting verification of the user's identity by a third party; and upon receiving the verification, enrolling the user's identity and linked hardware identifier onto the network.

Implementations of the method can include one or more of the following features. Identification data can include a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color. The method can include prompting the user to enter biometric data into the user's device before requesting verification.

Requesting verification can include providing the user with a verification document containing at least some of the identification data obtained from the user; and requesting the user to: present an identity document and the verification document to the third party; and requesting the third party to: confirm that the identity document is consistent with the information in the verification document. Requesting verification may further include requesting the user to affirm to the third party that the information in the verification document is correct and that the identity document is authentic. In addition, requesting verification may include requesting the user to enter biometric data into the user's device in the presence of the third party; and requesting the third party to witness the user enter biometric data into the user's device.

The user's biometric data may be encrypted and stored locally on the device. After requesting verification and before enrolling, confirmation can be received that biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification. For example, the user's device can generate a secure token when the biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification. Alternatively, the user's entered biometric data can be encrypted and transmitted. Then, biometric data entered in the presence of the third party can be matched to the biometric data entered before requesting verification.

The third party may be a notary public and the verification document a physical document. Then, requesting verification can include requesting the notary public to notarize the verification document after confirming that the identity document is consistent with the information in the verification document. The identity document can be a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport.

The method can include, before enrolling, positively determining that the user's identity has not been previously enrolled on the network.

Enrollment may further include linking the user's identity with the digital identity of another entity enrolled on the network upon verification that the user is an authorized representative of the entity.

After enrolling, the user's enrolled identity may be linked to a plurality of hardware identifiers respectively associated with a plurality of the user's devices.

In general, in a further aspect, a method of securely enrolling a user onto a network, includes entering identification data indicative of the user's identity using a device; sending the identification data and a hardware identifier uniquely associated with the device via a network to an enrollment administrator; receiving a request for verification of the user's identity by a third party, the request including a verification document containing at least some of the user's entered identification data; providing verification information and the verification document to the third party for certification; receiving confirmation of enrollment of the user's identity associated with the hardware identifier onto the network, upon receipt by the enrollment administrator of the certified verification document.

Implementations of the method can include one or more of the following features. The method can include entering biometric data using the device before receiving a request for verification.

Providing verification information can include presenting an identity document to the third party. It can also include affirming to the third party that the information in the verification document is correct and that the identity document is authentic and entering biometric data using the device in the presence of the third party.

Certification can indicate that the third party confirmed that the identity document is consistent with the information in the verification document; and witnessed the user entering biometric information into the user's device. In which case, receiving confirmation of enrollment may additionally require receipt by the enrollment administrator of confirmation that biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification.

The third party may be a notary public and affirming can be performed under oath.

The method may further include, after receiving confirmation of enrollment, requesting to link the user's enrolled identity with the digital identity of another entity enrolled on the network. This may include providing verification that the user is an authorized representative of the entity or that an authorized representative of the entity has granted permission for such linking.

Entering the user's identification data and biometric data may be performed shortly after the birth of the user. An attestation by a witness of the birth may be entered before receiving a request for verification. A request for verification may be received when the user has reached a competent age.

In general, in a further aspect, a system for securely enrolling a user onto a network includes a device arranged to collect identification data indicative of the user's identity; and transmit the identification data and a hardware identifier uniquely associated with the device; and a sever in communication with the device, the server arranged to receive the

identification data and hardware identifier from the device; link the user's identity with the hardware identifier; transmit a request to the device to verify the user's identity using a third party; and upon verification, enroll the user's identity and linked hardware identifier onto the network.

Implementations of the system can include one or more of the following features. The network can be a secure network. The device may include a hardware security module that encrypts the input to and output from the device. The hardware security module may use symmetric or asymmetric key encryption. The hardware security module can have a direct connection to the network. It can be tamper resistant or quantum-crypto immune.

The device can be a mobile device, such as a mobile phone or tablet computer.

In general, in a further aspect, a method of securely enrolling a user onto a network, includes obtaining identification data indicative of the user's identity, the identification data being acquired via a user's device; linking the user's identity with a hardware identifier uniquely associated with the user's device; verifying user's identity by videoconference using user's device; and upon receiving the verification, enrolling the user's identity and linked hardware identifier onto the network.

Implementations of the method can include one or more of the following features. The videoconference can be hosted by an authorized agent, such as a person or a bot.

The method can further include prompting the user to enter biometric data into the user's device before verifying. The method can further include receiving confirmation, before enrolling, that biometric information entered by user before verifying by

videoconference matches biometric data collected during videoconference.

Verifying the user's identity by videoconference can include requesting the user to present an identity document to the authorized agent via videoconference; and confirming that the identity document is consistent with the identification data provided by the user. Verifying user's identity by videoconference can further include requesting the user to affirm to the authorized agent via videoconference that: the user is attempting to enroll onto the network; the provided identification data is correct; and that the presented identity document is authentic. Verifying user's identity by videoconference can further include requesting user's device to passively collect user biometric data during videoconference. Verifying user's identity by videoconference can further include detecting liveness

The identity document can be a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport. The identification data can include at least one of a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color.

The method can further include, before enrolling, positively determining that the user's identity has not been previously enrolled on the network.

In general, in a further aspect, a method of securely enrolling a user onto a network, includes entering identification data indicative of the user's identity using a device; sending the identification data and a hardware identifier uniquely associated with the device via a network to an enrollment administrator; receiving a request for verification of the user's identity by videoconference; verifying identity by videoconference; and receiving, upon verification, confirmation of enrollment of the user's identity associated with the hardware identifier onto the network.

Implementations of the method can include one or more of the following features. The videoconference can hosted by an authorized agent, such as a person or bot.

The method can further include entering biometric data using the device before verifying.

Verifying identity by videoconference can include presenting an identity document to the authorized agent via videoconference. Verifying identity by videoconference can further include affirming to the authorized agent via videoconference that: the user is attempting to enroll onto the network; the provided identification data is correct; and that the presented identity document is authentic.

The identity document can include a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport. The identification data can include at least one of a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color.

In general, in a further aspect, a system for securely enrolling a user onto a network includes a device configured to: collect identification data indicative of the user's identity; participate in videoconferencing; and transmit the identification data and a hardware identifier uniquely associated with the device; and a sever in communication with the device, the server configured to: receive the identification data and hardware identifier from the device; link the user's identity with the hardware identifier; transmit a request to the user, through the device, to verify the user's identity by videoconference; and upon verification, enroll the user's identity and linked hardware identifier onto the network. Implementations of the system can include one or more of the following features. The network can be a secure network.

The device can include a hardware security module that encrypts the input to and output from the device. The hardware security module can use symmetric or asymmetric key encryption. The hardware security module can have a direct connection to the network. The hardware security module can be at least one of tamper resistant or quantum-crypto immune.

The device can be a mobile device, such as a mobile phone or tablet computer..

Among other advantages, implementations of the technology may allow for the creation of a globally unique registry of identities enrolled on the secure network. It may allow a trusted identity provider to verify that the person accessing the network is the registered user and to facilitate a bi-directional secure connection between enrolled users and entities on the network. Instead of storing private data with each enrolled entity, implementations of this technology would allow the user to store private data only with the trusted identity provider. The use of a TidP authorized agent for videoconference verification may allow for faster, simpler, and potentially automated, real time verification of user identity. It may also obviate the use of third parties unaffiliated with the TidP.

Videoconference verification can also provide an effective audit trail. For example, a recording of the videoconference can be used as part of an audit trail where the authenticity of an account or transaction is later challenged.

The details of one or more implementations of the subject matter of this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, the drawings, and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram of an embodiment of a system for securely enrolling a user onto a network.

FIG. 2 is a flowchart showing steps in the operation of the system shown in FIG. 1.

FIG. 3 is a flowchart showing steps in an exemplary application process performed by the user for securely enrolling a user onto a network.

FIG. 4 is a flowchart showing steps in an exemplary application process performed by the trusted identity provider for securely enrolling a user onto a network. FIG. 5 is a flowchart showing steps in an exemplary third party verification process for securely enrolling a user onto a network.

FIG. 6 is a flowchart showing steps in an exemplary enrollment process performed by the trusted identity provider for securely enrolling a user onto a network.

FIG. 7 is a flowchart showing steps in an exemplary device verification process for securely enrolling a user onto a network.

FIG. 8 is a schematic diagram of an embodiment of a system for authenticating a user to a secure network.

Fig. 9 is a schematic diagram of an embodiment of a system for securely enrolling a user onto a network using videoconferencing.

FIG. 10 is a flowchart showing steps in an exemplary application process performed by the trusted identity provider for securely enrolling a user onto a network.

FIG. 11 is a flowchart showing steps in an exemplary verification process for securely enrolling a user onto a network using videoconferencing.

FIG. 12 is a flowchart showing steps in an exemplary enrollment process performed by the trusted identity provider for securely enrolling a user onto a network.

FIG. 13 is a schematic diagram of an example computer system.

Like reference numbers and designations in the various drawings indicate like elements.

DETAILED DESCRIPTION

Referring to FIG. 1, a system 100 for securely enrolling a user onto a secure network includes a device 110 and a trusted identity provider ("TidP") 122. TidP 122 has access to a secure network 130. Before enrollment, the user does not have access to network 130. The device communicates with a TidP server 120 over a public network 118, such as the internet. Device 110 is a mobile phone or a computer or any other personal networked device (e.g., networked wirelessly or wired) capable of collecting and transmitting user information related to applying to enroll onto network 130. Device 110 includes a user interface 114 (e.g., a camera, a display, a keyboard, and/or and touch panel) which allows the user to interact with device 110. Device 110 also includes a hardware security module ("HSM") 116, which can be used for encrypting data and establishing secure communication channels. HSM 116 is a physical computing component (e.g., a SIM card or other integrated circuit) that safeguards and manages digital security keys for strong authentication and provides cryptoprocessing, which includes functionality such as security key generation (also called cryptographic key generation), encryption, decryption, and secure key storage. TidP 122 includes sever 120 in communication with secure network 130 and an enrollment

administrator 140. Enrollment administrator 140 can include a staff of one or more people able to access and communicate with secure network 130 using server 120. The enrollment administrator 140 can also be an electronic processor configured to communicate with server 120 and perform auxiliary enrollment functions.

Referring also to FIG. 2, a method 200 for securely enrolling a user onto a network is shown. In step 210, user 101 applies for enrollment onto TidP network 130 using device 110. In step 220, TidP 122 processes the application and sends the user a request for identity verification via third party 150. The third party verifies the user's identity in step 230. Upon verification, the user is granted access to TidP network 130 via device 110 in step 240.

Generally, network 130 is composed of conventional networking components, including servers, clients, switches, routers, etc. Servers, such as server 120 in FIG. 1, are used to enroll a user onto the secure network, or, as detailed further below, to authenticate an enrolled user when the user requests access to the network. In some implementations, network 130 includes quantum computers or devices that utilize quantum encryption.

Networks are composed of connected "nodes," e.g., redistribution points or communication endpoints. Network 130 has at least two types of nodes: edge nodes and remote nodes. Edge nodes include user controlled devices enrolled on the network, such as device 110. Remote nodes include nodes not under the control of the user, such as servers, switchers, and routers.

In general, network 130 is a secure network. For example, network 130 may be a private network, e.g., run by a private network operator, with access controlled solely by TidP 122. In some implementations, the only entities accessing the network other than TidP 122, are those that are enrolled securely through the process shown in FIGs 1-2. In addition, in these implementations, access is only provided over the device 110 used in the enrollment process, and other devices may be later registered with the TidP using the same enrolled identity. In that case, the TidP can verify user identity with confidence and be the single source of user information for entities on network 130. The TidP would also be the only party that stores user information necessary for authenticating transactions between parties on network 130. The network may be secured with additional features. For example, the components forming network 130 can be physically and/or logically isolated from public networks, such as public network 1 18. The network's data centers and/or some or all of its remote nodes may also be directly connected, e.g., via fiber optic cable. TidP may also have a direct connection, e.g., a physical tether via fiber optic cable, to the secure network. A physical tether may aid in protecting data coming to and from the TidP from being compromised.

Further, TidP 122, or a partnering private network operator of network 130, may have exclusive physical control over the remote nodes of secure network 130. In this manner, network 130 servers and data centers can be physically protected from unauthorized access. Edge nodes of network 130, such as device 110, may not be physically secured if they are portable, such as tablets and mobile phones. However, if the node is a desktop computer, for example a computer terminal used in a corporate or government facility, it may be physically secured in a secure room.

Redundancy in remote nodes may be used to ensure network availability and provide additional security. For example, the nodes may have unique secrets that would allow them to detect intrusion or compromise of other nodes. Various reconciliation schemes can be used to mitigate incorrect decisions issued by the breached nodes. For example, a decision to authenticate or enroll a user onto the network can be based on agreement of all relevant nodes. As another example, the decision can be based on a majority of the node decisions. In addition, system administrators, such as enrollment administrator 140 in the case of an enrollment decision, can be notified of the disagreement in node decisions to investigate and rectify the situation.

In general, network enrollment begins with an application process by a user. FIG. 3 is a flowchart showing an exemplary application process 300 by user 101 in applying for network enrollment. This process may be implemented, for example, when user 101 purchases device 1 10, e.g., a mobile phone or tablet. User 101 interacts with device interface 114 of device 1 10, inputting biometric data 320, e.g., fingerprints, and identification data 340, e.g., birth date or address, that uniquely describe the user's identity.

User 101 enters biometric data 320 that is maintained in local storage 330 of the device. Biometric data includes biometric identifiers that are distinctive, measurable characteristics used to label and describe individuals. Biometric identifiers can be categorized as physiological versus behavioral characteristics. Physiological characteristics are related to the shape of the body. Examples include, but are not limited to, fingerprint, palm veins, face recognition, DNA, palm print, hand geometry, iris recognition, retina and odor/scent. Behavioral characteristics are related to the pattern of behavior of a person, including but not limited to lip movement, face movement, typing rhythm, gait, and voice.

Device 1 10 includes user interface 114, which can use the device camera, display and keypad or touch panel, to measure biometric data. Device 1 10 may have other cameras and sensors for gathering images (still and video), microphones and other sensors for gathering audio data (e.g., speech data), IR cameras and other thermal image sensors, accelerometers for measuring gait, computer mouse (e.g., for gathering data on scrolling, moving, clicking), trackpads (e.g., scrolling and swiping), keyboards, keypads, and touchscreens.

Depending on the available sensors and the user interface, the device may be configured to include a facial recognition module (e.g., 2D image facial recognition, 3D image facial recognition), a hand geometry module, a keystroke dynamics module, a speech recognition module, a mouse motion module, a video analysis module (e.g., for gait detection), an audio analysis module (e.g., voice recognition modules, both text dependent and text independent modules), an accelerometer data analysis module (e.g., for gait detection), a language analysis module, a heartbeat module, a driving behavior module, a fingerprint module, an iris module, a foot shape/pressure module, an ear biometric module, an operator signature module, a thermal signature module, a device fingerprint module (e.g., for mobile devices, cars, computers, etc. ; see, e.g., https://audiofingerprint.openwpm.com), a network forensics module, a license plate recognition (LPR) module (e.g., fixed or cascade), a driving behavior module, an audio signature module (e.g., for detecting the audio signature of a car), an NFC module, a fixed low energy wireless module, and a cascade low energy wireless module.

Sensors may also be used to check that the biometric data 320 is not being spoofed or presented under duress. More details are discussed below.

In addition to entering biometric data, user 101 also enters identification data 340 using device user interface 1 14. Identification data 340 includes personal or sensitive information, other than biometric data 320, uniquely associated with user's identity.

Identification data 340 includes any one or more of the following: user's legal name, address of work or residence, birth date, social security number, driver's license number, e-mail, or any other information classified as personally identifiable information ("ΡΠ") or sensitive personal information ("SPI") by government regulatory bodies, such as the National Institute of Standards and Technology, or by laws or regulations, such as the Privacy Act of 1974. In certain embodiments, identification data 340 also includes a user's physical attributes, such as height, weight, eye color, hair color, etc.

In particular, user may enter identification data using the keypad or touch panel. Depending on the availability of sensors on the device, user may also enter data using a microphone.

Device 110 collects the identification data 340 and sends the information over network 118 to TidP 122. In some implementations, user 101 affirms the accuracy of identification data 340 by "signing" with biometric data 320 before transmission to TidP 122.

HSM 116 encrypts the identification data 340 and sends it to the TidP along with a hardware identifier 350 uniquely associated with device 110. The hardware identifier may be any identifier that uniquely identifies device 110 and authenticates that data was sent by that device. For example, the identifier may be the serial number of the HSM.

The HSM includes a processor, a random-access memory ("RAM"), a read-only memory ("ROM"), and a storage medium. The HSM is an integrated circuit capable of providing basic computing functions, and is configured to encrypt and securely store (and/or transmit) identification data 340 and biometric data 320, run various types of instructions stored in the storage medium, and provide a secure interface between TidP 122 and device 110. The module may come in the form of a plug-in card or an external device, e.g., a thumb drive hardware keystore, such as a USB ("Universal Serial Bus") HSM or an RSA key ("Rivest-Shamir-Adleman" cryptosystem key), that attaches directly to device 110 and provides an interface with TidP 122. The HSM may also be built into the device's permanent hardware.

HSM 116 supports secure input and output for device 110, e.g., via encryption. In certain implementations, in order to establish a secure communication channel with TidP's server 120, the TidP server needs to also have encryption capabilities. For example, the server may have its own HSM.

Various cryptography systems are contemplated, including symmetric and asymmetrical cryptography. In symmetric key cryptography, both parties to the

communication (such as the TidP and device 110) need to be in possession of a secret key (also known as a "shared secret") that allows them to encrypt and decrypt exchanged messages via a private information link. The use of this unique key also allows both parties to authenticate the sender. For an HSM built into device 110 (shown in FIG. 1 as 116), if TidP has a relationship with the device manufacturer, it may learn at the time of manufacturing which HSM is installed into which device and the unique private encryption key associated with that HSM. Thus, if the manufacturer maintains supply chain integrity to ensure that keys are never leaked, then only TidP 122 and HSM 116 would be in possession of the private key associated with device 110. If, on the other hand, TidP does not have a relationship with the manufacturer, the HSM 116 key would have to be transmitted to the TidP when user 101 applies for enrollment via device 110 (along with identification data 340 and hardware identifier 350). Alternatively, TidP 122 and device 110 may utilize the Diffie- Hellman key exchange scheme, which allows both parties to establish a shared private key ("secret") without directly transmitting their private keys over an unsecure channel. See https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange.

In an alternative cryptography communication method, asymmetric key cryptography uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. In practice, both parties (e.g., TidP 122 and device 110), when sending data, would sign the outbound data with their own private key and encrypt the outbound data with the other party's public key. When receiving data, both parties would decrypt the inbound data using their private key and verify the signature using the corresponding public key. To establish two-way encrypted communication between TidP 122 and device 110, the parties would have to exchange public key pairs corresponding to their respective HSM. The TidP may learn the public key of the device's HSM from the manufacturer or would receive it from the HSM during the registration process (along with identification data 340 and hardware identifier 350).

In general, the TidP may provide greater security for the device-to-TidP

communication channel if it can embed its algorithms directly into HSM 116 at the time of manufacturing, and learn of (and/or encode) the HSM encryption keys at that time. In that case, encryption keys (public or private) would not need to be exchanged over unsecure channels. In addition, greater integration of the TidP algorithms with device 110 hardware would allow for better protection of data collected by the device for enrollment and authentication. For example, HSM can be programmed to establish a secure route with the device's biometric sensors (part of user interface 114), preventing unauthorized data access, as described further below. If TidP is not able to embed its algorithms directly onto the device's hardware, then it would have to instruct HSM 116 through the device's operating system using available application programming interface commands. In that case, biometric data 320 would be collected in the main memory of the device, and not locally in HSM 116, but may still be encrypted by the HSM.

In some implementations, where TidP is able to directly program HSM 116 with its algorithms, HSM 116 can encrypt collected biometric data 320 and store it securely in its own local storage 330. The data 320 may be stored in HSM's ROM to prevent modification of user biometric information. In some implementations, the device's biometric sensors (part of user interface 114) are encrypted when in use, or additionally when not in use. Sensors that collect data 320 may either be embedded on the actual HSM or have a secure route to the HSM. With the secure route, sensors should be able to provide output exclusively to the HSM, to be processed by the HSM algorithm, instead of being accessible in main memory, where there is a higher potential for fraudulent access. The secure route would also prevent the possibility of biometric data skimming.

In some implementations, HSM 116 can establish direct connection to the TidP server 120. A direct connection can ensure that the data will make it to the server 120 as intended and that there is no man in the middle that can read, write, delete or modify the data after it leaves the HSM and before it reaches the secure network. Additional details about establishing a direct connection are provided further below.

HSM 116 may have various security features that may provide both logical and physical protection of its data from non-authorized use and potential adversaries. For example, its private encryption key, or other security keys generated by the HSM, cannot be accessed via the user interface. In addition, the HSM may have tamper or probing detection that would allow it to self-destruct the private encryption key, and its other security keys, in the event of unauthorized access.

HSM 116 may also be capable of running a secure output to a user interface or graphic user interface on device 110, ensuring that the HSM source code is not exposed, that the source code is not editable, and that the software running on the HSM is authentic.

In general, device 110 may have additional security features for highly secure applications. For example, device may have multiple HSMs which may be clustered and provide backup redundancies such as fans and power supplies in case one of the HSMs is broken or destroyed. In another example, cryptoprocessing by the HSM may be designed to be to use cryptographic algorithms that are secure against an attack by a quantum computer. In some implementations, device 110 may need to meet certain security standards, determined by the TidP, to be allowed access to network 130. For example, the device 110 may need to have a built in HSM as detailed above. The device 110 may also need to have the sensors necessary for collection of biometric data as specified by the TidP.

In some implementations, the identification data 340 is provided not to device 110 but on a physical form transmitted to TidP. In that case, biometric data 320 may still be supplied to the device as part of the application process, either as an affirmation of accuracy of identification data 340 or possibly for an additional verification step during the enrollment process involving a comparison between biometric data 320 and biometric data re-entered by the user at a later time.

FIG. 4 shows steps in an exemplary application process 400 performed by the trusted identity provider for securely enrolling a user onto a network. TidP 122 receives the encrypted identification data 340 and hardware identifier 350 from HSM 116 in step 410. TidP processes the data either manually or automatically (performed by enrollment administrator 140 in communication with TidP server 120). In some implementations, the TidP may run a background check on user 101 before proceeding.

In step 420, identity of user 101 is linked by TidP 122 with the hardware identifier 350 uniquely associated with device 110. TidP 122 then generates and sends the user a verification document containing at least some of the user's identification data 340, with a request for verification in step 430. If the verification document is digital it will be encrypted and sent to device 110 by server 120. If it is physical it will be sent to user 101 by TidP enrollment administrator 140, printed on a forgery resilient document and in tamper evident transport packaging.

FIG. 5 shows an exemplary process 500 of verification before a third party 150. In step 510, user 101 receives the verification document from TidP 122 with a request for verification. The request contains instructions to the user to verify their identity before third party 150.

In process 500, the third party is a notary public. Alternatively, or additionally, other third parties authorized by the TidP to verify user identity may be used.

In step 520, user 101 brings the verification document (digital copy on device 110 or physical document), device 110, and an identity document that identifies the user to the notary. The identity document may or may not have a photograph of the user. In some implementations, the identity document is a government issued identity document, such as a social security card, birth certificate, a state-issued driver's license, state-issued identification card, military identification card, resident alien identification card (e.g., green card), or a passport. In some implementations, the identity document is privately issued, such as a corporate identity document (e.g., employee ID) or a school identification card. A credit or debit card may also be an identity document.

Generally, a notary public third party 150 may be limited by its state appointing body with respect to the identity documents the notary can use for identity verification. For example, a notary public may only be able to accept a state-issued driver's license, state- issued identification card, a U.S. military identification card, a green card, and a U.S.

passport. If a third party authorized by the TidP is used instead of a notary public, the TidP may expand the scope of acceptable identity documents.

In step 530, the user 101 swears under oath that the user's identity document is authentic and that the information in the verification document provided by the TidP is correct. In step 540, notary 150 compares information in the identity document to the identification information 340 in the verification document. If the information matches, the notary notarizes the verification document in step 550. The notary may also check that the user's physical characteristics match any relevant identification data 340, or any relevant information in the identity document, before notarizing. The user may then send the notarized verification document to TidP in 560.

Where the verification document is digital, a TidP approved third party may be used. The third party would perform all the steps of the notary, except that the party would be able to digitally certify the verification document instead of notarizing as described above. In this case, the third party would have had to previously register biometric data, such as fingerprint data, or some other sort of digital signature data with TidP. TidP 122 may solicit additional steps to verify that the third party was authorized by TidP to perform verification. For example, the third party may need to have their own device capable of verifying their identity to the TidP.

FIG. 6 shows the exemplary final enrollment process 600 performed by TidP 122. In step 610, the TidP receives the certified (or notarized) verification document, either digitally or in physical form. If the document is physical, it is received by enrollment administrator 140, who would convert the verification document into digital form.

In step 620, the TidP server 120 verifies that the user's identity is unique on network 130. For example, server 120 may cross-reference user's identification data 340 with all other users already enrolled on network 130. If there is overlap of identification data with an existing user, server may determine whether the overlap is significant enough to indicate that user is already enrolled onto the network. If overlap is significant, server will not grant access to network 130 and may prompt the user for further input.

If the user's identity is determined to be unique on the network and no other abnormalities were detected (by the third party 150, or, optionally, the enrollment administrator 140), server 120, in step 630, grants user 101 access to network 130 via device 110.

In general, after enrollment, user 101 may be able to register additional devices to access network 130, if those other user devices have a key logged with the TidP and meet the same hardware and security criteria as device 110 described above.

Step 620 may alternatively be performed during initial application processing, along with step 420 in FIG. 4. Step 620 may also involve further verification. For example, server 120 may verify that verification document is certified by an authorized third party agent 150 with the agent's registered credentials. TidP may also cross-check user identification data 340 against other sources of information, such as government records, for any

inconsistencies.

In general, as mentioned above, biometric data 320 may be compared with biometric data entered at a later stage of the enrollment process as an additional verification step. Referring to FIG. 7, the additional verification process 700 may precede granting network access to user in 630. As previously discussed, in step 710, user 101 enters biometric data 320 into device 110 as part of the initial application process. This data is securely stored on device 110. In step 720, user inputs biometric data again during the verification process before a third party. In this implementation, the third party certifies to the TidP that the user properly entered biometric data into device 110. In step 730, device 110 compares the two entries of biometric data, and, in step 740, sends a confirmation token to TidP 122 if the entries match. With these implementations, the confirmation token would have to be received by server 120 before the TidP can grant user network access in 630.

In certain implementations, biometric data 320 is encrypted and transmitted to TidP 122 instead of only being stored locally on device 110. In these implementations, the TidP would perform the comparison of entered biometric data at step 730 before granting the user access in 630. Specific implementations of the enrollment process are contemplated below. For example, a user's identification and biometric data may be collected at birth, in a process analogous to issuing a birth certificate, and used at a later date to allow user 101 to access network 130. In such implementations, the user's identity is traceable back to the user's origin, providing an extra layer of verification. For example, device 110 may be used to obtain user data shortly after birth, ostensibly before any identity fraud or ambiguity is possible. For example, within a few days after birth (e.g., 10 days), or before user is released from the hospital after birth. Biometric data 320 may include fingerprints, palm prints, and/or iris scan data. Identification data 340 may include names of user, mother, father, and/or other designated guardian.

Similar to an actual birth certificate, collected biometric and identification data may be verified by a third party, e.g., a doctor or an authorized TidP third party. The data may also be affirmed (e.g., with biometric signatures) by at least one of the parents of the newborn. The data is transmitted to TidP 122 after verification.

When user 101 reaches a competent age, TidP 122 may send the user a request for verification of identity, as detailed in FIG. 2, step 220. After verification, the user may be granted access to secure network 130. Age of competence may be defined by state law as the age at which the person has the capacity to make the decision to enter into a contract. For example, age of competence may be 16 years of age, or 18 years of age. The verification step may be modified to account for the fact that certain biometric markers change as a person ages, such as fingerprints.

In general, network 130 is accessible only to users securely enrolled as described above. These users can then register an entity, such as a corporation, onto the network. For example, during incorporation of the agency, the authorized agents of the entity can submit documentation to a government office responsible for incorporation, requesting the agent identities be digitally bound to the entity on network 130. In another example, after incorporation, TidP and/or a government agency responsible for regulating the entity may request that certain verification steps be taken by an agent of the entity to verify that they are authorized to take actions on the agency's behalf on network 130.

An agent registered on the network as representing and entity may then delegate the authority to take acts on behalf of the entity to another enrolled user on the network. The delegation process may be specified by the entity, the TidP, or a government agency responsible for regulating agency acts. Any delegated authority may be revoked or diminished via a process specified by the entity and/or the TidP.

Generally, a user enrolled on network 130 may form relationships with other users or entities enrolled on the network. For example, a user may perform transactions with entities enrolled on the network, or may provide the entities with information using the TidP network.

In certain implementations, a user selects a registered entity from a TidP registry. If the entity is not in the TidP registry, the user may request TidP to send an authorized agent of the entity a form for enrollment onto the TidP network.

The user sends a request to the entity to form a relationship through the TidP network. The user may specify what specific permissions it is requesting from the entity. The entity may also request specific information from the user before a relationship is formed. After both parties consent, TidP grants the user allowed privileges, and sends the information requested by the entity. Such a relationship may be revoked by either party through the TidP.

The relationship may allow the user to request the entity to perform a transaction on its behalf, or the entity may request to perform the transaction on the user's behalf. For example, if the entity is a financial institution, the entity can request that the user authorize a withdrawal through the TidP. The user may approve such a transaction by authenticating their identity over their device 110, as detailed below.

In general, after enrollment, the user's identity can be remotely authenticated by device 110 and a TidP authentication server when the user requests access to network 130, or requests to validate their identity to another entity on the TidP network in order to form a relationship or perform a transaction with that entity. For example, device 110 can authenticate user 101 by collecting biometric data with the device's sensors and securely storing the data in the HSM, as described above for the application process. If the entered data matches data stored on the HSM's ROM, the HSM generates an authentication token and transmits it to the TidP authentication server or directly to the requesting entity to complete authentication.

If attribution tokens are exchanged directly between parties on the network, additional security steps may be necessary. For example, the user and entity may need to have a unique key pair that allows the user's device to sign and encrypt data in a way that only the entity can verify the attribution token.

In another method of authentication, as described below, the user may connect mentally with device 110 using a Neurolink tool, and undergo mental authentication challenges performed by the device to verify user identity. For example, the device would ask the user a security question and the user would mentally answer it.

During authentication, the attribution token may be signed with the device's unique private encryption key before it is transmitted to the TidP. The token may contain information such as when and where authentication took place, and for what purpose.

In certain implementations, instead of storing biometric data on the user's device, biometric data may be sent to TidP for correlation with previously entered data before authentication is complete.

To provide additional security during authentication, the TidP authentication server may be used to allow a device access to a secure network directly, without use of a public network. Where device 110 is a desktop computer, such direct connection may be provided by physical tethering, such as using a fiber. For example, the computer could have a toggle switch on it, one mode connecting it to the public internet infrastructure and the other mode connecting it the secure private network infrastructure for network 130.

A direct connection may also be provided for mobile devices. Referring to FIG. 8, a system 800 includes a mobile device 810 (corresponding to device 110 in FIG. 1), a mobile network 820, an IP exchange (IPX) 830, a TidP authentication server 840, a public network 118, and a secure network 130. Mobile device 810, using cellular technology such as EDGE/3G/4G/5G, is in communication with the mobile network 820. IP exchange 830 is in communication with mobile network 820, TidP authentication server 840, public network 118, and secure network 130.

In general, mobile network 820 is a provider of connectivity between mobile device 810 and IP exchange 830. In some implementations, mobile network 820 is a Mobile Network Operator (MNO). In some implementations, mobile network 820 is a Mobile Virtual Network Operator (MVNO) that may operate through the infrastructures provided by the MNO.

In a conventional system, the secure network 130 is typically interfaced to the internet, an example of public network 118, and access to secure network 130 is provided through a public, unsecured network. For example, an encrypted communication channel to the secure network 130 may be established over the public network, or a secure tunnel, such as a virtual private network, may be established through the public network to gain access to the private network. In contrast, IP exchange 830 is separated from the public internet, both logically and physically, and thus not addressable nor visible from the internet (e.g., public network 118). The IP exchange 830 provides exchange of IP based traffic between various network entities such as mobile network 820, fixed operators, as well as other types of service provider such as Internet Service Providers (ISP) via an IP based Network-to-Network Interface. By communicating through IP exchange 830, a private and secure communication channel can be established directly between mobile device 810 and secure network 130 without going through the internet.

In some implementations, upon successful authentication of the user's identity via user's mobile device 810, as described above, the authentication server 840 notifies IP exchange 830 of the successful authentication of the user. Based on this information, IP exchange 530 may grant mobile device 810 access to secure network 130 by making secure network visible, or reachable, to mobile device 810. Such a scheme shields secure network 860 from various threats in public network 118, as secure network 130 is reachable only to authenticated devices. Furthermore, because the authentication provided by the

authentication server is an authentication of the identity of the user of the mobile device, identity of the user can be made known to other connected devices and users of the secure network, providing attribution of actions performed by the devices on the secure network.

Alternatively, device 810 may be a satellite phone and network 820 may be a satellite phone network.

To prevent fraudulent transactions or access, device 110 (or 810) may also be configured to detect duress during authentication. Biometric sensors of the device may be programmed to detect changes in behavior by collecting information about changes in the user's style of typing, voice, or heartrate. In the event user duress is detected by device 110, the TidP authentication server may request that another party verify the transaction instead of the user.

In some implementations, authentication is performed continuously, as described in detail in SYSTEM FOR USER IDENTIFICATION AND AUTHENTICATION, App No. 62/533,598, filed on September 21, 2016, the entire contents of which are incorporated herein by reference.

Device 110 may also be configured to check for liveness when collecting biometric data, either for enrollment or authentication. This process can ensure than biometric data is entered by a live user and is not being spoofed. For example, input sensors of the device's interface 114 may measure heartrate, perform reaction tests on the iris, or detecting body heat through thermal imaging.

In certain implementations, the device may be paired with another device that determines the thoughts of the user and detects duress. For example, devices that provide a direct connection with a device implanted in a user's brain are being developed by Neuralink (San Francisco, CA).

Generally, device 1 10 may be configured to provide verification of its authenticity to a user. This prevents the user from inputting sensitive data into an untrusted device that is imitating the user's device. For example, device 1 10 can be configured to respond to a signal emitting chip, such as an RFID tag, worn by the user. The chip may be manufactured to uniquely identify the user and may be embedded in a personal object worn by the user, such as a wedding ring, or implanted in the user's body. When the chip comes into physical proximity with the device, the device may be configured to present the user with a secret known only to the user and stored only locally on the device, such as a picture or text. If the presented secret is correct, the user may continue inputting information into the device.

In some implementations, the RFID tag may also display a dynamic code. If the device comes into proximity with the tag and displays the same dynamic code, the user may proceed to use the device.

In some embodiments, the device 1 10 may have an implanted Neurolink tool that allows the user to mentally verify the authenticity of the device. For example, the user would mentally request the device to display a series of numbers. If the device redisplays the correct series, the user can be confident the device is authentic.

The foregoing embodiments contemplate the use of a third party 150 for verification. Other embodiments are also contemplated, including using videoconferencing (e.g., hosted by a TidP authorized agent) for identity verification. The use of a TidP authorized agent for videoconference verification may allow for faster and simpler verification of user identity. If completely automated, near real time verification of user identity is also possible. The use of videoconferencing can additionally or alternatively obviate the use of third parties unaffiliated with the TidP. Videoconference verification can also provide an effective audit trail. For example, a recording of the videoconference can be used as part of an audit trail where the authenticity of an account or transaction is later challenged.

Referring to FIG. 9, a system 900 for securely enrolling a user onto a secure network includes a device 110 and a trusted identity provider ("TidP") 122. System 900 is similar to system 100, with the following exceptions. Instead of using third party 150, identity verification in system 900 is performed by the user over videoconference via device 110 with a TidP authorized agent 950. Device 110 is additionally configured to participate in videoconferencing.

Authorized agent 950 cay be a person or a bot. Agent 950 can communicate with TidP server 120 and participate in videoconferencing with device 110. Videoconferencing can involve live streaming or sending video files to TidP for further processing.

TidP 122 additionally includes a videoconference analysis module 960. The videoconference analysis module 960 can be completely automatic or at least in part operated by a person. The module can run algorithms to analyze videoconference image and audio data. Enrollment administrator 140 can optionally be used to perform quality control over the performance of agent 950 or module 960.

Some or all steps recited below as being performed by authorized agent 950 can alternatively be performed by module 960 or enrollment administrator 140. All three TidP constituents can access the user's entered identification data 340 from server 120.

As in prior embodiments, user 101 applies for enrollment onto TidP network 130 using device 110. Upon receipt of the user's application, TidP 122 sends the user a request for identity verification. Upon verification, the user is granted access to TidP network 130 via device 110.

Referring to FIG. 10, an exemplary application process 1000 performed by the trusted identity provider for securely enrolling a user onto a network is shown. The user applies for enrollment by entering identification 340 and biometric data 320 into device 110, as discussed above in reference to FIG. 3. TidP 122 receives the entered encrypted

identification data 340 and hardware identifier 350 from the device's HSM 116 in step 1010. TidP processes the data either manually or automatically (performed by enrollment administrator 140 in communication with TidP server 120).

In step 1020, identity of user 101 is linked by TidP 122 with the hardware identifier 350 uniquely associated with device 110. TidP 122 then generates and sends the user a request for verification in step 1030.

FIG. 11 shows an exemplary process 1100 of verification with TidP authorized agent 950. In step 1110, user 101 receives a request for verification from the TidP. The request contains instructions for the user to verify their identity with TidP authorized agent 950 via videoconference using user's device 110. The request can identify documents that the user should present to the authorized agent, such as the identity documents mentioned above.

In step 1120, user 101 joins the videoconference via device 110. The authorized agent 950 can prompt user 101 for identifying information. For example, the agent can request that the user affirm that the user is attempting to enroll onto network 130 or that the identification data 340 previously provided by the user to TidP is correct, as shown in step 1130. The authorized agent can also request that the user hold up identity documents to the device's camera. The agent can request that the user affirm that the identity documents presented by the user are authentic, as also detailed in step 1130.

In step 1140, TidP compares information in the presented identity document, such as the user's birth date and legal name, to corresponding identification information 340 previously provided by the user. For example, the analysis module 960 can analyze the videoconference data in order to perform such comparison.

TidP may also request device 110 to passively collect user's biometric data during the videoconference. Such passive collection can utilize the same device sensors used to collect biometric data during the application process, as discussed previously. TidP or agent 950 may determine whether biometrics collected during the videoconference match the entered biometrics in step 1150. If biometric data 320 is stored only locally on device 110, then the device can perform the comparison between the entered biometrics 320 and passively collected biometrics, and can send TidP server 120 a confirmation token to confirm the match. If biometric data 320 is encrypted and transmitted to TidP 122, then TidP, e.g., the enrollment administrator 140, can perform the comparison of biometric data.

Passively collected biometric data can also be compared for consistency against the presented identity documents. For example, the user's eye color shown on an identity document can be compared to the user's eye color observed during the videoconference. In another example, the user's age can be approximated using biometrics and compared to the user's age listed in a presented identity document.

Agent 950 can optionally use the videoconferencing step to test for liveness. Liveness tests can be used to determine if the user is in fact present during the videoconference. This step may prevent fraudulent enrollment by ensuring that a prior recording of the user is not being illicitly played during the videoconference. For example, agent 950 can detect liveness by prompting the user to state the current time and date at some point during the

videoconference. The agent can also request that a user track a dot displayed over the videoconference. The agent can alternatively or additionally flash lights during the videoconference to observe the user's reaction. Liveness tests may also be used to detect spoofed biometrics or user coercion by continuously monitoring the user's biometrics for any changes. If significant changes to biometrics are detected during the videoconference, the TidP may take remedial measures, such as prompting the user to attempt verification at another time.

If the agent 950, or TidP via videoconference analysis module 960, determines that the user's entered identification data is consistent with the presented identity documents and that the entered biometric data matches the passively collected biometrics, verification is sent to TidP server 120 in step 1160.

FIG. 12 shows the exemplary final enrollment process 1200 performed by TidP 122. In step 1210, the TidP receives a verification based on the results of the videoconference, either from TidP authorized agent 950.

In step 1220, the TidP server 120 verifies that the user's identity is unique on network 130. For example, server 120 may cross-reference user's identification data 340 with all other users already enrolled on network 130. If there is overlap of identification data with an existing user, server may determine whether the overlap is significant enough to indicate that user is already enrolled onto the network. If overlap is significant, server will not grant access to network 130 and may prompt the user for further input.

If the user's identity is determined to be unique on the network and no other abnormalities were detected by the agent 950, server 120, in step 1230, grants user 101 access to network 130 via device 110.

Step 1220 may alternatively be performed during initial application processing, along with step 1020 in FIG. 10. Step 1220 may also involve further verification. For example, TidP may cross-check user identification data 340 against other sources of information, such as government records, for any inconsistencies.

FIG. 13 is a schematic diagram of an example computer system 1300. The system 1300 can be used to carry out the operations described in association the implementations described previously. In some implementations, computing systems and devices and the functional operations described above can be implemented in digital electronic circuitry, in tangibly-embodied computer software or firmware, in computer hardware, including the structures disclosed in this specification (e.g., system 1300) and their structural equivalents, or in combinations of one or more of them. The system 1300 is intended to include various forms of digital computers, such as laptops, desktops, workstations, personal digital assistants, servers, blade servers, mainframes, and other appropriate computers, including vehicles installed on base units or pod units of modular vehicles. The system 1300 can also include mobile devices, such as personal digital assistants, cellular telephones, smartphones, and other similar computing devices. Additionally, the system can include portable storage media, such as, Universal Serial Bus (USB) flash drives. For example, the USB flash drives may store operating systems and other applications. The USB flash drives can include input/output components, such as a wireless transmitter or USB connector that may be inserted into a USB port of another computing device.

The system 1300 includes a processor 1310, a memory 1320, a storage device 1330, and an input/output device 1340. Each of the components 1310, 1320, 1330, and 1340 are interconnected using a system bus 1350. The processor 1310 is capable of processing instructions for execution within the system 1300. The processor may be designed using any of a number of architectures. For example, the processor 1310 may be a CISC (Complex Instruction Set Computers) processor, a RISC (Reduced Instruction Set Computer) processor, or a MISC (Minimal Instruction Set Computer) processor.

In one implementation, the processor 1310 is a single-threaded processor. In another implementation, the processor 1310 is a multi -threaded processor. The processor 1310 is capable of processing instructions stored in the memory 1320 or on the storage device 1330 to display graphical information for a user interface on the input/output device 1340.

The memory 1320 stores information within the system 1300. In one implementation, the memory 1320 is a computer-readable medium. In one implementation, the memory 1320 is a volatile memory unit. In another implementation, the memory 1320 is a non-volatile memory unit.

The storage device 1330 is capable of providing mass storage for the system 1300. In one implementation, the storage device 1330 is a computer-readable medium. In various different implementations, the storage device 1330 may be a floppy disk device, a hard disk device, an optical disk device, or a tape device.

The input/output device 1340 provides input/output operations for the system 1300. In one implementation, the input/output device 1340 includes a keyboard and/or pointing device. In another implementation, the input/output device 1340 includes a display unit for displaying graphical user interfaces. The features described can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The apparatus can be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device for execution by a programmable processor; and method steps can be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output. The described features can be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer will also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto- optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

To provide for interaction with a user, the features can be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer. Additionally, such activities can be implemented via touchscreen flat-panel displays and other appropriate mechanisms.

The features can be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination of them. The components of the system can be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), peer-to-peer networks (having ad-hoc or static members), grid computing infrastructures, and the Internet.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as the described one. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any inventions or of what may be claimed, but rather as descriptions of features specific to particular implementations of particular inventions. Certain features that are described in this specification in the context of separate implementations can also be implemented in combination in a single implementation.

Conversely, various features that are described in the context of a single implementation can also be implemented in multiple implementations separately or in any suitable

subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the

implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular implementations of the subject matter have been described. Other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In certain implementations, multitasking and parallel processing may be advantageous.

Claims

What is claimed is:

1. A method of securely enrolling a user onto a network, comprising:

obtaining identification data indicative of the user's identity, the identification data being acquired via a user's device;

linking the user's identity with a hardware identifier uniquely associated with the user's device;

requesting verification of the user's identity by a third party; and

upon receiving the verification, enrolling the user's identity and linked hardware identifier onto the network.

2. The method of claim 1 further comprising prompting the user to enter biometric data into the user's device before requesting verification.

3. The method of claim 2, wherein requesting verification comprises:

providing the user with a verification document containing at least some of the identification data obtained from the user; and

requesting the user to:

present an identity document and the verification document to the third party; and

requesting the third party to:

confirm that the identity document is consistent with the information in the verification document.

4. The method of claim 3, wherein requesting verification further comprises requesting the user to affirm to the third party that the information in the verification document is correct and that the identity document is authentic.

5. The method of claim 3, wherein requesting verification further comprises:

requesting the user to enter biometric data into the user's device in the presence of the third party; and

requesting the third party to witness the user enter biometric data into the user's device.

6. The method of claim 5 further comprising, after requesting verification and before enrolling, receiving confirmation that biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification.

7. The method of claim 6, wherein the user's biometric data is encrypted and stored locally on the device.

8. The method of claim 7, wherein receiving confirmation comprises receiving a secure token generated by the user's device when the biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification.

9. The method of claim 6 further comprising encrypting and transmitting the user's entered biometric data.

10. The method of claim 9, wherein receiving confirmation comprises matching the biometric data entered in the presence of the third party to the biometric data entered before requesting verification.

11. The method of claim 4, wherein the third party is a notary public.

12. The method of claim 11, wherein the verification document is a physical document.

13. The method of claim 12, wherein requesting verification further comprises the requesting the notary public to notarize the verification document after confirming that the identity document is consistent with the information in the verification document.

14. The method of claim 3, wherein the identity document is a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport.

15. The method of claim 1, wherein enrolling further comprises linking the user's identity with the digital identity of another entity enrolled on the network upon verification that the user is an authorized representative of the entity.

16. The method of claim 1, wherein, after enrolling, the user's enrolled identity may be linked to a plurality of hardware identifiers respectively associated with a plurality of the user's devices.

17. The method of claim 1, wherein the identification data comprises at least one of a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color.

18. The method of claim 1 further comprising, before enrolling, positively determining that the user's identity has not been previously enrolled on the network.

19. A method of securely enrolling a user onto a network, comprising:

entering identification data indicative of the user's identity using a device; sending the identification data and a hardware identifier uniquely associated with the device via a network to an enrollment administrator;

receiving a request for verification of the user's identity by a third party, wherein the request comprises a verification document containing at least some of the user's entered identification data;

providing verification information and the verification document to the third party for certification;

receiving confirmation of enrollment of the user's identity associated with the hardware identifier onto the network, upon receipt by the enrollment administrator of the certified verification document.

20. The method of claim 19 further comprising entering biometric data using the device before receiving a request for verification.

21. The method of claim 20, wherein providing verification information comprises presenting an identity document to the third party.

22. The method of claim 21, wherein providing verification information comprises affirming to the third party that the information in the verification document is correct and that the identity document is authentic.

23. The method of claim 22, wherein providing verification information comprises entering biometric data using the device in the presence of the third party.

24. The method of claim 23, wherein certification indicates that the third party:

confirmed that the identity document is consistent with the information in the verification document; and

witnessed the user entering biometric information into the user's device.

25. The method of claim 24, wherein receiving confirmation of enrollment additionally requires receipt by the enrollment administrator of confirmation that biometric information entered in the presence of the third party matches the biometric information entered by the user before requesting verification.

26. The method of claim 22, wherein the third party is a notary public.

27. The method of claim 26, wherein affirming is performed under oath.

28. The method of claim 19, after receiving confirmation of enrollment, requesting to link the user's enrolled identity with the digital identity of another entity enrolled on the network, wherein requesting comprises providing verification that the user is an authorized representative of the entity or that an authorized representative of the entity has granted permission for such linking.

29. The method of claim 20, wherein entering the user's identification data and biometric data is performed shortly after the birth of the user.

30. The method of claim 29 further comprising entering an attestation by a witness of the birth before receiving a request for verification.

31. The method of claim 29, wherein receiving a request for verification occurs when the user has reached a competent age.

32. A system for securely enrolling a user onto a network, comprising:

a device configured to:

collect identification data indicative of the user's identity; and transmit the identification data and a hardware identifier uniquely associated with the device; and

a sever in communication with the device, the server configured to:

receive the identification data and hardware identifier from the device;

link the user's identity with the hardware identifier;

transmit a request to the device to verify the user's identity using a third party; and

upon verification, enroll the user's identity and linked hardware identifier onto the network.

33. The system of claim 32, wherein the network is a secure network.

34. The system of claim 32, wherein the device comprises a hardware security module that encrypts the input to and output from the device.

35. The system of claim 34, wherein the hardware security module uses symmetric key encryption.

36. The system of claim 34, wherein the hardware security module uses asymmetric key encryption.

37. The system of claim 34, wherein the hardware security module has a direct connection to the network.

38. The system of claim 34, wherein the hardware security module is at least one of tamper resistant or quantum-crypto immune.

39. The system of claim 32, wherein the device is a mobile device.

40. A method of securely enrolling a user onto a network, comprising:

verifying user's identity by videoconference using user's device; and

41. The method of claim 40, further comprising prompting the user to enter biometric data into the user's device before verifying.

42. The method of claim 41, wherein the videoconference is hosted by an authorized agent.

43. The method of claim 42, wherein the authorized agent is a person or bot.

44. The method of claim 43, wherein verifying user's identity by videoconference

comprises:

requesting the user to present an identity document to the authorized agent via videoconference; and

confirming that the identity document is consistent with the identification data provided by the user .

45. The method of claim 44, wherein verifying user's identity by videoconference further comprises requesting the user to affirm to the authorized agent via videoconference that:

the user is attempting to enroll onto the network;

the provided identification data is correct; and

that the presented identity document is authentic.

46. The method of claim 41, wherein verifying user's identity by videoconference further comprises requesting user's device to passively collect user biometric data during videoconference.

47. The method of claim 46, further comprising receiving confirmation, before enrolling, that biometric information entered by user before verifying by videoconference matches biometric data collected during videoconference.

48. The method of claim 44, wherein verifying user's identity by videoconference further comprises detecting liveness.

49. The method of claim 44, wherein the identity document is a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport.

50. The method of claim 40, wherein the identification data comprises at least one of a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color.

51. The method of claim 40, further comprising, before enrolling, positively determining that the user's identity has not been previously enrolled on the network.

52. A method of securely enrolling a user onto a network, comprising:

receiving a request for verification of the user's identity by videoconference;

verifying identity by videoconference; and

receiving, upon verification, confirmation of enrollment of the user's identity associated with the hardware identifier onto the network.

53. The method of claim 52, further comprising entering biometric data using the device before verifying.

54. The method of claim 53, wherein the videoconference is hosted by an authorized agent.

55. The method of claim 54, wherein the authorized agent is a person or bot.

56. The method of claim 55, wherein verifying identity by videoconference comprises presenting an identity document to the authorized agent via videoconference.

57. The method of claim 56, wherein verifying identity by videoconference further comprises affirming to the authorized agent via videoconference that:

the user is attempting to enroll onto the network; the provided identification data is correct; and that the presented identity document is authentic.

58. The method of claim 52, wherein the identity document is a government issued identity document, such as a social security card, a state-issued identification card, a resident alien identification card, a birth certificate, a state driver's license, a military identification card, or a passport.

59. The method of claim 52, wherein the identification data comprises at least one of a user's legal name, address of residence, birth date, social security number, e-mail address, height, weight, eye color, or hair color.

60. A system for securely enrolling a user onto a network, comprising: a device configured to:

collect identification data indicative of the user's identity;

participate in videoconferencing; and

transmit the identification data and a hardware identifier uniquely associated with the device; and

a sever in communication with the device, the server configured to:

receive the identification data and hardware identifier from the device;

link the user's identity with the hardware identifier;

transmit a request to the user, through the device, to verify the user's identity by videoconference; and

61. The system of claim 60, wherein the network is a secure network.

62. The system of claim 60, wherein the device comprises a hardware security module that encrypts the input to and output from the device.

63. The system of claim 62, wherein the hardware security module uses symmetric key encryption.

64. The system of claim 62, wherein the hardware security module uses asymmetric key encryption.

65. The system of claim 62, wherein the hardware security module has a direct connection to the network.

66. The system of claim 62, wherein the hardware security module is at least one of tamper resistant or quantum-crypto immune.

67. The system of claim 60, wherein the device is a mobile device.