Authentication Using Key Sharing

Abstract

The client may send an authentication request to the server, and the server may initiate a key agreement process using a server-generated short-lived private key and the device's public key to generate a shared secret and derive a symmetric key. The symmetric key may be used to encrypt a random challenge. The server then initiates a key agreement process for the client using a partial private key generated for the client and a server-generated short-lived public key. The partial key agreement result and the encrypted random challenge may be sent to the client. The client may complete the key agreement process using the partial key agreement result and each portion of the private key. The client may derive an encryption key and decrypt the random challenge. An indication of the random challenge may be sent to the server, which authenticates the client.

Description

Technical Field

[0001] This patent application is a national stage application of International Patent Application No. PCT / US2021 / 013221, entitled "AUTHENTICATION USING KEY AGREEMENT" by Pedda et al., which claims priority to U.S. Patent Application No. 16 / 938,632, entitled "AUTHENTICATION USING KEY AGREEMENT" by Pedda et al., filed on July 24, 2020, which has been assigned to the assignee of this application and is hereby expressly incorporated by reference in its entirety.

[0002] The present disclosure generally relates to database systems and data processing, and more specifically to authentication using key sharing.

Background Art

[0003] Cloud platforms (i.e., computing platforms for cloud computing) are used by many users to store, manage, and process data using a shared network of remote servers. Users may develop applications on the cloud platform to handle the storage, management, and processing of data. In some cases, the cloud platform may utilize a multi-tenant database system. Users may access the cloud platform using various user devices (such as desktop computers, laptops, smartphones, tablets, or other computing systems).

[0004] In one example, the cloud platform may support a customer relationship management (CRM) solution. This may include support for sales, service, marketing, community, analytics, applications, Internet of Things, etc. The user may utilize the cloud platform to assist in managing the user's contacts. For example, managing the user's contacts may include analyzing data, storing and preparing communications, and tracking opportunities and sales.

[0005] Encryption keys are used in various applications including user authentication. In some examples, the key may be used to authenticate a user to the system. If the key is compromised, user data may be compromised. For example, a compromised key may be used by someone to access user data via an application.

Brief Description of the Drawings

[0006]

Figure 1

[0007]

Figure 2

[0008]

Figure 3

[0009]

Figure 4

[0010]

Figure 5

[0011]

Figure 6

[0012]

Figure 7

[0013]

Figure 8

[0014]

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0015] Encryption keys are used in various applications including user authentication. In some examples, the key may be used to authenticate a user to a system. If the key is compromised, user data may be compromised. For example, a compromised key may be used by someone to access user data through an application.

[0016] The implementations described herein utilize a key sharing protocol to perform authentication of clients at a server. A client device, such as a mobile device running an application, may request access to a server (e.g., a server supporting the application). The access request may correspond to an account request. In response to a login request, the server may generate an asymmetric key pair including a public key and a private key. The server may split the private key and store the first part of the private key at the server. The second part of the private key may be sent to the client device. The client device may split the second part into two sub - parts, where the first sub - part is known to the user and the second sub - part is stored at the device. Thereby, the client provisioning process may be completed.

[0017] When the client attempts to login, the server may start a key sharing process using a short - lived private key generated at the server and the public key of the device, generate a shared secret, and derive a symmetric key using the shared secret. The symmetric key may be used to encrypt a random challenge. Further, the server may start a key sharing process for the client using a partial private key generated for the client and a short - lived public key generated at the server. The partial key sharing result and the encrypted random challenge may be sent to the client. The client may complete the key sharing process using the partial key sharing result and the two sub - parts of the private key, which may result in a shared secret. The shared secret may then be used to derive the same encryption key that is used to decrypt the random challenge. The indication of the random challenge may be sent to the server that authenticates the client.

[0018] In some examples, the asymmetric key pair may be generated using an elliptic curve process. Further, the key sharing process may utilize the ECDH (Elliptic-Curve Diffie-Hellman) protocol to derive a shared secret. Thus, leveraging this cryptographic protocol, a client may store the portion of the key used to derive the key for decrypting a random challenge. This may result in a more secure application and client authentication.

[0019] The disclosed aspects are first described in an environment supporting an on-demand database service. The disclosed aspects are further described with respect to general system diagrams, specific system diagrams, and process flow diagrams. The disclosed aspects are further illustrated and described with reference to apparatus diagrams, system diagrams, and flowcharts related to authentication using key sharing.

[0020] FIG. 1 illustrates an example of a system 100 for cloud computing that supports authentication using key agreement, according to an aspect of the present disclosure. System 100 includes a cloud client 105, a contact 110, a cloud platform 115, and a data center 120. The cloud platform 115 may be an example of a public or private cloud network. The cloud client 105 may access the cloud platform 115 via a network connection 135. The network may implement a TCP / IP (transfer control protocol and internet protocol) protocol such as the Internet, or other network protocols. The cloud client 105 may be an example of a user device such as a server (e.g., cloud client 105-a), a smartphone (e.g., cloud client 105-b), a laptop (e.g., cloud client 105-c), etc. In other examples, the cloud client 105 may be a desktop computer, a tablet, a sensor, or any other computing device or system capable of generating, analyzing, transmitting, or receiving communications. In some examples, the cloud client 105 may be operated by a user who is part of a business, enterprise, non-profit, startup, or any other organizational type.

[0021] The cloud client 105 may interact with a plurality of contacts 110. The interaction 130 may include communication, opportunities, purchases, sales, or any other interaction between the cloud client 105 and the contact 110. Data may be associated with the interaction 130. The cloud client 105 may access the cloud platform 115 to store, manage, and process the data associated with the interaction 130. In some cases, the cloud client 105 may have an associated security level or permission level. The cloud client 105 may access applications, data, and database information within the cloud platform 115 based on the associated security or permission level, and may not access others.

[0022] The contact 110 may interact with the cloud client 105 directly or via telephone, email, web, text message, mail, or any other suitable form of interaction (e.g., interactions 130-a, 130-b, 130-c, and 130-d). The interaction 130 may be a B2B (business-to-business) interaction or a B2C (business-to-consumer) interaction. The contact 110 may also be referred to by a customer, potential customer, lead, client, or any other suitable technical term. In some cases, the contact 110 may be an example of a user device such as a server (e.g., contact 110-a), laptop (e.g., contact 110-b), smartphone (e.g., contact 110-c), sensor (e.g., contact 110-d), etc. In other cases, the contact 110 may be another computing system. In some cases, the contact 110 may be operated by a user or a group of users. The user or group of users may be associated with a business, manufacturer, or any other suitable organization.

[0023] The cloud platform 115 may provide an on-demand database service to the cloud client 105. In some cases, the cloud platform 115 may be an example of a multi-tenant database system. In this case, the cloud platform 115 may serve multiple cloud clients 105 with a single software instance. However, other types of systems including, but not limited to, client-server systems, mobile device systems, and mobile network systems may be implemented. In some cases, the cloud platform 115 may support a CRM solution. This may include support for sales, service, marketing, community, analytics, applications, Internet of Things, etc. The cloud platform 115 may receive data associated with the contact interaction 130 from the cloud client 105 via the network connection 135, and may store and analyze the data. In some cases, the cloud platform 115 may receive data directly from the interaction 130 between the contact 110 and the cloud client 105. In some cases, the cloud client 105 may develop an application that operates on the cloud platform 115. The cloud platform 115 may be implemented using a remote server. In some cases, the remote server may be located in one or more data centers 120.

