Smart Card & Identity News A New Flavour for eCash
Smart Card & Identity News A New Flavour for eCash
Smart Card & Identity News A New Flavour for eCash
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
Such standards help the industry work together and benchmark best practices but they remain just one<br />
fundamental element of contributing to successful mobile payment security. Technology that makes the security<br />
of provisioning mobile payment applications as secure as issuing cards is also required, to build that much<br />
needed consumer confidence.<br />
Consumer fear around fledgling mobile payments techniques often centre on security issues. Much of this<br />
reticence to adopt mobile payments comes from the perceived risk of data being intercepted during a<br />
transaction. But threats exist at every stage of the mobile payment lifecycle, including how to get a payment app<br />
onto a phone securely and efficiently in the first place. Building the data needed to issue a payment application<br />
and create the secure messages to personalise a handset can be a lengthy and inefficient process, the numerous<br />
cryptographic functions posing a risk of exposing sensitive data.<br />
This initial set-up process or ‘provisioning’ normally happens over-the-air (OTA). It is a process that increases<br />
security risks due to the number of parties involved - typically the payment application provider (usually a bank),<br />
a Trusted Service Manager, the Mobile Network Operator, and the end user. A critical success factor is keeping<br />
this process highly secure to ensure that no data is compromised. Successful provisioning uses unique<br />
personalisation keys, to not only protect the loading of in<strong>for</strong>mation onto a device but also the subsequent<br />
transactions made by the application.<br />
As secure as traditional cards<br />
By applying the latest cryptography methods, users can ensure that ‘provisioning’ happens as securely as possible<br />
and at the same level as issuing traditional payment cards. Providers of physical cards tend to prefer Hardware<br />
Security Modules (HSMs), which generate and protect the encryption keys that are essential to managing<br />
issuance risk. This approach is also relevant <strong>for</strong> provisioning services to a mobile phone and can greatly simplify<br />
the process while simultaneously avoiding the vulnerability of keys stored in software. Overall, the main benefit<br />
of an HSM is to secure encryption keys and sensitive data in a way which ensures that such data is never<br />
exposed. In this way, the risk <strong>for</strong> the service provider is significantly reduced.<br />
However, while encryption is essential to the security of mobile payments, it isn’t the sole answer. For maximum<br />
security in this new payments channel, encryption must be teamed with authentication technologies that provide<br />
protection <strong>for</strong> data exchange and authorisation.<br />
Minimise the risk<br />
As the mobile payment world continues to evolve at lightning speed, industry best practices are far from being<br />
agreed, with operators and related parties still undecided about who should control the mobile wallet. But one<br />
thing that lies firmly beyond discussion is that security remains the primary barrier to adoption <strong>for</strong> most<br />
consumers.<br />
Overcoming this concern is no easy task, requiring a combination of robust standards and best practice, coupled<br />
with the right technical path to guarantee the experience is safe from the second that a user decides to download<br />
a payment app. If any business wants to take advantage of the impending explosion in mobile payments, security<br />
needs to be at the foundation of their approach to minimise risk and encourage widespread consumer adoption.<br />
<strong>Smart</strong> <strong>Card</strong> & <strong>Identity</strong> <strong><strong>New</strong>s</strong> • March 2012<br />
11