 |
|
|
M-Commerce has existed since first credit card purchase made through a cellular phone call. The challenge is to make m-commerce more secure while also making it more convenient.
The first m-commerce transaction was very insecure, because anybody with an FM scanner could have eavesdropped on the credit card information as it was being spoken over the phone. The only security came from the need to listen to hundreds of conversations to pick up something rewarding. This type of transaction is also inconvenient because the same information has to be provided on every transaction (credit card number, expiry date, name on card ...well, you know the drill, you have probably done it hundreds of times).
The problem with convenience is that generally the more secure a system is, the harder it is to use. A 4-digit numeric PIN, for example, only has 10,000 combinations – trivial for a machine to crack. A more secure system is to force people to use long passwords with a mixture of letters, digits and punctuation. But who is going to remember “$a37fj!@7Zwp4” in the morning?
This is a dilemma for a mobile device programmed with high security public key cryptography. When used for m-commerce transactions, the system can be 100% (well, 99 followed by lots of 9’s) sure that Jane Doe’s phone is being used for the transaction. But, if there is no protection on the device, how can the system tell if it has been stolen or, perhaps more insidiously, borrowed by a ‘friend’ to obtain some free products or siphon off m-commerce data, and later returned without the owner ever being aware that it was used illicitly? A system without protection on the device is very convenient to use, but as insecure as the weakest link in the chain. If the system is strengthened with a hard-to-guess and lengthy PIN code selected by the network (to avoid “1234” being used) there is a very good chance that Jane Doe will forget the PIN code, type it in erroneously or get so frustrated with the inconvenience that she will just stop using her phone’s m-commerce capabilities.
Biometric authentication offers some promise at protecting phones with strength AND convenience. Your signature or fingerprint can be thought of (mathematically) as a very large random number. They are very easy for the owner to present to a machine, but very difficult for anyone else to fake, and cannot be lost, stolen or borrowed. However, even biometric systems have problems. If they transmit a mathematical summary to a network device, it could be intercepted. Or, if biometric authentication is internal, the device could be captured, and authentication bypassed. Cloakware Corp. (www.cloakware.com) tries to solve this problem by analyzing the signature inside the phone, and only unlocking access to the cryptographic data if the analysis is successful. Further, they obscure the software and data inside the phone in ways that they claim make the internal process hard to intercept, and subject to failure if manipulations to the software are made. Pointsec (www.pointsec.com) goes even further by encrypting everything within the mobile device.
Securing the wireless device from fraudulent use is not enough, the transaction from the device to the m-commerce provider must also be secure. For this, security built into cellular, PCS or current WAP systems is not good enough, because it does not run end-to-end. Cellular and PCS authentication and encryption systems are even less useful, because they only protect the radio interface. Security systems with breaks in the middle eliminate eavesdropping by people with scanners, but do not prevent attacks on the unencrypted data that exists at intermediate points in the network.
Public Key (more correctly known as asymmetric key) encryption will play a critical role in securing transactions from one end to the other. Encrypting data with a public key ensures that only the content provider that owns the corresponding private key can decrypt it. But, where do you get the public key from? How do you ensure that it is valid? And, how can the overhead of public key encryption be reduced?
According to Ambarish Malpani, Chief Architect and founder of ValiCert, the answer to finding and validating a public key is the use of certificates. The Certificate Authority (CA) is an intermediary that maintains a list of public keys within certificates. By knowing the address and public key of the CA, a device can request a certificate based on, for example, a URL of a bank, and then obtain their public key.
Validation of a certificate is quite complex, and it is desirable to offload it from a wireless device to a server with more processor power and higher speed. The Simple Certificate Validation Protocol (SCVP)) is an IETF protocol, of which Malpani is senior author. A competing proposal is to extend the existing IETF Online Certificate Status Protocol (OCSP)) to incorporate validation.
The strength of public keys comes at a price. To gain the security of asymmetric key encryption without the full price, public keys are usually used to exchange private (symmetric) keys. Once private keys have been established, the transaction can be protected with the security of public key encryption and the efficiency of private key encryption. This is the method used in browsers, for example (SSL).
Solving the problems of m-commerce will take time. The growing industry will eventually settle on a set of solutions to all of the different problems, building end-to-end solutions that are both secure, cost-effective and easy for consumers to use. Ideally, the solutions should be independent of the radio technology, so consumers could have devices with cellular, 802.11 and Bluetooth capabilities, and use the same security system to make purchases, manage their finances and communicate privately.
© – Copyright