NitroKey 3 (NK3) and Firmware Upgrade Security Considerations

Hello NitroKey Forum!

I’m greatly pleased with the functionality of my NitroKey 3 (NK3). Having been a several years long user of the beloved NitroKey 2 (NK2, since its initial release), I can say the features of the now NK3 are leaps-and-bounds in the direction of functionality, versatility, and capacity. It is now (as far as I am concerned) a single device solution for password/key management! Oh, and there’s one more thing very new about the NK3 as compared to the NK2, its upgradable. That’s right, your NK3 can now, much like a bottle of wine, get better with time! How wonderful. Right?

I often ponder such things with much consternation, wondering if its truly possible to have this MUCH cake and eat it too. Are there consequences to having a NitroKey that can be upgraded? For example, upon my first usage of the NK3, I realized that the maximum PIN entry for stored passwords is now eight (8) as opposed to the NK2 which was/is three (3). Now, don’t get me wrong - no more holier than thou have I fat fingered my NK2 PIN enough times to retrieve my ADMIN PIN to save my secret unmentionables - but three (3) attempts for the potential adversary just seems like a magic number for me. For a six-digit PIN, a ~3/10^6 chance of guessing my PIN sounds pretty tight to me. Fail on the third attempt, and now she only has a ~3/10^8 chance on the ADMIN PIN. Unlucky you ; ) I wrote the Support team to ask if there was a way to set the max PIN entry back to three (3), and their response was that this is not currently possible but might be an option in future firmware upgrades. Interesting thought. Where am I going with this? …the firmware, of course, has much to say about the ultimate security of your passwords, GPG keys, and FIDO credentials. And this is all malleable.

In the old days of the NK2, the firmware is/was not upgradable (at least not without doing electronic surgery on a ‘tamper resistant’ form factor). If a NK2 was lost/stolen, best practice is consider your OTP’s compromised, but your passwords and GPG keys are still considered secure provided your PINs are not also compromised (that is, your OTP’s are vulnerable to anyone resetting the ADMIN pin, but everything else is cryptographically stored and is still ‘secure’ by at least statistical argument).

What about the NK3? If the beautiful freedom firmware (said with full affection and admiration) can be programmed to increase my PIN from 3 → 8, why not also to ‘infinite’? Intrigued and slightly concerned about such a thought, I asked the Support team at NitroKey. Well, as design choice would have it, only firmware signed by NitroKey can be pushed to the NK3. Sigh of relief, or is it?

So my question for the community (because at this point, Support is no longer entertaining my thought experiment in regards to this line of questioning, it seems), why has this not been discussed on this forum? The weakest link (precluding the user - which of course is always the true weakest link) is that only signed firmware can be pushed to the NK3. What then for users if NitroKey’s keys are stolen, confiscated by legal agencies, coerced/blackmailed from employees, etc? If I lose my NK3 or it is confiscated by anyone for any reason, there is merely a social means into the heart of that data. Period. This is at least philosophically inconsistent with cryptographic security. The best security model is a ‘zero trust’ model, wherein I (and only I) am the gatekeeper to my most precious and valuable authentication credentials. Damn the consequences. We don’t merely wear body armor, we wear bullet proof vests.

I’ve asked Support for the commission of a NK3 that can NOT be upgraded. I would gladly pay for new keys as the need arises - if only to satisfy my imagination (which is much more expensive than a NitroKey is priced).

So again, why has the firmware upgradability not been discussed as a design weakness in the NK3?

Best,

2 Likes

Hey @Kcortman , your concerns about this is genuine but i don’t think it has never been discussed. I have seen question regarding this in matrix groups and other forums and have myself asked this question before.
From my own knowledge of the security world , upgradability of firmware would be a trade off between its security and the features/utility it offers.
A hardware security key would be an important part in ones security practise and you would want it to be the most secure but still you would ahve to consider your threat model while applying such practice.
Example for a government , they might not want to have the slightest of possibility of a new attack vector and probably couldn’t trust on a single entity . So in that case such entity would want to use a non-upgradable security key by a trusted vendor.
But in an individual context or an even in a organizational context (having multisig) , the threat of supply chain attack or the vendor being compromised would have a lower possibility (i.e individual being targetted and robbed )

Also to note that the possibility of a vulnerability or a backdoor in non-upgradable key could still exist
so the concept of “zero-trust” security model does not hold true , as you still place some degree of trust on the vendor for supplying security key with a secure firmware and secure hardware in the first place. (unless you plan to use the DIY kit and use self-signed firmware , and still may have caveats).
So i think its a game of threat models and possibilities.

