Develop A Secure Banking Mobile Application With These Eight Security Methods
A company’s business is only as secure as its ability to guard its resources
Is it possible to design an application so secure it can’t be cracked or hacked? As a mobile application developer myself, here’s my short answer: No fortress will ever be 100% impenetrable. And us developers know that all too well. The best we can do is establish the highest levels of protection possible in our app’s backend and infrastructure. Heads-up: it’s an ongoing (read: never-ending) process.
That said, it’s not all doom and gloom. There are ways to make your app a lot more secure. Here are eight essential security tools and methods to apply and implement in your mobile application. I’ll also be citing a couple of Taiwan’s mobile regulations, as that’s where I’m based.
At DBS, all our banking apps include the following eight methods, allowing our customers’ journeys to be secure and protected throughout. Do note that while credit cards aren’t device binding, they still require two-factor authentication, especially when you make purchases online.
1) Application Programming Interface (API) Encryption
In the earlier days of Secure Sockets Layer (SSL), there were a variety of security flaws and vulnerabilities, some of which still exist today. While Transportation Layer Security (TLS), such as TLS 1.2 and TLS 1.3, were introduced to address these SSL vulnerabilities, and are the most used around the world, here are some other useful API encryption methods. In DBS, we use TLS1.2 and higher protocols to protect our API calls.
1a) SSL/TLS
In general, when people talk about SSL, they’re referring to the extended protocol TLS, (versions 1.2 or higher). SSL protocols have a large number of weaknesses and should not be used in any circumstances. General purpose web apps should only support TLS 1.2 and TLS 1.3, with all other protocols disabled.
Those who use Hypertext Transfer Protocol Secure (https) can claim that their API is encrypted. While there’s nothing wrong with that, SSL works on the connection level and you can have more secure methods by implementing any of following three encryption methods.
1b) JSON Web Encryption (JWE)
JWE is frequently used. While other sites provide adequate information, Wikipedia is still your best bet for updates.
1c) JSON Web Token (JWT) with customised key encryption
JWT with a customised key is a common method used with earlier SSL versions. It is similar to JWE, except that the key is constructed from byte addresses of the JWT header and symmetric-key algorithms are used for encryption and decryption of the data.
1d) End-to-end Encryption (E2EE)
You also can use E2EE for all API calls. In addition to cryptography, a hash algorithm of the checksum to confirm the integrity of the API header and body can also be used. A lengthier explanation is given below in point four. While some banks use E2EE for all their API calls, DBS does not, as it is too heavy and unnecessary.
2) Certificate Pinning
TLS certificate pinning accepts a trustworthy certificate from a known server and rejects connections from unknown servers. This system functionality is provided by both iOS and Android. The app only trusts its own certificate and ignores any trust store license in the device. If the app does not have correct certificate pinning, it can still succumb to a man in the middle (MITM) or spoofing attack.
Taiwan’s mobile regulation, Clause 10, Security of the Design of Transactional Applications, suggests the following:
Internet based applications should follow the procedures shown below:
1) No device passwords should ever be transferred over the internet and sensitive data should be encrypted during the entire transfer process.
2) Session control and timeout should be implemented. A delay of more than 10 minutes in response should result in disconnection or other protective intervention.
3) Identity Access Management (IAM)
In the above instances, an IAM system is still needed to protect client login and access. An IAM framework based on oath 2.0 is commonly used. The client is provided with a bearer token for access and the token can be refreshed to extend access time. Under IAM protection, a user can only access their own data, which can only be modified after permission has been given by IAM. This lasts only as long as the lifetime of the user login. Once access control has been established in IAM, none of the data can be disturbed by other users, unless the owners’ credentials have been stolen.
4) E2EE (see Wikipedia)
Mobile regulation in Taiwan suggests the following:
An end-to-end encryption mechanism should be provided for the transfer of all sensitive data. Data entered on the client side should be encrypted immediately and decrypted by hardware in the financial institution which complies with the Federal Information Processing Standards (FIPS) 140–2 Level 3 (or above) to avoid any MITM interception. Transfer of fixed passwords should be authenticated in a hardware safety module.
E2EE is a system of communication where only the communicating users can read the messages. This means that all data transmitted between the sender and recipient is fully encrypted and can only be decrypted and read by the recipient.
E2EE is commonly used for the transmission of credentials using a hardware security module (HSM). HSM provides a highly secure cryptographic function and uses very efficient crypto processor chips. According to the Principles of Digital Banking Operations and Security in Taiwan, a HSM system is mandatory for the transmission of all credentials.
The implementation of E2EE on a mobile involves the following steps.
1. Calling an API to fetch the public key;
2. Using that key to encrypt the credentials;
3. Sending the encrypted data to the server;
4. The server then decrypts the data using HSM, retrieving the credentials which were fully protected by E2EE during transmission.
This means the encryption algorithm must be implemented on the client side. It is not necessary to protect these cryptography algorithms, as they are usually of a common asymmetric type with normal asymmetric cryptographic key length.
Public keys must be exchanged during runtime as everything written within code is unsafe and vulnerable once a mobile application has been distributed. A fixed private key is the most dangerous because a hacker can easily discover a private key by monitoring app usage. Therefore, the implementation of E2EE on a mobile application should always be in the runtime and dynamic.
As for information privacy, mobile regulation in Taiwan suggests the following:
Processing of information:
Encryption may be symmetric or asymmetric.
1) Symmetric encryption should use a minimum 112-bit key Triple Data Encryption Standard (Triple DES) algorithm, a key of 128 bits (or more) for the Advanced Encryption Standard (AES) algorithm, or other algorithms of the same security level.
2) Asymmetric encryption should use a key of 2048 bits (or more) Rivest–Shamir–Adleman (RSA) algorithm, a key of 256 bits (or more) for Elliptic Curve Cryptography (ECC), or other algorithms of the same security level.
3) All the text must be encrypted; nothing should be left out.
5) Device Association
The concept of device association requires that the device be given a unique identity, which is written into the device. This is usually confirmed by a one-time password (OTP) sent by SMS, to establish that the device is associated with that one user only.
Once the device has been associated with a particular user, the unique identifier (UID) is presented. All the API calls are bound to that UID for the lifetime of the login. If a user changes to another device to log into his account, the device association must be repeated. This is done to guarantee that all the user operations after login, along with device association, are done with the associated device. In short, this means that the UID must be checked every single time the user calls an API after login.
A hacker would find it very difficult to get a device associated UID because the login is protected for its duration. However, any action before the device association has been made is not perfect because SMS OTP is used for association. There is still a chance that a victim may unintentionally provide their credentials and SMS OTP.
We apply the above method to all DBS apps. First time you log in, you’ll see that we require you to perform device association.
6) One-Factor, Two-Factor Authentication (2FA)
The four common authentications factors are OTP, biometric authentication, pattern password, and password. Low-risk transactions described in Principles of Digital Banking Operations and Security in Taiwan are:
Only low risk transactions are permitted, and at least two of the following security measures should be implemented:
1) Password or gesture password that the client has set with the bank.
2) Bank cards, tokens on devices, password notes, or an OTP that the bank can verify.
3) Biometrics or signatures that can be directly or indirectly verified by the bank.
Indirect verification denotes a verification process conducted on the client device or verified via a third party, where in this case, the bank only receives the result of the verification. The source of the process should be verified if necessary.
Only when two of the three security measures listed above have been taken, can low-risk transactions be carried out. Device association is one of them. At DBS, depending on each regional market’s regulatory requirements, 2FA through SMS OTP, digital or physical token are used for transactions and other scenarios.
7) Encrypted Local Data
There are three common ways to store data in the mobile apps — SharedPreference or UserDefault, local file, and local database. Not one of these are secure. In fact, they are all plain text, which can easily be inspected and read. Data that is stored in a mobile app should be encrypted; sensitive data should not be stored in local files.
How can data be encrypted in the light of all the sections mentioned above? Any key that is written in a mobile app will be insecure. And how can data be encrypted with an actual secure key?
The answer is simple: Android and iOS both provide a secure framework, keystore and keychain. These two can be used to generate keys and store data for later use. These frameworks are system based and combined with secure hardware elements. Today, it is uncommon for one to hear of data security breaches involving either of these frameworks.
Once the key has been generated, data can be encrypted using either symmetric or asymmetric encryption. The end user would not even be aware of the existence of such keys, as the process is handled automatically.
8) Transaction Flow
This brings us to the final security concept: transaction flows. Even though there aren’t security tests or laws that regulate or make such designs mandatory, it is a common and viable solution for mitigating transaction risks.
To ensure transactions cannot be breached or manipulated, the payload should first be transmitted with an API for like deposits, transfers, fund transactions and currency exchanges. This tells the server that a transaction is about to be executed. The transaction is stored and the exact payload is passed back to the client with a unique transaction ID. The client confirms the payload on the screen and performs factor authentication. The client calls a second API to tell the server that the transaction is valid and can be executed. The server then executes the transaction and returns the results.
The above journey produces the following results:
1. The payload of the transaction that’s stored in the server will never be altered.
2. Executional transaction servers can be protected from distributed denial-of-service (DDoS) attack.
3. Users are prevented from carrying out an incorrect transaction, either by accident or from the failure of an API.
Summary
A careful examination of the above sections reveals that banking applications include all the secure methods with solid implementation, to give the user the best security environment possible.
These security methods will never be completely impervious to attacks. Just imagine the door of a house secured with 100 locks. It’ll be difficult to open the door, but not impossible. Additionally, one can always decide to enter through windows, chimneys or by making a hole in the walls.
One key thing to note: while all security in mobile applications should be as comprehensive as possible, it should also comply with all the laws and regulations. And then comes yet another facet: ensuring that the user experience is kept friendly.
Hydra Shu Chang is an application engineer at DBS Taiwan.
