You are on page 1of 6

SSMS - A Secure SMS Messaging Protocol for the M-Payment Systems





Mohsen Toorani

Ali Asghar Beheshti Shirazi




Copyright © 2008 IEEE. Reprinted from the Proceedings of the 13
th
IEEE Symposium on Computers and Communications
(ISCC'08), pp.700-705, July 2008 [DOI 10.1109/ISCC.2008.4625610]. This material is posted here with permission of the IEEE. Internal
or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional
purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to pubs-
permissions@ieee.org.

Corresponding Author, ResearcherID: A-9528-2009


Abstract

The GSM network with the greatest worldwide number
of users, succumbs to several security vulnerabilities.
The Short Message Service (SMS) is one of its superior
and well-tried services with a global availability in the
GSM networks. The main contribution of this paper is to
introduce a new secure application layer protocol,
called SSMS, to efficiently embed the desired security
attributes in the SMS messages to be used as a secure
bearer in the m-payment systems. SSMS efficiently
provides confidentiality, integrity, authentication and
non-repudiation for the SMS messages. It provides an
elliptic curve-based public key solution that uses public
keys for the secret key establishment of a symmetric
encryption. It also provides the attributes of public
verification and forward secrecy. It efficiently makes the
SMS messaging suitable for the m-payment applications
where the security is the great concern.

1. Introduction

The mobile communications has experienced a great
acceptance among the human societies. At the beginning
of 2007, the worldwide number of mobile users reached
to 2.83 billion people [1]. The SMS is the most popular
data bearer/service within GSM, IS-95, CDMA2000,
and other cellular networks. It is a store-and-forward,
easy to use, popular, and low cost service. While it is
mainly used for the personal communications, it has also
been used in applications where the other party is an
information system. This includes a wide variety of
applications ranging from remote control of the
apparatus [2] to the m-banking and m-payment [3].
The Global Service for Mobile communications
(GSM) with the greatest worldwide number of users
suffers from many security problems [4]. In the GSM,
only the airway traffic between the Mobile Station (MS)
and the Base Transceiver Station (BTS) is optionally
encrypted with a weak and broken stream cipher (A5/1
or A5/2). The authentication is unilateral and also
vulnerable. The SMS messaging has some extra security
vulnerabilities due to its store-and-forward feature, and
the problem of fake SMS that can be conducted via the
Internet. When a user is roaming, the SMS content
passes through different networks and perhaps the
Internet that exposes it to various vulnerabilities and
attacks. Another concern is arisen when an adversary
gets access to the phone and reads the previous
unprotected messages. To exploit the popularity of SMS
as a serious business bearer protocol, it is necessary to
enhance its functionalities to offer the secured
transaction capability. Data confidentiality, integrity,
authentication, and non-repudiation are the most
important security services in the security criteria that
should be taken into account in many secure
applications. However, such requirements are not
provided by the traditional SMS messaging. Due the vast
area of applications, each of them having a different
level of security requirements, the most profitable
solution is via the end-to-end security or the security at
the application layer. It will be a network independent
solution and does not need any change in the network's
infrastructure. The security of SMS messaging at the
application layer is considered in some literature [5-8].
The TS 03.48 standard [9] that was designed for the SIM
Application Toolkit (SAT) can also be used for
providing the end-to-end security in any SMS message
outgoing or incoming to the Subscriber Identity Module
(SIM).
In this paper, a new Secure SMS messaging protocol
(SSMS) is introduced. Section 2 briefly describes the
proposed protocol, section 3 takes a glimpse at its
security attributes, and section 4 gives the conclusions.

2. The Proposed Scheme (SSMS)

A brief description of our SSMS protocol is provided
in this section. The end-to-end security in the cellular
systems can be generally provided by exploiting the
processing capabilities of one or some of the following
items:
1) The Mobile Equipment (ME) using the programming
languages,
2) The SIM card using SAT,
3) An additional smart card, e.g. JavaCard,
4) A crypto-processor that is embedded in the ME,
5) A portable PC (laptop) connected to the ME.
The SSMS provides the end-to-end security and is
based on the first solution. It suggests using J2ME (Java
2 Mobile Edition) as the programming platform. J2ME
is a runtime environment designed for resource restricted
devices such as mobile phones and Personal Digital
Assistants (PDA). It consists of Connected Limited
Device Configuration (CLDC), and Mobile Information
Device Profile (MIDP). A MIDlet is a program
developed in J2ME. The MIDlet uses classes defined in
APIs of CLDC and MIDP, and is run by the Java virtual
machine (JVM). A J2ME application is a collection of
byte code classes packed into a Java Archive file (JAR).
However, it is also possible to use other platforms as
they provide a way to access the extended feature of the
SIM card. In J2ME, this feature is provided by the
optional Security and Trust Service API (SATSA)
package [10]. In the SATSA specifications,
communications with the SIM card applications is
defined via the APDU format of message exchange. In
J2ME, the Wireless Messaging API (WMA) [11]
provides the ability of sending and receiving SMS
messages. The J2ME environment does not contain the
cryptographic functions. However, the Lightweight API
of the Bouncy Castle [12] can be used for this purpose.
Obfuscators can also be used for both decreasing the
JAR size and hardening the reverse-engineering of the
produced codes. SSMS works on all Java enabled
mobile phones supporting WMA and MIDP 2.0.
The SSMS protocol consists of the initialization
phase, the message exchange phase in which the
participants exchange their secured short messages, and
the judge verification phase that is used when any
dispute occurs. The revocation phase can follow the
typical rules of Public Key Infrastructures (PKI) and
will not be considered in this paper.

