Software based mobile payments and security
#digitalbanking #fintechs #paymentsystems #fintech #financialservices #digitalpayments #payments
?It is without doubt that the payment industry already has undergone tremendous changes, and will continue to change, as new business models in the digital economy are created, which in turn will also lead to new payment models and an increased utilization of non-cash and card-not-present payments.
The numbers are staggering, and projections across all payment solutions are all going in the same direction: for mobile payment Fortune Business Insights has predicted that the global market will grow from 1.18 trillion USD in 2019 to 8.94 trillion USD in 2027 (Fortune Business Insights, Jul 2020, Report ID FBI100336). The Covid-19 pandemic has certainly boosted contactless payments, and subsequently may lead to even faster growth of a digitized economy, and digital payments.
The only limitation are security concerns and convenience, as apparently a majority of consumers still rely on cash for their daily payments, driven by factors of safety and security due to privacy and online payment security concerns. And considering how many parties, systems and processes are involved, the concerns – in particular with more analogue consumers – are understandable. There are service and technology providers such as banks, card providers, payment facilitators and shops. Then there are technologies and systems such as cloud services, mobile devices, data networks, the World Wide Web, biometrics, SMS, QR-codes, NFC, apps and other software, SDKs, PKI, digital wallet, hosted wallets, etc. etc. etc. – it’s a jungle out there, and how do you know who to trust?
Obviously, there are ways to make it work, otherwise, we would not have digital payment solutions. The core of secure electronic based payments are essentially authentication and identification, cryptographic processes, data transmission and data storage.
Why are these essential? Taking a look at the threats and attacks on electronic payments, it becomes clear: threat vectors are interception, modification or interruption of elements of the payment process. The experts will know what is meant here, but to shed a little light just a few comments on these. What attackers might try to do is for example to obtain PINs using brute-force attacks, spoof fingerprints, trick face verification with static pictures, or modify user credentials, just to list a few examples.
Mitigation strategies and technologies to protect the elements used in the payment process and the processes themself are for example user identification through passwords and additional factors, hardening of devices by implementing trusted execution environments, or implementing hardware anchors for secure storage such as TPMs. We see that these measures are typically implemented in the hardware, i.e. on the smartphone or other devices used, but often this is still not enough and still represents a security challenge.
For any mobile device (smartphone, tablet, wearable) probably the biggest security challenge, and therefore a weakness, is that it is an open platform where an attacker can assign himself to get full access to all programs running on the device. So, any software involved in a payment process could become exposed and be the most critical part of the authentication chain.
A lot of work has been done and a variety of solutions have been created to provide security at the hardware level of a phone’s hardware. So it becomes clear that one of the most important requirements is to protect the software part of a mobile banking system so that it could not be attacked to steal or modify information, change results or steal sensitive data.
And where smart engineers and programmers invent solutions to make things secure, there are also industry associations and bodies that draft and release standards and recommendations, so that it becomes public domain how to implement security. Because security is not only a question of having a solution to a problem but also how it is implemented.
Considering this, it becomes clear and makes sense, that all these elements – SDKs, TEEs, REEs, cryptographic tools, attestion mechanisms, cardholder verification on the consumer device, and so on – as well as their implementation should be tested and evaluated by an independent 3rd party: the 4-eyes principle always works well and has proven successful.
This is where my expert colleagues at TüViT can assist, with advice on which test and evaluation makes sense for a defined product or application scenario. We can help with orientation workshops to discuss specific SBMP requirements and the evaluation / cer-tification process, GAP analysis, evaluation of security mechanisms like obfuscation or white-box cryptography implemented by SDKs, security evaluation of mobile applications, testing of conformity with the relevant security guidelines of the payment industry, to name a few.
However, one thing remains clear and cannot be changed or affected by technology – the human factor: inappropriate usage behaviors, careless use and installation of apps and programs cannot be stopped if the layer 8 (we humans) operates carelessly or circumvents security mechanisms.
For more information check here: 1) https://www.emvco.com/, 2) https://medium.com/josue-martins/ussd-top-10-security-risk-for-mobile-payments-bcd64d0a34dc, 3) https://www.tuvit.de/en/services/hardware-software-evaluation/electronic-payments/sbmp/