A mobile network operator-independent mobile signature service

Journal of Network and Computer Applications 34 (2011) 294–311

Contents lists available at ScienceDirect

Journal of Network and Computer Applications journal homepage: www.elsevier.com/locate/jnca

A mobile network operator-independent mobile signature service Antonio Ruiz-Martı´nez n, Juan Sa´nchez-Montesinos, Daniel Sa´nchez-Martı´nez Department of Information and Communications Engineering, University of Murcia, 30100 Murcia, Spain

a r t i c l e in f o

a b s t r a c t

Article history: Received 29 December 2009 Received in revised form 23 April 2010 Accepted 8 July 2010

Electronic signature (e-signature) is an important element in electronic commerce and government applications because it guarantees non-repudiation of transactions. E-signatures generated in a secure signature creation device can be considered legally equivalent to a handwritten signature. Mobile devices based on SIM/USIM cards, which are broadly extended, are the ideal devices to create these esignatures (named mobile signatures or m-signatures). Furthermore, thanks to m-signatures the development of m-signature-based applications becomes simpler for mobile application/service providers. There are several solutions to create m-signatures. However, current solutions present some problems: either they require that the solution is developed by every mobile network operator or the components to implement it in the mobile handset are too complex. As a solution to these problems we present an m-signature service that is not linked to a mobile network operator and where the client has more control over the signatures to perform them in an easier way. This paper presents the description and analysis of this new m-signature service as well as the prototype that is being tested in the University of Murcia. & 2010 Elsevier Ltd. All rights reserved.

Keywords: Electronic signature Mobile signature Smart card SIM Web services

1. Introduction Electronic signature (e-signature) is fundamental in fields such as electronic commerce and government since it provides some interesting features such as integrity, authentication and nonrepudiation (Ford and Baum, 1997; Sherif, 2000). For this reason, nowadays a great number of different applications require the use of e-signature and non-repudiation services such as (mobile) ¨ electronic payment systems (Hassinen and Hypponen Haataja, 2006), certified e-mail (Asokan Schunter, 2009), contract signing protocols (Asokan Schunter, 2009; Chadha et al., 2005; RuizMartı´nez et al., 2009), e-auctions (Lee et al., 2009), long-term preservation of documents (Blaicˇ et al., 2007), e-procurement (Liao et al., 2002), e-invoices (Kaliontzoglou et al., 2006), etc. The purpose of the e-signature is to guarantee the authenticity and integrity of electronic documents in a way equivalent to the handwritten signature in paper documents (Rossnagel, 2004; Ruiz-Martı´nez et al., 2007). In Europe, the directive 1999/93/EC of the European Parliament and the Council (Directive 1999/93/EC of the European Parliament and the council of December 1999 on a Community framework for electronic signatures, 1999) establishes the conditions that the electronic signature should fulfill in order to be considered legally equivalent to the handwritten signature. Basically, these conditions are two: first, the signature is

n

Corresponding author: Tel.: + 34 868 88 78 63. E-mail addresses: [email protected] (A. Ruiz-Martı´nez), [email protected] (J. Sa´nchez-Montesinos), [email protected] (D. Sa´nchez-Martı´nez). 1084-8045/$ - see front matter & 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.jnca.2010.07.003

generated in a Secure Signature Creation Device (SSCD) that satisfies Evaluation Assurance Level (EAL) 4+ specification (European Committee For Standardization (CEN), 2004) and, second, the signatures are based on the use of qualified certificates. Thus, the e-signatures that satisfy these criteria are named qualified electronic signatures (qualified e-signatures or simply qualified signatures) (Rossnagel, 2004; Rossnagel and Royer, 2005). Some of the devices that can be considered SSCD are some cryptographic smart cards (Domingo-Ferrer et al., 2007), such as a Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM). A deeper analysis on qualified signatures can be found in (Rossnagel, 2004; Rossnagel and Royer, 2005). SIMs/USIMs, under EAL 4+ specification, have been considered SSCD because they are tamper-resistant devices that can be used as a trusted storage for the private key (where the key never leaves it) as well as other security-related information (Kalman and Noll, 2007; Mayes and Markantonakis, 2008; Roßnagel and Muntermann, 2009). Furthermore, they can be used to provide other security and trust management services such as multiple identities, exchange of keys, mobile real-time services, etc. (Kalman and Noll, 2007; Mayes and Markantonakis, 2008; Roßnagel and Muntermann, 2009; Rust et al., 2008). Currently mobile handsets (mobile phones, personal digital assistants, etc.) are broadly extended. In fact, in developed countries almost everybody has a mobile handset and almost everybody has it on them all the time (Ruiz-Martı´nez et al., 2007). As these devices, in general, contain a SIM/USIM card they can be certified as SSCD. An analysis on the technologies that can be used to generate qualified e-signatures on these devices can be found in (Ruiz-Martı´nez et al., 2007, 2009b).

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

Thus, e-signature-based mobile applications could be developed for these devices. Even more, there could be desktop/server applications that could contact with these devices to request a signature. Thus, any user would be able to use any application that requires an e-signature. This kind of signature is named mobile signature (m-signature) (European Telecommunications Standards Institute (ETSI), 2003a). Mobile signature was proposed as ‘‘a universal method for using a mobile device to confirm the intention of a citizen to proceed with a transaction’’ (European Telecommunications Standards Institute (ETSI), 2003a). Thus, it is proposed as a solution that can be used in any application. Furthermore, thanks to the fact that the signature is generated in a mobile device, it may be used everywhere, everytime. Finally, the mobile signature is designed so that application providers do not have to develop multiple solutions for the wide range of mobile handsets, mobile operating systems and e-signature technologies that exist for mobile devices (Ruiz-Martı´nez et al., 2007, 2009b). In fact, these features have led Forrester Research to conclude that this technology could become a great success in the future since mobile signature could transform a mobile handset into an extension of our handwritten signatures or an identity card (Mobile signatures a success claims research, Card Technology Today, 2008). Furthermore, this technology can provide additional revenues for the Mobile Network Operators (MNOs) as analyzed in (Rossnagel and Royer, 2005) since there is a higher exchange of data in their networks. Moreover, m-signature can be used to provide another security services such as mobile authentication, service identity signing, etc. (Rust et al., 2008; Schnake et al., 2008). Several solutions, such as server-based signatures (Bicakci Baykal, 2003, 2004, 2005; Ding et al., 2002), the Mobile Signature Service (MSS) (European Telecommunications Standards Institute (ETSI) 2003a, b, c, d) proposed by the European Telecommunications Standard Institute (ETSI) and the Mobile Signature Application Unit (MSAU) (Pisko, 2007) have appeared to provide mobile signature. However, these solutions present several limitations we mention next: the server-based signatures cannot be considered legally equivalent to the handwritten signatures (RuizMartı´nez et al., 2007, 2009b), the MSS proposal would require that every Mobile Network Operator supported it in order to provide a universal solution and, finally, the solution proposed in the MSAU (Pisko, 2007) is limited to the use of mobile handsets with Java Micro Edition (ME), previously Java 2 Micro Edition (J2ME) and Security and Trust Services API for J2ME (SATSA) (JSR 177 Expert Group, 2007). Furthermore, it does not define an standardized interface for the invocation of the MSAU (Ruiz-Martı´nez et al., 2009b). As a response to the problems we have just mentioned, we have decided to propose a new service that improves the previous proposals in order to provide mobile signatures. From our proposal we can point out several features. First, it does not require its implementation by every MNO because we do not define roaming mechanisms. In our proposal, the user receives the signature requests directly from the mobile signature service. This service can be used by users of different MNOs. Second, the user has more control on the signature process. The user decides when to receive the request to be signed, unlike the other proposals where the mobile signature service has the control. Third, our proposal is based on the MSS proposal (and in its security mechanisms) to facilitate the migration from that architecture to ours. Fourth, in our proposal all the information is exchanged in a secure way. Finally, our solution has been developed and it is being tested in the University of Murcia. The scenario where it is being used allows the (associate/assistant) professors and lecturers to sign the final marks of their pupils and

295

send them to the faculty department to incorporate them to the file of each user. This paper is organized as follows. In Section 2, we describe background information and related work about current proposals for providing mobile signature. In Section 3, we describe the mobile signature service that we propose to overcome limitations of previous work, we analyze its security and we present some scenarios of use. Section 4 describes our implementation of the mobile signature service. In Section 5, we present the scenario that we have developed where this service is being tested. Finally, Section 6 summarizes the contributions of this paper and introduces some open issues.

2. Related work Due to the fact that mobile handsets are broadly extended, these can be seen as the ideal device to carry our private keys and certificates allowing us to produce e-signatures (Kalman and Noll, 2007; Rust et al., 2008). Thus, we could generate e-signatures and perform transactions anytime, everywhere. This idea has been named mobile signature and it is defined as a universal method to confirm a transaction (European Telecommunications Standards Institute (ETSI), 2003a). As analyzed in (Ruiz-Martı´nez et al., 2007, 2009b), the technologies for using electronic signatures in mobile devices are becoming available and mature. The principal problem for the developers of m-signature-based applications/services (MASPs) is that there are many different kinds of mobile handsets with different operating systems and technologies for providing m-signatures (Ruiz-Martı´nez et al., 2007, 2009b). Therefore, they have to develop many software solutions whether they want to reach an important number of users (critical mass). Solutions such as server-based signatures (Bicakci Baykal, 2003, 2004, 2005; Ding et al., 2002), Mobile Signature Service (European Telecommunications Standards Institute (ETSI), 2003a) and MSAU (Pisko, 2007) have been proposed as a solution to this problem. In the following sections we provide a brief description and analysis of each solution. 2.1. Server-based solutions Some time ago mobile devices were handsets with very limited computational resources and that in many cases were not able to use asymmetric cryptography. As a solution, more powerful devices such as a computer on a remote place, that is, a server, are introduced to produce msignatures. In this scenario the mobile handset is used to confirm the generation of the m-signature by the user. Thus, the user authorizes the m-signature by the introduction of a secret code, the generation of a Message Authentication Code (MAC) or OneTime Signature (OTS), which is used to protect the access to her private key in the server. This kind of solutions are named serverbased solutions (European Telecommunications Standards Institute (ETSI), 2003a; Ding et al., 2002). The general process of generating an m-signature according to this approach is as follows: 1. The user or a service or an application requests a signature to the signing server. 2. The signing server requests a signature authorization to the mobile handset. 3. The user confirms the generation of the e-signature by introducing a password or Personal Identifier Number (PIN) and the mobile device generates a MAC or an OTS.

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