2.1. Initialization

The initialization phase of the SSMS includes:
1) Selecting the domain parameters.
2) Registering the user details into the system,
generating the public/private keys, and issuing a
certificate for the public key of each user.
3) Installing the application software on the mobile
phone.
The domain parameters consist of a suitably chosen
elliptic curve E defined over the finite field
q
F with the
Weierstrass equation of the form b ax x y + + =
3 2
and a
base point ) (
q
F E Ge in which q is a large prime
number. In order to make the elliptic curve non-singular,
q
F b a e , should satisfy ) (mod 0 27 4
2 3
q b a = + . To
guard against small subgroup attacks [13], the point G
should be of prime order n ( O nG = where O denotes the
point of elliptic curve at infinity), and we should have
q n 4 > . To guarantee the intractability of ECDLP to
the Pollard-rho and Pohlig-Hellman algorithms [14],
160
2 > n is recommended. To protect against other
known attacks on special classes of elliptic curves, n
should not divide 1 ÷
i
q for all V i s s 1 ( 20 = V
suffices in practice [15]), q n = should be satisfied, and
the curve should be non-supersingular [13].
A strong block cipher such as AES is recommended
to be chosen for encrypting the messages. It will be used
in the core of SSMS protocol. It is also feasible to
provide a list of block ciphers and let the user choose the
suitable algorithm. However, it is not recommended
since it can increase the code size of the application.
The private key of user U is a randomly selected
integer ] 1 , 1 [ ÷ e n SK
R U
, and the corresponding public
key is generated as G SK PK
U U
= . Two different
approaches can be followed for the public/private key
generation:
1) Generating the public/private keys in a Key
Generating Server (KGS), as is depicted in Figure 1.
2) Generating the public/private keys in the ME, as is
depicted in Figure 2.
In the first approach that is recommended by the
SSMS, the public/private keys are directly and securely
stored on the SIM cards. The mobile phones are not
capable of generating very strong random numbers to be
used as strong private keys so the first approach is
preferred as it provides more security. The second
approach, on the other hand, has more flexibility and
may be suitable for some applications. However, several
precautions should be taken into account when using the
second approach: The Certificate Authority (CA) should
verify that each entity really possesses the corresponding
private key of its claimed public key. This may be
accomplished by a zero-knowledge technique. To thwart
the invalid-curve attacks, the CA server should also
check the validity of public keys [13].


Figure 1. When the key generation is taken
place in a KGS


Figure 2. When the key generation is taken
place in the ME

The CA server issues a certificate
U
Cert for the
public key of each user. The certificates contain strings
of information that uniquely identify users and bind their
identities to their public keys. The X.509v3 certificates
are a popular type of certificates that are extensively
used. Each user of the GSM network has several unique
identities such as IMSI, MSISDN, and etc. For making
the SSMS convenient, the unique international phone
number of each user (MSISDN) is chosen as his/her
identifier (ID
U
). The unique identifier, the public key,
and the corresponding certificate of each user are also
stored in an LDAP (Lightweight Directory Access
Protocol) directory, as is depicted in Figures 1 and 2.
It is assumed that the participants have access to an
authentic copy of the CA's public key, in order to use it
for the certificate validation. The private key is
encrypted and stored in an elementary file of the SIM
Card. The private key can be encrypted using a user's
password or PIN (Personal Identification Number). The
public keys can be stored in a transparent elementary
file. According to the GSM 11.11 standard, the trusted
keys and certificates (e.g. CA's) are stored in 4FXX
files. The key information can be stored in file 4F50.
The hash value of the private key that can be used for
validation of the encrypting password can also be stored
in the SIM Card.
The application can be purchased and be manually
installed on the mobile phone if the mobile phone is
capable of supporting such an application. It is also
feasible to download and install the application via an
Over-The-Air (OTA) server, as is depicted in Figure 3.
The Application Management Software (AMS) takes
care of downloading and installing the application on the
device. It is also feasible to combine the application
installation and key generation processes if the key
generation is to be done in the mobile phone [8].


Figure 3. Application installation via an OTA
Server

2.2. The Message Exchange

Alice as the sender or initiator of the protocol wants
to securely send her message M to Bob. Her message can
be a payment order and Bob may be a bank or a service
provider. SSMS is a certificate-based protocol so it is
necessary for both of participants to perform the
certificate validation [14] for the certificate of the other
party and use it for verifying the corresponding public
key. Since the Certificate Revocation List (CRL) is too
large for the limited memory capacity of mobile devices,
SSMS uses the Online Certificate Status Protocol
(OCSP) [16] for checking the revocation status of the
certificates. It has another advantage due to the online
and timely inquiry feature of the OCSP. However, the
OCSP server's duties in the SSMS differ from what is
specified in RFC 2560. The OCSP server in the SSMS
should also verify the public key of the corresponding
user if the queried certificate has a “good” status. The
result of such verification should be included in the
OCSP responses. The OCSP responses are digitally
signed with a private key that its corresponding trusted
public key is known to the participants. Basic
configuration of the SSMS protocol is depicted in Figure
4 in which OCSP
A
and OCSP
B
are the OCSP tokens for
the certificates of Alice and Bob. The message exchange
for the basic SSMS configuration is as follows.

SSMS Composing: Alice queries the OCSP server via
the Bob's phone number (ID
B
) for his public key and the
revocation status of his certificate by sending an SMS to
the gateway of the OCSP server. The OCSP server
produces an OCSP response, digitally signs it, and sends
(ID
B
, PK
B
, OCSP
B
) to Alice perhaps through SMS. Alice
verifies the OCSP server's signature and uses ID
B
and
PK
B
to generate ) , , ( s C R from the message M by
following the below steps:

(1) Randomly selects an integer ] 1 , 1 [ ÷ e n r
R
.
(2) Computes ) , (
R R
y x rG R = = .
(3) Computes ) , ( )
~
(
K K B A R
y x PK SK x r K = + = where
( (
) 2 mod ( 2
~ 2 / 2 / f
R
f
R
x x + = in which
¸ ¸
1 log
2
+ = n f . If O K = she goes back to step
(1). Otherwise, she drives the secret key of
encryption as ) || || || (
B K A K
ID y ID x H k ' = in which
H' is a one-way hash function that generates the
required number of bits for the secret key of the
deployed symmetric encryption (l bits).
(4) Computes the ciphertext as ) (M E C
k
= where E(.)
denotes the approved block cipher.
(5) Computes ) (modn r tSK s
A
÷ = where
) || || || || || ( k ID y ID x M H t
B R A R
= .
(6) Sends ) , , ( s C R to Bob through SMS.

The Short Message Center (SMC) of the network
operator automatically adds timestamps to the
exchanged short messages. A port number is also
assigned to the message indicating that the message is
intended for the SSMS application so the AMS will
automatically start the corresponding MIDlet upon
receiving the message.
Each short message can contain 140×8 bits of user
data. The GSM 03.38 standard [17] increases the
maximum length of a text-based SMS to 160 (7-bits)
characters. For the longer messages, new features such
as SMS concatenation and SMS compression have been
added in phase 2+ and are supported by the newer
mobile phones. It is possible to concatenate several short
messages to send messages or data records that are
longer than 140 bytes. Each segment of the short
message is still limited to 140 bytes but the receiving
application is alerted that the entire message is not
contained within one segment. The network handles
segments of a concatenated message like any other short
message and the relationship between the segments is
only made at the end-entities. Although it is theoretically
possible to concatenate 255 short messages, it is actually
limited to five or so [18].


Figure 4. Basic configuration of the SSMS
SSMS Delivering: Upon receiving an SSMS containing
) , , ( s C R , the AMS on the Bob side automatically starts
the SSMS application. The application may check
whether the timestamp resides in an acceptable time
window. It queries the OCSP server via the Alice's
phone number (ID
A
) for her public key and the
revocation status of her certificate by sending an SMS to
the gateway of the OCSP server. The OCSP server
produces an OCSP response, digitally signs it, and sends
(ID
A
, PK
A
, OCSP
A
) to Bob perhaps through SMS. The
SSMS application on the Bob side verifies the OCSP
server's signature and follows the following steps to
extract the Alice's message and verify her signature.

(1) Checks the validity of ) , (
R R
y x R = by verifying
that all the following conditions are satisfied.
Otherwise, he terminates the process with failure.
(1.1) O R = .
(1.2)
R
x and
R
y should have the proper format of
q
F elements.
(1.3) R should satisfy the defining equation of E.
(2) Computes ) , ( )
~
(
K K A R B
y x PK x R SK K = + = and
derives the secret key of encryption as
) || || || (
B K A K
ID y ID x H k ' = .
(3) Decrypts the received ciphertext as ) (C D M
k
= .
(4) Computes ) || || || || || ( k ID y ID x M H t
B R A R
= .
(5) Verifies whether
A
tPK R sG = + . If this is true, he
accepts M as the correct plaintext that is sent by Alice
and sends her a confirmation message M' perhaps in
addition to a tag ) (M MAC t
k
' = ' . Otherwise, he
rejects M and reports it as a malicious message to the
service provider.

Due to the processing and memory constraints,
delegating validations to a trusted server will offer
significant advantages. The required time of sending a
certificate to a validation server, receiving, and
authenticating the response can be considerably less than
the required time of performing the certificate path
discovery and validation. The SSMS performance can be
greatly improved by delegating the validation process to
a Delegated Validation (DV) server, as is depicted in
Figure 5. The DV server is completely independent of
the wireless network, e.g. GSM. It can be independently
provided by the m-payment service provider. The DV
server accomplishes the certificate validation via the
Delegated Path Validation (DPV) protocol [19].
However, its duties defer from what is specified in RFC
3379. All the short messages will be directed to the DV
server through the GSM network. The DV server
accomplishes the certificate and public key validations
for both sender and recipient. It queries the database
server for the certificates of participants via their
MSISDN. It obtains the revocation statuses by getting
OCSP responses from the OCSP server. It also checks
the validity of point R. The DV server will contact the
designated recipient (via SMS) after a successful
validation. If any error occurs, the DV server sends an
error message to the initiator and saves a copy in its log
file. According to the security policies, all the
transmitted messages may be separately saved by the
DV server for the possible disputes. The DV server
digitally signs its responses unless an error is occurred.
The signed responses should include a hash value of all
the transmitted parameters in addition to the identifiers
of both sender and recipient.
In the optimized SSMS configuration, the first step of
the basic SSMS delivering phase is omitted. Bob does
not check the validity of point R because it is checked by
the DV server. He just checks the DV server's signature.
Alice does not need to get any OCSP response for the
Bob's certificate. She just needs to know the public key
of Bob and save it in his phone for the future uses. If she
does not know the public key of Bob, she may query it
from the database server, as is depicted in Figure 5.
Therefore, the computational costs and communication
overheads are efficiently decreased by the optimized
SSMS configuration.


Figure 5. Optimized configuration of the SSMS
for the Customer-to-Customer (C2C) model

2.3. The Judge Verification in disputes

When Bob claims that he has received ) , , ( s C R from
Alice, the trusted third party (judge) wants him to
provide ) , , , , ( s k M C R . Bob simply extracts M and k
from the previously saved ) , , ( s C R . The judge follows
the following steps to decide on what Bob claims.

(1) Checks the validity of
A
Cert and uses it for
verifying
A
PK .
(2) Verifies whether ) (C D M
k
= . If this is not the case,
Bob is wrong.
(3) Computes ) || || || || || ( k ID y ID x M H t
B R A R
= .
(4) Verifies the Alice's signature by checking the
A
tPK R sG = + condition. If this is not the case, Bob
is wrong. Otherwise, Alice has sent ) , , ( s C R to Bob.

If the DV server saves the transmitted messages, the
judge as an additional proof may query the DV server to
confirm that Alice has sent a message containing
) , , ( s C R to Bob.

3. The Security of SSMS

The correctness of SSMS can be simply verified.
Alice and Bob reach to the same secret key of symmetric
encryption as:

= + = + = G SK SK x r PK SK x r K
B A R B A R A
)
~
( )
~
(

B A R B A R B
K PK x R SK G SK x rG SK = + = + = )
~
( )
~
(

The session key derivation function of the SSMS is
an improved version of the HMQV key establishment
protocol [20]. However, it does not exactly correspond
with the HMQV specifications. Defining
R
x
~
as the least
significant half in binary representation of
R
x is just a
trade-off between security and efficiency. The validation
of R in the SSMS delivering phase is accomplished to
prevent the invalid-curve attack. Hereunder, some
security attributes of the SSMS are briefly described.

1) Confidentiality: The confidentiality is completely
resided in the secrecy of session key since SSMS uses a
strong block cipher. The session key differs for different
sessions and is derived from the private keys of the
participants. The Unknown Key-Share (UKS) attack is
thwarted because the Alice's identifier is involved in
derivation of session key k. There are only two ways to
defeat the confidentiality: finding
B
SK , or having both
of
A
SK and r. Deducing the corresponding r of R is
generally in deposit of solving the Elliptic Curve
Discrete Logarithm Problem (ECDLP) that is
computationally infeasible with the chosen domain
parameters.

2) Authentication: The implicit authentication is
provided in three ways: both the participants verify the
certificate of the other party; only the legitimate parties
with the true private keys can reach to a correct key
agreement; and whenever the recipient verifies the
signature.

3) Unforgeability: It is computationally infeasible to
forge the signature of Alice without having her private
key
A
SK .

