HK1233804B - Persistent authentication system incorporating one time pass codes - Google Patents

Description

Persistent authentication system with one-time passcodes

Inventor: Ric Richardson

Technical Field

The present invention relates to a persistent authentication system incorporating a one-time passcode, and more particularly, but not exclusively, such a system does not require a user of the system to enter and re-enter a username and corresponding password for user sessions initiated by the user.

Background Art

The use of usernames and passwords is well known in the art. There is a growing problem in that storing passwords on the server side is becoming more vulnerable to attack, and the burden on users to use different and secure passwords on multiple websites creates inconvenience, overcomplication, and ongoing security risks.

Attempts to address this issue include device hardware fingerprinting or other multi-factor authentication methods such as biometrics. These are used to attempt to improve security and reduce exposure to issues associated with standard username and password authentication systems. However, they often simply add more complexity and inconvenience to an already burdensome process.

An example of such an attempt is IBM's US 5875296, the contents of which are incorporated herein by cross-reference. Its solution is outlined in its claim 1 as:

A method of authenticating a client to a web server connectable to a distributed file system of a distributed computing environment, the distributed computing environment including a security service for returning credentials to a user authenticated to access the distributed file system, the method comprising the steps of:

In response to the web server receiving the user ID and password from the client, executing a login protocol for the secure service and storing the resulting credentials;

returning a persistent client state object with the identifier therein to the client; and

The client is caused to use the persistent client state object including the identifier instead of a user id and password to gain subsequent access to Web documents in the distributed file system.

This arrangement can be interpreted as utilizing a "cookie" as a persistent client state object. This arrangement presents significant security issues.

Other prior art examples (all of which are incorporated by cross-reference) include:

US8447977Canon KK, its main claims are as follows:

A method for authenticating a device to a server via a network, the method comprising the following steps:

Establishing, by the device, a secure connection with the server;

transmitting, by the device, identification information of the device to the server, wherein the identification information uniquely identifies the device to the server and is pre-stored in the device;

determining, by the server, the trustworthiness of the device using the identification information transmitted by the device; and

When the server determines that the device is authentic:

creating, by the server, a first authentication token for the device, the first authentication token indicating that the device is authentic;

storing, by the server, the first authentication token;

transmitting, by the server, the first authentication token to the device using the secure connection; and

storing, by the device, the first authentication token;

The method further comprises the following steps:

establishing, by the device, a secure reconnection with the server; and

The device is authenticated by the server over the secure reconnection using the first authentication token stored by the device.

US6668322 Sun MicroSystems, its main claims are as follows:

A session credential for use in a security architecture for controlling access to one or more information resources, the session credential comprising:

A subject identifier that uniquely identifies the subject; and

the encoding of the authorization granted by the security architecture after pre-authentication of the login credentials corresponding to the principal,

The principal identifier and authorization code are cryptographically protected and allow the security framework to evaluate the sufficiency of the authorization to access the one or more information resources without requiring reauthentication of the login credentials.

US6421768 First Data, its main claims are as follows:

A method for transferable authentication, by which a user accessing a first computer can be authenticated to a second computer remote from the first computer without requiring the user to explicitly identify themselves to the second computer, the method comprising the steps of:

accessing the first computer at a user's computer;

authenticating the user to the first computer;

receiving, from the first computer, a cookie including a digital credential that includes characteristics of a user of the first computer, the credential being cryptographically secured by the first computer, the user characteristics being encrypted by the first computer using a client public key that is secret from the first computer and the second computer but unknown to the user, and incorporating the encrypted credential into the digital credential, the client public key being cryptographically secured using an asymmetric key of at least one of the first computer and the second computer;

Sending the cryptographically guaranteed client public key to the second computer via the user's computer; and

sending at least a portion of the cookie including the credentials to the second computer, the second computer being configured to:

authenticating the credentials without requiring the user to explicitly identify themselves to the second computer;

extracting the user characteristics from the credentials; and

An action is performed based on the user characteristics.

As mentioned above, cookies currently have certain security issues and ongoing adoption problems.

The following is also disclosed that discloses alternative ways to seek security systems without using repeated password entry and explicit communication of passwords from one machine to another. These systems may be more complex and include the use of third-party machines to perform verification/authentication.

US4578531AT&T

US6134592 Netscape

US6205480Computer Assoc

US7523490Microsoft

US20110320820IBM

US20130219472A1QSAN

Embodiments of the present invention are designed to address these problems.

Notes

The term "comprise" (and its grammatical variations) is used in this specification in the inclusive sense of "having" or "including", rather than in the exclusive sense of "consisting only of".

The above discussion of the prior art in the context of the invention is not an admission that any of the information discussed herein is part of the common general knowledge of a person skilled in the art in any country or is citable prior art.

Summary of the Invention

In summary, the concepts outlined in embodiments of the present invention are based on relying on two pieces of information for a persistent authentication process and corresponding systems and devices:

In a preferred detailed form, for each session, a new key pair is generated by the client and passed to the server. Communication for subsequent sessions is enabled only when there is a match between the public key stored on the server and the public key on the client that matches the user (user ID).

In summary, stated another way, according to a preferred embodiment, when using a client-side application that is talking to a server, an unbroken chain of one-time passcodes is used to represent the user. In a specific form, the one-time passcode is actually the public key of a client-generated key pair. In another specific preferred form, an aspect regarding updates is implemented wherein the one-time passcode is kept updated at regular intervals (in a preferred form, preferably at least once per connection session).

Thus, in one broad form of the invention, there is provided a method of maintaining ongoing authentication of a user of an application without requiring entry and re-entry of a username and corresponding password for each session initiated between a client-side application residing on a client-side platform and a server; and wherein the password is not stored on the server; the method comprising: utilizing an unbroken chain of one-time passcodes; each passcode in the chain being unique to the username and client-side application; each passcode being updated periodically, and preferably updated at least once during each said session.

Preferably, the passcode comprises a client-side public key that remains persistent on both the client-side platform and the server until replaced by the next client-side public key in the passcode chain.

Preferably, the client-side public key comprises a public key of a PKI key pair.

Preferably, the corresponding client-side private key is not shared with the server.

In another broad form of the present invention, a device is disclosed comprising a processor in communication with a memory adapted to execute an application; the device maintains ongoing authentication of a user of an application capable of executing on the device without requiring entry and re-entry of a username and corresponding password for each session initiated between a client-side application on a client-side platform residing on the device and a remote server; and wherein the password is not stored on the server; the method comprising: utilizing an unbroken chain of one-time pass codes; each pass code in the chain being unique to the username and the client-side application; and each pass code being updated at least once during each of said sessions.

Preferably, the passcode comprises a client-side public key that remains persistent on both the client-side platform and the server until replaced by the next client-side public key in the passcode chain.

Preferably, the client-side public key comprises a public key of a PKI key pair.

Preferably, the corresponding client-side private key is not shared with the server.

In another broad form of the present invention, there is provided a system comprising a device having a processor in communication with a memory adapted to execute an application; the device maintaining persistent authentication of a user of an application executable on the device without requiring entry and re-entry of a username and corresponding password for each session initiated between a client-side application residing on a client-side platform on the device and a remote server, the system deriving first and second data; the first data comprising:

"Something you have", which in the preferred form is the client-side public key.

The second item of data includes "things you know".

Preferably, the second item of data comprises a user PIN/password used to create a private key for any given session.

Preferably, the second item of data comprises any form of personally identifiable information including, but not limited to, a thumbprint or other biometric characteristic used to create a private key for any given session.

Preferably, for each session, a new key pair is generated by the client and passed to the server, and communication for subsequent sessions is enabled only if there is a match between the public key stored at the server and the public key on the client matching the user (user ID).

In yet another broad form of the present invention, there is provided a platform comprising at least one processor in communication with a memory, the processor executing code to perform a method of authenticating a user; the method comprising: characterizing the user using an unbroken chain of one-time passcodes when using a client-side application executing on the platform that communicates with a remote server over the Internet.

Preferably, the one-time passcode is a public key of a client-generated key pair.

In yet another broad form of the present invention, there is provided a system for maintaining ongoing authentication of users of an application without requiring entry and re-entry of a username and corresponding password for each session initiated between a client-side application residing on a client-side platform and a server, the system utilizing a renewable one-time passcode string, and wherein renewal is achieved by replacing the passcode at regular intervals.

In a preferred form, the interval comprises an interval that occurs once per session connection.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 shows the main components of an example embodiment.

FIG. 2 is a control process for initial use of an example embodiment.

FIG3 is a control process for non-initial use according to an example embodiment.

FIG4 is a block diagram of a method for constructing a private key according to another embodiment.

DETAILED DESCRIPTION

In summary, the present invention is based on the concept of relying on two pieces of information for initial authentication and then for ongoing authentication;

In a preferred detailed form, for each session, a new public key is generated by the client and passed to the server. Only when there is a match between the public key stored on the server and the public key on the client that matches the user (user ID) will communication for subsequent sessions be enabled.

