Switch p256/rsa3072 to rsa4096 in oem-factory-reset

[tlaurion]

Copy from https://matrix.to/#/!pAlHOfxQNPXOgFGTmo:matrix.org/$c9rY6olpOReMhqUg4kZVV52JvYCr5O7vj2Er7g8K3wE?via=matrix.org&via=nitro.chat&via=envs.net

@daringer @JonathonHall-Purism what would justify having nk3 enforce somewhat hidden p256 defaults (unless DEBUG is on) for nk3 today?

What would justify keeping RSA 3072 key generation on USB Security dongle (All other non nk3 today, all USB Security dongle if we switch to RSA for all) where before that was justified by OEM needing to stay behind laptops while they were provisioning where today everything is fully automated there?

If the justification is that some older nk3 firmware cannot enforce secure element based RSA key gen, then logic of oem-factory reset should be refactored with firmware versions verification to enforce p256 only where RSA4096 cannot be enforced, no?

Thoughts?

[JonathonHall-Purism]

@daringer @JonathonHall-Purism what would justify having nk3 enforce somewhat hidden p256 defaults (unless DEBUG is on) for nk3 today?

Not sure I can offer much on this, I don't have an NK3 and don't know much about any specific strengths/limitations it might have.

What would justify keeping RSA 3072 key generation on USB Security dongle (All other non nk3 today, all USB Security dongle if we switch to RSA for all) where before that was justified by OEM needing to stay behind laptops while they were provisioning where today everything is fully automated there?

It takes much longer to generate an RSA 4096 key doesn't it? I haven't tested lately, some numbers to compare are important here IMO.

Even though the OEM reset does everything, somebody still has to unpack and set up the laptop, plug in the key, do the OEM reset, init HOTP, unplug the key and re-pack everything, so it's still time spent assembling the device. Maybe long enough for them to start another one but it's still adding complexity. I can discuss it with our operations team if we have some numbers.

OTOH though, hypothetically, couldn't we eliminate the long time generating keys by generating them on the host and copying to the card? I know we have logic to do that but I think right now it is tied to formatting a split LUKS/clear flash drive, we'd need to be able to separate those.

[tlaurion]

@daringer @JonathonHall-Purism what would justify having nk3 enforce somewhat hidden p256 defaults (unless DEBUG is on) for nk3 today?

Not sure I can offer much on this, I don't have an NK3 and don't know much about any specific strengths/limitations it might have.

Noe as from 1.7.2 firmware: it could generate 3076+RSA keys. @daringer

What would justify keeping RSA 3072 key generation on USB Security dongle (All other non nk3 today, all USB Security dongle if we switch to RSA for all) where before that was justified by OEM needing to stay behind laptops while they were provisioning where today everything is fully automated there?

It takes much longer to generate an RSA 4096 key doesn't it? I haven't tested lately, some numbers to compare are important here IMO.

True, 3 minutes per key * 3 from human brain memory. Is that a problem?

Even though the OEM reset does everything, somebody still has to unpack and set up the laptop, plug in the key, do the OEM reset, init HOTP, unplug the key and re-pack everything, so it's still time spent assembling the device. Maybe long enough for them to start another one but it's still adding complexity. I can discuss it with our operations team if we have some numbers.

@JonathonHall-Purism thanks.
@jans23 @daringer wessel-novacustom: please provide input here. p256 support from what I understand was transitional. Now that secure element permits support, not sure why we should continue to support p256 unless proven to be more fit for some reason.

OTOH though, hypothetically, couldn't we eliminate the long time generating keys by generating them on the host and copying to the card? I know we have logic to do that but I think right now it is tied to formatting a split LUKS/clear flash drive, we'd need to be able to separate those.

Agreed @JonathonHall-Purism. That could be sub-issue to resolve. We wouldn't care about authenticated heads here and would want to simply generate in-memory + backup public key to a thumb drive? or not even because we would be in oem mode? Do I get the use case right? Simply generate subkeys in ram + key-to-card without public key backup because OEM wouldn't use it? This is where I see discrepencies in OEM deployments, where Nitrokey permits provisioning of USB Security dongle with secrets they ask from their shop and provision.

This is time to fill #1521 with clear OEM requirements. I have no problem investing time on this if some kind of money compensation is thee to improve things to fit OEMs deployment.

Thanks!

[tlaurion]

@jans23 ping