4) Integrity: The hash value of message, concatenated
with some variable parameters is involved in the
signature generation. The integrity is guarantied by the
security attributes of the deployed hash function and also
the unforgeability of the signature.

5) Non-repudiation: It can be easily deduced from the
unforgeability.

6) Forward secrecy of message confidentiality: As a
one-pass protocol, we cannot prospect SSMS for the
Perfect Forward Secrecy (PFS). However, if
A
SK is
revealed, the attacker cannot recover the previous
messages since he should know the respective random
number r of the corresponding session that is generally
in deposit of solving the ECDLP.

7) Public verifiability: Given ) , , , , ( s k M C R , anybody
can verify the signature without any need for the private
keys of the participants.

4. Conclusions

A new public key-based solution for secure SMS
messaging (SSMS) is introduced in this paper. It is an
application layer protocol that simultaneously provides
the confidentiality, integrity, authentication, non-
repudiation, public verification, and the forward secrecy
of message confidentiality. It efficiently combines
encryption and digital signature and uses public keys for
a secure key establishment to be used for encrypting the
short messages via a symmetric encryption. Since it
deploys elliptic curves and a symmetric encryption
algorithm, it has great computational advantages over
the previously proposed public key solutions while
simultaneously providing the most feasible security
services. It has great advantages to be used in the real m-
payment applications and whenever the secure SMS
messaging is important. However, its structure does not
reply on the SMS messaging and is suitable for any
other store-and-forward technology.

Acknowledgments

The authors would like to thank Iran
Telecommunication Research Center (ITRC) for
supporting this work by a grant.

5. References

[1] GSM World News-Statistics: http://www.gsmworld.com/
news/statistics/index.shtml. Access date: Jan. 23 2008.
[2] M.V. Werff, X. Gui, and W.L. Xu, “A Mobile-based Home
Automation System,” 2
nd
IEEE International Conference
on Mobile Technology, pp.1-5, Nov. 2005.
[3] B. Dukić, and M. Katić, “m-Order – Payment Model via
SMS within the m-Banking,” 27
th
IEEE International
Conference on Information Technology Interfaces, pp.93-
98, June 2005.
[4] S.M. Siddique, and M. Amir, “GSM Security Issues and
Challenges,” 7
th
IEEE International Conference on
Software Engineering, Artificial Intelligence, Networking
and Parallel/Distributed Computing (SNPD'06), pp.413-
418, June 2006.
[5] W. Itani, and A.I. Kayssi, “J2ME end-to-end security for
M-commerce,” IEEE Wireless Communications and
Networking Conference (WCNC'03), Vol.3, pp.2015-2020,
March 2003.
[6] M. Hassinen, “SafeSMS – End-to-end encryption for SMS
messages,” 8
th
IEEE International Conference on
Telecommunications (ConTEL'05), Vol.2, pp.359-365,
June 2005.
[7] M. Hassinen, and K. Hypponen, “Strong Mobile
Authentication,” 2
nd
IEEE International symposium on
wireless communication systems, pp.96-100, Sept. 2005.
[8] M. Hassinen, “Java based Public Key Infrastructure for
SMS Messaging,” 2
nd
IEEE Conference on Information
and Communication Technologies (ICTTA'06), Vol.1,
pp.88-93, April 2006.
[9] 3GPP TS 03.48, Digital cellular telecommunications
system (Phase 2+); Security mechanisms for SIM
application toolkit, Stage 2, version 8.8.0, 1999.
[10] Java Community Process: JSR-000177 Security and
Trust Services API for J2ME. http://www.jcp.org/
aboutJava /communityprocess/final/jsr177.
[11] Java Community Process: JSR-000120 Wireless
Messaging API. http://www.jcp.org/aboutJava/
communityprocess/final/jsrl20
[12] Legion of the Bouncy Castle:
http://www.bouncycastle.org
[13] D. Hankerson, A. Menezes, and Scott Vanstone, “Guide
to Elliptic Curve Cryptography,” Springer-Verlag, New
York, 2004.
[14] D.R. Stinson, “Cryptography-Theory and Practice,” 3
rd

edition, Chapman & Hall/CRC, 2006.
[15] ANSI X9.62, “The Elliptic Curve Digital Signature
Algorithm (ECDSA),” 1999.
[16] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C.
Adams, “X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol – OCSP”, RFC 2560, June
1999. Available at: http://www.ietf.org/rfc/ rfc2560.txt
[17] GSM 03.38 Digital cellular telecommunications system
(Phase 2+); Alphabets and language-specific information.
European Telecommunications Standards Institute
(ETSI).
[18] S.B. Guthery, and M.J. Cronin, “Mobile Application
Development with SMS and the SIM Toolkit,” McGraw-
Hill, 2002.
[19] D. Pinkas, and R. Housley, “Delegated Path Validation
and Delegated Path Discovery Protocol Requirements,”
RFC 3379, Sept. 2002. Available at:
http://www.ietf.org/rfc/rfc3379.txt
[20] H. Krawczyk, “HMQV: A high-performance secure
Diffie-Hellman protocol,” Advances in Cryptology –
CRYPTO'05, LNCS 3621, pp.546-566, Springer-Verlag,
2005.

The J2ME environment does not contain the cryptographic functions. The MIDlet uses classes defined in APIs of CLDC and MIDP. the point G should be of prime order n ( nG  O where O denotes the point of elliptic curve at infinity). Obfuscators can also be used for both decreasing the JAR size and hardening the reverse-engineering of the produced codes. However.1. this feature is provided by the optional Security and Trust Service API (SATSA) package [10]. it is also possible to use other platforms as they provide a way to access the extended feature of the SIM card. The revocation phase can follow the typical rules of Public Key Infrastructures (PKI) and will not be considered in this paper. and we should have n  4 q . the Lightweight API of the Bouncy Castle [12] can be used for this purpose. A J2ME application is a collection of byte code classes packed into a Java Archive file (JAR). and is run by the Java virtual machine (JVM). J2ME is a runtime environment designed for resource restricted devices such as mobile phones and Personal Digital Assistants (PDA). has more flexibility and may be suitable for some applications. the Wireless Messaging API (WMA) [11] provides the ability of sending and receiving SMS messages. The Proposed Scheme (SSMS) A brief description of our SSMS protocol is provided in this section. it is not recommended since it can increase the code size of the application. and the judge verification phase that is used when any dispute occurs. In J2ME. The mobile phones are not capable of generating very strong random numbers to be used as strong private keys so the first approach is preferred as it provides more security. However. The private key of user U is a randomly selected integer SKU R [1. It is also feasible to provide a list of block ciphers and let the user choose the suitable algorithm. 5) A portable PC (laptop) connected to the ME.0. communications with the SIM card applications is defined via the APDU format of message exchange. To guard against small subgroup attacks [13]. n  2160 is recommended. 2) The SIM card using SAT. It will be used in the core of SSMS protocol. This may be accomplished by a zero-knowledge technique. as is depicted in Figure 2. In the first approach that is recommended by the SSMS. However. 3) Installing the application software on the mobile phone. To guarantee the intractability of ECDLP to the Pollard-rho and Pohlig-Hellman algorithms [14]. 2. . b  Fq should satisfy 4a 3  27b2  0(mod q ) . and the corresponding public key is generated as PKU  SKU G . In J2ME. and the curve should be non-supersingular [13]. a. A strong block cipher such as AES is recommended to be chosen for encrypting the messages. the message exchange phase in which the participants exchange their secured short messages. as is depicted in Figure 1. To thwart the invalid-curve attacks. In the SATSA specifications. 2) Generating the public/private keys in the ME. The end-to-end security in the cellular systems can be generally provided by exploiting the processing capabilities of one or some of the following items: 1) The Mobile Equipment (ME) using the programming languages.g. The second approach. n  q should be satisfied. the CA server should also check the validity of public keys [13]. Initialization The initialization phase of the SSMS includes: 1) Selecting the domain parameters. The SSMS protocol consists of the initialization phase. It suggests using J2ME (Java 2 Mobile Edition) as the programming platform. 3) An additional smart card. JavaCard. e. A MIDlet is a program developed in J2ME. SSMS works on all Java enabled mobile phones supporting WMA and MIDP 2. n  1] . The domain parameters consist of a suitably chosen elliptic curve E defined over the finite field Fq with the Weierstrass equation of the form y 2  x3  ax  b and a base point G  E ( Fq ) in which q is a large prime number.2. However. on the other hand. and issuing a certificate for the public key of each user. generating the public/private keys. Two different approaches can be followed for the public/private key generation: 1) Generating the public/private keys in a Key Generating Server (KGS). To protect against other known attacks on special classes of elliptic curves. In order to make the elliptic curve non-singular. n should not divide q i  1 for all 1  i  V ( V  20 suffices in practice [15]). The SSMS provides the end-to-end security and is based on the first solution. and Mobile Information Device Profile (MIDP). 4) A crypto-processor that is embedded in the ME. 2) Registering the user details into the system. It consists of Connected Limited Device Configuration (CLDC). several precautions should be taken into account when using the second approach: The Certificate Authority (CA) should verify that each entity really possesses the corresponding private key of its claimed public key. the public/private keys are directly and securely stored on the SIM cards.

