GPG Authentication exists!

[tlaurion]

The future of GPG authentication, and Restricted Boot (RB) integration discussion started under #1515 (comment)

We have discussions since osresearch/heads moved to linuxboot/heads yesterday, so I suggest we use it!

So as of #1515 current state, generating keys in memory and creating an encrypted USB Thumb drive of GPG key material (master key, signing, encryption and authentication subkey, revocation key) copied to encrypted drive, while public key is copied to public partition is enough to enable GPG authentication, which is enabled right away.

This is currently fully optional, since the prompts to generate keys in memory and create an encrypted backup defaults to N in the OEM Factory Reset/Re-Ownership Questionnaire as shown at #1515 (comment)

I would really love to have input from the community for the path forward.

If enabled today as per commit 1ce158b in that PR, GPG Authentication (gpg_auth function) is called from:

• Recovery Shell access
• USB Boot (both detached signed ISOs or dd'ed drive).

The intent of the discussion is more tailored at use case then implementation details, but I'm ready for both!

[tlaurion]

@JonathonHall-Purism said under #1515 (comment):

👀 This is getting really long already and I have not gotten through the use cases you listed yet, posting this to break it up as I continue to go through them. May edit this if some of my thoughts are already answered 🤔

I think we should add a CONFIG_GPG_AUTH=y and that both CONFIG_GPG_AUTH= and CONFIG_HAVE_GPG_KEY_BACKUP=y should be checked by gpg_auth to enforce authentication in code?

Agree that it should be a separate config but IMO "GPG_AUTH" is too vague, and it's also a "how". Other things, like the content of /boot, are also authenticated with GPG or could be. Since the goal of this feature is to prevent tampering by requiring authentication before any action that could tamper, how about CONFIG_TAMPER_PREVENTION?

I'm not sure it needs to be tied to CONFIG_HAVE_GPG_KEY_BACKUP, but probably better safe than sorry, we can leave it tied to that initially and expand later if it makes sense.

I think the PR should offer gpg_auth out of the box.

Why does that matter? If you just don't want to merge the keygen improvements without GPG auth for some reason, it could still be two PRs 🤔

That said it's not critical either, but this is turning into a monster thread already buried inside of another feature's PR 🤔

Security goals: have authentication enforced prior of doing stuff that are not necessarily leaving tampering traces without restricting freedoms, and where left feasible actions can not wipe data (DOS) unless user authenticates himself, leaving physicla tampering/theft as the only possible threats to daily usage and leaving laptop unattended in a reasonably secure location.

This is great 🤩 So we want to prevent a physically-present attacker from disabling the system (in the absence of physical tampering, which as always requires physical countermeasures). That's different from RB as well. Booting the system authenticates by unlocking the disk (either normally or via TPM LUKS unlock), and we assume that the OS will not allow taking any destructive actions until the disk is unlocked (e.g. if it drops to a recovery shell after N failed attempts to unlock /, that'd be a problem).

So I think we need to prevent the following. We could gate them on authentication or require that the feature is disabled to access them:

👉 Edit: per other thoughts in the use cases, I'm 100% on board with doing this iteratively, not necessarily checking all the boxes initially. This is more to "begin with the end in mind" so we have a clear path to get there.

• External booting ✔️
• Recovery shell ✔️
• Flashing firmware 👈 Otherwise you could "upgrade" to a tampered ROM defeating this
• OEM reset
• Changing config settings - at least some of them, definitely this feature itself
• Boot menu (can't allow OS recovery options as you'd get an initramfs shell)
• Booting when no default is set, since it offers the boot menu (might be covered by boot menu)
• Reset TPM/TOTP/HOTP
• Maybe GPG menu?
• Anything else?

There is a lot of overlap with RB, and I can imagine probably future features will refine this policy even more. I wonder if we could structure it around some sort of security policy, where operations indicate what functionality is trying to be accessed, and we evaluate a policy to see if that is allowed based on the current config and authentication.

E.g. some operations could be:

Operation	Description	Normal	Restricted boot	Tamper prevention
Boot default	We assume this has some form of protection already before granting access	Allowed	Allowed	Allowed
Configure policy	E.g. change RB / TP / other relevant settings	Allowed	Prevented, except disabling RB	Requires auth (?)
Boot menu	Recovery shell boot could tamper	Allowed	Allowed	Prevented (?)
Tamper	Totally unrestricted access like flashing firmware / recovery shell	Allowed	Prevented	Requires auth
...	Others?	?	?	?

