Claims:
1. A method for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography comprising the steps of :
Requesting by the Client app CA to Identity server IdP for the issuance of access token for accessing server app SA;
Generating by the Client app CA random secret share [k] and [k1] then providing to IdP server;
Completing and validating of user credentials, IdP server issues CA an access token T wherein the payload of the token T now consists of two additional inputs [k] & [k1];
Embedding by the IdP server said [k] & [k1] into the token payload before cryptographically signing either with HS256 or RS256 signature schema; and
Sending by the client app CA the token T to service app SA and in order to validate the presented token by service app SA initiates a cryptographic challenge-response schema with the client app CA.

2. The method for securing stateless access tokens as claimed in claim 1, wherein the Client application CA generates a random secret [k] and then splits [k] into two secret shares [k1] and [k2] using the non-linear secret sharing (NLSS) image cryptography and the said token is preferably Jason Web tokens (JWT).
3. The method for securing stateless access tokens as claimed in claim 1, wherein said Client application CA then transmits [k] & [k1] to IdP server and keeps [k] & [k2] securely itself.
4. The method for securing stateless access tokens as claimed in claim 1, wherein said token T served by IgP server has one secret share [k1] while the other secret share [k2] is stored with the client application CA.
5. The method for securing stateless access tokens as claimed in claim 1, wherein the said challenge-response schema involve the steps of:
Step 1: parsing by SA the token T to extract [k] & [k1] wherein the said token [k] is typically an image;
Step 2: Upon receiving the challenge, CA returns the correct values of the coordinates back to SA;
Step 3: merging by the SA the response values from CA with the corresponding values of the corresponding coordinates of [k1] and an exact match revalidates the credentials of the token T.

6. The method for securing stateless access tokens as claimed in claim 5, wherein said image includes 1024*256 and the splitting with NLSS cryptography, [k1] & [k2] expands pixels by 8 times i.e. 8,192*256 pixels.
7. The method for securing stateless access tokens as claimed in claim 1, wherein during challenge response the said service app, SA picks a random set of 64 coordinates from the 262,144 pixels of [k] in the matrix and sends the challenge to CA seeking the corresponding 8*64=512 values from [k2].

8. The method for securing stateless access tokens as claimed in claim 7, wherein the result of the merger of the 512 values of [k1] & [k2] is being compared with the values of the corresponding 64 coordinates of the original challenge initiated.
9. The method for securing stateless access tokens as claimed in claim 1, wherein the said Apps are configured to provide peer-to-peer authentication without needing to contact a third party server
10. The method for securing stateless access tokens as claimed in claim 1, wherein both the CA and SA do not merge the full secret shares [k1] & [k2] to revalidate the token T, but only transmit a small portion of the secrets using the challenge-response method to validate the token.
11. A system for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography: a hardware based True Random number Generator (TRNG) generating keys; a client app CA, a Idp Server, a plurality of server app SA and a non-transitory computer-readable medium comprising instructions stored thereon, that when executed on a processor, perform the steps of:
Requesting by the Client app CA to Identity server IdP for the issuance of access token for accessing server app SA;
Generating by the Client app CA random secret share [k] and [k1] then providing to IdP server;
Completing and validating of user credentials, IdP server issues CA an access token T wherein the payload of the token T now consists of two additional inputs [k] & [k1];
Embedding by the IdP server said [k] & [k1] into the token payload before cryptographically signing either with HS256 or RS256 signature schema; and
Sending by the client app CA the token T to service app SA and in order to validate the presented token by service app SA initiates a cryptographic challenge-response schema with the client app CA.
12. The system for securing stateless access tokens as claimed in claim 11, wherein the Client application CA generates a random secret [k] and then splits [k] into two secret shares [k1] and [k2] using the non-linear secret sharing (NLSS) image cryptography.
13. The system for securing stateless access tokens as claimed in claim 11, wherein said Client application CA then transmits [k] & [k1] to IdP server and keeps [k] & [k2] securely itself.
14. The system for securing stateless access tokens as claimed in claim 1, wherein said token T served by IgP server has one secret share [k1] while the other secret share [k2] is stored with the client application CA.
15. The system for securing stateless access tokens as claimed in claim 1, wherein both the CA and SA do not merge the full secret shares [k1] & [k2] to revalidate the token T, but only transmit a small portion of the secrets using the challenge-response in order to validate the token.
, Description:FIELD OF INVENTION

The present invention relates to a method for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography and a system thereof. More particularly, the present invention discloses a solution using cryptographic secret share tags that protect against the loss/theft of stateless access tokens. The invention also relates to a method of securing user authentication to web applications & servers using secure identity tags using non-linear secret sharing cryptography and a system thereof.

BACKGROUND ART

Stateless access tokens such as JWT (Jason Web tokens) wherein, a server could generate a token that has the claim "logged in as admin" and provide that to a client. The client could then use that token to prove that it is logged in as admin. The tokens are signed by one party's private key (usually the server's), so that both parties (the other already being, by some suitable and trustworthy means, in possession of the corresponding public key) are able to verify that the token is legitimate. The said tokens are often used in various applications such as (a) federated or single sign on solutions (b) authentication & authorization of claims between applications, containers & microservices in a distributed cloud environment. Stateless access tokens translate stateful authenticated claims by authentication servers into stateless signed claims that can be used by one app node to access another app node without needing to check back with the primary authentication server every time a peer is trying to access another peer.

Stateless access tokens typically are JSON documents containing the following information:

User ID (ID of the user/application requesting the access token)
Payload of the access token
The cryptographic signature schema used to sign the document
The JSON document is cryptographically signed by either of the following cryptographic algorithms:
HS256 (HMAC method using SHA256 algorithm with symmetric encryption keys)
RS256 (RSA ECDSA)

The following depiction describes a typical scenario in which a stateless JWT token is used to authenticate & authorize.

The client app CA successfully validates identity & access rights with the identity server IdP.
IdP generates a JWT token T and cryptographically signs it.
IdP sends the JWT token T to the client app CA.
Whenever CA wants to access the service app SA, CA offers the token T to SA. SA checks that the token T is properly formed and also cryptographically validates the token. If HS256 is used, SA will use the shared symmetric key to validate the contents of the token T. If RS256 is used, SA validates the contents of the token with the public key.
After validation, SA grants access to CA.

Problems with stateless tokens

Stateless tokens can be lost or stolen. The Stateless tokens are bearer tokens and whichever app or service possesses it, it can gain access and validate claims. For example, is the token T is lost in transit or stolen from CA, let us say by CB, CB can then present the token to SA & receive the access as per the token T. Since T is a bearer token, there is no second line of defense against such attacks. To minimize the risks from tokens being lost or stolen, stateless tokens are usually issued for very short durations, less than 5 minutes in most cases. Short duration tokens minimize risks, but take away the flexibility offered by long duration tokens – many applications may need access for longer periods.

To translate long duration requests into multiple short duration access tokens, multiple additional hops to the identity server or api gateways may be needed. This creates significant inefficiencies & high latencies, especially for a multi-cloud, distributed micro services environment. Some architecture creates intermediate servers like api gateways to translate long-term access requests (usually called refresh tokens) into short term stateless access tokens. Intermediate servers reduce the statelessness of the access tokens and increase latencies.

Problems with existing user authentication methods There are various existing user authentication methods that help web servers & applications authenticate users seeking access. Hardware based authentication methods such as FIDO2 & biometric based tokens offer a secure way of completing user authentication. However, software based legacy authentication solutions based on passwords & one-time passwords (OTP) delivered by SMS are subject to various security compromises.
Passwords & other similar user credentials are typically stored in the Web server for authentication. As users could reuse the passwords across different servers, a breach of one server would expose all other servers where the user uses the same password (this attack is called password stuffing). Similarly, phishing attacks could steal user passwords. Passwords are also expensive to manage given the security needed for servers.
While there are some software passwordless authentication solutions such as mobile authenticators based on FIDO keys, they are insecure because the private key stored on the mobile app could be stolen.
Existing software authentication solutions also do not offer mutual authentication. Mutual authentication means both User & Server authenticate each other. While existing solutions let Server authenticate User successfully, User is not necessarily sure of connecting to the correct Server. Lack of mutual authentication could result in successful spoofing attacks.

OBJECT OF INVENTION
The principle object of the present invention is to disclose a method for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography and a system configured for using cryptographic secret share tags that protect against the loss/theft of stateless access tokens.

Another object of the present invention is to disclose a method of securing user authentication to web applications & servers using secure identity tags using non-linear secret sharing cryptography and a system configured to execute the said method.

Another object of the present invention is to provide stateless bearer tokens which are immune against any loss and irrespective of whichever app or service possesses it, it can gain access and validate claims.

Another object of the present invention is to minimize the risks from tokens being lost or stolen, stateless tokens are usually issued for very short durations.

Another object of the present invention is to provide mutual authentication means wherein both User & Server authenticate each other. The lack of mutual authentication could result in successful spoofing attacks.

SUMMARY OF INVENTION

Therefore such as herein described there is provided a method for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography comprising the steps of requesting by the Client app CA to Identity server IdP for the issuance of access token for accessing server app SA; generating by the Client app CA random secret share [k] and [k1] then providing to IdP server; completing and validating of user credentials, IdP server issues CA an access token T wherein the payload of the token T now consists of two additional inputs [k] & [k1]; embedding by the IdP server said [k] & [k1] into the token payload before cryptographically signing either with HS256 or RS256 signature schema; and sending by the client app CA the token T to service app SA and in order to validate the presented token by service app SA initiates a cryptographic challenge-response schema with the client app CA.

In an embodiment there is also disclosed a system for securing stateless access tokens using secure identity tags using non-linear secret sharing cryptography: a hardware based True Random number Generator (TRNG) generating keys; a client app CA, a Idp Server, a plurality of server app SA and a non-transitory computer-readable medium comprising instructions stored thereon, that when executed on a processor, perform the steps of: requesting by the Client app CA to Identity server IdP for the issuance of access token for accessing server app SA; generating by the Client app CA random secret share [k] and [k1] then providing to IdP server; completing and validating of user credentials, IdP server issues CA an access token T wherein the payload of the token T now consists of two additional inputs [k] & [k1]; embedding by the IdP server said [k] & [k1] into the token payload before cryptographically signing either with HS256 or RS256 signature schema; and sending by the client app CA the token T to service app SA and in order to validate the presented token by service app SA initiates a cryptographic challenge-response schema with the client app CA.
In another embodiment the Client application CA generates a random secret [k] and then splits [k] into two secret shares [k1] and [k2] using the non-linear secret sharing (NLSS) image cryptography and said Client application CA then transmits [k] & [k1] to IdP server and keeps [k] & [k2] securely itself.

In yet another embodiment the said token T served by IgP server has one secret share [k1] while the other secret share [k2] is stored with the client application CA and both the CA and SA do not merge the full secret shares [k1] & [k2] to revalidate the token T, but only transmit a small portion of the secrets using the challenge-response in order to validate the token.

BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS

Fig 1 illustrates the method of generation of JWT in accordance with the present invention;
Fig 2 illustrates the method of splitting random secret key [k] into two secret shares [k1] and [k2] using the non-linear secret sharing (NLSS) image cryptography in accordance with the present invention;
Fig 3 illustrates the result of the merger of the 512 values of [k1] & [k2] as compared with the values of the corresponding 32 coordinates of the original challenge accordance with the present invention;
Fig 4 illustrates a two level share generation wherein four secret shares are generated in accordance with the present invention;
Fig 5 illustrates challenge-response process which include CA sending the values of the 64 coordinates of each of the private shares in accordance with the present invention;
Fig 6 illustrates the method of splitting a User’s secret into four secret shares using the non-linear secret sharing (NLSS) in accordance with the present invention to achieve secure User authentication to Web Servers;
Fig 7 illustrates an embodiment of Figure 6 wherein the user keeps one secret share (K 11 ) & sends three (K 12 , K 21 & K 22 ) in accordance with the present invention;
Fig 8(a) illustrates an embodiment where the IdP Server stores (or commits) the token T on the DFS, it receives a DFS hash in accordance with the present invention;
Fig 8(b) illustrates the challenge-response method between the User & the Server to complete the authentication.

DETAILED DESCRIPTION

The disclosure herein propose a solution using cryptographic secret share tags that protect against the loss/theft of stateless access tokens. The solution works as follows:

As shown in Fig 1, the Client app CA requests Identity server IdP to issue access token for accessing server app SA. After successfully completing the validation of user credentials, IdP server issues CA an access token T (JWT token in this example). Unlike the usual process as depicted in fig 1, the payload of the JWT token T now consists of two additional inputs [k] & [k1]. While requesting the IdP server to grant token, CA provides the inputs [k] & [k1] to IdP. IdP server embeds [k] & [k1] into the token payload before cryptographically signing either with HS256 or RS256 signature schema.

Generation of [k] & [k1]

As shown in Fig 2, the Client application CA generates a random secret [k] and then splits [k] into two secret shares [k1] and [k2] using the non-linear secret sharing (NLSS) image cryptography. Client application CA then transmits [k] & [k1] to IdP server and keeps [k] & [k2] securely itself. Note that the stateless JWT token has one secret share [k1] while the other secret share [k2] is stored with the client application CA.

Let us look at a scenario where client app CA sends the token T to service app SA. SA would like to make additional checks on whether the token T is presented by CA or from an imposter app CB. To revalidate, SA would initiate a cryptographic challenge-response schema with the client app. The challenge-response schema will involve the following steps:

Step 1: SA parses the token T to extract [k] & [k1]. The token [k] is typically an image with 1024*256 or 262,144 pixels (the image sizes can be vary). When split with NLSS cryptography, [k1] & [k2] would expand by 8 times = 8,192*256 or 2,097,152 pixels. As challenge, SA picks a random set of 64 coordinates from the 262,144 pixels of [k] in the matrix and sends the challenge to CA seeking the corresponding 8*64=512 values from [k2]. It should be noted that the one can choose a different number than 64 for challenge, depending on the level of security & performance needed.

Step 2: Upon receiving the challenge, CA would return the correct values of the 512 coordinates back to SA.

Step 3: SA would merge the response values from CA with the corresponding values of the corresponding 512 coordinates of [k1]. The result of the merger of the 512 values of [k1] & [k2] is being compared with the values of the corresponding 64 coordinates of the original challenge initiated. An exact match would revalidate the credentials of the token T.

Note that CB will not be able to provide the correct response to the challenge, since it does not possess the secret [k2]. Hence, CB is not able to provide the additional proof of its ownership of the token T. A spoofing App is unable to gain access the Service App even if in possession of the stateless token T.

With the inventive method described above:
(a) Stateless or JWT tokens can be issued for a longer period of time without being worried about loss or theft
(b) Apps are able to provide peer-to-peer authentication without needing to contact a third party server

In the method described in this invention, the Client App CA generates a random secret k & splits it into [k1] & [k2]. Knowledge of either of the [k1] & [k2] by itself is not enough to recreate [k]. Knowledge of both the secret shares [k1] & [k2] would be needed to recreate the original secret [k]. The non-linear secret share cryptographic schema means every time [k] is split into secrets [k1] & [k2], the resulting secret pairs are orthogonally different. The encryption schema itself is keyless.

Note that in this invention, both the CA and SA do not merge the full secret shares [k1] & [k2] to revalidate the token T, but only transmit a small portion of the secrets using the challenge-response method to validate the token. This ability to validate the private shares without fully transmitting them is a very unique aspect of this invention. Of the 2,097,152 pixels in each private share, only 512 pixels are used each time to complete the challenge-response based authentication. As the private shares are themselves not revealed or transmitted over the network, the authentication process remains secure and sustains an extremely large number of authentications.

Key calculations behind the crack resistivity of the method explained:

Where the size of [k] is 1024*256 pixels or 218 bits,
size of the generated secret shares [k1] & [k2] = 221 bits.

Given the knowledge of [k] & [k1], for a 64 bit challenge-response schema, iterations required to find out [k2] = 264 (crack resistivity of the challenge-response schema).

For a 64 bit challenge-response schema,

1. Probability of a wrong share getting accepted = (1/2)64 = 5.421010e-20
2. In implementations where the 64 bits for challenge are chosen sequentially (challenge 1: 0 to 63 positions; challenge 2: 64 to 127 positions ….), total number of challenges possible without repetition = 218/26 = 4096. Probability that the same bit is repeated is 0 since counter is run sequentially.
3. In implementations where the 64 bits for challenge are chosen randomly,
Probability that same bit will be chosen after 1 attempt = ((1/2)18 * (1/2)18)*218 = (1/2)18 = 3.814e-6
Probability that same bit will be chosen after n attempts = n * (1/2)18
Probability that same bit will be chosen after 210 attempts = 210 * (1/2)18 = (1/2)8

Probability that same 64 bits will be chosen after 1 attempt = ((1/2)18)64 = (1/2)82
Probability that same 64 bits will be chosen after n attempts = n * (1/2)82
Probability that same bit will be chosen after 210 attempts = 210 * (1/2)82 = (1/2)72

Increasing number of private shares to enhance resistivity

To enhance the resistivity of the challenge-response schema, the applicant herein propose additional levels of secret share generation. For example a two level share generation of [k], four secret shares will be generated, k11, k12, k13 & k14. Along with [k], [k11) will be designated as public share and will be embedded into the JWT token T. Other three secret shares are kept as private shares by the Client app CA. The response in the challenge-response process will include CA sending the values of the 64 coordinates of each of the private shares.
With the two level secret share generation & three private secret shares,
Where the size of [k] is 1024*256 pixels or 218 bits,
size of the generated secret shares [k1] & [k2] = 224 bits

Given the knowledge of [k] & [k1], for a 64 bit challenge-response schema, iterations required to find out [k2] = 264*3 = 2192 (crack resistivity).

In an alternative implementation, [k] can be split into 8 secret shares, by adding another level of splitting in the tree. This creates 7 private secret shares. The corresponding crack resistivity = 264*7 = 2448. More levels of splitting can be added to increase resistivity, but this depends on the performance requirements. Based on the calculations shown in this document, one or two three private secret shares is sufficient security for most applications. In any case, the shares can be regenerated when needed.

In another embodiment, and referred in Fig 8(a), the secure services authentication can be achieved by not transmitting the stateless access or JWT token between IdP Server, Client & Service Apps. Instead, IdP Server can store the token T on a Distributed File System (DFS). One example of the DFS is the Inter-Planetary File System (IPFS)1 but different DFS can be used as well for the intended purpose.

