EP1912376B1

EP1912376B1 - Method and apparatus for authentication

Info

Publication number: EP1912376B1
Application number: EP06122041A
Authority: EP
Inventors: Gina Kounga; Chris Mitchell; Thomas Walter
Original assignee: NTT Docomo Inc
Current assignee: NTT Docomo Inc
Priority date: 2006-10-10
Filing date: 2006-10-10
Publication date: 2009-04-22
Anticipated expiration: 2026-10-10
Also published as: DE602006006454D1; JP2008113426A; EP1912376A1; JP4709815B2

Description

FIELD OF INVENTION

The present invention relates to a method and an apparatus for authentication, in particular in an ad-hoc network or an infrastructureless network.

BACKGROUND OF THE INVENTION

When a server wants to establish a secure communication channel with a client, the server must authenticate the client in order to be sure that it is communicating with the one intended, and must establish a session key in a way that guarantees that only the intended client will know the value of that secret key. It should be noted that here and in the following the terms client and server are used to respectively designate the entity that is authenticated and the one that performs the authentication. They are not intended to be understood as being limited to define client-server type communication. The solution of the invention which will later be presented can be applied to any type of communication (client-server, peer to peer, etc.).
Two methods permit authentication and the establishment of secure communication channels: one can either use public key certificates or use pre-shared keys. However, these solutions either require that an online trusted third party (TTP) is always reachable that is able to distribute up-to-date certificate revocation status information and secret keys, or require that clients and servers share in advance a secret key. In ad hoc networks there is no fixed infrastructure which guarantees that a TTP is always reachable and that only entities are present that share a secret key in advance. This can prevent a server from establishing confidential communication with a client. However, many applications require confidentiality of data to be provided even in ad hoc networks, such as the exchange of authentic and confidential message between rescue teams during natural disasters (earthquakes, etc.), the exchange of confidential messages between business partners during a trade fair, the legal distribution of multimedia resources between mobile devices, etc.
Two fundamental problems that need to be solved in order to establish secure communication channels in ad hoc networks are the following: How can a server authenticate a client that it has never met, and how can it establish a session key with it without using a public key certificate or a pre-shared secret key?
Existing solutions for authentication use hash chains. In existing solutions, when a client uses a one-way hash chain to prove its identity to a server, that client must publish the values contained in that chain. Because of this, these values cannot be used later to encrypt confidential data. This is the reason why one-way hash chains are not used to establish a secret key but only to perform authentication.
This use of one-way hash chains is schematically illustrated in Fig. 1. Here the client sends K_m to the server. For the i^th authentication to the server, the client sends K _m-i. The server then checks that fⁱ (K _m-i)=K_m . Since one-way hash chains are computationally hard to revert, only the client that knows the secret value s used to generate the one-way hash chain is able to send valid values to the server.
One may therefore regard a problem posed in the prior art to provide a solution how to use one-way hash chains to establish secure communication channels as follow:

How to define a one-way hash chain that permits publication of its elements without exposing these published elements to compromise?
How to verify the identity of the client that generated these elements without using a public key certificate?
How to use these published elements to derive a secret key?
More generally speaking, one may regard a problem of the invention of how to authenticate a client towards a server in an environment where no connection to a trusted third party is possible, such as in mobile ad-hoc networks.
In the following some prior art approaches are briefly presented.
In Y.-R. Tsai and S.-J. Wang, "Routing security and authentication mechanism for mobile ad hoc networks," in "Proceedings of the IEEE 60th Vehicular Technology Conference, 2004", entities from the same group share a group key and a pair-wise secret key with each member of the group. These keys are used to respectively prove the membership to the group and to prove its identity to a group member. However, in infrastructureless or ad-hoc networks, nothing guarantees that entities are always present that share a secret key in advance. Since no solution is proposed to permit entities that meet for the first time to establish shared keys, this solution can not always be used in infrastructureless or in ad-hoc networks.
The TESLA broadcast authentication protocol (see A. Perrig, R. Canneti, J. Tygar, and D. Song, "The TESLA broadcast authentication protocol," CryptoBytes, vol. 5, no. 2, pp. 2-13, 2002) relies on one-way hash chains (see L. Lamport, "Password authentication with insecure communication," Comm. ACM, vol. 24, no. 11, pp. 770-772, 1981) to authenticate the source of some broadcasted packets. However, the solution does not provide the means to bootstrap entity authentication. This must be provided by a regular data authentication system at session setup (see Perrig, D. Song, R. Canetti, J. D. Tygar, and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction," RFC 4082 (Informational), June 2005). Moreover, it does not support the establishment of a secure communication channel.
In A. Weimerskirch and D. Westhoff, "Identity certified authentication for ad-hoc networks," in SASN '03: Proceedings of the 1st ACM workshop on Security of ad hoc and sensor networks. New York, NY, USA: ACM Press, 2003, pp. 33-40, an entity A has some certificates issued by a trusted third party TTP from the fixed network. The issuance of certificates is made while A has connectivity with a fixed network. Each certificate binds A's identity to its one-way hash chain. More specifically, A chooses a secret key x ₀ that is the anchor of the chain. Given h, a secure cryptographic hash-function, m ≥ 1 a system parameter, and x_i = hⁱ (x ₀) (i ≥ 0), then the last generated hash value x _2m from A's chain is contained in A's certificate. That certificate also contains the issuance time and a random seed. Then, A divides time into intervals of equal length L - with L a public value - and assigns two keys from its one-way hash chain to each interval - in respect of the sense of use of the chain. In the interval T_i (0 ≤ i < m) between times t = iL and t = (i + 1)L, A uses the two values x _2m-2i-1 and x _2m-2i-2 from its chain to be authenticated by B. B can verify the correctness of these two values by first verifying the certificate to get a trusted copy of x _2m, and then iterating the hash-function the appropriate number of times on the hash values and comparing the result with the value x _2m. However, once x _2m-2i-1 and x _2m-2i-2 are disclosed, an attacker can replay them to an entity C to pretend it is A. To reduce this risk, B must ask A to use a certificate with a specific seed value. As a consequence, an attacker can only replay a previously disclosed key if it is asked by a verifying entity to present a certificate previously used and that contains a seed value already requested by another verifying node to A . However, since keys must be disclosed to perform entity authentication, they cannot be used to establish a secure communication channel. This means that an additional entity authentication solution must be used to permit A and B to establish an authenticated session key.

SUMMARY OF THE INVENTION

According to one embodiment there is provided a method for authenticating a client or first node towards a server or second node in an ad-hoc network, said method comprising:

obtaining a secret key s by said client node and using it to generate a one-way hash chain which is bound to the identity of said client node through a unique hash-code value contained in a certificate;
deriving a number of m public/private key pairs, m being an integer, by said first node using said one-way hash chain of said first node, said public/private key pairs being bound to one another and to the hash-code value contained in said client node's certificate;
sending by said client node one of its generated public keys along with its certificate to said server node;
authenticating said client node by said server node by verifying that the disclosed public key is bound to the hash-code value contained in said client node's certificate.

In the provided solution, each client, say A, chooses (or somehow obtains) a secret key s and uses it to generate a one-way hash chain. That chain is bound to A's identity through a unique hash-code value contained in a certificate. The client uses its chain to derive a number of public/private key pairs. These public/private key pairs are bound to one another and to the hash code value contained in A's certificate. Then, to be authenticated by the server B, the client just needs to send one of its public keys to B along with its certificate. B can authenticate A by verifying that the disclosed public key is bound to the hash-code contained in A's certificate.
It should be mentioned here that the public/private key pairs "being bound to each other" can be implemented by deriving the public/private key pairs based on the elements of a hash chain. This ensures that they are not independent of each other but to some extent "depend on each other" and therefore may be regarded as "being bound to each other". If the hash code contained in the certificate of the client is also based on the hash chain this hash code may therefore also be regarded as "being bound to the public/private key pairs".
According to one embodiment said public/private key pairs are bound to each other by each of said public/private key pairs being generated based on a first one-way hash chain which is generated based on said secret key s using a first hash function, and said method comprises: sending one or more elements of the same hash chain on which said public key is based from said client to said server. This enables a plurality of keys to be generated based on a single secret value s. It further enables the checking by using one or more elements of the same hash chain on which the public key sent from the client to the server is based.
According to one embodiment said public/private key pairs are bound to said unique hash-code value contained in a certificate by applying a second hash function to said one way hash chain. This makes it necessary to store only a single hash value in said certificate.
According to one embodiment said hash-code value is bound to the identity of said client contained in said client's node certificate through a signature generated using the private key of a trusted third party. This initially generates trust during an initialization phase of the proposed scheme.
According to one embodiment said method comprises:

an initialization phase during which said client node is connected to a trusted third party and an authentication phase during which no connection to a trusted third
party is necessary, whereas said initialization phase comprises:
- synchronizing the clock of the client with the one of the trusted third party;
- deriving a check value $v = h (g^{\prod_{j = 0}^{m} f^{j} (s)})$
  whereas f is said first cryptographic one-way hash function and h is said second one way hash function;
- requesting from said trusted third party a certificate which binds the identity of said client to said check value, said certificate containing a reference time value;
- dividing time into m equal intervals of length L, and assigning a respectively different key to each of said intervals, said keys being generated based on repeatedly applying said hash function f to s , whereas
said client node uses in a time interval T_i , 0≤i <m as private key $K_{m - 1 - i} = \prod_{j = 0}^{m - i - 1} f^{j} (s),$
and as corresponding public key g ^{K m-1-i}, said
method further comprising an authentication phase that comprises:
- sending said check value from said client to said server;
- sending the public key g^Kw = g ^{K m-1-i} assigned to the present time interval from said client to said server;
- sending f ^w+1(s) = f ^m-i(s) and said certificate from said client to said server;
and using these values by said server node which then computes: $\begin{array}{l} v * & = {(g^{K_{w}})}^{\prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} \prod_{j = w + 1}^{m} f^{j} (s) \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} . \end{array}$

