Introduction -1.2

Whenever something is introduced, it is always given a formal definition which can define precisely what it aims to achieve, what are the goals and a formal overview of everything it is trying to solve. In cryptography, every protocol ought to have a formal definition which has its own benefits while using in the actual scenarios.

Formal definitions are good in their own way. They help define precisely what the protocol aims to achieve, what are the goals, a brief overview of how it fares when compared to other protocols, also gives information about the fact; which all protocols should be used to attain a required/expected iota of security. They, in fact, serve as the building blocks to a big system. They, most of the times are successful in giving us the complex mathematical proofs of security of a protocol so that the engineers working on that big system feel more confident in developing it.

As stated above, we have talked enough about the benefits of having a formal definition with us while developing a big system, but we should also take into account, where does the formal definitions lag?

First thing first, it cannot be guaranteed that the formal definition of a protocol will render into reality/actual world too as it can be a very complex exercise.

Any mismatch between the formal and real-world definition can result to unexpected attacks on protocols and maybe some privacy issues too. We will try to show how frail are formal definitions w.r.t. PAKE.

PAKE

 In order to set up mutual authentication, there needs to be some kind of information that must be shared as it will be impossible to interact. The simple thing to imagine can be an easy to remember password. PAKE allows authentication based on password key exchange.

Example- A user U is trying to login into his email account by entering his password, at this point; both the server and browser interact via a PAKE protocol to set up a session key based on what password the user has input but also ensuring that his password is not revealed anyhow. In a way, both server and browser prove that they have used the same key to authenticate the user and in case the PAKE protocol gets failed, the browser immediately alerts the user stating that the password which he has entered does not match with the one on the server.

This protocol is designed to facilitate 2 parties with mutual authentication that agree on a shared key with the help of public-key cryptography.

Password-based systems are easy to use and deploy as no real cryptographic infrastructure is required. However, the problem with them is lack of absolute security and further decimated by horrible (easy to remember) choice of passwords by users.

In recent times, PAKE protocols have been standardized by IEEE[IEE05] and because of that more and more systems have started using it, even web applications for that matter [ABC06].

Let us now discuss what things we take into consideration while defining PAKE protocols.

The formal definition of PAKE assumes that a perpetrator can attack and break any kind of protocol using full force, it takes into all permutations and combinations that attacker can use. The attacker can, for example, use a brute force dictionary attack where he keeps on guessing the passwords unless it matches with the actual password.

If we assume N as the pool or bucket of passwords and to be on a very simpler side of the story, let us say he chooses the passwords randomly in a uniform fashion. And if a perpetrator attempts a maximum of Q logins for any Q, then the possibility of perpetrator breaking into the system is at the max Q/N and we can assume our PAKE to be secure in such a case

Issue with existing formal definitions

As we already discussed about the contradictions between formal and real-world definitions of the protocols, PAKE is no different. Going by the formal definition, it is not well equipped/ready to give the expected iota of security that is required in real world scenarios.

Formal definitions take the concept of assumptions and probabilities into account which means the perpetrators can break the protocol after trying up to a stage when they are able to breach the system. On the other hand, real-world scenarios would like to have full control over the security no matter how many times it is being attacked. Each attempt should be unsuccessful.

In Ideal situation, a user's account should get blocked/locked once he tries a certain number of Q^* failed log-in attempts. To achieve security Є one would set Q^* = Є.N & deny every login request once Q ^* unsuccessful tries are attempted on someone’s account.

But our opinion differs in this regard. We say that the things explained above do not succeed each time especially on large scale systems and networks such as Web.

So, to summarise this case, the formal definitions are theoretical rather than practical. They just advise what kind of security we should have when a perpetrator tries to attack the system multiple times, but they never tell us how that security ought to be achieved.

1.2.1 Our Benefactions

Overview of our attacks.

 In chapter 4, we will try to rationalize the claims that we made in the last section. We will take 2 different attacks that basically allows a perpetrator to go beyond Q* tries even if an account is locked after Q* number of unsuccessful tries.

 Let us kick off the things with Time delay out attack. It is applicable to any PAKE protocol where server authenticates first. This is a very clever minded attack where the attacker will go on guessing the passwords but at the same time, he will ensure that user does nor get to know that the system is being attacked. The system will keep on running normally while being attacked. The attacker does so by aborting the protocol before sending the final message. Now, the point to stress here is that, even if the sessions which have been timed out are taken as unsuccessful attempts of login at the end but the catch here is the long delay before the failure. This delay allows the attacker to go beyond testing Q* passwords.

So, in a nutshell, the client should authenticate first and not the server. Those should be preferred over the server first PAKE protocols.

The second attack to discuss here is Synchronization-delay attack. This is applicable to both types of authentication (where client/server authenticates first). This type of attack assumes that, in the actual scenario, Implementation of PAKE protocol will be divided/distributed among multiple servers. Since it is distributed among multiple servers, all the accounts and password information must be available to all the servers so that the information is available every time and on an immediate basis. Due to this factor, there will be a marginal delay from the moment Q*th unsuccessful login attempt happens and as described above, this data is sent across to all server copies. Now, again this delay can be exploited to exceed the number of Q* logins.

Though, the latter attack has done a minimalistic impact looking at the history, but we will still discuss these attacks for below reasons.

Firstly, formal definitions generally capture precise bounds instead of approximations.

Secondly, formal definitions become inconsistent with practical use if the attacks are unaccounted. Last but not least, synchronization delay attacks can be used in big systems to the point of non-compliance with published password standards (chapter4).

Multi-domain attacks can be used to increase the effects of the 2 attacks we stated above. In Multi-domain attacks, the user has accounts with various distinct domains and uses the same password in all accounts. The maximum number of queries that can be used by the perpetrator is nQ (for n domains).

So, to summarise the benefactions, we will provide the analytical and experimental proofs to describe these attacks in chapter 4.

We will also issue a new definition of security as we have already discussed that there is a gap between formal and real-world definition. We will then analyze these attacks according to the new definition and will provide privacy enhancements. Last but not the least, we depict how will we apply these enhancements [ABC+06].