search

Nitrokey / nitrokey-hotp-verification

A command line C app to validate HOTP codes on Heads
GNU General Public License v3.0
11 stars 10 forks source link

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

Open tlaurion opened 1 month ago

tlaurion commented 1 month ago

Wrongly reported under https://github.com/linuxboot/heads/issues/1726

My answer at https://github.com/linuxboot/heads/issues/1726#issuecomment-2241140702

@nestire answer (incomplete) at https://github.com/linuxboot/heads/issues/1726#issuecomment-2243048271

--

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 commented 1 month ago

Relevant:

tlaurion commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@daringer : could hotp-verification

daringer commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

@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:

On hotp-verification output:

Let's start from there @daringer ?