Introduction
Mobile banking and wallet apps have revolutionized the way we manage our finances. From checking account balances to making transfers, these apps provide convenience, accessibility, and control right at our fingertips. For customers, they offer round-the-clock banking without the need to visit a physical branch.
At Comviva, we offer Mobiquity Pay and Banking suite platforms. Like any other financial system, it’s absolutely crucial to ensure top-notch security in all our products. A single vulnerability could expose millions of users to risks, such as identity theft and fraudulent transactions.
In this article we will explain how implementing end-to-end encryption is being adopted at Comviva as a significant step towards protecting sensitive banking data. It ensures that customer information remains confidential and tamper-proof, providing a strong defense against potential cyber-attacks.
The Need for End-to-End Encryption in Mobile Banking Apps
Our platform handles an extensive array of sensitive information, including account details, transaction data, and personal identifiers on regular basis. The confidentiality and integrity of this data are paramount. Protecting these data from an intruder is one of our primary objectives.
With the threat landscape continuously evolving, and sophisticated cyber attacks becoming increasingly common, we concluded that an end-to-end encryption could effectively protect the system from various security threats, including data breaches, identity theft, and man-in-the-middle attacks.
Our implementation of end to end encryption
We use Diffie-Hellman Ephemeral for key exchange and AES 256 for the actual encryption of data. This asymmetric key exchange and symmetric data encryption helps us lay a solid foundation of our data encryption framework.
The DHE key exchange allows the secure sharing of temporary encryption keys between the mobile app and the server, ensuring a unique key for each session. This ephemeral key forms the basis for the symmetric encryption key utilized in AES 256, a robust encryption algorithm. In effect, this dual-layered approach guarantees secure and confidential communication for every banking session, safeguarding the transmission of sensitive financial data from potential security threats.
If we put the whole thing in a diagram, it looks like this
The end to end solution
Let’s take it step by step.
Server-side Setup:
The server generates a long-term public-private key pair during setup. This is stored securely on the server and is used for signing the ephemeral public key in later stages.
Client Fetches Public Key:
When the mobile app starts, it fetches the server’s long-term public key over a protected secure channel.
Ephemeral Key Generation:
At the start of a new session, both the server and the mobile app generate their own ephemeral private-public key pairs.
Ephemeral Key Exchange:
The server signs its ephemeral public key using its long-term private key, then sends it to the client. The client verifies the signed ephemeral public key using the server’s long-term public key, then sends back its own ephemeral public key.
Shared Secret Calculation:
Both the server and the mobile app independently calculate a shared secret using their own ephemeral private keys and the other’s ephemeral public key, following the Diffie-Hellman method.
Symmetric Key Derivation:
This shared secret is used to derive the symmetric encryption key for the session.
Secure Communication:
Both the server and the client use the derived symmetric key to encrypt and decrypt their communication using AES 256.
Session Termination:
If a session termination event occurs (time expiration on the server side, or user logout on the client side), the ephemeral keys are deactivated. A new session with a new ephemeral key pair must be initiated for further communication.
One simple example of Diffie Hellman key exchange with Alice and Bob
The Diffie-Hellman key exchange is a method of generating a shared secret between two parties in such a way that the secret can’t be seen by observing the communication. That’s useful for encryption/decryption and other cryptographic processes.
Here’s a simplified explanation of the Diffie-Hellman Key Exchange:
- Both parties (Sender and receiver) agree on a prime number, p, and a base, g, in advance. This is considered as public information.
- Each party picks a private number. For instance, Alice picks a, and Bob picks b.
- They then compute their public keys. Alice’s public key is A = g^a mod p, and Bob’s public key is B = g^b mod p. They exchange these public keys.
- Upon receiving the other party’s public key, they independently calculate the shared secret for the session. Alice computes s = B^a mod p, and Bob computes s = A^b mod p. The result s will be the same number for both, hence a shared secret.
Diffie Hellman Key exchange and derived key generation
The security comes from the fact that while a and b are kept secret, A and B are public, and it is computationally infeasible (given sufficiently large prime number p) to determine a or b given A and B due to the discrete logarithm problem.
This shared secret can then be used as a symmetric key for encryption and decryption of the messages exchanged between both parties. Each session should generate its own set of private numbers a and b, resulting in a unique shared secret for each session. This provides forward secrecy as compromise of one session’s key doesn’t impact the security of other sessions.
Another interesting feature of this approach is, the shared secret is never transmitted through network and is always calculated independently in server and client. This adds to the security of the overall system.
Benefits of this approach
The implementation of end-to-end encryption using Diffie-Hellman Ephemeral key exchange and AES 256 carries significant advantages, particularly in the context of mobile banking.
Enhanced Data Security:
This encryption method ensures the highest level of data protection. By encrypting data at the source and decrypting it only at the intended destination, we prevent unauthorized interception or alteration of sensitive financial information during transmission.
Forward Secrecy:
With ephemeral keys generated for each session, the system provides forward secrecy. A potential compromise of a key from a single session doesn’t risk past or future session data, offering an additional layer of security.
Scalability:
Our approach does not require a one-to-one relationship between the server’s long-term keys and the mobile app. This allows a large number of secure connections to be maintained concurrently.
Protection Against Attacks:
The proposed method guards against man-in-the-middle attacks, with the server signing its ephemeral public key with its long-term private key, providing a robust level of verification and trust.
Flexibility and Maintenance:
If the server’s long-term key pair needs to be changed, the mobile app can fetch the new public key at the start of the next session without requiring a redeployment of the app, thereby reducing maintenance efforts and potential downtime.
The proposed encryption workflow significantly elevates the security infrastructure of mobile banking applications. By implementing end-to-end encryption, sensitive user data is securely protected from unauthorized access during transmission. The use of ephemeral keys enhances this security by adding forward secrecy, which ensures that each session’s security is independent and not affected by any potential compromise in other sessions. The ability to perform long-term key updates without app redeployment and the inherent scalability of the system allow for efficient management and robust protection against numerous security threats. Thus, the integration of these key elements results in a comprehensive, fortified, and reliable security approach for mobile banking applications, bolstering user trust and ensuring continued growth in the digital banking landscape.
Consideration Points
Performance Impact Mitigation:
Implementing end-to-end encryption undoubtedly brings an overhead in terms of computation. We can overcome this by optimizing cryptographic operations, using hardware acceleration where available, and ensuring the server infrastructure is capable of handling the load.
Efficient Key Management:
With the use of ephemeral keys, the complexity of key management increases. Key management needs to be efficient and error-free to maintain the system’s integrity.
Ensuring Quality Random Number Generation:
The system’s security heavily relies on the generation of large, truly random numbers for keys. To prevent predictability or flaws in this process, we need to employ high-quality random number generators and keep them updated.
These consideration points aim to strengthen the end-to-end encryption system, enhancing its security while ensuring its practical usability for a high number of concurrent sessions.
Conclusion
In conclusion, integrating end-to-end encryption into mobile banking apps is not just a trend but a necessity in our digitally driven world. With the financial information of millions at stake, the extra layer of security provided by end-to-end encryption can offer peace of mind to both the financial institutions and their customers. Using the Diffie-Hellman ephemeral key exchange, we can implement a robust system that significantly reduces the risk of data breaches, ensuring that even if data is intercepted, it remains undecipherable without the correct keys.
While there are computational challenges that are quite obvious in the adoption of such a system, the benefits clearly outweigh these. Not only does it enhance user confidence in the system’s security, but it also meets the rising regulatory expectations for customer data protection.
This article serves as an initial blueprint for those considering the implementation of end-to-end encryption in their apps. It’s not an exhaustive guide, but rather a stepping stone towards creating a more secure environment for different systems. As technology advances, so must our security measures, and end-to-end encryption is a significant step in that direction.
