Enforcing security key ‘make and model’ with AAGUIDs in Entra ID

Imagine you are implementing Passwordless (MFA) for your organization and you have decided to use FIDO2 security keys. In this context, how do you make sure that the authenticators enrolled by end-users across branch offices and work-from-home settings are the intended keys that you saw fit to standardize on? Using AAGUID(s) is a sure way of doing just that, but it is not without a few caveats…

Background and Scope

In this article I am going to first make a further case for ‘why’ an organization should consider enforcing ‘make and model’ restrictions on FIDO security keys. I will then briefly discuss ‘how’ the AAGUID supports such measures, before exemplifying a practical implementation using Microsoft Azure. Finally, I will cover some minor challenges to be aware of in regards to whitelisting or blacklisting based on AAGUIDs alone.

Note: Towards the end of this article is a list that I have compiled of AAGUIDs for different vendors and products.

Really, why bother?

FIDO2 is a standard so does it really matter what exact authenticator the user ends up enrolling? Isn't the more important thing that the user is a happy camper? Well, ‘yes’ and ‘no’.

All Fido, even when certified to the same level, aren’t equal. Features and form-factors vary greatly and so does many other aspects that aren't at first apparent.

TCO

If we think about TCO (Total Cost of Ownership) for a moment, what will it do to the cost of operating and supporting the Passwordless initiative if Helpdesk will have to deal with users having problems with their rainbow colored “OTP-PIV-FIDO2-USB-A-NFC-BLE” device? And what if the user has also already enrolled 5–10 personal (non work) accounts on that authenticator (you can’t instruct him/her to factory reset, can you!?)?

Compare that with the effort of supporting [at an opposite extreme] a single vendor and single model USB-A + NFC authenticator with FIDO2. Not even close, right!?

Security

Then there’s the security aspect of a laissez-faire approach to strong(?) authentication. To start with: Do you trust Chinese vendor products? I am not saying you should or should not, but rather that the question ought to be asked.

Bloomberg (2018) about secret spy chips on American servers.

Yet another aspect of this not related to country of origin, is for example tamper protection measures and risk of interception and manipulation: everything from manufacturing (capital vs. labor, what labor?) and the use of epoxy on the PCB), packaging (e.g. the use of ‘blister packs’) and whatever might happen in the supply chain between the vendor’s in-house or outsourced production facilities and the customer.

The software itself poses another challenge. The security keys are hopefully certified to (Fido Alliance) level 1 or 2 and we can derive some trust from that, but what about any management software included and tooling? What if no tools are included (and no support possible)?

Case in point: I recently tested a level 2 authenticator only to find the companion software was missing required code signing…

And then there’s the big and important discussion on platform (Windows Hello) vs mobile (some app) vs security keys (YubiKey et al.) and the varying assurance level they offer. Not to mention: the use cases they can support! Food for a separate blog post I should think.

User Experience / User Satisfaction

Okay, let’s come back to the happy camper argument. One of the more important things I’ve learned in life is that freedom exists within set boundaries. Without boundaries there is not freedom, but chaos. If you don’t follow you need to read your Jordan B Peterson.

Applying this to your Passwordless project I firmly believe that users, not just Helpdesk, will be happier if requirements are ‘streamlined’ and the user experience ‘guided’ towards a given or a given set of authenticators rather than the ‘anything goes’ approach (Microsoft default, for example is: text-based MFA, Authenticator app, call to phone /…/ any Fido).

The exception to the rule here is if different employee roles and working realities (e.g. desk or factory floor) imposes that the authenticator scheme or form-factor be different. It is important to tailor to such requirements, possibly scoping by role or group membership. This isn’t laissez-faire authentication: it is identified subsets of population using a specific method.

This, the catering to user personas or user authentication journey as Gartner would phrase it, could very well mean that at the end of the day you implement FIDO2 + PKI + OTP, but in a standardized fashion and with a vendor you trust.

