This section explains how the choice of technical solutions is made. Since a secured pay-ment system needs to fulfill at least four security requirepay-ments, it is important to find a series of components furnishing the system with that security protection. Many researchers make use of an “Onion Layer” model to analyze a security system. One of the Onion Layer models is the Onion Ring framework proposed by Wei et al.(2006). Adopting the Onion Ring framework, this thesis proposes a security map to guide the research activity and sys-tem design. The Onion Layer Framework is described in Subsection 3.3.1; the proposed security map and how the security map works are described in Subsection3.3.2.
3.3.1 Onion Layer Framework
The Onion Ring Framework, an Onion Ring m-commerce security framework, is based on VAX/OS architecture which is a popular operating system with a multi layered architecture (Wei et al., 2006). This five-layer framework is proposed for analyzing and improving mobile commerce security requirements and performance. It is employed as a perspective in building the security map in the research, and provides several starting points in order to reach proper solutions for security. The Onion Ring offers a good security performance by coordinating and pairing access authority to increasing levels of accountability (Wei et al., 2006). Figure3.5 depicts an Onion Layer m-commerce security framework adopted from Wei et al.(2006). The five layers include the security of mobile devices, language, wireless communication access control, access management, and transactions.
According toWei et al.(2006):
• The mobile device security layer is used to implement a security strategy for all mo-bile communication devices. A momo-bile device has limitations such as being
suscepti-Figure 3.5: An Onion Layer Framework for m-commerce security (Wei et al.,2006).
ble to power outages, and having narrow bandwidth and low computational capacity.
This research aims to find solutions that can be used to heighten security enforcement in this layer. As a mobile device is always utilized as a front-end facility involved in securing payment transactions, it is vital to design authentication strategies, se-cured channels, user-friendly payment schemes and receipt delivery in development of mobile devices (Thanh,2000).
• The language security layer concerns the programming language used. A secure programming language in m-commerce requires and ensures that all programming codes have restricted access to operations that can affect the environment (Wei et al., 2006). Java is classified as a secure language as it is an object-oriented programming language which permits libraries to offer secure interfaces to incoming code. In addition, Java has a byte-code verifier which can be used in checking a program at load time.
• The wireless communication access control security layer is intended to restrain mo-bile devices from accessing wireless communication channels. Currently, some tech-nologies have been employed to enhance security in this layer. Secure Sockets Layer (SSL) over Global System for Mobile (GSM) mentioned byVihinen(2004) is a good example of security protection in this layer. The HTTP combined with SSL as Hy-pertext Transfer Protocol Secure (HTTPs) also provides a security strategy in this layer.
• The access management security layer can restrict resource access, audit mobile pay-ment actions, and provide non-repudiation of transactions. A variety of technologies that can support security functions can be utilized in this layer. Multiple authentica-tion strategy system is one candidate choice.
• Transaction security concerns application level transaction security. At the applica-tion level much progress can be made toward achieving transacapplica-tion security by offer-ing users authentication, loggoffer-ing the transaction information, and generatoffer-ing digital confirmation.
The Onion Layer Framework provides programmers or system architects a starting point to design a secured system or architecture. Some security technologies and solutions are also suggested in the Onion Layer framework.
3.3.2 Security Map
In this subsection, a security map is proposed on the basis of the Onion Layer framework in order to find proper technologies and solutions that are employed in designing the archi-tecture in the present research.
Illustrated in Figure 3.6, the X-axis parameterizes the Onion Layer framework dis-cussed in Subsection3.3.1, the Y-axis represents the four security objectives explained in Section3.2, and each black spot on the grid represents a security component.
Confidentiality
Authentication
Integrity
Non-repudiation
Device Language Communication Access Transaction
X-axis
Onion Ring Framework
Y-axis Security Objectives
Figure 3.6: Security Map.
• Onion Layer Framework: Presently there are various security technologies. To choose these security technologies, the five layers in the Onion Layer is used as the starting-point. In Figure3.6, the X-axis represents the five layers outlined in the Onion Layer framework.
• Security Objectives: The present research goal is to enable the proposed architecture
protect the four objective security properties described in section3.2. The Y-axis in Figure 3.6 represents four objective security requirements. A secured architecture should be able to meet these security requirements. The Y-axis represents the four security properties.
• Security component: A potential secured technology employed in a secured system is denoted as a black spot. Each spot is placed at a cross point in the security map. The process of placing a spot at the cross point identifies a process looking for the suit-able security technology for that requirement in a system. For example, researchers are looking for technologies to fulfill the security requirement on non-repudiation.
The process on the security map is to place big back spots on the line signed by non-repudiation in the Y-axis. In the X-axis, there are five fields which are considered to be candidate solutions. In the access management security layer, as a public-key cryptography solution (digital signature) ensures non-repudiation, a spot is placed on the cross point of the non-repudiation line and the access line. In the same way, writ-ing a log in the transaction security layer can be employed to meet the requirement of non-repudiation, and so a dot can be placed on the cross point of the non-repudiation line and the transaction line.
When the proper solutions for building a system are chosen, it is necessary to consider the actual running environment of the system. A payment transaction system runs in a computational environment, which includes several computational resources, such as mo-bile device CPU, memory, and the bandwidth of wireless networks. A proper design needs to consider these environmental factors. Since the proposed architecture is implemented for financial transactions over mobile devices, which are resource-limited facilities, designing a lightweight architecture that will run efficiently and feasibly is the goal of the present research.
As illustrated in Figure3.6, the research activity can be viewed as a process of mapping secure solutions on the security map to meet the objective security requirements. Secure technologies are chosen from the collection mentioned in the Onion Layer framework (X-axis). The potential secured technologies can be utilized to meet one or more security ob-jectives (Y-axis). The chosen technologies or solutions (security components) are restricted by the particular resource environment. The most appropriate technologies are combined to build the proposed architecture.