Broad defects within the NK fido product ecosystem.

[Firstyear]

We have tested a large number of keys from various vendors and have found significant issues in NK2 and NK3.

This is a very broad issue, and unfortunately it will necessitate a large number of changes. All of them however are inter-connected - they largely impact manufacturing, physical key design and software release process. We believe that a new product will need to be launched to resolve these defects.

• Defective user presence button.

The user presence button on NK2 and NK3 is defective. We have 2 NK2 and 3 NK3's, and multiple persons who are all able-bodied are unable to reliably activate the UP action. We believe it is about 1 in 20 to activate it generally. We do not believe the button could be operated by any person with any mobility impairment.

• NFC antenna is defective

The NFC of all our NK3 units does not work with multiple iPhones, iPads, Androids or external readers. The only reader we were able to use was a proxmark3. This makes the NFC feature not usable in most cases, and has been reported on other forums.

• Lack of Tamper evidence

NKs ship with no tamper evident packaging, and the NK units themself can be opened and disassembled without leaving evidence. This seems like a large oversight given how NK attempts to position themself in the market.

• Debug pins exposed / Secure boot bypass.

The CPU used in the NK3 may be vulnerable to a secure boot bypass. https://oxide.computer/blog/another-vulnerability-in-the-lpc55s69-rom

Other persons have commented on the accessibility of the debug pins which may be a vulnerability that we haven't yet investigated fully.

• NK3 mini didn't use the SE

This is now resolved, but for a long time the NK3 didn't use it's own secure enclave.

• FW version signaling.

As a webauthn relying party when a device is attested it must also be possible to attest the version of the firmware as that signals if security issues may be present. There is an in-development spec for signaling this in the webauthn wg, but it seems to have not really taken off.

To reliably signal different firmware versions, the NK should roll the AAGUID with each firmware version.

Without this, RP's need to assume that any device with that AAGUID is the lowest FW and thus compromised. For example, we are unable to accept the NK3 mini because past versions didn't use the SE.

-- Actionable Steps

• Redesign of the UP button to be a simpler and more robust design that can be actuated by persons with mobility impairment.
• Redesign of the NFC antenna and tested in broader conditions.
• Redesign packaging and the key itself to be tamper evident or resistant including potentially epoxy over the circuit elements similar to solokey.
• Debug pins should not be accessible and the CPU should be validated to ensure secure boot and other attestation elements can't be bypassed
• Changes to the release process such that the AAGUID is rotated each FW version so that RP's can assert and attest the version in use. Alternately adopt the Add packed attestation optional firmware version attribute w3c/webauthn#1953 element.

[jans23]

Which NK3 model you experienced an unreliable user presence button with?

[Firstyear]

The fullsize nk3

[daringer]

Hey @Firstyear thanks for approaching us, let me break this down and leave some comments. I will focus on the following items:

1. Defective user presence button
2. NFC antenna is defective
3. Lack of Tamper evidence
4. Debug pins exposed / Secure boot bypass.
5. NK3 mini didn't use the SE
6. FW version signaling.

Defective user presence button

This is a behavior we can by no means understand or confirm. You might need a few attempts to find the right spot initially, but 1 out of 20 seems far too much. Would be great if you could explain how you tried that (it should be: entire fingertip gentle touch on the Nitrokey 3x labeled side of the Nitrokey, slightly further away from the USB connector than closer).

We have not received similar reports from other users about this.

NFC antenna is defective

We have reports that many customers' smartphone and Nitrokey 3 combinations work fine, while some don't work reliably. There is a big variance across devices and smartphones. This overall is mostly a non-software issue, more about that below.

Lack of Tamper evidence & Debug pins exposed / Secure boot bypass

• The debug pins are disabled; this is non-reversible and done in production
• The casing is indeed not tamper resistant, more about that below
• The lpc55s issue is known, although too late for the Nitrokey 3 development

Your report mainly highlights mechanical, hardware, and electrical issues. While these are known challenges, labeling them as 'broad defects' is excessive. As a small, independent company, Nitrokey can't easily change casing or electronics like software commits. We're currently working on a new NFC transceiver, which involves time-consuming electrical and mechanical design iterations. This process is extremely resource-intensive, especially as we prioritize open-source development and regional manufacturing for obvious reasons. These efforts aren't eligible for grants or similar funding, making them particularly challenging for us.

NK3 mini didn't use the SE

Not using the Secure Element is a design decision, which we openly document and even promote. We have many people explicitly asking for a non-proprietary, fully review-able software implementation. Although a secure element is audited for security (as most likely the LPC55s was too, right?) it is still proprietary, we had a product (Nitrokey Start) to address this need, today this is configurable (only for the OpenPGP Card currently!) with the Nitrokey 3.

Furthermore, the statement that the Mini didn't support the Secure Element and now does, is not correct. For FIDO2 there is no secure element used as of today, which is well document. The recently started "Nitrokey Passkey" also goes this way. Ultimately, we will for sure also have the option to switch into SE050-backend-mode for FIDO2 - but this is simply not there yet.