296

4. Whether the MAC or OTS received is verified, the signing server generates the signature and sends it to the service or application.

 MSS_Profile. It provides information on the profile associated to 

Server-based solutions are an interesting approach because they can be developed in any mobile device since the requirements of computational resources are minimal and affordable for every device in the market. The main drawback of this kind of proposals is that the m-signature cannot be considered a qualified e-signature. This is due to the fact that the signature is not generated under the sole control of the user since it is generated in the server (Ruiz-Martı´nez et al., 2007, 2009b). 2.2. Mobile signature service The European Technical Standard Institute defined the specification named Mobile Signature Service (European Telecommunications Standards Institute (ETSI) 2003a, b, c, d). The purpose of this specification is to facilitate the development of mobile signature-based services/applications to MASPs. In this specification they defined an entity named Mobile Signature Service Provider (MSSP) that is associated to an MNO. This entity could be developed by the MNO or by an entity in which the MNO trusts. Each end-user has to be registered with the MSSP associated to its MNO to use the service. The MSSP is responsible for receiving signature requests from the MASP and, then, it contacts with the mobile handset and obtains the user’s signature, that is, MSSP-oriented. In the event the signature request is not for one of its users, this entity forwards the request to the roaming MSSP. This latter entity is responsible for contacting the MSSP associated to the MNO of the user the MASP is requesting the signature of. When the request arrives at the user’s MSSP, it requests the user’s signature, which is sent back through the roaming MSSP service to the initial MSSP. Finally, the MSSP provides the m-signature to the MASP. The MSSP has defined two working modes for providing a signature to a MASP: the synchronous mode and the asynchronous mode. In the synchronous mode the MASP sends the request to the MSSP service as we have just described and the m-signature is sent as a response to the request. The asynchronous mode is used when the m-signature cannot be received in a short period of time after the request. Hence, the service returns a response indicating that this m-signature will be provided later. Depending on the functionality supported by the MASP, MASP could either be notified when the m-signature is available or it would have to use a status query, from time to time, to check when the m-signature is available. Apart from requesting m-signatures to the mobile handsets, the MSSP can also provide other value-added services such as time-stamping. A deeper analysis of this solution can be found in (Ruiz-Martı´nez et al., 2007, 2009b). The different operations that the ETSI defines in its service are briefly commented next. This description is provided because most of these operations will be incorporated to our proposal. These operations are:

 MSS_Signature. The MASP invokes this operation to request the

 

MSSP the m-signature from a user. In the synchronous mode, it returns the m-signature. In the asynchronous mode, it returns a state indicating the request is being processed. MSS_StatusQuery. This operation is provided to check the status of a transaction and obtain the m-signature when the operation is finished (in the asynchronous mode). MSS_Registration. It allows the registration of a user in the MSSP through the MASP.



a mobile user as well as information about mobile system signature capabilities. MSS_Handshake. The exchange between the MASP and MSSP of the security options supported and that are going to be used in a transaction is established by means of this operation. Thus, they describe how the communication is protected. MSS_Receipt. This optional operation is invoked by the MASP in order to provide a receipt of the transaction to the mobile user.

For each of these operations there are two messages: a request and a response. Let us suppose the name of a service is X (one of the previous ones in the list), the messages are named XReq and XResp, e.g., for the MSS_Signature operation its messages are MSS_SignatureReq and MSS_SignatureResp, respectively. Several MNOs have launched initiatives based on this proposal, e.g. Telefo´nica Mo´viles and Vodafone in Spain (Miro´), and Turkcell in Turkey (‘‘yand Turks with mobile signature programme’’, 2007). In these proposals the e-signature is based on the use of the SIM. The main advantage of this solution is that the MASP does not have to develop different e-signature solutions for the different mobile handsets and the broad range of different technologies available to support m-signatures in mobile handsets (RuizMartı´nez et al., 2007, 2009b). This task is performed by the MSSP of each MNO. Depending on the solution developed by the MSSP, the e-signature is considered qualified or not. However, the main goal is to develop solutions that satisfy this requirement. Another interesting point of this solution is that it promotes interoperability (Ruiz-Martı´nez et al., 2007, 2009b) between MASPs and MSSPs because the service is defined as a Web service. This also facilitates the development of these solutions to the MSSPs and MASPs as well as granting independence to the solution of the technology used to develop it (Ruiz-Martı´nez et al., 2007, 2009b). However, there is not any definition for the interface between mobile handset and the MSSP. This proposal is limited since if a MASP wanted to offer a solution that could be used by any mobile user, every MNO operator should have to develop a MSSP. Furthermore, it would be necessary to develop the roaming mobile signature services among the MNOs. 2.3. Mobile signature application unit The Mobile Signature Application Unit (Pisko, 2007) proposes an architecture based on Java ME and SATSA which simplifies the role of the MSSP. In this architecture, the Mobile Signature Service is integrated in the mobile device as an application unit (the MSAU). Thus, the MASP is the one who exchanges information with the MSAU by using different communication carriers (UMTS – Universal Mobile Telecommunications System, Bluetooth, NFC – Near Field Communication, etc.), which access the SIM/USIM to generate the m-signature. Therefore, this solution can generate qualified signatures. The core of the MSAU is the Cryptoengine which has a part located on the mobile handset and another part on the smart card. These parts communicate between them by means of Application Protocol Data Unit (APDU) messages in order to perform cryptographic operations such as public key generation and management, signatures, etc. The main limitation of this proposal is that the architecture is restricted to those mobile devices with Java ME and SATSA technologies. Furthermore, it does not define how the interface offered to the MASP is, and the invocation of the service is open

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

and, therefore, the MASP would have to develop different kinds of access depending on the user. It does not define how this information is discovered either. In this sense, this proposal is more open than ETSI proposal. However, due to the fact that MSAU is more open, the MASP would have to develop different applications (with different technologies) for different kinds of devices, which makes achieving interoperability difficult and requires a higher investment in the development (Ruiz-Martı´nez et al., 2007, 2009b).

3. Mobile network operator-independent mobile signature service In this paper we propose a new Mobile Signature Service architecture that is MNO-independent and is not linked to any mobile handset-based specific technology to generate the electronic signature in the mobile handset. Our proposal is based on the MSS specification defined by the ETSI but it eliminates the need of roaming mobile signature services and of every MNO having to develop a MSSP. We have chosen that specification in order to facilitate the migration from ETSI-compliant solutions (backward compatibility) and the acceptance of our proposal. Thus, we have incorporated most of its services and its security mechanisms, we have re-defined some of them from its extension mechanisms trying to maintain backward compatibility and we have defined new services for those issues that were not covered by the ETSI. Moreover, we have improved the functionality of the MSSP and reduced its overhead because in our model the MSSP, which is named MNO-independent MSSP (iMSSP), is not responsible for checking whether the mobile handset is available to perform an m-signature. In our proposal the mobile user, when available and able to perform signature processes, checks by means of a Web service in the iMSSP whether there are m-signature requests to be signed. Currently, it is feasible to invoke Web services from mobile devices thanks to the development of the Extensible Markup Language (XML) and Web services (WS) Application Programming Interfaces (APIs) and libraries for mobile handsets (Kangasharju, 2007) (e.g., mobile handsets with Java ME that supports Java Specification Request (JSR) 172 specification (JSR 172 Expert Group, 2004) or with Microsoft .NET compact framework (Neable, 2002; Fox and Box, 2003), etc.). Thanks to the definition and specification of a Web service interface to be developed by the MSSPs for mobile clients, we promote the development of our m-signature solution for a mobile handset since the m-signature application developed could be used with different MSSPs. Furthermore, in our proposal, thanks to this service, the user has more control on the signature process, unlike ETSI proposal, where the user cannot decide when to perform m-signatures. This also facilitates the mobile user trust since we define how to perform this communication and the security mechanisms that are used, unlike in the MSS where it was not specified. In ETSI specification, the m-signature requests are sent to the mobile user as soon as the MSSP receives them. Thus, the mobile handset has to wait for the signature requests from the MSSP, behaving as a server. This also supposes that the mobile handset has to establish additional mechanisms to be protected against possible attacks that could come from other entities to obtain an m-signature from that user. However, in our approach the mobile user, when available to make signature, connects to the server to obtain m-signature requests. Therefore, the mobile handset does not have to support server functionalities. This shift of responsibility could introduce a problem: we could lose part of the instantaneity of ETSI model and some

297

requests, when downloaded, could have lost its validity. To prevent this situation our iMSSP supports a notification mechanism for the user. The invocation to this new service as well as all the processes defined in the system are protected using security mechanisms that allow us to guarantee the confidentiality, the integrity and the authentication of information exchanged between the parties during the communication. Furthermore, the m-signature generated by the mobile user guarantees the non-repudiation of the information signed. Moreover, we can point out that our architecture is not limited to Java ME and SATSA for mobile handsets. Our iMSSP defines the access to its services by means of Web services and mobile devices that can use any technology to develop the functionality that generates the m-signature (Java ME and SATSA, Windows Mobile Applications, etc.). Later, these services and mobile devices invoke the iMSSP to send the m-signature to the MASP. Another interesting feature of our proposal is that the mobile user may use different handsets to generate the signature that is sent to the MASP. Therefore, we provide a solution that facilitates the provision of mobile signatures. Finally, although our proposal is independent of the MNO, if an MNO decides to adopt it, the MNO can obtain additional benefits. Thus, MNOs that are not supporting ETSI proposal can obtain benefits due to the network traffic generated by mobile users that are using this proposal. This can also constitute a value-added service that could attract new clients. For MNOs that are already supporting ETSI specification, by adding the new features we have incorporated to this proposal they can obtain a set of different advantages: first, they could have a higher number of users using their iMSSP (mobile users from other MNOs could register with their iMSSP and use their solution), which supposes more traffic in their network and therefore, more benefits. Second, when their users are in roaming (using the network services of a visited MNO), they could use their mobile signature service where they are registered even if the visited MNO, that is providing them with connectivity, does not support either ETSI proposal or our proposal. This is due to the fact that the network services of the visited MNO will be used to access the iMSSP where the mobile user is registered, that is, the mobile user only needs connectivity from the visited MNO to make use of the iMSSP. We present next an overview of the system by indicating the different steps that would take place to acquire the capability of mobile signature and how the process of performing an msignature is. Later we will describe in detail the different processes introduced in the following section.

