Device Binding to Protect Your Banking and UPI Apps

In an era where cyber threats are becoming increasingly sophisticated, securing sensitive data has never been more crucial. Device binding stands out as a vital strategy in the fight against unauthorized access. By ensuring that specific devices are uniquely tied to user identities, this method enhances security protocols, making it significantly more difficult for malicious actors to breach systems.

In this blog, we explore the concept of device binding, its importance in contemporary cybersecurity practices, and how it can bolster the integrity of your organization’s data protection measures. Whether you’re an IT professional or a business leader, understanding device binding can provide you with an edge in securing your digital assets. Let’s uncover how this powerful technique can transform your approach to cybersecurity.

 

What is Device Binding?

Device binding is the process of registering your device as a trusted device for banking. It registers your device and validates it with the registered mobile number. This allows access to the mobile banking application from a trusted device only and makes your app usage safe and secure.

 

Why is it necessary to implement device binding in banking and UPI applications?

Device binding is a security feature that improves transaction security and safeguards user data across a variety of applications, including financial and payment services companies like banks and payment service providers (PSPs). It involves connecting a particular device, like a computer, tablet, or smartphone, to an individual’s account or an action, like making a financial transaction. Applications use device binding for several reasons, particularly in the financial sector:

Enhanced Security: Device binding makes it possible for only approved devices to access accounts and carry out particular tasks. This lowers the possibility of fraud and illegal access.

Compliance: To secure sensitive financial data, a number of laws and industry standards, such as the Payment Card Industry and Data Security Standard (PCI DSS), mandate or advise using device binding or robust authentication methods.

User Convenience: Device binding can improve user convenience, even if it is primarily a security measure. On reliable devices, users can access their accounts or finish transactions faster and don’t require repeated authentication.

Data protection: By making sure that an attacker would still need access to the specific device linked to the account in the event that the credentials for the account were compromised, it can help protect sensitive user data.

Authentication on Untrusted Devices: To increase security even more, users may be required to utilize better authentication techniques when logging into their accounts from unfamiliar or untrusted devices.

 

To enable device binding, the following prerequisites must be met:

Operating System Validation:

The system needs to confirm the compatibility and validation of the user’s operating system. This step ensures that the user’s device meets the necessary technical and software requirements for the device binding process. The OS check verifies that the system can support and securely manage the binding operation, preventing any compatibility issues or security vulnerabilities.

Device Binding Restrictions:

Disallowed on Airplane Mode: Device binding cannot proceed if the device is in Airplane Mode. Airplane Mode typically disables all wireless communication, including cellular, Wi-Fi, and Bluetooth connections. Since device binding often requires network communication to verify credentials, establish secure connections, and synchronize data, the process cannot be completed while Airplane Mode is enabled.

Sim State Validation:

The system will check the status of the SIM card in the device. A valid and active SIM card might be necessary for device binding, particularly for actions involving cellular network authentication, identity verification, or service provisioning. If the SIM card is not in an appropriate state (e.g., missing, inactive, or locked), the device binding process will be disallowed.

Block Diagram: 

User Starts Device Binding: The process begins with the user starting the device binding. This step involves the user’s mobile device requesting the device binding process.

Sending User Information: The user’s device ID, mobile number, and operator information are sent to the Payment Service Provider (PSP).

Receiving Unique Codes: The PSP then sends unique VMN numbers and a string back to the user.

 

Random String Sent to a Virtual Mobile Number (VMN): The string that is received in the previous step is sent to a Virtual Mobile Number (VMN). This string serves as a kind of security code or token.

PSP Verification: The Payment Service Provider (PSP) verifies whether the string which is received from the user’s mobile numbers matches the string that was sent in Step 3

 

Attack Scenarios:

Case Study 1: How an attacker could register a UPI on behalf of the victim 

NPCI Check:

If the Payment Service Provider (PSP) detects identical shortcodes from multiple mobile numbers, the device binding should be rejected. Within the token expiry period, if the PSP receives two SMS messages with the same short code, the code should be considered invalid.

Attacker Scenario:

To execute this attack, the attacker needs access to the victim’s device. Through social engineering, the attacker can install malware on the victim’s device, gaining control over it.

Exploit:

