CN112313983B

CN112313983B - User authentication using companion device

Info

Publication number: CN112313983B
Application number: CN201980041052.4A
Authority: CN
Inventors: S·V·沙赫; 何嘉乐
Original assignee: Microsoft Technology Licensing LLC
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2018-06-28
Filing date: 2019-06-21
Publication date: 2024-05-14
Anticipated expiration: 2039-06-21
Also published as: WO2020005729A1; US11038684B2; CN112313983A; US20200007334A1; EP3815413A1

Abstract

User authentication techniques using companion devices associated with mobile computing devices are described. The companion device receives the user authentication request from the user authentication service via the mobile computing device, displays information related to the user authentication request, receives approval of the user authentication request, and transmits the approval of the user authentication request to the service via the mobile computing device. In one embodiment, after transmitting the approval, the companion device receives a token from the mobile computing device that includes a value obtained from the service, signs the token with a private key of a securely stored signing key pair, and provides the signed token to the service via the mobile computing device. In another embodiment, the mobile computing device provides the personal identification code from the secure store to the service after the companion device transmits the approval to the mobile computing device.

Description

User authentication using companion device

Technical Field

The present disclosure relates to user authentication using companion devices.

Background

There are smart phone applications, such as online network applications or services, that help users gain access to resources. According to this technique, a user attempts to access a resource via a host computing device. As used herein, the term "primary computing device" is used to refer to a computing device that a user will ultimately use to interact with a resource after gaining access to the resource. If it is determined that user authentication is required to access the resource, a user authentication service is invoked. The user authentication service then interacts with the user's smartphone and the smartphone application executing thereon to perform the user authentication process. For example, in response to one or more communications from a user authentication service, the smart phone application may request the user to approve the access, respond to the challenge, and so forth, before the access may be authorized. If the user provides an appropriate response via her smart phone application, the user authentication service will authorize user access to the resource via the host computing device. The foregoing process relies on the user being able to locate and unlock his smart phone to interact with the smart phone application.

Disclosure of Invention

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

Methods, systems, apparatuses, and computer program products are provided for performing user authentication to gain access to resources by using companion devices associated with mobile computing devices. According to an embodiment, a first computing device (e.g., a smart watch or other companion device) includes a secure memory having stored therein a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers. The first computing device receives the user authentication request from the user authentication service via a second computing device (e.g., a smart phone or other mobile computing device paired with the first computing device), wherein the second computing device is connected to the user authentication service and is wirelessly connected to the first computing device. The first computing device displays information related to the user authentication request, receives approval of the user authentication request, and transmits the approval of the user authentication request to the second computing device. The first computing device also receives a token from the second computing device, wherein the token comprises a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request, signs the token with the private key to generate a signed token, and provides the signed token to the second computing device for subsequent transmission to the user authentication service. The signature token and public key may be used by the user authentication service to determine that the user authentication request is to be authorized.

According to an alternative embodiment, a first computing device (e.g., a smart phone or other mobile computing device) includes a secure memory having stored therein a personal identification code registered with a user authentication service that includes one or more user authentication servers. The first computing device receives a user authentication request from a user authentication service to which the first computing device is connected, transmits the user authentication request to a second computing device (e.g., a smart watch or other companion device paired with the first computing device) to which the first computing device is wirelessly connected, and receives approval of the user authentication request from the second computing device. After receiving approval of the user authentication request from the second computing device, the first computing device reads the personal identification code from the secure memory and transmits it to the user authentication service. The personal authentication code is usable by the user authentication service to determine that the user authentication request is to be authorized.

Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings. Note that the present invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Other embodiments will be apparent to those skilled in the relevant arts based on the teachings contained herein.

Drawings

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present application and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments.

FIG. 1 is a block diagram of an example system that authenticates a user attempting to gain access to a resource via their host computing device in a manner that utilizes the user's mobile computing device.

FIG. 2 is a block diagram of an example system that authenticates a user attempting to gain access to a resource via their host computing device in a manner that utilizes an companion device of the user communicatively connected to the user's mobile computing device, according to an example embodiment.

Fig. 3 is an example sequence diagram for generating and securely storing a signing key pair on a companion device and for registering a public key of the signing key pair with an authentication service to facilitate a password-less user authentication process according to an example embodiment.

Fig. 4 is an example sequence diagram for performing a password-less user authentication process according to an example embodiment.

Fig. 5 is an example sequence diagram for performing a multi-factor authentication (MFA) user authentication process according to an example embodiment.

Fig. 6 depicts a flowchart of a method performed by a companion device as part of a password-less user authentication process, according to an example embodiment.

Fig. 7 depicts a flowchart of a method performed by a companion device for generating and securely storing a signing key pair and for transmitting a public key via a mobile computing device for registration at a user authentication service in accordance with an illustrative embodiment.

Fig. 8 depicts a flowchart of a method performed by a mobile computing device as part of an MFA user authentication process, according to an example embodiment.

Fig. 9 depicts a flowchart of additional steps that may be performed by a mobile computing device as part of an MFA user authentication process, according to an example embodiment.

FIG. 10 is a block diagram of an exemplary mobile system including a mobile device that can be used to implement various embodiments.

FIG. 11 is a block diagram of an example computing device that may be used to implement various embodiments.

Features and advantages of the present invention will become more apparent from the following detailed description taken in conjunction with the accompanying drawings in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The first-appearing graphic of an element is indicated by the leftmost digit(s) in the corresponding reference number.

Detailed Description

I. Introduction to the invention

The specification and drawings disclose one or more embodiments that incorporate the features of the invention. The scope of the invention is not limited to the disclosed embodiments. The disclosed embodiments are merely illustrative of the invention, and modifications of the disclosed embodiments are also contemplated by the invention. Embodiments of the invention are defined by the appended claims.

References in the specification to "one embodiment," "an example embodiment," etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the discussion, unless otherwise indicated, adjectives (e.g., "substantially" and "about") modifying the condition or relational characteristic of one or more features of embodiments of the disclosure are understood to mean that the condition or characteristic is defined to be within an acceptable tolerance for operation of the embodiments for its intended application.

Many exemplary embodiments are described below. Note that any section/sub-section headings provided herein are not intended to be limiting. Embodiments are described throughout this document and any type of embodiment may be included under any section/section. Furthermore, embodiments disclosed in any section/section may be combined in any manner with any other embodiment described in the same section/section and/or a different section/section.

Example embodiment

Example embodiments described herein relate to techniques for performing user authentication to gain access to resources by using companion devices communicatively connected to a mobile computing device. For example, and without limitation, in one instance, the resource may comprise an online web application or service, the mobile computing device may comprise a smart phone, and the companion device may comprise a smart watch paired with the smart phone.

As discussed in the "background" section above, there are smart phone applications that help users gain access to resources via a host computing device. As used herein, the term "primary computing device" is used to refer to a computing device that a user will ultimately use to interact with a resource after gaining access to the resource. For example, such an application may enable a user to gain access to a resource using a password-free method in which the user does not need to enter a password into the host computing device, but rather relies on credentials protected by the smartphone. Alternatively, such an application may enable a user to access a resource using a multi-factor authentication (MFA) user authentication method in which the user enters a password into a host computing device to provide a first authentication factor, and then one or more additional authentication factors are obtained from the smartphone. In this way, the security of the resource is improved by requiring more interactions with the user's mobile device. Furthermore, the password-less method makes the user's life easier because they do not have to remember the password to gain access to the resource. This is desirable for a number of reasons, including that many passwords are complex and thus difficult for users to remember. Furthermore, as many online applications and services now require passwords, and have different rules for what passwords are acceptable passwords, it is increasingly difficult for users to remember each of their different passwords.