[0024] The data center 120 may include multiple servers. The multiple servers may be used for data storage, management, and processing. The data center 120 may receive data from the cloud platform 115 via the connection 140, or directly from the cloud client 105 or from the interaction 130 between the contact 110 and the cloud client 105. The data center 120 may utilize multiple redundancies for security purposes. In some cases, the data stored in the data center 120 may be backed up by copies of the data in different data centers (not depicted).

[0025] The subsystem 125 may include a cloud client 105, a cloud platform 115, and a data center 120. In some cases, data processing may occur in any of the components of the subsystem 125, or in a combination of these components. In some cases, a server may execute data processing. The server may be the cloud client 105 or may be located in the data center 120.

[0026] The application server may support applications that can be executed on user devices. Before the application and the user access various services, the application may need to be authenticated by the server. In some cases, an authentication key or access token may be used for access. However, key management is complex and may be subject to human influence in a man-in-the-middle attack, and an unauthorized party may obtain access to the key and access the user data and services supported by the application.

[0027] The cloud platform 115 may support authentication based on key sharing. Although the implementation is described with respect to application and user authentication, it should be understood that the implementation described herein is also applicable in other scenarios. The cloud platform 115 may support an application server that supports applications that may be executed on the devices of the cloud client 105 and / or the contact 110. In some cases, the application server that supports these implementations may be used by the cloud client 105 to authenticate the contact 110. When the device first requests access to the application server, the application server may generate an asymmetric key pair including a private key and a public key. The private key may be split into two parts, and the first part may be stored on the server. The second part of the split private key may be shared with the device (e.g., the cloud client 105 or the contact 110). In some cases, the second part may be further split into sub-parts, one of which may be known to the user and the other may be stored on the device. This process may be referred to as client provisioning.

[0028] Subsequently, when the user wants to log in to the application system, the server may generate a new short-lived asymmetric key pair including a short-lived private key and a short-lived public key in response to a request from the client. This may be a temporary asymmetric key pair used for this specific instance of the login. The short-lived private key and the public key associated with the (previously generated) client may be used to generate a shared secret (e.g., using the ECDH protocol). The shared secret may be used to derive a symmetric key that is used to encrypt a random challenge. Further, the server may initiate a key sharing process for the client using the part of the split private key stored on the server and the short-lived public key. The partial key sharing result and the encrypted random challenge may be digitally signed and sent to the client.

[0029] The client receives the signed and encrypted random challenge and the partial sharing result, and verifies the signature (e.g., using the public key associated with the server). During verification, the client may complete key sharing using the partial of the private key at the client. This may include receiving a sub - part (e.g., PIN) from the user and using both sub - parts, similar to the client public key, to generate a shared secret. Due to the encryption protocol used to generate the asymmetric keys, the server and the client may generate the same shared secret. That is, the server generates the shared secret using the client's public key and the ephemeral private key, and the client generates the shared secret using the private key of the device (using the partial key sharing at the server) and the ephemeral public key generated at the server, so the shared secret is the same. In this way, the client may derive the same symmetric key (e.g., using the same key derivation function) and decrypt the random challenge. The client may show the result of decrypting the random challenge to the server. The server may authenticate the client based on the indication of the random challenge. Thus, using this process, no single party (e.g., the client or the server) stores the entire private key used to derive the shared secret. Since user devices (e.g., smartphones, laptops) may be vulnerable to theft, storing parts (e.g., sub - parts) of the private key may prevent unauthorized access to the server. Additionally, these described techniques may prevent or limit the use of passwords for accessing a secure system. Thus, instead of the user entering a password, these techniques may be used to authenticate the user and the device.

[0030] Those skilled in the art should understand that one or more aspects of the present disclosure may be implemented in system 100 to additionally or alternatively solve other problems than those described above. Further, aspects of the present disclosure may provide technical improvements to "conventional" systems or processes as described herein. However, the description and the accompanying drawings only include exemplary technical improvements resulting from implementing aspects of the present disclosure, and thus do not represent all of the technical improvements provided within the scope of the claims.

[0031] For example, cloud client 105 may be supported by servers of cloud platform 115. A user such as contact 110 may download an application to a user device such as a smartphone. When downloading an application to the user device or when opening the application for the first time, the server may send a partial private key to the device. The application may request the user to enter a pin that can function as a sub - part of the private key. The other sub - part (the part obtained by subtracting the pin) may be securely stored in the user device. When logging in to the application, the application may send a request to the server, and the server may respond with a payload including an encrypted random challenge and a partial key sharing result. The application may request the user to complete key sharing to generate a shared secret using the sub - part of the private key corresponding to the pin entered by the user and the other sub - part stored in the device. The shared secret may be used to derive an encryption key to decrypt the random challenge. The application may send an instruction of the decrypted random challenge to the server, and the server may authenticate the user device to access the services of the application supported by the server.

[0032] Figure 2 illustrates an example of a system 200 that supports authentication using key sharing, according to an aspect of the present disclosure. The system 200 includes a client 205 and a server 210. The server 210 may be an example of an aspect of the cloud platform of FIG. 1. For example, the server 210 may be an example of an application server. The client 205 may correspond to a client device such as a laptop, desktop, smartphone, tablet, or other type of client system. In 250-a, a user of the client 205 may download an application supported by the implementation described herein.

[0033] Upon downloading, executing, etc. of the application, the client 205 may send an access request 220 to the server 210. In response, the server 210 may generate an asymmetric key pair including a public key and a private key. The private key may be split into a first part and a second part. The first part may be stored at the server, and the second part of the private key 225 may be shown to the client 205. In one example, the part may be displayed on the device (e.g., a QR code (registered trademark) that can be scanned by the client 205 may be generated and displayed). In another example, the part of the private key 225 may be sent using a secure communication channel, email, text message, etc.

[0034] Client 205 or the application of Client 205 may further split a portion of the private key 225 into sub-portions. In one example, the user of Client 205 is requested to enter a PIN. Based on the PIN and the sub-portion, Client 205 may identify an operator / operation (such as addition, multiplication, etc.) that can be used in conjunction with the PIN to generate the sub-portion. For example, a sub-portion of the portion of private key 225 may have a value of 1000. The user may enter a PIN of 1234. Thus, an operator such as (-234) may be identified so that the input of the PIN results in that portion (e.g., 1234 - 234 = 1000). Other sub-portions of the portion of private key 225 may be securely stored in Client 205. This process may complete the provisioning portion in implementation 250-a described herein.

[0035] After that, when the user wants to authenticate to server 210 via Client 205 in 250-b, the user may open an application in Client 205. In response, the application may send an authentication request 230 to server 210. Server 210 may generate a new short-lived asymmetric key pair that includes a short-lived public key and a short-lived private key. This short-lived asymmetric key pair may be an example of a one-time use key pair, because the private key may be discarded after these operations. The short-lived private key and public key generated during the provisioning process may be used to generate a shared secret (e.g., using a key sharing protocol). The shared secret may be input into a key derivation function that outputs a symmetric key. Then, using the symmetric key, a random challenge 240 (e.g., a random value) may be encrypted to result in an encrypted random challenge 245. Thereafter, the private key may be erased.

[0036] Furthermore, the server 210 may identify a partial private key corresponding to the client 205. Using the partial private key and the short-lived public key (e.g., one-time use key) of the asymmetric key, the server 210 executes a partial sharing process, which outputs a partial key sharing result 260. The encrypted random challenge 245 and the partial key sharing result 260 may be sent to the client 205 as the payload 235. In some cases, the payload 235, or a portion thereof, may be digitally signed using the signature private key of the server 210.

[0037] The client 205 receives the payload 235 and may verify the digital signature (e.g., using the signature public key of the server 210). If the payload 235 is verified, the client 205 may prompt for the user's PIN. The user may enter a PIN (e.g., 1234), and the client 205 may derive the corresponding sub-portion of the portion of the private key 225. For example, based on the determined operations described above, the client 205 may subtract the value 234 from the PIN to derive a sub-portion of the portion of the private key 225 (e.g., 1234 - 234 = 1000). The resulting value is combined with the portion of the private key stored in the client, which results in the portion of the private key 225. The portion of the private key 225 is used to complete the key sharing process using the partial key sharing result 260. This may result in a shared secret derived by the server using the client public key and the server private key. Thus, this shared secret is input into a key derivation function to derive a symmetric key that can be used to decrypt the encrypted random challenge 240. Next, the client 205 may send an indication of the random challenge 240 to the server 210, and the server 210 may authenticate the client 205 to access data, systems, and services.

[0038] In some cases, the server 210 may present a blind challenge, such as for verifying the client 205. This blind challenge may be included in the payload 235. This blind challenge may be used to prevent another client from attempting to log in to the server 210 at the same time as the client 205. For example, a user may enter a username that triggers an authentication request 230 (e.g., a login request). In response, the server 210 may send an instruction for the blind challenge to the user (e.g., via text, email, or some other communication means for an identifier associated with the user). The user may verify that they are attempting to log in by indicating a random number using the user interface in the client 205. Thus, if another client attempts to log in using the user's username, the actual user may be notified of the random blind challenge and reject the request. The blind challenge may be an example such as a random number, a capture, an image selection, etc.

[0039] FIG. 3 illustrates an example of a system 300 that supports authentication using key sharing, according to an aspect of the present disclosure. The system 300 includes a client 305 and a server 310, which may be examples of corresponding devices as described with respect to FIGS. 1 and 2. Specifically, the system 300 illustrates a client provisioning process that supports authentication using key sharing according to the implementation described herein.

[0040] Users of client 305 may sign up for an account using device applications such as mobile device applications, web applications, etc. In response to the user's sign-up, server 310 may generate an asymmetric key pair 315 including a public key 325 and a private key 320. In some cases, the asymmetric key pair 315 is generated using elliptic curve cryptography principles, and the key pair 315 may be referred to as an elliptic curve key pair. Server 310 may include a hardware security module (HSM). The HSM may be an example of a physically secure hardware system such as a chipset, or a logical or virtual security system. The HSM may support digital key derivation, encryption, decryption, digital signatures, authentication, and other cryptographic functions.

[0041] Server 310 (e.g., the HSM of the server) may split the private key 320 using a key splitting function at 360-a. The keys may be split according to multi-party computation principles. Those key splits result in a first part of the private key 330 and a second part of the private key 335 that is sent to client 305. The first part of the private key 330 may be securely stored in the data store of server 310. The splitting and dispersal of the keys may be referred to as secret sharing in some examples. Various types of secure secret sharing protocols and algorithms may be used.

[0042] The transmission of the second part of the private key 335 to client 305 may be supported using various techniques. According to one technique, a QR code may be displayed on or by a computing display. The user may use a mobile device to scan or read the QR code. In another case, the second part of the private key 335 is sent to the application via secure communication channels, such as via email, text message, etc. Various other techniques for transmitting the second part of the private key 335 are contemplated within the scope of the present disclosure.

[0043] In client 305, in some examples, the second part of the private key 335 may be stored in memory for subsequent authentication. In other examples, as illustrated in FIG. 3, the second part of the private key 335 is further divided into two sub-parts including a first sub-part 340 and a second sub-part 345 using a key splitting function 360-b. This splitting process may include presenting parts (e.g., pins) to the user, where the pins may correspond to the second sub-part 345. In other cases, the user is prompted to enter a pin, and an operator / action is generated based on the entered pin. Subsequently, the user may enter the pin, and the client may execute the action, which may result in the second sub-part 345. The first sub-part 340 may be securely stored in the client 305 in relation to the application. Thus, the second part of the private key 335 may be distributed between the device and the user, which may further enhance security in the implementations described herein. Subsequently, during the login / authentication process, the second part of the private key 335 may be utilized by the client 305 to authenticate at the server 310 by completing a key sharing process and decrypting a random challenge using the derived symmetric key. This process is further described with respect to FIG. 4.

[0044] FIG. 4 illustrates an example of a system 400 that supports authentication using key sharing, according to aspects of the present disclosure. The system includes a client 305 and a server 310, which may be examples of corresponding devices as described with respect to FIGS. 1 and 3. As illustrated in FIG. 3, the client 305 is provisioned with the second part of the private key 335, and the first part of the private key 330 is stored in the server 310. In FIG. 4, an authentication process is illustrated.

[0045] When the user attempts to log in on the client 305, the client 305 may send a login request to the server 310. In response, the server executes a first process 470 and a second process 475. The server may generate a short-lived asymmetric key pair 415 in response to the login request. The short-lived asymmetric key pair 415 includes a public key 420 (e.g., a short-lived public key) and a private key 425 (e.g., a short-lived private key). Since this asymmetric key pair may be used for this specific login instance, it may be a temporary key pair. Thus, when the user subsequently performs a subsequent login, another short-lived asymmetric key pair 415 may be generated. Further, since the short-lived private key 425 is erased after use, the public key 420 shall not be used for any authentication purposes. According to the first process 470, the server 310 initiates a key sharing process to be completed by the client. Using the first part of the private key 330 stored in the server and the public key 420 (e.g., the public key associated with the private key 425), the server 310 performs key sharing (e.g., using the ECDH protocol), which may result in a partial key sharing result 480. At this point, since the second part of the private key 335 is stored in the client 305 and not used to complete the key sharing process, the partial key sharing result 480 shall not be utilized for any authentication purposes.