In summary, in another embodiment, when using a client-side application that is communicating with a server, an unbroken chain of one-time passcodes is used to represent the user. In a specific form, the one-time passcode is actually a public key. In another specific preferred form, an aspect regarding updates is implemented in which the one-time passcode is kept updated at regular intervals (at least once per session).

Example embodiments are disclosed that use an unbroken chain of one-time passcodes to replace passwords in traditional username and password authentication systems.

The key components of an example embodiment are shown in Figure 1. When a user connects to a server using a unique user ID 23, an encryption and authentication system such as a public key cryptographic exchange is typically used.

Typically, a user has a client-side application 24 that generates a key pair 10 for communicating with a server, where the server uses its own key pair 11. In the known practice of public-key cryptography, the client's private key 12 is used with the server's 14 public key to encrypt messages, and the server uses the client's public key 13 and the server's private key 15 to decrypt sent messages.

Once the identities of the sender 10 and the receiver 11 are verified, both parties share a secret password 17 , which is used for high-speed encryption and decryption of the encrypted message 16 .

Typically, the encrypted message 16 uses a secret password 17 that is used only for the length of the communication session, after which the password 17 is discarded and never used again.

In an example embodiment, the key exchange and encryption process described above is extended to include a second set of key pairs generated by the client 18. This key pair generation 18 is used to uniquely link the current authenticated session with the next authentication system between the client and server.

This key pair 18 comprises a private key 20 stored locally on the client device and a public key 19, also stored locally. The stored client public key is also shared with and transmitted to the server 25, which then links a stored reference to the unique user ID 21 of the person currently using the client with a stored copy of the client's public key 22.

During subsequent connections between the client and server, the stored and shared client public key 19, 22, the server's public key 14 and the private key 20 stored on the client are used as the current client-side public key pair, and additional key pairs are then generated and stored for subsequent sessions.

Figure 2 discloses the control process of an initial session of an example embodiment.A user interacts with a server 31 using an application on the client side 30 of the communication.

Initially, the user connects to the server (32) using a unique ID using a persistent one-time key. Initially, the server and client use a traditional public key encryption session (33) to secure communications between the client 30 and the server 31.

Next, it is confirmed that the user wants to use a persistent, one-time code (34), and the user's unique ID is captured or retrieved from the user or from storage on the client and sent to the server (35). The server then requests the client to generate a public key pair for use in the next session (36). The client then generates a public key pair (37), which is securely stored on the client for use in the next session (38), and shares the public key of the key pair with the server (39).

The client public key for the next session is stored on the server using the user's unique ID (40). Once this step is confirmed, the existing SSL, TLS or similar connection is used to ensure ongoing communication between the client and server until the session is terminated or times out (41).

Figure 3 discloses the control process of a non-initial session of an example embodiment.A user interacts with a server 61 using an application on the client side 60 of the communication.

Initially, the user connects to the server (62) using a persistent one-time key using a unique ID. Initially, the server and client use a traditional public key encryption session (63) to secure communications between the client 60 and the server 61.

Next, the unique ID is captured or retrieved from storage on the user or client (64). Next, the unique user ID of the current user is used to retrieve the stored client key pair stored during the previous session (65). The user unique ID and the previously stored client public key are then shared with the server (66).

The server then searches its own user database for the user's unique ID and retrieves the previously saved client public key (67) for comparison with the shared client public key from the client (68). If the two keys do not match, the server notifies the user and suggests various measures to resolve the issue (70). If a match does occur (69), the server requests (71) the client to generate a second public key pair (72) and then stores the key pair (73). Additionally, the public key of the key pair just generated (72) is shared with the server for use in the next session (74). The server then stores the next client public key to be used with the user's unique ID (75), and the current key pair of both the client and the server is used for ongoing communications between the client and the server until the session terminates or times out (76).

As a result, a persistent chain of one-time codes in the form of the client's public key can be used to establish and continue a secure connection between the client system and the server system across multiple ongoing sessions.

Alternative Embodiments

An example embodiment uses the generation and chaining of a series of client-side public keys stored on both the client side and the server side as a persistent identifier for authentication purposes. An alternative embodiment may use a TLS session key chain such as a shared AES passphrase as a persistent identifier. In this case, each time a shared client-side public key is used, a follow-up key is generated and stored on both sides for use in the next session. The advantage of using the client-side public key as a persistent identifier is that, unlike the case of TLS session keys, the client-side private key is not shared with the server, thereby increasing the security level of the system.