However. SSMS is a certificate-based protocol so it is necessary for both of participants to perform the certificate validation [14] for the certificate of the other party and use it for verifying the corresponding public key. The OCSP server in the SSMS should also verify the public key of the corresponding user if the queried certificate has a “good” status. It is assumed that the participants have access to an authentic copy of the CA's public key. When the key generation is taken place in the ME The CA server issues a certificate CertU for the public key of each user. The OCSP server produces an OCSP response.11 standard. PKB. Her message can be a payment order and Bob may be a bank or a service provider.2. Each user of the GSM network has several unique identities such as IMSI. The OCSP responses are digitally signed with a private key that its corresponding trusted public key is known to the participants. in order to use it for the certificate validation. It has another advantage due to the online and timely inquiry feature of the OCSP. Alice verifies the OCSP server's signature and uses IDB and Figure 2. OCSPB) to Alice perhaps through SMS. The X. The private key can be encrypted using a user's password or PIN (Personal Identification Number). SSMS uses the Online Certificate Status Protocol (OCSP) [16] for checking the revocation status of the certificates. MSISDN.509v3 certificates are a popular type of certificates that are extensively used. According to the GSM 11. The certificates contain strings of information that uniquely identify users and bind their identities to their public keys. When the key generation is taken place in a KGS The application can be purchased and be manually installed on the mobile phone if the mobile phone is capable of supporting such an application. digitally signs it. Basic configuration of the SSMS protocol is depicted in Figure 4 in which OCSPA and OCSPB are the OCSP tokens for the certificates of Alice and Bob. and etc. Figure 3. the OCSP server's duties in the SSMS differ from what is specified in RFC 2560. For making the SSMS convenient. The unique identifier. Application installation via an OTA Server 2. and sends (IDB.g. The public keys can be stored in a transparent elementary file. as is depicted in Figure 3. SSMS Composing: Alice queries the OCSP server via the Bob's phone number (IDB) for his public key and the revocation status of his certificate by sending an SMS to the gateway of the OCSP server. Since the Certificate Revocation List (CRL) is too large for the limited memory capacity of mobile devices. The Message Exchange Alice as the sender or initiator of the protocol wants to securely send her message M to Bob. the public key. The result of such verification should be included in the OCSP responses. as is depicted in Figures 1 and 2. It is also feasible to combine the application installation and key generation processes if the key generation is to be done in the mobile phone [8]. and the corresponding certificate of each user are also stored in an LDAP (Lightweight Directory Access Protocol) directory. The message exchange for the basic SSMS configuration is as follows.Figure 1. The hash value of the private key that can be used for validation of the encrypting password can also be stored in the SIM Card. The key information can be stored in file 4F50. the trusted keys and certificates (e. It is also feasible to download and install the application via an Over-The-Air (OTA) server. the unique international phone number of each user (MSISDN) is chosen as his/her identifier (IDU). The Application Management Software (AMS) takes care of downloading and installing the application on the device. . The private key is encrypted and stored in an elementary file of the SIM Card. CA's) are stored in 4FXX files.

If this is true. It can be independently provided by the m-payment service provider. The application may check whether the timestamp resides in an acceptable time window.g.3) R should satisfy the defining equation of E. y K ) and x derives the secret key of encryption as k  H ( x K || ID A || y K || IDB ) . (5) Computes s  tSK A  r (mod n ) where t  H ( M || x R || ID A || y R || IDB || k ) . SSMS Delivering: Upon receiving an SSMS containing ( R. y K ) where x ~  2  f / 2   ( x mod 2  f / 2  ) xR in which R f  log 2 n   1 . delegating validations to a trusted server will offer significant advantages. y R ) by verifying that all the following conditions are satisfied. C . the AMS on the Bob side automatically starts the SSMS application.2) x R and y R should have the proper format of Fq elements. e. (6) Sends ( R. It queries the database server for the certificates of participants via their MSISDN. The SSMS application on the Bob side verifies the OCSP server's signature and follows the following steps to extract the Alice's message and verify her signature. However.1) R  O . For the longer messages. It queries the OCSP server via the Alice's phone number (IDA) for her public key and the revocation status of her certificate by sending an SMS to the gateway of the OCSP server. he accepts M as the correct plaintext that is sent by Alice and sends her a confirmation message M' perhaps in addition to a tag t   MACk (M ) . The network handles segments of a concatenated message like any other short message and the relationship between the segments is only made at the end-entities. (1) Checks the validity of R  ( x R . A port number is also assigned to the message indicating that the message is intended for the SSMS application so the AMS will automatically start the corresponding MIDlet upon receiving the message. The required time of sending a certificate to a validation server. The SSMS performance can be greatly improved by delegating the validation process to a Delegated Validation (DV) server. (1. The GSM 03. s ) from the message M by following the below steps: (1) Randomly selects an integer r R [1. (4) Computes the ciphertext as C  Ek ( M ) where E(. The Short Message Center (SMC) of the network operator automatically adds timestamps to the exchanged short messages. The DV server accomplishes the certificate validation via the Delegated Path Validation (DPV) protocol [19]. The DV server accomplishes the certificate and public key validations for both sender and recipient. as is depicted in Figure 5. The OCSP server produces an OCSP response. OCSPA) to Bob perhaps through SMS. Basic configuration of the SSMS . If K  O she goes back to step (1). n  1] . and authenticating the response can be considerably less than the required time of performing the certificate path discovery and validation. s ) . Otherwise. (4) Computes t  H ( M || x R || ID A || y R || IDB || k ) .PKB to generate ( R. she drives the secret key of encryption as k  H ( x K || ID A || y K || ID B ) in which H' is a one-way hash function that generates the required number of bits for the secret key of the deployed symmetric encryption (l bits). (2) Computes R  rG  ( x R . GSM.) denotes the approved block cipher. (5) Verifies whether sG  R  tPK A . (3) Computes K  ( r  ~R SK A ) PK B  ( x K . Each segment of the short message is still limited to 140 bytes but the receiving application is alerted that the entire message is not contained within one segment. new features such as SMS concatenation and SMS compression have been added in phase 2+ and are supported by the newer mobile phones. C . All the short messages will be directed to the DV server through the GSM network. receiving. Otherwise. (1.38 standard [17] increases the maximum length of a text-based SMS to 160 (7-bits) characters. he terminates the process with failure. C . The DV server is completely independent of the wireless network. y R ) . s ) to Bob through SMS. its duties defer from what is specified in RFC 3379. (2) Computes K  SK B ( R  ~R PK A )  ( x K . he rejects M and reports it as a malicious message to the service provider. PKA. it is actually limited to five or so [18]. Due to the processing and memory constraints. Although it is theoretically possible to concatenate 255 short messages. (3) Decrypts the received ciphertext as M  Dk (C ) . It is possible to concatenate several short messages to send messages or data records that are longer than 140 bytes. (1. Otherwise. Each short message can contain 140×8 bits of user data. and sends (IDA. digitally signs it. It obtains the revocation statuses by getting Figure 4.

2) Authentication: The implicit authentication is provided in three ways: both the participants verify the certificate of the other party. The integrity is guarantied by the security attributes of the deployed hash function and also the unforgeability of the signature. s ) . s ) to Bob. If the DV server saves the transmitted messages. Alice does not need to get any OCSP response for the Bob's certificate. s ) to Bob. If she does not know the public key of Bob. However. C . The DV server will contact the designated recipient (via SMS) after a successful validation. Alice has sent ( R. the computational costs and communication overheads are efficiently decreased by the optimized SSMS configuration.3. 4) Integrity: The hash value of message. She just needs to know the public key of Bob and save it in his phone for the future uses. Bob is wrong. Defining ~R as the least significant half in binary representation of x R is just a trade-off between security and efficiency. the DV server sends an error message to the initiator and saves a copy in its log file. it does not exactly correspond x with the HMQV specifications. C . Figure 5. (4) Verifies the Alice's signature by checking the sG  R  tPK A condition. The Security of SSMS The correctness of SSMS can be simply verified. According to the security policies. Deducing the corresponding r of R is generally in deposit of solving the Elliptic Curve Discrete Logarithm Problem (ECDLP) that is computationally infeasible with the chosen domain parameters. M . Alice and Bob reach to the same secret key of symmetric encryption as: K A  ( r  ~R SK A ) PK B  ( r  ~R SK A ) SK BG  x x ~ SK G )  SK ( R  ~ PK )  K  SK B ( rG  x R A xR A B B The session key derivation function of the SSMS is an improved version of the HMQV key establishment protocol [20]. (1) Checks the validity of Cert A and uses it for verifying PK A . The Judge Verification in disputes When Bob claims that he has received ( R. and whenever the recipient verifies the signature. (3) Computes t  H ( M || x R || ID A || y R || IDB || k ) . C . s ) from Alice. concatenated with some variable parameters is involved in the signature generation. If any error occurs. some security attributes of the SSMS are briefly described. the trusted third party (judge) wants him to provide ( R. The judge follows the following steps to decide on what Bob claims. 1) Confidentiality: The confidentiality is completely resided in the secrecy of session key since SSMS uses a strong block cipher. In the optimized SSMS configuration. 3. 5) Non-repudiation: It can be easily deduced from the unforgeability. The DV server digitally signs its responses unless an error is occurred. Otherwise. C . Optimized configuration of the SSMS for the Customer-to-Customer (C2C) model 2. the first step of the basic SSMS delivering phase is omitted. only the legitimate parties with the true private keys can reach to a correct key agreement. He just checks the DV server's signature. Therefore. The session key differs for different sessions and is derived from the private keys of the participants. s ) . (2) Verifies whether M  Dk (C ) . The Unknown Key-Share (UKS) attack is thwarted because the Alice's identifier is involved in derivation of session key k. C . Bob does not check the validity of point R because it is checked by the DV server. The validation of R in the SSMS delivering phase is accomplished to prevent the invalid-curve attack. Bob is wrong. Hereunder. she may query it from the database server. Bob simply extracts M and k from the previously saved ( R. k . as is depicted in Figure 5.OCSP responses from the OCSP server. the judge as an additional proof may query the DV server to . all the transmitted messages may be separately saved by the DV server for the possible disputes. confirm that Alice has sent a message containing ( R. If this is not the case. 3) Unforgeability: It is computationally infeasible to forge the signature of Alice without having her private key SK A . It also checks the validity of point R. There are only two ways to defeat the confidentiality: finding SK B . The signed responses should include a hash value of all the transmitted parameters in addition to the identifiers of both sender and recipient. If this is not the case. or having both of SK A and r.

96-100. and K. [4] S. Stinson. 1999. [18] S.L. pp.V. Krawczyk. 2002. June 2005. New York.3. it has great computational advantages over the previously proposed public key solutions while simultaneously providing the most feasible security services. 2004. we cannot prospect SSMS for the Perfect Forward Secrecy (PFS).” RFC 3379. [10] Java Community Process: JSR-000177 Security and Trust Services API for J2ME. Menezes. Springer-Verlag. [7] M. [6] M. Digital cellular telecommunications system (Phase 2+).” 27th IEEE International Conference on Information Technology Interfaces.ietf. European Telecommunications Standards Institute (ETSI). http://www. Vol. . [3] B.R.2. Chapman & Hall/CRC. Sept. Available at: http://www. Amir. and M. M . “Guide to Elliptic Curve Cryptography. 5.1-5. its structure does not reply on the SMS messaging and is suitable for any other store-and-forward technology.88-93. and R. June 1999. “m-Order – Payment Model via SMS within the m-Banking. “J2ME end-to-end security for M-commerce.1.546-566. nonrepudiation.” McGrawHill.” 8th IEEE International Conference on Telecommunications (ConTEL'05). anybody can verify the signature without any need for the private keys of the participants. RFC 2560. Kayssi.38 Digital cellular telecommunications system (Phase 2+). “Cryptography-Theory and Practice. Hankerson. Security mechanisms for SIM application toolkit.” 2nd IEEE International Conference on Mobile Technology. public verification.jcp. authentication.” 2nd IEEE Conference on Information and Communication Technologies (ICTTA'06). 23 2008. [8] M. Alphabets and language-specific information. Hassinen. pp.org/ aboutJava /communityprocess/final/jsr177.2015-2020.9398. 2005.” Springer-Verlag.” 2nd IEEE International symposium on wireless communication systems.” 7th IEEE International Conference on Software Engineering.bouncycastle. However. “Delegated Path Validation and Delegated Path Discovery Protocol Requirements. Networking and Parallel/Distributed Computing (SNPD'06).M. Cronin. pp.ietf. X.I.B. Available at: http://www. s ) .359-365. pp.com/ news/statistics/index. 2005. [5] W. Itani. Galperin.48. and W. Sept. 7) Public verifiability: Given ( R. 4. [16] M. S. Stage 2. “HMQV: A high-performance secure Diffie-Hellman protocol.jcp. the attacker cannot recover the previous messages since he should know the respective random number r of the corresponding session that is generally in deposit of solving the ECDLP. June 2006.413418. 2005. Gui. Acknowledgments The authors would like to thank Iran Telecommunication Research Center (ITRC) for supporting this work by a grant.org [13] D.” 1999.” Advances in Cryptology – CRYPTO'05. Malpani. and the forward secrecy of message confidentiality. 2002. Dukić. if SK A is revealed. Nov. R. pp. k . “SafeSMS – End-to-end encryption for SMS messages. pp. It has great advantages to be used in the real mpayment applications and whenever the secure SMS messaging is important.txt [17] GSM 03.org/rfc/ rfc2560. However. and C.8. 2006. LNCS 3621.6) Forward secrecy of message confidentiality: As a one-pass protocol. Access date: Jan. It is an application layer protocol that simultaneously provides the confidentiality.org/aboutJava/ communityprocess/final/jsrl20 [12] Legion of the Bouncy Castle: http://www. “GSM Security Issues and Challenges. and Scott Vanstone. Myers. version 8. http://www. Katić. Hypponen. Vol. Ankney. and M. “A Mobile-based Home Automation System.shtml. “Strong Mobile Authentication. Pinkas. It efficiently combines encryption and digital signature and uses public keys for a secure key establishment to be used for encrypting the short messages via a symmetric encryption. Since it deploys elliptic curves and a symmetric encryption algorithm. “X.” IEEE Wireless Communications and Networking Conference (WCNC'03).org/rfc/rfc3379. Vol.txt [20] H. pp. [2] M.gsmworld. [19] D. [15] ANSI X9. “Java based Public Key Infrastructure for SMS Messaging. C . Hassinen. Adams. References [1] GSM World News-Statistics: http://www. Werff. pp. [11] Java Community Process: JSR-000120 Wireless Messaging API.62. Siddique. [9] 3GPP TS 03. Xu. Guthery.509 Internet Public Key Infrastructure Online Certificate Status Protocol – OCSP”. and M.J. “Mobile Application Development with SMS and the SIM Toolkit. “The Elliptic Curve Digital Signature Algorithm (ECDSA). June 2005. Hassinen.0. A. integrity. [14] D. and A. April 2006. Artificial Intelligence.” 3rd edition. Conclusions A new public key-based solution for secure SMS messaging (SSMS) is introduced in this paper. March 2003. Housley. A.