What SCA Requirements Mean for Passkeys (SCA & Passkeys III)

• Device-Bound vs. Synced Passkeys
• Analysis of PSD2 & SCA Requirements
• PSD3 / PSR Implications for Passkeys

After having analyzed, the differences between device-bound and synced passkeys in the first part of our series, and the specific requirements of SCA in the second part of our series, we now combine the two fields and work on the application and real-life conclusions for banks, fintechs and financial institutions.

In the following, we will focus on a scenario where SCA applies to the use case of accessing online banking accounts. The goal is to find out the real-life legal applicability of passkeys.

We start by taking a look at typical SCA architectures of banks today, learn why device-binding has been around for a while and how passkeys could serve as the next step in user authentication.

The European banking system for consumers can widely be divided between traditional banks with stationary branches and neo-banks that have evolved as app-first fintechs / banks that often do not have a desktop website or branches for banking.

The array of authentication options has evolved considerably, but many traditional banks still rely on easily phishable knowledge factors as the primary security measure (e.g. PIN or password), which can give potential attackers access to user accounts. This vulnerability may allow them to circumvent further security layers, e.g. by exploiting less secure methods like SMS TAN for fraudulent purposes. For second factors in traditional banking, especially when focusing on native apps, “device binding” has been the standard. When the device was reinstalled from a backup (in case of a device change), the association with the banking app was lost causing a sub-optimal UX.

As we have outlined above, banking apps that provide the second authentication factor via a native application, through methods such as scanning a QR code, Photo-TAN, or receiving or generating a one-time passcode (OTP), user accounts are bound to a this specific mobile device.

The fundamental process of utilizing a native application as a second authentication factor involves generating a public/private key pair. This pair is then linked to the user's account on the provider's side by submitting the public key to the provider. This submission often occurs during the completion of the initial identification process or service registration, usually as part of the recovery mechanism mentioned earlier. The native application retains the private key to sign future challenges, one-time passcodes (OTPs), or push notifications. This process effectively demonstrates that the second factor of authentication, namely "possession," is securely maintained.

Let’s first go back to remember the statements by the regulators to gather the corresponding requirements that apply in this scenario:

• Implement adequate security features and prevent unauthorized use (#EBA2019.24)
• Prevent unauthorized use (RTS Article 7)

The only way to ensure the credentials’ safety was to use the hardware security modules provided by the operating systems (e.g. secure enclaves, TPMs, TEEs). They ensured that the keys would never leave the mobile phone because keys stored in these operating system hardware security modules are not exportable,durable (some of the settings configurable depending on the operating system) and are therefore not included in device backups.

The private key storage in the hardware security module was necessary because there was no guarantee that the device was sufficiently protected to prevent an attacker from extracting the private key from the application storage of a native app – even from its “private space”(!= hardware security module).

Since mobile devices are often backed up to desktop computers and cloud services, this presents a considerable security risk. There’s no assurance that these backups and cloud copies are secured in accordance with the stringent customer authentication standards mandated by PSD2 regulations. Specifically, there may be no multi-factor authentication (MFA) guarantee, no encryption, and no measures in place to prevent unauthorized access.

This is also outlined in #EBA2019.26: a device binding would be necessary to actually be able to identify that this specific key pair belongs to a specific user. The device-binding therefore does not constitute a requirement in itself. It evolved as consequence of storing the private key into the hardware security module in the mobile phone as the only way to fulfill secure storage requirement. Therefore, the resulting experience was that a device loss or device change would lead to losing the device binding.

The table above clearly shows that storing the private key in a hardware security module system is without alternative, leaving developers with no opportunity to enable secure key mobility between consumer devices.

To find out if device-bound and synced passkeys are compliant to SCA, lets go through all necessary steps and requirements we have laid out above in our definitions. Let’s first start with generic things that apply to both passkey types (device-bound & synced).

• ✅ Two authentication factors (PSD2 Directive): Passkeys authentication with user verification enabled has two factors: The passkey is comprised of a public/private key pair and the private key is stored inside the hardware security module of the device (first factor: possession-based). Additionally, biometric authentication is required (second factor: inherence-based). In case of biometrics failure or unavailabilty, a PIN / password (alternative second factor: knowledge-based) is required.
• ✅ Two distinct authentication categories (EBA): Passkeys combine possession with inherence or knowledge and therefore fulfil this requirement.
• ✅ Two independent authentication factors (EBA): Both factors are independent of each other and a breach of one of the factors does not risk the breach of the other.
• ✅ Allowed form of biometrics are used in inherence factors (EBA): Passkeys usually use fingerprint or face scanning on mobile devices which both are allowed forms of biometrics in inherence factors. Moreover, technological advancement is adding new identifications with increasing security (e.g. Apple’s Optic ID which authenticates the user’s iris).
• ✅ Low probability of biometrics going wrong (EBA): Biometric information on mobile devices never leave the device, they are protected in dedicated chips. Also the sensors have a probabilities in the area of 1:1.000.000 to wrongly identify the actual owner of the device. They quickly fall back to requesting the PIN in case biometrics go wrong. The PIN on the other side is protected by exponentially increasing waiting times on wrongly entered codes.

Passkeys fulfil, all general requirements to constitute an authentication process that is SCA-compliant. For possession factors via apps & private-public cryptography, the EBA has provided some additional requirements that have to be checked (#EBA2019.24-26), which we will do in the following paragraphs.

The last requirement that needs to be checked is that the passkey is safely associated with the user, there is proof of possession, and that the private key is securely stored with mitigation measures. Let’s go through them one by one:

• ✅ Association with the user (EBA): In our case the keypair is safely associated with the user. This is done by registering the public key with the service provider.
• ✅ Proof of actual use of the possession (EBA): In the case for passkeys, that’s quickly answered as fulfilled, as we create a cryptographically verifiable signature that can only be generated from somebody who is in possession of the private key (and PIN / biometrics).
• ❓ Secure key store (EBA): Two core questions emerge when analyzing the compliance of passkeys with the secure key store requirement:
  • Prevent unauthorize use: Is the private key stored securely with mitigation measures to prevent unauthorized use?
  • Prevent replication: Do we have measures in place to prevent the replication of the elements by an attacker?

Now we have reached the important distinction point between device-bound passkeys and synced passkeys.

Passkeys in general are always stored in the hardware security module as we have discussed in the beginning of the article. Their only difference is the key-portability with cloud syncing.

Let’s unpack the differences by adjusting our table from above to include a column for device-bound and a column for synced passkeys. The core question we want to answer with this analysis is:

What are the security differences between device-bound passkeys and synced passkeys?

The main difference is that the private keys will be part of backups and can be access from multiple devices. For device-bound passkey we can therefore conclude that the secure storage requirements are fulfilled. The consequences of the storage architecture is that they can only ever be used on one device.

To answer the question whether synced passkeys satisfy the secure key storage requirement, we have to take a look at the technology behind the synchronization feature.

Google and Apple have spent significant effort on designing a secure ecosystem for passkeys. We will analyze in-depth the implementation and efforts of Apple, but most of the design principles apply equally to Google.

Which steps are needed to use synced passkeys on Apple devices with iCloud (prevent unauthorize use)?

The following requirements need to be fulfilled to sync passkeys across Apple devices via the iCloud Keychain

1. New OS version: The device runs on iOS 16+, iPadOS 16+, macOS 13+ or tvOS 16+
2. Enabled passcode: The device’s passcode needs to be set (then, the device is protected and locally encrypted).
3. Enabled 2FA: Two-factor authentication needs to be enabled for the iCloud account by either adding a verifying mobile phone number or hardware security key (multiple numbers & security keys can be added).
4. Enabled Keychain: The Apple iCloud Keychain needs to be enabled.

After making sure these steps are fulfilled, iCloud accounts essentially conform to SCA automatically. The first factor of authentication is the iCloud account’s password, and the second factor is an SMS TAN / hardware security key.

With the activation of the iCloud Keychain, all devices that need to be part of the synced Keychain must be enrolled either with another device or with 2FA. Subsequently, all keys generated within this iCloud account are synced securely, ensuring that private keys never leave any device unencrypted. They can only be securely synced from one secure enclave to another.

How can access to the iCloud Keychain be restored prevent replication)?

In case the user needs to restored access to their iCloud Keychain, there can be two scenarios depending if other connected / trusted devices are available.

• Scenario 1: Other trusted devices available: Access on a new device can be restored by logging into the iCloud account and then additionally confirming the new device on a connected / trusted device.
• Scenario 2: No other trusted devices are available:
  • Use the escrow contact & recovery code: There are two methods to additional methods to protect the data. You can add an escrow contact that will confirm recovery together with you or you store a recovery code at a secure, physical location which you can use to restore your account.
  • Last resort: To prevent loss of access, the iCloud Keychain can be restored with the Apple iCloud Keychain escrow functionality (!= escrow contact from above), but there is a strong process in place that protects the last resort backup. The following steps are required to be done in this process:

    • Successful login with iCloud account password and second factor

    • Provision of last used device passcode on any of the user’s devices

      Note the following:

    • After 3-5 wrong attempts the escrow record is locked.

    • Apple customer support needs to be contacted for more attempts

    • After a total number of 10 wrong attempts the escrow record is deleted unrecoverable

    • During all attempts it is cryptographically guaranteed that Apple cannot read the device’s passcode or the stored private keys

      The escrow data are stored in government- / enterprise-level HSM lusters separated from other iCloud / phone backup records. This means that accessing the last resort escrow requires three factors (Password, second factor SMS OTP / security key and passcode).

What happens with my passkeys when the device is stolen (prevent unauthorized use)?

In case a device holding passkeys is stolen, we need to distinguish two scenarios:

• Scenario 1: Device’s passcode is not known to the theft: Devices that use passkeys are protected with the passcode that is a prerequisite to enabling passkeys (see above). Therefore, all apps and passkeys are protected by it. Unlocking via brute-force attempts is also not possible due to delay when trying wrong passcodes.
• Scenario 2: Device’s passcode is known to the theft: In case the device is stolen and the passcode has been observed before by the theft, passkeys and traditional banking apps that rely on biometrics are at risk equally, because device biometrics always fall back to the passcode. In an effort to further protect devices from theft after having eyewitnesses entering of the passcode, Apple has introduced “Stolen Device Protection” which protects the Keychain (and other critical functionality) by never falling back to passcode in unknown locations (away from home/work) thereby making use impossible.

We can see that there is considerable effort to protect information inside mobile phone in case of theft, but are the information safe with Apple?

Can Apple access my passkeys (prevent unauthorized use of third-parties)?

Let’s analyze if Apple has access to a user’s passkeys. Answer-first: Apple has no direct access to passkeys. Just like passwords, passkeys are encrypted and stored in the user’s iCloud Keychain, where they aren't visible to anyone (including Apple).

• How does this work technically?: Keychain items are transferred from device to device, travelling through Apple servers, but are encrypted in such a way that Apple and other devices can't read their contents. The actual entries within the Keychain are encrypted using AES-256-GCM. Several optimizations have been applied, so that metadata can be queried fast although all sensitive information is encrypted.
• How does an escrow work?: Apple keeps an encrypted version of your iCloud Keychain. The decryption is only possible with a passcode, which Apple does not know. The brute-force protection is embedded into the hardware security modules by Apple, they explicitly state: “These policies are coded in the hardware security module firmware. The administrative access cards that permit the firmware to be changed have been destroyed.”

Using Apple as example we see that there is considerable effort to protect keys, store them securely and have mitigations in place to prevent malicious use. That’s why we conclude the following:

• ✅ Do synced passkeys have a secure key store: Let’s get back to the two core questions that emerged (already above) when analyzing the compliance of passkeys with the secure key store requirement:
  • Is the private key stored securely with mitigation measures to prevent unauthorized use?
    • Yes.
  • Do we have measures in place to prevent the replication of the elements by an attacker?
    • Yes.

Over 99% of all passkeys currently created as synced passkeys are stored in the cloud services of Google and Apple. There are numerous security measures in place to enhance the security of these passkeys. The industry anticipates the integration of synced passkeys for Microsoft platforms as well; currently, passkeys on Microsoft are device-bound. These three operating systems are considered First-Party Passkey Providers, for which there should be no security concerns. Third-Party Passkey Providers, such as password managers like 1Password or Dashlane, integrate with platforms through APIs. The security of their storage depends on the implementation but should also be a focus for the provider since they store passwords for consumers and enterprises, often including banking accounts. There is an ongoing discussion within the industry pointing out that some password managers do not comply with the standard when verification is required. This could lead to a future where some providers might be excluded by security-focused companies. Overall synced passkey providers can be overwhelmingly considered as safe as nearly all passkeys reside within First-Party-Providers. When passkeys import/export between providers should become reality those points need to be revisited.

Synced passkeys with user verification activated are secure way of multi-factor authentication that can uphold the high standards that Strong Customer Authentication (SCA) sets, even when the passkeys are synced to the cloud. It is important to keep in mind that with advancing technology, older assumptions, and decisions of the EBA can be reinterpreted differently. Very conservative traditional banking institutions have adopted a strict mindset regarding “device binding”. They leave the technical advancement and user experience improvements out of sight.

In the opinion from 2019 under number #24 the EBA outlines:

Article 4(30) of PSD2 defines possession as ‘something only the user possesses’. Possession does not solely refer to physical possession but may refer to something that is not physical (such as an app)

In a more general sense now, a synced-passkey proves possession of the “Cloud account” that lies behind the passkey – which is something the user possesses but is not physical.

Apple and Google provide enough documentation about the protection of synced passkeys in their respective cloud accounts that they can be considered SCA-compliant. Therefore, the chain of trust is not broken for the vast majority of passkeys in the consumer market.

The same assumption was stated by the EBA about the security of SMS OTPs when they assumed that mobile phone network providers put in considerable efforts to protect the reliability of the mobile phone network. This leads to the conclusion that the concern is not about the actual device but about the possession of the actual SIM card, despite numerous proofs indicating that SMS is not entirely safe. For years, this stance has remained unchanged, likely due to practicality reasons. SMS OTP remains the most accepted and convenient second factor authentication option for consumers due to its portability. Given the choice, consumers overwhelmingly prefer SMS OTP over other methods (80%), even when it incurs costs.

Furthermore, in our discussion, we have not really touched on the fact that passkeys are a non-phishable authentication option. This is a dimension of authentication factor quality that has not yet received the attention that it should.

Finally, we want to show a final comparison of the most important dimensions when comparing the two types of passkeys.

Passkeys are the future of authentication on the Internet. Banks, fintechs and financial institutions banks should start adopting this technology by collecting passkeys from their customers. We understand that for traditional banks, the step to start implementing passkey-first authentication with synced passkeys might be a major effort, but there are other options to begin with:

• Passkeys as a First Factor Replacement for PINs/Passwords: Passkeys can serve as a first-factor authentication method, replacing PINs and passwords, which are easily solicited from customers or left unprotected in browsers.
• Passkey-First with SMS OTP: Using passkeys in conjunction with SMS OTPs can significantly streamline recovery processes and reduce friction in cases of device loss or change. Passkeys can be retrieved from backups, and SMS messages can be received immediately after a SIM change.

Replacing the first authentication factor with an unphishable one, such as passkeys, stops many cyber-attacks at their source. Starting the integration of passkeys into banking apps and websites is also beneficial to prepare for a future where passkeys are standard and ubiquitous (this scenario will sooner or later come). A subsequent adoption or upgrade to supplementalPubKeys is always feasible, enabling the enforcement of device-linking at a cryptographic level.

Here are the links to the other parts of our series:

• Part 1 “Device-Bound vs. Synced Passkeys (SCA & Passkeys I)"
• Part 2 "Analysis of PSD2 & SCA Requirements (SCA & Passkeys II)"
• Part 4 "PSD3 / PSR Implications for Passkeys (SCA & Passkeys IV)"