3.1. Overview of the system and its processes The purpose of this section is to provide an overview of the different processes that will take place in our mobile signature system. This overview is made from the mobile user’s point of view. Subsequently, these processes will be explained in depth in Section 3.4. In order to facilitate the understanding of the different processes, we use them to explain a case of use, e.g., let us suppose that a mobile user wants to formalize her enrollment in a university course. A university (acting as MASP) has a university course application. This application, in order to confirm that the request really comes from the user that has filled in the form, requests an m-signature from the mobile user. When the user signs the form, the university course application provides the mobile user with a receipt that confirms enrollment in the course. The different processes in which the mobile user can participate are depicted in Fig. 1. In these processes, all the different communication steps are performed through one or

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

298

Mobile User

PKI

Mobile Service/Application Provider

iMSSP

0. Mobile User Certification 1. Enrollment process 2. Use of the a m-signature-based application/service (providing mobile user identifier) 3. Request m-signature 4. Sign pending m-signatures requests 5. Obtain m-signature 6. End of the service or application

Fig. 1. Overview of the proposed m-signature system.

several MNOs. As initial requirement the user needs a mobile device and a certificate associated to its private key. It is preferable that the private key is generated in a SSCD as the SIM/USIM, although it could also be generated in the mobile device. In the latter case the e-signature could not be considered as equivalent to the handwritten signature but it could be used for those scenarios where this legal requirement is not mandatory. With the purpose of obtaining a certificate the mobile user performs a certification process with a Public Key Infrastructure (PKI) (step 0). Once the mobile user owns a certificate she performs an enrollment process (step 1) with an iMSSP. Through this process the mobile user obtains an identifier that will be used to receive mobile signature requests and a mobile signature application, if needed, to sign them. When the mobile user wants to use an m-signature-based services/application of a MASP, she has to provide her identifier to the MASP (step 2). In our case of use, let us suppose that in the university course application, the user chooses the course she wants to enroll in from the list of the university courses and fills in a form with her personal data. The mobile user has to sign the form to confirm her enrollment. For this purpose, she provides her identifier to initiate the process that will allow the university course application to obtain the signature of the data introduced in the form. From the identifier, the university course application locates the WS of the iMSSP and sends an m-signature request (step 3). With this request, the university course application could include some additional information related to the m-signature request such as the number of course or some text introduced by the user to identify the transaction. The iMSSP stores all the requests received from different MASPs and when the mobile user is available to make msignatures, she connects to the iMSSP to obtain m-signature requests and signs them if she agrees with them (step 4). In our case of use, the mobile user, sometime after having provided her identifier to the university course application, will use her m-signature application to connect to the iMSSP and receive as m-signature request the information related to the course in order to sign it.

Once the m-signature has been performed, the MASP can obtain it, validate it (step 5) and then, the application or the service confirms the finalization of the process and performs its task or provides the information needed (step 6). In our case of use, the MASP would validate the signature and would provide a receipt of her enrollment in the selected course to the mobile user. Some additional scenarios of use are described in Section 3.7. In the following section, we describe in depth the functionality that is associated to the different entities that participate in the service that we have just overviewed. Later, we describe in detail the different processes that are part of the flow of acquiring and using an m-signature mentioned in this section. Then, we describe the changes we have introduced as regards the ETSI MSS specification. After that, we describe the Web services we have defined for the iMSSP and MASPs. Finally, once the processes and services have been described, we define the security requirements that they should satisfy and we analyze the security features they are accomplished with.

3.2. Roles and responsibilities Conceptually, the different roles that are part of our system are depicted in Fig. 2. The roles are similar to the ones proposed by the ETSI (European Telecommunications Standards Institute (ETSI), 2003a), namely, Mobile Network Operators, Certification Authority, Registration Authority, Mobile Signature Service Provider and the Mobile User. However, we have re-defined some relationships as well as some of the functions to be carried out by them. Next we provide a description of each role.

3.2.1. Mobile network operators In Fig. 2 we can see different Mobile Network Operators. These operators provide mobile network services to their registered users and to the users from other MNOs with whom they have some agreement. In our model the MNO is not responsible for the provision of the iMSSP. However, as mentioned previously, it

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

299

Fig. 2. Roles in the system.

could provide it as a value-added functionality. Thus, we facilitate the migration from the ETSI proposal to our approach.

3.2.2. MNO-independent mobile signature service provider In this proposal the core role is the iMSSP. This role provides mobile signature services for mobile users and MASPs independently of the MNO they usually work with (see Fig. 2). The interface the iMSSP provides to MASPs is based on the Web services defined by the ETSI (European Telecommunications Standards Institute (ETSI), 2003b). We have extended some messages and defined new operations to support a new functionality we describe later. Apart from this re-defined MASP interface, we have also defined an interface for mobile handsets. This is the main difference between our proposal and ETSI proposal. In our model the iMSSP is not responsible for checking whether the user is connected (MSSP-oriented), available and willing to make msignatures. Here, the user is the one who requests to the iMSSP (mobile-user-oriented) the pending m-signatures requests to sign. Mobile users, previous to making use of the iMSSP service, have to carry out a registration process. In this registration process the user indicates which certificates she wants to use to sign and downloads a mobile signature application for her mobile handset. Here, if the iMSSP (or a company on his behalf or an independent trusted company that develops software for iMSSPs) in charge of the development of this application supports a great number of devices (or technologies associated to these devices) user registration will increase. In this model, although the MNOs do not control the entity that plays this role, they continue obtaining benefits from the service provided by this entity because mobile users make use of its network services and this increases the traffic producing benefits for MNOs (Rossnagel and Royer, 2005). As a result of the registration process, mobile users obtain an identifier in this iMSSP. This identifier is similar to an e-mail address. In fact, it follows the same specification, that is, Request For Comments (RFC) 5322 (Resnick, 2008). Thus, this identifier will have the following format: user-identifi[email protected] This identifier also enables MASPs to locate the user’s iMSSP he has to use to request her signature. For its localization we propose to introduce an entry in the iMSSP Domain Name System (DNS)

server that indicates the Uniform Resource Locator (URL) where the m-signature service for MASP is located. In particular we propose to introduce this URL as a TXT entry as recommended in the RFC 1464 (Rosenbaum, 1993) in order to store machine-readable data in this field. Thus, our definition for this URL is: TXT ‘‘iMSSP-MASP-URL ¼URL-iMSSP’’where the iMSSP-MASPURL tag indicates that this DNS entry contains the URL of the iMSSP service description which contains the endpoint of the service. This URL is the following field that appears in the entry, that is, the URL-iMSSP. From the endpoint found in the Web service description provided by this URL, the MASPs can invoke the service to request mobile user’s signatures. 3.2.3. Certification service provider The Registration Authority (RA) and Certification Authority (CA) are roles that belong to a Certification Service Provider (CSP) or Public Key Infrastructure that is in charge of providing certificates for mobile users. In our system we do not have limitation for the number of CSPs or PKIs that can participate, it depends on the users and their choice to use a PKI for providing certificates. Needless to say that the PKI used should be trusted by the different entities in the system. Furthermore, a Time-Stamp Authority (TSA) could be associated to a PKI but it could also be an independent entity. 3.2.4. Mobile service/application provider The Mobile Service/Application Provider or MASP is the role that provides some m-signature-based/required services or applications to the mobile user. The MASP does not need a previous registration with a particular iMSSP. This registration process can be performed once he receives for the first time a request from a new user that works with an iMSSP with whom there was not a relationship previously. Depending on the trust on the iMSSP, he could refuse to work with a specific iMSSP. We have also defined a mechanism in which the MASP does not have to be registered with the iMSSP. This mechanism has been defined for those cases in which the MASP is not registered in the iMSSP and the MASP is not going to work usually with the iMSSP. For those cases, the Mobile User provides a token, which we name ticket, to the MASP to be used only once. The MASP

300

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

sends this token with the m-signature request to the iMSSP. If the iMSSP can verify it, then the MASP can use the service without registration. 3.2.5. Mobile user The mobile user is a user that owns a mobile handset and wants to use some services or applications of MASPs that require an m-signature (see Fig. 2). The user wants to make use of her mobile handset to generate her signatures. For this purpose, the mobile user obtains a certificate from a PKI. More details on how to perform this process are provided later in Section 3.4.1. Once the user has a certificate, she registers with one or more iMSSPs and downloads the software needed in her device to perform these m-signatures. In this registration process she obtains an identifier that will be sent to the MASPs to carry out an m-signature process. This identifier could be used with different handsets and certificates. 3.3. Flow of acquiring and using an m-signature

3.

4.

5.

6.

In Section 3.1 we provided an overview of the different steps of our mobile signature solution. Next, in this section we describe in more detail the sequence of steps in which a user could be involved to register in the system and use m-signature. Later, in the following section we will describe these processes in depth indicating the different messages exchanged. The steps for acquiring and using a m-signature, which are shown in Fig. 3, are: 0. The user, previous to making m-signatures, has to obtain a certificate from a PKI. This process is made through the MNO and could follow the steps described in (Rossnagel, 2004; Rossnagel and Royer, 2005; European Telecommunications Standards Institute (ETSI), 2003a). Basically, it consists in requesting a certificate. Then, the user goes to the RA to confirm her request, the RA verifies the identity of the user and confirms the request and the CA issues the certificate. Once the certificate is available, the user downloads it. 1. The user enrolls with a iMSSP. On the other hand, if a MASP estimates he will usually work with a particular iMSSP, he could enroll with him. 2. The user wants some service from MASP. Let us suppose that the application or service requires an m-signature. The user indicates her service request to the MASP with her identifier. In the event MASP was not registered with her iMSSP, he could

7.

provide a ticket. This step could be optional if the user has previously registered her identifier with the MASP. If the MASP was not previously registered in the system and he is interested in working with this iMSSP he could register in this moment. The MASP sends a signature request to the iMSSP. If the iMSSP authenticates to the MASP (because MASP is registered and authenticated with his certificate or because he owns a ticket), the iMSSP stores the request. Additionally, if the request was marked by the MASP as urgent, the iMSSP sends a notification to the mobile user. The mobile user accesses the iMSSP and downloads the list of msignature requests that contains the basic information associated to a transaction to sign. Additionally, the mobile user could download the full document associated to the request. If the requests come from applications or services agreed by the mobile user, she signs them and sends them back to the iMSSP. The iMSSP stores signatures. Additionally, the iMSSP can carry out some tasks such as requesting a time-stamp. The iMSSP provides the signature to the MASPs that requested them. For the provision there are two possibilities. First, the iMSSP notifies the MASP the m-signature. Second, the MASP is not notified and from time to time MASP checks whether the m-signature is available. When it is available the iMSSP provides it. The MASP verifies the signature. If it is valid, he provides the access to the service. Additionally, the MASP could also provide a receipt of the transaction to the mobile user through the iMSSP or the application/service.

