The analysis of smartphone APIs is carried out by implementing the test configuration with existing APIs. The first experiment objective of analysing the state of current APIs, limits the experiment to developing new APIs only when they facilitate the further analysis of existing APIs. The development of new APIs is further limited to those parts of the configuration listed under the configuration’s device constraints. This limitation is necessary in order to focus on those aspects of the configuration that influence interoperability.
The absence of the configuration parts specified under network constraints does not have an impact on a mobile requester’s ability to communicate with an end-to-end secured provider.
The absence of MTOM support decreases the practicality of a WS-Security-secured mobile web services transaction because of the increased message sizes resulting from WS-Security, as was discussed in section 4.4.2. However, a requester may still interact with an end-to-end provider without MTOM.
In contrast, the absence of the configuration components specified under the device con-straints prevents a requester from interacting with an end-to-end provider. The parts specified under the devices constraints are considered to be critical. To this end, an implementation of these critical components is conducted when existing components are found to be inadequate or do not exist. MTOM support is not implemented because it does not aid in determining whether a requester may interact with an end-to-end secured provider. The rest of the method described in this section details the approach taken in the investigation of critical aspects of the configuration.
CHAPTER 5. EXPERIMENT 81
5.3.1 Top-Down Analysis of APIs
Figure 5.1: Hierarchy of API categories under investigation.
Figure 5.1 identifies the types of smartphone API that work towards the implemention of the mobile WS-Security configuration. They are presented in a hierarchy based on the discussion of WS-Security in section 3.6. This discussion shows that WS-Security is built on XML security specifications such as XML Encryption. These XML security specifications are in turn built with XML processing and cryptography APIs.
The hierarchical model, shown in figure 5.1, facilitates a top-down analysis of smartphone APIs that play a role in the provision of interoperable, end-to-end, mobile web services security.
WS-Security APIs are investigated first. New WS-Security APIs are built with XML security APIs when existing WS-Security APIs are inadequate or absent. New XML security APIs are built with base XML and cryptography APIs where existing XML security APIs are also inad-equate or missing. This top-down analysis ends when XML and cryptography APIs are absent or inadequate to build XML security APIs. These base APIs are not built because such an effort does not aid the analysis of any lower level APIs. This top-down analysis of smartphone APIs is carried out using the approach described in the following section.
5.3.2 Practical Approach to the Analysis
The top-down analysis introduced in the previous section is driven by whether the APIs in a particular category adequately fulfil their role in implementing the mobile WS-Security
configu-CHAPTER 5. EXPERIMENT 82 ration. APIs existing at a lower level of the hierarchy are analysed only if the APIs at the current layer under investigation are incapable of fulfilling their role. The definition of these roles en-ables the analysis to take place. The roles are identified through a mapping of the API categories to the requirements of the mobile WS-Security configuration.
5.3.2.1 WS-Security API
WS-Security APIs must coordinate the XML security APIs to apply the mobile WS-Security configuration mechanisms to a SOAP message. The XML security APIs may expose independent functionality, for example one library may sign XML and another may encrypt XML. It is the responsibility of the WS-Security API to combine such functionality to secure a SOAP message.
5.3.2.2 XML Security API
The XML security APIs must directly implement the mobile WS-Security configuration mecha-nisms that meet the challenges of confidentiality, integrity , authentication and message unique-ness. Confidentiality must be met through the asymmetric encryption of symmetric keys and the symmetric encryption of XML according to XML Encryption. The challenge of integrity must be met by symmetric signature generation according to XML Signature.
The XML security APIs must insert WS-Security tokens into a SOAP message. The mobile WS-Security configuration dictates that the username token must be used to meet the challenges of authentication and message uniqueness. XML security APIs must support the creation and insertion of this token into a SOAP message. The failure of existing XML security APIs to meet the challenges of confidentiality, integrity, authentication and message uniqueness as dictated by the mobile WS-Security configuration, requires new XML security APIs to be constructed from XML and cryptography APIs.
5.3.2.3 XML and Cryptography API
The XML APIs must enable the XML security APIs to insert WS-Security tokens into SOAP messages and transform XML into a format upon which cryptography operations may act. The cryptography APIs must provide the symmetric and asymmetric cryptography algorithms re-quired by the XML security APIs. The symmetric AES and asymmetric RSA encryption al-gorithms are selected for the encryption carried out during the experiment because they are considered de facto industry standards [Ferguson and Schneier, 2003]. The adoption of these algorithms within industry means that they are likely to be supported by a secure provider.
CHAPTER 5. EXPERIMENT 83 The HMAC-SHA1 symmetric algorithm is used to generate signatures in the experiment.
The HMAC-SHA1 algorithm is selected because HMAC must be carried out on platforms that support the TLS protocol [Dierks and Rescorla, 2006]. A secure provider is reasonably expected to implement the HMAC-SHA1 algorithm because TLS is the most popular mechanism deployed to secure web services. This popularity means that a secure provider will at least support TLS and HMAC [Kearney, 2005].
The end-to-end security that is enabled by these cryptography algorithms is necessitated by the possible existence of intermediaries. The reason why intermediaries are not implemented in the experiment, forms the final topic of discussion concerning the experiment method.
5.3.3 The Exclusion of Intermediaries from the Experiment
The implementation of the mobile WS-Security configuration is carried out on mobile requesters and a traditional provider only. Intermediaries are not deployed because this does not add value to the research presented. The implications that intermediaries have on end-to-end security are discussed in section 3.5.1.1 and WS-Security is selected because it deals with these issues. The deployment of the intermediaries within the experiment would serve only to prove that WS-Security is appropriate for securing a web services transaction with intermediaries along the message path. This has been established in section 3.6 and is out of the scope of the discussion because the experiment is concerned with whether a mobile requester may interact with an end-to-end secured provider.