With this second improvement, we want to give the entities the ability to know exactly why a registration does not complete. This additional requirement will introduce complexity in the protocol. The simplification described in 4.6.1 brought us in the opposite direction but now we can build our strategy on solid bases.
In our specification, the special events only happened when neither the user
nor the TTP meet an erroneous message otherwise, they declare an error and stop
the protocol. By adding cryptographic operations and checks to the processing
of the messages, we reduce the cases where a special event can take place. The
model of our user owns valid credentials and always performs a correct
registration but he still declares failures with USER_REG_FAILED events.
This behaviour can only result from intruder's actions and shows that the user
cannot completely distinguish errors from failures. In other words, some errors
are interpreted as failures. Normally, the user must never meet a failure with
our assumptions, meaning that the user's registration must always finish with a
positive answer from the TTP or an error. The figure 7 exhibits a
scenario that leads to such a failure with the simplified version of the protocol.
The user starts his registration and the protocol progresses normally until the intruder replaces the register response message of the user with another one. This new message is wrong because the intruder does not own credentials the TTP is waiting for and thus, a failure is declared and the TTP sends a negative acknowledgement. The user also declares a failure upon its reception.
This scenario is not related to the authentication properties of safety we have previously verified. The TTP refuses to authenticate the user due to an intruder's action but is not authenticating the user incorrectly. The reason of the failure is linked to the integrity of the messages transmitted during the protocol. In this particular case, the register response message has been changed by the intruder.
To achieve the user's distinction of errors from failures, we will strengthen the requirements on the protocol and add a new property.
or expressed with special events:
USER_REG_FAILED event is allowed in the LTS of the system.
From the point of view of the TTP, he would also make a
complete distinction between failures and errors if he never declares a
failure of the user because the user always tries to perform a valid registration.
All disturbing elements must come from the intruder and must lead to
errors (or possibly to a TTP_REG_FAILED with the intruder's
identity). We model this case with another new property called P7 that does
not allow the TTP to refuse to register the user. Formally, no
TTP_REG_FAILED event with the user's identity (TTP_REG_FAILED !USERID_A) is permitted in the LTS of the system.
We check for the presence of USER_REG_FAILED and TTP_REG_FAILED !USERID_A events using the Exhibitor tool. If the verification does not find any
of these events, our new properties are satisfied. The simplest protocol cannot
guarantee P6 nor P7 because the parameters used in the GQ algorithm are not checked
before the GQ verification (see the previous scenario). So we propose a new
solution with two new signatures.
The main difficulty to solve comes from the GQ verification. The protocol must provide a way to find why the GQ calculation is not correct. If the problem is due to the use of bad credentials, the TTP must declare a failure, otherwise he must declare an error.
The signature of the register challenge message allows the user to verify that the data transmitted in the first message were correctly received. This could not be achieved by signing the register request because the TTP does not know the user's public key yet. If and only if the user agrees with the register challenge, he generates a response F(B ,d), signed with his private key. When the TTP receives this third message, he can use the recently received public key to check the signature. If the signature is incorrect, the TTP declares an error. Otherwise, if the result of the GQ computation is correct, that means that the user has received a valid register challenge message and thus agrees with the public key used in this message. Hence the TTP owns the real public key of the user. Both the GQ computation and the signature must be correct. One of them is not enough to make a good verification.
From the TTP's point of view, nothing distinguishes the received result of the function F from a random number before the GQ verification. So we have added the user's identity in the register response message to allow the TTP to check the user's signature.
With this version of the protocol the transmission of the user's public key does no longer need to be associated with the computations of the GQ verification. Our model of the GQ identification scheme states that the function F acts as a signature verified by the user's identity and the user's public key. In fact, this new version of the registration protocol can be used with a GQ algorithm in which B is only linked to user's identity and not to its public key. This is because the two new signatures in messages 2 and 3 allow the certification of the user's public key. This simplified GQ is in fact the original one [GQ88].
Property P6 is satisfied with this version. There is no possible
USER_REG_FAILED event. All the intruder's actions are detected by the
various checks involved in the cryptographic operations. Nevertheless, it was
not possible to suppress all the TTP_REG_FAILED events. Property P7
is thus not satisfied. Indeed, the complete removal of these events would imply a
kind of authentication before the authentication itself, and therefore constitutes an
unreachable goal. The figure 8 will further clarify
this. It exhibits a possible attack where the intruder replaces the user's
public key with its own. Without knowing the right user's public key before the
beginning of the registration, the TTP cannot detect the falsification.
