Webauthn Attestation and OpenSource Keys
Webauthn (Passkeys) are only going to become more important in the future and as this grows, deployments with higher security risks and criticality are going to need to start to understand and embrace attestation of their keys.
In their current form, almost all software products and IDM's today allow you to enroll any cryptographic authenticator. It doesn't matter what make or model it is, it will be allowed.
However, not all authenticators are made equal. They each have different properties, security features, and some even have security issues affecting their hardware or software. Because webauthn is a self contained multiple factor authenticator, this means we need to be even more careful to ensure these devices are secure.
To manage this deployments can attest keys during enrollment. Attestation is a cryptographic proof of origin that proves the device is of a certain make and model. This allows us to select which devices we allow - and which we don't.
Threat Modelling
To make an informed determination about what keys we should allow in our IDM we have to assess our individual risks. Generally we want to consider the damage from a compromised authenticator.
When I'm inside my home network going to control my house lightbulbs, that's quite low risk. Private network, with little consequences of damage.
For my personal email, compromise would represent a huge amount of personal damage as email is so critical to individual account security.
If the release engineers in a linux distribution were compromised for example, that could lead to malware being distributed in the distribution aftecting thousands of people. Similar for developers of opensource where compromise of their credentials can lead to bugdoors being injected into code.
Authenticator Risks
Because of this, we need to consider the possible threat vectors against authenticators, and how an authenticator may become compromised.
A problem here is that in Webauthn attestation, firmware versions are not (currently) included. This means that if any model or version of an authenticator's software or hardware is compromised, that all versions of that device must be considered compromised. This raises the bar for vendors to be sure they "get it right" when they ship a device the first time.
Physical Attacks
This is the most obvious one. It can occur either in transit as the device is sent to you, or it can occur when the device is in your possesion.
Mitigations are tamper evident packaging (transit only), tamper evident features on the device, or device construction that requires destruction actions to open.
Local Software Attacks
Rather than attacking the device physically, the device may be attacked locally via it's interfaces such as USB, NFC or Bluetooth. This leaves no physical evidence, but can still allow compromise of a device if physical access is obtained.
Mitigations are tamper evident packaging (to prevent transit software attacks), and software hardening and use of memory safe languages.
Remote Software Attacks
This is the most nefarious class, where a device can be compromised by it being connected to your machine as it visits a webpage. This is due to weaknesses in it's software via it's CTAP interface.
Mitigations are software hardening, auditing for hidden vendor commands, and devices ensuring that any out of band management is never performed via the CTAP interface (it must be a seperate channel).
Cryptographic Failures
This is a failure of the devices programming or hardware during cryptographic operations allowing private keys to be removed from the secure enclave that exists inside the device.
Mitigations are in the hands of vendors requiring detailed audits and work to ensure their software is not vulnerable.
External Certification Bodies
FIDO who certifies authenticators publishes a metadata service that shows details about various authenticators and their assessments. These can be found on the mds service site.
The MDS defines multiple certification levels for devices. These are defined on fido's site.
Currently the best reference for an overview is the table of authenticator hardware examples.
We have a tool for querying this data as part of webauthn-rs
What Authenticator Do You Recommend?
These are the gold standard, and have all the best features here.
- Tamper evident packaging
- Hardware that can not be opened without destruction
- Hardened software to prevent local compromise
- No hidden vendor commands in CTAP preventing remote compromise
- Audits of their cryptographic processors to ensure they are high quality
- FIPS variant meets L2 FIDO criteria - the highest level currently granted by FIDO
- Non FIPS variants are the same HW, so should be able to achieve L2 as well in future
Runner up - this is the only other authenticator we have found with high quality tamper resitent features.
- No tamper evident packaging
- Hardware that can not be opened without destruction
- Hardened software to prevent local compromise
- No hidden vendor commands in CTAP preventing remote compromise
So What About OpenSource Authenticators?
There are two major brands that I am aware of. Nitrokey and Solokey.
Sadly both have issues, meaning I advise against their use.
Solokey
Solokey is the only opensource authenticator with a FIDO certification. They are built with an epoxy over their main circuits to highlight if these are altered. This is a great level of tamper resistence.
The solokey is based on an LPC55S69 which unfortunately means it has been affected by a trust chain bypass. As a result NXP have had to issue new board revisions to resolve this, but it's not clear when you own a solokey if you have an affected revision or not. Since webauthn can't distinguish firmware versions either, it's also impossible to tell if a device has been fully software updated.
In summary
- No tamper evident packaging
- Hardware that can not be opened without destruction
- Unable to tell if fully updated (vendor must change aaguids on fw version update)
- Local software trust chain bypass may be possible
Nitrokey 3 NFC
The Nitrokey 3 is built on the same hardware and software as the solokey. This means it is also vulnerable to the same issues. Unlike the solokey, the Nitrokey lacks tamper proof hardware - I can open mine quite easily with a spudger leaving no evidence of access. The NK3 I own is also a revision of the LPC55S69 which I can confirm is vulnerable to the trust chain bypass.
- No tamper evident packaging
- Hardware has no tamper resistance
- Unable to tell if fully updated (vendor must change aaguids on fw version update)
- Local software trust chain bypass may be possible
Nitrokey 3 Mini
The Nitrokey 3 Mini uses the same software an the NK3N, but uses a different chip (nrf32). We are unable to assess the hardware security as we don't own one, but nitrokeys trackrecord would indicate it likely has poor tamper resistance.
The NK3M shop page as of 2023 declares:
IMPORTANT NOTE: The included Secure Element is not used at this time. We are currently working on its integration and will enable its use later via firmware update.
This means that keys are very likely not stored with secure mechanisms. Unless a firmware update that enables this feature changes the aaguid, it will always have to be assumed that this model of key is a version not using the secure enclave, making it inelligble for any serious use.
- No tamper evident packaging
- Hardware likely has no tamper resistance
- Unable to tell if fully updated (vendor must change aaguids on fw version update)
- Does not use devices own secure element
Nitrokey 2
Also called the Nitrokey FIDO2. While this device is named "FIDO2", it has never been certified by FIDO. Like the NK 3, it has no tamper resistant packaging or hardware.
The NK2 has a weird feature though - you can update it from a website ( update site ).
The way this is performed is with a hidden set of vendor commands that are hidden inside the credential ID
of the CTAP2 get assertion process, defined by the value WALLET_TAG. You can see the checks for this
in the nitrokey firmware source
The problem here is that this means any website can sent a credential id with this WALLET_TAG and
the nitrokey will respect and start to process those commands. More shocking, is these commands do
not require interaction (touch) of the device or the pin to proceed, so visiting any webpage can
trigger these commands. These commands include retrieving the device firmware versions, triggering
the device to go into bootloader mode, and updating the firmware.
At this time I am not aware of or sure about vulnerabilities in the NK2 L432KC6 chip. However, the ability to perform remote unauthenticated firmware updates is not something I want in a secure authenticator.
Just like the other keys, since webauthn can't distinguish firmware versions either, it's also impossible to tell if a device has been fully software updated.
- No tamper evident packaging
- Hardware has no tamper resistance
- Unable to tell if fully updated (vendor must change aaguids on fw version update)
- Remote software trust chain bypass may be possible due to vendor commands
Summary
Today there are no opensource keys that meet basic security requirements for use in higher security environments. This means that attestation of webauthn keys in these environments is critical to ensure that these and other compromised keys documented in the FIDO MDS are not used in these situations.
If there are other models and makes of opensource security keys I haven't reviewed, let me know so that I can purchase them for auditing!