We can mention that steps 0 and 1 are only executed once, when the user is not part of the system. When the user is in the system, the steps usually executed are from 2 to 7. 3.4. Processes For the provision of a Mobile Signature Service is necessary to define a set of processes. Some processes are directly related to the provision of the MSS such as registering in the iMSSP or requesting an m-signature. However, there are other processes such as generating a private key and obtaining a certificate that are not directly related to the MSS. In this section we explain in depth the processes and the different messages exchanged that are more closely related to the generation of m-signatures.

Fig. 3. M-signature flow.

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

3.4.1. Mobile user certification The user needs a private key and a certificate associated to this private key in order to generate m-signatures. If the private key is under the sole control of the user and the PKI is considered qualified, the m-signature will be qualified. This certification is not offered by the iMSSP, although it could participate in the process. This certification service is offered by a PKI and the steps to follow will depend on the PKI chosen. In general, this process is as follows: 1. The mobile user generates a pair of asymmetric keys (private and public). 2. The user registers her personal data and her public key in a RA by sending them signed with her private key. After that, the mobile user goes to the RA so that her data can be verified by the RA. 3. If validation data is successful, the RA notifies the CA to issue the certificate. 4. The CA issues the certificate. 5. The mobile user downloads her certificate. More details on the steps to follow in this process can be found in (Rossnagel, 2004). Another possibility is the process specified in (European Telecommunications Standards Institute (ETSI), 2003a) where the iMSSP could participate in the certification process. Thus, in this process the RA (acting as MASP) sends an m-signature request to the iMSSP in order to request that the user signs the registration information using its private key. 3.4.2. Mobile user registration at iMSSP Once the user has a certificate, she might want to take advantage of m-signatures to access applications or services provided by MASPs. For this purpose, the user has to be registered with, at least, one iMSSP. In the ETSI specification (European Telecommunications Standards Institute (ETSI), 2003a) this process (MSS_Registration) is carried out by means of a MASP such as the RA. In some cases the user has to provide some information that completes registration process such as a PIN, a certificate, etc. However, this process has been defined as a synchronous process. Besides, no mechanism to query the status of the process has been defined either. This can suppose a problem if the requested information cannot be provided immediately. We could solve this problem in different ways: either by defining a new service to make queries or by extending the query service to return other data different from signature. In order to maintain backward compatibility we propose that for this query, the MASP submits the previous registration request previously sent, that is, with the same transaction identifier and with an updated instant of time. Additionally, in our proposal this process can be carried out through the iMSSP’s Web application or by means of the same Web service we have defined for the iMSSP (the application that implements this service would be provided by the iMSSP or by a trusted developer). In both cases the user chooses an identifier and provides some information to the iMSSP: the set of certificates she has and could use to generate m-signatures, optionally, the list of MASPs and time-stamps authorities in which she trusts, etc. With the Web service the sequence of steps is the following: 1. The user sends an MSS_MUBookRegistration request containing the preferred user identifier and an identifier of transaction generated randomly. If the identifier is free, the service returns the MSS_MUBookRegistration response containing the identifier

301

of the transaction and the date and time until this identifier is booked for the mobile user. Otherwise, it returns whether the identifier was already taken or whether the identifier is momentarily booked. In the latter case the service also indicates the date and time until it is booked. If before that time the mobile user has not finished the registration process, the identifier is released and could be taken by other user. 2. The mobile user decides to finish the registration. The steps exchanged are the following: firstly, the mobile user sends the identifier chosen with the transaction identifier generated in the previous step, her desired password, the MASPs accept (she already trusts) and, finally, the certificates she owns (in the event the mobile user has already a certificate. Otherwise, this process could be made through the iMSSP) and she is willing to use to generate m-signatures. This information is sent signed by the mobile user. This service is named MSS_MURegistration and the response to its invocation confirms the information was correctly stored in the iMSSP. It also contains the URL to download the m-signature application for her mobile handset (if necessary, since the registration application could also include the functionality needed).

3.4.3. MASP registration at iMSSP In the ETSI specification, the MASP registration is not defined because the MASP is supposed to have previously reached a commercial agreement with its MNO in order to be provided mobile signature services. Thus, the MNO provides an access password to the MASP. In our proposal we have defined how to carry out this process from the MSS_Handshake defined in the ETSI specification. This service was defined for those cases where there the use of XML signatures (Eastlake et al., 2008; Agne Nordbotten, 2009) in the Simple Object Access Protocol (SOAP) (Gudgin et al., 2007) request is necessary in order to provide an additional level of security by authenticating the MASP. Based on the MSS_Handshake (European Telecommunications Standards Institute (ETSI), 2003b) we propose the following sequence of steps to carry out MASP registration: 1. The MASP sends an MSS_HandshakeReq request message to the iMSSP. This message contains its certificate(s), signature algorithms supported, CAs supported, requested identifier, password and any information that has to be provided in order to accept the enrollment to the iMSSP (terms and conditions, etc.). 2. If the iMSSP trusts in the certificate issued by the CA and the MASP accepts iMSSP terms and conditions, it sends an answer (MSS_HandshakeResp) with the confirmed identifier, the certificates that the iMSSP accepts as well as any other information that could be needed. 3. The MASP sends an MSS_RegistrationRequest message to the iMSSP. In the ETSI specification this request is used to register a mobile user with a iMSSP through the MASP. In the request, the MASP as mobile user indicates the iMSSP. Thus, the iMSSP understands that it is a MASP registration. This request is signed with one of the certificates accepted in step 2. 4. The iMSSP verifies the request and answers with the MSS_RegistrationResponse confirming whether the registration was made correctly. This process can be performed anytime the MASP wants to join an iMSSP, that is, it could be made before receiving any user’s request or the first time the MASP receives a service request from a user associated to that iMSSP.

302

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

In the event the MASP is not interested in registering with the iMSSP, the MASP could request an m-signature to the iMSSP as long as the mobile user provides him with a ticket for a particular transaction. In this case, the ticket acts as an authentication token in the iMSSP that gives the right to request an m-signature to this user.

3.4.4. Mobile signature request and generation The m-signature process can start in two different ways. If the mobile user is not registered with the MASP she needs to provide the MASP with her identifier. Then, the first step would be the provision of this identifier. On the other hand, if the mobile user is already registered with MASP this step might not be necessary. Apart from the provision of the identifier, depending on the application, the mobile user could initiate the process of requesting the signature in an application, e.g., the user could be carrying out a transaction in the MASP and for confirming the transaction, an m-signature could be requested. In this case, the mobile user could confirm the request of the m-signature. On the other hand, another scenario could be that the MASP requested directly the m-signature, e.g., the user is registered with the MASP and she could have configured in such a way that when a new document that has to be signed arrives, that an m-signature request is automatically sent. Independently of how the process has started, the following steps would be necessary so that the MASP obtains the m-signature: 1. The MASP sends a signature request to the iMSSP (MSS_SignatureReq). If the MASP is not registered in the MSSP either he would have to follow a registration process as specified in the previous section or the MASP would have to provide a ticket and sign the request. Furthermore, in the request the MASP indicates whether he supports the notification mechanism. It could also indicate whether this process is urgent or not. 2. The iMSSP stores the MASP request and sends a response to the MASP indicating him that the request is being processed (MSS_SignatureResp). 3. If the MASP signature request is marked as urgent or the expiry of the request is very short, the iMSSP sends a notification to the user (e.g. via Short Message Service – SMS -). Otherwise, no notification is sent. 4. When the user is available and is willing to sign the pending m-signatures, she uses her m-signature application and sends a request to download all the pending m-signature requests (MSS_SigReqListReq). The iMSSP checks the request from the mobile user and sends a response with the information about the different pending m-signature requests (MSS_SigReqListResp). The mobile user checks in the application the different m-signature requests. The requests contain some reduced information of the transaction, namely: MASP, identifier, short description of the transaction and the hash of the document to sign that has been calculated by the iMSSP. This information is limited in order to reduce the amount of data to download. 5. Additionally, the user could request the full document associated to the transaction by sending the MSS_SigReqDocReq. The document is received in the MSS_SigReqDocResp message. 6. Once the mobile user has checked the requests, she signs those she accepts. Then, the m-signatures are sent to the iMSSP (MSS_ClientSignatureReq). 7. The iMSSP checks the request and if it is correctly processed, he sends the result with the MSS_ClientSignatureResp.

8. The iMSSP also checks whether the m-signatures he has received need some additional process such as a time-stamp. In this case, he requests a time-stamp for them. Once he has made all additional processes, he stores the m-signatures. 9. Additionally, if the MASP supports the notification mechanism, the iMSSP would send the m-signature as a notification to the MASP (MSS_NotificaticationReq). The MASP would process the m-signature and will send a response to the iMSSP. Optionally, in the response the MASP could send a receipt of the transaction to the mobile user. If the MASP does not support the notification mechanism, the following steps would take place. Otherwise, this process would finish. 10. Sometime later, the MASP will check whether the msignature is available. For this purpose, he uses the status request (MSS_StatusReq). 11. The iMSSP checks whether the m-signature is available and sends it as a response (MSS_StatusResp). 12. Optionally, the MASP could provide a receipt of the transaction to the mobile user. In this case, the MASP would send the receipt with the MSS_ReceiptReq. Other possibility is that the receipt is provided directly to the mobile user through the MASP. 13. The iMSSP processes the receipt and sends a response to the MASP (MSS_ReceiptResp). Then, it stores the receipt for the user. Later, the mobile user could recover it.

