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].
