The Mobile Phone as Authentication Token

IVAR JØRSTAD, DO VAN THANH

This paper provides a study of the various ways the mobile phone can be used as an authentication
token towards service providers on the Internet. It starts by discussing the need for a strong
authentication scheme and the motivation for using the mobile phone to improve on several aspects
of the current authentication processes. Then, the general architecture for authentication with mobile
phones is presented. Several different authentication solutions using the mobile phone as authentica-
tion token are then described, where the solutions vary in complexity, strength and user-friendliness.
Ivar Jørstad is The paper ends with an evaluation of the different solutions, and a discussion of the most probable
CEO of
attacks. A classification of the solutions is also provided, according to defined criteria.
Ubisafe AS

1 Introduction • Its widespread deployment (over 100 % market

A lot of value-added services on the Internet today
require authentication, i.e. the proper verification of
the user’s identity, before the user gets access to the
service itself. The most common authentication
Do Van Thanh is scheme which is employed is the use of username and
Senior Research password. However, the username/password scheme
Scientist in has several weaknesses which make it unsuitable for
Telenor R&I very many (most) services. Most importantly they
reduce security and make service access inconvenient
for the users due to:
• Username/password can be subject to phishing;
• Too many username/password pairs make it impos-
sible to remember all;
• It is common to reuse the same username/password
for different services;
penetration in Norway);
• It usually follows the user at all times (you seldom
leave home without).
Thus, by using the mobile phone as an authentication
solution, the major weaknesses of existing solutions
are reduced:
• More convenient for the user who now only
requires one device;
• Usually higher level of security (depends on the
specific authentication scheme implemented);
• Reduction in deployment and maintenance costs
for service providers (reuses existing infrastructure,
i.e. the mobile phone and the mobile network).

• It is common to write down username/password
where others can easily find them.
Due to these weaknesses of the username/password
scheme, other solutions must be used. For services
with particularly high security requirements, One-
Time-Passwords (OTP) [1] or Smart Card solutions
have been taken into use, e.g. for Internet-banking
services or corporate service access. These more
secure solutions usually increase the cost of the
security solutions both in the deployment phase
(provide all users with OTP-calculators or Smart
Cards w/readers) but also in the maintenance phase
(defective OTP-calculators, lost Smart Cards, invali-
dation of users etc.).
In addition, some such solutions can provide mobile
network operators with new sources of revenue since
they control much of the required infrastructure.
This paper starts with a discussion of authentication
strength and discusses the concept of multi-channel
authentication as a mechanism for stronger authenti-
cation. Then some different authentication schemes
using the mobile phone as an authentication token
will be described. An evaluation of the different
schemes will then be performed according to specific
criteria.
2 Strong Authentication

As a consequence of the weaknesses of existing 2.1 Two Factor Authentication

authentication solutions, new solutions should be Two factor authentication means that the authentica-
investigated. Using the mobile phone as an authenti- tion process consists of two stages, where each stage
cation solution towards Internet-based services is uses a different credential. For example, the mobile
particularly compelling due to: phone authentication process is (usually) two factor

ISSN 0085-7130©Telenor ASA 2007

Telektronikk 3/4.2007 143
 because it relies on 1) the PIN-code to activate the