3.4.5. Other services The iMSSP offers other processes such as the query of the information on the mobile signature system (signature policy, capabilities of mobile users, etc.). This is named query of the mobile signature profile (MSS_ProfileQuery); or the provision of receipts for the users (MSS_Receipt) previously mentioned. These functions have also been defined in our iMSSP and its use and structure is the same as defined by the ETSI specification (European Telecommunications Standards Institute (ETSI) 2003a, b, c, d). 3.5. Web services description In this section we describe the Web services we have defined for the iMSSP and the MASP. We explain the different functions or operations of each service as well as pointing out the main changes we have introduced as regards ETSI specification. For the Web service description we have made use of Web Service Description Language (WSDL) (Chinnici et al., 2007) as well as a set of schemas. In the WSDL named MSS_Service, we have described messages, portTypes, bindings and the endpoint of the Web service. Currently, this service is only available to be used internally in the University of Murcia. For the description of messages we have made use of two schemas: one schema with types introduced by ETSI specification (named MSS.xsd) and another for the new types we have introduced (named MSSUMU.xsd). Both schemas refer to other schemas such as XML Digital Signature schema (Eastlake et al., 2008) or XML Encryption (Eastlake and Reagle, 2002) for types related to e-signature and encryption in XML (Agne Nordbotten, 2009). As protocol for sending the messages we have specified SOAP/ HTTP over TLS (Transport Layer Security)/Secure Socket Layer (SSL) in order to obtain server authentication (iMSSP or MASP, depending on the operation), integrity and confidentiality. 3.5.1. iMSSP Web service The complete set of operations that we have defined for the iMSSP Web service are depicted in Fig. 4. Next we provide a brief

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

303

Fig. 4. iMSSP Web service.

description of each operation as well as the possible differences with ETSI specification. Firstly, we describe functions that were already defined by the ETSI.



 MSS_Signature. This operation receives signature requests from

 

  

MASP. As a response, it provides a transaction identifier that will be used by the MASP to query the status of the request later. This process is described in Section 3.4.4. Due to our client-oriented m-signature approach, the service does not support the synchronous mode anymore. For this function we have defined a new AdditionalService that allows the MASP to indicate whether he supports the notification mechanism. If provided, the iMSSP will invoke this operation in the MASP to notify and send him the m-signature that has been received. MSS_StatusQuery. This operation provides the MASP with the status about a specific transaction. If the signature is available, it is provided to the MASP as a response. MSS_Registration. The MASP uses this operation to register a mobile user as explained in Section 3.4.2. We have also defined how to use it to register the MASP with the iMSSP as described in Section 3.4.3. MSS_Profile. This operation provides information on m-signature capabilities of the mobile user system. MSS_Receipt. The MASP might provide a receipt of the transaction to the mobile user with this function as described in Section 3.4.4. MSS_Handshake. This function is used to perform MASP authentication as defined by ETSI. We have also defined how to use it to perform MASP registration as explained in Section 3.4.3.

Next, we provide a description of the new operations we have defined for the iMSSP:

 MSS_MUBookRegistration. This operation is used by the mobile



user to check and book an identifier in the iMSSP (see Section 3.4.2). It also obtains some information on the iMSSP such as the set of CAs he supports, mobile handsets supported, etc. MSS_MURegistration. This operation allows the registration of the mobile user from an identifier obtained with the previous operation and its associated password in the iMSSP (see Section 3.4.2). The user can provide the set of certificates she owns, the set of time-stamps authorities she trusts, the set of MASP she trusts and any other information relevant and related to the m-signature process. As a result of this operation, the iMSSP acknowledges the registration and provides the URL where the mobile user could download an

  



m-signature application for her handset in the event she does not have any application yet. MSS_SigReqList. The mobile user invokes this operation to obtain the m-signature requests that the iMSSP has received (see Section 3.4.4). Each request contains information on the transaction (transaction identifier, MASP identifier, time validity, etc.) as well as the hash of the document or transaction to sign. If the user trusts the MASP she could perform the signature from the hash received in the request. On the contrary, she could obtain the complete document with the operation we explain next. MSS_SigReqDoc. This operation provides the document or transaction information associated to an m-signature request as mentioned in Section 3.4.4. MSS_ClientSignature. The mobile user sends the iMSSP the m-signatures that she accepted and decided to perform (see Section 3.4.4). MSS_Ticket. The mobile user invokes this operation to request a ticket for a MASP. She can indicate whether she wants to receive it or whether it should be sent directly to the MASP. The ticket is signed by the iMSSP and contains an identifier of the transaction, a validity period and the identity of the mobile user and the MASP. MSS_MUReceipts. Although, in general, the mobile user obtains the receipts from the iMSSP Web service interface, we have defined an operation so that she can obtain them with her mobile applications if desired. This operation provides all latest receipts the MASPs have sent to the mobile user.

3.5.2. MASP Web service In this section we describe the functionality provided by the MASP Web service. This service has also been described by means of WSDL and the different operations it offers are:

 MSS_Notification. The implementation of this operation is not

 

mandatory. It is implemented by the MASP in the event he is interested in being notified as soon as the iMSSP receives an m-signature. This function is designed according to the ETSI specification. MSS_ReceiveTicket. The definition of this operation in the MASP is also optional. It is used to receive a ticket from the iMSSP instead of the mobile user and it has not been defined by the ETSI. MSS_InitTransaction. This operation is defined to start an m-signature-based transaction from the service instead of the Web interface. This operation is optional.

304

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

3.6. Security requirements and analysis In this section we establish the different security requirements that the elements of our solution should satisfy and we also analyze the system from the security point of view. In a mobile signature system there are several elements that should be analyzed. On the one hand, the different elements involved in the generation of the mobile signature. On the other hand, the different communication processes that take place between the different entities. It is important to point out that as our proposal is based on the extension of ETSI MSS solution, we could consider the same requirements, which are specified in (European Telecommunications Standards Institute (ETSI), 2003c). Thus, our proposal guarantees the same level of security as MSS and provides additional features that were previously mentioned at the beginning of Section 3 and whose security features will be analyzed in this section. The mobile device needs some software to generate msignatures. The application used, named Mobile Signature Application (MSA), should be downloaded from a trusted entity such as the iMSSP and should be signed in order to detect changes during the download. For this purpose the iMSSP (or a developer company in which iMSSP trusts) should sign the application by using an asymmetric key that is certificated by a trusted PKI. This MSA could also be pre-installed if the iMSSP is developed by a MNO (the MNO could establish with his manufacturer(s) that this application will be included in the mobile device). Furthermore, the functionality of the MSA should satisfy the security requirements established in (European Committee For Standardization (CEN), 2004; Jansen and Scarfone, 2008). Basically these requirements are: guaranteeing the integrity of the data to be signed, trusted channels between the application and the SSCD, integrity of the different components that are part of the application, integrity of the information exchanged and that the data shown to the user to sign is the data that the user is really signing. If this application satisfies these requirements and a trusted party certifies it, then the client can be sure the MSA behaves as expected. Depending on the scenario and if the m-signatures have to be considered equivalent to the handwritten signatures, the MSA to generate the m-signature should be based on a SSCD and the user should have a qualified certificate. The communication between the MSA and the SSCD should be based on trusted channels as specified in depth in (European Telecommunications Standards Institute (ETSI), 2003c). If the private key is stored in memory instead of in a SSCD, it is more difficult to guarantee that it can only be used by the mobile user, since it is not protected by a secure environment (RuizMartı´nez et al., 2007, 2009b). Although this approach could be valid in some scenarios such as in local processes in an enterprise. Therefore, due to the fact that the use of keys in mobile device memory is more risky and the m-signatures cannot be considered legally equivalent to handwritten signature, the use of an SSCD is strongly recommended for the generation of m-signatures. The conditions SSCD devices should satisfy are specified in (European Committee For Standardization (CEN), 2004). This device could be the SIM/USIM and should be provided for the MNO. It could also be provided by other entity but in this case, the mobile device should have an additional hardware element to communicate with it such as a second smart card reader (dual-chip or dual-slot) or a USB interface (Ondrus and Pigneur, 2005). The obtaining of a qualified certificate requires the establishment of a certification process with a PKI that satisfies the requirements, obligations and liability established in (European Telecommunications Standards Institute (ETSI), 2007, 2006) for this kind of certificate. Under these conditions the mobile user

could be sure that she owns a secure environment for the generation of m-signatures that are legally equivalent to the handwritten signature. Next, we are going to analyze the main exchanges that are performed between the different entities. 3.6.1. Certification process In this process, a pair of asymmetric keys is generated and a certificate associated to these keys is issued. As mentioned previously, there are several ways to perform this process that depend on the PKI used (Rossnagel, 2004; European Telecommunications Standards Institute (ETSI), 2003a). The application used to perform this process should satisfy the same security requirements as the MSA mentioned above. (even it could be the same application). Furthermore, in order to guarantee the protection of the private key, its generation should be performed in the SIM/USIM. Once the keys are generated, the certificate request should be based on Public Key Cryptography Standard (PKCS) #10 (Nystrom and Kaliski, 2000) or Certificate Request Message Format (CRMF) (Schaad, 2005) or Certificate Management Messages over CMS (CMC) (Schaad and Myers, 2008) formats in order to facilitate interoperability and its use with different PKIs. After sending the certificate request, the mobile user should go to the RA to confirm her request and authenticate herself. Thus, the RA can verify the identity of the user and the information to be included in the certificate, as established for PKIs that issue qualified certificates (European Telecommunications Standards Institute (ETSI), 2007). Then, the RA validates the request and later the CA issues a X.509 certificate that will be downloaded by the application. This application will use the CA certificate to check that the mobile user certificate comes from the desired PKI and that it has not been modified. In the event the validation is performed successfully, the certificate is installed and may be used to produce m-signatures. The CA certificates could be pre-installed in the operating system of the mobile device as is usually made, or the user could obtain the CA certificate by the mechanisms defined by the PKI (Web application, WS, Multimedia Messaging System—MMS, etc.). 3.6.2. Mobile user registration at iMSSP This process could be performed through the iMSSP Web application or through an application provided by the iMSSP or a trusted developer company that implements our solution and the Web services defined in Section 3.5. This application should satisfy the same requirements as the MSA, even the same application could implement both processes. During this process the mobile user connects to the iMSSP by means of a SSL/TLS connection (both in the Web application and in the WS defined for this purpose) that guarantees the authentication of the server (the mobile client has to check that the server certificate has been issued by a trusted PKI and that the certificates belongs to the desired iMSSP), integrity and confidentiality. Thus, if the mobile user’s SSL/TLS client implemented in the application is properly configured both the mobile user and the iMSSP can be sure that man-in-the-middle attacks cannot be carried out and the integrity and the confidentiality of the information is guaranteed (Burkholder, 2002). Furthermore, the mobile user registration request is signed by the mobile user. Thus, the iMSSP can have an of the authentication (a nonrepudiation) of the mobile user that has requested being registered and will be sure that it does not come from an attacker that wants to register the user on his behalf. As a result of this process, the mobile user obtains a user identifier at iMSSP and establishes a password that will be used in

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