One advantage of upgradable firmware would be that vulnerabilities would be fixed without you needing to dispose the older and buy new one (contrary to the possibility of a non-upgradable key vendor keeps its users in dark about a vulnerability so as to not make its current stock a useless pile of junk).
Also I found out that even signed firmware of nk3 can be reproduced to make sure that the signed firmware is actually compiled from the same source code that the company represents it on the github.

However on reading about one of the points you made about you losing your key and a firmware update was done to increase the pin retries by coercing the employees , i got an idea about how firmware upgrades could be made more safe. My idea is to ask for a PIN while performing any upgrade (if it doesn’t currently , don’t exactly remember) , and incase you forget or can’t provide the PIN , the only way to upgrade it would be factory reset the key completely , thereby addressing your concern.

2 Likes

You’re right, enforcing the PIN during upgrade would solve this problem. If this is already the case, Support didn’t mention it.

Thank you greatly for comments and thoughts.

1 Like

Just to make sure you know that 6 digit pin is just a minimum requirement and the nk3 can infact have pin upto 127 characters including the use of alphanumeric and special characters. Refer Set PINs - Nitrokey Documentation

Well aware of it.

Honestly, I agree 100% with Kcortman.

Could we go from 8 to 3 failled attempt?
And prevent even a nitrokey team update from changing this setting to unlimited?

Imagine a legal request from a German court forcing Nitrokey to do so?

Couldn’t we each update the firmware by compiling it with our own signature (not that of the nitrokey team)?

When we fork an APK on Android, we sign it with apksigner, we should be able to do the same thing, change what we want in the firmware, compile it, sign it with our key and push it to our nitrokey key(s).

In this way, no attacker could change this parameter via an update.
We users would be responsible for the management and security of our signature and key updates.

This requirement comes from the FIDO standard and I think that Nitrokey right now rather wants to reach a certification level.

A change to the number of retries would deploy a new app on the tolen. Thus, the key would be protected as it gets wiped during firmware upgrade.

For running your own compiled firmware, there is a special variant available.

To my knowledge this applied just to the first batch. After Nitrokey changed the NK2 bootloader, the keys were not marketed as upgradable, but they later enabled firmware updates. In fact, if you look at the product page today, you will see the green tick for NK2 Pro firmware updates.

Be aware the Nitrokey-app has a note directly in the GUI that OTP are “not protected against physical attacks. If a device has been lost, change all OTP secrets”. The NK2 secrets may be cryptographically derived (obviously), but they are stored in plain.

Blockquote Be aware the Nitrokey-app has a note directly in the GUI that OTP are “not protected against physical attacks. If a device has been lost, change all OTP secrets”. The NK2 secrets may be cryptographically derived (obviously), but they are stored in plain.

So if we encrypt with luks + FIDO2, and our nitrokey is not protected against a physical attack.

What does that protect us from?

So a good diceware password would be more secure? Because if the laptop gets stolen, chances are the nitrokey will get stolen too.

You refer to the NK3, while the nitrokey-app is the application to manage NK2 OTP secrets. The device neither has fido functionality, nor can the OTP be used via cryptsetup for luks.

How secure are our physical keys against forensic attack?

  • FIDO2
  • GPG
  • TOTP-OTP

If an attacker recovers a nitrokey 3 key physically, how quickly can he break the security of the secure element?

Or can the secure element, given what we know today, not be broken?

Hi nku,

Are you referring to the AAGUID requirement? I still like @kevin 's idea of the PIN being required to push a firmware upgrade (or something real and similar to this effect).

Also, it seems as if you’re implying that firmware upgrades destroy the key data (or perhaps the ‘token’ associated with the PIN?). This is no longer the case since v 1.0.1 (Firmware Update - Nitrokey Documentation). It would be nice if Support offered some additional insight or clarity into the security implications of upgradable firmware. I don’t have a spare NK3 to play with at the moment, but I was planning on buying a couple more (as a backup and to also ‘play’).

From what you may suggest, and correct me if inaccurate as I’ve not read through FIDO specifications (maybe something I should do), is that the FIDO specifications requires OEM signed and upgradable firmware. The former, interestingly enough is to enforce make/model requirements (e.g. https://swjm.blog/enforcing-fido-security-key-make-and-model-with-aaguids-in-azure-3861b4409a45?gi=89a0675520c5). (Note: ‘You’ may have already witnessed this one while initializing your FIDO2 credentials wherein a site may specifically ask you to supply make/model information after PIN entry. The AAGUID is always read, btw.) But as to the latter? Must it also be upgradable? Are there restrictions as to how the upgrade can be performed or protected (e.g. designed to destroy all key data or in association with a PIN that can’t be exceeded). [EDIT] …of course not → https://support.yubico.com/hc/en-us/articles/360013708760-YubiKey-Firmware-Is-Not-Upgradeable, somebody at least understands the risks with firmware upgrades. Oh, boy.

–Begin Digression regarding an AAGUID or make/model enforcement –

A short rant that can be ignored....

Isn’t it ‘just like’ the experts and authorities to use MFA to potentially exclude you and your metal. I could say many things here, but they’d all just be emotionally charged. Suffice it to say, I personally don’t like it one bit. Naive me thought FIDO2 would be just as agnostic as TOTP is - the user simply and elegantly supplies the correct response to a shared secret, and viola. Already in ways of the past is the direction of such things moving. --End of Digression–

The typical attack on such keys is to readout the flash or trick the secure element into circumventing the brute force attack prevention (voltage glitches, laser beam etc.).

The NXP SE050 secure element is as good as it gets for consumer grade applications:

Built on NXP Integral Security Architecture 3.0 ™
•Uses advanced 40 nm silicon foundry technology
•CC EAL 6+ certified HW and OS as environment to run NXP IoT applications,
supporting fully encrypted communications and secured lifecycle management
•Effective protection against advanced attacks, including Power Analysis and Fault
Attacks of various kinds
•Multiple logical and physical protection layers, including metal shielding, end-to-end
encryption, memory encryption, tamper detection

In case the secure element is not used, there is still the readout protection of the LPC55S69 and the nRF52840. They are both used to protect intellectual property but are not meant as security processors.

Therefore, the length and entropy of the PIN is especially important as the sensitive data is encrypted by AES and in worst case it should still withstand brute force with defeated retry limits.

I guess that you could use the nitrokey 3a nfc hacker (already said on another post)?

Since it is design to flash your own firmware, I guess there is a way to only accept your signing key ?

On another note, once someone else hold your nitrokey to put on another machine, you should just consider it as unsafe, and revoke all access to what this key offer.

I guess that you could use the nitrokey 3a nfc hacker (already said on another post)?

There’s no indication that I’ve found or presumption that the NFC Hacker edition is signature restrictive.

On another note, once someone else hold your nitrokey to put on another machine, you should just consider it as unsafe, and revoke all access to what this key offer.

This conversation is not just about losing or having stolen your Nitrokey (which I would immediately agree has some consequences and prudent actions that one should take) it’s about the fact that your stored GPG keys, passwords, MFA’s, etc are completely accessible to an attacker provided a Nitrokey signed firmware allows it to be. Mind you, this is by design with no owner safe guards in place.

->Perhaps a recap is in order. The only thing stopping your NK3 stored GPG keys, passwords, etc. from being completely pwned is a signature key from Nitrokey.

As a corollary, Nitrokey should just legitimize this ‘feature’ by providing a signed firmware that behaves as a ‘rescue’ firmware. So, say for example I’ve exhausted all my USER PIN attempts and 2 of my 3 ADMIN PIN attempts. I say to my self, “uh ohh!” I need more PIN attempts because something is seriously wrong here. I go to Nitrokey’s Github page and download a “rescue” version of the firmware that I push to the key (using nitropy) which gives an “infinite number” of PIN attempts to figure it out and fix it. I don’t even need my PIN to upgrade the firmware, just a touch of a finger #3 (Firmware Update - Nitrokey Documentation).

Understand what I’m describing is 100% possible right now, provided the signature is obtained (e.g. stolen, leaked, confiscated, etc.).

If something I’ve described in here is inaccurate regarding the firmware upgrade process or the protections therein, I would be grateful if someone (preferably Nitrokey Support) provided clarification.

PS. Please, pardon my systematic misspelling of Nitrokey as ‘NitroKey’.

I did not dig in the code, but I would guess that all the secrets are encrypted with the help of your pin (which can be very long by the way, and not limited to numbers).

Maybe there is a mailing list for that, or matrix ?

1 Like

If you are cautious that changes to the lockout behavior can be introduced by Firmware changes, Just use the SE050 then. This Secure Element is like a Smartcard and enforces the PIN lockout. The behavior is validated during EAL 6+ certification.

@sosthene-nitrokey can you say a few words about when the secrets are cleared during firmware upgrade?

That was my thought too, plus I was wondering if enabling KDF before key generation/transfer on/to the SE050 makes a difference for that scenario.

No secret is ever deleted after a firmware upgrade. Otherwise that would mean losing all your data when updating the firmware.

Enabling KDF before or after the key generation leads to the same state. KDF does improve security against brute force attacks if you are afraid that the hardware security provided by the nitrokey’s internal storage encryption, bootloader or the SE050 is not enough.

1 Like