SIM-card, and 2) the possession of the SIM-card
itself with the appropriate keys and algorithms. Lack-
ing one of these will usually mean that it is impossi-
ble to authenticate. However, it is possible to reduce
the SIM authentication to one factor by disabling the
PIN-code verification.
2.2 Multi-channel Authentication
Multi-channel authentication is the process of utilis-
ing more than one communication channel for the
secure establishment of the user’s identity. It is cru-
cial to understand the properties of the different chan-
nels in order to implement authentication solutions
with adequate properties. When using the mobile
phone for authentication, it is today possible to use
the connection between the mobile phone and a com-
puter, which again communicates with an authentica-
tion server on the Internet, as one channel, e.g. to ini-
tiate the authentication process. The response to the
authentication request can be sent on another channel
back to the user, e.g. using an SMS message. The
user can then again either complete the authentication
process by responding with an SMS or by sending a
message through the initial channel.
3 The Different Mobile Phone
Authentication Schemes
To be able to authenticate users through a mobile
phone, certain main components must be in place.
Figure 1 shows the main components and the basic
architecture needed for the solutions described later
to work.
The user must have access to a computer connected
to the Internet and be in possession of a mobile phone
GSM network
M user can confirm that the session IDs match and send
GS
Authentication server
Mobile phone
Radius
TP
HT
Bluetooth/
user interaction
HTTP
User User computer Service provider
Figure 1 A general architecture of mobile authentication
ISSN 0085-7130©Telenor ASA 2007
144
with a working SIM card. If the computer and mobile
phone are equipped with Bluetooth, higher usability
can be obtained. Through the Internet browser on the
computer the user can access web services provided
by service providers. The service provider (SP) is
connected to an Authentication Server (AS) that will
handle the authentication on behalf of the SP. The AS
is connected to the GSM network which enables it to
communicate with the user’s mobile phone and the
operator’s Authentication Center (AuC). The AS is
composed of two parts, an authenticator and an AAA
server. The authenticator communicates with the
client and relays messages to the AAA server which
handles the authentication.
When designing an authentication scheme which uses
two separate devices that communicate over two dif-
ferent networks it is very important to ensure that it
is the same user that controls both devices. This is
done by ensuring that there is a “closed loop” going
through all the components involved in the authenti-
cation as illustrated in Figure 1. The loop starts in the
device requesting the service, the user’s computer,
goes through the network with SP and AS and then
via the mobile phone and back to the initial device,
either by user interaction or Bluetooth.
This closed loop can be realized in several ways as
described in the solutions presented below.
3.2 SMS Authentication
with Session-ID Check
This solution exploits that a user with a valid mobile
subscription is already authenticated through the
GSM system. Session IDs are used to ensure that it
is the same user that controls both the computer and
the mobile phone.
When the user accesses a service provider a unique
session ID is created and sent both to the user’s com-
puter and to the mobile phone. The session ID is sent
over the Internet to the computer and shown in the
web browser and sent to the phone by SMS. Then the
a confirmation by SMS to the service provider. When
receiving the confirmation from the user the AS
knows that the user is in possession of the phone and
the authentication is successful.
The comparison of the session ID can be made by the
user or automatically by software if the phone is con-
nected to the computer by Bluetooth.
3.2.1 User Verification of Session ID
The user accesses the service provider through the
Internet browser and chooses to be authenticated by
his mobile phone. The user identifies himself with his
Telektronikk 3/4.2007
 Mobile phone Computer Service provider Authentication server

Request/access

Request/identity

Response/identity

Request/authentication (identity)

Session ID

Session ID

Confirmation

Response/authentication (identity)

Access granted

Figure 2 Session ID check

mobile phone number and the request is redirected to
the authentication server. The authentication server
then creates a unique session ID and sends this to the
user by SMS and over the Internet to the computer.
The user checks that the session ID in the SMS is the
same as the one shown in the browser. If this is the
case the user replies by sending an SMS back to the
AS confirming that the session IDs match. When
receiving the confirmation the authentication server
redirects the browser back to the service provider and
the user is given access to the service. The message
exchange is shown in Figure 2.
3.2.2 Automatic Check of Session ID
To make it even easier for the user the session ID can
be checked automatically. This can be done by pair-
ing the mobile phone and the computer by Bluetooth.
[3]. When the AS receives the confirmation it notifies
the authenticator that the user is authenticated and
redirects the browser back to the SP. The message
exchange is shown in Figure 3.
3.3 One-Time-Password from PC to SMS
The next two solutions make use of the OTP principle
[4] for authentication. The solutions describe differ-
ent ways to securely use the mobile phone as an OTP
token.
The authentication procedure for the OTP from PC
to SMS solution is shown in Figure 4. When the
client wants to access the SP the client’s identity is
requested. The client responds by typing his user-
name in the browser. The message is relayed to the
AS which handles the authentication. Upon receiving

When the computer receives the session ID from the

AS a Java applet running in the browser contacts the
SIM card using the Bluetooth SAP. SAP requires that Java applet (PC) SIM
a 16 digit pass-phrase is used during the pairing pro-
Session ID (from AS) Session ID (SMS from AS)
cess. The applet checks the SIM for an SMS with an
Setup SAP connection
appropriate session ID. For this to function it must be
ensured that the SMS received from the AS is stored Read SMS
on the SIM. This can be done by setting the TP-PID
in the SIM header to require SIM data download [2]. Send SMS (confirmation)
This forces the mobile phone to store the SMS on the
SIM. If a matching session ID is found the applet cre- Confirmation (SMS to AS)
ates a confirmation message that is sent to the AS by Terminate connection

SMS. This is done with a proactive SIM which can

issue commands to the mobile phone as described in Figure 3 Automatic check of session ID

ISSN 0085-7130©Telenor ASA 2007

Telektronikk 3/4.2007 145
 Client Authenticator Authentication server AuC

Access

Request/identity

Response/identity

Challenge

Challenge

OTP

OTP

Authentication successful

Access granted

Figure 4 OTP from PC to phone

the client’s identity the AS generates a challenge, typ-
ically a random number based on the client’s profile,
and a corresponding OTP. Then the AS sends the
challenge to the client. The client enters the challenge
on the mobile phone. The OTP applet on the SIM
card generates an OTP from the challenge. The OTP
is then sent to the AS by SMS. The AS compares the
calculated and received OTP and notifies the authen-
ticator that the client is authenticated. The browser is
redirected back to the SP and the user is successfully
logged in.
3.3.1 Manual Variant
When the client receives the challenge from the AS it
is displayed in the browser. The user starts a MIDlet
MIDIet Java ME
Connect
Manage channel
Select applet
Connection confirmed
OTP applet
on the phone which can communicate with the SIM
card through SATSA-APDU [5] as shown in Figure
5. The user is prompted for the challenge and enters
it on the phone. The MIDlet transfers the challenge
to the OTP applet which responds with an OTP. The
user creates an SMS containing the OTP and sends it
to the AS.
3.3.2 Automatic Variant
If the mobile phone and computer are connected
through Bluetooth the challenge can be sent to the
phone automatically. To realize this, a Java applet
will run in the browser and communicates with the
Java MIDlet on the mobile phone. The MIDlet on the
phone also has to be expanded so that it can create
and send an SMS with the OTP to the AS. This can
be done by the Wireless Message API[6].
SIM
When the user wants to log in using the automatic
solution the first thing to be done is to pair the mobile
phone and the computer. If this is the first time these
two devices are paired a pass-phrase must be entered
on both devices. When the pairing is done the user
can choose to log in with the automatic solution and
after providing an identity the rest of the procedure
will go automatically.

Challenge After providing the identity a challenge is sent to

the user. The Java applet retrieves the challenge and
Challenge
contacts the MIDlet on the mobile phone. When the
Bluetooth connection is set up the challenge is sent
to the MIDlet. The MIDlet contacts the SIM card as
Response (OTP)
Response (OTP) shown in Figure 5. When the OTP is created the
MIDlet creates an SMS containing the OTP and
sends it by the GSM network to the AS.
Figure 5 OTP Applet

ISSN 0085-7130©Telenor ASA 2007

146 Telektronikk 3/4.2007
3.4 One-Time-Password from SMS to PC
This solution builds on the same principle as the
session ID check, that a user with a working phone is
already authenticated through the GSM network. The
difference is that the check is done by the server and
therefore relieves the user from this burden.
The user starts the authentication procedure by enter-
ing his username. The session is redirected to the AS
which creates an OTP based on the user’s identity by
a cryptographic hash function. The OTP is then sent
to the user by SMS. When receiving the SMS the
user types the OTP in the browser. The AS verifies
that the OTP is correct and redirects the browser back
to the service provider and the user is logged in. Fig-
ure 6 shows the message exchange of this solution.
3.4.1 Manual Variant
When the user receives the SMS with the OTP from
the AS he types the OTP in the browser and presses
the log-in button. If the OTP is correct the user is
successfully logged in.
3.4.2 Automatic Variant
If the mobile phone and the computer are paired
through Bluetooth the OTP can be transferred auto-
matically from the phone to the computer and then
forwarded to the AS through the browser. This can be
handled by a Java applet on the computer communi-
cating with the SIM card through SAP. When the AS
has sent the OTP by SMS it notifies the client that
this has been done. When receiving this notification
the Java application contacts the mobile phone and
retrieves the SMS from the AS. The applet retrieves
the OTP from the SMS and sends it to the AS
through the Internet browser. As in the session ID
solution the TP-PID field in the SMS header must
be set to “SIM DATA DOWNLOAD” so that the
SMS is guaranteed to be stored on the SIM card.
3.5 SIM Strong Authentication via Mobile
Phones
This solution makes use of the EAP-SIM protocol [7]
to authenticate the user. EAP-SIM is run between the
SIM and the AS. The protocol can be run through the
computer over Bluetooth and Internet or over the
GSM network by SMS.
When the user accesses an SP the browser is redi-
rected to an AS. If the user chooses to run the SIM
strong authentication the rest of the procedure is hid-
den for the user as the SIM card and the AS authenti-
cate each other. If the authentication is successful the
browser is redirected back to the SP and the user is
logged in.
ISSN 0085-7130©Telenor ASA 2007
Telektronikk 3/4.2007
Client Authenticator Authentication server
Access
Request/identity
Response/identity
OTP (by SMS)
OTP (in browser)
Authentication successful
Access granted
Figure 6 OTP SMS to PC
In order to be able to run the EAP-SIM protocol
between the AS and the client the AS needs to
communicate with the SIM card. To avoid having to
install specific software on the client’s computer this
communication is handled by a Java applet [8].
The applet will play the role as supplicant and run in
the client’s browser and relay messages between the
authenticator and the SIM card.
Its main functions will be to
1 Receive EAP request from the EAP authenticator;
2 Send the content of the these packets to the SIM
card;
3 Build EAP response packets from the SIM
responses;
4 Send the EAP response packets to the EAP authen-
ticator.
The applet communicates with the SIM card using
Bluetooth SIM Access Protocol (SAP) [9]. The EAP
authenticator is implemented as a Java Servlet run-
ning inside the AS. The authenticator first request an
EAP identity from the supplicant. The supplicant
translates this request and relays it to the SIM card.
The SIM card responds with the international mobile
subscriber identity (IMSI). The authenticator sends
the identity received to the AAA server which con-
tacts the user’s AuC for GSM triplets. The challenges
contained in the triplets are concatenated and sent
back to the supplicant. The supplicant relays the
challenges to the SIM card that
1 Authenticates the server by verifying that the
MAC1 received is in order;
2 Runs the GSM algorithms to calculate a MAC2
that is sent back to the AS.
147
 SIM Supplicant Authenticator Authentication server

EAP-request identity
Get IMSI

IMSI
EAP-response - identity (based on IMSI)

EAP-request/SIM/start

EAP-request/SIM/start (with Nonce)

EAP-request/SIM/challenge (with n*RAND, MAC1)

Run GSM algorithm (RAND, MAC)

Message 1

EAP-response/SIM/challenge (with MAC2)

EAP-success

Figure 7 EAP SIM authentication

The supplicant receives the response from the SIM
and sends them to the authenticator in EAP format.
The authenticator relays the response to the AAA
server that verifies that the MAC2 is correct. If
MAC2 is correct the authentication is successful and
the user is logged in. The EAP-SIM authentication is
shown in Figure 7.
3.5.1 SMS Variant
This solution is a variant that does not require a Blue-
tooth enabled mobile phone. Instead the EAP-SIM
protocol will run over SMS.
The user chooses to log in using the EAP over SMS
solution. When this is done, a web page is presented
asking for a session ID. An authentication applet on
the SIM card is started by the AS through SAT and
the user is asked to confirm that he wants to start the
authentication. A session ID is displayed on the
mobile phone screen and the user enters the session
ID in the browser. If the session ID is correct the user
must accept to start authentication by pressing an OK
button on the phone. Then EAP-SIM authentication is
performed between the SIM card and the AAA server
by exchanging SMS messages. If the authentication
is successful, the SP is notified that the user with the
corresponding session ID is authenticated, and the
user is provided access to the protected resources.
To enable the phone to perform EAP authentication
over SMS an applet on the SIM card must be
installed. The applet generates the session ID to be
entered in the browser. Thereafter, the SIM applet
performs authentication towards GSM using SMS
messages which encapsulate the EAP-SIM protocol.
This solution is similar to the previous, however it
does not require the Bluetooth connection between
the mobile phone and the user’s PC since it instead
uses SMS to close the authentication loop. SAP is
used to control the SIM card and mobile phone dur-
ing authentication.
The implementation can be optimized so that only
two mobile-originated short messages and one server-
originated short message are required for full EAP-
SIM authentication.

ISSN 0085-7130©Telenor ASA 2007

148 Telektronikk 3/4.2007
4 Evaluation
4.1 Criteria
This section provides an evaluation of the different
authentication schemes using the mobile phone as
authentication token. The evaluation is performed
according to the following criteria:
• Strength & vulnerability
• Cost
• User friendliness
As Figure 8 illustrates, the different authentication
solutions can be subject to attacks in several areas,
depending on the specific scheme:
1 On the mobile phone;
2 Across the Bluetooth connection;
3 On the computer;
4 Across the Internet connection;
5 Across the connection between service provider
and authentication server;
6 On and between GSM network components and
connections.
The following sections will discuss some of the most
probable attacks on the different mobile authentica-
tion solutions.
4.2 Session-ID check with SMS
4.2.1 Manual
With regard to Figure 8, this solution is realistically
most susceptible to an attack in the response phase,
i.e. when the user sends an acknowledgement back to
the AS through the GSM network. Consider a possible
hijacker whose goal it is to steal a session from a valid
user. If the hijacker establishes a session towards a
service at the same time as the valid user, using the
valid user’s identity (i.e. cellular phone number), two
messages with session-ids will be sent to the valid
user. Being unaware of the hijack attempt, the valid
user might respond with acceptance to the invalid
user’s request, instead of to the valid user’s request.
However, such an attempt requires a hijacker to be
familiar with the valid user’s identity as well as being
well synchronised with the valid user’s activitity (e.g.
through visual observation). The likeliness of such
a successful hijack attempt is therefore in practice
extremely low, since it also assumes that the user
does not properly study each of the incoming SMS
messages with session-ids. Another problem with the
solution is that it is technically possible to spoof SMS
sender addresses, i.e. send SMS messages with the
valid user’s number. Additional security mechanisms
should be applied to prevent this.
ISSN 0085-7130©Telenor ASA 2007
Telektronikk 3/4.2007
6. GSM network
AS
1. Mobile phone
4. Internet 5. SP - AS 5. SP-AS
connection structure structure
2.
Bluetooth
3. Computer SP
Figure 8 Possible points of attack in mobile
authentication solutions
4.2.2 Automatic
This solution, being rather similar to the previous
one, eliminates the human factor in the verification of
the received session-id in the SMS. Instead, it intro-
duces another point of possible attack; the Bluetooth
connection (2) between the mobile phone and the
user’s computer. The equality of the session-id on the
mobile phone and the user’s computer is performed
over this Bluetooth connection. Consider a hijacker
which is able to intercept communication over this
connection (man-in-the-middle attack), thus being
able to receive requests over it as well as sending
responses in return. A hijacker could then, similarly
to in 4.2.1, establish a session towards the service in
question with the user’s identity (cellular phone
number). An SMS will then be received by the valid
user’s mobile phone, with the appropriate session-id.
However, if the hijacker is able to redirect his Java
Applet so that it contacts the valid user’s mobile
phone, instead of his own, to access the valid session-
id, he can in theory hijack a user session, and this
could happen even when the valid user is not actually
in the process of establishing a session towards the
service at the same time. The Java Applet must also
send the confirmation SMS through the valid user’s
mobile phone, since the AS will check that the confir-
mation comes from the appropriate cellular phone
number.
The Bluetooth connection between the user computer
and the mobile phone is protected by encryption
using a 16 digit key (as required by SAP) which is
used in the pairing process, so the feasibility to estab-
lish such an attack is very limited.
149
 4.3 OTP PC-to-SMS
