Understanding Strong Customer Authentication (SCA) and Device Binding Under PSD2

5 min read

The Payment Services Directive 2 (PSD2) has significantly transformed the European payment landscape, with Strong Customer Authentication (SCA) at its core. Businesses and financial institutions must comply with SCA requirements to enhance payment security and reduce fraud. This blog post dives into the technical and practical aspects of implementing SCA, focusing on the ‘possession’ element and the crucial concept of strong device binding. We’ll also explore how to leverage secure environments on mobile devices to meet compliance.

What is Strong Customer Authentication (SCA)?

At its heart, SCA is a requirement under PSD2 to verify the identity of the customer when making electronic payments. The goal is to protect users by making unauthorized access to their accounts more difficult.

To meet SCA requirements, authentication must be based on at least two out of three elements:

  1. Something the customer knows (knowledge) – such as a password or PIN.
  2. Something the customer has (possession) – such as a mobile device or token.
  3. Something the customer is (inherence) – typically a biometric feature like a fingerprint or facial recognition.

Today, we will focus on the second element—possession—and how it ties into the implementation of strong device binding.

The ‘Possession’ Element: More Than Just a Device

While possession might sound as simple as requiring the customer to use their mobile phone or token, the technical details are more complex. Possession in the context of SCA is about ensuring the secure binding of a device to the customer. This concept is explored extensively in PSD2’s Regulatory Technical Standards (RTS), which outline how possession can be verified using cryptographic keys stored in secure environments within devices.

For instance, the European Banking Authority (EBA) highlights that possession is effectively demonstrated when a digital signature is generated using a private key securely stored on the customer’s device. This ensures that only the rightful device owner can authenticate transactions.

In practice, this often requires the use of hardware-backed security, such as Apple’s Secure Enclave or Android’s Trusted Execution Environment (TEE).

Strong Device Binding: Ensuring Secure Possession

What is Device Binding?

Device binding refers to the process of securely linking a customer’s device to their account in a way that the device itself becomes a form of authentication. This is achieved by generating cryptographic keys on the device, which can then be used to sign transactions or verify the customer’s identity.

According to articles 26 and 27 of the RTS, device binding is crucial for proving possession. This is done by:

  • Generating a key pair within the secure element (e.g., Secure Enclave or TEE) of the device.
  • Storing the private key securely in this protected environment.
  • Using the private key to sign transactions, verifying that the correct device is being used.

This process ensures that only the intended device can be used to approve sensitive operations, such as payments, and that any attempt to spoof or emulate the device would be unsuccessful.

Using Apple Secure Enclave and Android Trusted Execution Environment

To comply with SCA, the most reliable method of implementing strong possession is by using secure environments built into modern mobile devices. Apple’s Secure Enclave and Android’s Trusted Execution Environment (TEE) are prime examples of these environments. They provide the following benefits:

  1. Hardware-backed security: Private keys are generated and stored in a way that makes them inaccessible to the main operating system, ensuring that they cannot be extracted, even in the event of a device compromise.
  2. Cryptographic operations: These secure environments can perform cryptographic operations, such as signing data, ensuring that the private key never leaves the secure area.
  3. Tamper resistance: These environments are designed to be tamper-proof, protecting the keys from any unauthorized access.

However, leveraging these secure environments often requires native code integration, as React Native frameworks, for example, do not provide direct access to Apple Secure Enclave or Android TEE. Native modules written in Objective C for Apple devices and Java for Android will be necessary to fully implement this security layer. This native approach ensures that cryptographic keys remain in the secure environment and cannot be accessed by any other part of the system.

Key Implementation Steps for SCA and Device Binding

  1. Generating Cryptographic Keys: A private-public key pair should be generated inside the secure element of the mobile device. The private key stays within the secure environment, while the public key is shared with the authentication server.
  2. Digital Signature Generation: When a user initiates a transaction, the device uses the private key to generate a digital signature. This signature can then be verified by the server to confirm that the transaction came from the correct device.
  3. Key Management: It’s essential to implement lifecycle management for these keys. When the device is no longer in use or compromised, the private key should be securely deleted. The ability to remove these keys ensures that lost or stolen devices do not remain a security risk.
  4. Integration of Native Modules: For a seamless and secure implementation, native modules must be used to interface with the device’s secure environment. Tools like React-Native-Keychain may provide limited functionality but do not fully meet the requirements of accessing hardware-backed security. Native development for both iOS (Objective-C) and Android (Java) will be required to unlock the full potential of secure device binding.

Possession and Fraud Prevention: The Role of Device IDs and Emulators

While binding a device to a user is essential for verifying possession, fraudsters often look for ways to bypass this security measure. One notable example is the use of mobile emulator farms. In large-scale fraud operations, cybercriminals use device emulation to bypass device binding mechanisms. By emulating hundreds of unique device IDs, they attempt to trick authentication systems into believing they are legitimate devices.

However, strong device binding using secure cryptographic keys stored in environments like the Secure Enclave or TEE makes it significantly harder for emulators to replicate the possession element effectively. This underscores the importance of using hardware-backed security rather than relying solely on software-based device identification.

Conclusion: Implementing SCA and Strong Device Binding

Implementing Strong Customer Authentication under PSD2 involves much more than simple two-factor authentication. The possession element must be securely verified, and device binding is essential for ensuring that only the rightful customer’s device can approve transactions.

By leveraging hardware-backed environments such as Apple Secure Enclave and Android Trusted Execution Environment, businesses can provide a higher level of assurance that a customer’s device truly represents the possession element.

The takeaway for businesses is clear: a robust implementation of secure device binding mechanisms is critical to meeting compliance requirements and enhancing the security of digital payments. By adhering to these best practices, companies can mitigate risks and protect both their customers and themselves from fraud.

Popular

Navigating the Latest PCI DSS Updates: Addressing Requirements 6.4.3 and 11.6.1 for Client-Side Security

5 min read –The release of PCI DSS v4.0 has introduced significant updates to address emerging threats in the payment ecosystem, particularly...

Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x

5 min read –The landscape of payment security continues to evolve, and organizations handling cardholder data must stay ahead of the curve...

Secure Customer Authentication: How Not to Do It

5 min read –In today’s digital-first world, secure customer authentication (SCA) is critical for protecting data and meeting regulatory requirements, such as PSD2. While SCA...

Related articles

Navigating the Latest PCI DSS Updates: Addressing Requirements 6.4.3 and 11.6.1 for Client-Side Security

5 min read –The release of PCI DSS v4.0 has introduced significant updates to address emerging threats in the payment ecosystem, particularly...

Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x

5 min read –The landscape of payment security continues to evolve, and organizations handling cardholder data must stay ahead of the curve...

Secure Customer Authentication: How Not to Do It

5 min read –In today’s digital-first world, secure customer authentication (SCA) is critical for protecting data and meeting regulatory requirements, such as PSD2. While SCA...

Your advisor is ready to help now.

Your details