The attacker exploits this scenario during the device binding process. When a binding request is initiated, a string is sent to a virtual mobile number (VMN). Using a message-forwarding app, the attacker can forward the string to both the VMN and the victim’s mobile number. When the victim’s phone sends the string to the VMN, the attacker can register the Unified Payments Interface (UPI) for other users.

 

Case Study 2: How an attacker can bypass the device binding limit.

NPCI Check: When customers initiate the device binding for the payment service provider (PSP), they can only try to connect a device to their account three times a day. This limit doesn’t apply if they’re using a unique combination of a mobile device and another device. The PSP needs to check for any risks when a device repeatedly tries to connect, and regularly review and possibly block or take action against devices that seem suspicious.

Attacker Scenario: Device binding limit can be bypassed by the response manipulation if server-side validation is not implemented.

 

Case Study 3: Make use of a deactivated SIM to bypass the device binding.

NPCI Check: The application should not allow device binding to deactivate the SIM.

Attacker Scenario: If the application doesn’t verify, an attacker could bind a device using a deactivated SIM, gaining access to the victim’s account. For example, if the victim loses their phone and deactivates the SIM, the attacker could use the deactivated SIM to perform device binding and gain access to the victim’s account.

Sim cloning is another type of attack where an attacker can take the same phone number as the victim’s and take over the user’s account and viewing the bank details.

The following checks are listed according to the NPCI/2023-24/RMD/004A document.

1. Follow these checks for Android:

 

Check SIM State	On Android, do not allow device binding when SIM/e-Sim is not present
Device binding disallowed on Airplane Mode	The application should not allow device binding if the phone is in airplane mode
WiFi Mode	On Android, device binding over WiFi shall only be permitted if the SIM/e-SIM/telco-based connectivity checks mentioned above in points 1 and 2 are adhered to.
Device Binding completion in the same session	Android: Customer should not be allowed toggle between apps or press any other button until the device binding process is completed. The token must be invalidated if the customer moves out of the active session. Auto notification pertaining to SMS charges received on customer devices during registration shall not be considered as toggling.
Device Binding is disallowed on multiple shortcodes (tokens)	PSP to decline device binding if it receives the same short code (token) from multiple mobile numbers during the device binding timer set.   For Ex: PSP receives short code 123 from Mobile A and Mobile B during the device binding timer set, it should then decline device binding.
Length of device binding string	SMS token length is to be a minimum of 35 characters with a mix of alphanumeric and special characters (‘space’ shall not be considered as a special character).
Multiple device binding Limits	UPI App to block device ID for 24 hours where more than 3 tokens are generated during registration
Allowing device binding only for the latest app version	The app should allow customer registration through the latest app version only. In case the user tries to register on the older app versions, the app should force an upgrade to the latest version.
SMS token expiry	The end-to-end device binding timer cannot exceed 45 seconds. The PSP bank may decide to reduce the time window at their end if, they notice any device binding-related controls being bypassed.
Dynamic SMS token	The PSP bank must ensure that the SMS token is dynamic and changes for every registration attempt.   Also invalidate the token if it’s generated for a particular VMN but sent to a different VMN (Example: token generated for VMN 1 should not be accepted if sent on any other VMN)
Private API solution for iOS	All UPI apps on the iOS platform should implement the Private API solution. This solution prevents editing of the encrypted token and VMN number on the SMS body, when a user sends an SMS to register on iOS
Customer onboarding on Android-based devices	Customer onboarding for Android-based devices shall be allowed from Android API version 23 and above only.
VMN Binding for SMS token	Every UPI App to ensure at least 10 VMNs on which token should be generated dynamically and sent randomly to one of the VMN (Unique). Note: – VMN’s should not be in series and should not repeat.
Application to check for successful ‘SMS sent check’ OR ‘Auto read OTP’ validation	The UPI application/PSP should validate a successful ‘sent’ check of SMS for both iOS and Android devices.   Implementation instruction: a)  The UPI application/ PSP- should read the sent items from the SMS message box (where UPI app is installed) and validate that the SMS was sent to the intended VMN along with the correct token. This will help ensure that device binding will not happen if the token is not sent to VMN from the device where the UPI app is installed.   b) If the mobile device does not facilitate SMS sent to check, then the application should trigger auto OTP read functionality after polling the database for a token creation request. Auto Read OTP (manual entry of OTP disallowed) should be done along with sender ID validation (reading SMSs only from whitelisted numbers of the app). This will act as an additional layer of security for handsets that do not facilitate SMS-sent checks.   c) For handsets that do not support both i.e successful SMS sent check or Auto-read OTP. new registration should not be allowed by the PSP/App

 

