-
-
Notifications
You must be signed in to change notification settings - Fork 185
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch p256/rsa3072 to rsa4096 in oem-factory-reset #1764
Comments
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.
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. |
Noe as from 1.7.2 firmware: it could generate 3076+RSA keys. @daringer
True, 3 minutes per key * 3 from human brain memory. Is that a problem?
@JonathonHall-Purism thanks.
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! |
@jans23 ping |
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?
The text was updated successfully, but these errors were encountered: