FIELD OF INVENTION

The present invention relates to a system and method for identity-based entity authentication for client-server communications.

BACKGROUND ART

In recent times, online service providers have had an increasing capacity to authenticate a client with ease and confidence. This has made it possible for emailing, online banking, online shopping and social networking to flourish. It has also made it possible for bodies within the government, education and healthcare sectors to offer online services that have been hitherto impractical or impossible.

Authentication of a client is commonly known as "entity authentication". The most common technique involves authentication based on username and password. For a client, this technique is relatively easy to learn and implement. That is, the client only needs to choose a username and a password, both generally consisting of memorisable character strings.

Password-based authentication is, however, considered a relatively weak authentication mechanism with two underlying negative issues. Firstly, for every session that a client establishes a connection with the server, an identical password is used. Once the password is known (or successfully guessed) by an attacker, the attacker can replay the password to access the server. The system would be much more secure if every session is fresh, that is requiring a fresh password, whereby successful attack on a particular session does not result in the attacker being able to replicate the attack on previous or subsequent sessions. Secondly, clients tend to choose simple passwords since difficult- to-guess or long passwords are more difficult to remember. Many of these passwords are susceptible to dictionary attacks. This represents one of the main problems facing security systems with username and password mechanisms. Systems would generally be more secure if the password mechanism were to be replaced (or complimented) with stronger entity authentication approaches. Entity authentication based on cryptographic protocols can be used to address the above issues. These protocols provide much stronger authentication assurance compared with using username and password entry alone. Cryptographic protocols involve message interactions between communicating parties in order to fulfil security requirements of a particular system. This is generally achieved using cryptographic building blocks, such as message authentication codes, hash functions and digital signature schemes.

One example of a cryptographic protocol is the handshake protocol in SSL/TLS. This provides authenticated key agreement for secure session establishment. SSUTLS is widely deployed to authenticate websites for secure online transactions. The main underlying security framework of this protocol is a Public Key Infrastructure (PKI) that uses digital certificates. A certificate-based PKI includes fully trusted Registration Authorities (RA), fully trusted Certificate Authorities (CA) and the management of certificates issued to clients. Common implementation of this protocol sees SSUTLS being used on the server-side (i.e. for a client to authenticate the server based on a server certificate), but to use username and password, and possibly credit card information for the server to authenticate the client. This example presents security pitfalls in terms of the freshness and weakness of passwords, as discussed above. In addition, a client may also unintentionally expose his password to an external party when a bogus certificate is accepted.

A more secure alternative is to use a mutual authentication setting of SSUTLS. In this setting, both the server and the client register with the RA and, given the registration information, the CA issues digital certificates to the server and the client. The client certificate contains a digitally signed public key and identification information for the client. A private key corresponding to the public key is also generated by either the client or the CA depending on the application policy. If someone wishes to verify the public key of a client, C, they can do so by verifying C's certificate that is signed by the CA. In this example, C's private key must be stored securely, while the certificate can be publicly announced or provided when required. During authentication, C initiates the communication by first authenticating the web server through verification of the server certificate. In return, the web server requests C's certificate and a signature by C on the messages that have been exchanged between the two parties up to the signature request. The web server then verifies the identity of C by verifying the signature using C's public key. The web server also verifies the authenticity of C's certificate, which in this case is a signature on the certificate signed by the CA. While security issues surrounding password-based authentication may be addressed by deploying mutual authentication based on SSIJTLS with the support of certificate-based PKI, computation and management of certificates for clients and web servers remains one of the main overheads in existing certificate-based entity authentication mechanisms (i.e. SSUTLS).

It would be advantageous if entity authentication protocols could be constructed that are designed using challenge-response techniques and that are certificate-free on the client side. In particular, it would be advantageous if systems could be devised that simplify client side identity management and minimise the required changes on legacy systems on the server site.

The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described above. Rather, this background is only provided to illustrate one exemplary technology area where some embodiments described herein may be practice.

SUMMARY OF INVENTION

The present invention relates to a system and method for identity-based entity authentication for client-server communications.

One aspect of the present invention provides a system (100) for identity-based (ID- based) entity authentication for client-server communications comprising a trusted authority module (110) configured to register at least one client and at least one server involved in the client-server communications and generate public parameters and secret parameters for use in the authentication; a server module (120) configured to securely store secret parameters for the server to authenticate the server to the client, and to authenticate the client to the server; a client module (130) configured to verify the authenticity of the server and to authenticate the client to the server; and a protocol module (140) configured to provide mutual authentication between the client and the server. The protocol module (140) further comprises at least one selector engine (142) and at least one message authentication code engine (144) to provide mutual authentication between said client and said server using ID-based challenge-response protocol and that said server module (120) authenticates said client to said server using ID-based signature scheme, wherein said selector engine (142) is configured to select challenge-response messages for mutual authentication of said client and said server and said message authentication code engine (144) is configured to compute keyed authentication tokens on said challenge-response messages using a message authentication code algorithm.

In another aspect the invention provides a system (100) wherein the trusted authority (110) comprises a private key generation engine (112) and a certificate authority engine (114).

In a further aspect the invention provides a system (100) wherein the private key generation engine (112) is configured to generate public parameters, at least an ID- based master key and ID-based private keys for the client and the server based on server and client identity credentials using an ID-based signature scheme and wherein the certificate authority engine (114) is configured to generate a server certificate given a private key for the server.

In yet another aspect the invention provides a system (100) wherein the server module (120) comprises a signature engine (122) configured to create an identity credential, generate a certificate-based signature using a signature scheme or generate an ID- based signature using an ID-based signature scheme, and verify a signature using at least and ID-based signature scheme to authenticate the client. In still a further aspect the invention provides a system (100) wherein the client module (130) comprises a- signature engine (132) configured to create an identity credential, generate an ID-based signature using an ID-based signature scheme and verify a signature using a certificate-based signature scheme to authenticate the server. In another aspect the invention provides a method (200) for identity-based (ID-based) entity authentication for client-server communications comprising: registering at least one client and at least one server involved in said client-server communications and generating public parameters for ID-based and cert-based cryptographic keys for use in said authentication (210); generating at least one ID-based master key and securely storing said ID-based master key (220); computing client and server private keys using said ID-based master key (230); transmitting said public parameters to said client and said server and transmitting said client and server private keys to said client and said server respectively (240); generating a server certificate based on a given certificate private key for said server (250); transmitting said server certificate to said server (260); and mutually authenticating said client and said server (270). The said mutual authentication between said client and said server (270) uses an ID-based challenge- response protocol and that authentication of said client to said server uses an ID-based signature scheme. In a further aspect the invention provides a method (300) wherein mutually authenticating said client and server (270) further comprising steps of receiving a request from the client to communicate with the server (310). The method comprises the steps of receiving a request from said client to communicate with said server (310); said server generating a signature based on said private key for said server (320); said client and server agreeing on a session key based on said signature or a certificate of said server under a key exchange protocol (330); said client and server negotiating and agreeing on authentication and freshness modes for said authentication (340); and said client and server mutually authenticating each other using methods under said authentication and freshness modes (350).

In yet another aspect the invention provides a method (400) wherein said client and server mutually authenticating each other using methods under said authentication and freshness modes further comprising said server generating a nonce and a MAC on the nonce using the session key (410); said server sending the nonce and the MAC to the client (420); said client computing a MAC using the session key on the received nonce (425); said client comparing the newly generated MAC with the received MAC value (430); said client generating a nonce and signing an authentication message using the ID-based private key (440); hashing the signature together with the client generated nonce and other security information using said session key (450); said client sending the ID-based signature, nonce and the MAC to the server for verification (460); said server computes a MAC using the session key on the nonce and the signature (470); said server comparing newly generated MAC with the received MAC (480); said server verifying ID-based signature using client ID (490) and said server allowing client to access authorized files (495).

In still another aspect the invention provides a method (500) wherein said client and server mutually authenticating each other using methods under said authentication and freshness modes further comprising said server generating a nonce and a MAC on the nonce using the session key given the 1-time ID-based signature (510), said server sending the nonce and the MAC to the client (520); said client computing a MAC using the session key on the received nonce (525); said client comparing the newly generated MAC with the received MAC (530); said client creating a session public ID and using the ID-based private key to generate a new 1-time private key (540); said client generating a nonce and signs an authentication message using the 1-time private key (545); hashing the ID-based signature with the client generated nonce using said session key (550); said client sending the session public ID, ID-based signature, nonce and the MAC to the server for verification (560); said server computes a MAC using the session key on the nonce and the signature (565); said server comparing newly generated MAC with the received MAC (570); said server verifying ID-based signature using client session public ID (580); and said server allowing client to access authorized files (590).