[0046] According to the second process 475, the private key 425 and the public key 325 of the asymmetric key pair are used to generate a shared secret, and then a symmetric key 435-a is derived based on the shared secret. Note that the public key 325 is the public key associated with the private key 320 of FIG. 3, which was split into the first part of the private key 330 and the second part of the private key 335 during the client provisioning process of FIG. 3. The derived symmetric key 435-a is used to encrypt a random challenge 440 (e.g., a random number), resulting in an encrypted random challenge 440. The private key 425 may be erased from the server's memory.

[0047] The results of the first process 470, which is the partial key sharing result 480, and the results of the second process 475, which is the encrypted random challenge 440, may be sent to the client 305 as part of the payload (e.g., the payload 235 in FIG. 2). Optionally, the payload, or a portion thereof, may be digitally signed using the signature private key associated with the server.

[0048] The client 305 receives the payload. Optionally, the client 305 may verify the digital signature of the payload using the signature public key of the server, which may typically be included in a digital certificate. Further, if the second part of the secret key 335 is split into sub - part 345 - a and sub - part 345 - b, the client 305 may prompt the user for the second sub - part (or corresponding PIN). Using the first sub - part 345 - a and the second sub - part 345 - b, the client 305 may generate the second part of the secret key 335. Using the partial key sharing result 480 and the second part of the secret key 335, the client 305 may execute or complete a key sharing process, which may result in a shared secret (which may be the same as the shared secret used to derive the symmetric key 435 - a at the server according to the key sharing protocol). Using the shared secret, the client 305 may derive a symmetric key 435 - b, which may be the same symmetric key 435 - a. Thus, the client may decrypt the encrypted random challenge 440 using the symmetric key 435 - b to result in a random challenge 460. This random challenge 460 may be shown to the server 310, and the server 310 may authenticate the client 305.

[0049] The key derivation function (KDF) used to derive the symmetric key 435 may be agreed upon between the client 305 and the server 310. The KDF may be one of many key derivation functions. For example, the KDF may be an example such as an Advanced Encryption Standard (AES) function, a Galois / Counter mode (GCM) protocol, etc.

[0050] Figure 5 shows a process flow diagram 500 that supports authentication using key sharing, according to an aspect of the present disclosure. The process flow diagram includes a client 505 and a server 510, which may be examples of corresponding devices as described with respect to FIGS. 1-4.

[0051] At 515, the client 505 may send a sign-up request to the server. The sign-up request may also be referred to as an access request. In some examples, the sign-up request is sent in response to the user opening an application downloaded to the client 505. The client may be associated with a client public key.

[0052] At 520, the server 510 may generate an asymmetric key pair including a public key and a private key. The public key may be stored in the server 510.

[0053] At 525, the server 510 may store a first portion of the private key. That is, the server 510 may split the private key into a first portion and a second portion using multi-party computation principles.

[0054] At 530, the server 510 may send a second portion of the private key to the client 505. The operations at 515, 520, and 525 may correspond to a client provisioning process 590.

[0055] Thereafter, at 535, the server 510 may receive an authentication request from the client 505. The authentication request may correspond to a login at the client 505.

[0056] At 540, in response to receiving the authentication request, the server 510 may generate a short-lived asymmetric key pair. The asymmetric key pair may be generated using an elliptic curve process.

[0057] At 545, the server 510 may generate a symmetric key using the client public key and the short-lived private key of a short-lived asymmetric key pair, at least partially based on receiving an authentication request. To generate the symmetric key, the server 510 may perform a key sharing process that may result in a shared secret, and the shared secret may be used to derive the symmetric key.

[0058] At 550, the server 510 may encrypt a random challenge using the generated symmetric key. The random challenge may use a challenge-response authentication technique. For example, the random challenge may be a random character set. The server 510 and the client 505 may have pre-agreed on some processes or algorithms to identify the response to the random character set.

[0059] At 555, the server 510 may generate a partial key sharing result using the first part of the split private key. The partial key sharing result may also utilize the short-lived public key generated at the server. The key sharing process may be based on the ECDH protocol.

[0060] At 560, the server 510 may send the encrypted random challenge and the partial key sharing result to the client 505.

[0061] At 565, the client 505 may complete the key sharing process using the second part of the private key and the key sharing result. Completion of the key sharing may also utilize the public key generated during the client provisioning process. In some examples, the client 505 may verify the digital signature of the server 510 before completing the key sharing.

[0062] At 570, the client 505 may generate a symmetric key based on the shared secret, which is the result of completing the key sharing at 565. The symmetric key may be generated using a key derivation function.

[0063] At 575, client 505 may decrypt the random challenge received from server 510 using the derived symmetric key. At 580, server 510 may receive an indication of the decrypted random challenge. In some examples, this may include receiving a response to the random challenge derived based on an agreed-upon process or algorithm. As described herein, server 510 and client 505 may have pre-agreed on some processes or algorithms to identify a response to a random character set. For example, the random challenge may be a random character set, and the response to the random challenge may be some transformation of those random characters (based on the agreed-upon algorithm).

[0064] At 585, server 510 may authenticate client 505 based at least in part on receiving an indication of the success of the client's decryption of the random challenge. Operations 535 - 585 may correspond to authentication process 595.

[0065] FIG. 6 shows a block diagram 600 of an apparatus 605 that supports authentication using key sharing in accordance with an aspect of the present disclosure. Apparatus 605 may include an input module 610, a security manager 615, and an output module 655. Apparatus 605 may also include a processor. Each of these components may communicate with each other (e.g., via one or more buses). In some cases, apparatus 605 may be an example of a user terminal, a database server, or a system including a plurality of computing devices.

[0066] The input module 610 may manage input signals for the device 605. For example, the input module 610 may identify input signals based on interactions with a modem, keyboard, mouse, touch screen, or similar device. These input signals may be associated with user input or processing in other components or devices. In some cases, the input module 610 may utilize an operating system such as iOS®, ANDROID®, MS-DOS®, MS-WINDOWS®, OS / 2®, UNIX®, LINUX®, or other known operating systems to handle the input signals. The input module 610 may transmit the aspects of these input signals to other components of the device 605 for processing. For example, the input module 610 may transmit the input signals to the security manager 615 in accordance with aspects of the present disclosure. In some cases, the input module 610 may be a component of the input / output (I / O) controller 815 as described with reference to FIG. 8.

[0067] The security manager 615 may include an authentication interface 620, an asymmetric key component 625, a symmetric key component 630, an encryption component 635, a key sharing component 640, a random challenge component 645, and an authentication component 650. The security manager 615 may be an example of the aspects of the security manager 705 or 810 described with reference to FIGS. 7 and 8.

[0068] At least a part of the security manager 615 and / or its various sub-components may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, at least some of the functions of the security manager 615 and / or its various sub-components may be executed by a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described in this disclosure. At least a part of the security manager 615 and / or its various sub-components may be physically located in various places, including being distributed such that some of the functions are implemented at different physical locations by one or more physical devices. In some examples, at least a part of the security manager 615 and / or its various sub-components may be separate individual components according to various aspects of this disclosure. In other examples, at least a part of the security manager 615 and / or its various sub-components may be combined with one or more other hardware components including, but not limited to, I / O components, transceivers, network servers, another computing device, one or more other components described in this disclosure, or combinations thereof according to various aspects of this disclosure.