for verifying the identity of said client node by checking that v = h(v*)

In this manner authentication becomes possible without a third party being necessary for performing authentication.
According to one embodiment G=(G,^*) is a finite cyclic group of order q, g ∈ G is a generator of G, and f is a cryptographic (one-way) hash-function mapping the set {0,1,...,q-1} onto itself.
According to one embodiment said initialization comprises:

distributing to said server node one or more of G, g, f, m, the trusted third party's public key K_TTP and h being a one way hash function;
and for the client node which wishes to prove its identity, calculating said check value accordingly and a certificate according to ${[ID, v, t_{0}, L]}_{K_{TTP}^{- 1}},$
whereas ID is the identifier of said node, t ₀ is a reference time or the issuing time of the
certificate, L defines the length of the time interval for which a public/private key pair is valid, and ${[\dots]}_{K_{TTP}^{- 1}}$
is the signature generated by the trusted third party with its private key $K_{TTP}^{- 1}$
on the fields of the certificate.

In this manner at different moments in time different keys are used that can be authenticated as soon as they are received. The compromise of a key at a given time does not give any information about the keys that will be used in the future. Therefore, an attacker that has compromised a key in the past cannot impersonate a user in the future.
According to one embodiment a clock drift is taken into account by defining a maximum clock drift between synchronized clocks and further whether more than one key may be disclosed during authentication to take into account a possible clock drift. This can take into account imperfect synchronization or a drift of the clocks.
According to one embodiment said method comprises:

authenticating said server node towards said client node in the same manner as said client node was authenticated towards said server node. This enables a mutual authentication.

According to one embodiment said method further comprises:

establishing a session key between said client node and said server node by computing: SK = (g^Kw ) ^Ky , whereas g^Kw is the public key sent from said client to said server and K_y is the said server 's private key.

