Clarify/document hotp-verification output for 6 Admin/User PINS and firmware version, lack of secret app Heads mechanism for 'secret' app reset/Admin PIN

[tlaurion]

Analysis under: #36 (comment)

Pictures under: #36 (comment)

Need:

• hotp-verification report real nk3 firmware version
• hotp-verification capability of resetting/PIN change of distinct nk3 secure element's Admin PIN for oem/re-ownership
• reconsideration at nk3 manufacturing state to require touch/physical presence to seal HOTP to nk3
• change hotp-verification output of counters (admin/user pin both decrement on wrong PIN input) - > only one secret app PIN only showed for nk3
• Changes in both hotp-verification and Heads handling hotp-verification output for proper UX based on nk3 real status, redo Heads assumptions

Blocker for linuxboot/heads#1827

---

History: Wrongly reported under linuxboot/heads#1726

My answer at linuxboot/heads#1726 (comment)

@nestire answer (incomplete) at linuxboot/heads#1726 (comment)

--

End user asked clarifications under Dasharo Premier support at (answered by me): https://matrix.to/#/!RNcjJXCGHiyxXCHpKv:matrix.org/$A9IbvnjLuw1EaXAynHtvlrnewrkPqYpMA2kae5t1ONM?via=matrix.org&via=nitro.chat&via=matrix.3mdeb.com

[tlaurion]

Relevant:

• v1.5: hotp-verification's reported firmware version is incorrect #33
• V1.5 : NK3 currently accepts any PIN on HOTP secret sealing #30

[tlaurion]

End user asked clarifications under Dasharo Premier support at (answered by me): >>https://matrix.to/#/!RNcjJXCGHiyxXCHpKv:matrix.org/$A9IbvnjLuw1EaXAynHtvlrnewrkPqYpMA2kae5t1ONM?via=matrix.org&via=nitro.chat&via=matrix.3mdeb.com
I've just read the seal-hotpkey source code and it suggests that this is expected behaviour for a month, but you are encouraged to change it - will do that, thanks :-)

@jans23 @nestire @daringer : seal-hotpkey get the output of gpg which in this case is a bit irrelevant since NK3 implement HOTP secret independently of GPG. The "age" being <1 month old is still valid for public key age, where card counters don't apply for NK3 HOTP secret validation.

So technically, logic applied under seal-hotp-key to check HOTP counter (not Admin PIN related) is invalid as of today.

See https://github.com/linuxboot/heads/blob/ebd9fbadb63ae9f43e8497a2d0aebbed169f1767/initrd/bin/seal-hotpkey#L97-L107

[daringer]

It looks like the output of hotp_verification info is only used inside the lower part of the referred code snippet. Essentially hotp_token_info is parsed for the admin pin retry count.

As hotp_verification is anyways only used in HEADS, wouldn't it make sense to tailor its output more towards the needs of HEADS? How about you propose what hotp_verification info should output (best case with an example) for the different security tokens accepted (should be: nk-pro/storage, librem, nk3) and we adapt its output accordingly?

Going this way the entire hotp_token_info parsing could be removed from HEADS.

[tlaurion]

@daringer : could hotp-verification

• output nk3 firmware version, not the secret secure element version?
• could hotp-verification report on HOTP/GPG Admin/User PIN?
• Could hotp-verification make nk1/2 pro/librem key/nk3 usage a total abstraction of the HOTP sealing firmware requirements?

[daringer]

output nk3 firmware version, not the secret secure element version?

will check

could hotp-verification report on HOTP/GPG Admin/User PIN?

I suppose you mean it should report remaining tries, if so: will check

Could hotp-verification make nk1/2 pro/librem key/nk3 usage a total abstraction of the HOTP sealing firmware requirements?

Don't understand this, can you elaborate what you mean here? Also please keep in mind we are talking about hotp_verification info here.

Generally, an example of the expected output of hotp_verification info would help to get the same understanding.

[daringer]

The first and second points should not be too complicated, @tlaurion could you please tell (note down an example) how you would like the hotp_verification info output to look like ?

[tlaurion]

The first and second points should not be too complicated, @tlaurion could you please tell (note down an example) how you would like the hotp_verification info output to look like ?

Sorry I haven't looked into this.
Well I do not know what is available there. My point was to make this abstract of nk1 nk2nk3 lk2, Heads should depend on hotp-verification to give user feedback that can be understandable by cognizant beings.

As of now the output doesn't make any sense providing info that are not even in releases notes so cannot even be crosslinked.

I already referred to what code of heads do and where things could be adapted depending of what hotp-verification could provide.

For the rest this is nitrokey problem, not mine I'm sorry.