When the IdP Server stores (or commits) the token T on the DFS (the commit is called as pinning in the case of IPFS, it receives a DFS hash (the DFS hash can be used by any app to retrieve the token T without needing to communicate with the IdP Server again). After receiving the DFS hash, the IdP Server sends the DFS hash to the Client App. In order to access the Service App, the Client App simply needs to present the DFS hash. Upon receiving the DFS hash, the Service App retrieves the token T from the DFS by presenting the DFS hash. After retrieving the token T, the Service App validates T using the challenge-response methods explained in this invention (Fig 3).

It should be noted that token T still contains the secret [k] & one secret share [k11]. By transmitting the DFS hash instead of the token T itself, the invention helps to enhance security considerably. Note that JWT tokens are usually encrypted only by simple Base 64 encryption & can be deciphered easily. By transmitting the DFS hash instead, no information about the tokens is revealed on the network.

Another useful feature in this embodiment is about the token management. If the IdP server would like to revoke the token T, it simply deletes or uncommits (uncommit is known as unpinning in the case of IPFS) it from DFS or uncommit. The Service App upon presenting the DFS hash will come to know that the token T is revoked by the IdP server. Currently, Service Apps need to check with IdP servers or App Gateways continuously to check if tokens are valid or not (increasing centralization, latency, costs & creating additional security challenges).

In an exemplary embodiment :-
User authentication using NLSS secret shares

The method is similar to one explained in services authentication, but used for User authentication (either as a Two Factor Auth or as a software passwordless solution). User generates a secret on his mobile or desktop (mostly using an app). The secret can be generated in various methods, some of which are described below:
Secret from user defined password User can choose a password. The double hash of the password is computed to determine the secret. Secret = Hash (Hash(Password))
Secret from a random input User’s system can generate the secret from a random input. The random input can be derived either using True Hardware Random Number Generator or a pseudo random number generator function.or Secret can be randomly generated by the User.
Secret from a private key or FIDO private key A private key can be generated on the User’s system using a private-public key method. The private key is used to determine the secret on the User’s system.

Once the private key is generated, the User then splits the secret into four secret shares K 11 , K12 , K 21 & K 22 as shown in figure 6 shown below: As an alternative to splitting into 4 shares, User can generate 8, 16, 32,… secret shares depending on the level of security needed. The higher the number of shares, the more secure the implementation would be.

Once 4 secret shares are generated, User keeps three secret shares K 11 , K 12 , K 21 and sends K22 to the Authentication Server, along with the secret itself. Each secret is 1024*256 pixels (262,144 pixels) & each secret share is of 8192*256 pixels (2,097,512 pixels) in this illustration, but the size can be varied based on the implementation security & bandwidth needs.

When the Authentication Server needs to verify the identity of the User

1. Server generates a challenge to the User. The challenge consists the coordinates of 512 pixels of the 8192*256 pixels. The 512 coordinates can be picked by the Server randomly or in a pre-set fashion. Since the Server is honest in its attempt to prove the identity of the User, there is no risk of compromise or repeat of the challenge coordinates.

2. Once the challenge is received, User picks the values from the three secret shares K 11 , K 12
&; K 21 of the coordinates contained in the challenge & sends them back to the Server.

3. Server combines the values of the 512 coordinates from the three secret shares sent by the User & the values of the 512 coordinates from the secret share K 22 held at the Server. The output is compared with the values of the 512/8 = 64 coordinates of the original Secret. If the Match is perfect, authentication is successful; else, it is a failure. User is able to prove the secret share knowledge of the Secret without sharing the full secret shares themselves with the Server.

Steps 1 to 3 describe how the Server authenticates the User using a challenge-response method based on non-linear secret sharing. To achieve mutual authentication, the User can issue a similar challenge based of 512 coordinates to the Server – the Server would send the response to the User to complete the authentication. Since both the User & Server complete the challenge-response interactions, both authenticate each other, resulting in mutual authentication.

Second version: Zero Knowledge Proof
In another embodiment, and as shown in Fig 7, the user keeps one secret share (K 11 ) and sends three (K 12 , K 21 & K 22 ) to the Server (instead of sending one share and keeping three). Note that the Server can now create K2 by itself using K 21 & K 22 . However, the Server would need K 11 to calculate K 1 and hence K to complete the validation.

1. Server generates a challenge to the User. The challenge consists of values of the 512 coordinates of K12 . Upon receiving the challenge, User combines the values of the corresponding 512 coordinates of K11 with the received values of K12. The resulting combination values are sent to the Server (combination values are nothing but the values of the corresponding coordinates of K1 ).

2. Upon receiving the values of the 512 coordinates of K 1 , Server combines the values with the corresponding values of K 21 & K 22 . The final result is then compared with the corresponding values of Secret K as shown in Fig 8(b).

3. Note that in this embodiment, the User never shares any values of the K 11 to the Server over the network. Hence, we can say that the User is able to provide zero knowledge about his secret share K 11 to the Server.

Although the foregoing description of the present invention has been shown and described with reference to particular embodiments and applications thereof, it has been presented for purposes of illustration and description and is not intended to be exhaustive or to limit the invention to the particular embodiments and applications disclosed. It will be apparent to those having ordinary skill in the art that a number of changes, modifications, variations, or alterations to the invention as described herein may be made, none of which depart from the spirit or scope of the present invention. The particular embodiments and applications were chosen and described to provide the best illustration of the principles of the invention and its practical application to thereby enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplated. All such changes, modifications, variations, and alteration should therefore be seen as being within the scope of the present invention as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly, legally, and equitably entitled.