Skip to content
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

Closed
tlaurion opened this issue Dec 1, 2021 · 7 comments · Fixed by #1136
Closed

oem-factory-reset (OEM aimed tool) default PINs not outputted on screen #1067

tlaurion opened this issue Dec 1, 2021 · 7 comments · Fixed by #1136

Comments

@tlaurion
Copy link
Collaborator

tlaurion commented Dec 1, 2021

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)

@tlaurion tlaurion changed the title oem-factory-reset oem-factory-reset default PINs not outputted on screen Dec 1, 2021
@jans23
Copy link

jans23 commented Dec 2, 2021

I understand during OEM factory reset also Nitrokeys are reset. In this case HEADS could use the default PINs automatically without user intervention.

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 3, 2021

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.
We should say clearly what they are (while you know my perspective on using default passphrases).
It's never written on the screen, currently buried inside of the script only and the output is buried into redirected output and nevrr shown on screen, see below link.

This is what the user sees

(Without the error shown on screen because it was troubleshooting on Yubikey usage. Image comes from #1063 (comment))


Why now

I 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.
On Heads, there wouldn't be any compromise on security, where the reownership code would be executed from /boot would be detached signed, and where Heads would only contain OEM keys, validating reownership code (eg. /boot/reownership.sh) if detached signature (eg. /boot/reownership.sh.sig) exists, being validated by a public key (eg. /etc/keys/oem/Insurgo.sig) validating its state prior of use.

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 today

Usage of default PINs on a security aimed device is still really questionable to me:

  • At best, is it security by obscurity (relying on default PINs being unknown to some?)
  • Rapid testing case? If then, why is it the default?

On a security perspective:

  • What is the valid use case of signing /boot with a dongle's known passphrase of 123456 for the user? What is stopping someone having rapid access to that USB Security dongle being left on table, or plugged in computer, from modifying grub configuration, dropping a compromised Xen/Kernel/Initrd and signing changes? OEM-> user transit tamper evidence is invalidated here.
  • What is the use case of remote attestation over HOTP with a known passphrase of 12345678 for the Admin PIN? What is stopping someone having rapid access to that same above USB Security dongle from replacing firmware with a compromised one and reseal HOTP measurements without the user knowing unless he validates firmware integrity with TOTP/Disk Unlock Key passphrase? OEM-> user transit tamper evidence is invalidated here.

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?

  • HOTP Resealing can be done with the the default Admin PIN
  • Signing /boot content can be done with the default User PIN?

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).
But then, why having a USB Security dongle with PINs if PINs are not an enforced security feature which defeats the USB Security dongle promises?

I am really not sure about the current defaults of this script.
@kylerankin @MrChromebox @jans23


Custom PINs enforced by oem-factory-reset today

When 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?
Again it leads to #771 to deal with this properly, but I'm eager to hear your thoughts and current usage in your current deployments.


Next steps

I 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.

@jans23
Copy link

jans23 commented Dec 6, 2021

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.

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.

(or generating them from Diceware dictionnary for user/OEM in ALL cases)

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?

@daringer
Copy link
Collaborator

daringer commented Dec 6, 2021

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.

I would advise into at least having custom PINs prompt asking for 2 distinct PINs

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 first start flag (which is set after a oem-factory-reset), which will lead to a prompt for the user (forcing him/her) to update the pin. The first start flag would then only be cleaned up if the user successfully sets a non-default pin, which would remind the user to update the pins (with the drawback that this would not be cleared if the user chooses to change the pin outside of heads).

@tlaurion
Copy link
Collaborator Author

tlaurion commented Dec 7, 2021

Pureboot way is to burn one PIN attempt trying to change it.

@tlaurion tlaurion changed the title oem-factory-reset default PINs not outputted on screen oem-factory-reset (OEM aimed tool) default PINs not outputted on screen Dec 7, 2021
@daringer
Copy link
Collaborator

daringer commented Dec 7, 2021

Means Pureboot will try 1234 on every boot and warn the user accordingly if the default pin is set ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants