The present invention relates to a method and an apparatus for performing an authentication.

In computer networks, many services can only be provided if identities of nodes are guaranteed. This is the case for security services like access control or confidentiality. It is also the case for a more basic service like routing. If there is no solution to guarantee the correctness of a binding between an IP address and a node no routing protocol can guarantee the correct delivery of a message to the right destination. The required guarantees regarding nodes' identities are traditionally provided thanks to central administration authorities or dedicated entities. But such entities can not be found in every environment. This is particularly a problem in the field of ad-hoc networks. Since (mobile) ad-hoc networks are infrastructureless and self-organized, no central administration authority or dedicated entity can be found. This lack of administrative control has the effect that malicious behaviors that lead to a change of a network address can not be detected.

Network addresses are not the only kind of information that permits to identify nodes. Other identification information like PKCs (Public Key Certificates) or secret encryption keys can be used. However, in order to ensure that any entity actually is the entity it pretends to be, a process that permits to guarantee the correctness and the validity of the binding between identification information and an entity(a "node") in the network is needed, and such a process typically is referred to as entity authentication or authentication.

A particularly interesting field for authentication mechanisms are ad-hoc networks. They are interesting because they permit to increase the coverage area in which services are provided without relying on any infrastructure. This can permit mobile network providers to reduce their exploitation costs. In order to deploy the services they usually provide in their networks - like phone calls - mobile networks providers will have to offer the same guarantees - regarding the quality of the services they offer - in ad-hoc networks as in their traditional networks. This means that any customer in an ad-hoc network should have the ability to call someone and to be sure that the network will establish a connection with the right callee. It also means e.g. that when an MMS (Multimedia Messaging Service) will be sent by a customer that is in an ad-hoc network, it will be required to guarantee that the message will be delivered at the right destination. These examples highlight the fact that routing, which is one of the most basic services that permits a network to work properly, needs identities of nodes to be guaranteed in order to deliver messages to the right destinations. Therefore no service can efficiently be deployed in ad-hoc networks if the identity of nodes is not guaranteed.

Accordingly for ad-hoc networks there is a strong need for verifying the identity of a node. However, entity authentication is a problem in ad-hoc networks because the fact that nodes often not know each other implies that they may not share a common secret. Therefore traditional authentication solutions based on secret key mechanisms which rely on the fact that two entities share a secret cannot be used. The only way to permit two nodes that share no common knowledge to authenticate is to use public key based mechanisms. But when public key based authentication mechanisms are used like those that rely on PKCs (Public Key Certificates) there is no way to guarantee the validity of these certificates. This is because there is the fundamental problem that there is no way of obtaining the required up to date revocation information in an ad-hoc network as will be explained in the following.

When a certificate is issued it is expected to be in use for its entire validity period. But various circumstances may cause a certificate to become invalid prior to the expiration of its validity period like: a change of name, a compromise or a suspected compromise of the corresponding private key. Many reasons can lead to the compromise of the private key like its loss or its disclosure. When this happens a certificate has to be revoked. This is traditionally made thanks to revocation mechanisms that rely on central authorities - like certification authorities (CAs), OCSP responders or repositories - in order to enable the nodes of the network to identify the public keys which must not be used anymore because they are not anymore associated with their legitimate owners. This is the reason why revocation mechanisms are required whenever certificates are used.

However, since existing revocation solutions rely on central entities -while ad-hoc networks are infrastructureless and have no central entity - the traditional approaches cannot be used in ad-hoc networks. Therefore it is required to provide a mechanism that will permit to guarantee that a certificate used in an ad-hoc network is used by its legitimate owner.

