Using mobile phones to access Web Services in a secure way Dan Marinescu March 7, 2007
Abstract Web Services is a technology that has gained in acceptance and popularity over the past years. The promise of providing interoperability in a heterogeneous world, as well as the possibility of offloading operations that require high processing power, make the mobile phones an ideal target device for accessing web services. But along with these advantages come security concerns. This article presents how Web Services can be accessed using a mobile phone, and how the communication between the web service and the mobile phone client can be secured.
Contents 1 Introduction 2 2 Background 3 2.1 JavaME..................................... 3 2.2 Web Services.................................. 3 3 Accessing Web Services using the JavaME Web Services API 4 3.1 Introduction to the J2ME Web Services API................ 4 3.2 Using the JavaME Web Services API..................... 5 4 Security and Trust Services API: Providing security for JavaME applications 8 4.1 Introduction to the Security and Trust Services API............ 8 4.2 Using SATSA PKI to secure the communication with Web Services.... 9 5 Discussion and Conclusion 12 1
1 Introduction In this article, the Java Platform, Micro Edition (JavaME) will be used to demonstrate how a mobile phone and a Web Service can communicate in a secure way. Section 2 briefly introduces the JavaME Platform and the basic concepts behind Web Services. Afterwards, in Section 3, the JavaME Web Services API will be presented, together with an example of how to access a Web Service using this API. Section 4 introduces the JavaME Security and Trust Services API and extends the previous example by using this API to secure the communication between the mobile phone and the Web Service. Finally, Section 5 concludes this article. 2
2 Background 2.1 JavaME JavaME is an application platform for mobile devices. Developers using JavaME can develop applications, using the Java language, that are portable across a long range of mobile devices (like PDAs, TV set-top boxes and of course mobile phones) and operating systems. A further discussion of JavaME is outside the purpose of this article. More information regarding JavaME can be found at http://java.sun.com/javame/index. jsp. 2.2 Web Services In order to be accessed by a client, a Web Service needs to be developed and deployed in a way that is understandable for the client. The Web Services Description Language (WSDL) is an XML-based language used to describe a public interface for a Web Service. This includes information like the address where the Web Service is located and the publicly available functions it provides. After a Web Service has been deployed, it can be accessed by a client. The communication between the client and the Web Service takes place using SOAP, an XML-based protocol used to exchange object data. Although SOAP can be used in conjunction with several transport protocols like SMTP or FTP, it is HTTP that is becoming the standard way of transporting SOAP. 3
3 Accessing Web Services using the JavaME Web Services API 3.1 Introduction to the J2ME Web Services API The Java ME Web Services API (WSA) is defined through the Java Community Process as Java Specification Request (JSR) 172. Its purpose is to provide mobile applications written in Java with a way of accessing Web Services, and it does that by providing two optional packages: A package for XML processing, based on the Simple API for XML 2 (SAX2) 1 and the Java API for XML Processing (JAXP) 2 A package for remote service invocation, representing a subset of the Java API for XML-based RPC version 1.1 (JAX-RPC 1.1) 3 For the purpose of this article we will focus on the second package, namely the JAX-RPC 1.1 subset. Figure 1 shows the common components of a JavaME application that consumes Web Services using WSA. The two main components that are communicating are the service provider (also known as the endpoint) and the service consumer (also called the client). They communicate over the network by using SOAP encoded messages, typically transported over HTTP. Figure 1: The components of a mobile application consuming Web Services with JavaME WSA [2] 1 see http://www.saxproject.org for more information 2 see http://jcp.org/en/jsr/detail?id=63 for more information 3 see http://java.sun.com/webservices/jaxrpc/ for more information 4
On the service provider side, the services represent the business logic and are hosted inside a so-called SOAP engine. The SOAP engine provides the JAX-RPC SOAP runtime for service invocation. The ties component represent the proxy classes responsible for marshalling and unmarshalling data. Requests and responses are, in this case, transported over the Web by means of a Web Server. The service consumer side is located inside the mobile device. According to the JSR 172 specification, the JAX-RPC runtime is embedded in the device by the manufacturer. On top of that are the client stubs, which represent the remote service, thereby hiding the complexity of data-encoding and communication with the service. The application logic uses the stubs to access the services as if it would be locally (from the applications point of view) located. Note that WSA provides only a subset of JAX-RPC 1.1. This involves some limitations, among which no support for SOAP Message Handlers and the possibility of accessing SOAP Endpoints only in document/literal modus. 3.2 Using the JavaME Web Services API Now that the basic concepts behind WSA have been introduced, let s see an example of how this API can be used to access a Web Service. In this example, the mobile client will access a Broker Web Service that buys stocks on behalf of the client. The client does that by calling the method buy(string identifier), just like in Figure 2. In order to keep this example simple, the only parameter of the buy() method is an identifier which contains information regarding the customer, the type and amount of stocks to be bought. The Web Service answers by confirming that the stocks were bought. Figure 2: Example: Mobile client calls the Broker Web Service 5
The first step in developing the client is generating the client stubs. This can be achieved by using the stub generator that comes with the Sun Java Wireless Toolkit 2.5. As shown in Figure 3, the stub generator needs to be provided with the URL of the WSDL file, the output path and the name of the package where the stub files will be generated. Figure 3: Example: Mobile client calls the Broker Web Service In this example, two files are generated: BrokerWS_Stub.java and BrokerWS.java. The BrokerWS.java is an interface which provides the signature of the buy() method provided by the Broker Web Service. The BrokerWS_Stub class implements this interface, as well as the javax.xml.rpc.stub interface and masks the entire complexity of the remote method invocation. Since these files are automatically generated, it is not recommended to edit and modify them. 6
Once the stubs have been generated, an object of type BrokerWS_Stub can be instantiated in the application code, just like in line 2 of Listing 1. In line 3, the target service endpoint address is specified by using the _setproperty() method, while in line 4 is indicated that the client wants to participate in a session with a service endpoint. After these configuration steps, the buy() method can be called. Line 5 shows that, from the client applications point of view, the call takes place just like a normal local call. The String response contains the answer of the Web Service. 1... 2 SecureBrokerWS_Stub service = new SecureBrokerWS_Stub (); 3 service. _setproperty ( Stub. ENDPOINT_ADDRESS_PROPERTY, serviceurl ); 4 service. _setproperty ( Stub. SESSION_MAINTAIN_PROPERTY, new Boolean ( true )); 5 String response = service. buy (" fooid "); 6... Listing 1: Calling the Broker Web Service by using the stubs in the application code This example shows how simple it is to use WSA together with the Sun Java Wireless Toolkit 2.5 for accessing Web Services. After the stubs were automatically generated, it only took 4 lines of code to call the desired method on the Web Service. 7
4 Security and Trust Services API: Providing security for JavaME applications 4.1 Introduction to the Security and Trust Services API The Security and Trust Services API (SATSA) is defined through the Java Community Process as JSR 177. The main driving factor for this API was e-commerce and the motivation was to provide mobile applications with the ability of communicating in a secure way. SATSA is focused on achieving security by using so-called secure elements like Smart Cards or Wireless Identification Modules which provide basic cryptographic functionalities like confidentiality, authentication and integrity by means of encryption and digital signatures. SATSA is composed by four sub-apis, as it can be observed in Figure 4. Furthermore, they can be categorized in communication APIs: SATSA-Application Protocol Data Unit (APDU) Communication API and SATSA-Java Card RMI (JCRMI) Communication API, used for communicating with secure elements like Smart Cards by means of a lowlevel respectively an RMI-based protocol, and pure security APIs: SATSA-Public Key Infrastructure (PKI) Signature Service API and SATSA-CRYPTO Cryptographic API. For the purpose of this article the focus will be on SATSA-PKI. Further information with respect to the other SATSA APIs, including SATSA-PKI, can be obtained in [3], [4] and [1]. Figure 4: The SATSA APIs [3] SATSA-PKI provides a mobile application with the possibility of both requesting a digital signature from a Smart Card and managing certificates. A generated signature 8
can either be used to provide authentication, or it can be used for integrity and nonrepudiation. 4.2 Using SATSA PKI to secure the communication with Web Services Section 3 described how WSA can be used to access a Broker Web Service. The problem with this example is that no authentication takes place, so that anyone can use the service to buy stocks on behalf of someone else. In this subsection an approach to solving this problem is presented, using digital signatures generated by a Smart Card to authenticate the customer. For this, the Secure Broker Web Service is used as service endpoint. This Web Service is similar with the Broker Web Services, the only difference being that the Secure Broker Web Service expects a byte array as input for the buy() method. Generating the appropriate stubs and calling the Web Service is done just like in Subsection 3.2. The communication between the Mobile Client, the Smart Card and the Web Service is shown in Figure 5. Figure 5: Example: Mobile client generates a signature and calls the Secure Broker Web Service To generate a digital signature, the class CMSMessageSignatureService belonging SATSA-PKI API is used. This class defines 3 methods: one for authentication using a 9
string as input for the signature, one for authentication using a byte array as input and one for integrity and non-repudiation that uses a string as input. For this example, the method authenticate() taking a string as input will be used. The result will be a byte array that complies to the Formatted Digital Signature 4 format. Since the actual signing process takes place on the Smart Card, a communication with the Smart Card must take place.the Sun Java Wireless Toolkit (WTK) comes with the Java Card Platform Simulator which can be used to simulate Smart Cards in the Sun WTK emulator s slots. Along with this simulator come a couple of prebuilt memory images and a demo of how to use the SATSA-PKI API together with such an image to generate a digital signature. In order to communicate with the Secure Broker Web Service, the client application needs to provide a byte array containing the previous identifier, but this time it has to be signed and must include the certificate corresponding to the private key that was used to sign the string identifier. Listing 2 shows how this byte array is created. In line 4, the method autheticate() is called using as parameter a string identifier to be signed. The second parameter specifies that both the certificate and the content should be embedded in the output, whereas the canames parameter indicates which certificate should be used. The userprompt parameter is a string that is shown to the user when a connection with the Smart Card can not be established. To establish such a connection using the Sun WTK, the Java Card Platform Simulator needs to be started using the appropriate memory image. The entire code in Listing 2 must be executed in a separate thread. This is because the JSR 177 specification obliges the manufacturers of mobile devices that provide SATSA support to handle issues like requesting a PIN from the user in order to access the private key used for signature or showing the string to be signed to the user previous to signing. Such UI interaction can cause problems if is not implemented in a separate thread or if the application does not take in consideration that generating a signature involves additional user interaction. 1... 2 String caname = "c=us,st =CA,l= Santa Clara,o= dummy CA,ou=JCT,cn= thehost "; 3 String [] canames = new String [1]; 4 authsignature = CMSMessageSignatureService. authenticate ( stringtosign, CMSMessageSignatureService. SIG_INCLUDE_CERTIFICATE CMSMessageSignatureService. SIG_INCLUDE_CONTENT, canames, userprompt ); 5... Listing 2: Generating a signature using SATSA-PKI Once the byte array containing the signed identifier (this is the same identifier used with the Broker Web Service and presented in Section 3) has been generated, it can be used as parameter to call the Secure Broker Web Service. In such a way the Secure Broker 4 http://www.ietf.org/rfc/rfc2630.txt 10
Web Service can make sure that the request to buy stocks comes from the right person and has not been faked. The mobile client and the Web Service have now communicated in a secure way. 11
5 Discussion and Conclusion The purpose of this article was to show how two of the recently developed, optional JavaME APIs can be used to consume Web Services in a secure way. Using this approach presents some problems and limitations. The biggest problem is that, in this way, the developer of a Web Service must deal with both business logic and security issues. This is definitely not the right way, since security is a non-functional property of a system and should be separated from the business logic. Another problem of this approach is that there is no way of providing confidentiality by encrypting sensitive data or parts of a SOAP message transported over the network. Transport layer security like SSL cannot help here, since SOAP messages might travel between more hops. Message layer security can be provided by using WS-Security 5, a standard developed to solve the special security requirements of Web Services. It is also impossible to determine if a Web Service requires security just by analyzing the WSDL file. A solution for this problem, still under development, is to use a standard called WS-Policy 6. Still, the approach presented in this article can be used when the developer of the mobile application and the developer of the Web Service are one and the same, and the only security requirement is to provide authentication by using strong cryptography, like smart cards do. 5 http://www.oasis-open.org/specs/index.php#wssv1.0 6 http://www.w3.org/submission/ws-policy/ 12
References [1] Sun Microsystems. Security and trust services apis for java 2 platform, micro edition. http://developers.sun.com, December 2004. [2] C. Enrique Ortiz. Introduction to j2me web services. http://developers.sun.com, April 2004. [3] C. Enrique Ortiz. The security and trust services api for j2me, part 1. http://developers.sun.com, March 2005. [4] C. Enrique Ortiz. The security and trust services api for j2me, part 2. http://developers.sun.com, September 2005. 13