The basics of AAGUIDs

Now that we see eye to eye on the need to standardize, let’s discuss the basics of how this is facilitated, namely through the AAGUID.

The AAGUID or the “Authenticator Attestation Globally Unique Identifier” (which name do you prefer!?) is part of the FIDO2 specification and is used during enrollment (during attestation to be specific).

The value of this attribute [in most cases] identifies the authenticator make and model. For example, the YubiKey 5 NFC can be identified from AAGUID:

2fc0579f-8113-47ea-b116-bb5a8db9202a

Note: AAGUID identifies the model, not the individual authenticator. That is, it does not allow you to track the owner of an authenticator, but it allows you to (among other things) act on authenticators at a “group” level. Note also that the value is randomly generated.

The ‘attestation object’ contains the AAGUID during enrollment.

With this out of the way we are going to now look at a practical implementation of enforcing FIDO security key ‘make and model’ with AAGUIDs using Microsoft Azure. There’s just one more thing I want to bring your attention to and that is: when the AAGUID can be acted on:

Note how the attestation object reaches the RP/IdP only in step 5.

Observe above how within the registration (enrollment) process of a security key (e.g. “As a user Bob wants to register his rainbow colored security key with Azure”) the AAGUID which is part of the attestationObject is presented very late in the exchange, on step 5. Keep that in mind for later.

Enforcing security key ‘make and model’ in Azure

At this point we understand that the AAGUID identifies the ‘make and model’ of a FIDO authenticator. As such it allows the Relying Party (RP) or Identity Provider (IdP) a simple way to allow or disallow authenticators just by knowing the identifier (i.e. not necessarily having to look it up in the Fido Metadata Service). One IdP that has done exactly this is Microsoft Azure.

Configuring enforcement of security key ‘make and model’ in Azure

1. Open a browser and navigate to the Azure portal
2. In the search bar, type “authentication methods” and hit Enter
3. Within Authentication methods feature, select the Policies blade
4. Click on FIDO2 Security Key to bring up the settings view
5. In the FIDO2 Security Key settings make sure FIDO is enabled and then click on Configure
6. Select Yes for Enforce key restrictions and then in Restrict specific keys set the toggle to Allow (Note: this will disallow any FIDO authenticator not explicitly allowed)
7. Finally, click Add AAGUID and paste in your target value (see list towards the end of this article).

Select Policies an then click on FIDO2 Security Key.

Add the AAGUID for the authenticators you want to whitelist (Allow) or blacklist (Block).

Enrolling an allowed security key

1. Open a browser and navigate to My Sign-Ins (or My Account)
2. Authenticate with a current method(!)
3. Click on Security info (left hand side)
4. Click on Add method
5. In the ‘Add a method’ view, select Security key in the dropdown and click Add to continue
6. In the ‘Security key’ view, select if you will enroll over USB or NFC
7. Some amount of information displays. Click Next
8. Follow the instruction to tap (touch) the security key
9. When prompted, set or input your PIN (a second factor) and then click OK
10. Select Allow when prompted to read make and model
11. Give the security key a name (can be anything!) and click Next
12. Click Done.

The security key is now successfully enrolled ✔️

Select ‘Security key’ in the ‘Add a method’ box.

Select USB or NFC (wireless) as applicable to your authenticator and endpoint.

Some redundant info. Click ‘Next’.

Wait a bit, it will be fine eventually…

Touch the glowing area of the FIDO authenticator (insert and remove if a smartcard form-factor).

Set and confirm or provide PIN (if already set).

Touch the authenticator again. You’ve got 60 seconds!

The added popup (consent) is part of attestation happening: Azure wants your AAGUID!

Name the security key towards the end (final step) of enrollment.

If you get this far it means that enrollment of the security key was successful (yay!).

Logging in (image from Microsoft).

Enrolling a DISALLOWED security key

