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)

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)
• 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.