End-to-end security implementation for mobile devices using TLS protocol, Hacking and IT E-Book Dump Release
[ Pobierz całość w formacie PDF ]
J Comput Virol
DOI 10.1007/s11416-006-0017-x
ORIGINAL PAPER
End-to-end security implementation for mobile devices
using TLS protocol
Baris Kayayurt
·
Tugkan Tuglular
Received: 13 January 2006 / Revised: 11 February 2006 / Accepted: 28 March 2006
© Springer-Verlag France 2006
Abstract
End-to-end security has been an emerging
need for mobile devices with the widespread use of per-
sonal digital assistants and mobile phones. Transport
Layer Security Protocol (TLS) is an end-to-end secu-
rity protocol that is commonly used on the Internet,
together with its predecessor, SSL protocol. By imple-
menting TLS protocol in the mobile world, the advan-
tage of the proven security model of this protocol can
be utilized. The main design goals of mobile end-to-end
security protocol are maintainability and extensibility.
Cryptographic operations are performed with a free li-
brary, Bouncy Castle Cryptography Package. The object
oriented architecture of proposed end-to-end security
protocol implementation makes the replacement of this
library with another cryptography package easier. The
implementation has been experimented with different
cases, which represent use of different cryptographic
algorithms.
these kinds of applications. However, some deficiencies
prevent its acceptance in e-commerce applications [12].
With more and more network connected applications,
security has became one of the most popular concept
in mobile community. Mobile security deals mainly with
two issues: security of the physical device and its con-
tents and security of the data in network communication.
The communication of data in mobile devices is pro-
vided by the mobile networks. Mobile networks are
open to many kinds of attacks. The open data communi-
cation in these networks may cause attacks against the
secrecy, integrity and authenticity of data. Many ven-
dors have proposed solutions against these security vul-
nerabilities. Most of these solutions are vendor-specific
proprietary products or libraries.
Jøsang and Sanderud [6] investigated the aspects of
mobile networks and found that it is both harder and
easier to implement communication security as com-
pared to the Internet for example. They concluded that
communication between mobile and fixed networks cre-
ate particular problems regarding security protocol de-
sign. Data security problems can be minimized through
the implementation of end-to-end security in this proxy-
based environment.
Many mobile networks have proxy-based architec-
ture. In this architecture, security between the mobile
device and the proxy server is provided with a solu-
tion and the security between the proxy server and the
destination server is provided with another solution.
WTLS, announced as the security solution of WAP pro-
tocol, is such a protocol. There are two problems with
proxy-based solutions. First, it decreases performance.
As the data is decoded and reencoded at proxy server, it
may cause latency. Second, regardless of using WTLS, a
malicious operator can eavesdrop and tamper with the
1 Introduction
Current trends in mobile applications have been the
enterprise-style applications that needed high-capacity,
network-connected devices. Financial applications like
banking and stock trading are common examples of
B
B. Kayayurt (
)
Havelsan, Eskisehir Yolu 7. Km.,
06520 Ankara, Turkey
e-mail: kayayurt@bornova.ege.edu.tr
T. Tuglular
Department of Computer Engineering,
Izmir Institute of Technology,
Gulbahce Koyu, Urla, Izmir, Turkey
e-mail: tugkantuglular@iyte.edu.tr
B. Kayayurt, T. Tuglular
data [10]. These attacks may be a threat to the data
security between the period it is decoded and encoded.
The alternative to proxy based security solutions is
end-to-end security. End-to-end security refers to the
securely encoding of data at the source host and decod-
ing at the destination host. The data will not travel un-
encoded at any part of the communication. Transport
Layer Security Protocol (TLS) and its predecessor Se-
cure Sockets Layer (SSL) protocols are end-to-end secu-
rity solutions that are commonly used in the wired world
[1]. There are a number of reasons to use these protocols
in the mobile world:
2 Mobile architectures
Mobile Java applications run on mobile devices, mostly
mobile phones and Personal Digital Assistant (PDA)
devices. Whatever the device is, the application platform
has a unique architecture. This architecture consists of
the device’s architecture (hardware, OS, JVM, etc.), net-
work connection architecture that connects the mobile
device to the outside world and the application architec-
ture. The mobile security protocol developed will run on
the architecture explained below.
2.1 Device architecture
–
TLS and SSL protocols have been used for many
years, so their security is tested by the community
and accepted as secure enough to be used by finan-
cial data communication.
–
TLS and SSL protocols are common in wired world
and may be accepted as the security protocol of In-
ternet. Using these in mobile applications will make
the integration between mobile applications and In-
ternet easier.
–
TLS and SSL have open specifications and many
implementations. It may be relatively easy to imple-
ment these for specific needs.
Today, many cell phones and PDAs support Mobile
Information Device Profile (MIDP) technology. Usu-
ally, cell phones have built-in support for either MIDP
1.0 or 2.0; and PDAs (mostly PALM based PDAs) sup-
port MIDP after installing the KVM (Kilobyte Virtual
Machine) specific for these devices. A variety of devices
from different vendors have J2ME (Java 2 Micro Edi-
tion) MIDP support [7]. In order to support this kind of
flexibility and customization need, J2ME architecture
is designed to be modular and scalable. Figure 1 shows
the general architecture of a J2ME MIDP device with
its layered approach, based on [13]. In this architecture,
the host operating system communicates with the device
hardware and provides services for the Java Virtual Ma-
chine (JVM) layer. JVM layer is the implementation of
a Java virtual machine that is customized for a particular
device’s host operating system and supports a particu-
lar J2ME configuration. The configuration layer defines
the minimum set of Java virtual machine features and
Java class libraries available on a particular category of
devices. The profile layer defines the minimum set of
Application Programming Interfaces (APIs) available
on a particular family of devices. The layer where Java
applications are written is the Profile Layer. Mobile de-
vice operating systems control the mobile device hard-
Both protocols are known by their resource consuming
nature and the idea that they are not suitable for mobile
networks. The end-to-end security solution presented
in this paper is implemented for mobile devices using
Java platform in order to show that it is possible and
efficient to use TLS in mobile networks. Kwon et al. [8]
worked on the same problem and published an end-to-
end security model that utilizes transport layer security
to overcome WAP security problems. However, imple-
mentation of their model and related experiments with
resulting values cannot be found.
In this paper, only transport layer security for mobile
devices has been discussed. Other security issues are out
of scope of this paper. Any implementer of the transport
layer security for mobile devices should be aware of the
security weaknesses that the J2ME environment con-
tains [4].
This paper presents a solution to end-to-end secu-
rity needs of mobile devices, such as PDAs and mobile
phones. After a brief explanation of mobile architec-
tures is given, the proposed architecture for end-to-end
security of mobile devices is described. The next section
mentions the implementation details of the architecture;
the development environment and some implementa-
tion issues. Then the experiment enviroment and exper-
iments are explained together with their results. The
paper ends with a discussion of the results of experiments.
Fig. 1
J2ME device architecture [13]
End-to-end security implementation for mobile devices using TLS protocol
ware and provide services for the JVM layer. Although
MIDP applications run on top of a JVM and are inde-
pendent of the operating system, the implementation of
the JVM is customized for the operating system. So the
operating systems capabilities define the MIDP applica-
tion capabilities. Themost common operating systems in
MIDP supporting devices are PALM OS and Symbian
OS.
As in desktop, Java applications on mobile devices
run on top of a virtual machine called JVM. The virtual
machine is implemented in native code and may directly
use operating systemservices. TheVMof mobile devices
are different from J2SE JVM because of the limited
resources and device architectures of mobile devices.
The KVirtual Machine (KVM) is a highly portable JVM
designed from the ground up for small memory, limited-
resource and network-connected devices such as cellular
phones, pagers and personal organizers [13].
Configuration Layer defines the minimum set of Java
virtual machine features and Java class libraries avail-
able on a particular “category” of devices. Connected,
Limited Configuration Layer (CLDC) is the configu-
ration specified for small, resource constraint mobile
devices. CLDC specification defines Java language and
virtual machine features, core libraries, input/output,
networking, security and internationalization [14].
CLDC configuration does not address application life-
cycle management (installation, launching, deletion),
user interface, event handling and high level application
model. These features are addressed by profiles imple-
mented on top of the CLDC.
Profile Layer defines the minimum set of APIs avail-
able on a particular family of devices. Profiles are imple-
mented on top of configurations. A device can support
multiple profiles. MIDP (see [15, 16]) is the most com-
mon profile implemented in all J2ME profiles. MIDP
defines a very limited API because of size and perfor-
mance reasons. However, it can be extended with vari-
ous optional packages. Bluetooth (JSR82),Web services
(JSR 172), wireless messaging (JSR 120), multimedia
(JSR 135), and database connectivity are some of the
optional packages developed for CLDC/MIDP environ-
ments. Device manufacturers may or may not include
optional packages in their device implementations.
modulation, and this carrier wave then acts as the trans-
mission medium, taking the place of a wire. WLANs
use the 2.4Gigahertz (GHz) frequency band. WLANs
offer all the features of traditional Ethernet or Token
Ring networks with the addition of increased network
infrastructure flexibility. This flexibility makes wireless
networks an important alternative to wired-networks in
small areas. WLANs provide a communication medium
for wireless mobile devices (PALM, e.g.) in small areas
like a building.
An alternatively new technology in mobile device
communication is Bluetooth. Bluetooth provides short-
range wireless connectivity over radio-frequency tech-
nology that uses the 2.4GHz Industrial-Scientific-Medic
al (ISM) band [9]. Bluetooth lets mobile devices com-
municate with each other up to 10m range and 1Mbit/s
speed. The IEEEhas designated its version of Bluetooth
with 20Mbit/s speed, as the IEEE 802.15 standard.
GPRS (General Packet Radio Service) is an enhance-
ment of core GSM (Global System for Mobile Com-
munications) networks that allows the rapid transfer of
data bundled into packets, separate from voice or data
call circuits [17]. GPRS is a 2.5 Generation (2.5G) tech-
nology that is the last stone before the coming 3G net-
works that will give high speed access allowing live video.
GPRS data is transmitted in packets, up to the speed of
20 or 30Kbps though the theoretical maximum speed is
171.2Kbps. GPRS set-up time is short and connection is
always on.
2.3 Application architecture
Client/server architecture is the main architecture for
mobile network applications. In this architecture, a
network-aware application residing on a wireless device,
client, connects with back-end applications and servers
behind a firewall or proxy gateway over a wireless net-
work and Internet and corresponding communication
protocols. Figure 2 shows the client/server architecture
of a mobile application.
In Figure 2, thewireless devices can bemobile phones,
PDAs or two-way pagers. They have the mobile applica-
tions on top of MIDP and communicate with an antenna
over a wireless communication protocol. These proto-
cols can be Wireless-LAN on a small area or GPRS on a
wide area. The antenna is directly connected to a wired
network like Internet, which connects the mobile device
to the back-end server systems.
Mobile applications typically use HTTP as the
application-level communication protocol as it is com-
mon and can pass firewalls. HTTP is the mandatory pro-
tocol in MIDP 1.0 [15] and MIDP 2.0 specifications [16].
2.2 Network connection architecture
A Wireless Local Area Network (WLAN) is a flexi-
ble data communications system that can either replace
or extend a wired LAN to provide added functionality
[5]. WLANs use Radio Frequency (RF) to transmit and
receive data over the air without cables. Data is super-
imposed onto a radio wave through a process called
B. Kayayurt, T. Tuglular
Fig. 2
Environment of a
typical networked wireless
application [11]
With MIDP 2.0, low-level socket APIs can also be used
to directly communicate with the server application be-
low the application level.
TLS may provide an application-level end-to-end
security on top of sockets in this architecture. The TLS
implementation developed in this thesis runs on top of
pure sockets and provides an application level security
between aMIDP application and server back-end appli-
cation. The MIDP version of the developed TLS proto-
col communicates with the J2SE version of the protocol
and sends object data over the secure connection. The
mobile device always runs the client version of TLS pro-
tocol and the back-end server always runs the server
version of the TLS protocol. Peer To Peer Architecture
is an alternative and new architecture for wireless de-
vices. In this architecture, the two devices communicate
directly with each other. This communicationmay be the
direct communication of the devices over a communica-
tion medium like Bluetooth or it may be an application
level communication with the two mobile applications
communicating over a central server.
The client side of the application is the same as the
Client/Server Architecture. It uses either HTTP or low-
level socket APIs, either stream-based or datagram-
based, for network communication. The difference is
in the server side. In this architecture, the server is also
a mobile device. MIDP 2.0 has an API for server sockets
that may be used for this purpose. The TLS implemen-
tation to work in this architecture needs both client and
server versions of TLS to work in the mobile device.
This may be impractical for two reasons. First, re-
source constraints of mobile devices may cause perfor-
mance problems for server side implementation of the
TLS protocol. Second, server sockets are not commonly
implemented inMIDP devices. In spite of these deficien-
cies, the TLS implementation presented in this paper can
be used in peer-to-peer architectures for experimental
purposes.
3 Design of mobile devices end-to-end security
architecture
The security protocol presented in this paper is an end-
to-end security protocol based on TLS 1.0 specifications
and adopted to work on J2ME mobile devices as well as
standard Java VMs. The protocol implementation itself
is also an application, although high-level applications
may use it through its APIs to transmit data and objects
securely.
The security protocol architecture developed cov-
ers both TLS protocol architecture and the necessary
APIs architecture. TLS protocol architecture is based
on TLS 1.0 specification and has some additions and
subtractions. The necessary APIs architecture involves
cryptography model classes that abstract the real imple-
mentations of cryptography packages; socket classes that
abstract TCPorUDPbased socket implementations and
the serialization of object data; XML Serializer archi-
tecture that is a standalone API incorporated into the
protocol implementation. The main design issues taken
into consideration during the definition of the architec-
ture of protocol implementation are J2ME compatibil-
ity, mobile adaptation, secure object transmission, full
abstraction and complete solution.
The main architecture of the mobile end-to-end secu-
rity protocol is based on the TLS 1.0 protocol specifica-
tion [3]. TLS is a protocol that consists of several layers
of protocols as shown in Figure 3. At the bottomof these
layers, there is the TLS Record Protocol. The Record
Protocol is responsible for taking messages to be trans-
mitted, fragmenting into blocks, optionally compress-
ing, applying MAC to protect data integrity, encrypting
the block and transmitting the result to higher level cli-
ents. Received data is then decrypted; applied MAC
is verified to protect data integrity; optionally decom-
pressed; reassembled and then delivered to higher level
clients by the Record Protocol. TLS Record Protocol
End-to-end security implementation for mobile devices using TLS protocol
Fig. 3
The layered structure
of TLS protocol
blocks are transported over a reliable transport proto-
col like TCP. There are four clients of record proto-
col: TLS Handshake Protocol, TLS Alert Protocol, TLS
Change Cipher Spec Protocol and application data. TLS
1.0 Specification allows new record protocol clients to be
supported by the record protocol. TLS Handshake Pro-
tocol is used to allow peers to authenticate each other
and to exchange cryptographic parameters that are used
in TLS Protocol. TLS Handshake is performed at the
beginning of a session before the application data is
transmitted or received. The Change Cipher Spec Pro-
tocol is used to start to use new keys and encryption
methods that the Handshake Protocol has established.
TLS Alert Protocol is used to send warning and fatal
level errors that could occur in TLS session. After the
handshake is performed, application data is taken by
Record Layer and sent securely to the other peer.
In our model, the Record Layer behavior is imple-
mented in the class RecordLayerImpl and the Hand-
shake Layer behavior is implemented in the class
HandshakeLayerImpl. This class has two instances of
class RecordLayerImpl; one for current state and one
for pending state. Both HandshakeLayerImpl and Re-
cordLayerImpl classes are transparent of the underlying
socket implementations and talk to the peer classes in
both sides of the communication.
The classes TLSClientSocket and TLSServerSocket-
Listener are the only classes needed to be known by
the applications that will use this implementation of the
protocol. An application that needs to be the client in
the secure communicationmust use the class TLSClient-
Socket; an application that needs to be the server in the
secure communication must use the class TLSServer-
SocketListener. The class TLSServerSocket is used to
handle a secure connection session in the server-side as
a separate thread. An applicationmay use the class TLS-
SocketFactory to obtain either a TLSClientSocket class
instance or a TLSServerSocketListener class instance.
The mobile secure application is designed as the pro-
tocol implementation separated from the underlying
communication model. This is achieved by the inter-
face TLSSocketImpl. This interface defines the opera-
tions needed for sending and receiving of secure data
and implemented by the client and server socket clas-
ses that abstract the communication details from the
protocol details. Thus, the communication of data can
be changed without changing any protocol dependent
code. The class TLSTCPSocketImpl is the client-side
implementation of the interface TLSSocketImpl as TCP
based stream socket and the class TLSTCPServerSock-
etImpl is the server-side implementation of the interface
TLSSocketImpl as TCP based stream server socket. The
class TLSUDPSocketImpl is the client-side implemen-
tation of the interface TLSSocketImpl as UDP based
datagram socket and the class TLSUDPServerSocket-
Impl is the server-side implementation of the interface
TLSSocketImpl asUDPbased datagramsocket. Figure 4
shows the main object model of the mobile end-to-end
security protocol.
The class HandshakeLayerImpl defines operations
and attributes needed to perform Handshake Layer
behavior and to send and receive application-level data
after the establishment of a secure session. Each secure
session has one instance of class HandshakeLayerImpl
and the class instances at both side of the communica-
tion talk to each other. While the Handshake Layer in
TLS Protocol communicates with the Record Layer to
send and receive data, the HandshakeLayerImpl class
uses RecordLayerImpl class to send and receive data.
The class RecordLayerImpl defines operations and
attributes needed to perform Record Layer behavior.
The responsibilities of RecordLayerImpl class are to
send and receive application and Handshake Layer data
after encoding and decoding; generate new TLS keys
according to the exchanged security parameters; copy
security parameters from pending state to current state
and activate new TLS keys for read side and write
side. In TLS 1.0, the Record Layer performs encryp-
tion, MAC and compression functions according to the
algorithms exchanged during handshake procedure. The
Record Layer architecture of the mobile protocol is
modeled to support this need in an extensibleway. This is
[ Pobierz całość w formacie PDF ]
zanotowane.pl doc.pisz.pl pdf.pisz.pl upanicza.keep.pl
J Comput Virol
DOI 10.1007/s11416-006-0017-x
ORIGINAL PAPER
End-to-end security implementation for mobile devices
using TLS protocol
Baris Kayayurt
·
Tugkan Tuglular
Received: 13 January 2006 / Revised: 11 February 2006 / Accepted: 28 March 2006
© Springer-Verlag France 2006
Abstract
End-to-end security has been an emerging
need for mobile devices with the widespread use of per-
sonal digital assistants and mobile phones. Transport
Layer Security Protocol (TLS) is an end-to-end secu-
rity protocol that is commonly used on the Internet,
together with its predecessor, SSL protocol. By imple-
menting TLS protocol in the mobile world, the advan-
tage of the proven security model of this protocol can
be utilized. The main design goals of mobile end-to-end
security protocol are maintainability and extensibility.
Cryptographic operations are performed with a free li-
brary, Bouncy Castle Cryptography Package. The object
oriented architecture of proposed end-to-end security
protocol implementation makes the replacement of this
library with another cryptography package easier. The
implementation has been experimented with different
cases, which represent use of different cryptographic
algorithms.
these kinds of applications. However, some deficiencies
prevent its acceptance in e-commerce applications [12].
With more and more network connected applications,
security has became one of the most popular concept
in mobile community. Mobile security deals mainly with
two issues: security of the physical device and its con-
tents and security of the data in network communication.
The communication of data in mobile devices is pro-
vided by the mobile networks. Mobile networks are
open to many kinds of attacks. The open data communi-
cation in these networks may cause attacks against the
secrecy, integrity and authenticity of data. Many ven-
dors have proposed solutions against these security vul-
nerabilities. Most of these solutions are vendor-specific
proprietary products or libraries.
Jøsang and Sanderud [6] investigated the aspects of
mobile networks and found that it is both harder and
easier to implement communication security as com-
pared to the Internet for example. They concluded that
communication between mobile and fixed networks cre-
ate particular problems regarding security protocol de-
sign. Data security problems can be minimized through
the implementation of end-to-end security in this proxy-
based environment.
Many mobile networks have proxy-based architec-
ture. In this architecture, security between the mobile
device and the proxy server is provided with a solu-
tion and the security between the proxy server and the
destination server is provided with another solution.
WTLS, announced as the security solution of WAP pro-
tocol, is such a protocol. There are two problems with
proxy-based solutions. First, it decreases performance.
As the data is decoded and reencoded at proxy server, it
may cause latency. Second, regardless of using WTLS, a
malicious operator can eavesdrop and tamper with the
1 Introduction
Current trends in mobile applications have been the
enterprise-style applications that needed high-capacity,
network-connected devices. Financial applications like
banking and stock trading are common examples of
B
B. Kayayurt (
)
Havelsan, Eskisehir Yolu 7. Km.,
06520 Ankara, Turkey
e-mail: kayayurt@bornova.ege.edu.tr
T. Tuglular
Department of Computer Engineering,
Izmir Institute of Technology,
Gulbahce Koyu, Urla, Izmir, Turkey
e-mail: tugkantuglular@iyte.edu.tr
B. Kayayurt, T. Tuglular
data [10]. These attacks may be a threat to the data
security between the period it is decoded and encoded.
The alternative to proxy based security solutions is
end-to-end security. End-to-end security refers to the
securely encoding of data at the source host and decod-
ing at the destination host. The data will not travel un-
encoded at any part of the communication. Transport
Layer Security Protocol (TLS) and its predecessor Se-
cure Sockets Layer (SSL) protocols are end-to-end secu-
rity solutions that are commonly used in the wired world
[1]. There are a number of reasons to use these protocols
in the mobile world:
2 Mobile architectures
Mobile Java applications run on mobile devices, mostly
mobile phones and Personal Digital Assistant (PDA)
devices. Whatever the device is, the application platform
has a unique architecture. This architecture consists of
the device’s architecture (hardware, OS, JVM, etc.), net-
work connection architecture that connects the mobile
device to the outside world and the application architec-
ture. The mobile security protocol developed will run on
the architecture explained below.
2.1 Device architecture
–
TLS and SSL protocols have been used for many
years, so their security is tested by the community
and accepted as secure enough to be used by finan-
cial data communication.
–
TLS and SSL protocols are common in wired world
and may be accepted as the security protocol of In-
ternet. Using these in mobile applications will make
the integration between mobile applications and In-
ternet easier.
–
TLS and SSL have open specifications and many
implementations. It may be relatively easy to imple-
ment these for specific needs.
Today, many cell phones and PDAs support Mobile
Information Device Profile (MIDP) technology. Usu-
ally, cell phones have built-in support for either MIDP
1.0 or 2.0; and PDAs (mostly PALM based PDAs) sup-
port MIDP after installing the KVM (Kilobyte Virtual
Machine) specific for these devices. A variety of devices
from different vendors have J2ME (Java 2 Micro Edi-
tion) MIDP support [7]. In order to support this kind of
flexibility and customization need, J2ME architecture
is designed to be modular and scalable. Figure 1 shows
the general architecture of a J2ME MIDP device with
its layered approach, based on [13]. In this architecture,
the host operating system communicates with the device
hardware and provides services for the Java Virtual Ma-
chine (JVM) layer. JVM layer is the implementation of
a Java virtual machine that is customized for a particular
device’s host operating system and supports a particu-
lar J2ME configuration. The configuration layer defines
the minimum set of Java virtual machine features and
Java class libraries available on a particular category of
devices. The profile layer defines the minimum set of
Application Programming Interfaces (APIs) available
on a particular family of devices. The layer where Java
applications are written is the Profile Layer. Mobile de-
vice operating systems control the mobile device hard-
Both protocols are known by their resource consuming
nature and the idea that they are not suitable for mobile
networks. The end-to-end security solution presented
in this paper is implemented for mobile devices using
Java platform in order to show that it is possible and
efficient to use TLS in mobile networks. Kwon et al. [8]
worked on the same problem and published an end-to-
end security model that utilizes transport layer security
to overcome WAP security problems. However, imple-
mentation of their model and related experiments with
resulting values cannot be found.
In this paper, only transport layer security for mobile
devices has been discussed. Other security issues are out
of scope of this paper. Any implementer of the transport
layer security for mobile devices should be aware of the
security weaknesses that the J2ME environment con-
tains [4].
This paper presents a solution to end-to-end secu-
rity needs of mobile devices, such as PDAs and mobile
phones. After a brief explanation of mobile architec-
tures is given, the proposed architecture for end-to-end
security of mobile devices is described. The next section
mentions the implementation details of the architecture;
the development environment and some implementa-
tion issues. Then the experiment enviroment and exper-
iments are explained together with their results. The
paper ends with a discussion of the results of experiments.
Fig. 1
J2ME device architecture [13]
End-to-end security implementation for mobile devices using TLS protocol
ware and provide services for the JVM layer. Although
MIDP applications run on top of a JVM and are inde-
pendent of the operating system, the implementation of
the JVM is customized for the operating system. So the
operating systems capabilities define the MIDP applica-
tion capabilities. Themost common operating systems in
MIDP supporting devices are PALM OS and Symbian
OS.
As in desktop, Java applications on mobile devices
run on top of a virtual machine called JVM. The virtual
machine is implemented in native code and may directly
use operating systemservices. TheVMof mobile devices
are different from J2SE JVM because of the limited
resources and device architectures of mobile devices.
The KVirtual Machine (KVM) is a highly portable JVM
designed from the ground up for small memory, limited-
resource and network-connected devices such as cellular
phones, pagers and personal organizers [13].
Configuration Layer defines the minimum set of Java
virtual machine features and Java class libraries avail-
able on a particular “category” of devices. Connected,
Limited Configuration Layer (CLDC) is the configu-
ration specified for small, resource constraint mobile
devices. CLDC specification defines Java language and
virtual machine features, core libraries, input/output,
networking, security and internationalization [14].
CLDC configuration does not address application life-
cycle management (installation, launching, deletion),
user interface, event handling and high level application
model. These features are addressed by profiles imple-
mented on top of the CLDC.
Profile Layer defines the minimum set of APIs avail-
able on a particular family of devices. Profiles are imple-
mented on top of configurations. A device can support
multiple profiles. MIDP (see [15, 16]) is the most com-
mon profile implemented in all J2ME profiles. MIDP
defines a very limited API because of size and perfor-
mance reasons. However, it can be extended with vari-
ous optional packages. Bluetooth (JSR82),Web services
(JSR 172), wireless messaging (JSR 120), multimedia
(JSR 135), and database connectivity are some of the
optional packages developed for CLDC/MIDP environ-
ments. Device manufacturers may or may not include
optional packages in their device implementations.
modulation, and this carrier wave then acts as the trans-
mission medium, taking the place of a wire. WLANs
use the 2.4Gigahertz (GHz) frequency band. WLANs
offer all the features of traditional Ethernet or Token
Ring networks with the addition of increased network
infrastructure flexibility. This flexibility makes wireless
networks an important alternative to wired-networks in
small areas. WLANs provide a communication medium
for wireless mobile devices (PALM, e.g.) in small areas
like a building.
An alternatively new technology in mobile device
communication is Bluetooth. Bluetooth provides short-
range wireless connectivity over radio-frequency tech-
nology that uses the 2.4GHz Industrial-Scientific-Medic
al (ISM) band [9]. Bluetooth lets mobile devices com-
municate with each other up to 10m range and 1Mbit/s
speed. The IEEEhas designated its version of Bluetooth
with 20Mbit/s speed, as the IEEE 802.15 standard.
GPRS (General Packet Radio Service) is an enhance-
ment of core GSM (Global System for Mobile Com-
munications) networks that allows the rapid transfer of
data bundled into packets, separate from voice or data
call circuits [17]. GPRS is a 2.5 Generation (2.5G) tech-
nology that is the last stone before the coming 3G net-
works that will give high speed access allowing live video.
GPRS data is transmitted in packets, up to the speed of
20 or 30Kbps though the theoretical maximum speed is
171.2Kbps. GPRS set-up time is short and connection is
always on.
2.3 Application architecture
Client/server architecture is the main architecture for
mobile network applications. In this architecture, a
network-aware application residing on a wireless device,
client, connects with back-end applications and servers
behind a firewall or proxy gateway over a wireless net-
work and Internet and corresponding communication
protocols. Figure 2 shows the client/server architecture
of a mobile application.
In Figure 2, thewireless devices can bemobile phones,
PDAs or two-way pagers. They have the mobile applica-
tions on top of MIDP and communicate with an antenna
over a wireless communication protocol. These proto-
cols can be Wireless-LAN on a small area or GPRS on a
wide area. The antenna is directly connected to a wired
network like Internet, which connects the mobile device
to the back-end server systems.
Mobile applications typically use HTTP as the
application-level communication protocol as it is com-
mon and can pass firewalls. HTTP is the mandatory pro-
tocol in MIDP 1.0 [15] and MIDP 2.0 specifications [16].
2.2 Network connection architecture
A Wireless Local Area Network (WLAN) is a flexi-
ble data communications system that can either replace
or extend a wired LAN to provide added functionality
[5]. WLANs use Radio Frequency (RF) to transmit and
receive data over the air without cables. Data is super-
imposed onto a radio wave through a process called
B. Kayayurt, T. Tuglular
Fig. 2
Environment of a
typical networked wireless
application [11]
With MIDP 2.0, low-level socket APIs can also be used
to directly communicate with the server application be-
low the application level.
TLS may provide an application-level end-to-end
security on top of sockets in this architecture. The TLS
implementation developed in this thesis runs on top of
pure sockets and provides an application level security
between aMIDP application and server back-end appli-
cation. The MIDP version of the developed TLS proto-
col communicates with the J2SE version of the protocol
and sends object data over the secure connection. The
mobile device always runs the client version of TLS pro-
tocol and the back-end server always runs the server
version of the TLS protocol. Peer To Peer Architecture
is an alternative and new architecture for wireless de-
vices. In this architecture, the two devices communicate
directly with each other. This communicationmay be the
direct communication of the devices over a communica-
tion medium like Bluetooth or it may be an application
level communication with the two mobile applications
communicating over a central server.
The client side of the application is the same as the
Client/Server Architecture. It uses either HTTP or low-
level socket APIs, either stream-based or datagram-
based, for network communication. The difference is
in the server side. In this architecture, the server is also
a mobile device. MIDP 2.0 has an API for server sockets
that may be used for this purpose. The TLS implemen-
tation to work in this architecture needs both client and
server versions of TLS to work in the mobile device.
This may be impractical for two reasons. First, re-
source constraints of mobile devices may cause perfor-
mance problems for server side implementation of the
TLS protocol. Second, server sockets are not commonly
implemented inMIDP devices. In spite of these deficien-
cies, the TLS implementation presented in this paper can
be used in peer-to-peer architectures for experimental
purposes.
3 Design of mobile devices end-to-end security
architecture
The security protocol presented in this paper is an end-
to-end security protocol based on TLS 1.0 specifications
and adopted to work on J2ME mobile devices as well as
standard Java VMs. The protocol implementation itself
is also an application, although high-level applications
may use it through its APIs to transmit data and objects
securely.
The security protocol architecture developed cov-
ers both TLS protocol architecture and the necessary
APIs architecture. TLS protocol architecture is based
on TLS 1.0 specification and has some additions and
subtractions. The necessary APIs architecture involves
cryptography model classes that abstract the real imple-
mentations of cryptography packages; socket classes that
abstract TCPorUDPbased socket implementations and
the serialization of object data; XML Serializer archi-
tecture that is a standalone API incorporated into the
protocol implementation. The main design issues taken
into consideration during the definition of the architec-
ture of protocol implementation are J2ME compatibil-
ity, mobile adaptation, secure object transmission, full
abstraction and complete solution.
The main architecture of the mobile end-to-end secu-
rity protocol is based on the TLS 1.0 protocol specifica-
tion [3]. TLS is a protocol that consists of several layers
of protocols as shown in Figure 3. At the bottomof these
layers, there is the TLS Record Protocol. The Record
Protocol is responsible for taking messages to be trans-
mitted, fragmenting into blocks, optionally compress-
ing, applying MAC to protect data integrity, encrypting
the block and transmitting the result to higher level cli-
ents. Received data is then decrypted; applied MAC
is verified to protect data integrity; optionally decom-
pressed; reassembled and then delivered to higher level
clients by the Record Protocol. TLS Record Protocol
End-to-end security implementation for mobile devices using TLS protocol
Fig. 3
The layered structure
of TLS protocol
blocks are transported over a reliable transport proto-
col like TCP. There are four clients of record proto-
col: TLS Handshake Protocol, TLS Alert Protocol, TLS
Change Cipher Spec Protocol and application data. TLS
1.0 Specification allows new record protocol clients to be
supported by the record protocol. TLS Handshake Pro-
tocol is used to allow peers to authenticate each other
and to exchange cryptographic parameters that are used
in TLS Protocol. TLS Handshake is performed at the
beginning of a session before the application data is
transmitted or received. The Change Cipher Spec Pro-
tocol is used to start to use new keys and encryption
methods that the Handshake Protocol has established.
TLS Alert Protocol is used to send warning and fatal
level errors that could occur in TLS session. After the
handshake is performed, application data is taken by
Record Layer and sent securely to the other peer.
In our model, the Record Layer behavior is imple-
mented in the class RecordLayerImpl and the Hand-
shake Layer behavior is implemented in the class
HandshakeLayerImpl. This class has two instances of
class RecordLayerImpl; one for current state and one
for pending state. Both HandshakeLayerImpl and Re-
cordLayerImpl classes are transparent of the underlying
socket implementations and talk to the peer classes in
both sides of the communication.
The classes TLSClientSocket and TLSServerSocket-
Listener are the only classes needed to be known by
the applications that will use this implementation of the
protocol. An application that needs to be the client in
the secure communicationmust use the class TLSClient-
Socket; an application that needs to be the server in the
secure communication must use the class TLSServer-
SocketListener. The class TLSServerSocket is used to
handle a secure connection session in the server-side as
a separate thread. An applicationmay use the class TLS-
SocketFactory to obtain either a TLSClientSocket class
instance or a TLSServerSocketListener class instance.
The mobile secure application is designed as the pro-
tocol implementation separated from the underlying
communication model. This is achieved by the inter-
face TLSSocketImpl. This interface defines the opera-
tions needed for sending and receiving of secure data
and implemented by the client and server socket clas-
ses that abstract the communication details from the
protocol details. Thus, the communication of data can
be changed without changing any protocol dependent
code. The class TLSTCPSocketImpl is the client-side
implementation of the interface TLSSocketImpl as TCP
based stream socket and the class TLSTCPServerSock-
etImpl is the server-side implementation of the interface
TLSSocketImpl as TCP based stream server socket. The
class TLSUDPSocketImpl is the client-side implemen-
tation of the interface TLSSocketImpl as UDP based
datagram socket and the class TLSUDPServerSocket-
Impl is the server-side implementation of the interface
TLSSocketImpl asUDPbased datagramsocket. Figure 4
shows the main object model of the mobile end-to-end
security protocol.
The class HandshakeLayerImpl defines operations
and attributes needed to perform Handshake Layer
behavior and to send and receive application-level data
after the establishment of a secure session. Each secure
session has one instance of class HandshakeLayerImpl
and the class instances at both side of the communica-
tion talk to each other. While the Handshake Layer in
TLS Protocol communicates with the Record Layer to
send and receive data, the HandshakeLayerImpl class
uses RecordLayerImpl class to send and receive data.
The class RecordLayerImpl defines operations and
attributes needed to perform Record Layer behavior.
The responsibilities of RecordLayerImpl class are to
send and receive application and Handshake Layer data
after encoding and decoding; generate new TLS keys
according to the exchanged security parameters; copy
security parameters from pending state to current state
and activate new TLS keys for read side and write
side. In TLS 1.0, the Record Layer performs encryp-
tion, MAC and compression functions according to the
algorithms exchanged during handshake procedure. The
Record Layer architecture of the mobile protocol is
modeled to support this need in an extensibleway. This is
[ Pobierz całość w formacie PDF ]