To help illustrate the foregoing, fig. 1 will now be described. In particular, FIG. 1 is a block diagram of an example system 100 that authenticates a user attempting to gain access to a resource via their host computing device in a manner that utilizes the user's smart phone. As shown in fig. 1, the system 100 includes a first computing device 110, a second computing device 102, a user authentication service 108, and a resource endpoint 106, all communicatively connected via one or more networks 130. The system 100 also includes a resource 104 connected to the network 130 via a resource endpoint 106.

The first computing device 110 is intended to represent a computing device via which a user intends to access the resource 104. As described above, the computing device may be referred to herein as a "master computing device. The first computing device 110 may include, for example, but is not limited to, a desktop computer, a tablet computer, a laptop computer, a video game console, and the like. As shown in fig. 1, the first computing device 110 includes a web browser 120 with which a user may interact to gain access to the resource 104 and ultimately interact with the resource 104. For purposes of illustration, a web browser 120 is shown in fig. 1, but those skilled in the art will appreciate that any internet-capable application may be used to facilitate such interaction.

The second computing device 102 is intended to represent a smart phone or other computing device that the user owns or is otherwise associated with the user. The computing device may also be referred to herein as a "second computing device". As shown in fig. 1, the second computing device 102 includes processing circuitry 112, memory 118, secure memory 114, and a user interface 116. The processing circuitry 112 is configured to execute certain computer programs stored in the memory 118, including an Operating System (OS) 124 and an authentication application 122. As will be discussed below, the authentication application 122 is used to assist in a user authentication process that ultimately enables a user to gain access to the resource 104 via the first computing device 110. Secure memory 114 is configured to store highly sensitive information, such as one or more credentials that may be used in the user authentication process described above. Secure memory 114 may include, for example, an encrypted database. Such an encrypted database may be protected by an encryption key obtained, for example, based on information unique to the second computing device 102 and in conjunction with a user-defined password, but this is merely one example. The user interface 116 includes means by which a user can interact with the second computing device 102, and in examples in which the second computing device 102 is a smart phone, may include a touch-sensitive display and one or more buttons or switches.

Resource 104 is intended to represent a resource that a user wishes to access and only allows access by authenticated users. For example, the resources 104 may include, but are not limited to, online network applications or services that require the user to be authenticated prior to gaining access, although this example is not intended to be limiting. Such online network applications or services may be executed on one or more computing devices, as is known in the art.

Network 130 is intended to represent one or more physical links between computing devices or other electronic devices that enable data communication therebetween. The network 130 may include any type of network including, but not limited to, a Local Area Network (LAN), a Wide Area Network (WAN) such as the internet, a telecommunications network, and the like. The network 130 may also include one or more wired and/or wireless networks. Communication over the network 130 may be performed using any of a variety of well-known wired and wireless network communication protocols.

When a user wishes to access the resource 104 via the first computing device 110, the user may interact with the web browser 120 in a well-known manner to cause the web browser 120 to send an access request to the resource endpoint 106. Resource endpoint 106 includes one or more computing devices that operate to receive such an access request and grant or deny access to resource 104 depending on whether a user associated with the request is authorized to access resource 104. If user authentication is required to access the resource 104, the resource endpoint 106 will invoke the user authentication service 108 to authenticate the user before determining whether to authorize or deny access to the resource 104. The user authentication service 108, also implemented on one or more computing devices, may then initiate a user authentication process to authenticate the user in a manner involving both the first computing device 110 and the second computing device 102.

One such user authentication process, which may be referred to as a password-less user authentication process, will now be described. According to this procedure, the user authentication service 108 prompts the user via the web browser 120 or inputs a password required for user authentication, or selects to perform user authentication in such a manner that such a password does not need to be input. If the user chooses to perform password-less user authentication, the user authentication service 108 interacts with an authentication application 122 executing on the second computing device 102 to obtain therefrom user credentials stored in the secure memory 114. Upon receiving the secure user credentials, the user authentication service 108 may then authorize the user to access the resource 104. For example, the user authentication service 108 may authorize a user to access the resource 104 by sending back an appropriate access token to the resource endpoint 106. Upon receiving the access token, the resource endpoint 106 then provides the user with access to the resource 104 via the first computing device 110.

The authentication application 122 may provide the secure user credentials to the user authentication service 108, for example, by signing a value (e.g., a blob or a cryptographic random number) provided by the user authentication service 108 with a private signing key stored in the secure memory 114 and then returning the signed value to the user authentication service 108. The user authentication service 108 may then verify the signature value using a previously registered public signature key that corresponds to the private signature key. However, this is only one example of the manner in which authentication application 122 may provide user credentials to user authentication service 108, and various other user credentials and techniques may be used.

The authentication application 122 requires the user to authorize an access attempt through some form of interaction with the user interface 116 of the second computing device 102 before providing the user credentials to the user authentication service 108. For example, the user may be required to indicate via the user interface 116 that the access attempt should be allowed. As another example, the user may be required to select the same number or code displayed on the user interface 116 as is displayed via the web browser 120 of the first computing device 110, or to provide a response to some other security challenge. Other ways for obtaining user authorization for the access attempt may be used. In an example scenario where the second computing device 102 is a smart phone, the user must be able to find and unlock his smart phone in order to make such interactions with the user interface 116.

An alternative user authentication process, which may be referred to as a multi-factor authentication (MFA) user authentication process, will now be described. According to this process, the user authentication service 108 prompts the user via the web browser 120 to input a password required for user authentication. The password is used as a first authentication factor. The user authentication service 108 then also interacts with an authentication application 122 executing on the second computing device 102 to obtain one or more additional authentication factors therefrom. In this example, the personal identification code stored in secure memory 114 and provided to user authentication service 108 provides an additional authentication factor. Upon receipt of the personal identification code, the user authentication service 108 may then authorize the user to access the resource 104. For example, the user authentication service 108 may authorize a user to access the resource 104 by sending back an appropriate access token to the resource endpoint 106. Upon receiving the access token, the resource endpoint 106 then provides the user with access to the resource 104 via the first computing device 110.

Authentication application 122 may provide the personal identification code to user authentication service 108, for example, by reading the personal identification code from secure memory 114 and transmitting the personal identification code to user authentication service 108. The user authentication service 108 may then compare the personal identification code with previously registered personal identification codes to ensure that they match.

The authentication application 122 may require the user to authorize the access attempt through some form of interaction with the user interface 116 of the second computing device 102 before providing the personal identification code to the user authentication service 108. For example, the user may be required to select the same number or code displayed on the user interface 116 as is displayed via the web browser 120 of the first computing device 110, or to provide a response to some other security challenge. However, this is not intended to be limiting and other means for obtaining user authorization of the access attempt may be used. Also as described above with respect to the password-less method, in an example scenario where the second computing device 102 is a smart phone, the user must be able to find and unlock his smart phone in order to make such interactions with the user interface 116.

As previously described, in a scenario where the second computing device 102 is a smart phone, the authorization application 122 assists the user in gaining access to resources via the first computing device 110, but requires the user to find and unlock the smart phone in order to interact with the authorization application 122, which may not be desirable because the user's smart phone may not be easily located and/or unlocked by the user when the user authentication process occurs. For example, a user's smartphone may be misplaced or not easily reached, or the user may not be able to find and unlock her smartphone. To address this issue, embodiments described herein enable a user authentication process to be performed via user interaction with a companion device communicatively connected to the smartphone, rather than the smartphone itself. Because the companion device may include, for example, a smart watch or other wearable computing device, it may be better and/or easier for a user to access. Furthermore, the embodiments described herein enable an authentication process to be performed while the smart phone remains locked, which means that the user does not need to find and/or unlock the smart phone to complete the user authentication process.

As will also be discussed herein, embodiments described herein rely on wireless communication between a mobile computing device, such as a smart phone, and a companion device, such as a smart watch or other wearable computing device, to perform a user authentication process using credentials stored on the mobile computing device or the wearable computing device. However, such credentials may never be transferred between the mobile computing device and the companion device according to embodiments described herein. This approach advantageously protects the security of these credentials by ensuring that malicious parties cannot obtain them by monitoring (or "sniffing") wireless communications between the mobile computing device and the companion device.

To help illustrate the foregoing, fig. 2 will now be described. In particular, fig. 2 is a block diagram of an example system 200 according to an example embodiment, the example system 200 authenticating a user attempting to gain access to a resource via their host computing device in a manner that utilizes the user's companion device (e.g., a smart watch or other wearable device) paired with the user's mobile computing device (e.g., a smart phone). As shown in fig. 2, system 200 includes some of the same components as shown in fig. 1, and these components may operate in a substantially similar manner, with the differences now described.

As shown in fig. 2, the second computing device 102 of the system 200 stores the mobile device authentication application 216 in the memory 118 in place of the authentication application 122. As will be discussed below, the mobile device authentication application 216 is configured to interact with the companion device authentication application 212 executing on the third computing device 202 and the user authentication service 108 to perform a user authentication process in which a user interacts with the third computing device 202. Further, the mobile device authentication application 216 is configured to interact with the companion device authentication application 212 and the user authentication service 108 while the second computing device 102 is in an unlocked state or a locked state. As used herein, the term "locked state" is used to refer to a state in which a user is prevented from accessing all functions of the second computing device 102 before entering credentials, such as a biometric identifier or a previously registered password. Further, the term "unlocked state" is used to refer to a state in which a user is allowed to access all of the functionality of the second computing device 102.

Specifically, as shown in fig. 2, the system 200 further includes a third computing device 202 communicatively connected to the second computing device 102. The third computing device 202 is intended to represent a companion computing device, such as a smart watch or other wearable computing device, owned or otherwise associated with the user and that may be communicatively linked with the second computing device 102. In one embodiment, the third computing device 202 is connected to the second computing device 102 via a wireless connection (such as a Bluetooth connection or an IEEE 802.11 connection). However, this is merely an example, and any type of wired or wireless connection may be used to facilitate communication between third computing device 202 and second computing device 202.

As shown in fig. 2, the third computing device 202 includes processing circuitry 204, memory 210, secure memory 206, and a user interface 208. The processing circuitry 204 is configured to execute certain computer programs stored in the memory 210, including an Operating System (OS) 214 and an companion device authentication application 212. As described below, the companion device authentication application 212 is used to facilitate a user authentication process that ultimately will enable a user to gain access to the resource 104 via the first computing device 110 by interacting with the user authentication service 108 via the mobile device authentication application 216 of the second computing device 102. Secure memory 206 is configured to store highly sensitive information, such as one or more credentials that may be used in the user authentication process described above. Secure memory 206 may include, for example, an encrypted database. Such an encrypted database may be protected by an encryption key obtained, for example, based on information unique to third computing device 202 and in conjunction with a user-defined password, but this is merely one example. The user interface 208 includes means by which a user may interact with the third computing device 202, and in examples in which the third computing device 202 is a smartwatch, may include a touch sensitive display and one or more buttons. It should be noted that in the example embodiment of fig. 2, third computing device 202 is in an "unlocked state," which means that the user is enabled to fully interact with third computing device 202. For example, in an example where the third computing device 202 is a smart watch, the smart watch is unlocked and on the user's wrist.

In the method represented by system 200, when a user wishes to access resource 104 via first computing device 110, the user may interact with web browser 120 to cause web browser 120 to send an access request to resource endpoint 106, and if user authentication is required to access resource 104, resource endpoint 106 will invoke user authentication service 108 to authenticate the user before determining whether to authorize or deny access to resource 104. The user authentication process performed will involve not only the computing device 110 and the second computing device 102, but will also involve the third computing device 202. As will be described below, the method enables a user to interact with the third computing device 202 while the second computing device 102 remains locked.

According to the example of fig. 2, one such user authentication process may be a password-less user authentication process. According to this procedure, the user authentication service 108 prompts the user via the web browser 120 to input a password required for user authentication or selects to perform user authentication in such a manner that such a password does not need to be input. If the user chooses to perform password-less user authentication, the user authentication service 108 interacts with the companion device authentication application 212 executing on the third computing device 202 (via the mobile device authentication application 216) to obtain therefrom the user credentials stored in the secure memory 206. Upon receiving the secure user credentials, the user authentication service 108 may then authorize the user to access the resource 104. For example, the user authentication service 108 may authorize a user to access the resource 104 by sending back an appropriate access token to the resource endpoint 106. Upon receiving the access token, the resource endpoint 106 then provides the user with access to the resource 104 via the first computing device 110.

The companion device authentication application 212 may provide secure user credentials to the user authentication service 108, for example, by signing a token including a value (e.g., a blob or random number) provided by the user authentication service 108 with a private signing key stored in the secure memory 206 and then returning the signed token to the user authentication service 108 via the mobile device authentication application 216. The user authentication service 108 may then verify the signature token using the previously registered public signature key corresponding to the private signature. However, this is but one example of the manner in which the companion device authentication application 212 may provide user credentials to the user authentication service 108, and various other user credentials and techniques may be used.

The companion device authentication application 212 asks the user to authorize an access attempt through some form of interaction with the user interface 208 of the third computing device 202 before providing the user credentials to the user authentication service 108. For example, the user may be required to simply indicate via the user interface 208 that the access attempt should be allowed. As another example, the user may be required to select the same number or code displayed on the user interface 208 as is displayed via the web browser 120 of the first computing device 110, or to provide a response to some other security challenge. Other ways for obtaining user authorization for the access attempt may be used. In an example scenario where the second computing device 102 is a smart phone and the third computing device 202 is a smart watch, the user is enabled to perform an authentication process by merely interacting with the smart watch without having to find or unlock the smart phone. In addition, the private signing key is never transferred between the smart watch and the smart phone, thereby enhancing the security of the system.

Further in accordance with the example of fig. 2, an alternative user authentication process may be an MFA user authentication process. According to this process, the user authentication service 108 prompts the user via the web browser 120 to input a password required for user authentication. The password is used as a first authentication factor. The user authentication service 108 then also interacts with the companion device authentication application 212 executing on the third computing device 202 (via the mobile device authentication application 216 executing on the second computing device 102) to obtain one or more additional authentication factors. In this example, the personal identification code stored in secure memory 114 and provided to user authentication service 108 provides an additional authentication factor. Upon receipt of the personal identification code, the user authentication service 108 may then authorize the user to access the resource 104. For example, the user authentication service 108 may authorize a user to access the resource 104 by sending back an appropriate access token to the resource endpoint 106. Upon receiving the access token, the resource endpoint 106 then provides the user with access to the resource 104 via the first computing device 110.

The mobile device authentication application 216 may provide the personal identification code to the user authentication service 108, for example, by reading the personal identification code from the secure memory 114 and transmitting the personal identification code to the user authentication service 108. The mobile device authentication application 216 may read the personal identification code from the secure memory 114 in response to receiving approval from the companion device authentication application 212. The user authentication service 108 may then compare the personal identification code with previously registered personal identification codes to ensure that they match.

The mobile device authentication application 216 may require the user to authorize the access attempt through some form of interaction with the user interface 208 of the third computing device 202 before providing approval to the mobile device authentication application 216 so that the personal identification code may be read and provided to the user authentication service 108. For example, the user may be required to select the same number or code displayed on the user interface 208 as is displayed via the web browser 120 of the first computing device 110, or to provide a response challenge to some other security. However, this is not intended to be limiting and other means for obtaining user authorization of the access attempt may be used. Also as described above with respect to the password-less method, in an example scenario where the second computing device 102 is a smart phone and the third computing device 202 is a smart watch, the user is enabled to perform an authentication process by interacting with only the smart watch without the need to find or unlock the smart phone. In addition, the personal identification code is never transferred between the smart phone and the smart watch, thereby enhancing the security of the system.

The foregoing method may be performed in various ways. A specific example of how an embodiment may operate in accordance with the foregoing techniques will now be described with reference to fig. 3. In particular, fig. 3 is an example sequence diagram 300 for generating and securely storing a signing key pair on a paired device and for registering a public key of the signing key pair with an authentication service to facilitate a password-less user authentication process according to an example embodiment. As shown in fig. 3, a sequence diagram 300 illustrates interactions between the various components described above with reference to fig. 2. In particular, the sequence diagram 300 illustrates interactions between the third computing device 202 and the second computing device 102 and between the second computing device 102 and the user authentication service 108.

As shown in fig. 3, the companion device authentication application 212 executing on the third computing device 202 generates a signing key pair (302), wherein the signing key pair includes a private key and a public key.

In one embodiment, the companion device authentication application 212 performs operation (302) only if a personal identification code (such as a PIN) has been enabled for the third computing device 202. Such a personal identification code may be required to unlock third computing device 202 and interact with companion device authentication application 212. By requiring such a personal identification code to be enabled (302) prior to performing the operation, embodiments thereby ensure that the user is required to enter the personal identification code prior to interacting with companion device authentication application 212 to perform the aforementioned password-less user authentication process.

Further in accordance with such an embodiment, if at some later point in time, companion device authentication application 312 determines that the personal identification code has been disabled for third computing device 202, then companion device authentication application may delete the signing key pair. Again, this ensures that the password-less user authentication process is only useful if the third computing device 202 requires entry of a personal identification code before the user can interact with the companion device authentication application 212.

Further in accordance with this example, companion device authentication application 312 executing on third computing device 202 transmits the public key (304) to mobile device authentication application 212 executing on second computing device 102 so that the public key may be registered with user authentication service 108. The public key may be registered in various ways. For example, as shown in FIG. 3, the mobile device authentication application 212 first obtains a certain user authentication input and provides it to the user authentication service 108 (306). The user authentication input may include user input providing strong authentication. In response to receiving the user authentication input, the user authentication service 108 provides a time-limited token to the mobile device authentication application 212 (308). The mobile device authentication application 212 then transmits a request to register the public key to the user authentication service 108 using the time-limited token (310). In an embodiment, the request may include a time-limited token and a public key. The user authentication service 108 then registers the public key.

Once the public key has been registered by the user authentication service 108, the user authentication service 108 generates and transmits a server key identifier to the mobile device authentication application executing on the second computing device 102 (312). The server key identifier may include an identifier maintained by the user authentication service 108 and usable in future communications with it to identify the public key. The server key identifier may be much shorter than the public key itself and its use in subsequent communications may improve efficiency. In response to receiving the server key identifier, the second computing device 102 forwards the server key identifier to the third computing device 202 (314). Third computing device 202 then stores the signing key pair, its local identifier, and the server key identifier (316).

Following the example of fig. 3, fig. 4 is an example sequence diagram 400 for performing a password-less user authentication process according to an example embodiment. As shown in fig. 4, the user authentication service 108 transmits a user authentication request to the second computing device 102 and the operating system 124 executing thereon passes the user authentication request to the operating system 214 executing on the third computing device 202 (402). The operating system 214 then passes the user authentication request to the companion device authentication application 212.

As further shown in fig. 4, the companion device authentication application 212 executing on the third computing device 202 transmits an approval of the user authentication request to the mobile device authentication application 216 executing on the second computing device 102 (404). For example, and referring to fig. 2, companion device authentication application 212 may display information related to the user authentication request to the user via user interface 208 so that the user may approve or reject the user authentication request. In one embodiment, the user authentication request may include a challenge such that approval of the user authentication request includes a response of the user to the challenge.

In response to receiving the approval, the mobile device authentication application 216 executing on the second computing device 102 sends a value request to the user authentication service 108 (406). In response to receiving the value request, the user authentication service 108 transmits a value to the mobile device authentication application 216 executing on the second computing device 102 (408). In one embodiment, the value may comprise a cryptographic random number, although this example is not intended to be limiting.

As further shown in fig. 4, in response to receiving the value, the mobile device authentication application 216 executing on the second computing device 102 sends a token to the companion device authentication application 212 executing on the third computing device 202 (410), wherein the token includes the value. The companion device authentication application 212 executing on the third computing device 202 signs the token with the securely stored private signing key (412) and then transmits the signed token to the mobile device authentication application 216 executing on the second computing device 102 (414). The mobile device authentication application 216 then transmits the signed token to the user authentication service 108 (416). The user authentication service 108 uses the signature token and the public key to determine whether to authorize the user authentication request.

In one embodiment, the user authentication service 108 uses the public key to verify the signature token. If the signature token is verified, the password-less user authentication is deemed successful. As shown in fig. 4, in response to successful user authentication, the user authentication service 108 generates and transmits a success message to the operating system 124 executing on the second computing device 102 (418), which operating system 124 forwards the success message to the operating system 214 executing on the third computing device 202 (420).

As described above, various user authentication processes may be used to authenticate a user. Another example of how an embodiment may operate according to the foregoing techniques will now be described with reference to fig. 5. In particular, fig. 5 is an example sequence diagram 500 for performing a multi-factor authentication (MFA) user authentication process according to an example embodiment. As shown in fig. 5, a sequence diagram 500 illustrates interactions between the various components described above with reference to fig. 2-4. In particular, sequence diagram 500 illustrates interactions between third computing device 202 and second computing device 102 and between second computing device 102 and user authentication service 108.

As shown in fig. 5, the user authentication service 108 transmits a user authentication request to the second computing device 102 and the operating system 124 executing thereon passes the user authentication request to the operating system 124 executing on the third computing device 202 (502). The operating system 214 then passes the user authentication request to the companion device authentication application 212.

As further shown in fig. 5, the companion device authentication application 212 executing on the third computing device 202 transmits an approval of the user authentication request to the mobile device authentication application 216 executing on the second computing device 102 (504). For example, and referring to fig. 2, companion device authentication application 212 may display information related to the user authentication request to the user via user interface 208 so that the user may approve or reject the user authentication request. In some embodiments, obtaining user approval may also require the user to respond to a security challenge.

In response to receiving the approval, the mobile device authentication application 216 executing on the second computing device 102 transmits an authentication details request to the user authentication service 108 (506). The authentication details request may represent a request to obtain additional details required to read a personal identification code securely stored on the second computing device 102. As shown in fig. 5, in response to receiving the authentication details request, the user authentication service 108 transmits the authentication details to the second computing device 102 (508). In alternative embodiments, authentication details may not be required, and the mobile device authentication application 216 executing on the second computing device 102 may read the personal identification code from secure memory immediately after approval is received.

As further shown in fig. 5, in response to receiving the authentication details, the mobile device authentication application 216 executing on the second computing device 102 reads the personal identification code from the secure memory 114 (510). The mobile device authentication application 216 then transmits the personal identification code to the user authentication service 108 as part of the ping request (512). The user authentication service 108 then verifies the personal identification code by comparing the personal identification code with a copy of the previously stored personal identification code. If the codes match, the personal identification code passes the ping and the user authentication service 108 sends a personal identification code valid response to the mobile device authentication application 216 executing on the second computing device 102 (514).

In response to receiving the valid response, the mobile device authentication application 216 executing on the second computing device 102 transmits an authentication result request to the user authentication service 108 (516). Upon receipt of the authentication result request, the user authentication service 108 generates and transmits a success message to the operating system 124 executing on the second computing device 102 (518). The operating system 124 executing on the second computing device 102 then provides a success message to the operating system 214 executing on the third computing device 202 (520).

Fig. 6 depicts a flowchart 600 of a method performed by a companion device as part of a password-less user authentication process, according to an example embodiment. The method of flowchart 600 may be performed, for example, by third computing device 202 described above with reference to fig. 2 and 4.

As shown in fig. 6, the method of flowchart 600 begins at step 602 by receiving a user authentication request from a user authentication service via a second computing device, wherein the second computing device is connected to the user authentication service and is wirelessly connected to the first computing device at step 602. For example, and with continued reference to fig. 2 and 4, the second computing device 102 is connected to the user authentication service 108 and is wirelessly connected to the third computing device 202 such that user authentication requests can be received from the user authentication service 108 via the second computing device 102. As described above, the second computing device 102 may be wirelessly connected to the third computing device 202 in various ways, such as, but not limited to, bluetooth or IEEE 802.11 connections. In an embodiment, the user authentication request may include a challenge, such as asking the user to select the same number or code displayed on the user interface 208 as displayed via the web browser 120 of the first computing device 110, or to provide a response to some other security challenge.

In step 604, information related to the user authentication request is displayed. For example, and with continued reference to fig. 2 and 4, information related to the user authentication request is displayed to the user via the user interface 208. The information may include prompts for user approval and/or responses to the security challenge.

At step 606, approval of the user authentication request is received. For example, and with continued reference to fig. 2 and 4, approval is received from the user via the user interface 208 and transmitted to the third computing device 202. In embodiments where the user authentication request includes a challenge, the approval may include a user response to the challenge.

At step 608, approval of the user authentication request is transmitted to the second computing device for subsequent transmission to the user authentication service. For example, and with continued reference to fig. 4, approval is transmitted from third computing device 202 to user authentication service 108 via second computing device 102.

At step 610, a token is received from the second computing device, the token including a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request. For example, and with continued reference to fig. 4, a value is obtained by the second computing device 102 from the user authentication service 108 and transmitted to the third computing device 202 as part of the token. As described above, the value may comprise a cryptographic random number or some other value.

At step 612, the token is signed with the private key to generate a signed token. For example, and with continued reference to fig. 4, the third computing device 202 signs the token to generate a signed token.

At step 614, the signed token is provided to the second computing device for subsequent transmission to the user authentication service, the signed token and public key being usable by the user authentication service to determine that the user authentication request is to be authorized. For example, and referring to fig. 3 and 4, the third computing device 202 provides the signed token to the second computing device 102, and the second computing device 102 transmits the signed token to the user authentication service 108. The user authentication service 108 then uses the signature token and public key 304 to determine whether the user authentication request is to be authorized.

As described above, before using the no-password process, the signing key pair must be generated so that third computing device 202 can securely store the signing key pair and the public key can be registered with user authentication service 108. For example, fig. 7 depicts a flowchart 700 of a method performed by an companion device for generating and securely storing a signing key pair and for transmitting a public key via a mobile computing device for registration at a user authentication service in accordance with an illustrative embodiment. The method of flowchart 700 may be performed, for example, by third computing device 202 described above with reference to fig. 2 and 3.

As shown in fig. 7, the method of flowchart 700 begins at step 702 where a signing key pair is generated at step 702. For example, and with continued reference to fig. 2 and 5, the companion device authentication application 212 generates a signing key pair. In one embodiment, the companion device authentication application 212 generates a signing key pair only if the personal identification code has been enabled for the third computing device 202.

In step 704, the signing key pair is stored in a secure memory of the first computing device. For example, and with continued reference to fig. 2 and 3, the signing key pair is stored in the secure memory 206 of the third computing device 202. In embodiments in which the signing key pair is generated only if the personal identification code is enabled for the third computing device 202, the signing key pair is deleted in response to determining that the personal identification code has been disabled for the third computing device 202.

At step 706, the public key is transmitted to the second computing device so that the second computing device can register the public key with the user authentication service. For example, and with continued reference to fig. 2 and 3, the third computing device 202 transmits the public key to the second computing device 102 such that the second computing device 202 is able to register the public key with the user authentication service 108. The second computing device 102 may register the public key in various ways. For example, as shown in fig. 3, the second computing device 102 may first obtain user authentication input and provide it to the user authentication service 108. The second computing device 102 may also receive a time-limited token from the user authentication service 108 in response to providing the user authentication input and transmit a request to register a public key with the user authentication service 108 using the time-limited token.

As described above, embodiments herein describe various user authentication processes. For example, fig. 8 depicts a flowchart 800 of a method performed by a mobile computing device as part of an MFA user authentication process, according to an example embodiment. The method of flowchart 800 may be performed, for example, by second computing device 102 described above with reference to fig. 2 and 5.

As shown in fig. 8, the method of flowchart 800 begins at step 802 by receiving a user authentication request from a user authentication service to which a first computing device is connected at step 802. For example, and with continued reference to fig. 5, the second computing device 102 is connected to the user authentication service 108 such that a user authentication request is received from the user authentication service 108.

At step 804, a user authentication request is transmitted to a second computing device to which the first computing device is wirelessly connected. For example, and with continued reference to fig. 2 and 5, a user authentication request is transmitted to the third computing device 202 to which the second computing device 102 is wirelessly connected. As described above, the second computing device 102 may be wirelessly connected to the third computing device 202 in various ways, such as through Bluetooth or IEEE 802.11 connections.

At step 806, approval of the user authentication request is received from the second computing device. For example, and with continued reference to fig. 2 and 5, approval is received from third computing device 202.

At step 808, after approval of the user authentication request is received from the second computing device, the personal identification code is read from the secure memory and transmitted to the user authentication service, the personal identification code being usable by the user authentication service to determine that the user authentication request is to be authorized. For example, and with continued reference to fig. 2 and 5, the second computing device 102 reads the personal identification code from the secure memory 114 and may transmit the personal identification code to the user authentication service 108. As described above, the personal identification code may be used by the user authentication service 108 to determine whether the user authentication request is to be authorized.

As described above, additional details may need to be read before the personal identification code is read. For example, fig. 9 depicts a flowchart 900 of additional steps that may be performed by a mobile computing device as part of an MFA user authentication process, according to an example embodiment. The method of flowchart 900 may be performed, for example, by second computing device 102 as described above with reference to fig. 5.

As shown in fig. 9, the method of flowchart 900 begins at step 902 by transmitting an authentication details request to a user authentication service in response to receiving approval of the user authentication request from a second computing device at step 902. For example, and with continued reference to fig. 5, an authentication detail request is transmitted from the second computing device 102 to the user authentication service 108.

At step 904, authentication details are received from the user authentication service, the authentication details indicating that a personal identification code must be provided. For example, and with continued reference to fig. 5, authentication details are transmitted from the user authentication service 108 to the second computing device 102.

In step 906, in response to receiving the authentication details, the personal identification code is read from the secure memory and transmitted to the user authentication service. For example, and with continued reference to fig. 5, in response to the second computing device 102 receiving the authentication details, the second computing device 102 reads the personal identification code from secure memory and transmits it to the user authentication service 108.

Example Mobile and stationary device embodiments

The embodiments described herein may be implemented in hardware or hardware in combination with software and/or firmware. For example, embodiments described herein may be implemented as computer program code/instructions configured to be executed in one or more processors and stored in a computer-readable storage medium. Alternatively, the embodiments described herein may be implemented as hardware logic/circuit coordination.

As described herein, the described embodiments (including, for example, system 100 of fig. 1, system 200 of fig. 2, sequence diagram 300 of fig. 3, sequence diagram 400 of fig. 4, and sequence diagram 500 of fig. 5, along with any components and/or sub-components thereof, and any operations and portions of the flow charts/flow diagrams described herein and/or other examples described herein) may be implemented in hardware or hardware with any combination of software and/or firmware, including as computer program code configured to be executed in one or more processors and stored in a computer-readable storage medium, or as hardware logic/circuitry, such as implemented together in a system on a chip (SoC), field Programmable Gate Array (FPGA), or Application Specific Integrated Circuit (ASIC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a microcontroller, microprocessor, digital Signal Processor (DSP), etc.), memory, one or more communication interfaces, and/or other circuitry and/or embedded firmware to perform its functions.

Embodiments described herein may be implemented in one or more computing devices similar to mobile systems and/or computing devices in fixed or mobile computer embodiments, including one or more features of the mobile systems and/or computing devices described herein, as well as alternative features. The descriptions of mobile systems and computing devices provided herein are provided for purposes of illustration and are not intended to be limiting. Embodiments may be implemented in other types of computer systems, as known to those skilled in the relevant art.

Fig. 10 is a block diagram of an exemplary mobile system 1000 including a mobile device 1002 that can implement embodiments described herein. For example, in the preceding sections, mobile device 1002 may be used to implement any system, client, or device, or component/sub-component thereof. As shown in fig. 10, mobile device 1002 includes various optional hardware and software components. Any component in mobile device 1002 may communicate with any other component, although not all connections are shown for ease of illustration. The mobile device 1002 can be any of a variety of computing devices (e.g., cellular telephone, smart phone, handheld computer, personal Digital Assistant (PDA), etc.) and can allow wireless two-way communication with one or more mobile communication networks 1004, such as a cellular or satellite network, or with a local or wide area network.

The mobile device 1002 may include a controller or processor 1010 (e.g., a signal processor, microprocessor, ASIC, or other control and processing logic circuitry) for performing functions such as signal encoding, data processing, input/output processing, power control, and/or other functions. Operating system 1012 can control the allocation and use of components of mobile device 1002 and provide support for one or more application programs 1014 (also referred to as "applications" or "apps"). The application programs 1014 may include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications) and any other computing application (e.g., word processing applications, mapping applications, media player applications).

Mobile device 1002 can include memory 1020. Memory 1020 may include non-removable memory 1022 and/or removable memory 1024. The non-removable memory 1022 may include RAM, ROM, flash memory, a hard disk, or other well-known memory devices or technologies. Removable memory 1024 may include flash memory or a Subscriber Identity Module (SIM) card, as is well known in GSM communication systems, or other well known memory devices or technologies such as "smart cards. Memory 1020 may be used to store data and/or code for operating system 1012 and application programs 1014. Example data may include web pages, text, images, sound files, video data, or other data to be transmitted to and/or received from one or more web servers or other devices via one or more wired or wireless networks. The memory 1020 may be used to store subscriber identifiers, such as International Mobile Subscriber Identities (IMSIs), and device identifiers, such as International Mobile Equipment Identifiers (IMEIs). Such identifiers may be transmitted to a network server to identify users and devices.

Many programs may be stored in memory 1020. Such programs include an operating system 1012, one or more application programs 1014, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing one or more of the following: the system 100 of fig. 1, the system 200 of fig. 2, the sequence diagram 300 of fig. 3, the sequence diagram 400 of fig. 4, and the sequence diagram 500 of fig. 5, along with any components thereof and/or sub-components thereof, and any operations and portions of the flow charts/flow diagrams described herein and/or other examples described herein.

The mobile device 1002 may support one or more input devices 1030 (such as a touch screen 1032, a microphone 1034, a camera 1036, a physical keyboard 1038, and/or a trackball 1040), and one or more output devices 1050 (such as a speaker 1052 and a display 1054). Other possible output devices (not shown) may include piezoelectric or other haptic output devices. Some devices may provide more than one input/output function. For example, the touch screen 1032 and the display 1054 may be combined in a single input/output device. The input device 1030 may include a Natural User Interface (NUI).

As is well known in the art, one or more wireless modems 1060 may be coupled to antenna(s) (not shown) and may support bi-directional communication between the processor 1010 and external devices. The modem 1060 is shown generally and may include a cellular modem 1066 for communicating with the mobile communication network 1004 and/or other radio-based modems (e.g., bluetooth 1064 and/or Wi-Fi 1062). The at least one wireless modem 1060 is typically configured to communicate with one or more cellular networks, such as a GSM network for data and voice communications within a single cellular network, between cellular networks, or between a mobile device and a Public Switched Telephone Network (PSTN).

The mobile device 1002 may also include at least one input/output port 1080, a power supply 1082, a satellite navigation system receiver 1084, such as a Global Positioning System (GPS) receiver, an accelerometer 1086, and/or a physical connector 1090, where the physical connector 1090 may be a USB port, an IEEE 1394 (FireWire) port, and/or an RS-232 port. The illustrated components of mobile device 1002 are not required or all inclusive, as any components may be deleted and other components may be added as will be appreciated by those skilled in the art.

In one embodiment, mobile device 1002 is configured to implement any of the above-described features of the flow diagrams/embodiments herein. Computer program logic for performing any of the operations, steps, and/or functions described herein may be stored in memory 1020 and executed by processor 1010.

FIG. 11 is a block diagram of an example computing device that may be used to implement various embodiments. For example, the embodiments described herein may be implemented in one or more computing devices similar to computing device 1100 in fixed or mobile computer embodiments, including one or more features and/or alternative features of computing device 1100. The description of computing device 1100 provided herein is provided for purposes of illustration and is not intended to be limiting. Embodiments may be implemented in other types of computer systems and/or game consoles, etc., as will be appreciated by those skilled in the relevant art(s).

