-
-
Notifications
You must be signed in to change notification settings - Fork 186
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
oem-factory-reset (OEM aimed tool) default PINs not outputted on screen #1067
Comments
I understand during OEM factory reset also Nitrokeys are reset. In this case HEADS could use the default PINs automatically without user intervention. |
@jans23 this is the case here, sorry if I wasn't clear. The factory reset puts the default PINs automatically. What I mean here is that those PINs are not shown nor known to the user. At best for oem->user transit tamper evidence, should not even be known from neither user nor oem. Keep reading. We should not imply that an end user knows what is the value of those default PINs unless we imply that the users search for those online and dig GPG documentation. (Without the error shown on screen because it was troubleshooting on Yubikey usage. Image comes from #1063 (comment)) Why nowI never really used this code myself and have to admit that my audit of it was limited to being functional/not functional before, while reviewing it in the scope of #1067 gave me some goosebumps. And here again, mea culpa, I depended up until now on my fork #551, implementing diceware passphrases and a reownership wizard. In that use case, OEM passphrases are automatically generatated and never shared with the end user since only serving transit tamper evidence, being replaced at time of re-ownership after validating firmware and /boot integrity. I'm now looking into current state of the oem-factory-reset, and looking in ways to re-implement stuff in a simpler way in the goal of upstreaming it so security is accessible to all, but won't go through the same burden that happened under #551 which complexity led to a non-merge. I'm now looking into seeing if oem-factory-reset could be the place for modifications, or if the way to go is having OEMs responsible to deploy their own reownership code if desired, being signed by their private OEM key, where Heads would validate integrity/authenticity prior of entering re-ownership mode from Heads provided public key. Those are my current options. Upstreaming something that is secure enough, or splitting this out of the Heads project where every OEM could do what they want and users being able to inspect it; that script becoming public to users, but from a Heads perspective, woukd be proprietary and not in-tree. In-tree changes would include the reownership triggering (/boot/oem exists?) while script path would be hardcoded (/boot/reownership.sh) where Heads would be responsible to validate integrity of the script against provided detached signature and will validate it against known OEM public keys added under /etc/keys/oem/ used to validate only reownership script providdd by OEM. Default PINs enforced by oem-factory-reset todayUsage of default PINs on a security aimed device is still really questionable to me:
On a security perspective:
In those use cases following oem-factory-reset usage, I only see valid user-triggered oem-factory-reset security being given by enabling Disk Unlock Key being released by TPM, so that the TPM NV memory kept secret and sealed Disk Unlock Key is released by TPM if past sealed measurements (including LUKS header, kernel modules loaded and firmware measurements) are valid and that the Disk Unlock Key passphrase is valid. But yet again here, /boot integrity could lie to the user, which relies solely on USB Security dongle's PIN. Security of USB Security dongle's enforced security being invalidated here. Additionally, in this use case of having default PINs, the remote attestation over HOTP is less interesting then the TOTP version kept in smartphone from scanned Qr code. That TOTP would be more valid verification then HOTP, since HOTP can be changed with the default Admin PIN, where Qr based TPMToTP was at least secured by (we hope) a smartphone proper lockscreen mechanism. Security of USB Security dongle's enforced security being invalidated here. This mind game permits to ask ourselves what is the advantage of the oem-factory-reset as it is with default PINs?
This might be good for fast testing/if the user is thought to ALWAYS have the dongle in its pocket (which is never the case). I am really not sure about the current defaults of this script. Custom PINs enforced by oem-factory-reset todayWhen the user asks for a custom PIN, that PIN is applied for User PIN + Admin PIN + TPM Ownership PIN. If asked to set a custom PIN, I'm not sure why User and Admin would have the same PIN? Convenience, I understand, but eavesdropping User PIN would permit to an attacker to reseal HOTP (Admin=User PINs) without user ever knowing, which defeats end-user thought (faith based security) protection? And If the oem-factory-reset code is used to generate signing/encryption/authentication keys to be used to encrypt emails and other private-driven stuff, the current Admin=User PINs is not fitting more important use cases for a USB Security dongle, where the user is left to manually generate keypairs and manually provision their USB Security dongle. So my question here again would be: what are the expected use cases for the current oem-factory-reset implementation? Next stepsI would advise into at least having custom PINs prompt asking for 2 distinct PINs (or generating them from Diceware dictionnary for user/OEM in ALL cases), where the Admin PIN could be reused for TPM Ownership as it is right now, and additionally used to define a reset code. Let's remember that if the goal here is transit tamper evidence, there is no need for those passphrases to be even known to the end user, and Heads actual mechanisms are all there. We could modify Heads main screen to also show the outcome of /boot integrity validation. That is, if a user GPG keychain exists, exported from key-init, to output the HOTP (valid/invalid) result onscreen alongside of /boot integrity being valid/invalid. That is good enough for in transit firmware and /boot integrity validation and doesn't require any secret sharing with customers. The user would be protected against evil maid trying to modify ROM and reseal with Admin PIN and be able to unlock Admin PIN if dongle was bruteforced, with Reset code. Since the Admin PIN is barely if never typed by the user, this would offer a proper trade-off. Lost USB Security dongle still being a case for #771, while I think that oem-factory-reset altogether might be replaced by a proper implementation of #771 as well, which would also cover Yubikey not currently being supported under oem-factory-reset as reported under #1063 and where a proposed PR there doesn't fix Yubikey usage without breaking Librem Key/Nitrokey use case. |
As the name implicates, the OEM Factory Reset aims for OEMs (like Nitrokey), not for end users. We use it to prepare laptops in our workshop. I agree that User PIN, Admin PIN and TPM PIN should differ and ideally changed from default values to custom values.
Nitrokeys uses PINs and not passphrases. The difference is that PINs can be short (e.g. 6 digits) and in combination with the device's PIN counter provide sufficient strong protection against brute force attacks. Therefore no need for long passphrases. Not sure if this answers all your questions. Does it? |
I think simply outputting the PINs is clearly something that imposes no disadvantage for the vendor (e.g., Nitrokey), but still serves as a certain added value for the end-user doing a factory reset for whichever reason. So here I would fully second this approach.
Also cool with that, but there should be a option for OEMs to stick to default pins. Both always come with trade-offs, means either a "default pin" or a "communicated pin" (even if the OEM sets an random pin, this has to be communicated to the user - this is very customer unfriendly and not really an option). This being said, the imho "cleanest" solution would be to have something like a |
Pureboot way is to burn one PIN attempt trying to change it. |
Means Pureboot will try |
The PINS should be given back to the end-user:
User PIN by default is: 123456
Admin PIN by default is: 12345678
TPM Ownership PIN: 12345678
Otherwise end-user needs to google stuff around to/from Nitrokey/Purism/Other brands of GPG enforcing USB Security dongles. Heads should ease that process and tell what passphrases setuped are.
@alex-nitrokey @nitrosimon @jans23 @MrChromebox
Note: when it comes to manually selecting passphrases, I personally prefer when those are not echoed back in plaintext, but when there is a prompt requiring me to type it to confirm my input. That would be valid for all secrets to be typed, but that is just a personal opinion.
#1063 (comment)
The text was updated successfully, but these errors were encountered: