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

Add option to change the nk3 secret apps pin for reowner ship #40

Open nestire opened 2 days ago

nestire commented 2 days ago

see also #36

this is not yet possible in heads only via nitropy or the nitrokey app 2

tlaurion commented 2 days ago

GPG Admin/User PINs are reset through gpg factory reset under Heads. If Admin PIN has no counter left then Admin is locked out and factory reset needs to be done there. That was also the case for HOTP in nk2/librem key for HOTP secret sealing: GPG Admin PIN was used there.

The bare minimal here would be to have hotp-verification permit factory reset of the secret app just like gpg does for opengpg smartcard si that OEM factory reset and re-ownership can be done under Heads, and the secret element by wiped as anything else in the dongle.

No issue was opened to tackle the issue of physical presence. Could this be optionally turned off when reset at oem-factory-reset through hotp-verificarion?

This prevent unattended oem factory reset and transfer of ownership improvements to happen and I see no justification for touch requirement in remote attestation use case but maybe for servers: PIN does the physical presence + authentication being physically present brings what more?

nestire commented 2 days ago

@tlaurion for the presence see #41 but not sure if there is a good way of doing this

daringer commented 1 day ago

this will lead to a new command line argument: change-pin <old-pin> <new-pin>

how to handle backwards compatibility? will this just fail for pro/storage? I don't think it makes sense to re-implement gpg functionality here.

tlaurion commented 1 day ago

this will lead to a new command line argument: change-pin <old-pin> <new-pin>

how to handle backwards compatibility? will this just fail for pro/storage? I don't think it makes sense to re-implement gpg functionality here.

I'm not sure I understand why simple equivalent of nitropy nk3 secret reset is not implemented first, with Hotp-verification being transparent when it sets a pin to secret element, permitting heads to set it as part of ownership, re-ownership

PIN change would be nice, but it's not the blocker here. HOTP sealing, resealing and PIN provisioning is the blocker @daringer

tlaurion commented 1 day ago

this will lead to a new command line argument: change-pin <old-pin> <new-pin>

how to handle backwards compatibility? will this just fail for pro/storage? I don't think it makes sense to re-implement gpg functionality here.

@JonathonHall-Purism comments?

daringer commented 1 day ago

I'm not sure I understand why simple equivalent of nitropy nk3 secret reset is not implemented first, with Hotp-verification being transparent when it sets a pin to secret element, permitting heads to set it as part of ownership, re-ownership

PIN change would be nice, but it's not the blocker here. HOTP sealing, resealing and PIN provisioning is the blocker @daringer

please don't derail this issue, this has nothing to do with reset - we can for sure prioritize reset - no problem, this issue - as you requested - is about something else. If priorities belong somewhere, then into the parent issue where you asked for these issues. Let's please focus on pin change here and it would be great if we could answer the questions I asked.