This provides a solution that permits a client and a server that do not share a secret key in advance to establish an authenticated session key without using a public key certificate but by using one-way hash chains.
According to one embodiment there is provided an apparatus for authenticating a client node towards a server node in an ad-hoc network, said apparatus comprising:

a module for obtaining a secret key s by said client node and using it to generate a one-way hash chain which is bound to the identity of said client node through a unique hash-code value contained in a certificate;
a module for deriving a number of m public/private key pairs, m being an integer, by said first node using said one-way hash chain of said first node, said public/private key pairs being bound to one another and to the hash-code value contained in said client node's certificate;
a module for sending by said client one of generated public keys along with its certificate to said server node;
a module for authenticating said first node by said second node by verifying that the disclosed public key is bound to the hash-code contained in said first node's certificate.

According to one embodiment said apparatus comprises:

an initialization module for executing an initialization during which said client node is connected to a trusted third party and an authentication phase during which no connection to a trusted third party is necessary, whereas said initialization comprises:
- synchronizing the clock of the client with the one of the trusted third party;
- deriving a check value $v = h (g^{\prod_{j = 0}^{m} f^{j} (s)}),$
  whereas f is said first cryptographic one-way hash function and h is said second one way hash function;
- requesting from said trusted third party a certificate which binds the identity of said client to said check value, said certificate containing a reference time value;
- dividing time into m equal intervals of length L, and assigning a respectively different key to each of said intervals, said keys being generated based on repeatedly applying said hash function f to s, whereas
- said client node uses in a time interval T_i , 0≤i<m as private key $K_{m - 1 - i} = \prod_{j = 0}^{m - i - 1} f^{j} (s),$
  and as corresponding public key g ^{K m-i-1}, said apparatus further comprising an authentication module which comprises:
- a module for sending said check value from said client to said server;
- a module for sending the public key g^Kw = g ^{K m-i-1} assigned to the present time interval from said client to said server;
- a module for sending f ^w+1(s) = f ^m-i(s) and said certificate from said client to said server;
- and a module for using these values by said server node which then computes: $\begin{array}{l} v * & = {(g^{K_{w}})}^{\prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} \prod_{j = w + 1}^{m} f^{j} (s) \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} . \end{array}$
  
  for verifying the identity of said client node by checking that ν = h(ν*)

According to one embodiment said apparatus comprises:

a module for taking into account a clock drift by defining a maximum clock drift between synchronized clocks and further whether more than one key may be disclosed during authentication to take into account a possible clock drift.

According to one embodiment said apparatus further comprises:

a module for authenticating said server node towards said client node in the same manner as said client node was authenticated towards said server node.

According to one embodiment said apparatus further comprises:

a module for establishing a session key between said client node and said server node by computing: SK = (g^Kw ) ^Ky , where g^Kw is the public key sent from said client to said server and K_y is the said server's private key.

According to one embodiment there is provided a computer program for performing authentication in ad-hoc networks, said computer program comprising computer program code which when being executed on a computer enable said computer to carry out the method of one of the embodiments of the invention.
The proposed authentication scheme may be used to provide other security services such as authorization, integrity, etc. It can secure applications such as the secure exchange of resources: (e.g. multimedia files) in ad hoc networks. Nowadays, mobile phones are also MP3 players. Therefore mobile phones may be used to extend (legal) platforms for multimedia file distribution permitting distribution even when no infrastructure is accessible. The proposed scheme may further be used to secure confidential communication between business partners, e.g. during trade fairs, or the exchange of confidential and authentic data by rescue teams during natural disasters such as earthquakes, etc.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 illustrates the use of one-way hash chains for authentication.
Fig.2 schematically illustrates the mapping between time intervals and keys generated with elements in the client's one-way hash chain according to an embodiment of the invention.
Fig.3 schematically illustrates which elements of a hash chain are published according to an embodiment of the invention.
Fig.4 schematically illustrates a mechanism for taking into account drift according to an embodiment of the invention.

DETAILED DESCRIPTION

In the following detailed embodiments of the invention will be described.
Prior to use of the authentication scheme according to an embodiment of the invention, certain system parameters need to be agreed by all parties, as follows.

G=(G,*) is a finite cyclic group of order q (for some large q), g ∈ G is a generator of G, and we assume that computing discrete logarithms in G with respect to g is computationally infeasible. For example, G might be a large multiplicative subgroup of $Z_{p}^{*}$
for some large prime p, where q is a large prime dividing p-1; alternatively G could be the group of points on an elliptic curve (usually written additively).
h is a cryptographic (one way) hash-function mapping arbitrary length binary strings to strings of a fixed length (ℓ say, where a typical value for ℓ might be 224).
f is a cryptographic (one-way) hash-function mapping the set {0,1,...,q-1} onto itself. In practice, f might, for example, be derived from h.
m ≥ 1 is a positive integer that determines the number of key pairs available to the client.

In the following the authentication scheme according to an embodiment of the invention will be described.
When the scheme is initialized the client chooses a secret s E {0, 1, ... , q-1}. The client then generates the check value v as $v = h (g^{\prod_{j = 0}^{m} f^{j} (s)}),$

and v is included in a certificate signed by some trusted third party (TTP), e.g. the network operator to which the node has subscribed. That certificate contains the identity of the client and a reference time such as the issuance time of the certificate t ₀. The client is synchronized with the TTP and divides time into intervals of equal length L, where L is a public value. Each interval is assigned a key generated with elements from the client's one-way hash chain obtained by repeatedly applying f to s. This is schematically illustrated in Fig. 2 where it is shown how the time is divided into intervals of length L, and each interval at time iL has assigned a different key. A time different from the issuance time t ₀ of the certificate may also be chosen as long as the time identifies correctly a certain moment in time so that based on the reference time at any moment later in time it can be determined which interval iL is valid at a certain time so that the corresponding key can be identified.
Subsequently, in time interval T₁ , 0≤i≤m, the client uses as private key $K_{m - 1 - i} = \prod_{j = 0}^{m - i - 1} f^{j} (s),$
and as corresponding public key g ^{K m-1-i}. To enable a server to obtain a verified copy of the public key g^Kw (where w=m-i-1), the client sends the server:

g^Kw ,
f ^w+1(s), and
the certificate containing v.
The server can be assumed to know w (because it is time-dependent and can be derived from the present time and the reference time t ₀ contained in the certificate) and can then compute
f^j (s), w+1≤j≤m.

Using these values the server then computes $\begin{array}{l} v * & = {(g^{K_{w}})}^{\prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} \prod_{j = w + 1}^{m} f^{j} (s) \\ = g^{\prod_{j = 0}^{w} f^{j} (s)} . \end{array}$
Finally, the server checks that v = h(v*).
If the equality is verified then the server knows that g^Kw was generated by the client whose identity is contained in the received certificate.
Fig. 3 illustrates that at a certain moment in time when the authentication is performed only the value of the hash chain belonging to the interval into which the moment falls is published. The preceding values of the hash chain are not published.
Therefore and because at different intervals different values are published the proposed mechanism achieves a high level of security.
If the server and the client agree to use asymmetric encryption, the server is able to send to the client a confidential message by encrypting it with g^Kw . Then, the client will be able to decrypt the message with its private key K_w .
According to one embodiment, if the server uses the same method as the one used by the client previously, then the server can prove its identity to the client by disclosing the key g^Ky . Once the client has verified the validity of g^Ky , it can generate a Diffie-Hellman session key SK with the server such that: SK = (g^Ky ) ^Kw . The server obtains the same key by computing SK = (g^Kw ) ^Ky .
In the described solution, client, server and TTP should have synchronized clocks. Many solutions can be used to achieve such a synchronization, including use of the network time protocol (see D. Mills. Network Time Protocol (Version 3) Specification, Implementation and Analysis. RFC 1305, March 1992), making the client and server become synchronized with the TTP's clock, etc. This is done at the initialization phase, while client and server are connected to the fixed network. However, afterwards they may run independently of the TTP and the fixed network. Synchronization is performed to permit verification of the freshness and the validity of keys published during the authentication process. However, entities do not need to have perfectly synchronized clocks. A clock drift of few seconds may not be a problem if, for instance, two keys, or more, are valid during one time period as represented in Fig. 4. If d is the maximum clock drift that is tolerated between two entities synchronized with the TTP, then d can be the period of time that separates, in the same time interval, the beginning of the validity period of these two keys. This guarantees that at least one key will permit to establish an authenticated session key in each time interval. To illustrate this, reference is made to Fig. 4. In the interval T ₀, K _m-1 and $K_{m - 1}^{1}$
are valid, and even if there is a clock drift between the client's and the server's clocks, that is less than or equal to d, then at least one of the keys will permit verification of the relation v = h(v*). if more than one key must be disclosed during a time interval, then the TTP can specify it in the certificates. The value of d may be specified by the TTP and sent to entities at the initialization phase.
In the described embodiment an entity does not need to verify the validity of the certificate by obtaining updated revocation status information. Indeed, if the value s is well protected - this could, for example, be based on a password or pass-phrase, and only stored in the machine for the brief period necessary to generate K_i , for some i- only the client that knows s is able to generate the key K _m-i-1 valid in interval T_i as well as the corresponding public key g^Km -1-i. Since K _m-i-1 is generated with elements of the client's one-way hash chain that have not been published in another time period, and since one-way hash chains are computationally hard to reverse, an attacker is not able to find K _m-i-1 from keys that the client used in the past. It is also computationally hard for an attacker to find K _m-i-1 from g^Km -1-i (see W. Diffie and M. Hellman. New Directions in Cryptography. In IEEE Transactions on Information Theory, Vol. IT-22, No. 6, pp. 644--654, 1976). For these reasons, only the legitimate owner of a certificate is able to generate a valid authenticated session key with a given server during a given time interval.
According to one embodiment certain optimizations in the public key verification process are possible if the server caches a trusted copy of a past public key for the client.
It will be understood by the skilled person that the embodiments described hereinbefore may be implemented by hardware, by software, or by a combination of software and hardware. The modules and functions described in connection with embodiments of the invention may be as a whole or in part implemented by microprocessors or computers which are suitably programmed such as to act in accordance with the methods explained in connection with embodiments of the invention. An apparatus implementing an embodiment of the invention may e.g. comprise a node or element in a network which is suitably programmed such that it is able to carry out an authentication as described in the embodiments of the invention.
According to an embodiment of the invention there is provided a computer program, either stored in a data carrier or in some other way embodied by some physical means such as a recording medium or a transmission link which when being executed on a computer enables the computer to operate in accordance with the embodiments of the invention described hereinbefore.
Embodiments of the invention may be implemented e.g. by nodes in a network or any entities in a network which are programmed to operate in accordance with the authentication mechanisms as described before.

Claims

A method for authenticating a client or first node towards a server or second node, said method comprising:
obtaining a secret key s by said client node and using it to generate a one-way hash chain which is bound to the identity of said client node through a unique hash-code value contained in a certificate;

deriving a number of m public/private key pairs, m being an integer, by said first node using said one-way hash chain of said first node, said public/private key pairs being bound to one another and to the hash-code value contained in said client node's certificate;

sending by said client node one of its generated public keys along with its certificate to said server node;

authenticating said first node by said second node by verifying that the disclosed public key is bound to the hash-code value contained in said client node's certificate.
The method of claim 1, wherein said public/private key pairs are bound to each other by each of said public/private key pairs being generated based on a first one-way hash chain which is generated based on said secret key s using a first hash function, and said method comprises:
sending one or more elements of the same hash chain on which said public key is based from said client to said server.
The method of claim 1 or 2, wherein said public/private key pairs are bound to said unique hash-code value by applying a second hash function to said hash chain.
The method of one of the preceding claims, wherein
said hash-code value is bound to the identity of said client contained in said client's node certificate through a signature generated using the private key of a trusted third party.
The method of one of claims 1 to 4, said method comprising:
an initialization phase during which said client node is connected to a trusted third party and an authentication phase during which no connection to a trusted third party is necessary, whereas said initialization phase comprises:
synchronizing the clock of the client with the one of the trusted third party;

deriving a check value $v = h (g^{\prod_{j = 0}^{m} f^{j} (s)}),$
whereas f is said first cryptographic one-way hash function, h is said second one way hash function;

requesting from said trusted third party a certificate which binds the identity of said client to said check value, said certificate containing a reference time value;

dividing time into m equal intervals of length L, and assigning a respectively different key generated with elements from said client's one-way hash chain to each of said intervals, said one-way hash chain being generated based on repeatedly applying said hash function ƒ to s whereas

said client node uses in a time interval T_i , 0 ≦ i < m as private key $K_{m - 1 - i} = \prod_{j = 0}^{m - i - 1} f^{j} (s),$
and as corresponding public key g ^{K m-1-i} , said method further comprising an authentication phase comprises:
sending said check value from said client to said server;

sending the public key g^Kw = g^Km-1-i assigned to the present time interval from said client to said server;

sending ƒ ^w+1(s) = f^m-i (s) and said certificate from said client to said server;

and using these values by said server node which then computes: $\begin{array}{l} v^{*} & = {(g^{K_{w}})}^{\prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{w} f^{j} (s) \prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{m} f^{j} (s)} . \end{array}$
for verifying the identity of said client node by checking that v = h(v*).
The method of claim 5, wherein G=(G,*) is a finite cyclic group of order q, g ∈ G is a generator of G, and f is a cryptographic one-way hash-function mapping the set {0,1,...,q-1} onto itself.
The method of one of the preceding claims, wherein said initialization comprises:
distributing to said server node one or more of G, g, ƒ, m, the trusted third party's public key K_TTP and h being a one way hash function;

and for the client node which wishes to prove its identity, calculating said check value accordingly and a certificate according to ${[ID, v, t_{0}, L]}_{K_{TTP}^{- 1}},$
whereas ID is the identifier of said node, t ₀ is a reference time or the issuing time of the certificate, L defines the length time interval for which a public/private key pair is valid, and ${[\dots]}_{K_{TTP}^{- 1}}$
is the signature generated by the trusted third party with its private key $K_{TTP}^{- 1}$
on the fields of the certificate.
The method of one of claims 2 to 7, wherein
a clock drift is taken into account by defining a maximum clock drift between synchronized clocks and further whether more than one key may be disclosed during authentication to take into account a possible clock drift.
The method of one of the preceding claims, said method comprising:
authenticating said server node towards said client node in the same manner as said client node was authenticated towards said server node.
The method of claim 9, further comprising:
establishing a session key between said client node and said server node by computing: SK = (g^Kw ) ^Ky =(g^Ky ) ^Kw , where g^Kw is the public key sent from said client to said server and K_y is the said server's private key and g^Ky is the public key sent from said server to sa id client and K_w is the said client's private key.
An apparatus for authenticating a client or first node towards a server or second node in an ad-hoc network, said apparatus comprising:
a module for obtaining a secret key s by said client node and using it to generate a one-way hash chain which is bound to the identity of said client node through a unique hash-code value contained in a certificate:

a module for deriving a number of m public/private key pairs, m being an integer, by said first node using said one-way hash chain of said first node, said public/private key pairs being bound to one another and to the hash-code value contained in said client node's certificate:

a module for sending by said client node one of its generated public keys along with its certificate to said server node;