1. Open a browser and navigate to My Sign-Ins (or My Account)
2. Authenticate with a current method(!)
3. Click on Security info (left hand side)
4. Click on Add method
5. In the ‘Add a method’ view, select Security key in the dropdown and click Add to continue
6. In the ‘Security key’ view, select if you will enroll over USB or NFC
7. Some amount of information displays. Click Next
8. Follow the instruction to tap (touch) the security key
9. When prompted, set or input your PIN (a second factor) and then click OK
10. Select Allow when prompted to read make and model
11. Give the security key a name (I usually go with make and model) and click Next …

Enrollment has failed ❌

Note: I am only showing the image where the process differs. Refer to images in the previous section for the full sequence.

And you came this far!

Conclusion

Clearly Microsoft gets the job done enabling an organization to effectively whitelist or blacklist different FIDO2 security keys, but is it a job well done?

There are a couple of things that stands out:

• As an administrator, working with AAGUIDs is a bit tedious
• The user is not informed beforehand if the authenticator is allowed or not
• The user enrolling a disallowed security key is subjected to multiple views before the denial.

If we assume this is just Microsoft’s first iteration on this feature, how might Microsoft or a third party IdP improve on this going forward?

AAGUID’s are available in the Fido Metadata Service (MDS) along with vendor name, model name and a host of additional parameters (even vendor icon). An iteration on this feature could have the server fetch, parse and present the metadata as a selector in the admin portal:

A quick U/X mockup in Photoshop showing selector instead of AAGUID entry field.

With regards to the end-user experience (U/X) it would be great to reduce the overall number of views (screens) and to allow for a customer-configurable initial view. A customer could use such an enhancement to present a statement about supported security keys. This would effectively do away with any objections about the many screens to traverse before denial, or the issue I will cover next.

One last thing

For an end-user trying to enroll an unsupported authenticator there is an additional penalty to be paid: at the point of denial, the FIDO credential is already created (remember step 5?) on the security key -it just not accepted by the RP (Azure). This is a possible concern because it potentially impairs future use of that authenticator. How so you might ask!?

• It affects the U/X of any later authentication to Azure in that it offers up the disallowed credentials for logon (while in reality it’s orphaned).
• It occupies important storage on the security key.

An orphaned resident credential offered up for (im)possible login.

Maybe it’s a fair price to pay for trying to circumvent security controls? Luckily some premiere FIDO vendors provides tools for deleting offending credentials.

Assembled list of Fido AAGUIDs

The below artifact comprises a list of AAGUIDs from popular vendors. Do note that the list is not exhaustive. I will attempt to keep an updated list on my GitHub and update below table (gist) from time to time. If you want to contribute to the list, please comment on GitHub or on this blog post.

Other ways of obtaining the AAGUID

If against all odds the AAGUID for your authenticator is not listed in the above table (did you search!?) there are a couple of ways you can obtain it still.

If you cannot obtain the AAGUID using one of these methods it probably means your security key is not FIDO2 but of the older UAF variety!

As an Administrator or Advanced User

If you are an advanced user, well, there are soo many options for you sir!

• Query the Fido Alliance Metadata Service (MDS) yourself!
• Use the FIDO MDS Explorer (new MDS)by Olivier Potonniée
• Use the FIDO Metadata Browser (old MDS) also by Olivier Potonniée
• If you have physical access to the security key, use this tool by Yubico

The FIDO MDS Explorer reads authenticator details (including AAGUID) from the metadata blob.

As an end-user

As an end-user (or as an admin impersonating an end-user…) you can find the AAGUID of your FIDO authenticator using the Microsoft My Account or the Microsoft My Sign-Ins page(s). To do so:

1. Login to your account (using either link above)
2. Register your FIDO authenticator
3. Once registration is done, wait a few seconds and then refresh the page
4. Now click to expand/view the authenticator details

The AAGUID is listed.

An example of listing the AAGUID from the Microsoft My Sign-Ins page.