As shown in fig. 11, computing device 1100 includes one or more processors (referred to as processor circuit 1102), a system memory 1104, and a bus 1106, the bus 1106 coupling various system components including the system memory 1104 to the processor circuit 1102. The processor circuit 1102 is an electrical and/or optical circuit implemented as a Central Processing Unit (CPU), microcontroller, microprocessor, and/or other physical hardware processor circuit in one or more physical hardware circuit device elements and/or integrated circuit devices (semiconductor material chips or dies). The processor circuit 1102 may execute program code stored in a computer readable medium, such as program code of an operating system 1130, application programs 1132, other programs 1134, and the like. Bus 1106 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus, using any of a variety of bus architectures. The system memory 1104 includes Read Only Memory (ROM) 1108 and Random Access Memory (RAM) 1110. A basic input/output system 1112 (BIOS) is stored in ROM 1108.

Computing device 1100 also has one or more of the following drives: a hard disk drive 1114 for reading from and writing to a hard disk, a magnetic disk drive 1116 for reading from or writing to a removable magnetic disk 1118, and an optical disk drive 1120 for reading from or writing to a removable optical disk 1122 such as a CD ROM, DVD ROM, or other optical media. The hard disk drive 1114, magnetic disk drive 1116 and optical disk drive 1120 can be connected to the bus 1106 by a hard disk drive interface 1124, a magnetic disk drive interface 1126 and an optical drive interface 1128, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk, and a removable optical disk are described, other types of hardware-based computer readable storage media can be used to store data, such as flash memory cards, digital video disks, RAM, ROM, and other hardware storage media.

A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such programs include an operating system 1130, one or more application programs 1132, other programs 1134, and program data 1136. The application 1132 or other program 1134 may include, for example, computer program logic (e.g., computer program code or instructions) for implementing the embodiments described herein, such as the system 100 of fig. 1, the system 200 of fig. 2, the sequence diagram 300 of fig. 3, the sequence diagrams 400 of fig. 4, and the sequence diagram 500 of fig. 5, along with any components and/or sub-components thereof, and any operations and portions of the flowcharts/flow diagrams described herein and/or other examples described herein.

A user may enter commands and information into the computing device 1100 through input devices such as a keyboard 1138 and pointing device 1140. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, touch screen, and/or a touch pad, a voice recognition system for receiving voice input, a gesture recognition system for receiving gesture input, or the like. These and other input devices are often connected to the processor circuit 1102 through a serial port interface 1142 that is coupled to the bus 1106, but may be connected by other interfaces, such as a parallel port, game port or a Universal Serial Bus (USB).

A display screen 1144 is also connected to bus 1106 via an interface, such as a video adapter 1146. Display screen 1144 may be external to computing device 1100 or incorporated into computing device 1100. The display 1144 may display information and be a user interface for receiving user commands and/or other information (e.g., via touch, finger gestures, virtual keyboard, etc.). In addition to the display 1144, the computing device 1100 may include other peripheral output devices (not shown), such as speakers and printers.

The computing device 1100 is connected to a network 1148 (e.g., the internet) through an adapter or network interface 1150, modem 1152, or other means for establishing communications over the network. Modem 1152, which may be internal or external, may be connected to bus 1106 via serial port interface 1142, as shown in fig. 11, or may be connected to bus 1106 using another interface type, including a parallel interface.

As used herein, the terms "computer program medium," "computer-readable medium," and "computer-readable storage medium" are used to refer to physical hardware media such as the hard disk associated with hard disk drive 1114, removable magnetic disk 1118, removable optical disk 1122, other physical hardware media such as RAM, ROM, flash memory cards, digital video disks, zip disks, MEM, nanotechnology-based storage devices, and other types of physical/tangible hardware storage media (including memory 1104 of fig. 11). Such computer-readable media and/or storage media are distinct from and non-overlapping (excluding) the communication media and the propagated signals. Communication media embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, RF, infrared and other wireless media and wired media. Embodiments also relate to communication media that are separate and non-overlapping from embodiments that relate to computer-readable storage media.

As described above, computer programs and modules (including application programs 1132 and other programs 1134) may be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received via network interface 1150, serial port interface 1142, or any other interface type. Such computer programs, when executed or loaded by an application, enable computing device 1100 to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of the computing device 1100.

Embodiments also relate to computer program products that include computer code or instructions stored on any computer-readable medium or on computer-readable storage media. Such computer program products include hard disk drives, optical disk drives, storage device packages, portable memory sticks, memory cards, and other types of physical storage hardware.

Additional exemplary embodiments

A system includes a first computing device. The first computing device includes: a processing circuit; a secure memory connected to the processing circuit, the secure memory storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers; and a memory connected to the processing circuit, the memory storing computer program instructions executable by the processing circuit to cause the processing circuit to: receiving, via a second computing device, a user authentication request from the user authentication service, the second computing device being connected to the user authentication service and being wirelessly connected to the first computing device; displaying information related to the user authentication request; receiving approval of the user authentication request; transmitting the approval of the user authentication request to the second computing device; receiving a token from the second computing device, the token comprising a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request; signing the token with the private key to generate a signed token; and providing the signed token to the second computing device for subsequent transmission to the user authentication service, the signed token and the public key being usable by the user authentication service to determine that the user authentication request is to be authorized.

In an embodiment of the foregoing system, the user authentication request comprises a challenge, and wherein the approval of the user authentication request comprises a user response to the challenge.

In another embodiment of the foregoing system, the first computing device comprises a wearable computing device.

Further in accordance with such an embodiment, the wearable computing device comprises a smart watch.

In yet another embodiment of the foregoing system, the wearable computing device is in an unlocked state.

In another embodiment of the foregoing system, the second computing device comprises a smart phone.

In yet another embodiment of the foregoing system, the smart phone is in a locked state.

In yet another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via a Bluetooth connection.

In another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via an IEEE 802.11 connection.

In a further embodiment of the foregoing system, the value comprises a cryptographic random number.

In another embodiment of the foregoing system, the system further comprises the second computing device; wherein the computer program instructions are further executable by the processing circuitry to cause the processing circuitry to: generating the signing key pair; storing the signing key pair in the secure memory; and transmitting the public key to the second computing device; and wherein the second computing device is configured to: registering the public key with the user authentication service.

In yet another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: the signing key pair is generated only if a personal identification code has been enabled for the first computing device.

In yet another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: deleting the signing key pair in response to determining that the personal identification code has been disabled for the first computing device.

In a further embodiment of the foregoing system, the second computing device is configured to register the public key with the user authentication service by: acquiring user authentication input; providing the user authentication input to the user authentication service; receive a time-limited token from the user authentication service in response to providing the user authentication input; and registering the public key with the user authentication service using the time-limited token.

Another system including a first computing device is also described herein. The first computing device includes: a processing circuit; a secure memory connected to the processing circuit, the secure memory storing a personal identification code, the personal identification code being registered with a user authentication service comprising one or more user authentication servers; a memory connected to the processing circuit, the memory storing computer program instructions executable by the processing circuit to cause the processing circuit to: receiving a user authentication request from the user authentication service to which the first computing device is connected; transmitting the user authentication request to a second computing device to which the first computing device is wirelessly connected; receiving approval of the user authentication request from the second computing device; and after receiving the approval of the user authentication request from the second computing device, reading the personal identification code from the secure memory and transmitting the personal identification code to the user authentication service, the personal identification code being usable by the user authentication service to determine that the user authentication request is to be authorized.

In another embodiment of the foregoing system, the computer program instructions are further executable by the processing circuit to cause the processing circuit to: transmitting an authentication details request to the user authentication service in response to receiving the approval of the user authentication request from the second computing device; receiving authentication details from the user authentication service, the authentication details indicating that the personal identification code must be provided; and in response to receiving the authentication details, reading the personal identification code from the secure memory and transmitting the personal identification code to the user authentication service.

