Professional Documents
Culture Documents
Growth Inhibitors:
1.
2.
3.
4.
Major Players:
Target
Type
User
Vulnerabil
ity
Inadvertent
installation
of
malicious
software on
mobile
phone by
user
User
Absence of
two-factor
authenticat
ion
POS
system
accepts
OTA
transmissio
ns
Service
Provide
r
Threat
Risk
Downloade
d
application
intercept of
authenticat
ion data
Theft of
authenticat
ion
parameters
,
information
disclosure,
transaction
repudiation
Fraudulent
transaction
s, provider
User
masqueradi
ng
Malicious
party
floods POS
system
with
meaningles
s requests
Denial of
Service
(DoS)
Counter
Measures
Authenticatio
n of both user
(PIN) and
application
(digital
signature by
trusted third
party), TPM
Two- Factor
Authenticatio
n
Request
filtering at
reader based
on mobile
device-reader
relative
geometry
2. Secure design: The first headline of MSDNs Lessons learned from five
years of building more secure software is: Its not just the code.
According to them, many vulnerabilities are design issues and not related
to coding at all.
3. Secure application deployment: In the deployment phase, make sure
your customer is directed to, and installs, the correct application. This can
be achieved in many different ways and can have varying degrees of
impact on the user experience. The recommendation here is to design a
secure application deployment process that keeps your risk within
tolerance, without deteriorating the user experience too much.
4. Upgrade through the official application stores: Make sure you
actively warn against the customer installing upgrades from other sources.
Be aware of security issues that might allow fraudsters to publish
application upgrades that appear to have been signed and built by you.
5. Maintain the application: make sure that changing circumstances (e.g.
new Operating Systems) do not affect your application security and that
release management includes proper source code control and versioning.
6. Sensitive data not recoverable: make sure that you store the minimum
set of sensitive data on the device and that it is not possible to recover
usable data on lost and stolen devices. If this is not achievable for the
design of your product, make sure you devalue the usable data that can
be recovered (e.g. tokenisation).
7. Cover time: make sure you obfuscate the data and code in your mobile
application to protect against reverse engineering. Make sure you have
carried out a cover time analysis and know how long it will take before
your obfuscation cannot be considered secure anymore (this requires up
to date expertise on the latest attack methods).
8. Hiding/obfuscation of keys: Make sure you obfuscate keys that have to
be stored as part of your mobile application and that you protect them
with a recognised mechanism, such as key wrapping. You may want to use
hardware backed key storage when available.
9. App integrity protection: you may want to implement mechanisms to
protect the application integrity to mitigate the risk of malware trying to
modify or gain access to your installed applications or data.
References:
http://www.cgap.org/blog/drivers-mobile-money-profitability
http://www.strategyr.com/MarketResearch/Mobile_Wallet_Market_Trends.asp
http://www.futuremarketinsights.com/reports/global-mobile-payment-transactionmarket
http://www.visaeurope.com/media/pdf/secure%20mobile%20payment
%20systems%20guide.pdf
http://www.researchgate.net/profile/Mark_Sherman4/publication/266657628_An_i
ntroduction_to_mobile_payments_market_drivers_applications_and_inhibitors/link
s/547de5170cf27ed9786255f4.pdf?
inViewer=true&&origin=publication_detail&inViewer=true