Test nk3 related hotp-verification patches upstream (unpaid by Nitrokey)

[tlaurion]

Focusing on PR content, see PR to follow white rabbit on security/UX/oem issues they solve:

• Add support for nitrokey 3 distinction between the secrets app firmware and the device firmware versions Nitrokey/nitrokey-hotp-verification#43

  • attempts to resolve issue Make Info Output more verbose for nk3 Nitrokey/nitrokey-hotp-verification#38

• Add pin-info command Nitrokey/nitrokey-hotp-verification#44

  • attempts to resolve issue Add cli option to request secret app admin/user pin counts Nitrokey/nitrokey-hotp-verification#39

• Add nk3-change-pin command Nitrokey/nitrokey-hotp-verification#45

  • unneeded since hotp_verification reset doesn't set a secure app PIN for now...

• Add reset command for nitrokey 3 Nitrokey/nitrokey-hotp-verification#46

  • attempts to solve Add option to do a secrets apps reset for the nk3 similar to: nitropy nk3 secret reset  Nitrokey/nitrokey-hotp-verification#42 by requiring hotp_verification reset to implement an optional PIN argument since not setting one by default, preventing PIN change...

• hotp_verification version bump plus upstream commits not part of 1.7 under hotp-verification 1.7+non-versioned bump commit (suppression of touch status) still wrong and still repeats itself Nitrokey/nitrokey-hotp-verification#52 to suppress bogus touch related output still not being clean

40h of work and counting. Will edit.

---

2024-12-16: Heads-->Nitrokey work highlighted above still refused to be paid in totality without fighting as of now.
Will have call with @jans23 Tuesday 2024-12-17 after mail exchanged but dismissed, to see if we can arrive to respectful collaboration or not for the future.

In all case, in absence of co-beneficial agreement (mutualism), I will not test Nitrokey code unless it's associated to a PR under Heads from now on since Heads related work should be paid. I'm responsible for Heads, and time must be recognized/valued/paid accordingly Heads partnership should be based on biological concept of mutualism and nothing else. This work, in this issue, should not be confounded with what should be expected to be paid by profit sharing agreement (maintenance and new board porting collaboration related only). If i'm expected to fix Nitrokey stuff, then Nitrokey must pay for the past, present and in the future.

If no mutualism is possible with Nitrokey, at bare minimum commensalism would be expected.
But in no case I will tolerate parasitism from Nitrokey.

Heads usage of Nitrokey based devices started by mutialism with Purism partnering with Heads in 2018 to ease remote attestation through reverse HOTP secret sealing on USB security dongles of their rebranded Nitrokey 1 pro devices, details at https://www.linuxjournal.com/content/tamper-evident-boot-heads. Mutualism could happen again if Nitrokey recognizes their responsibility in making tamper evidence a priority again, but there is not much more of my free time I can invest into this nk3 where absolutely no collaboration from Nitrokey toward Heads (Nitrokey->Heads participation in code/money) and Where Heads invested too much time (Heads->Nitrokey) for this to be considered anything else than parasitism from my perspective at this point.

If not comfortable about those biology principles, make your head reading https://biodifferences.com/difference-between-mutualism-commensalism-and-parasitism.html

---

@jans23 donations expected otherwise expect less collaboration from me in the future, and future security issues discovered on my side will be associated with a CVE. I learned my lessons, and won't hesitate on going public following ethical disclosure, which i did. This was discussed in chat, in person, you don't seem to understand.

This is me reminding you that the nk3 is not a novelty product and used for security purposes, here under Heads for remote attestation. This remote attestation, through reverse HOTP to a usb security dongle under Heads, always required: authentication, reset and provisioning capabilities, and since forever forwrd plans discussed many times in the past to reduce OEM provisioning time, unattended reset+automated secret provisioning to augment strength of anti-interdiction (both hardware+security dongle in same hipping package) while reducing OEM provisioning costs: reduce time to shipment on OEM side and ease User Re-Ownership frictions while implementing best practices with even diceware passphrases (I shipped this with the Privacy Beast at first shipment back in ~2018, made conferenes about this, and that was what was QubesOS certified.)

If work leading to https://www.nitrokey.com/blog/2024/heads-v25-and-nitrokey-3-firmware-v171-security-update was not compensated in money before (+30h there, didn't count), and as we talked at QubesOS mini-summit 2024 in person, work needs to be paid, otherwise maybe stop selling security promises or pay for security audits not relying on my discoveries that shake trust from the ecosystem and myself into secirity promises, discoveries from my side while testing other things to discover vulnerabilities/bad design/regressions in nk3 over previous security dongles. This impacts myself, Nitrokey, but also partners and the whole ecosystem, resulting in money losses from every support team depending on your security dongles, resulting in issues opened in all partners issue tracking systems, qubesos forum discussions and ping pong games between everyone; meaning downstream/upstream lost time and energies resulting in money loss by being neglectful.

