 |
|
|
Needed: Solutions that tighten m-commerce security without strangling it.
M-commerce has existed since the first credit-card purchase made during a cellular phone call. The crucial next step is to make m-commerce more secure while also making it more convenient.
The first m-commerce transaction was 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 also is 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 probably have 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.99999%) 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 convenient to use, but that also becomes the weakest link in the security 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 good chance that Jane Doe will forget the 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 of protecting phones with strength and convenience. The subscriber’s signature or fingerprint can be thought of (mathematically) as a large random number. These are easy for the owner to present to a machine but difficult for others to fake, and they 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 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, it claims to obscure the software and data inside the phone in ways that make the internal process hard to intercept and subject to failure if manipulations to the software are made. Pointsec 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, building security 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 they do not prevent attacks on the unencrypted data that exists at intermediate points in the network.
Public-key (also 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? How do you ensure that it is valid? And, how can the overhead of public-key encryption be reduced?
According to Ambarish Malpani, ValiCert chief architect & founder, 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 its public key.
Validation of a certificate is complex, and it is desirable to off-load it from a wireless device to a server with more processor power and higher speed. The simple certificate validation protocol is an IETF protocol, of which Malpani is senior author. A competing proposal is to extend the existing IETF online certificate status protocol 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 usually are 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.
Solving the problems of m-commerce will take time. The growing industry eventually will settle on a set of solutions to all of the different problems, building end-to-end solutions that are 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