![](bg3.png)
authentication scheme as a prototype for evaluation
and further studies. This implementation uses
ubiquitous cell phones as security tokens storing the
encrypted OTP list, similar to many commercially
available solutions.
The web-based authentication server and the
client software components were developed in the
the Java programming language, using the Java EE
and Java ME frameworks for the server-side and
cell-phone components, respectively. The service
server calls the authentication server by means of a
web service. The OTP list is generated by the
authentication server and encrypted using a strong
encryption algorithm, e.g. Twofish (Schneier et al.,
1998).
Since almost every business person today uses a
Java-enabled cell phone, this approach to 2FA a
does not require additional equipment for users, thus
creating no additional costs. Therefore, also some
commercially available 2FA solutions now offer a
cell phone-based software replacement of the smart
card.
3 SECURITY ANALYSIS
In the security analysis of the prototype
implementation for the described authentication
scheme, different typical attacks are considered (Lin,
2001).
Since the algorithm for generating the OTP lists
is not needed to be defined within the authentication
scheme and its implementation needs to reside only
on the authentication server and not the security
tokens, any known algorithm for generating a
sequence of random numbers may be used. It is also
possible to easily switch the generation scheme
regularly or to use different versions at the same
time. Therefore, assuming that always a state-of-the-
art algorithm is used, an intruder may not predict or
forge the OTP list.
E.g., the HMAC-based OTP algorithm (HOTP)
may be used (M'Raihi et al., 2005), which generates
OTP values by using keyed hashed message
authentication code (HMAC). With the HOTP
algorithm, the only thing that has to kept secret is the
so-called secret key (not necessarily identical with
the user's OTP list decryption key). Any iterative
cryptographic hash function could be used within the
HOTP algorithm. Since the proposed scheme allows
to use arbitrary secret keys and hash functions for
the OTP list generation, the difficulty of forgery and
prediction attacks is additionally increased. Thus,
the authentication scheme is resistant against these
attacks as well as an eavesdropping of the sequence
number send to the user during the authentication-
and-login phase.
If an intruder eavesdrops a valid authentication
message during the login process to the service
server, the attempt to perform a replay attack will
fail in the verification phase since every OTP is
invalidated by the authentication server after used
once. This is similar for all approaches using an
OTP.
However, a major security threat for the scheme
is the possible disclosure of the encrypted OTP list
from a user's security token. In case the security
token (i.e. a cell phone) is stolen or lost, and the user
realizes the loss, the stored list may easily be
invalidated on the authentication server and replaced
by a new one. However, if the user does not realize
the loss of the device or only the OTP list is copied
from the device, the list may be disclosed by an
offline password guessing attack. Although the
stored OTP list is encrypted using a strong
encrypting algorithm (e.g. Twofish), there is still the
danger that an intruder might decrypt it within its
period of validity. Depending on the length and the
strength of the used password, the encryption might
be broken by a password guessing attack. Thus, it is
important to use sufficiently strong passwords for
the OTP list encryption.
In the future, an interesting solution for this
might be the use of self-destructing digital data to
prevent copying of the list. E.g., the research project
Vanish (Geambasu et al., 2009), conducted by
University of Washington, intends to develop such a
digital data.
Additionally, the OTP lists should be exchanged
frequently. However, this increases the
administrative overhead of distributing the OTP lists
to the security tokens. Thus, a suitable automation
solution for this should be considered.
In summary, any solution implementing the
described 2FA scheme, following the stated open
design principles and fulfilling the above
requirements, in the authors' opinion is not less
secure than the frequently used OTP number
generation inside the security token.
4 CONCLUSIONS
In conclusion, we presented our opinion on how
2FA should be implemented using an open design
approach. We claimed that the recently reported
security issue once again demonstrated the
SECRYPT 2011 - International Conference on Security and Cryptography
420