So, e.g. if you are about to show the boot menu, call check_policy boot_menu, and check_policy would evaluate the configuration of RB / TP, authenticate if needed, etc.

Otherwise I think embedding the business logic for each of these into the scripts actually doing the work could quickly get out of hand, and we would end up with a lot of holes.

☝️ Edit: again here, if we just drop in two gpg_auth calls in two places that's probably OK initially, but I don't think we should go sprinkling in much more than that in the long run, RB probably already has too many carve-outs scattering its business logic.

[JonathonHall-Purism]

Thanks for copying my thoughts here @tlaurion !

I think this is a great feature, but I think the name "GPG authentication" is vague. For example, /boot is authenticated with GPG, but that is not part of the "GPG authentication" feature. "GPG" is also (IMO) how the feature is accomplished, not the goal itself, and we could change it in the future if something solves this problem better than GPG (hypothetically).

Since the goal is to prevent tampering by authenticating the user in some circumstances, what about "Tamper Prevention" or "User Authentication"? Those are both distinct from Heads' normal mode of operating (which detects but does not prevent tampering, and which authenticates the computer to the user, not the user to the computer).

With that said perhaps "Restricted Boot" should be revisited too to distinguish it from this feature. It does restrict what the computer will boot, but the goal of that feature is to ensure that booting anything unsigned creates evidence of tampering, not to prevent it outright (RB can always be disabled, which itself creates evidence of tampering).

[Oessel]

Just a little comment, first, i want to thank everybody who is involved for the hard work, your doing great stuff! And second, i like the new feature with a master signing key as encrypted Backup, because now i can use the good, old RSA keys on nitrokey 3, the device can store up to 4096bit key length only generation on the device is currently limited. I don't like the NIST ECC algorythms very much, or am i ignoring an important feature oft them?
Greetings from Germany!
Ößel

Edit:
And i added the variable RSA_MASTER_KEY_LENGTH=4096 in the factory reset script, otherwise all keys are generated with 3072 bit length

[headscontrib]

Hi, following up on that point!

As of today, I'm a little lost into the relationship between RB and gpg_auth. Overall, I'd like to be able to use gpg_auth to ensure that noone else can boot the computer or flash the firmware with having to open the machine.

RB

RB prevents the following without TOTP being wiped:

• Flashing/updating the bios
• Accessing recovery shell
• Unsigned Isos

RB allows booting from signed ISOS (arch...) and modify configuration options (except flashing firmware).

Additionally, RB can be disabled, even though you'll know it later on.

GPG AUTH

Gpg_auth ensures prevents unauthenticated user to:

• Access recovery shell
• Boot from any external media

But anyone can flash/update, use unsafe boot and change config options.

Ideas

What about requiring GPG_AUTH to :

• flash/update firmware. This will prevent attacks that mimicks PCRs value.
• access to boot menu to make sure no one can use the unsafe boot option.
• OEM reset should also be protected, as someone could reset and boot what she wants?

This will make GPG_AUTH at least as secure as RB (regarding the flash procedure) and seems easy to do?

Questions

I'm not sure about the use of gpg_auth for the following regarding the objective set to to ensure that noone else can boot the computer or flash the firmware with having to open the machine.

• Changing config settings: I'm trying to figure out which one would be necessary to prevent.
  - update checksums and sign all files?
  - edit idea: if unauthenticaded flashing is not allowed, should we worry about changing config?
  - Edit bis: but one can still change config for the current boot without flashing.
• Reset TPM/TOTP/HOTP: should we worry about that?
• Maybe GPG menu: GPG modifications requires flashing, which should be prevented already?
  - Same thing here: what about current boot, even without flashing for next boot persistence?

However, we could simply enforce gpg_auth for nearly everything except default boot: this may simplify thinking and be worth it? In other words, what are the benefits of looking at every case if we can stick to something simple and secure? The question becomes: what actions need to be left unauthenticated?

Comments

Sorry if I'm a bit confused, this is a lot to think! But thank you very much for the hard work!!!

[tlaurion]

@headscontrib if you revisit discussion tofay, woukd you rewrite it?