Username and password authentication is probably the most widely used au- thentication scheme and the one users are most familiar with. When requesting a Web service a username and password can be communicated in the following ways.
By using HTTP Authentication in basic or digest mode, the username and pass- word are sent in the header of the HTTP request. Most Web service frameworks such as Apache Axis support and make this method easily available.
By using the WS-Security specification, a username token is sent as a SOAP header. Username tokens also support sending the password either as a plain text or as a digest, the latter being more secure. The idea behind password digest is that instead of sending the actual password, a value is sent that can only be computed by someone who has the password. Two additional values are sent, the nonce (n) and the creation timestamp (c). They should have the property that the UTC value of the timestamp can only differ from the servers
4.4 Securing the Mobile Web Service Framework 39
timestamp by some predefined limit. That is, the message is only valid in a predefined time window and each nonce can only be used once within this time limit [2].
The listing below shows a WS-Security header. The WS-Security header con- tains one element; UsernameToken, which contains the necessary elements Username, Password, Nonce and Created. The password is indicated to be
a PasswordDigestby the type attribute on the Password element. The Encod-
ingType attribute on the Nonce element indicates that the element value is Base64Binary encoded and has to be decoded before calculating the digest.
<wsse:Security soapenv:actor="..." soapenv:mustUnderstand="0" xmlns:wsse="..."> <wsse:UsernameToken> <wsse:Username>USERNAME</wsse:Username> <wsse:Password Type="...#PasswordDigest"> cUOHqo8mVw2sgQkG9OlW11FDM7E= </wsse:Password> <wsse:Nonce EncodingType="...#Base64Binary"> /pMTBqYfaWLQxLiMZtBwgQ== </wsse:Nonce> <wsu:Created xmlns:wsu="...">2008-07-06T11:06:24.591Z</wsu:Created> </wsse:UsernameToken> </wsse:Security>
The WS-Security UsernameToken Profile 1.0 [3] specifies the password digest function as follows.
Password_Digest = Base64 ( SHA-1 ( nonce + created + password ) )
That is the nonce, created timestamp and password are concatenated and hashed with the SHA-1 function and then base64 encoded for transmission. When a plain text password is sent only the Username and Password elements are re- quired.
Since password authentication is so popular, individuals have username/pass- word accounts in various places, and they tend to reuse the same passwords in multiple places. This makes passwords vulnerable to repurposing attacks, where administrators of one service use the registered password to access the users account in another service [2]. This vulnerability becomes even greater when the administrator personally knows the user, as is likely in the case of mobile Web services with friends requesting services from each other devices. It is also generally not considered a good practice to store passwords in their original form in the password store, here the device database. A hash func- tion should be used to transform the password, to protect the actual password in case the stores security is compromised. Storing a hash transformation in the password store however complicates matters when using password di- gest since the client would have to know and perform the same transformation function on the password before computing the digest to send.
40 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Usually Web services are not used directly by the user, they are more frequently used indirectly through some Web service enabled client. The demo applica- tion that has been constructed in this thesis is for example an online service that uses the Web services on the mobile device. Obscuring the password would probably be better handled by the user client. That is, the client would gen- erate an abstract password for the user that it would use to authenticate itself and the user to the Web services. This abstract password could be a hash of the password the user uses to authenticate to the client, or totally random gener- ated. Obscuring the password would then take place on the client side instead of the server side and the device password store would be treated as unsafe. Through the manager interface the device owner is able to create users and assign them privileges. The management Web services should also make it possible for clients to request a username and access to a service or operation.
Using encryption and digital signatures
A username scheme only provides authentication but does not provide any message integrity. The message could be tampered with during transmission or its content read by a third party. The gateway provides message integrity to an extent since all requests through the gateway are secured on the transport layer by HTTPS and SSL. As mentioned, the weakness is that the connections are terminated at the gateway and thus do not provide true end-to-end secu- rity, it can only be trusted if the gateway is trusted. When one client is directly requesting services from another this is probably sufficient. Another possible scenario is two clients exchanging data between a third party service, and the clients wanting to protect the integrity of data which they pass through the service. An example of such a service could be a calendar synchronization ser- vice, allowing synchronization of events between parties. In the current setup the calendar service would request events from one party and relay it to the next one. In the process it would be able to do anything with the data, without the parties knowing. To protect the data integrity the parties would have to sign their data with a digital certificate before sending it through the service or encrypt parts of the message such that only the intended recipient can decrypt it.
WS-Security supports both message level encryption, where selected parts of the SOAP message can be encrypted, and the usage of X.509 Public Key Infrastructure (PKI) certificates to sign messages or parts of message. Selective encryption of XML elements is specified by the XML Encryption W3C specification and used by WS-Security. It defines how the encrypted element and information about the encryption, such as encryption method and key, should be trans- mitted. Commonly, the data is encrypted by using a symmetric-key and the symmetric-key encrypted with the recipients public-key. The recipient then uses his own private key to decrypt the symmetric key and can then decrypt the message. The information about the keys are contained in a
<xenc:EncryptedKey ...>...</xenc:EncryptedKey>
4.4 Securing the Mobile Web Service Framework 41
<xenc:EncryptedData ...>...</xenc:EncryptedData>, XML block. The Encrypted Data block is given a unique id and in the Encrypted Key block there is a reference to the ids encrypted with this key. It thus becomes possible to encrypt multiple blocks within the same message with multiple or the same key, where one encrypted block can even contain another encrypted block. When a message is encrypted with the recipients public asymmetric key, only the intended recipient can decrypt it with his public key. The same property holds true in reverse, if a sender encrypts a message with its private key, it can be decrypted with his public key. This property is used in digital signing of messages. The sender of a message creates a hash of the message (to reduce size of information that need to be encrypted) and then encrypts the signed hash with its private key. The intended recipient can then validate that the message did in fact come from the sender by calculating the same hash of the message, decrypt the signed hash with the senders public key and check if they match. PKI provides a trusted key distribution framework, a PKI X.509 certificate con- tains the owners public key, identity of the owner and other information like expiry date signed by a trusted Certificate Authority (CA) with its own private key. WS-Security with the XML Signature specifies how a SOAP message can be signed and the signature transmitted within the message. Instead of a User- nameToken as shown above, the senders certificate chain is carried in a Bina- rySecurityToken element. The signature of the message is carried within a Sig- nature element, both contained in the WS-Security <wsse:Security ...> header.
Signing a message with a digital signature also proves that the message could only have originated from the owner of the digital certificate that was used to sign the message and could thus be used to replace username/password authentication. This would be especially useful when authenticating a well known central service provider like for example Google Calendar. When mak- ing a request to a users device, Google Calendar would sign the messages with its digital certificate. Upon receiving the incoming message with the digital sig- nature, the framework would verify the certificate and ask the user if the owner of the certificate signed towww.google.comissued byThawte SGC CAshould be granted access to the service and operation in question. Then a rule could be set to automatically grant this access in the future. The framework would in- clude a certificate store containing certificates of trusted certificate authorities like Thawte and VeriSign.
Other security approaches
Mobile devices have some other interesting properties in regards to security that can be used. First of all their location and use of network connections vary. An option in the mobile Web service security configuration, could be to choose on a network by network basis what services should be available. Allowing different set of services to be requested through the gateway, from within the workplace network, a hot spot in the mall and the home network.
42 CHAPTER 4. MOBILE WEB SERVICE FRAMEWORK DESIGN
Mobile devices also have the advantage that it is easy to simply ask the user. Users could mark specific services so that they would be asked each time the service is being requested, or they could be asked the first time a user requests a Web service he has not been granted access to, followed by an option to create a rule for future access.
Security as a service
In SOA architecture everything should be implemented as a service, includ- ing the security. The different services that an enterprise publishes are very likely to be spread around various servers with different run times. A central security service brings the benefits of just implementing and enforcing security restrictions in one place for every service. Clients then request a security token from the service and use it to authenticate themselves to other services. Each service then only needs to validate the security token. If clients do not provide a security token, the service can forward the request to the security service or deny it.
This scheme is not very optimal when transferred to the mobile device. First of all, services are published from the same location and in the same run time, if published through the same framework. Clients would still need to know how to identify themselves with the service but they would not have to provide the authentication details in each request, instead they would have to provide the token. Burden would be added on the framework/security implementation since it would have to maintain information about valid tokens additionally to the authentication information. A much simpler approach is to simply imple- ment the security constraints in a central function/class that can be applied to each service. However if the gateway is trusted, a security service could be im- plemented at the gateway. Further discussion on that possibility is in chapter 7.
Code integrity
As the previous discussion about the Nokia Mobile Web Server security model in 3.4 indicated, all security measures are breached if malicious code is de- ployed on the device. To further increase the integrity of code published as Web services, the framework could offer a method to get hash checksums of installed services and the checksums could be compared to checksums of the service implemented by a trusted repositories / implementations of the same service for the platform. This comparison could be done by the gateway or requesters. This would also be a method to validate that the needed version of the service was installed.
4.4 Securing the Mobile Web Service Framework 43
Security recommendations
To summarize the discussion the following recommendations and best prac- tices should be followed:
• The gateway provider has to be trustworthy, just like mobile network operators also have to be trusted.
• Interoperable authentication methods should be used to restrict access to services.
• Methods accessible through a direct WLAN request could be limited to only those that do not transmit sensitive data.
• Avoid password reuse.
• Use Web service clients to create obscure or hashed passwords for users and limit the exposure of real passwords to a mobile server.
• Creating username and password accounts and assigning privileges to users should be possible through services.
• Access to services could be based on real time user consent, by asking the user directly and then possibly creating an appropriate access rule. • Hash checksums of installed services should be made available and be
Chapter 5
Mobile Web Service
Framework Implementation
5.1
Introduction
The Mobile Web Service Framework has been implemented for Nokia S60 de- vices on top of the Nokia Mobile Web Server project. The Mobile Web Server solution is used to solve the addressability problem and makes the Nokia plat- form feasible as a test case platform. Due to its easy integration with the Mobile Web Server through mod python and its feature rich API, PyS60 has been cho- sen as the application development platform.