4.3.1 Manual
In this solution, it is the OTP which is the most cru-
cial element. If an eavesdropper can get hold of the
OTP, he could in theory hijack a user session. How-
ever, since a user’s session (and OTP) is associated
with a specific challenge, it is not enough to get hold
of the OTP, it is also necessary to hijack the HTTP-
session which has previously been created by the
valid user. The solution could also in addition to the
OTP include a check of the sender address of the
SMS carrying the OTP, to further improve the
strength and reduce the possibility of malicious
attacks.
4.3.2 Automatic
The automatic variant of the OTP-solution mostly
improves the user-friendliness. However, it also
reduces the possibility of attacks due to a strong
association between the user’s phone and computer
through an authenticated and encrypted Bluetooth
connection. Attacks towards this solution could be
launched on the Bluetooth-connection, but this is
not trivial.
4.4 OTP SMS-to-PC
4.4.1 Manual
Since the OTP in this solution is sent to the user,
attacks must be directed towards obtaining the OTP.
However, the OTP is typically associated with an
HTTP-session created by the valid user. Therefore,
both the OTP and the HTTP-session must be attacked
in order for a malicious user to get access to the valid
user’s services.
4.4.2 Automatic
This solution simplifies the work of the user, and pre-
vents eavesdroppers from visually getting hold of the
OTP which is received by the valid user’s mobile
phone. The OTP is never actually exposed to the
user, but handled only by the system components.
The solutions are rated with relative weights from
1 to 6, with 6 as the best.
4.5 SIM Strong Authentication
The SIM strong authentication solution can be used
with the SIM-card in the mobile phone, but also with
the SIM-card in a USB-dongle or similar. The two
different solutions differ in some of their properties.
4.5.1 SIM in Mobile Phone
From a user’s perspective, this is the most ideal solu-
tion, since no additional device is required to perform
authentication. Regarding the security properties, this
ISSN 0085-7130©Telenor ASA 2007
150
solution requires a wireless Bluetooth connection
between the phone and the user’s computer, which in
theory could be compromised, but as previously dis-
cussed, this is in reality unfeasible. The biggest secu-
rity risk with the solution is loss of terminal, but the
SIM is also protected by a PIN-code, which renders
the device useless when unknown. The PIN-code
must be used to activate the SIM when the phone is
switched on, but in addition, the solution can require
the user to also enter the PIN-code each time an
authentication is to be performed, further strengthen-
ing the solution in case of loss of mobile phone.
4.5.2 SIM in USB-dongle
This solution is slightly less user friendly than the
previous one due to the need for an additional device,
and in theory a bit more secure since it requires a
physical connection between the user’s computer and
the SIM-card. This solution also requires a PIN-code
for activation of the SIM-card prior to authentication,
which prevents use by arbitrary users if the dongle
with SIM is lost.
4.5.3 SIM Strong Authentication with SMS
This solution combines the strength of SIM strong
authentication with the session-id check, and the
result is a relatively strong authentication solution.
However, it requires the installation of a special
applet on the user’s SIM-card. The solution also
requires a check of session-id, and could also possi-
bly include the PIN-verification procedure to provide
further protection in case of loss of mobile phone.
All the SIM strong authentication solutions above are
based on well-proven, standardised technologies and
protocols where the strength and weaknesses have
been scrutinized by computer and communication
network security experts.
4.6 Comparison of Authentication
Solutions
Table 1 illustrates some of the security properties of
the major categories of authentication solutions dis-
cussed in this paper. It shows what type of attacks the
different solutions can be susceptible to.
Figure 9 shows a comparison of the different authenti-
cation solutions with respect to four parameters; secu-
rity, cost, infrastructure and user-friendliness. The
comparison is informal and only meant to provide
some insight into the properties of the various solu-
tions in relation to each other. As with all such solu-
tions, the actual implementations might have other
properties than illustrated here. The scores are relative
from 1 to 10, with 10 as the best rating. High rating in
e.g. cost and infrastructure does not mean high cost,
nor a lot of infrastructure, but rather the opposite.
Telektronikk 3/4.2007
5 Conclusion Security requirement Session ID OTP solutions SIM strong
solutions
This paper has suggested several ways to employ the
mobile phone as an authentication token, with the Online guessing n/a √ n/a
purpose of addressing shortcomings of existing
Replay √ √ √
authentication solutions on the Internet today. The
solutions show that there are many different possibili- Eavesdropping √ √

ties, and that the authentication process can take one Shared secrets not revealed n/a √ √
single path back and forth, or exploit several channels Multi-factor authentication √ √ √
(multi-channel authentication) to complete the
Man-in-the-middle √
authentication. The paper also informally illustrates
the security properties of the solutions and provides Session hijacking √
a comparison between the solutions with respect to Authenticated data transfer √
four important criteria.
Table 1 Security properties

References
1 OATH – An industry roadmap for Open Strong 2006 [online] – URL: http://www.gemplus.com
Authentication. October 22, 2007 [online] – URL: /pss/telecom/download/jsr177_whitepaper
http://www.openauthentication.org/ _april05.pdf

2 3GPP. Technical realization of the Short Message
Service. 2003. (3GPP TS 23.040)
3 ETSI. GSM 11.14 Specification of the SIM Appli-
cation Toolkit for the Subscriber Module –
Mobile Equipment (SIM – ME) Interface. Sophia
Antipolis, 1996.
6 Ortiz, C E. The Wireless Messaging API, 2002.
March 2007 [online] – URL:
http://developers.sun.com/techtopics/mobility
/midp/articles/wma/
7 Aboba, B et al. Extensible Authentication Proto-
col. IETF, 2004.

4 Haller, N, Metz, C, Nesser, P, Straw, M. A One-
Time Password System. IETF, 1989. (RFC 2289)
5 Cricco, R, Vinson, Y. Integrating the SIM Card
into J2ME as a Security Element, 2005. October
8 Lunde, L, Wangensteen, A. Using SIM for strong
end-to-end application authentication. In: Tele-
matics. Trondheim, NTNU, 2006. (MSc thesis)
9 Bluetooth-SIG. Bluetooth specification SIM
Access Profile v.10, 2005.

Score
12 Session-ID check (manual)

Session-ID check (automatic)

10

OTP PC-to-SMS (manual)

8
OTP PC-to-SMS (automatic)

6
OTP SMS-to-PC (manual)

4 OTP SMS-to-PC (automatic)

2 SIM Strong authentication

SIM Strong authentication with SMS

0
Security Cost Infrastructure User-friendliness
Criteria

Figure 9 Comparison of the different authentication solutions based on the mobile phone

For a presentation of Ivar Jørstad and Do Van Thanh, please turn to page 10 and 2, respectively.

ISSN 0085-7130©Telenor ASA 2007

Telektronikk 3/4.2007 151