A further aspect of the invention provides a method (600) wherein said client and server mutually authenticating each other using methods under said authentication and freshness modes further comprising said client generates time-stamp, signing authentication message using ID-based private key when given ID-based signature with timestamp mode (610); said client computes a MAC using the session key on the timestamp and the ID-based signature (620); said client sending ID-based signature and timestamp to the server for verification (630); said server computes a MAC using the session key on the ID-based signature and the timestamp (640); said server compares newly generated MAC with the received MAC (650); said server verifies said ID-based Signature using client ID (660) and said server allowing client to access authorized files (670).

In another aspect the invention provides a method (700) wherein said client and server mutually authenticating each other using methods under said authentication and freshness modes further comprising said client creating a session public ID and using the ID-based private key to generate a new 1-time private key (710); said client generating a timestamp and signing an authentication message using the 1-time private key (715); said client computing a MAC using the session key on the timestamp and MAC to the server (720); said client sending the session public ID, ID-based signature timestamp and MAC to the server for verification (730); said server computing a MAC using the session key on the ID-based signature and timestamp (740); said server comparing newly generated MAC with the received MAC (750); said server verifying ID- based signature using client's session public ID (760) and said server allowing client to access authorized files (770).

The present invention consists of features and a combination of parts hereinafter fully described and illustrated in the accompanying drawings, it being understood that various changes in the details may be made without departing from the scope of the invention or sacrificing any of the advantages of the present invention. BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

To further clarify various aspects of some embodiments of the present invention, a more particular description of the invention will be rendered by references to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail through the accompanying drawings in which:

FIG. 1.0 illustrates the system of an embodiment of the invention. FIG. 2.0 illustrates the method of an embodiment of the invention. FIG. 3.0 further illustrates the method of FIG. 2.0. FIG. 4.0 further illustrates the method of FIG. 2.0. FIG. 5.0 further illustrates the method of FIG. 2.0. FIG. 6.0 further illustrates the method of FIG. 2.0.

FIG. 7.0 further illustrates the method of FIG. 2.0.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a system and method for identity-based entity authentication for client-server communications.

Hereinafter, this specification will describe the present invention according to the preferred embodiments. It is to be understood that limiting the description to the preferred embodiments of the invention is merely to facilitate discussion of the present invention and it is envisioned without departing from the scope of the appended claims.

Referring to Figures 1 and 2, the system (100) of embodiments of the invention includes a trusted authority module (110) that is configured to register clients and servers, and to generate ID-based and cert-based cryptographic keys (210). The trusted authority module (110), after being given an identification (ID) by a server (or a client), verifies the ID and executes a private key generation (PKG) engine (112) to generate public parameters and a trusted authority (TA) master key (220). Together with the server (or client) ID, the TA master key is used as an input to the PKG engine (112) to further generate a private key for the server (or client) (230). The public parameters and the ID- based public-private key pair (server or client ID, server or client ID-based private key) are transmitted to the server (or client) under a secure channel (240).

At the same time, the trusted authority (TA) module (110) also executes a certificate authority (CA) engine (114) to generate a server certificate given a server private key (250). The certificate is transmitted to the server (260) and the ID-based and cert-based key pairs are used by the server and client to mutually authenticate one another (270).

Referring to Figures 1 and 3, the system (100) also includes a server module (120) configured to authenticate the server to the client and to verify the authenticity of a client. In particular, a server, after receiving request to communicate from a client (310), authenticates itself to the client by executing a signature engine (122) to sign a communication message using its cert-based private key (320). The server then uses a protocol module (140), discussed in more detail below, to authenticate to the client. A client module (130) is provided to verify the authenticity of the server and to authenticate the client to the server. A client, after verifying the server signature by executing a signature engine (132) and using the server certificate, signs a communication message using its ID-based private key. The client then uses the protocol module (140) to authenticate to the server.