I would hope this is actioned upon without needing me to produce any ouput whatsoever: nitrokey changes should not break compatibility, or hotp-verification should be adapted to follow nitrokey changes. I make a statement here. I was told to stop working for free. That's what I'm doing.

[tlaurion]

@daringer : maybe we have to flip this around and see what Heads official docs currently says at https://github.com/linuxboot/heads-wiki/blob/master/Installing-and-Configuring/configuring-keys.md rendered at https://osresearch.net/Configuring-Keys/#oem-factory-resetre-ownership

Thinking points:

• hotp-verification was an implementation detail. With NK3, GPG Admin pins has nothing to do with HOTP. How would you word that?
• OEM Factory reset doesn't set it, its set on first use. What would be the guidelines for HOTP related PIN, how users are supposed to change it etc? what are the official Nitrokey Docs, how can end user make sense of it all?

On hotp-verification output:

• Please output nk2 output, detail its meaning
• Please output nk3 output, detail its meaning

Let's start from there @daringer ?

[tlaurion]

@daringer do you think we can do a crunch here and fix this issue prior of 2024-11-20 feature freeze of Heads at linuxboot/heads#1821 ?

I had again an issue at #37 (comment) related to hotp-verification not reporting the good thing and therefore Heads doing wrong assumptions.

Eg:

Message: Not trying default PIN (12345678) only 0 attempt left si to say the least misleading

[tlaurion]

This discussion needs answers to #36 (comment) to follow through @jans23

[JonathonHall-Purism]

@tlaurion Could you paste / screenshot the result of hotp_verification info in this situation?

It's looking for ^\s*Card counters: Admin (\d),.*$. If the output changed, we can change the regex in Heads.

[tlaurion]

Repro:

nk3a-mini

test

user@heads-tests-deb12-nix:~/heads$ nitropy nk3 test
Command line tool to interact with Nitrokey devices 0.4.47
Found 1 Nitrokey 3 device(s):
- Nitrokey 3 at /dev/hidraw0

Running tests for Nitrokey 3 at /dev/hidraw0

[1/5]	uuid     	UUID query              	SUCCESS  	EF25D848139028D30000000000000000
[2/5]	version  	Firmware version query  	SUCCESS  	v1.7.2
[3/5]	status   	Device status           	SUCCESS  	Status(init_status=<InitStatus: 0>, ifs_blocks=238, efs_blocks=465, variant=<Variant.NRF52: 2>)
Running SE050 test: |                                                                                                                                                                                              
[4/5]	se050    	SE050                   	SUCCESS  	SE050 firmware version: 3.1.1 - 1.11, (persistent: (31432,), transient_deselect: (607,), transient_reset: (592,))
Please press the touch button on the device ...
Please press the touch button on the device ...
[5/5]	fido2    	FIDO2                   	SUCCESS  	

5 tests, 5 successful, 0 skipped, 0 failed

Summary: 1 device(s) tested, 1 successful, 0 failed

reset:

user@heads-tests-deb12-nix:~/heads$ nitropy nk3 secrets reset
Command line tool to interact with Nitrokey devices 0.4.47
Do you want to continue? [y/N]: y
Please touch the device if it blinks
Done

Then from Heads:

$ cat hotp_verification_info-output_nk3a_mini.log 
HOTP code verification application, version 1.6
Connected device status:
	Card serial: 0xEF25D848
	Firmware: v4.13
	Card counters: PIN is not set - set PIN before the first use
Operation success

nk3-nfc

test:

user@heads-tests-deb12-nix:~/heads$ nitropy nk3 test
Command line tool to interact with Nitrokey devices 0.4.47
Found 1 Nitrokey 3 device(s):
- Nitrokey 3 at /dev/hidraw0

Running tests for Nitrokey 3 at /dev/hidraw0

[1/5]	uuid     	UUID query              	SUCCESS  	7BE66C6C09655959911E4A5958996AEF
[2/5]	version  	Firmware version query  	SUCCESS  	v1.7.2
[3/5]	status   	Device status           	SUCCESS  	Status(init_status=<InitStatus: 0>, ifs_blocks=41, efs_blocks=462, variant=<Variant.LPC55: 1>)
Running SE050 test: |                                                                                                                                                                                              
[4/5]	se050    	SE050                   	SUCCESS  	SE050 firmware version: 3.1.1 - 1.11, (persistent: (32767,), transient_deselect: (191,), transient_reset: (176,))
Please press the touch button on the device ...
Please press the touch button on the device ...
[5/5]	fido2    	FIDO2                   	SUCCESS  	

5 tests, 5 successful, 0 skipped, 0 failed