[0069] The authentication interface 620 may receive an authentication request from a client at the server.

[0070] In response to receiving the authentication request, the asymmetric key component 625 may generate a short-lived asymmetric key pair on the server, and the client is associated with the client public key.

[0071] The symmetric key component 630 may generate a symmetric key using the short-lived private key and the client public key of the short-lived asymmetric key pair based on receiving an authentication request.

[0072] The encryption component 635 may encrypt the random challenge using the generated symmetric key.

[0073] The key sharing component 640 may generate a partial key sharing result using the first part of the split private key. The server has sent the second part of the split private key to the client, and the split private key is associated with the client public key.

[0074] The random challenge component 645 may send the encrypted random challenge and the partial key sharing result to the client. The client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result.

[0075] The authentication component 650 may authenticate the client based on receiving an indication of successful decryption of the random challenge by the client.

[0076] The input module 655 may manage the output signal for the device 605. For example, the output module 655 may receive signals from other components of the device 605 such as the data holding module 615, and may send these signals to other components or devices. In some specific examples, the output module 655 may send the output signal for display at the user interface, storage in a database or data store, further processing in a server or server cluster, or any other processing in any number of devices or systems. In some cases, the output module 655 may be a component of the I / O controller 815 as described with reference to FIG. 8.

[0077] FIG. 7 shows a block diagram 700 of a security manager 705 that supports authentication using key sharing, according to an aspect of the present disclosure. The security manager 705 may be an example of the security manager 615 or the security manager 810 described herein. The security manager 705 may include an authentication interface 710, an asymmetric key component 715, a symmetric key component 720, an encryption component 725, a key sharing component 730, a random challenge component 735, an authentication component 740, a provisioning component 745, a key splitting component 750, a key transmission interface 755, a key encoding component 760, a display component 765, a QR code component 770, a client interface 775, a key storage component 780, a key erasure component 785, and a digital signature component 790. Each of these modules may communicate directly or indirectly with each other (e.g., via one or more buses).

[0078] The authentication interface 710 may receive an authentication request from a client at the server.

[0079] In response to receiving the authentication request, the asymmetric key component 715 may generate a short-lived asymmetric key pair on the server, and the client is associated with the client public key.

[0080] In some examples, the asymmetric key component 715 may generate a first key pair including a client public key and a secret key based on the request.

[0081] In some examples, the asymmetric key component 715 may generate an elliptic curve key pair as a short-lived asymmetric key pair including a short-lived secret key and a short-lived public key based on receiving the authentication request.

[0082] In response to receiving the authentication request, the symmetric key component 720 may generate a symmetric key using the short-lived secret key of the short-lived asymmetric key pair and the client public key.

[0083] In some examples, the symmetric key component 720 may generate a symmetric key using a server private key and a client public key, and the partial key sharing result is generated using a first part of the split private key and the server public key, such that the client can derive the symmetric key using a second part of the split private key of the short-lived asymmetric key pair and the short-lived public key.

[0084] In some examples, the symmetric key component 720 may use the ECDH (Elliptic-Curve Diffie-Hellman) protocol to generate a symmetric key and a partial key sharing result.

[0085] The encryption component 725 may encrypt the random challenge using the generated symmetric key.

[0086] The key sharing component 730 may generate a partial key sharing result using a first part of the split private key, and the server has sent a second part of the split private key to the client, where the split private key is associated with the client public key.

[0087] The random challenge component 735 may send the encrypted random challenge and the partial key sharing result to the client, and the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result.

[0088] The authentication component 740 may authenticate the client based on receiving an indication of successful decryption of the random challenge by the client.

[0089] The provisioning component 745 may receive a request for authentication from the client at the server.

[0090] The key splitting component 750 may generate a split private key including a first part of the split private key and a second part of the split private key based on the private key.

[0091] The key transmission interface 755 may send an instruction of the second part of the split secret key, and the server is configured to receive an authentication request from the client based on sending the instruction of the second part of the split secret key to the client.

[0092] The key encoding component 760 may generate an encoded version of the second part of the split secret key.

[0093] The display component 765 may cause a display of the encoded version of the first part of the split secret key on the user interface of the computing device.

[0094] The QR code component 770 may generate a Quick Response (QR) code, and the QR code is displayed to the user on the user interface.

[0095] The client interface 775 may cause the first sub - part of the second part of the split secret key to be stored at the client.

[0096] In some examples, the client interface 775 may cause a display of the second part of the split secret key to be displayed by the user interface.

[0097] The client interface 775 may verify the user to the user device associated with the client, at least in part based on sending a blind challenge in response to the authentication request and receiving an instruction of the blind challenge.

[0098] The key storage component 780 may store the first part of the split secret key in association with the client public key.

[0099] The key erasure component 785 may erase the short-lived secret key from memory in response to generating a symmetric key using the short-lived secret key, which results in the short-lived secret key being a one-time use key.

[0100] The digital signature component 790 may generate a digital signature of the encrypted random challenge using the server signature secret key, such that the client can verify the encrypted random challenge using the server signature public key.

[0101] FIG. 8 shows a diagram of a system 800 including a device that supports authentication using key sharing, according to an aspect of the present disclosure. The device 805 may be an example of, or may include, components of the application server or device 605 as described herein. The device 805 may include components for two-way data communication including components for transmitting and receiving communications, including a security manager 810, an I / O controller 815, a database controller 820, a memory 825, a processor 830, and a database 835. These components may be in electronic communication via one or more buses (e.g., bus 840).

[0102] The security manager 810 may be an example of the security manager 615 or 705 as described herein. For example, the security manager 810 may execute any of the methods or processes described above with reference to FIGS. 6 and 7. In some cases, the security manager 810 may be implemented in hardware, software executed by a processor, firmware, or any combination thereof.

[0103] The I / O controller 815 may manage input signal 845 and output signal 850 for device 805. The I / O controller 815 may also manage peripheral devices not integrated with device 805. In some cases, the I / O controller 815 may represent a physical connection or port to an external peripheral device. In some cases, the I / O controller 815 may utilize an operating system such as iOS (registered trademark), ANDROID (registered trademark), MS-DOS (registered trademark), MS-WINDOWS (registered trademark), OS / 2 (registered trademark), UNIX (registered trademark), LINUX (registered trademark), or other known operating systems. In other cases, the I / O controller 815 may represent or interact with a modem, keyboard, mouse, touch screen, or similar devices. In some cases, the I / O controller 815 may be implemented as part of a processor. In some cases, the user may interact with device 805 via the I / O controller 815 or via hardware components controlled by the I / O controller 815.

[0104] The database controller 820 may manage data storage and processing within database 835. In some cases, the user may interact with the database controller 820. In other cases, the database controller 820 may operate automatically without user interaction. The database 835 may be an example of a single database, distributed database, multiple distributed databases, data store, data lake, or emergency backup database.