2. Follow these checks for iOS:

Control name	Control Description
Check SIM State	On iOS mobile data connectivity is to be validated
Device binding disallowed on airplane Mode	The application should not allow device binding if the phone is in airplane mode
Wi-Fi Mode	On iOS devices mobile data is mandatory (irrespective of WiFi) during the device binding process
Device Binding completion in the same session	iOS: Once the user is redirected to the messaging app and if the customer presses cancel or switches to another app, then the application should reject the device binding. For any user registration on iOS devices, the customer onboarding PSP shall decline device binding, if the time taken for the control to be passed from the SMS composer window to the application exceeds 5 Seconds.
Device Binding is disallowed on multiple shortcodes (tokens)	PSP to decline device binding if it receives the same short code (token) from multiple mobile numbers during device binding timer set.   For Ex: PSP receives short code 123 from Mobile A and Mobile B during the device binding timer set, it should then decline device binding.
Length of device binding string	SMS token length is to be a minimum of 35 characters with a mix of alphanumeric and special characters (‘space’ shall not be considered as a special character).
Multiple device binding Limits	UPI App to block device ID for 24 hours where more than 3 tokens are generated during registration.
Allowing device binding only for the latest app version	The app should allow customer registration through the latest app version only. In case the user tries to register on the older app versions, the app should force an upgrade to the latest version.
SMS token expiry	The end-to-end device binding timer cannot exceed 45 seconds. The PSP bank may decide to reduce the time window at their end if, they notice any device binding-related controls being bypassed.
Dynamic SMS token	The PSP bank must ensure that the SMS token is dynamic and changes for every registration attempt. Also invalidate the token if it’s generated for a particular VMN but sent to a different VMN (Example: token generated for VMN 1 should not be accepted if sent on any other VMN)
Private API solution for iOS	All UPI apps on the iOS platform should implement the Private API solution. This solution prevents editing of the encrypted token and VMN number on the SMS body when a user sends an SMS to register on iOS
Customer on-boarding on iOS/Android based devices	Customer onboarding for iOS shall be allowed on iPhone devices that support SMS sent. API that is available from iOS 17 onwards. (Currently, XS/XR series and above devices support OS 17 which enables SMS sent API)
VMN Binding for SMS token	Every UPI App to ensure at least 10 VMNs on which the token should be generated dynamically and sent randomly to one of the VMN (Unique) Note: VMN’s should not be in series and should not repeat
Application to check for successful ‘SMS sent check’ OR ‘Auto read OTP’ validation	The UPI application/PSP should validate a successful ‘sent’ check of SMS for both iOS and Android devices. Implementation instruction: a)  The UPI application/ PSP- should read the sent items from the SMS message box (where UPI app is installed) and validate that the SMS was sent to the intended VMN along with the correct token. This will help ensure that device binding will not happen if the token is not sent to VMN from the device where the UPI app is installed. b) If the mobile device does not facilitate SMS sent to check, then the application should trigger auto OTP read functionality after polling the database for a token creation request. Auto Read OTP (manual entry of OTP disallowed) should be done along with sender ID validation (reading SMSs only from whitelisted numbers of the app). This will act as an additional layer of security for handsets that do not facilitate SMS-sent checks. c) For handsets that do not support both i.e successful SMS sent check or Auto-read OTP. new registration should not be allowed by the PSP/App

NOTE: Please note that this checklist will be updated annually by NPCI.

 

Conclusion

Device binding is not just a technical safeguard; it represents a proactive approach to cybersecurity. By integrating device binding into your security strategy, you significantly enhance your ability to protect sensitive information and maintain the integrity of your systems.

As cyber threats continue to evolve, the importance of robust, multi-layered security measures cannot be overstated. Device binding offers a reliable solution that helps ensure that only authorized devices and users can access critical data. Embracing this technology can provide peace of mind and a stronger security posture for your organization.

 

Recommended Reading

Top 7 Most Trusted Cybersecurity Firms in India

How Poor Cryptographic Practices Endanger Banking Software Security

How to Intercept Traffic from Proxy Unaware Application Using DNSChef