Passwordless Passkeys — Device-Bound [7]

Joeri — Juramento

·

Subscribe

9 min read

·

Apr 15, 2024

Listen

Share

Passkey development goes on. Historically, with YubiKey a brand of a Security Key, once upon a time there were only device-bound Passkeys on physical Security Keys (though they were not called ‘Passkeys’ back then). Nowadays (2024Q1), Passkeys are being generated by Operating Systems like Windows, MacOS, iOS but also Password Managers like 1Password, Keeper and so on.

What is also becoming clear is what the functional differences and implications are between the two types. Syncable Passkeys are less strict than a device-bound Passkey on a Security Key probably making their adoptability higher. Now the next type, is right in the middle of those two. Microsoft 365 for Business has been reluctant to support authentication with those perhaps-named “syncable wild west Passkeys” and they have launched a preview of a device-bound Passkey on a phone. (Kinda.) Here we go.

(You are welcome to open the previous article[6] in this series, though you can read this article independently.)

Device-bound Passkey on an iPhone

Before April 2024, the approximating-equivalent for a Passkey-device-bound-on-an-iPhone(🤓) security level would require:

1. Single-Sign-On in Microsoft Entra (for example)
2. Conditional Access enforcing MFA plus:
3. Authentication Strength set to FIDO2 (and perhaps Authenticator Phone-Sign-In).

This is a lot of tech and configuration. And this only covers the usage, the actual authentication, not the onboarding. Traditional SSO onboarding would require a process where the new employee is able to temporary circumvent the Catch22 situation where the user does not have a strong method of Authentication yet (MFA). Entra has Temporary Access Pass to offer that, which is a secret of 8 random chars that blows through most default MFA restrictions allowing an employee to setup MFA.

Attestation — Proving that x is really device model x.

Since the 11th of April 2024 (2024–04–11), Microsoft launched a preview of device-bound passkey inside their authenticator app on iOS or Android for organisations. They are the first as far as I know that offer the type device-bound Passkeys on an iPhone.

Microsoft launched device-bound Passkeys without support for attestation. So a key claiming to have been generated by a Microsoft Authenticator does not actually have to be generated on it, making it harder to make any further claims or assurances about it. This seems suboptimal. General info here. You can also read this position about alleged limited need.

Entra’s attestation enforced switch is tenant-wide, applicable during FIDO2-device registration, not authentication and cannot be selectively enforced per user-group via Authentication Methods (or Authentication Strength).

In other words, if you start allowing this today where before you have been exclusively allowing FIDO2 Security Key with attestation enforced, it seems that you you will have downgrade your security for the whole tenant in order to use Passkey on iPhone.
At the moment you also have to manually add AAGUID numbers of all the Security Key Models you want to allow. You cannot configure “Allow FIDO2 Certified Security Keys + device-bound Passkey-in-Authenticator on iOS”, you have to fetch the AAGUIDS you want to allow and add them one by one in Authentication Methods\FIDO2\Configure. — This will hopefully change, but somebody made a design decision that the (new) default is “Allow all Security Key types but no Passkey-in-App-on-iOS” and as soon if you want to allow Passkey-in-App-on-iOS, you also have to specifically define the regular Security-Keys-models as well. It is unclear why. The act of allowing Passkey-on-iOS should not enforce the entering all specific allowed AAGUIDs of OTHER FIDO2 Security Keys. If anyone knows why, please let me know via the comments.

Attestation — Exploring

Attestation for Passkeys-in-MS-Authenticator might be difficult to implement as it based on Public-Key-Infrastructure and it seems the app could be dissembled (source) and its private key might be accessed. On a hardware device one cannot access this data by design.

So, speculating along, either iOS starts supporting device-bound keys natively with attestation or Apple, Microsoft or actually the FIDO Alliance come up with a method in which the underlaying operating system’s Secure Enclave plays a role in the attestation of a freshly generated FIDO2 Credential in any Password Manager app of my choice. — There is some overlap between what we talked about above in the On-Behalf article and attestation. [Imagined] One could protect that attestation private key that is used to sign newly generated FIDO2 Credential (when they were being registered) to proof where they were generated on, by wrapping the original attestation private key by a general ‘platform-bridge-key’. So the Microsoft Authenticator app while running on iOS can then decrypt the wrapped attestation private key with help of the underlaying OS and perform operations needed for attestation. As long as the operating system is not compromised and the bridge-key stays in iOS’ Secure Enclave, the Microsoft Authenticator App download itself is no longer vulnerable for private key extraction. It would require some high-fives between tech companies, but that should be possible.

Limit of iOS Password Manager integration Detected

At the moment (2024–04–11) Apple only supports two Password managers to be integrated and offering Passwords or Passkeys in iOS 17.4.1. By having Microsoft’s unique device-bound Passkeys added to the Authenticator, the need for three slots seems now to have emerged. Two might not always be enough if the Passkeys are spread out. (A Microsoft Entra ‘work Passkey’ cannot be created in iOS or 1Password currently because it needs to be device-bound.)