In an exemplary embodiment, the client is used to generate a key pair for use in processing. In an alternative embodiment, a server can be used to generate a key pair and share it with the client for use in subsequent sessions.

The example embodiment shares the server-stored copy of the next client public key with the shared copy of the client public key from the client during the current session. Alternative embodiments may use any equivalent of the client public key for comparison purposes, including but not limited to a checksum or hash of the client public key.

Other embodiments

4 and in a particularly preferred form, according to another embodiment, an embodiment of the present invention relies on two pieces of information according to a method of constructing a private key.

"Something you have", which in the preferred form is the client-side public key.

"Something you know," which in the preferred form is the user's PIN/password used to create the private key for any given session.

In a further enhancement of the example embodiment, the private key of the client key pair can be linked to a specific user of the client device to implement two-factor authentication. This is achieved by requiring the user to enter a PIN or other "something the user must know" and "something the user must have" (in this case, the required private key of a valid client key pair) in two-factor authentication using the example embodiment.

In this enhancement, the private key 100 of the client key pair 101 is split into two parts 102, 103. The first part is a PIN 102, which is selected by the user to verify their identity in future sessions. This PIN 102 is subtracted from the full private key 100 to produce a differential key element 103. Unless the user adds the correct PIN 102 to the correct differential key element 103 to produce a usable private key 100 of a usable key pair 101, the differential key element 103 cannot be used as a successful private key 100 in the client key pair 101.

The differential key element may be securely stored 104 on the client device for use in the next session, as the element 104 cannot be successfully used without the required PIN 102 .

In practice, the PIN 102 will be requested from the user at the start of each session and then added to the differential key element 103 to establish successful public key data encryption and decryption.

Additionally, the PIN 102 will be temporarily stored on the client and then used to generate a suitable differential key element 103 for the next session private key 20 .

The example embodiment shows the use of a PIN as the "thing the user must know" in order to implement two-factor authentication. Alternative embodiments may use any form of personally identifiable information, including but not limited to a thumbprint or other biometric feature.

The example embodiment generates the differential key element using subtraction by subtracting the PIN from the private key of the client-side key pair.Alternative embodiments may use any calculation that allows combining a personally identifiable factor with a second file element to generate a usable private key in the client-side key pair.

The foregoing describes only some embodiments of the present invention, and modifications apparent to those skilled in the art may be made without departing from the scope and spirit of the invention.

Industrial Applicability

Embodiments of the present invention may be applied in situations where authentication of a device or a device plus user combination needs to be verified before further communication with the device.

Claims (24)

1. A method for maintaining continuous authentication between a user and a server in a client-side application residing on a client-side platform, the method comprising the following steps: Step a: The client-side platform connects to the server that uses a persistent one-time passcode; Step b: The client-side platform and the server establish the current secure session using SSL or TLS; Step c: The client-side platform retrieves the current key pair generated in the previous session and the unique user ID associated with the user; Step d: The client-side platform provides the server with the unique user ID and the current client public key of the current key pair; Step e: The server retrieves the previously stored client public key by searching the user database using the unique user ID; Step f: The server compares the previously stored client public key retrieved with the current client public key provided from the client-side platform, wherein for the current secure session, authentication is enabled between the client-side platform and the server when the retrieved previously stored client public key matches the current client public key; Step g: The server requests the client-side platform or the server to generate the next key pair; Step h: The next key pair is generated by the client-side platform or server for use in the next session, wherein the corresponding client-side private key is not stored on the server; Step i: Share the next client public key of the next key pair between the client-side platform and the server for use in the next session; Step j: The server stores the next client public key in association with the unique user ID in the user database; Step k: Maintain in-process communication between the client and the server using the current key pair and the server key pair until the current secure session terminates or times out; Step 1: The client-side platform replaces the current key pair with the next key pair; and Steps a through l are repeated for each subsequent session to perpetuate the secure connection between the client-side platform and the server across multiple ongoing sessions, without requiring the user to enter and re-enter the username and corresponding password for each session. This generates and persistently maintains an uninterrupted chain of the current client public key until it is replaced by the next client public key. 2. The method according to claim 1, wherein the next key pair is generated on the client-side platform. 3. The method according to claim 2, wherein the client-side public key includes the public key of the PKI key pair. 4. The method according to claim 2, further comprising: The client-side platform requires the user to input the first and second pieces of data. The first data item includes "what you own," which is the client-side public key, and The second item of data includes “things you know,” which is the user PIN or password used to create a private key for any given session. 5. The method of claim 4, wherein the second data includes any form of personally identifiable information, including: thumbprints or other biometric data used to create a private key for any given session. 6. The method according to claim 4, further comprising: For each session, the client-side platform generates a new key pair and transmits the new key pair to the server. Communication for subsequent sessions is only enabled if there is a match between the server-side public key and the client-side public key that matches the user. 7. The method according to any one of claims 1 to 6, wherein the password is not stored on the server. 8. The method of claim 1, wherein the next key pair is generated on a server. 9. The method of claim 8, wherein the client-side public key is matched with the user by referring to the private key of the PKI key pair of the client-side public key; and wherein the client-side key includes the public key of the PKI key pair. 10. The method of claim 8, further comprising: The client-side platform requires the user to input the first and second pieces of data. The first data item includes "what you own," which is the client-side public key, and The second item of data includes “things you know,” which is the user PIN or password used to create a private key for any given session. 11. The method of claim 10, wherein the second data includes any form of personally identifiable information, including: thumbprint or other biometric data used to create a private key for any given session. 12. The method of claim 10, further comprising: For each session, the client-side platform generates a new key pair and transmits the new key pair to the server. Communication for subsequent sessions is only enabled if there is a match between the server-side public key and the client-side public key that matches the user. 13. A system for maintaining continuous authentication between a user and a server for a client-side application residing on a client-side platform, wherein the client-side platform has a processor and memory, the system being configured to perform the following steps: Step a: The client-side platform connects to the server that uses a persistent one-time passcode; Step b: The client-side platform and the server establish the current secure session using SSL or TLS; Step c: The client-side platform retrieves the current key pair generated in the previous session and the unique user ID associated with the user; Step d: The client-side platform provides the server with the unique user ID and the current client public key of the current key pair; Step e: The server retrieves the previously stored client public key by searching the user database using the unique user ID; Step f: The server compares the previously stored client public key retrieved with the current client public key provided from the client-side platform, wherein for the current secure session, authentication is enabled between the client-side platform and the server when the retrieved previously stored client public key matches the current client public key; Step g: The server requests the client-side platform or the server to generate the next key pair; Step h: The next key pair is generated by the client-side platform or server for use in the next session, wherein the corresponding client-side private key is not stored on the server; Step i: Share the next client public key of the next key pair between the client-side platform and the server for use in the next session; Step j: The server stores the next client public key in association with the unique user ID in the user database; Step k: Maintain in-process communication between the client and the server using the current key pair and the server key pair until the current secure session terminates or times out; Step 1: The client-side platform replaces the current key pair with the next key pair; and Steps a through l are repeated for each subsequent session to perpetuate the secure connection between the client-side platform and the server across multiple ongoing sessions, without requiring the user to enter and re-enter the username and corresponding password for each session. This generates and persistently maintains an uninterrupted chain of the current client public key until it is replaced by the next client public key. 14. The system of claim 13, wherein the next key pair is generated on the client-side platform. 15. The system of claim 14, wherein the client-side public key includes the public key of the PKI key pair. 16. The system of claim 13, wherein the system is further configured to perform the following steps: The client-side platform requires the user to input the first and second pieces of data. The first data item includes "what you own," which is the client-side public key, and The second item of data includes “things you know,” which is the user PIN or password used to create a private key for any given session. 17. The system of claim 16, wherein the second data includes any form of personally identifiable information, including: thumbprint or other biometric data used to create a private key for any given session. 18. The system of claim 16, wherein the system is further configured to perform the following steps: For each session, the client-side platform generates a new key pair and transmits the new key pair to the server. Communication for subsequent sessions is only enabled if there is a match between the server-side public key and the client-side public key that matches the user. 19. The system according to any one of claims 13 to 18, wherein the password is not stored on the server. 20. The system of claim 13, wherein the next key pair is generated on a server. 21. The system of claim 20, wherein the client-side public key is matched with the user by referring to the private key of the PKI key pair of the client-side public key; and wherein the client-side key includes the public key of the PKI key pair. 22. The system of claim 20, wherein the system is further configured to perform the following steps: The client-side platform requires the user to input the first and second pieces of data. The first data item includes "what you own," which is the client-side public key, and The second item of data includes “things you know,” which is the user PIN or password used to create a private key for any given session. 23. The system of claim 22, wherein the second data includes any form of personally identifiable information, including: thumbprints or other biometric data used to create a private key for any given session. 24. The system of claim 22, wherein the system is further configured to perform the following steps: For each session, the client-side platform generates a new key pair and transmits the new key pair to the server. Communication for subsequent sessions is only enabled if there is a match between the server-side public key and the client-side public key that matches the user.