a module for authenticating said first node by said second node by verifying that the disclosed public key is bound to the hash-code value contained in said client node's certificate.
The apparatus of claim 11, wherein said public/private key pairs are bound to each other by each of said public/private key pairs being generated based on a first one-way hash chain which is generated based on said secret key s using a first one way hash function, and said apparatus comprises:
a module for sending one or more elements of the same hash chain on which said public key is based from said client to said server.
The apparatus of claim 11 or 12, wherein said public/private key pairs are bound to said unique hash-code value by applying a second hash function on said hash chain.
The apparatus of one of claims 11 to 13, wherein
said hash-code value is bound to the identity of said client contained in said client node's certificate through a signature generated musing the private key of a trusted third party.
The apparatus of one of claims 11 to 14, said apparatus comprising:
an initialization module for executing an initialization during which said client node is connected to a trusted third party and an authentication phase during which no connection to a trusted third party is necessary, whereas said an initialization comprises:
synchronizing the clock of the client with the one of the trusted third party;

deriving a check value $v = h (g^{\prod_{j = 0}^{m} f^{j} (s)}),$
whereas f is said first cryptographic one-way hash function and h is said second one way hash function;

requesting from said trusted third party a certificate which binds the identity of said client to said check value, said certificate containing a reference time value;

dividing time into m equal intervals of length L, and assigning a respectively different key generated with elements from said client's one-way hash chain to each of said intervals, said one-way hash chain being generated based on repeatedly applying said hash function ƒ to s , whereas

said client node uses in a time interval T_i , 0 ≤ i < m as private key $K_{m - 1 - i} = \prod_{j = 0}^{m - i - 1} f^{j} (s),$
and as corresponding public key g ^{K m-1-i}, said apparatus further comprising an authentication module which comprises:
a module for sending said check value from said client to said server;

a module for sending the public key g^Kw = g ^{K m-1-i} assigned to the present time interval from said client to said server;

a module for sending f ^w+1 (s) = f^m-i (s) and said certificate from said client to said server;

and a module for using these values by said server node which then computes: $\begin{array}{l} v^{*} & = {(g^{K_{w}})}^{\prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{w} f^{j} (s) \prod_{j = w + 1}^{m} f^{j} (s)} \\ = g^{\prod_{j = 0}^{m} f^{j} (s)} . \end{array}$
for verifying the identity of said client node by checking that v = h(v*)
The apparatus of claim 15, wherein G=(G,*) is a finite cyclic group of order q, g ∈ G is a generator of G, and f is a cryptographic one-way hash-function mapping the set {0,1,..,q-1} onto itself.
The apparatus of one of claims 11 to 16, wherein said initialization comprises:
distributing to said server node one or more of G, g, ƒ, m, the trusted party's public key K_TTP and h being a one way hash function;

and for the client node which wishes to prove its identity, calculating said check value accordingly, and a certificate according to ${[ID, v, t_{0}, L]}_{K_{TTP}^{- 1}},$
whereas ID is the identifier of said node, t ₀ is a reference time or the issuing time of the certificate, L defines the length time interval for which a public/private key pair is chosen, and ${[\dots]}_{K_{TTP}^{- 1}}$
is the signature generated by the trusted third party with its private key $K_{TTP}^{- 1}$
on the fields of the certificate.
The apparatus of one of claims 11 to 17, further comprising
a module for taking into account a clock drift by defining a maximum clock drift between synchronized clocks and further whether more than one key may be disclosed during authentication to take into account a possible clock drift.
The apparatus of one of claims 11 to 18, further comprising:
a module for authenticating said server node towards said client node in the same manner as said client node was authenticated towards said server node.
The apparatus of claim 19, further comprising:
a module for establishing a session key between said client node and said server node by computing: SK= (g^Kw ) ^Ky = (g^Ky ) ^Kw, whereas g^Kw is the public key sent from said client to said server and K_y is the said server's private key and g^Ky is the public key sent from said server to said client and K_w is the said client's private key.
A computer program for performing authentication in ad hoc networks, said computer program comprising computer program code which when being executed on a computer enables said computer to carry out the method of one of claims 1 to 10.