• Either Apple needs to allow more than two managers for Passkey-discovery and/or:
• Apple could support native device-bound (non-syncing) Passkeys to saved on the phone; or alternatively:
• Password Managers like 1Password start supporting device-bound Passkeys, ideally with attestation.

Use case example why one could need three:

1. iCloud Keychain supports Shared Groups which could be used for non-techy family-members who cannot use or do not need cross-platform solutions (like 1Password offers).
2. 1Password (or other cross-platform manager) as main Password & Passkey or Credential Ledger.
3. Microsoft Authenticator for Phone-Sign-in (switch above not required) + the newly device-bound-in-app Passkeys (requires switch above).

Device-bound | Why?

It comes down to trust in a Passkey and to opportunity it has to leak over time and it implications in use. One of the properties of a traditional hardware-based Passkey, was the protection mechanism around the secret. You can only use it when you know the device-pin (or have the proper fingerprint scan). Even a malicious actor will have a very hard time attacking a stolen YubiKey. They are constructed in such a way that unauthorised access does not get very far. So it not like one’s house key that a finder theoretically could use. One does not require authentication to use a house-key, it only requires possession (and perhaps knowing it’s lock’s location).

A Security Key requires authentication towards the device itself and is used for authentication towards services or a computer (for example) and requires possession (something you have; the key) and something you know (the pin), so it is itself a Multi-Factor, but facilitates Passwordless authentication without actually needing anything else per se.

A syncable Passkey is also used for authentication, but it does not always require having possession of a separate device and suddenly the Passkey itself has different protection mechanism around it.

Based on previous articles, see here a condensed list of the characteristics, in general form:

Passkey Differentiating Characteristics:

1. Phishing resistance
2. Duplication-ability
3. Shareability
4. Exportability
5. Revocability
6. Type of Account Access Sharing
7. Time-limited Sharing Ability
8. Attestation state
9. Identifiability (logs)
10. On-behalf Registration-ability

This list will grow because implication in the human experience are complicated. If you want to see these points explained regarding syncable and device-bound Passkeys, you can find point 1–9 can be read in article[5] and point 10 was added in this article[6]. (Deep paragraph links.)

So with the introduction of non-physical syncable Passkeys one changed more than one variable / characteristics at the same time. The reason for existence of device-bound Passkeys on an iPhone is because it “moves the needle back a bit” towards the original Security Key’s design because in some situations you do not want to give up certain Security Key’s characteristics, for example:

1. In a company if a iPhone is authorised to login to company apps, we don’t want the Passkey to sync to the device at home to an iPad which might be shared.
   ⛓️‍💥 The weakest link to company secrets would be protected by any device-pin of all linked Apple devices. Syncing is not always desired.
   ⚠️ It can be even dangerous for the company. Suddenly Bring-Your-Own-Device becomes Bring-All-Your-Synced-Digital-Devices to work.
2. Not every user might even realize their devices sync. Users might be unaware of exposing Passkeys via other devices if they are unaware the tech-eco-system is syncing it for them.
3. As a consumer, do also want the Passkey for your banking app to sync in all your devices in your home? — You can always use Cross-Device-Authentication with a QR code if you want to do some banking on your PC, scanning the QR-code with your phone; you do not have to expose your Passkey to this device to accomplish that.
   ⚠️ The bank itself might even choose to enforce a device-bound Passkey to mitigate risk; or facilitate a gradual approach (🤩; I see great UX opportunity here).
4. If you can sync it to another computer, it implies that this Passkey could be shared with other humans one day. (Either by your choice or accidentally or via social engineering.) Do you always want your Passkeys synced?
5. If you have a client list, and you need to log in to their tenants with a native account as administrator, using a Security Key is safest, but in certain situation a non-Security-key device-bound Passkey might be suitable.

(I might update this list in the future.)

Device-bound | Wrapping-up

It is a step that the first device-bound Passkey on Phone is here.

I hope in the future for more clarity about (the need for) attestation. I am leaning towards needing a device-bound Passkey container with attestation, because you want to be aware of the what is protecting the Passkey; we will see how developments go. At the moment on iPhone, one would have to change iOS settings and switch back and forth between their primary third-party Passkey Manager and Microsoft’s; as discussed this friction needs to be resolved one way or the other.

Despite lack of attestation, if you are interested in a first impression comparison to the Passwordless sign-in with the Authenticator: Passkey Authentication is quicker because you do not have to type in that 2-digit number on your phone, just select Passkey holder, Continue, Touch ID / Face-ID.

I hope the differences between Passkey types have become clear as well as the benefits regarding the wished-for device-bound Passkeys on iOS, 1Password (and others) as that this type of Passkey can benefit consumers, employees, companies where the syncable Passkey is not suitable.

Thank you for reading.

Kind regards,

Joeri • Juramento

References