next up previous
Next: Procotol specification Up: An example of verification Previous: An example of verification

The registration protocol


The registration protocol involves a user who wants to access a multimedia service and a TTP that acts as a notary. The mutual authentication of the user and the TTP must be achieved by the protocol. The TTP must be sure that the claimed identity of the user is the right one and the user must be sure that he registers with the right TTP. The TTP must also receive the good user's public-key during the procotol to issue a corresponding public-key certificate needed for the subcription phase.

The authentication of the user by the TTP uses the Guillou-Quisquater (GQ) zero-knowledge identification scheme [GQ88]. Before registering, the user has received secret personal credentials derived from its real-life identity. These credentials will help him to prove who he is to the TTP but without revealing them. The authentication of the TTP by the user uses a challenge based on a nonce (i.e. a number used once). The user has also received the TTP's public-key to perform the required checks on the messages and to authenticate the TTP. The transmission of the user's public-key to the TTP is possible with an improved version of the GQ algorithm [LBQ96]. The registration protocol presented in this paper is, in fact, an enhanced version of the original one found in [LBQ96].

The GQ identification scheme is based on complex mathematical relations derived from the user's identity, the user's public-key and the secret credentials. It uses a random number issued by the TTP to challenge the user and a second random number issued by the user to scramble the public-key and protect the credentials. To specify the algorithm, we have designed an abstract model which is particulary simple while still capturing the essence of it. The key point of the authentication are the secret credentials. If we consider them as a secret encryption key and the user's identity together with its public key as a corresponding public decryption key, the GQ algorithm looks like an authentication scheme based on a nonce and works as follows. The user sends his public decryption key to the TTP and receives back a nonce as a challenge. Then he returns to the TTP the nonce encrypted by his encryption key. The TTP can then check that the nonce has been encrypted as expected. This scheme resists to the ``man-in-the-middle'' attack because the decryption key is mathematically linked to the user's identity.

In the remaining of this paper, we will present all the messages with the following structure:


A couple tex2html_wrap_inline820 will denote the pair of private/public keys of the principal A. Encryption of data will be written tex2html_wrap_inline826 while signature will be written tex2html_wrap_inline828. F(B, d) will represent the special encryption of the GQ model where B are the credentials.

The protocol works as follows:

The user generates a random nonce n and sends the message 1.


When the TTP receives message 1, he decrypts the nonce n and signs it, generates a random number d and sends them to the user. The TTP can handle several registrations at a time. So he maintains an internal table with one entry for each user who has a registration in progress and he records the tuple tex2html_wrap_inline842.


When the user receives message 2, he checks the signature. If the signature is correct, he performs the GQ calculation and sends the result to the TTP.


When the TTP receives message 3, he checks the GQ authentication using this message and the data found in his internal table. Then, he sends a response according to the result. The response is signed and includes both the user's identity and the nonce n. The user's entry in the internal table is deleted. If the response is positive, the TTP registers the tuple tex2html_wrap_inline850


next up previous
Next: Procotol specification Up: An example of verification Previous: An example of verification