As mentioned, the fact that nodes may not access to a online third party (TTP) and may not know each other imply that they may not share a common secret which makes a shared secret inappropriate for authentication. However, also the use of public key mechanisms for authentication in ad-hoc networks poses problems. The difficulty to define public key authentication mechanisms adapted to ad-hoc networks comes from the risk of compromise of public/private key pairs. Since this kind of key pairs can be compromised they can be used by other nodes than their legitimate owners. Therefore, when it is not possible to know the revocation status of a public/private key, giving the proof that the private key associated to a public key is known does not always permit to identify the legitimate owner of a public/private key pair. This shows the limits of the solutions generally used to provide node authentication.

When a key is compromised a node that has to perform authentication is not able to make the difference between the real owner of a certificate and an attacker.

Accordingly, there is a need for providing an authentication method which overcomes the deficiencies of the conventional methods.

According to one embodiment there is followed an approach based on associating to public (non-secret) information m_p contained in a certificate some public information S_P which, however, is based on m_p and a secret key x_p only known by the legitimate owner of the certificate and the issuer of the certificate and which has been calculated in a manner which does not disclose x_p. That way by a computer-implemented method of verifying in a communications network the identity of a proving node P by a verifying node V to verify said node P as the legitimate owner of a public key certificate C, said method comprising:

• proving by said node P to said verifying node V that node P knows the secret key x_p without disclosing x_p, whereas:
• said secret key x_p is a secret knowledge shared by said node P and a certification authority CA which has issued said certificate C to node P,
• said certificate C which has been issued to P by said certification authority comprises :
  • the public key of said proving node;
  • one or more non-secret elements m_p identifying the identity of the owner of the certificate to which said certificate C was issued and the certification authority,
  • a non-secret value S_P which has been generated using a cryptographic method based on said secret value x_p and one or more other non-secret elements m_p of said certificate C in such a manner that the thus generated value S_P is based on but does not disclose x_p , said a non-secret value S_P being a signature of one or more other non-secret elements m_p of said certificate, said signature having been generated based on raising m_p to x_p ; and said certificate further comprising:
    • a signature which has been generated based on S_P and on one or more other non-secret elements of said certificate using the private key of said certification authority;

• choosing a random value a by said verifying node V and generating a challenge based on raising m_p to a or on raising S_P to a, said challenge being forwarded to node P;
• raising by node P said challenge to x_p if said challenge is based on m_p or to 1/x_p if said challenge is based on S_P and forwarding the result to node V as said proof; and
• verifying the identity of P by comparing the proof forwarded from node P to node V with a value calculated by node V through raising either S_P or m_p to a.

According to one embodiment there is followed an approach based on associating to public (non-secret) information m_p contained in a certificate some public information S_P which, however, is based on m_p and a secret key x_p only known by the legitimate owner of the certificate and the issuer of the certificate and which has been calculated in a manner which does not disclose x_p. That way by proving the knowledge of x_p without disclosing its actual value only the legitimate owner of the certificate will be identifiable.

To keep the method safe the information x_p to be kept secret and is never disclosed and only known by the owner of the certificate and the certification authority. This can be guaranteed e.g, by distributing the secret key in a secure manner and by storing that key on a tamper proof hardware or by requiring a password to be entered in order the key be generated and used by a mobile device. So according to one embodiment the mechanism may comprise:

• ■ A secret key x_p -that will never be disclosed - is distributed in a secure way by a CA CA₁ to a node P
• ■ that secret key x_p is associated to the certificate C that P received from CA₁ -in a way that does not expose x_p
• ■ a node V that will have to authenticate P will be sure that P is the legitimate owner of C and that C has not been revoked if P is able to prove him the knowledge of the secret key x_p without disclosing it.

Since the secret key will never be disclosed, even if the public/private key pair is compromised, only the legitimate owner of the certificate will be able to prove the knowledge of x_p and thus only P will be identified as the legitimate owner of the certificate and it will be possible to know that the public key/private key pair is still valid..

According to one embodiment said method is used for verifying that certificate C, used by a proving node P to prove its identity to a node V, has not been revoked, and for verifying the identity of node P even when no connectivity to a fixed network is available and for verifying that the public/private key pair associated to certificate C has not been compromised.

According to one embodiment said non-secret value S_p has been generated using a cryptographic function k as S_p = k (m_p, x_p), and said method comprises:

• generating a challenge f by said node V based on an arbitrary number a as $$\mathrm{f}\mathrm{=}\mathrm{f}\left(\mathrm{a}\mathrm{,}\mathrm{g}\left(m_p{x}_p\right)\right)$$
• and forwarding said challenge to node P;
• generating by said node P a proof R as $$\mathrm{R}\left(x_p,\mathrm{f}\left(\mathrm{a}\mathrm{,}\mathrm{g}\left(m_p{x}_p\right)\right)\right),$$

$$\mathrm{Rʹ}=\mathrm{Rʹ}\left(m_p{S}_p\mathrm{a}\right)$$

This makes it possible for the verifying node V to know that P's certificate has not been revoked and therefore to perform an authentication to verify P's identity even without knowing x_p.

According to one embodiment the authentication method comprises:

• receiving by said verifying node a message comprising said value S_P which has been calculated based on raising m_p to x_p;
• choosing a random value a by said verifying node and generating a challenge based on raising m_p to a or on raising S_p to a, said challenge being forwarded to node P;
• raising by node P said challenge to x_p if said challenge is based on m_p or to 1/x_p if said challenge is based on S_p and forwarding the result to node V; and
• verifying the identity of P by comparing the result forwarded from node P to node V with a value calculated by node V through raising either S_P or m_p to a.

The foregoing embodiment enables a node P that has received a secret key x_p from a certification authority CA to prove to a node V - it never met - that it shares the secret key x_p with CA without disclosing that secret key.

Thus the mechanism permits to identify the legitimate owner of a certificate even when the associated key pair has been compromised. Therefore it permits to know if a public/private key pair has been revoked. The mechanism is a secret key based mechanism based on secret key x_p which prevents other nodes than the legitimate owner of a certificate from using that certificate. As a result, the risk a node be impersonated by an attacker in an ad-hoc network or in any other network is negligible.

The mechanism guarantees that only the legitimate owner of a certificate will be identified as the legitimate owner of a public key even if his public/private key pair has been compromised. Moreover, it permits to avoid the use of a compromised key by an attacker. For these reasons, the solution permits to provide efficient entity authentication in ad-hoc networks.

According to one embodiment the method comprises: encrypting said challenge generated by node V with the public key of node P and forwarding said challenge to P in an encrypted manner;
decrypting the received encrypted challenge by node P using its private key.

The usage of the encryption using the public/private key pair of P increases the security.

According to one embodiment the method comprises:

• adding to said challenge a value identifying verifying node V;
• forwarding said challenge including said added value to node P;
• encrypting said challenge including said added value by P using the private key of P and forwarding the thus encrypted challenge to node V.

The addition of a value identifying V makes it difficult to apply a replay attack because the intended verifying node has to cooperate in the procedure with its own unique identity.

According to one embodiment the added value comprises:

• a value S_V which has been generated using a cryptographic method based on secret value x_V shared by node V and a certification authority and one or more other non-secret elements m_V of a certificate C of node V in such a manner that the thus generated value S_V is based on but does not disclose x_V.

The value S_V uniquely identifies node V in the same manner as does S_P, and therefore is preferable over e.g. the public key of V which in principle could also be used but which may have been compromised and therefore is less preferable.

According to one embodiment the method comprises:

• adding a session identifier and/or a nonce to said message which is forwarded to V when presenting said value S_p to said node V;
• further adding an encrypted version of said message which is generated based on the private key of node P;
• adding a session identifier and/or a nonce to said challenge which is generated by node V and forwarded to node P;
• encrypting said challenge using the private key of node V;
• encrypting said challenge using the public key of node P.

The usage of session identifiers and/or nonces increases the security of the method.

According to one embodiment the method further comprises:

• adding session identifier sid_P and/or a nonce n_P to said message which is forwarded to V when presenting said value S_P to said node V;
• further adding an encrypted version of said message with the private key of node P;
• adding a session identifier sid_V and the said session identifier sid_P previously sent by P, to said S_V and to said challenge which is generated by node V;
• encrypting a first value comprising said challenge, said session identifier sid_v, said S_V, said nonce n_P that can be incremented by one and a nonce n_V, using the private key of node V;
• encrypting a second value comprising said challenge, said nonce n_P that can be incremented by one, said nonce n_v and said values val₁ encrypted with the private key of node V, using the public key of node P;
• forwarding of said sid_P, said Sid_V, said S_V and the said second value encrypted with the public key of node P
• encrypting a third value comprising said proof, said S_V, said value identifying node P, said nonce n_V that can be incremented by one, using the private key of node P;
• encrypting a fourth value comprising said value identifying node P, said nonce n_V that can be incremented by one and said third value encrypted with the private key of node P, using the public key of node V;
• forwarding said session identifiers sid_P and sid_V and said encrypted fourth values encrypted with the public key of node V to node V.

According to one embodiment there is provided a method of generating a certificate to be used to verify the identity of a node P in a network, said method comprising:

• distributing knowledge about a secret key χ_p between a certification authority and node P such that both share said knowledge,
• calculating a non-secret value S_P in such a manner that said non- secret value S_P does not disclose secret key x_p;
• including said non- secret value S_P into a certificate issued to node P by said certification authority, and
• adding to said certificate a signature which is generated using the private key of said certification authority and which is based on said non- secret value S_p and on one or more further non-secret elements of said certificate.

A certificate generated by this method can be used for authentication even if the public/private key pair belonging to the owner of the certificate has been compromised.

According to one embodiment said certificate C comprises:

• one or more non-secret elements identifying the identity of the owner of the certificate to which said certificate C was issued and the certification authority,
• said non-secret element S_P, and
• a signature which has been generated based on S_P and one or more of said other non-secret elements using the private key of said certification authority.

The certificate in this manner may be a standard certificate including all typical elements like name of the owner, issuer, the owner's public key, an expiration date, etc., however it further includes the public value S_P generated based on secret key x_p. Preferably it further includes a signature over one or more of these elements including the value S_P generated using the private key of the certification authority.

According to one embodiment said a non-secret value S_P is calculated based on raising m_p to x_p. This enables a proof of the knowledge of x_p by P without disclosing it by making use of a challenge raising S_P or m_p to a which is an arbitrary value chosen by V.

According to one embodiment in addition to its knowledge of secret key x_p node P has knowledge of a public key e_p corresponding to secret key x_p whereas, however, e_p is kept secret by node P unless a revocation request becomes necessary to enable node P to issue a revocation request if necessary based on said public key e_p. This provides the possibility for node P to issue a revocation request if necessary.

According to one embodiment there is provided a method of revoking a certificate which has been generated and issued to a node P according to the method of one of the embodiments of the invention, said method of revoking comprising:

• generating and disclosing a message comprising S_p and secret key x_p or its corresponding public key, and a signature of said message which has been generated using the private key of node P.

This enables the node P to revoke the certificate and further enables the other nodes of the network to verify the authenticity of the revocation request.

According to one embodiment the method comprises: regularly exchanging revocation messages between nodes of the network.

This keeps the nodes of the network up-to-date about any certificates which may have been revoked.

• Fig. 1A schematically illustrates an embodiment of the invention.
• Fig. 1B schematically illustrates a further embodiment of the invention.
• Fig. 2 schematically illustrates a certificate according to an embodiment of the invention.
• Fig. 3 schematically illustrates the operation of an embodiment of the invention.
• Fig. 4 schematically illustrates the operation of a further embodiment of the invention.

The invention will now be described in detail in the following by means of exemplary embodiments.

According to one embodiment the node P is to prove its identity to a verifying node V. For that purpose the node P makes use of a certificate which has been issued to it by certification authority CA. Fig. 1A schematically illustrates the relationship between the participants and the operation of an embodiment of the invention.

CA and P share a common secret x_p. This secret key x_p may have been distributed by CA to P through a secure channel, or P may have chosen it on its own and CA has approved it. In addition to this shared secret x_p P has been issued a certificate C by CA, and this certificate - in addition to having associated with it a public/private key pair owned by P has associated with it a value S_P which albeit being public has been generated based on secret key x_p. This means that S_p implicitly involves some knowledge about x_p, however, this "knowledge" remains implicit because S_P has been generated in such a manner that it is computationally infeasible to deduce x_p from S_P.

Nevertheless, public value S_P and the secret value x_p which is an additional secret owned by P in addition to the private key belonging to its certificate are then used to authenticate P towards V. For that purpose P proves to node V that it knows secret key x_p without disclosing it. Thereby the identity proof becomes independent of the public/private key pair owned by P and still works even if this key pair has been compromised.

In connection with Fig. 2A there will now be explained a further embodiment of the invention.

As can be seen from Fig. 1A, the non-secret value S_P is based on a cryptographic function k which is defined as S_p = k (m_p, x_p).

In order to prove the knowledge of x_p by V at first V sends a challenge f to P which is calculated based on f (a, g(m_p, x_p)). a here is an arbitrary number, e.g. a random number, which is chosen by V and known only to V. The function g may be identical to the function k, in this case the challenge takes the form f (a, S_P).

However the function g may also be different from k and may e.g. take the form g(m_p) without having involved even an implicit knowledge of x_p when generating challenge f. However, node V has some implicit knowledge about x_p because it knows S_P which is publicly available, e.g. through the certificate owned by node P or through some other source since S_P is public and not secret.

Based on the challenge f then node P calculates a proof value R as $$\mathrm{R}=\mathrm{R}\left(x_p,\mathrm{f}\left(\mathrm{a}\mathrm{,}\mathrm{g}\left(m_p{x}_p\right)\right)\right)$$

This proof is then forwarded to node V which then in turn verifies the proof by recalculating the proof value based on its knowledge about a, m_p and S_P as a value $$\mathrm{Rʹ}=\mathrm{Rʹ}\left(m_p{S}_p\mathrm{a}\right)$$

If the proof R and the recalculated proof value R' coincide, the authentication has been successfully performed.

In the following embodiment it will be explained in somewhat more detail how node V can verify that node P actually knows x_p despite node V doesn't know it. To clear the terminology used in the following description, the term n will denote a large number n. All values transmitted between the participants are sent modulo n . Here n may be defined like in the RSA cryptosystem described in R.L. Rivest, A. Shamir, and L.M. Adleman, A method for obtaining digital signatures and public-key cryptosystems, Communications of the ACM (2) 21 (1978), Page(s):120-126.

However, it should already now be mentioned that the following description is not limited to RSA cryptosystems but other cryptosystems may be employed as well.

For that purpose according to one embodiment there is used the mechanism of digital signature. This choice is explained by the fact that a digital signature is considered to not expose the private key used to generate it to compromise - through breaking- if the requirements regarding parameters like the hash function used, the private key length etc. are met.

In the rest of the document S = m ^xp mod n is considered to denote the digital signature generated on a message m with the secret key x_p

It should further be noted that if in the following reference is made to a hash function it intends to refer to a function which when applied to a given starting value returns a resulting hash value based on which the starting value cannot be deduced. The feature that the hash-function should be collision-free which is a requirement for hash-functions used for generating database keys, however, is for the present application of less importance and not mandatory.

In this embodiment a certificate traditionally used in PKIs, such as e.g. the X.509 certificate described in R. Housley, W. Polk, W. Ford, and D. Solo, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, RFC 3280, April 2002.is somewhat modified. In the new format, the certificate C that certification authority CA₁ issues to P contains one or more extra elements which are e.g. a digital signature $S_p=m_p^{x_p}$ mod n that is generated on the message m_P with the secret key x_p - that P shares with CA₁- and the value n used to generate that signature. The certificate format is schematically illustrated in Figure 2. The most important element thereby is the digital signature S_p which distinguishes it from known certificates and which enables the operation of the embodiment of the invention.

Here m_P represents a message generated with the fields that precede S_P in P's certificate. It should be mentioned here m_P does not need to include all the fields preceding S_P, it is sufficient if it includes one of the public information elements in the certificate. Since this information is public any node is then able to generate m_p. The only requirement is that the public information elements used to generate m_p can be easily identified. However, S_P is generated by CA₁ (or P) and actually can only be generated by one of these entities because only they know χ_p

It should be noted here that S_p not necessarily has to be included in the certificate, it is sufficient if it is "associated" with the certificate such that any interested entity can obtain S_p and can identify it as the value S_p belonging to the certificate C.

Since the certificate is signed by CA₁ using its own private key, any node V that will have to verify the authenticity of the certificate will have the confidence that S_p has been generated by CA₁ or is valid as soon as CA₁'s signature on the certificate will be correct.

According to one embodiment this new certificate is used in order to provide entity authentication. The embodiment permits a node P - the prover - to prove to a node V- that is the verifier and that P may have never met - that it knows the secret key x_p used to generate the signature $S_P=m_P^{x_P}$ mod n associated to the public key certificate C without disclosing x_p. This permits V to identify P as the legitimate owner of C.

A known mechanism to verify that node P knows the secret key used to generate a signature would be the traditional check of the validity of a signature with the public key associated to the private key that was used to generate that signature

However, since the private key associated with a public key can be compromised, checking the validity of the signature $S_P=m_P^{x_P}$ mod n with the right public key will not permit to be sure that the owner of the private key which corresponds to that public key is the one that initially received the secret key x_p from the CA.

In particular it can be seen that the traditional proof based signature verification using a public/private key pair requires revocation mechanisms to be used because these keys can be compromised. Therefore, using these solutions will make us enter a circle: signatures are added in certificates to perform revocation and revocation is required to check these signatures. This is why the approach according to an embodiment of the invention does not rely on public key mechanisms. Instead there is chosen to use secret key mechanisms to check the validity of the signature S_p on P's certificate. If P's secret key is securely stored in a tamper proof hardware like the SIM card used in GSM or is not directly stored in the mobile device but generated after a password is enter by the user it can be assumed that it does not require to be revoked.

Therefore a different approach is used which will be explained in the following.

Fig 3 schematically illustrates the operation of an authentication method according to this embodiment.

Before explaining in detail the operation of the embodiment shown in Fig. 3, the terminology used therein is explained in the following.

• Cert_P : P's public key certificate
• K_P : P's public key
• {m}_KP : encryption of the message m with P's public key
• ${{\mathit{Sig}}_{K_P^{-1}}}^{\left\{x_1{x}_2\dots x_n\right\}}$: signature generated with P's private key on the message composed of the elements x₁, x₂,..., x_n.
• $m_v^{x_v}$:The signature generated by CA₁ on V's certificate with the secret key x_v that CA₁ shares with V

At message (1) P sends its certificate in order to launch the authentication process.

It should be mentioned that instead of sending the (full) certificate P may also only send S_P. As still another an alternative the node P may send any message indicating that the authentication procedure should start, and then node V receives somehow S_P. This can also be achieved by having S_p actively retrieved though node V from some database where it is stored. What should, however, be the result of step (1) is that node V finally has received S_p and thereby has received "implicit" knowledge about secret key x_p which is explicitly known only by node P and CA.

Assuming now that in message (1) V has received the full certificate of node V. When receiving the message (1), V preferably checks the validity of the CA's signature - present in the received certificate. If it is correct, it selects a random value a, generates a challenge by raising m_p - that it will have previously composed thanks to P's certificate- to a and obtains $m_p^a$ Then V sends that challenge along with its certificate to P as message (2). Instead of sending the full certificate V may also just send $m_v^{x_v}$ Preferably the challenge is encrypted with P's public key. After it has received the message (2) and if it has been encrypted, P decrypts the challenge with its private key. Once the decryption done, P uses its secret key to raise the challenge to x_p and obtains ${\left(m_P^a\right)}^{x_P}$

Then it uses the result, $m_v^{x_v}$ - this element is taken from V's certificate - and its private key $K_P^{-1}$ to generate a signature. That signature is sent to V as message (3). When V receives the message (3), it uses $m_p^{x_p}$ present in P's certificate, raises it to a and obtains a result $R={\left(m_P^{x_P}\right)}^a={\left(m_P^a\right)}^{x_P}$. Then V uses the value $m_v^{x_v}$ - that is in its certificate - and R to generate a hash that it will compare to the one obtained by decrypting the received signature with P's public key K_P. If the compared values are identical then, V will have the confidence that it is the entity that received x_P from CA₁ -i.e. the legitimate P- that generated the proof. This will further permit V to know that the certificate has not been revoked and to identify P. Since to check the validity of the proof sent by P, the verifier has to verify the validity of the hash used for the signature, no node except the one that generated the random value α is able to check the correctness of the proof. Here the non-reversible property of one way hash functions is used. Moreover, since $m_v^{x_v}$ -that is used here to identify the verifier- is used to generate the signature, it will not be possible to replay the proof to another node than V.

It should be mentioned that here there is used $m_v^{x_v}$ and not V's public key because the fact that public/private key pairs can be compromised makes that using a public key will not always permit to identify one unique entity. However, since only the legitimate V knows the x_v associated to $m_v^{x_v}$ one can be sure that only the legitimate entity will be identified with it. So it will only be possible to replay the proof to the legitimate V.

A difference between the solution according to this embodiment and any previous approach is that while these approaches wanted to prove that a signature and a public key have a common exponent - the private key- in the present embodiment it is only necessary to verify that a signature generated by the CA has been generated with an exponent whose value is known by the prover. This makes it possible to transform the initial public key based approach into a secret key based approach. Another difference comes from the fact that in the present embodiment, the whole proof is only accessible to the verifier through a hash generated thanks to a one way hash function. Since they are non-reversible, the secret that the prover shares with the CA can not be computed by the verifier.

In the following there will be explained in connection with Fig. 4 a further embodiment of the invention.

The Figure 4 schematically presents an even more robust version of an authentication method. Here there is used the same notation than previously used, but there are added:

• ■ sid_P, sid_v : the session identifiers chosen by each party for the on going authentication process
• ■ n_P,n_v : nonces used to guarantee the freshness of the messages

The signature is used here in order to link the knowledge of the private key associated with a public key to the knowledge of a secret key shared with a CA. This permits to be sure that the node that currently uses the private key associated to a public key is the one that received the secret key from the CA and therefore it is the legitimate owner of the certificate.

In connection with this embodiment the following should be noted:

• ■ Mutual authentication can be provided by adding a challenge that P will send to V at message (3) and that V will respond in a message (4).
• ■ Even in case of compromise of the public/private key pair associated with the certificate only the legitimate owner of the certificate will be authenticated as the legitimate owner of the key pair.

In order to take into account the specific circumstances arising in the case of ad-hoc networks, according to one embodiment there is provided an efficient revocation mechanism.