The issues/PR above, and as you can see if clicking on them, needed a lot of involvement (again) ffrom my side, which was not expected/planned. I understand that it was not planned from Nitrokey either, but that is the problem. And work needs to be paid. I never consented to this in this feature freeze, nor what lead to 1.7.1 nk3 firmware when testing improvements on OEM factory reset/Re-Ownership 6 months ago either.

Details of work done here:

• nk3 reset needed to done by Heads as part of oem-factory reset and re-onwership. Still requires physical presence which is unexplained regression of nk3 and prevents unattended oem reownership with diceware secrets for now until regression fix for Allow factory reset/pin change without user presence Nitrokey/nitrokey-hotp-verification#41
• nk3 needed to provide real information on its secrets app PIN state, which is not the same as for nk2/nk1/nk2 storage (which was GPG Admin PIN) to be parsed and dealt with so that sealing HOTP could be done when public key <1 month (in delay of oem factory reset to the moment shipped to the user on first HOTP sealing per OEM/User attempting default PIN). This was broken since nk3 release and never fixed by Nitrokey nor under Heads code or even discussed prior of introducing change and regression, leading to losses.
• Heads needed to be adapted to deal with proper hotp-verification output for nk3 now reported secrets app PIN (Add support for nitrokey 3 distinction between the secrets app firmware and the device firmware versions Nitrokey/nitrokey-hotp-verification#43)

This can be tested under #1875 and I won't have time to split it all out, feature freeze discussed was 2024-11-20, and as of 2024-12-11 I'm still waiting for a version bump of hotp-verification to use that commit under Heads.

[tlaurion]

The one i'm the most interested (Heads maintainer), per defined priorities at Nitrokey/nitrokey-hotp-verification#36 (comment) is Nitrokey/nitrokey-hotp-verification#46, starting with it.

[tlaurion]

The one i'm the most interested (Heads maintainer) is Nitrokey/nitrokey-hotp-verification#46, starting with it.

Ha. segfaults on nk2/lk Nitrokey/nitrokey-hotp-verification#46 (comment)

[tlaurion]

Finally got an understanding that it doesn't make sense to not set a pin if no default pin is set at Nitrokey/nitrokey-hotp-verification#46 (comment)

[tlaurion]

There is still two pins instead of one at Nitrokey/nitrokey-hotp-verification#44 (comment)

[tlaurion]

A lot of misunderstanding around Nitrokey/nitrokey-hotp-verification#45 around related issues.

There is no need to change pins if there is only one secure app pin which if locked requires reset, as opposed to gpg pins..... Seems like nitrokey attempts to reinvent the wheel and do patches on top of bad design.

Let's review what worked before here instead of under their issues and PR, since I'm not going to participate but sporadically more and more feeling like https://vimeo.com/800938284

---

Under gpg:

• reset code (if provisioned: not provisioned by default) unlocks gpg Admin PIN
• gpg Admin PIN can unlock user PIN
• gpg User PIN cannot unlock itself when locked (counter of PIN attempts decremented from 3 to 0).

On devices prior of nk3

• HOTP related PIN was GPG Admin PIN: rarely used on the daily but for remote attestation to seal state in HOTP (ie: after config settings change, after firmware upgrade, otherwise tampering. Reseal needed when remote attestation fails, meaning TPMTOP secret in TPM nvram cannot unseal)
• GPG Admin PIN was reset to default pin 12345678 per oem-factory-reset/re-ownership on gpg reset call.
• Both GPG Admin PIN and User PIN could then be changed because the default PINs always set and known (always set to known default values, default values never change and hardcoded)

Nk3:

• adds a secret app pin, currently misleadingly duplicated in another set of User and Admin PIN (confusing for all) where only one exists for secret app PIN.
• currently not set by any default PIN
• pin set at first use since HOTP 1.6 and nk3 firmware 1.7.1.
  • Prior of that, was accepting any pin, HOTP secret resealing was only needing physical presence, silently accepting and neglecting any PIN that was entered.

Therefore.

• It makes no sense to have a pin change if no default pin is previously, and alway set (change what?)
• secure element pin has a counter of 6 attempts as opposed to 3 for GPG Admin/User PINs on devices <nk3
• changing a secret app PIN useful use case would be if user upgraded firmware and fears eavesdropping of that pin because.... He upgraded firmware in unsafe environment that potentially eavesdropped his Secret App PIN? Bad opsec = Bad user.
  • changing PIN: Nice to have at best but if necessary, we fail our users: nothing implements this change outside of GPG for GPG related PINs today which doesn't fit secure element today, nor we have any GUI to do this today : not planned on my side.

TLDR...... hotp-verification should

• Either set a default secret app pin and offer pin change so re-ownership can change it just like before as part of re-ownership for <nk3 (GPG Admin PIN for <nk3 is nk3 secret app PIN for nk3. Regression as of today, best practices not followed, reinventing the wheel with weaker process was chosen as of today)
• have hotp_verification reset SECRET_APP_PIN requiring a pin if none set by default
• Have hotp_verification reset set a default PIN, which if we don't plan to reinvent the wheel should be equivalent to gpg Admin PIN which is 12345678.

@daringer this is heads requirements.
You have to decide what is best for nitrokey other secret app PIN; I have no voice there, but this is looping over Heads use case. Nitrokey chose to reinvent the wheel without consulting first. And current implementation is bogus.

Consequently. hotp_verification should also stop presenting false or misleading information:

• report only one single secure app PIN, and only for nk3 (stop misleading users with additional Admin and User PINs that don't exist and confuse UX, we all know better and overflowing support requests for no good reason. This is shoveling problems into the future for all ecosystem. Justifiable other use cases? Name them and let's work around them, otherwise bad design.
• report GPG User/Admin PIN counters (tries left)
• present real nk3 high level firmware version, eg 1.7.1.
• If and oly if useful to nitrokey, keep secret app version in info output... but this useless to Heads and misleading to end users. TMI unless stated otherwise.

That's it.

---

Added number of hours spent on this prior of even implementing changes needed under heads, feedback received after feature freeze original date set to 2024-11-20. Everything will land in my hands at the same time, I hope everyone will understand that it's not how things should work for healthy iterative development. Tag bounty added.

[tlaurion]

We seem to finally have an understanding (Nitrokey/nitrokey-hotp-verification#39 (comment))

that:

• hotp_verification info alone is needed, there is no need for pin-info, and that info should present only real, accurate, actionnable info: GPG Admin/User PIN, Secure App PIN, fimware version (user can check it: 1.7.1? no need for secure app subversion unless relevant for Nitrokey support eam somehow, left to their discretion!), and this info being output only if present (no Secure App PIN: don't show it) under Add pin-info command Nitrokey/nitrokey-hotp-verification#44
• We seem to finally have agreed that the way to go for hotp_verification reset will not be to set a default PIN by default, and require SECRET_APP_PIN argument to be provided by oem-factory-reset under Heads, which will require physical presence until next nk3 version. This is ongoing Add reset command for nitrokey 3 Nitrokey/nitrokey-hotp-verification#46

Therefore:

• secure app PIN passwd change (Add nk3-change-pin command Nitrokey/nitrokey-hotp-verification#45) is irrelevant if no PIN is set by default, and would require 2x physical presence (touch) unless nk3 firmware update removing physical presence requirement (Allow factory reset/pin change without user presence Nitrokey/nitrokey-hotp-verification#41)
• pin-info is irrelevant Add pin-info command Nitrokey/nitrokey-hotp-verification#44 (info is relevant and MUST CHANGE ) with requirements above, where we concluded that an additional subset of Admin/User PIN (which doesn't exist: there is only a single Secure App PIN existing) should be removed and replaced by a single Secret APP PIN, only if it exists.

Please confirm that we have same understanding @sosthene-nitrokey @daringer @nestire and this actionaable where I can only plug in change of commits and go forward in this issue which is aimed to test until mergeable and not causing regression for nk3.

---

On my side

I implemented a workaround for now for gpg output of PINs prior of asking to unlock openpgp smartcard for signing (showing GPG User PIN rety count left before User PIN locks see latest video output #1863), and reduce support request volumes, and will apply proper safeguards under Heads as started under #1850.

[tlaurion]

Another 5 hours today, customizing messages on Heads side and testing reset APP_SECURE_APP PIN in oem-factory reset since

Adding 5 hours to the 15 in OP.
Linked to Nitrokey/nitrokey-hotp-verification#46 (comment)

Diff:
https://github.com/linuxboot/heads/compare/b550151d54fb8545b16ff4e6c9a2e2eb57f0d289..444ff3ee3719956744f780e558bb3d72890e1224

[tlaurion]

5 hours testing Nitrokey/nitrokey-hotp-verification#43 Nitrokey/nitrokey-hotp-verification#46 under #1850

Modifying OP from 20h hours of work to 25h

[tlaurion]

5 hours Nitrokey/nitrokey-hotp-verification#46 (comment).

Changing op from 25h to 30h

[tlaurion]

hotp-verification still not version bumped. Not doing anything. Waiting. Seems like this work won't be paid.
Current hotp-verification + reset for nk3 was tested and output provided under #1875.

[tlaurion]

Version bump testing under heads, plus testing of some commits upstreamed not part of 1.7 resulting of issue Nitrokey/nitrokey-hotp-verification#52 and other issues/PR testing under #1875 staging PR

10h more, modifying op to 40h