[0105] Memory 825 may include a random access memory (RAM) and a read-only memory (ROM). When executed, memory 825 may store computer-readable computer-executable software that includes instructions to cause a processor to perform various functions described herein. In some cases, memory 825 may include, among other things, a BIOS (basic input / output system) that can control basic hardware or software operations, such as interactions with peripheral components or devices.

[0106] Processor 830 may include an intelligent hardware device (e.g., a general-purpose processor, a DSP, a central processing unit (CPU), a microcontroller, an ASIC, an FPGA, a programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof). In some cases, processor 830 may be configured to operate a memory array using a memory controller. In other cases, the memory controller may be integrated into processor 830. Processor 830 may be configured to execute computer-readable instructions stored in memory 825 to perform various functions (e.g., functions or tasks that support authentication using key sharing).

[0107] FIG. 9 shows a flowchart illustrating a method 900 for supporting authentication using key sharing, according to an aspect of the present disclosure. The operations of method 900 may be implemented by an application server or a component thereof as described herein. For example, the operations of method 900 may be performed by a security manager as described with reference to FIGS. 6-8. In some examples, the application server may execute a set of instructions for controlling functional elements of the application server to perform the functions described below. Additionally or alternatively, the application server may use special-purpose hardware to perform aspects of the functions described below.

[0108] At 905, the application server may receive an authentication request at the server from a client. The operation of 905 may be executed according to the method described in this specification. In some examples, the operation mode of 905 may be executed by an authentication interface as described with reference to FIGS. 6 to 8.

[0109] At 910, in response to receiving an authentication request, the application server may generate a short-lived asymmetric key pair on the server, and the client is associated with the client public key. The operation of 910 may be executed according to the method described in this specification. In some examples, the operation mode of 910 may be executed by an asymmetric key component as described with reference to FIGS. 6 to 8.

[0110] At 915, based on receiving an authentication request, the application server may generate a symmetric key using the short-lived private key of the short-lived asymmetric key pair and the client public key. The operation of 915 may be executed according to the method described in this specification. In some examples, the operation mode of 915 may be executed by a symmetric key component as described with reference to FIGS. 6 to 8.

[0111] At 920, the application server may encrypt a random challenge using the symmetric key. The operation of 920 may be executed according to the method described in this specification. In some examples, the operation mode of 920 may be executed by an encryption component as described with reference to FIGS. 6 to 8.

[0112] At 925, the application server may generate a partial key sharing result using the first part of the split private key, and the server has sent the second part of the split private key to the client, and the split private key is associated with the client public key. The operation of 925 may be executed according to the method described in this specification. In some examples, the operation mode of 925 may be executed by a key sharing component as described with reference to FIGS. 6 to 8.

[0113] At 930, the application server may send an encrypted random challenge and a partial key sharing result to the client, and the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result. The operation of 930 may be performed according to the method described herein. In some examples, the manner of operation of 930 may be performed by a random challenge component as described with reference to FIGS. 6-8.

[0114] At 935, the application server may authenticate the client based on receiving an indication of successful decryption of the random challenge by the client. The operation of 935 may be performed according to the method described herein. In some examples, the manner of operation of 935 may be performed by an authentication component as described with reference to FIGS. 6-8.

[0115] FIG. 10 shows a flowchart illustrating a method 1000 for supporting authentication using key sharing according to an aspect of the present disclosure. The operations of method 1000 may be implemented by an application server or a component thereof as described herein. For example, the operations of method 1000 may be performed by a security manager as described with reference to FIGS. 6-8. In some examples, the application server may execute a set of instructions for controlling the functional elements of the application server to perform the functions described below. Additionally or alternatively, the application server may use special purpose hardware to perform the aspects of the functions described below.

[0116] At 1005, the application server may receive an authentication request from the client at the server. The operation of 1005 may be performed according to the method described herein. In some examples, the manner of operation of 1005 may be performed by an authentication interface as described with reference to FIGS. 6-8.

[0117] At 1010, in response to receiving an authentication request, the application server may generate a short-lived asymmetric key pair on the server, and the client is associated with the client public key. The operation of 1010 may be performed according to the method described in this specification. In some examples, the manner of operation of 1010 may be performed by an asymmetric key component as described with reference to FIGS. 6-8.

[0118] At 1015, based on receiving an authentication request, the application server may generate a symmetric key using the short-lived private key of the short-lived asymmetric key pair and the client public key. The operation of 1015 may be performed according to the method described in this specification. In some examples, the manner of operation of 1015 may be performed by a symmetric key component as described with reference to FIGS. 6-8.

[0119] At 1020, the application server may encrypt a random challenge using the symmetric key. The operation of 1020 may be performed according to the method described in this specification. In some examples, the manner of operation of 1020 may be performed by an encryption component as described with reference to FIGS. 6-8.

[0120] At 1025, the application server may generate a partial key sharing result using the first part of the split private key, and the server has sent the second part of the split private key to the client, and the split private key is associated with the client public key. The operation of 1025 may be performed according to the method described in this specification. In some examples, the manner of operation of 1025 may be performed by a key sharing component as described with reference to FIGS. 6-8.

[0121] At 1030, the application server may send an encrypted random challenge and a partial key sharing result to the client, and the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result. The operation of 1030 may be performed according to the method described herein. In some examples, the manner of operation of 1030 may be performed by a random challenge component as described with reference to FIGS. 6-8.

[0122] At 1035, the application server may authenticate the client based on receiving an indication of successful decryption of the random challenge by the client. The operation of 1035 may be performed according to the method described herein. In some examples, the manner of operation of 1035 may be performed by an authentication component as described with reference to FIGS. 6-8.

[0123] At 1040, the application server may receive a request for authentication from the client at the server. The operation of 1040 may be performed according to the method described herein. In some examples, the manner of operation of 1040 may be performed by a provisioning component as described with reference to FIGS. 6-8.

[0124] At 1045, the application server may generate a first key pair including a client public key and a private key based on the request. The operation of 1045 may be performed according to the method described herein. In some examples, the manner of operation of 1045 may be performed by an asymmetric key component as described with reference to FIGS. 6-8.

[0125] At 1050, the application server may generate a split secret key including a first part of the split secret key and a second part of the split secret key based on a secret key. The operation of 1050 may be performed according to the method described herein. In some examples, the mode of operation of 1050 may be performed by a key splitting component as described with reference to FIGS. 6-8.

[0126] At 1055, the application server may send an instruction of the second part of the split secret key to the client, and the server is configured to receive an authentication request from the client based on sending the instruction of the second part of the split secret key to the client. The operation of 1055 may be performed according to the method described herein. In some examples, the mode of operation of 1055 may be performed by a key sending interface as described with reference to FIGS. 6-8.

[0127] At 1060, the application server may generate an encoded version of the second part of the split secret key. The operation of 1060 may be performed according to the method described herein. In some examples, the mode of operation of 1060 may be performed by a key encoding component as described with reference to FIGS. 6-8.

[0128] At 1065, the application server may cause a display of an encoded version of the first part of the split secret key on the user interface of the computing device. The operation of 1065 may be performed according to the method described herein. In some examples, the mode of operation of 1065 may be performed by a display component as described with reference to FIGS. 6-8.

