partySecurity against Attacks: the security of data transfer over wireless networks relies on the security technique applied to it. In particular, in all the frameworks stated above, the message transferred from the client to either the proxy server or the merchant must be secured by deploying security services provided by application-layer and transport-layer pro- tocols. For example, in WSET FAB02, the client performs SET, an application-layer protocol, payment transactions over WTLS/TLS protocols which are transport-layer protocols.Additionally, there is a concern about the security of agent-based frame- work. As discussed in section 2.4.2, SET/A 37 is vulnerable to attacks because the client allows the mobile agent to bring her sensitive information, such as private key or credit-card number, and generate an encrypting key in the merchant’s environment.
Integrated Mobile Payment FrameworkAccording to the discussion in section 2.4.4, it can be seen that each mobile payment framework has its own advantages and disadvantages. From our point of view, we can offer a framework which is more general and offers a better solution than the existing frameworks in that:We deploy a non proxy-based payment protocol to perform payment transactions in the system.
Best services for writing your paper according to Trustpilot
Thus, we can achieve lightweight payment transactions. We deploy a mobile agent to perform transactions on behalf of the client to reduce connection cost. We deploy proxy-based framework by setting up a proxy server to pro- vide a trusted environment for the mobile agent to perform high computational operations and to generate the client’s request following the structure of the payment protocol.Figure 2.8 presents the framework that illustrates our approach. Note that A(C) stands for an agent A owned by the client C.
Our framework incorporates the main advantages and solves the problems of the existing frameworks. Later in this thesis, chapter 4 will present our framework in details. We demonstrate the practical usefulness of the proposed framework by applying it to SET protocol Mas97. Then, in chapter 5, two non proxy-based payment protocols are presented to enable practical and secure mobile payment. Applying either of them to our framework enhances transaction security and performance.
Fixed NetworkWireless Network Client A(C) Proxy Server MerchantB Figure 2.8: Integrated mobile payment framework Securing Transfer of Account Information during Payment TransactionsIn a shared-key based system, a user and the system (or another user) share secret information (or secret key) that can be used for several purposes:• Credential or Authentication Token: the shared secret can be used to authenticate the user to the system such as access password. For ex- ample, the user and the system establish a secure communication channel by running a key exchange protocol. Then, the user supplies her user- name and password to the system through the secure channel as a request for remote access. The system checks if the supplied username and pass- word match the ones in its database.
If they are matched, the user is allowed to access the system resource.In some applications such as credit-card payment, a cardholder (or a client) sends her credit-card number, which is the secret shared between herself and her (card) issuer, as an authentication token including payment-related information to a merchant through a secure channel, such as SSL FKK96, to request a payment to the merchant. The merchant then forwards such information to the issuer to request for payment authorization. As the credit-card number is shared between the client and the issuer, the issuer can verify that the client’s request is valid.
The issuer then deducts the requested amount from the client’s account and transfers it to the merchant’s account.• Cryptographic Operations: the shared secret can be used as the key for encrypting or hashing a message sent between parties. For example, Alice sends Bob a message, encrypted with a shared key between herself and Bob, securely over an open network.
If Bob did not previously generate this message, he can infer that this message has been originated by Alice. This is because, in addition to Bob, only Alice can generate the message.Considering Internet payment scenario, the most obvious application which deploys shared secrets is the credit-card payment scheme over SSL 37. In this scheme, a credit-card number is considered as an authentication to- ken shared between its owner (a client) and her issuer.
To make a payment to a merchant, after a SSL connection is established, the client supplies her credit-card number and relevant information, such as date of birth and billing address, to authenticate herself to the issuer. In ST protocol Mas97, the client’s credit-card information as an authentication token is encrypted with the payment gateway’s public key and then signed with the client’s private key. When it is transferred to the issuer (via the payment gateway), the issuer can infer that this request has been originated by the client and it contains the valid authentication token. In this section, we focus on the security of credit-card information transfer during payment transactions to point out the security issues related to the deployment of shared secrets in payment trans- actions.Obviously, the most sensitive information in any payment system is ac- count information which is shared between a client and her issuer.
Several security issues related to the exposure of the account information have been reported 38, . In SSL-based credit-card payment system, although the credit-card information is securely transferred through a SSL channel, it is still revealed to the merchant who is considered as an un trusted party. In SET protocol 39, the encrypted credit-card information is decrypted by the payment gateway and then forwarded to the issuer. This problem may arise if the payment gateway and the issuer are different parties. That is, the payment gateway may be a company that is monitoring the system.
It may possibly have a conspiracy with an attacker, or even the merchant, so that the attacker can get the client’s credit-card information without any attempt to decrypt any messages.Moreover, the credit-card number is considered as long-term, reusable