Summary: 1 device(s) tested, 1 successful, 0 failed

reset

user@heads-tests-deb12-nix:~/heads$ nitropy nk3 secrets reset
Command line tool to interact with Nitrokey devices 0.4.47
Do you want to continue? [y/N]: y
Please touch the device if it blinks
Done

Heads collected ouput:

user@heads-tests-deb12-nix:~/heads$ cat /media/hotp_verification_info-output_nk3_nfc.log 
HOTP code verification application, version 1.6
Connected device status:
	Card serial: 0x7BE66C6C
	Firmware: v4.13
	Card counters: PIN is not set - set PIN before the first use
Operation success

@JonathonHall-Purism yes, we could change regex (must: at least for linuxboot/heads#1821), even more if downstream plans to do one Heads release a year, maybe two).
@daringer that won't change the fact that the output reported by hotp_verification is totally irrelevant (UX? Scripts not working today in lack of proper output.)

• Firmware 4.13?
• How to get counts of HOTP bad attempts?
• What to change in code so that GPG Admin PIN is not thought to set HOTP as for Nk2/Librem keys?

[JonathonHall-Purism]

Relevant line (same in both): Card counters: PIN is not set - set PIN before the first use

It sounds like we are doing the right thing for the wrong reason. If no PIN is set, it doesn't make sense to try the default, but our message could be more precise, just by detecting this text.

I don't have an NK3. Is it possible to seal HOTP in this state? What PIN is the user supposed to enter? Based on that, what should seal-hotpkey actually do?

[tlaurion]

Relevant line (same in both): Card counters: PIN is not set - set PIN before the first use

It sounds like we are doing the right thing for the wrong reason. If no PIN is set, it doesn't make sense to try the default, but our message could be more precise, just by detecting this text.

Would be better but still really problematic:

I don't have an NK3. Is it possible to seal HOTP in this state? What PIN is the user supposed to enter? Based on that, what should seal-hotpkey actually do?

The 'secret' app gets its 'GPG Admin PIN" (Wrong naming...) set on first HOTP sealing. Exactly there (as of today, after reboot past oem-factory-reset run, which seals TPMTOTP secret through reverse HOTP in nk3 into its secret app):
quote from #36 (comment):

Message: Not trying default PIN (12345678) only 0 attempt left si to say the least misleading

But this hides another more important problem, as noted under #37 (comment), quoting:

• Resetting TPM/sealing TOTP through reverse HOTP fails

Screenshot:

This means....

• No user re-ownership can happen if OEM seals HOTP secret currenlty (without needing a second computer with nitropy to reset secret)
• Meaning that currently, HOTP isn't/can't be sealed by OEM???

We need:

• hotp-verification reporting properly on nk3 secrets Admin count (reminder, we have GPG Admin Pin, GPG User PIN and now Nk3 secret Admin PIN, where heads is aware/deals and report only of GPG PINs and can only set once HOTP related Admin PIN, but cannot reset it)
• hotp-verification reporting properly on firmware meta version (expected here: 1.7.2. I reask: what is 4.13?!?! And what is the end user supposed to do with that information?)
• How to get counts of HOTP bad attempts?
• What to change in code so that GPG Admin PIN is not thought to set HOTP (secret app Admin PIN) as for Nk2/Librem keys?
• And most importantly, a mechanism to change that secret app passphrase/reset it just like for nk2/librem keys (which were GPG Admin PIN). We cannot expect users to use nitropy on a second computer, can we? Ohterwise no re-ownership possible with TPMTOPT reversed seal in HOTP.

Thoughts and plan of action @daringer @jans23 @JonathonHall-Purism @sosthene-nitrokey @szszszsz?

[JonathonHall-Purism]

To make the user re-ownership flow work:

• surely we could implement the secrets PIN reset performed by nitropy in C or something, right? I don't know how this works and cannot really volunteer to do it as we're not selling NK3, but it does not seem this should fundamentally require python
  • then OEM reset could do this for nk3
• could OEM reset also perform a dummy HOTP seal for nk3, just to set the initial secrets PIN? E.g. seal it with 0000000.... or something, next boot will ask to reseal anyway, but the PIN will be set now

If the PIN is set, do we get a valid attempt counter?

[tlaurion]

To make the user re-ownership flow work:

• surely we could implement the secrets PIN reset performed by nitropy in C or something, right? I don't know how this works and cannot really volunteer to do it as we're not selling NK3, but it does not seem this should fundamentally require python

Yes. since hotp-verification already sets the secret app Admin PIN, i do not think its a far stretch to have it implement what is needed here so that as nk2/librem key, the nk3 can support oem factory reset/reownership properly, while Heads will need to become interactive here so that new HOTP requirement of physical presence of nk3 (touching dongle) is clearly stated in oem-factory-reset script for OEM/user when comes the time to seal TPMTOP through reverse HOTP to the nk3.

• then OEM reset could do this for nk3
• could OEM reset also perform a dummy HOTP seal for nk3, just to set the initial secrets PIN? E.g. seal it with 0000000.... or something, next boot will ask to reseal anyway, but the PIN will be set now

As of now, first attempt of HOTP without PIN being set is managed by hotp-verification and sets the passphrase provided at prompt as secret app Admin PIN on first use, so no need to sail it with a dummy PIN. But there is a need for reset/passphrase change that is for sure, with same reasons as explained earlier, otherwise there is no transfer of ownership possible and nk3 is regression over nk2/librem keys for Heads attestation with transfer of ownership being at heart of the concept not anymore respected.

If the PIN is set, do we get a valid attempt counter?

user@localhost:~/heads$ cat /media/hotp_verification_info-output_nk3a_mini-secret_admin_pin_set.txt 
HOTP code verification application, version 1.6
Connected device status:
	Card serial: 0x7BE66C6C
	Firmware: v4.13
	Card counters: Admin 8, User 8
Operation success

This adds to the current list : what is the User PIN here?

[JonathonHall-Purism]

... so no need to sail it with a dummy PIN. But there is a need for reset/passphrase change that is for sure

I mean do a dummy HOTP seal with the real pin, but dummy HOTP secret of all-zeros or something. Effectively, just setting the secrets PIN.

(Though a proper mechanism to just set the PIN would be much better.)

If we eventually have forward-sealing, we could forward-seal at that time with the real PIN and real HOTP secret.

[tlaurion]

Just did a test to see which counter (Admin/User) decrease when failing HOTP sealing.

Surprise surprise, both are decremented on bad TPMTOTP reverse HOTP sealing over nk3?his is why I originally opened this issue with OP.

cat /media/hotp_verification_info-output_nk3a_mini-secret_admin_pin_set-bad_hotp_reseal.txt 
HOTP code verification application, version 1.6
Connected device status:
	Card serial: 0x7BE66C6C
	Firmware: v4.13
	Card counters: Admin 6, User 6
Operation success

@daringer can you open independent issues to be worked on to fix this meta-issue, to be each individually addressed by PR once we agree on the problems exposed in this meta-issue?

I would need some kind of a timeline to know if the needed fixes will land before 2024-11-20, if we need to move that deadline under linuxboot/heads#1821, otherwise landing in known issues of downstream releases until next releases.

[tlaurion]

@daringer @jans23 @sosthene-nitrokey @szszszsz: ping.

Please let me know that you have clear understanding of the problems at stake here as detailed, with screenshots, under #36 (comment)

TLDR:

• Once HOTP is sealed the first time, accepting there any PIN given to set once with what is called today the Nitrokey Admin PIN. This PIN cannot be changed afterward, unless, as screenshot show, the user runs 'nitropy nk3 secret reset' or used 'Nitrokey App 2' on a second computer.
  • Hotp-verification needs to handle that by itself.
• This means that no re-ownership is possible
• This means that OEM factory reset needs physical presence and blocks feature requests of unattended, randomized secret provisioning and re-ownership
• reported versiin of firmware(screeshot: '4.13') doesn't mean anything as of today.
• Admin and User 'Nitrokey PINs' decrement at the same time at failed HOTP secret sealing, where user is right to think the re-ownership changed this PIN to match the ones fed at provisioning and factory reset.

I cannot highlight enough that 'Nitrokey Admin PIN' can only be configured once, and does not warn that there is a PIN being set when it does so, leaving everyone thinking its part of oem-factory-reset with PINs set there. Therefore if user types it wrong the first time its set without warning, the user cannot seal HOTP and needs second computer to reset dongle

[daringer]

please define priorities for the 4 newly created issues @tlaurion here - what needs to be there for a release (feature freeze) what doesn't.

[tlaurion]

For feature freeze, we need re-ownership to work as intended so that OEM can seal HOTP and end user can define new secrets per re-ownership.

This implies, in order or priority:

• Allow factory reset (no change PIN) without user presence Allow factory reset/pin change without user presence #41. So that Heads can reset secure element alongside gpg factory reset and expect to set GPG Admin PIN for Secret Element Admin PIN (User PIN/Admin PIN duplicated count output seems irrelevant here, not sure how to present proper UX without confusing user but that is Add cli option to request secret app admin/user pin counts #39). This is my blocker.
• Make info Output more verbose/consistent for admin/user pin Counts (Make Info Output more verbose for nk3 #38) to stop confusing users.
• Add cli option to request secret app admin/user pin counts (Add cli option to request secret app admin/user pin counts #39): on this, for nk2/librem key, discussions with @JonathonHall-Purism are needed too make sure of no regression in UI
• Add option to change the nk3 secret apps pin for Re-Onwership Add option to change the nk3 secret apps pin for reowner ship #40. This would be nice to have, but not sure needed if we can reset secret app. A re-ownership as up to now was resetting the whole security dongle (nk2/librem key), the arrival ok nk3 seperated things. I cannot tell what is best for other nk3 use cases, only thing I can say here is that since hotp-verification is silently setting secret app admin/user PIN on first HOTP seal, if the PIN there is entered with a typo, the user will be confused (just like I was when I discovered this) and won't be able to change it. He couldn't change it anyway because typo when asked to enter old PIN. With GPG, changing/unpocking User PIN can be done with Admin PIN, and if Admin PIN is locked, he can reset Admin PIN with "recovery key" if setup (not done by default). Since you said secret app User/Admin PIN is the same, I do not see this being really useful as opposed to a secret app reset where hotp-verification should prompt for PIN and wipe secret app, which is Allow factory reset/pin change without user presence #41

So in order of priority:

• Allow factory reset/pin change without user presence #41 (blocker for oem-factory-reset needed changes for OEM factory reset and now impossible re-ownership because use cannot change HOTP secret and need to know OEM HOTP secret: this is bad, and then needs second computer.
• Then Make Info Output more verbose for nk3 #38: hotp-verification output being usable by Heads (firmware version :do i need to upgrade)
• Then Add cli option to request secret app admin/user pin counts #39 (so end-user can understand output:, Single PIN/User/Admin PIN: no regression for nk2/librem keys and heads)

I do not think #40 is needed, but for users that know their HOTP PIN to change it before going abroad, or when they think someone saw them type HOTP sealing PIN on post firmware upgrade (wanted: at firmware upgrade), just so par with nk2/librem key which could be done through gpg before and now can't.

TLDR: #41>#38>#39, nice to have #40

[daringer]

okok, yeah #41 will not be possible, currently I do not support this overall, we will discuss this, but generally it is currently not an option. Also, given the firmware nature of this, this is independent to HEADS feature freeze. Even if I would greenlight this, a full firmware release for the nitrokey 3 takes time and is nothing to be pushed through within a week.

So we'll focus on #38 and #39 .... please make sure all asked information to finalize the work is stated in the respective tickets

[tlaurion]

okok, yeah #41 will not be possible, currently I do not support this overall, we will discuss this, but generally it is currently not an option. Also, given the firmware nature of this, this is independent to HEADS feature freeze. Even if I would greenlight this, a full firmware release for the nitrokey 3 takes time and is nothing to be pushed through within a week.

So we'll focus on #38 and #39 .... please make sure all asked information to finalize the work is stated in the respective tickets

Then #41 needs to be splitted into physical presence removal (firmware: later: that issue) and hotp-verification issue : heads need to be able to do équivalent of nitropy nk3 secret reset without requiring user to run nitropy/Nitrokey app on another computer. Please open missing issue.

Commented at #41 (comment)

[tlaurion]

@daringer

End user reported issue linked to this just now https://matrix.to/#/!RNcjJXCGHiyxXCHpKv:matrix.org/$suNZxaOPK-1hUSNccluJABlNvEZTIPt_S1V2orNJsbw?via=matrix.org&via=nitro.chat&via=tchncs.de

Please answer to premier support channel and understand how this is problematic please

[tlaurion]

@sosthene-nitrokey just want to make sure we are at the same page:

<nk3

HOTP code verification application, version 1.7
Connected device status:
Card serial: 0x7BE66C6C
         Firmware Nitrokey 2: v1.7.1
OpenPGP smartcard PIN counters : Admin: 3, User: 3
Operation success

nk3:

HOTP code verification application, version 1.7
Connected device status:
Card serial: 0x7BE66C6C
         Firmware Nitrokey 3: v1.7.1
         Firmware Secrets app: v4.13
Secret app PIN counter : 6
OpenPGP smartcard PIN counters : Admin: 3, User: 3
Operation success

Originally posted by @tlaurion in #38 (comment)

[tlaurion]

For feature freeze, we need re-ownership to work as intended so that OEM can seal HOTP and end user can define new secrets per re-ownership.

TLDR: #41>#38>#39, nice to have #40

#41 was deemed impossible because physical presence removal required nk3 firmware change, and led to #42

So priorities are:

#42>#41>#38>#39, nice to have #40