future communications to authenticate her, such as when she downloads pending m-signature requests to sign them. 3.6.3. MASP registration at iMSSP The MASP is registered at iMSSP by invoking the services defined in the Section 3.5. For the invocation of these services an SSL/TLS connection with server authentication is also established. Furthermore, in this process the MASP chooses a password for future communications and signs the request. Therefore, in this process the authentication of both parties, the integrity and the confidentiality of the information exchanged are guaranteed. 3.6.4. Mobile signature request and generation The process of m-signature is initiated when a user wants to access a service/application that is based on an electronic signature. For initiating this process the mobile user has to provide her identifier and, depending on the application, provide some additional data related to the process. Furthermore, if the MASP is not registered with the iMSSP and the MASP does not want to make a registration, the mobile user has to provide a ticket to the MASP (this ticket could be sent by either the mobile user or the iMSSP). The way all this information is provided depends on the scenario, e.g., in an on-line scenario, these data should be provided by a Web application secured with SSL/TLS. In a scenario where the user is physically located in the vendor dependencies, these data would be provided by oral communication, e.g., when the mobile user is making purchases in a department store. Once the MASP has the information, if the MASP is registered, he sends an m-signature request to the iMSSP. This request is sent over an SSL/TLS channel and is authenticated by means of the password he established during the MASP registration at iMSSP. Thus, only the iMSSP and MASP can see the information exchanged and the iMSSP can be sure that the request comes from the registered MASP. In the request the MASP can also specify if the mobile user should be notified or not of this request. If the MASP is not registered, in the request, the MASP has to include a ticket provided by the user and has to sign the request. The ticket is generated by the iMSSP specifically for a transaction of a mobile user with a MASP. Therefore, it can only be used once and it can only be used by the MASP that is specified, since an e-signature is required for the MASP authentication. The ticket can be checked by the mobile user and the MASP since it is signed by the iMSSP and therefore, it cannot be changed whether reused or used by a MASP that is not considered trusted. When the iMSSP receives the MASP request, if it is indicated, the mobile user should be notified. Then he will send a notification to the mobile user (by means of an e-mail, SMS, etc.). Otherwise, he will wait for the mobile user to be available for making signatures and request him the pending m-signature requests. The mobile user, in order to obtain the pending m-signature requests to sign, uses the MSA that invokes the services defined using an SSL/TLS connection with server authentication. The MSA has to satisfy the conditions established at the beginning of this section and, in order to guarantee the protection of the private key, should use an SSCD. The client requests are authenticated by means of the password she established during her registration process. Therefore, the communication guarantees the secure exchange of the information and the authentication of both parties. If the user is successfully authenticated, the iMSSP provides the information related to the documents to sign. Thus, only the authorized user can access her information. The user checks the information related to each request and if she accepts them, she signs them and sends the m-signatures to the iMSSP. Once the iMSSP has received them, he validates them and he could also perform some additional tasks such as including

305

a time-stamp. Then, the iMSSP stores them. The user could also query them later as long as she is successfully authenticated by means of the Web application or the Web service. Thanks to the iMSSP stores pending m-signature requests and m-signature performed, if a problem happens when the mobile user is downloading her requests, she could also re-download them later because the iMSSP stores them until the mobile user confirms she wants to sign them or reject them. The iMSSP also stores all the m-signatures carried out by the mobile user. Thus, if the user has a problem with her mobile device or her application she could also recover them. If the MASP supports a notification mechanism, the iMSSP sends a notification with the m-signatures available. This notification is made by invoking the Web service defined over a secure channel based on SSL/TLS and the iMSSP authenticates the MASP by using the password the MASP established with iMSSP. Thus, the MASP can be sure the notification comes from the iMSSP and that nobody can access the information exchanged. Furthermore, he receives the m-signatures that provide a non-repudiation evidence of the information signed by the mobile user. In the response, the MASP could provide a receipt of the transaction that would be used as a non-repudiation evidence of the MASP on the m-signature generated by the mobile user. This signature should also based on a SSCD and a qualified certificate.

3.6.5. Summary of the security properties of the exchanges In this section we sum up the different properties that guarantee the different exchanges performed between the different parties involved in the system. These properties are:

 Confidentiality and integrity. All the communications are



ciphered by using SSL/TLS. In the use of SSL/TLS we encourage to follow the recommendations indicated in (Burkholder, 2002; Lee et al., 2007) to avoid possible attacks or flaws. This requires choosing the correct version of SSL/TLS (TLS 1.0 or later), the set of encryption ciphers (Triple Data Encryption Standard–3DES–, Advanced Encryption Standard–AES–, Digital Signature Standard–DSS–, RSA, Elliptic Curve Digital Signature Algorithm–ECDSA–) and hash functions (Secure Hash Algorithm (SHA)-1 or SHA-2) and, the length of the keys (see (Barker et al., 2007) for this purpose). We also suggest following the recommendations proposed in (Chou, 2003; Jobanputra et al., 2009) regarding the efficiency of the algorithms to use. Thanks to the establishment of this kind of channel, only the participants in the exchange can access the information and the communication is safe against eavesdropping, traffic analysis and active attacks (Burkholder, 2002; Wagner and Schneier, 1996; Mitchell et al., 1998; Paulson, 1999). Furthermore, the participants in the exchange can detect if, during the communication, the information has been changed thanks to the use of shared keys and the Hashbased Message Authentication Code (HMAC) function (message authentication) (Krawczyk et al., 1997). Authentication. Due to the fact that all the communications are performed by means of an SSL/TLS channel, the server authentication is guaranteed. In some transactions the role of the server is carried out by the MASP and in others by the iMSSP. Additionally, in the registration processes, the entities that perform the registration, such as the mobile user or the MASP, are authenticated by means of an e-signature. In the rest of the processes, such as requesting an m-signature, requesting pending m-signatures requests for signature or notification, an authentication based on a password (established during registration process) is used. This authentication is used because a more advanced level of authentication, as

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

306







based on e-signature, is not required for the communication. Thus, the process can be performed in a more efficient way. Due to the fact that authentication is based on password in some processes, the users should choose their passwords based on the recommendations provided in (Burr et al., 2006; Adams and Sasse Lunt, 1997; Gehringer, 2002; Yan, 2004). Non-repudiation. The m-signature generated by the mobile user provides a non-repudiation evidence of the information signed for the access to a service or application. Furthermore, if the m-signature is based on an SSCD and a qualified certificate, the m-signature generated is considered legally equivalent to the handwritten signature. Man-in-the-middle and replay attacks. If the SSL/TLS client is correctly configured (Burkholder, 2002) the system can avoid this kind of attacks (Burkholder, 2002; Wagner and Schneier, 1996; Mitchell et al., 1998; Paulson, 1999). Access control. Unless a user reveals his/her password, he/she will be the only person able to access his/her information in the iMSSP (pending m-signature requests, m-signatures performed, receipts, etc.).

3.7. Scenarios of application In this section we explain briefly how the MSS could be used in different scenarios such as (mobile) payments, authentication for access control, contract signing and workflows (Ruiz-Martı´nez et al., 2007; Rossnagel and Royer, 2005; Rust et al., 2008; RuizMartı´nez et al., 2009b). There are many other possibilities where it could be used such as identity-based services, service identities signing, electronic business, betting transactions, single sign-on, etc. (Schnake et al., 2008; Nagell, 2008; Li and Tao, 2009). We have decided to explain these systems because they represent some of the most interesting scenarios of applications of m-signature. In (mobile) payment systems the MSS could be used in order to confirm a transaction and its cost. In this scenario the user can choose a product or service from a MASP, then the MASP presents an invoice with the data of the transaction and the amount to pay. If the user accepts the invoice, she provides the MASP with her identifier. Next the MASP sends an m-signature request to the iMSSP to confirm the invoice. Basically, this request would contain the transaction identifier, the MASP identifier, the amount to be paid and the mobile user’s bank identifier. The user will download the request and will sign it. This signed invoice is presented later to the mobile user’s bank so that the amount agreed by the vendor is paid for. In an access control system (e.g., for accessing to contents on a Web or in a physical scenario of accessing dependencies, in WLAN access, etc.), the m-signature could be used to authenticate the user. In this scenario, the MASP would send a challenge to the mobile user. If the challenge is properly signed, the user would be authenticated and the system would allow the access to the system. Other interesting scenario where an m-signature could be used is the signing of a contract between two parties or more parties (with or without the participation of a Trusted Third Party (TTP), that is, on-line or off-line TTP (Onieva et al., 2008)). In this scenario the parties could negotiate the conditions of the contract. When the conditions are agreed on, each party could request to the other party the signing of the contract. In this process, a fair contract signing protocol should be used so that this exchange is performed in a fair way for both parties (Chadha et al., 2005; Ruiz-Martı´nez et al., 2009). As final scenario, we can suppose an enterprise where their executives are traveling and they are required that from time to time they activate/approve some processes, such as the generation of a payment order. In this scenario, they could receive a

mobile signature request and confirm the beginning of the process with his/her signature. The main advantage of using m-signature in these scenarios is that these processes could be developed everywhere, anytime.

4. Implementation details With the aim of testing the architecture and the services we have presented in the previous section we have developed an a way to implement them. This implementation has been developed in order to prove the viability of the system proposed. Although our development is based on a specific set of software technologies that we describe below, it is important to point out that our proposal is independent of any specific software technology and, therefore, other technologies and platforms could be used to implement the invocation to the different Web services defined. From the components of this implementation we have developed a prototype of a scenario of application we describe in Section 5. This scenario is also used to carry out a performance analysis on the time needed to obtain an m-signature in a transaction. Next, in this section, we describe the general environment of development first. Later, we describe the main components developed for each entity. 4.1. Development environment We have based the development of our implementation on Java language because it is an object-oriented language that is platform-independent (Arnold et al., 2005). We have adopted Eclipse as Integrated Development Environment (IDE) for the development in Java since it is a complete system that is freely distributed and that has plug-ins for the development in mobile devices as well as for the development of Web services and applications. For the development of Web services we have used Axis (Apache Axis, 2009), which is an open source implementation of Web services in Java. Basically, Axis is a SOAP engine that includes a server (stand-alone or with plug-ins into servlet engines), supports for WSDL, libraries for SOAP and WSDL and tools for generating classes from WSDL. In our development, the Axis services are provided through a Tomcat server. For the development of the components in the mobile handset we have made use of the Eclipse Mobile Edition (Eclipse ME) plugin that supports the use of Java Wireless Toolkit (JWTK) for the development with Java ME. Thus, our development for the mobile client is based on Java ME. For the development of Web components (Web applications and services) we have used the Web Tools Platform (WTP) extension for Eclipse. The WTP includes different tools such as source and graphical editors, wizards for simplifying the development and tools for developing Web and Java Enterprise Edition (EE) applications. Fig. 5 depicts all the elements that are part of this development scenario. Next we describe the elements developed for each party. 4.2. Mobile client For the mobile user’s mobile handset, we have developed a Java ME application that is in charge of communicating with the iMSSP in order to obtain the signature requests and sending the signatures performed. The different elements are depicted in Fig. 6. This application makes use of a Java ME library that we have developed to implement the access to the operations provided by the iMSSP for the mobile user (MSS_ClientWS), that

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