In yet another embodiment of the foregoing system, the second computing device comprises a wearable computing device.

In yet another embodiment of the foregoing system, the wearable computing device comprises a smart watch.

In yet another embodiment of the foregoing system, the first computing device comprises a smart phone.

In yet another embodiment of the foregoing system, the first computing device is wirelessly connected to the second computing device via an IEEE 802.11 connection.

Also described herein is a method in a first computing device storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers. The method comprises the following steps: receiving, via a second computing device, a user authentication request from the user authentication service, the second computing device being connected to the user authentication service and being wirelessly connected to the first computing device; displaying information related to the user authentication request; receiving approval of the user authentication request; transmitting the approval of the user authentication request to the second computing device; receiving a token from the second computing device, the token comprising a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request; signing the token with the private key to generate a signed token; and providing the signed token to the second computing device for subsequent transmission to the user authentication service, the signed token and the public key being usable by the user authentication service to determine that the user authentication request is to be authorized.

In another embodiment of the foregoing method, the user authentication request comprises a challenge, and wherein the approval of the user authentication request comprises a user response to the challenge.

In yet another embodiment of the foregoing method, the first computing device comprises a wearable computing device.

In yet another embodiment of the foregoing method, the wearable computing device is in an unlocked state.

In yet another embodiment of the foregoing method, the second computing device comprises a smart phone.

In yet another embodiment of the foregoing method, the smart phone is in a locked state.

In yet another embodiment of the foregoing method, the first computing device is wirelessly connected to the second computing device via a Bluetooth connection.

In yet another embodiment of the foregoing method, the first computing device is wirelessly connected to the second computing device via an IEEE 802.11 connection.

In a further embodiment of the foregoing method, the value comprises a cryptographic random number.

In a further embodiment of the foregoing method, the method further comprises: generating the signing key pair; storing the signing key pair in a secure memory of the first computing device; and transmitting the public key to the second computing device such that the second computing device can register the public key with the user authentication service.

In yet another embodiment of the foregoing method, the signing key pair is generated only if a personal identification code has been enabled for the first computing device.

In yet another embodiment of the foregoing method, the signing key pair is deleted in response to determining that the personal identification code has been disabled for the first computing device.

Conclusion of V

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

1. An authentication system, comprising:

A first computing device, comprising:

A processing circuit;

A secure memory connected to the processing circuit, the secure memory storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers; and

A memory connected to the processing circuit, the memory storing computer program instructions executable by the processing circuit to cause the processing circuit to:

Receiving, via a second computing device, a user authentication request from the user authentication service, the user authentication request including a challenge, the second computing device being connected to the user authentication service via one or more networks and being wirelessly connected to the first computing device;

Displaying information related to the user authentication request;

receiving an approval of the user authentication request, the approval including a user response to the challenge;

transmitting the approval of the user authentication request to the second computing device;

receiving a token from the second computing device, the token comprising a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request;

Signing the token with the private key to generate a signed token; and

The signature token is provided to the second computing device for subsequent transmission to the user authentication service, the signature token and the public key being usable by the user authentication service to determine that the user authentication request is to be authorized.

2. The system of claim 1, further comprising:

the second computing device;

Wherein the computer program instructions are further executable by the processing circuitry to cause the processing circuitry to:

Generating the signing key pair;

storing the signing key pair in the secure memory; and

Transmitting the public key to the second computing device; and

Wherein the second computing device is configured to:

Registering the public key with the user authentication service.

3. The system of claim 2, wherein the computer program instructions are further executable by the processing circuit to cause the processing circuit to:

The signing key pair is generated only if a personal identification code has been enabled for the first computing device.

4. The system of claim 3, wherein the computer program instructions are further executable by the processing circuit to cause the processing circuit to:

Deleting the signing key pair in response to determining that the personal identification code has been disabled for the first computing device.

5. The system of claim 2, wherein the second computing device is configured to register the public key with the user authentication service by:

acquiring user authentication input;

providing the user authentication input to the user authentication service;

Receiving a time-limited token from the user authentication service in response to providing the user authentication input; and

Registering the public key with the user authentication service using the time-limited token.

6. The system of claim 1, wherein the value comprises a cryptographic random number.

7. An authentication system, comprising:

A first computing device, comprising:

A processing circuit;

a secure memory connected to the processing circuit, the secure memory storing a personal identification code, the personal identification code being registered with a user authentication service comprising one or more user authentication servers;

Receiving a user authentication request from a user authentication service to which the first computing device is connected via one or more networks;

Transmitting the user authentication request to a second computing device, the first computing device being wirelessly connected to the second computing device;

receiving approval of the user authentication request from the second computing device; and

Upon receiving the approval of the user authentication request from the second computing device, reading the personal identification code from the secure memory and transmitting the personal identification code to the user authentication service, the personal identification code being usable by the user authentication service to determine that the user authentication request is to be authorized;

Transmitting an authentication details request to the user authentication service in response to receiving the approval of the user authentication request from the second computing device;

receiving authentication details from the user authentication service, the authentication details indicating that the personal identification code must be provided; and

In response to receiving the authentication details, the personal identification code is read from the secure memory and transmitted to the user authentication service.

8. The authentication system of claim 7, wherein the second computing device comprises a wearable computing device.

9. The authentication system of claim 8, wherein the wearable computing device comprises a smart watch and the first computing device comprises a smart phone.

10. The authentication system of claim 9, wherein the wearable computing device is in an unlocked state and the smartphone is in a locked state.

11. The authentication system of claim 7, wherein the first computing device is wirelessly connected to the second computing device via a bluetooth connection or an IEEE 802.11 connection.

12. A method in a first computing device storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers, the method comprising:

Receiving, via a second computing device, a user authentication request from the user authentication service, the second computing device being connected to the user authentication service via one or more networks and being wirelessly connected to the first computing device;

Displaying information related to the user authentication request;

Receiving approval of the user authentication request;

receiving a token from the second computing device, the token comprising a value obtained by the second computing device from the user authentication service in response to receiving the approval of the user authentication request, the value comprising a cryptographic random number value;

Signing the token with the private key to generate a signed token; and

13. The method of claim 12, wherein the user authentication request comprises a challenge, and wherein the approval of the user authentication request comprises a user response to the challenge.

14. The method of claim 12, wherein the first computing device comprises a wearable computing device.

15. The method of claim 14, wherein the wearable computing device comprises a smart watch and the second computing device comprises a smart phone.

16. The method of claim 15, wherein the wearable computing device is in an unlocked state and the smartphone is in a locked state.

17. The method of claim 12, further comprising:

Generating the signing key pair;

Storing the signing key pair in a secure memory of the first computing device; and

Transmitting the public key to the second computing device enables the second computing device to register the public key with the user authentication service.

18. The method of claim 17, further comprising:

Generating the signing key pair only if a personal identification code has been enabled for the first computing device; and

19. A method in a first computing device storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers, the method comprising:

Displaying information related to the user authentication request;

Signing the token with the private key to generate a signed token; and

20. A method in a first computing device storing a signing key pair comprising a private key and a public key, the public key being registered with a user authentication service comprising one or more user authentication servers, the method comprising:

Displaying information related to the user authentication request;

Receiving approval of the user authentication request;

Signing the token with the private key to generate a signed token; and

Providing the signature token to the second computing device for subsequent transmission to the user authentication service, the signature token and the public key being usable by the user authentication service to determine that the user authentication request is to be authorized, the method further comprising:

Generating the signing key pair;