Clarify/document hotp-verification output for 6 Admin/User PINS and firmware version

[tlaurion]

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 ?