307

Fig. 6. Components of mobile equipment. Fig. 5. Development environment.

is, MSS_MUBookRegistration, MSS_MURegistration, MSS_Ticket, MSS_SigReqList, MSS_SigReqDoc, MSS_ClientSignature and MSS_MUReceipts. This library is based on the API defined in the JSR 172 – J2ME Web Services Specification (JSR 172 Expert Group, 2004). On the other hand, the application, has to access to the USIM card in the mobile handset in order to sign the m-signature requests. For this purpose we have developed a library called USIM Signature library. This library implements the signature functions and the access to the USIM through the API defined in the JSR 177 – Security and Trust Services API for J2ME (JSR 177 Expert Group, 2007). 4.3. MNO-independent mobile signature service provider For the iMSSP we have developed the Mobile Signature Service and a Web application. The MSS supports the operations defined in Section 3.5.1. Its different components are shown in Fig. 7. For the server we have installed a Tomcat server with support for Axis and we have developed a Web service based on this Java API that implements the operations we have just mentioned. The Mobile Signature Web service makes use of a library that implements the client operations for the MASP service based on Axis library (MASP_client). We also make use of Java Database Access (JDBC) to store information on transactions. As database we have installed MySQL. For the certification path processing we make use of a client library that invokes the service provided by the University of Murcia e-government platform (Sa´nchez-Martı´nez et al., 2008). Additionally, for those cases when the client wants a time-stamp of a signature, the MSS makes use of a time-stamp client library that invokes the time-stamp service also offered by the University of Murcia e-government platform. This platform is presented in Section 5. The Mobile Signature Web Application (MSWA), which is the Web interface of the iMSSP for the registration process and for the query of information, is based on HyperText Markup Language (HTML) and Java Server Pages (JSP).

Fig. 7. MSSP architecture.

For this entity we have adapted a Web application (SUMA Web Application – SUMAWA) and the MASP Web service as described in Section 3.5.2. SUMAWA is a Virtual Campus application that is based on PHP Hypertext Pre-processor (PHP), JSP and makes use of JBDC to store information in an Oracle 10g database. This application to request m-signatures invokes the functions of the library (MSS_Client) to access the iMSSP services. These functions are: MSS_Signature, MSS_StatusQuery, MSS_Registration, MSS_Receipt and MSS_Handshake. We have also developed the MASP Web service in order to support the notification mechanism and client requests. This service is developed by using Axis and its functionality is implemented by means of a library named MASPL that implements the operations described in Section 3.5.2. For additional operations such as certification path processing and signature verification the application invokes the University of Murcia e-Government platform by means of the corresponding libraries.

4.4. Mobile application/service provider

5. Prototype/scenario of application

The different components that are part of the development made for the MASP are shown in Fig. 8. Next we describe the main components.

In this section we present a prototype scenario that is being used by a limited number of users to test the Mobile Signature Service in a Web application. The scenario is based on the

308

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

e-Government (Sa´nchez-Martı´nez et al., 2008) and Virtual Campus (SUMA) (SUMA (Servicios de la Universidad de Murcia Abierta – Virtual Campus)) platforms of the University of Murcia (see Fig. 9). SUMA (SUMA (Servicios de la Universidad de Murcia Abierta – Virtual Campus)) is the Virtual Campus platform of the University of Murcia and it is used both providing an eLearning platform and an academic management application. Currently its potential

Fig. 8. MASP architecture.

users are around 30,000 people between students, professors and administrative staff. It has four modules: academic management (student record, payslip, guides of the degrees, etc.), extracurricular information (book sport facilities, generic chat, etc.), teaching (that is, the virtual room with spaces for the different subjects where professors can upload contents, create forums and chats, tutorship, etc.) and commercial (university shop, etc.). These modules make use of e-Government platform in order to perform tasks related to electronic document management (Sa´nchez-Martinez et al., 2008), electronic signature validation and certification path processing (Ruiz-Martı´nez et al., 2008). In these modules, particularly in the teaching module, an (associated) professor or lecturer can publish the marks of his/her pupils. Subsequently, this person has to sign and send them to the faculty secretary to make them official. This document can be sent by traditional means (the document is printed, signed by hand and presented personally or by internal snail mail) or electronically by signing the document with an electronic signature (using its own PC with a private key and a certificate that is in the Windows store or in some cases by using a university smart card). For this scenario, in a future we contemplate the possibility that this signature can be made with a mobile device. Thus, we have developed a prototype according to our proposal where the e-signature can be produced with the private key and certificate stored in the user’s mobile device. In the following section we describe the results we have obtained from the development we have made.

Fig. 9. University of Murcia platforms.

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

5.1. Performance analysis We have tested the performance of the solution we provide by means of the scenario we have just described. The different tests, which are shown in Table 1, have been made under the following conditions:

 We have supposed the SUMA application requests a signature of the pupils’ marks once these marks have been introduced. We have considered several cases. In the first case, we suppose the professor has only to sign a mark (e.g. previously the professor signed the marks of the whole group and after that he/she realizes that there was a mistake in a mark and the professor has to change it). In the second case, the professor has a group of very few people (5 people). In the third case, the usual size of the group will be around 30 people. Finally, we have considered a big group with 90 people.  We have calculated the times from 100 tests. The times we present are based on mean times. For calculating these times we have used SUN JWKT simulator.  The total time of each test (TSAP), in seconds, is the sum of the following steps (see Fig. 10): a. T1: SUMA (MASP) requests a signature to the iMSSP and the client downloads it.

Table 1 Tests of our solution in different situations. Times tests

T1

T2

T3

TSAP

Signature Signature Signature Signature

4.4 4.3 4.4 4.3

18 19.5 20.7 22.8

0.5 0.4 0.43 0.4

22.9 24.2 25.53 27.5

without download 5 marks with download (0.6 kb) 30 marks with download (2.6 kb) 90 marks with download (7.3 kb)

309

b. T2: The mobile client signs the request and sends it to the iMSSP. Optionally, the client previous to the signature could download the whole document to sign. c. T3: The MASP checks whether the request is available, the iMSSP returns the signature. From this table we can derive the following conclusions. First, the behavior of T1 and T3 remains independent of the number of marks to download. This is due to the fact that in the download request (without the document), almost every time, the size of the information of the request is the same, the only difference is the length of the description request as well as the length of the signature generated are the same. Second, the key difference is produced when the user decides to download the document. Thus, the greater the size of the document is, the more time is needed to perform the download and, therefore, the whole process. Finally, we can mention the times we have obtained might be accepted by the end users in the process of generating an electronic signature. The e-signature process is slower than using a private key installed in our personal computer. However, this solution provides the best security (the private key is in a tamper-resistant device and never leaves the smart card) and better mobility.

6. Conclusions and future work Mobile devices can be used as a signature device that generates e-signatures legally equivalent to the handwritten signature. However, currently there are many solutions to provide mobile signature in these devices. This fact implies that the Mobile Application/Service providers have to develop a wide range of solutions in order to obtain acceptance for their applications and a broad number of users. As a solution to this problem the Mobile Signature Service proposed by the ETSI appeared. However, this solution is too

Fig. 10. Scenario for the performance analysis.

310

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

closed to mobile network operators and to become successful it must be implemented by an important number of them. In order to solve this problem we have proposed a new solution that is network mobile operator-independent. It is based on ETSI proposal so as to facilitate its acceptance. Furthermore, in our proposal the user has bigger control on the signature process and she decides when she is available to receive signature requests. Our proposal has been developed and a prototype is being tested. We have presented the scenario and the results obtained in that scenario. As a conclusion, we could consider the solution is viable and could be accepted. Our proposal facilitates that mobile signature can be introduced by MASPs and produced everywhere. Thus, it becomes an extension of the handwritten signature because the signing device is almost always with the user. We have also analyzed our solution from the security point of view and we can conclude that the exchanges of information between the different parties are made in a secure way. As future work our aim is to finish the prototype with the implementation of notification mechanism and incorporate it to other scenarios such as mobile payment solutions. Once we have finished the prototype, other issues related to the acceptability of the system such as battery consumption could be analyzed. We also aim to study the use of a new Mobile Security Card, which has microSD (micro Secure Digital) format and contains a cryptographic smart card chip, to support e-signature in mobile devices.

Acknowledgments We would like to thank the anonymous reviewers for their comments and suggestions. They have significantly contributed to improve the quality of this paper. This work has been partially funded by Programa de Ayuda a los Grupos de Excelencia de la Fundacio´n Se´neca 04552/GERM/06. References Adams A, Sasse MA, Lunt P. Making passwords secure and usable. In: Proceedings of HCI on people and computers XII, Springer-Verlag, 1997. p. 1–19. Agne Nordbotten N. XML and Web services security standards. IEEE Communications Surveys and Tutorials 2009;11:18. Apache Axis, /http://ws.apache.org/axis/S, available at: 23 December, 2009. Arnold K, Gosling J, Holmes D. Java(TM) programming language (4th ed.). The Addison-Wesley Professional; 2005. Asokan N, Schunter M. Optimistic fair exchange. In: Handbooks in information systems, vol. 4, 2009. p. 365–92. Barker E, Barker W, Burr W, Polk W, Smid M. Recommendation for key management—part 1: general (revised). National Institute of Standards and Technology (NIST) Special Publication 800-57, March 2007. Bicakci K, Baykal N. Design and performance evaluation of a flexible and efficient server assisted signature protocol. In: Proceedings of the eighth IEEE international symposium on computers and communications. IEEE Computer Society, 2003. p. 1239. Bicakci K, Baykal N. SAOTS: a new efficient server assisted signature scheme for pervasive computing. In: Security in pervasive computing, 2004. p. 187–200. Bicakci K, Baykal N. Improved server assisted signatures. Computer Networks 2005;47:351–66. Blaicˇ AJ, Klobucˇar T, Jerman BD. Long-term trusted preservation service using service interaction protocol and evidence records. Computer Standards and Interfaces 2007;29:398–412. Burkholder P. SSL man-in-the-middle attacks. SANS Institute InfoSec Reading Room, February 2002. Burr WE, Dodson DF, Polk WT. Electronic authentication guideline. National Institute of Standards and Technology (NIST) Special Publication 800-63, April 2006. Chadha R, Mitchell JC, Scedrov A, Shmatikov V. Contract signing, optimism, and advantage. Journal of Logic and Algebraic Programming 2005;64:189–218. Chinnici R et al. Web Services Description Language (WSDL), version 2.0, Part 1: Core language. W3C Recommendation, 26 June 2007. Chou W. Elliptic curve cryptography and its applications to mobile devices. College Park: University of Maryland; 2003. Directive 1999/93/EC of the European Parliament and the council of December 1999 on a Community framework for electronic signatures, 1999.

Ding X, Mazzocchi D, Tsudik G. Experimenting with server-aided signatures. In: Proceedings of the network and distributed systems security symposium (NDSS’02), 2002. Domingo-Ferrer J, Posegga J, Sebe´ F, Torra V. Advances in smart cards. Computer Networks 2007;51:2219–22. Eastlake D, Reagle J. XML encryption syntax and processing (2nd ed.). W3C recommendation, 10 December 2002, 2002. Eastlake D, Reagle J, Solo D, Hirsch F, Roessler T. XML signature syntax and processing (2nd ed.). 10 June 2008, 2008. European Telecommunications Standards Institute (ETSI). Mobile Commerce (M-COMM); mobile signatures; business and functional requirements. Technical report 102 203, May 2003a. European Telecommunications Standards Institute (ETSI). Mobile Commerce (M-COMM); mobile signatures; Web service interface. Technical report 102 204, August 2003b. European Telecommunications Standards Institute (ETSI). Mobile Commerce (M-COMM); mobile signatures; security framework. Technical report 102 206, August 2003c. European Telecommunications Standards Institute (ETSI). Mobile Commerce (M-COMM); mobile signatures; specifications for roaming in mobile signature services. Technical report 102 207, August 2003d. European Committee For Standardization (CEN). Secure signature-creation devices EAL 4 + . In: CEN workshop agreement (CWA) 14169, March 2004. European Committee For Standardization (CEN). Security requirements for signature creation applications. In: CEN workshop agreement (CWA) 14170, May 2004. European Telecommunications Standards Institute (ETSI). Qualified certificate profile. Technical report 101 862, January 2006. European Telecommunications Standards Institute (ETSI). Electronic signatures and infrastructure (ESI); policy requirements for certification authorities issuing qualified certificates. Technical report 104 456, May 2007. Ford W, Baum MS. Secure electronic commerce: building the infrastructure for digital signatures and encryption. Prentice Hall; 1997. Fox D, Box J. Building solutions with the Microsoft.Net compact framework: architecture and best practices for mobile development. Addison-Wesley Longman Publishing Co., Inc.; 2003. Gehringer E. Choosing passwords: security and human factors. In: Technology and society, 2002, (ISTAS’02), 2002 international symposium, 2002. p. 373, 369. Gudgin Met al. SOAP version 1.2 Part 1: messaging framework (2nd ed.). W3C recommendation, 27 April 2007. ¨ Hassinen M, Hypponen K, Haataja K. An open, PKI-based mobile payment system. In: Proceedings of the emerging trends in information and communication security, 2006. p. 86–100. Jansen W, Scarfone K. Guidelines on cell phone and PDA security. National Institute of Standards and Technology (NIST) Special Publication 800-124, October 2008. Jobanputra N, Kulkarni V, Rao D, Gao J. Emerging security technologies for mobile user accesses. The Electronic Journal for Emerging Tools and Applications 2009;2:1–12. JSR 172 Expert Group. J2ME Web services specification. Java Community Process Program 2004. JSR 177 Expert Group. Security and trust services API (SATSA) for Java MicroEdition, version 1.0.1, Java Community Process Program, 2007. Kaliontzoglou A, Boutsi P, Polemi D. eInvoke: secure e-invoicing based on Web services. Electronic Commerce Research 2006;6:337–53. Kalman G, Noll J. SIM as secure key storage in communication networks. In: Proceedings of the third international conference on wireless and mobile communications, IEEE Computer Society, 2007. p. 55. Kangasharju J. Efficient implementation of XML security for mobile devices. In: IEEE international conference on Web services, 2007. p. 134–141. Krawczyk H, Bellare M, Canetti R. Hmac: keyed-hashing for message authentication, request for comments (RFC) 2104. Internet Society; 1997. Lee C, Ho P, Hwang M. A secure e-auction scheme based on group signatures. Information Systems Frontiers 2009;11:335–43. Lee HK, Malkin T, Nahum E. Cryptographic strength of SSL/TLS servers: current and recent practices. In: Proceedings of the seventh ACM SIGCOMM conference on Internet measurement, San Diego, California, USA, ACM, 2007. p. 83–92. Li L, Tao L. Security study of mobile business based on WPKI. In: Proceedings of the 2009 eighth international conference on mobile business. IEEE Computer Society, 2009, p. 301–304. Liao TS, Wang MT, Tserng HP. A framework of electronic tendering for government procurement: a lesson learned in Taiwan. Automation in Construction 2002;11:731–42. Mayes K, Markantonakis K. Smart cards, tokens, security and applications, 1st ed. Springer; 2008. Mobile signatures a success claims research. Card Technology Today, vol. 20, 2008, p. 5. Miro´ C. Spain’s Banco Sabadell introduces mobile signature. Card Technology Today, vol. 20, p. 12–13. Mitchell JC, Shmatikov V, Stern U. Finite-state analysis of SSL 3.0. In: Proceedings of the seventh conference on USENIX security symposium, 1998—vol. 7, San Antonio, Texas, USENIX Association, 1998. p. 16–16. Nagell B. Extending mobile identity beyond authentication. Forrester Research 2008. Neable C. The .NET compact framework. IEEE Pervasive Computing 2002;1:84–7. Nystrom M, Kaliski B. PKCS #10: certification request syntax specification. Version 1.7, request for comments (RFC) 2986. Internet Society; 2000.

A. Ruiz-Martı´nez et al. / Journal of Network and Computer Applications 34 (2011) 294–311

Ondrus J, Pigneur Y. A disruption analysis in the mobile payment market. In: Proceedings of the Hawaii international conference on system sciences, Los Alamitos, CA, USA. IEEE Computer Society, 2005. p. 84c. Onieva JA, Lopez J, Zhou J. Secure multi-party non-repudiation protocols and applications. Springer Publishing Company, Incorporated; 2008. Paulson LC. Inductive analysis of the Internet protocol TLS. ACM Transactions on Information and System Security 1999;2:332–51. Pisko E. Mobile electronic signatures: progression from mobile service to mobile application unit. In: Proceedings of the international conference on mobile business, 2007. p. 6. Resnick P. Internet message format. Request For Comments (RFC) 2008;5322. Rosenbaum R. Using the domain name system to store arbitrary string attributes. RFC 1993;1464. Rossnagel H. Mobile qualified electronic signatures and certification on demand. In: Proceedings of first European PKI workshop: research and applications, EuroPKI 2004, 2004. p. 274–286. Rossnagel H, Royer D. Making money with mobile qualified electronic signatures, en: trust. Privacy and Security in Digital Business 2005:110–8. Roßnagel H, Muntermann J. Introducing SIM-based security tokens as enabling technology for mobile real-time services. In: Identity and privacy in the Internet age, 2009. p. 163–78. Ruiz-Martı´nez A, Sa´nchez-Martı´nez D, Martı´nez-Montesinos M, Go´mez-Skarmeta AF. A survey of electronic signature solutions in mobile devices. Journal of Theoritical and Applied Electronic Commerce Research 2007;2:94–109. Ruiz-Martı´nez A, Sa´nchez-Martı´nez D, Marı´n-Lo´pez CI, Gil-Pe´rez M, Go´mezSkarmeta AF. ACVS: an advanced certificate validation service in serviceoriented architectures. In: ICIW, 2008, p. 297–302. ˜ o-Lo´pez L, Go´mez-Skarmeta A, New Fair A. Ruiz-Martı´nez A, Marı´n-Lo´pez C, Ban Non-repudiation protocol for secure negotiation and contract signing. Journal of Universal Computer Science 2009a;15:555–84.

311

Ruiz-Martı´nez A, Sa´nchez-Martı´nez D, Martı´nez-Montesinos M, Go´mez-Skarmeta AF. Mobile signature solutions for guaranteeing non-repudiation in mobile business and mobile commerce. In: Mobile and ubiquitous commerce: advanced e-business methods, information science reference, 2009b. p. 116–35. Rust C, Salsano S, Schnake L. The SIM card as an enabler for security, privacy, and trust in mobile services. In: Proceedings of the conference on ICT-MobileSummit 2008, IIMC, 2008. Sa´nchez-Martı´nez D, Marı´n-Lo´pez I, Go´mez-Skarmeta A, Jime´nez-Garcı´a T. Towards e-government: the security SOA approach of the University of Murcia. In: Proceedings of the third international conference on digital information management, ICDIM 2008, 2008, p. 813–818. Sa´nchez-Martinez D, Marı´n-Lo´pez I, Jime´nez-Garcı´a T. Electronic document management in the University of Murcia. In: Proceedings of the European UNiversity Information Systems (EUNIS) 2008 Conference, 2008. Schaad J. Internet X.509 public key infrastructure certificate request message format (CRMF), request for comments (RFC) 4211. Internet Society; 2005. Schaad J, Myers M. Certificate management over CMS (CMC), request for comments (RFC) 5272. Internet Society; 2008. Schnake L, Rust C, Oeters R. SIM card based security and trust management in mobile services. WWRF meeting, Wireless World Research Forum Meeting, 2008. Sherif MH. Protocols for secure electronic commerce, 1st ed. CRC Press; 2000. SUMA (Servicios de la Universidad de Murcia Abierta—Virtual Campus), /https:// suma.um.esS. Wagner D, Schneier B. Analysis of the SSL 3.0 protocol. In: Proceedings of the second UNIX workshop on electronic commerce, 1996. p. 29–40. Yan J. Alan, Ross, Alasdair, password memorability and security: empirical results. IEEE Security and Privacy 2004;2:25–31. ‘‘yand Turks with mobile signature programme’’. Card Technology Today, vol. 19, 2007. p. 6.