![](bg2.png)
powered and operational device. To protect the crit-
ical data on the phone from unauthorized access, the
user has to authenticate herself to the phone before
usage, and it has to be locked afterwards.
On the other hand smartphone usage typically
consists of short but frequent sessions. As a conse-
quence, the chosen user authentication method has
a large impact on the usability of smartphones. For
many users, the speed and ease of use of the available
methods are important factors in deciding whether au-
thentication is enabled or not (D¨orflinger et al., 2010).
Finally, due to the high mobility of these devices,
they will often be used in insecure places with a great
number of potential observers. An easy and user-
friendly approach to authentication requires the secu-
rity of the authentication method to be independent of
the environment the phone is used in.
Based on the characteristics described above, the
following requirements for authentication on smart-
phones can be defined:
• The user has to authenticate before each session
• A passing observer should learn next to nothing
about the secret used for authentication
• User effort has to be minimal, authentication
should be fast and secure
The authentication methods currently available on
smartphones are not able to meet all of these require-
ments.
The most common method is PIN/Password au-
thentication. It requires time-consuming user inter-
action (always typing in the password when unlock-
ing the phone), hence the typical user is very likely to
choose easy to type, short passwords/PINs, and is not
secure when used publicly in crowded places.
The alternative to the password-based approach,
graphical patterns, benefit from faster input, but are
even easier to memorize by casual observers.
Biometric techniques like fingerprint scanning or
facial recognition are still not widely deployed and
can usually be circumvented by using a simple photo-
graph or fake fingerprints.
In contrast to these methods, the token-based au-
thentication approach described in the next section
covers all the requirements defined above.
3 THE PROPOSED METHOD
The proposed method uses a hardware token to au-
thenticate the user to the smartphone. When the token
is in range, no additional user interaction is required.
A service running on the smartphone handles the au-
thentication process. Therefore an authentication pro-
tocol as described in the next section is required. The
protocol has to take the limited resources of the to-
ken hardware into account. It is important to keep the
authentication process as fast and secure as possible,
with respect to the low computational power of the
MCU and the limited amount of energy available to
the token.
If the token is out of range, or is unable to commu-
nicate with the smartphone, the proposed method falls
back to the most commonly used password/PIN ap-
proach. Since this rarely happens during normal op-
erating conditions, the password can be chosen long
and secure without unduly affecting usability.
A successful token-based authentication causes no
user interaction at all. On the downside, the user has
to carry an additional piece of hardware with him. In
practice the token functionality could for example be
integrated with a USB memory stick and attached to a
keyring, resulting in a negligible extra burden for the
user.
An attacker now either has to acquire both, the
smartphone and the hardware token, or guess/know
the password, which can be chosen to be long, com-
plicated and secure, since it only has to be entered
when the token is not present.
4 THE AUTHENTICATION
PROTOCOL
The authentication protocol described in this paper
belongs to the class of challenge-response protocols.
They allow one party to gain assurance of the iden-
tity of another (Menezes et al., 2001). For the first
proof-of-concept we decided to implement our own
protocol, based on well-known primitives like Diffie-
Hellman, which also allows for periodic rekeying. As
future work we plan to also evaluate different exist-
ing challenge-response protocols for the suitability of
the constrained environment present in our usage sce-
nario. Our protocol consist of three phases:
Key Establishment. In this phase a shared secret is
generated. It is triggered by the user and is
based on the Diffie-Hellman key exchange proto-
col (Diffie and Hellman, 1976).
Authentication. This phase consists of a hash based
challenge-response protocol.
Rekeying. Periodical rekeying prevents brute force
attacks. After a given time or number of authenti-
cation attempts a new shared secret is generated.
DCNET2013-InternationalConferenceonDataCommunicationNetworking
52