In this embodiment, revocation can be provided by the legitimate owner of a certificate by sending the following request: $${\mathit{Cert}}_{\mathit{P}}\mathit{,}{\mathit{e}}_{\mathit{P}}\mathit{,}{}_{{\mathit{Sig}}_{{\mathit{K}}_{\mathit{P}}^{-1}}}\left\{{\mathit{Cert}}_{\mathit{P}}{\mathit{e}}_{\mathit{p}}\right\}$$

This request will be sent to all nodes in the network. Edge nodes or gateways may also distribute it to neighboring networks so that the knowledge about revoked certificates will be efficiently distributed.

Revocation in this embodiment is made by disclosing the public key e_p - like e.g. the one defined in the RSA cryptosystem mentioned already - associated to the secret key x_p. Since x_p is never disclosed, only the node that received it from the CA is able to publish a valid public key that permits to verify $S_p=m_p^{x_p}$. By receiving the request, nodes will check the correctness of the received signature with P's public key- contained in P's certificate- and then check the validity of S_p with e_p. Thereby they can verify the authenticity of the revocation request.

If all the verifications are correct then nodes will have the confidence that the request was sent by the legitimate owner of the certificate. They will consider that P's certificate is not valid anymore and put it in their revocation list. Once a certificate is in a revocation list the public key associated to it is not used anymore.

According to one embodiment the revocation solution can be enriched by a regular exchange of revocation information between nodes. This permits new members of the ad-hoc network to obtain information about certificates that have been revoked before they entry in the network. It will also permit newly arrived nodes to inform the ad-hoc network about keys that have been revoked in their previous networks. After a node has revoked its certificate it will have to use a new one. So each node will have to store more than one certificate.

According to another embodiment a way to perform revocation could be to disclose x_p. This solution, however, is less preferable because then an attacker N will be able to leave the network after the disclosure of the secret key and to use it in another network to impersonate the emitter of the revocation request.

The interesting point when e_P is disclosed is that it does not directly expose the secret key to compromise. To be able to generate a valid proof N would have to break e_P - i.e. to find x_p from e_P. Since modern cryptography relies on the difficulty to find a private key from the corresponding public key the risk a public key be broken is almost negligible.

This revocation solution permits the whole network to know which key has to be considered invalid and also guarantees that no node in the network will be impersonated by a node that will have compromised its public/private key pair. It also reduces significantly the risk of impersonation attack in a different network than the one of the legitimate owner of a certificate.

It will be apparent to the skilled person that modifications of the embodiments described hereinbefore are possible for the skilled person without deriving from the scope of the invention. In particular the following should be noted in connection with the present and previous embodiments and possible modifications.

So far it has been considered that the secret key x_p was distributed by a CA - here CA₁. This is not a necessity. Indeed, node P can choose by itself its secret key x_p. Then, during the certificate issuance process, P will present the signature $S_p=m_p^{x_p}$ mod n - that it will have generated by itself - to the CA and prove to it the knowledge of the corresponding secret key. The CA will then check that the signature is not used by another node. If it is not used, the CA will be able to generate a certificate. There may be further a check of the identity of P through some "classical means" like a passport or any "human identification" before the CA certifies by issuing the certificate that P indeed is P and not anybody else who pretends to be P.

Furthermore, the large number n used to generate the signatures can be different from a certificate to another one.

While in the foregoing embodiments mostly RSA has been chosen as an example, it should be noted that the embodiments of the invention can also be implemented with different cryptosystems.

In the authentication methods described before in connection with Fig.3, it is possible to send in the message (2) the challenge $m_P^{x_P*a}$ instead of sending $m_p^a$.

The proof sent at message (3) will then be: ${\mathit{Sig}}_{{\mathit{K}}_{\mathit{p}}^{-1}}\left\{{\mathit{m}}_{\mathit{p}}^{\mathit{a}}{\mathit{m}}_{\mathit{V}}^{{\mathit{x}}_{\mathit{V}}}\right\}$
The same modification can be made in the complete version of the protocol defined in Figure 4. This also permits to identify the node P.

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 described in connections 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.

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.