[0129] A method for authenticating a client to a server is described. This method includes receiving, at the server, an authentication request from the client; in response to receiving the authentication request, generating, on the server, a short-lived asymmetric key pair, wherein the client generates, based on the client public key associated therewith and on receiving the authentication request, a short-lived private key of the short-lived asymmetric key pair and the client public key; encrypting a random challenge using a symmetric key; generating a partial key sharing result using a first part of a split secret key, wherein the server has sent a second part of the split secret key to the client and the split secret key is associated with the client public key; sending the encrypted random challenge and the partial key sharing result to the client, wherein the client is configured to derive, using the partial key sharing result, a symmetric key for decrypting the random challenge; and authenticating the client based on receiving an indication of successful decryption of the random challenge by the client.

[0130] An apparatus for authenticating a client to a server is described. The apparatus may include a processor, a memory coupled to the processor, and instructions stored in the memory. The instructions cause the apparatus to receive an authentication request from a client at the server, generate a short-lived asymmetric key pair on the server in response to receiving the authentication request, wherein the client is associated with the client public key, generate a short-lived private key of the short-lived asymmetric key pair and the client public key based on receiving the authentication request, encrypt a random challenge using a symmetric key, generate a partial key sharing result using a first part of a split secret key, wherein the server has sent a second part of the split secret key to the client and the split secret key is associated with the client public key, send the encrypted random challenge and the partial key sharing result to the client, wherein the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result, and authenticate the client based on receiving an indication of successful decryption of the random challenge by the client, and may be executable by the processor to cause the above to be performed.

[0131] Another apparatus for authenticating a client to a server is described. The apparatus includes receiving, at the server, an authentication request from the client; generating, in response to receiving the authentication request, a short-lived asymmetric key pair on the server, wherein the client is associated with the client public key; generating, based on receiving the authentication request, a short-lived private key of the short-lived asymmetric key pair and the client public key; encrypting a random challenge using a symmetric key; generating a partial key sharing result using a first part of a split secret key, wherein the server has sent a second part of the split secret key to the client and the split secret key is associated with the client public key; sending the encrypted random challenge and the partial key sharing result to the client, wherein the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result; and authenticating the client based on receiving an indication of successful decryption of the random challenge by the client.

[0132] A non-transitory computer-readable medium storing code for authenticating a client to a server is described. The code includes instructions that, at the server, receive an authentication request from the client and, in response to receiving the authentication request, generate a short-lived asymmetric key pair on the server, where the client is associated with the client public key, generate, based on receiving the authentication request, a short-lived private key of the short-lived asymmetric key pair and the client public key, encrypt a random challenge using a symmetric key, generate a partial key sharing result using a first part of a split secret key, where the server has sent a second part of the split secret key to the client and the split secret key is associated with the client public key, send the encrypted random challenge and the partial key sharing result to the client, where the client is configured to derive a symmetric key for decrypting the random challenge using the partial key sharing result, authenticate the client based on receiving an indication of successful decryption of the random challenge by the client, and may be executable by a processor to perform.

[0133] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may further include operations, features, means, or instructions for, at the server, receiving a request for authentication from the client, generating, based on the request, a first key pair including a client public key and a private key, generating, based on the private key, a split secret key including a first part of the split secret key and a second part of the split secret key, sending an indication of the second part of the split secret key to the client, where the server is configured to receive an authentication request from the client based on sending the indication of the second part of the split secret key to the client, and performing the sending.

[0134] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, transmitting an indication of a first portion of a split secret key may include operations, features, means, or instructions for generating an encoded version of a second portion of the split secret key and causing a display of the encoded version of the first portion of the split secret key on a user interface of a computing device.

[0135] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, generating an encoded version of a first portion of a split secret key may include operations, features, means, or instructions for generating a quick response (QR) code, where the QR code is to be displayed to a user on a user interface.

[0136] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, transmitting an indication of a first portion of a split secret key may include operations, features, means, or instructions for causing a first sub-portion of a second portion of the split secret key to be stored at a client and causing a display of a second sub-portion of the split secret key to be displayed by a user interface.

[0137] In some examples of the methods, apparatuses, and non-transitory computer-readable media described herein, operations, features, means, or instructions may be included for storing a first portion of a split secret key in association with a client public key.

[0138] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein further include operations, features, means, or instructions for generating an elliptic curve key pair as a short-lived asymmetric key pair including a short-lived private key and a short-lived public key based on receiving an authentication request, and generating a symmetric key using a server private key and a client public key, where a partial key sharing result is generated using a first part of a split private key and the short-lived public key, such that the client may be able to derive the symmetric key using a second part of the split private key and the server public key.

[0139] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein further include operations, features, means, or instructions for erasing a short-lived private key from memory in response to generating a symmetric key using the short-lived private key, where erasing results in the short-lived private key being a one-time use key.

[0140] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein further include operations, features, means, or instructions for generating a digital signature of an encrypted random challenge using a server signature private key, such that the client may be able to verify the encrypted random challenge using the server signature public key.

[0141] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein further include operations, features, means, or instructions for sending a blind challenge to a user device associated with a client in response to an authentication request, and verifying the user based at least in part on receiving an indication of the blind challenge.

[0142] Some examples of the methods, apparatuses, and non-transitory computer-readable media described herein may include operations, features, means, or instructions for generating symmetric keys and partial key sharing results using the Elliptic-Diffie-Hellman (ECDH) protocol.

[0143] The above-described methods describe possible implementations, and the operations and steps may be rearranged or modified in other ways, and it should be noted that other implementations are possible. Further, aspects from two or more of the methods may be combined.

[0144] In connection with the accompanying drawings, the descriptions set forth herein describe exemplary configurations and do not represent all examples that may be implemented or that are within the scope of the claims. The term "exemplary" as used herein means "serving as an example, instance, or illustration" and does not mean "preferred" or "advantageous over other examples." The detailed description includes specific details for providing an understanding of the described technology. However, these technologies may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form to avoid obscuring the concepts of the described examples.

[0145] In the accompanying drawings, similar components or features may have the same reference labels. Further, various components of the same type may be distinguished by tracking the reference labels with a second label that differentiates between dashes and similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label, regardless of the second reference label.

[0146] The information and signals described in this specification may be represented using any of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips that may be referenced throughout the above description may be represented by voltage, current, electromagnetic waves, magnetic fields or magnetic particles, optical fields or optical particles, or any combination thereof.

[0147] The various exemplary blocks and modules described in connection with the disclosure herein may be implemented or executed using a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gates or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices (e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration).