FW version signaling

The AAGUID is designed to identify the model, not the firmware version. Since CTAP 2.1, there is a firmware version field in the getInfo reply. Even on the Webauthn level, updating the attestation certificate, ideally including the firmware version also reported by getInfo, without changing the AAGUID should be sufficient for your use case. So far, this was not requested by customers and we did not do it proactively as there were no firmware changes with security impact regarding FIDO2. We will take this with us as a feature request.

[Firstyear]

Defective user presence button

This is a behavior we can by no means understand or confirm. You might need a few attempts to find the right spot initially, but 1 out of 20 seems far too much. Would be great if you could explain how you tried that (it should be: entire fingertip gentle touch on the Nitrokey 3x labeled side of the Nitrokey, slightly further away from the USB connector than closer).

Even with that technique, we can't get any of our keys to work. We have tried with multiple users, and we really just can not fathom how the UP button is meant to work.

In addition, it shouldn't need instructions, it needs to work 100% of the time for a diverse range of users. Yubikeys are a great example of this, and are the gold standard for ease of use - NK should aim for the same.

We certainly have heard those reports from NK users, so I'm surprised you haven't. I seriously would encourage you to redesign that button because it needs to be a lot more sensitive IMO.

We have not received similar reports from other users about this.

NFC antenna is defective

We have reports that many customers' smartphone and Nitrokey 3 combinations work fine, while some don't work reliably. There is a big variance across devices and smartphones. This overall is mostly a non-software issue, more about that below.

Correct, it's hardware. The NFC antenna is really marginal, and again, needs a redesign. We don't see these issues on competitors keys.

Lack of Tamper evidence & Debug pins exposed / Secure boot bypass

* The debug pins are disabled; this is non-reversible and done in production

* The casing is indeed not tamper resistant, more about that below

* The lpc55s issue is known, although too late for the Nitrokey 3 development

Your report mainly highlights mechanical, hardware, and electrical issues. While these are known challenges, labeling them as 'broad defects' is excessive. As a small, independent company, Nitrokey can't easily change casing or electronics like software commits. We're currently working on a new NFC transceiver, which involves time-consuming electrical and mechanical design iterations. This process is extremely resource-intensive, especially as we prioritize open-source development and regional manufacturing for obvious reasons. These efforts aren't eligible for grants or similar funding, making them particularly challenging for us.

And that's why I'm reporting them to you, so that they can be fixed.

Yes, I sympathise that it's expensive to retool and fix these problems, but they are problems. They shouldn't be ignored.

NK3 mini didn't use the SE

Not using the Secure Element is a design decision, which we openly document and even promote. We have many people explicitly asking for a non-proprietary, fully review-able software implementation. Although a secure element is audited for security (as most likely the LPC55s was too, right?) it is still proprietary, we had a product (Nitrokey Start) to address this need, today this is configurable (only for the OpenPGP Card currently!) with the Nitrokey 3.

I'd point to your own branding which lists statements like

"""
HIGH SECURITY:

Your secret keys are stored in the tamper-resistant and PIN-protected device and are secured against computer viruses, other malware, phishing, loss, theft and brute-force attacks.
"""

Furthermore, the statement that the Mini didn't support the Secure Element and now does, is not correct. For FIDO2 there is no secure element used as of today, which is well document. The recently started "Nitrokey Passkey" also goes this way. Ultimately, we will for sure also have the option to switch into SE050-backend-mode for FIDO2 - but this is simply not there yet.

Sorry, are you saying that NK2 and NK3 don't use a SE at all? This combined with the issues like the LPC55s, means we can't allow NK to be used in any security sensitive areas - areas which it seems like your brand is targetting.

This can't co-exist with hardware that isn't tamper-proof, or with a CPU which has vulnerabilities, or a firmware that doesn't even use it's own SE.

Not only this, you list huge customers on your frontpage: https://www.nitrokey.com/

Customers where these issues really do matter!

I think that this needs some better transparency ...

FW version signaling

The AAGUID is designed to identify the model, not the firmware version.

Correct, but webauthn also doesn't account for firmware versions which is why some other identifier that an RP can use is needed.

Since CTAP 2.1, there is a firmware version field in the getInfo reply. Even on the Webauthn level, updating the attestation certificate, ideally including the firmware version also reported by getInfo, without changing the AAGUID should be sufficient for your use case. So far, this was not requested by customers and we did not do it proactively as there were no firmware changes with security impact regarding FIDO2. We will take this with us as a feature request.

Getinfo is not sufficient as we need it as an RP. We need it to be present in the attestation output so an RP can make informed choices about which devices to accept. Currently if a FW update was to be issued that embedded FIDO keys in the SE we would need a way to distinguish these keys from previously versions so that we can only accept the keys that meet the security criteria.

I'm raising these issues because I want to see them resolved because there really are no other opensource keys on the market that are viable.