Authentication elements are either categorized as knowledge, possession, or inherence. How are these categories defined — and what does each of them require?
We previously explored the role of authentication codes in Strong Customer Authentication. To recap, the authentication factors of knowledge, possession, and inherence are alternate terms for what individuals know, what they have, and what they are. From these three categories, businesses utilizing Strong Customer Authentication must select at least two independent authentication factors to add to their applications. The chosen factors will then be used by customers who make transactions using the app.
To provide a more detailed idea of how these elements can take shape in applications, we’ve created a table of authentication factor examples in a separate blog post.
Today, we’d like to dig deeper into how each of these categories is defined and regulated. To do so, we’ll analyze the texts corresponding to these topics in the Regulatory Technical Standards (RTS) of Strong Customer Authentication.
Requirements for SCA Elements
Let’s begin by breaking down the three entries (articles 6-8) related to the requirements of categorized elements as well as devices and software linked to them.
1. Requirements for Elements Categorized as Knowledge (What You Know)
- First, payment service providers need to adopt measures designed to mitigate the risk of SCA elements categorized as knowledge being uncovered by or disclosed to any unauthorized parties.
- These mitigation measures will apply to individuals’ use of the elements (in other words, when they’re carrying out a transaction) in order to prevent the elements’ disclosure to unauthorized parties
2. Requirements for Elements Categorized as Possession (What You Have)
- Similar to the first point, payment service providers must adopt measures to mitigate the risk that the SCA elements categorized as possession are used by unauthorized parties.
- Anyone using these elements will be subject to the mitigation measures designed to prevent the replication of the elements.
3. Requirements for Devices and Software Linked to Elements Categorized as Inherence (What You Are)
- Regarding mitigation measures, the same rule applies here: Payment service providers are required to adopt measures to mitigate the risk that SCA elements categorized as inherence, which are read by access devices and software provided to payers, would be uncovered by unauthorized parties. At the very least, payment service providers need to ensure that said access devices and software have a “very low probability” of an unauthorized party being authenticated as the payer.
- Payers using elements categorized as inherence are subject to measures ensuring that devices and the software guarantee resistance against unauthorized use of the elements through access to the devices and the software. In other words, regardless of how smart the algorithm is for identifying users through biometrics, if the hardware or software has vulnerabilities, the respective biometrics system can’t be trusted.
Implementing Mitigation Measures
What can these nitigation measures look like in practice? Since each of the three articles above revolves around the need for payment service providers to adopt certain mitigation measures, it’s important to understand what this means in reality.
Examples of mitigation measures in mobile authentication could include:
- User-specific keys that are generated directly on the user’s mobile device.
- Key storage that leverages a secure mobile operating system mechanism (such as iOS Keychain or Android Keystore) and utilizes protection based on a hardware chip (if the system allows it).
- For elements categorized as possession: The use of a device fingerprint to encrypt the possession-related key, which prevents simple transfers between devices.
- For elements categorized as knowledge, the use of a cryptographic mechanism to ensure that PIN codes aren’t stored anywhere (not even in hashed form). A user’s PIN code should be used locally on the device to unlock the cryptographic key, which is later used for computing a signature. This greatly minimizes the chance of PIN leakage.
- For biometrics, the use of scanners provided by mobile platforms, such as Face ID or Touch ID on iOS and Universal Biometric Authentication on Android. These scanners are directly integrated with the secure storage systems mentioned above.
Independence of Elements
The following entry in the RTS is Article 9, which focuses on the need for elements to remain independent of one another. In more technical terms, the independence of elements means that “in terms of technology, algorithms and parameters, the breach of one of the elements does not compromise the reliability of the other elements.”
The entry goes on to state the following points:
- Payment service providers shall adopt security measures, where any of the elements of strong customer authentication or the authentication code itself is used through a multi-purpose device, to mitigate the risk which would result from that multi-purpose device being compromised.
- More specifically, the mitigating measures shall include each of the following: The use of separated secure execution environments through the software installed inside the multi-purpose device, mechanisms ensuring that the software or device has not been altered by the payer or by a third party, and further mechanisms to mitigate the consequences of any alterations that have taken place.
What Are Secure Execution Environments?
Relating to the second bullet point above, you may be left wondering what a “secure execution environment” actually is. While the RTS doesn’t offer a concrete definition of the term or lay out any specific specifications for its implementation and use, we can lean on industry knowledge to draw up a pretty holistic picture of what payment service providers must pay attention to when setting up these environments.To better illustrate what a secure execution environment contains, we asked our CEO, Petr Dvorak, to provide a real-world description.
Like any software, mobile operating systems may contain vulnerabilities and can be compromised. As a result, applications cannot solely rely on an operating system. Instead, they must implement certain defensive measures to detect compromised devices (for example, those that have been rooted or jailbroken), tools for hacking and developer tools, attempts to tamper with the application’s executable file or memory content, and any signs of mobile malware. This type of protection is typically carried out by automatically re-wrapping existing apps using specialized tools that randomly insert tens of thousands of security points to the application to protect it from various threats. The measures will also assure the termination of the application in case any of the security measures become compromised.
— Petr Dvorak, CEO at Wultra —
Using the above explanations, payment service providers should not only be able to keep the requirements of SCA elements in mind, but they should also have a clearer understanding of how their business can properly achieve the requirements and maintain SCA compliance.
Next up, our SCA series will continue with a post diving into exemptions from SCA. If you’d like to keep up with the latest from Wultra, you can subscribe to our newsletter.
.webp)