The system further includes a protocol module (140) configured to provide mutual authentication between the server and the client through authenticated key exchange protocols. In particular, the server and the client, after the client receives the server signature or certificate and verifies its authenticity, agree on a session key based on a key exchange protocol such as the SSL/TLS handshake protocol (330). The server, after successful completion on session key establishment with the client, agrees with the client on a client authentication mode, requesting the client to either authenticate by an ID-based signature or a 1-time ID-based signature through executing a selector engine (142). At the same time, the server further agrees with the client on a freshness mode (340), whether authentication on nonce or timestamp through executing the message authentication code (MAC) engine (144). The client and server mutually authenticate one another using the methods under the authentication and freshness modes (350).

If ID-based signature and nonce is selected (400), the server generates a nonce (which is a unique random number used only once for each session) and uses the session key as an input to generate a MAC on the nonce (410). A MAC is a message authentication code that provides data origin authentication between two or more parties. The nonce and the MAC are sent to the client (420).Thereafter, the client computes the MAC using the session key on the received nonce (425). Upon receiving the nonce and the MAC, the client verifies the MAC by using his or her session key to compute a MAC on the received nonce. The newly computed MAC is compared with the received MAC (430). If both are identical then the client is assured that the nonce is from the server. If it is not, the client terminates the session.

The client then signs an authentication message using his or her ID-based private key and generates a nonce (440). The signature and the nonce is MAC using the MAC engine (450). The signature, nonce and the MAC are sent to the server (460). The server then verifies that the received MAC is correct by executing the MAC engine (144) on the received signature and nonce. The server computes a MAC using the session key on the nonce and the signature (470) and the server compares the newly generated MAC with the received MAC (480). If it is correct the server proceeds to verify the ID- based signature using the client's ID (490). If the signature is valid, then the client is authenticated wherein the server allows the client to access authorized files (495).

If 1-time ID-based signature and nonce is selected (500), the server and the client folloW the same steps as above (510, 520, 525, 530, 550, 560), except that the client creates a session public ID and uses the ID-based private key to generate a new 1-time privatej key (540). The 1-time private key is used to generate the signature instead of using the ID-based private key (545). The server again computes a MAC using the session key on the nonce and the signature (565) and the server compares the newly generated MAC with the received MAC (570). If it is correct the server proceeds to verify the ID-based signature using the client session public ID (580). If the signature is valid, then the client is authenticated wherein the server allows the client to access authorized files (590).

If ID-based signature and timestamp is selected (600), the client generates a signature on a timestamp using his or her ID-based private key (610) and MAC the timestamp and the signature using the session key (620). The timestamp, signature and MAC are sent to the server (630). Upon receiving the timestamp, signature and MAC, the server verifies the MAC by using his or her session key to compute a MAC on the received timestamp and signature (640). The newly computed MAC is compared with the received MAC (650). If both are identical the server proceeds to verify the signature using the client's ID (660). If the signature is valid, then the client is authenticated and the server allows the client to access authorized files (670).

If 1-time ID-based signature and timestamp is selected (700), the client create a session public ID and use the ID-based private key to generate a new 1-time private key (710). The client generates a timestamp and signs an authentication message using the 1 -time private key (715). The client computes a MAC using the session key on the timestamp and the ID-based signature (720). The client sends the session public ID, ID-based signature, timestamp and MAC to the server (730) and the server computes a MAC using the session key on the ID-based signature and the timestamp (740). The server compares the newly generated MAC with the received MAC (750). If both are identical, the server proceeds to verify the ID-based signature using the client session public ID. If the signature is valid, the server allows the client to access authorized files (770).

Unless the context requires otherwise or specifically stated to the contrary, integers, steps or elements of the invention recited herein as singular integers, steps or elements clearly encompass both singular and plural forms of the recited integers, steps or elements.

Throughout this specification, unless the context requires otherwise, the word "comprise", or variations such as "comprises" or "comprising", will be understood to imply the inclusion of a stated step or element or integer or group of steps or elements or integers, but not the exclusion of any other step or element or integer or group of steps, elements or integers. Thus, in the context of this specification, the term "comprising" is used in an inclusive sense and thus should be understood as meaning "including principally, but not necessarily solely".

It will be appreciated that the foregoing description has been given by way of illustrative example of the invention and that all such modifications and variations thereto as would be apparent to persons of skill in the art are deemed to fall within the broad scope and ambit of the invention as herein set forth.