[0148] The functions described in this specification may be implemented in hardware, software executed by a processor, firmware, or any combination thereof. When implemented in software executed by a processor, the functions may be stored as one or more instructions or codes on a computer-readable medium or transmitted via the same. Other examples and implementations are within the scope of the present disclosure and the appended claims. For example, due to the nature of software, the functions described above may be implemented using software executed by a processor, hardware, firmware, hardwire, or any combination thereof. The features implementing the functions may be physically located at various positions, including being distributed such that portions of the functions are implemented at different physical locations. Also, as used herein, including when used in the claims, "or" as used in a list of items (e.g., a list of items preceded by phrases such as "at least one of", "one or more of", etc.) indicates an inclusive list such that, for example, a list of at least one of A, B, or C means A, B, or C, AB, AC, or BC, or ABC (i.e., A, B, and C). Also, as used herein, the phrase "based on" shall not be construed as a reference to a closed set of conditions. For example, an exemplary step described as "based on condition A" may be based on both condition A and condition B without departing from the scope of the present disclosure. In other words, as used herein, the phrase "based on" shall be construed in the same manner as the phrase "at least partially based on".

[0149] A computer-readable medium includes both a non-transitory computer storage medium and a communication medium including any medium that facilitates transfer of a computer program from one location to another. The non-transitory storage medium may be any available medium that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, the non-transitory computer-readable medium can be RAM, ROM, electrically erasable programmable read-only memory (EEPROM), compact disc (CD) ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to carry or store desired program code means in the form of instructions or data structures and that can be accessed by a general purpose or special purpose computer, or a general purpose or special purpose processor. Also, any connection is properly termed a computer-readable medium. For example, software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, and microwave, the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. As used herein, disk (disc) includes CD, laser disk, optical disk, digital versatile (DVD) disk, floppy disk, and Blu-ray (registered trademark) disk, disk typically magnetically reproduces data, and disc optically reproduces data with a laser. Combinations of the above are also included within the scope of computer-readable medium.

[0150] The description herein is provided to enable a person of ordinary skill in the art to make or use the present disclosure. Various modifications to the present disclosure will be readily apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other variations without departing from the scope of the present disclosure. Thus, the present disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for authenticating a client to a server, comprising: at the server, receiving an authentication request from the client; in response to receiving the authentication request, generating a short-lived asymmetric key pair on the server; generating a partial key sharing result using a first part of a split secret key and the short-lived public key of the short-lived asymmetric key pair, wherein the split secret key is associated with a client public key; transmitting to the client an encrypted random challenge and the partial key sharing result, at least partially based on receiving the authentication request, wherein the partial key sharing result is based on the first part of the split secret key, the encrypted random challenge is encrypted at least partially based on the short-lived asymmetric key pair, the server has transmitted a second part of the split secret key to the client, and the client is configured to derive a symmetric key for decrypting the encrypted random challenge using the partial key sharing result; authenticating the client at least partially based on receiving an indication of successful decryption of the encrypted random challenge by the client.

2. generating a symmetric key using the short-lived secret key of the short-lived asymmetric key pair and a client public key, at least partially based on receiving the authentication request; further comprising encrypting a random challenge using the symmetric key to generate the encrypted random challenge, according to the method of Claim 1.

3. further comprising erasing the short-lived secret key from memory in response to generating the symmetric key using the short-lived secret key, wherein the erasing results in the short-lived secret key being a one-time use key, according to the method of Claim 2.

4. at the server, receiving a request for authentication from the client; generating a first key pair including a client public key and a secret key, at least partially based on the request; generating a split secret key including a first part of the split secret key and a second part of the split secret key, at least partially based on the secret key. Transmitting an indication of the second portion of the split secret key to the client, wherein the server is configured to receive the authentication request from the client at least partially based on transmitting the indication of the second portion of the split secret key to the client, and the method according to claim 1 further comprising transmitting.

5. Transmitting the indication of the first portion of the split secret key comprises generating an encoded version of the second portion of the split secret key, and causing a display of the encoded version of the first portion of the split secret key on a user interface of a computing device, the method according to claim 4.

6. Generating the encoded version of the first portion of the split secret key comprises generating a Quick Response (QR) code, the QR code (registered trademark) being displayed to the user on the user interface, the method according to claim 5.

7. Transmitting the indication of the first portion of the split secret key comprises causing the first sub-portion of the second portion of the split secret key to be stored at the client, and causing a display of the second sub-portion of the split secret key to be displayed by a user interface associated with the client, the method according to claim 4.

8. The method according to claim 4 further comprising storing the first portion of the split secret key in association with the client public key.

9. An apparatus for authenticating a client to a server, comprising means, at the server, for receiving an authentication request from the client, and means, responsive to receiving the authentication request, for generating a short-lived asymmetric key pair on the server, and means for generating a partial key sharing result using the first portion of the split secret key and the short-lived public key of the short-lived asymmetric key pair, the split secret key being associated with the client public key. Means for transmitting an encrypted random challenge and the partial key sharing result to the client, at least partially based on receiving the authentication request, wherein the partial key sharing result is based on the first part of the split secret key, the encrypted random challenge is encrypted at least partially based on the short-lived asymmetric key pair, the server has transmitted the second part of the split secret key to the client, and the client is configured to derive a symmetric key for decrypting the encrypted random challenge using the partial key sharing result, and means for transmitting; Means for authenticating the client, at least partially based on receiving an indication of successful decryption of the encrypted random challenge by the client, and an apparatus comprising the same. **Claim 10** Means for generating a symmetric key using the short-lived private key of the short-lived asymmetric key pair and the client public key, at least partially based on receiving the authentication request; The apparatus according to claim 9, further comprising means for encrypting a random challenge using the symmetric key to generate the encrypted random challenge. **Claim 11** Means for erasing the short-lived private key from memory in response to generating the symmetric key using the short-lived private key, wherein the erasing results in the short-lived private key being a one-time use key, and the apparatus according to claim 10 further comprising means for erasing. **Claim 12** A non-transitory computer-readable medium storing code for authenticating a client to a server, the code comprising instructions, the instructions receiving, at the server, an authentication request from the client; in response to receiving the authentication request, generating, on the server, a short-lived asymmetric key pair; generating a partial key sharing result using the first part of the split secret key and the short-lived public key of the short-lived asymmetric key pair, wherein the split secret key is associated with the client public key; Transmitting an encrypted random challenge and the partial key sharing result to the client, at least partially based on receiving the authentication request, wherein the partial key sharing result is based on the first part of the split secret key, the encrypted random challenge is encrypted at least partially based on the short-lived asymmetric key pair, the server has transmitted a second part of the split secret key to the client, and the client is configured to derive a symmetric key for decrypting the encrypted random challenge using the partial key sharing result; Authenticating the client at least partially based on receiving an indication of successful decryption of the encrypted random challenge by the client; a non-transitory computer-readable medium executable by a processor to perform. **Claim 13** The instructions are further executable by the processor to generate a symmetric key using the short-lived private key of the short-lived asymmetric key pair and the client public key, at least partially based on receiving the authentication request; Encrypting a random challenge using the symmetric key to generate the encrypted random challenge; the non-transitory computer-readable medium according to claim 12, further executable by the processor to perform. **Claim 14** The instructions are further executable by the processor to erase the short-lived private key from memory in response to generating the symmetric key using the short-lived private key, the erasing resulting in the short-lived private key being a one-time use key; the non-transitory computer-readable medium according to claim 13, further executable by the processor to perform.

Images