config: T4919: Add support for encrypted config with TPM

[sarthurdev]

Change Summary

PR to implement how a TPM could be used to provide hardware backed encryption of the /config data.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Code style update (formatting, renaming)
• Refactoring (no functional changes)
• Migration from an old Vyatta component to vyos-1x, please link to related PR inside obsoleted component
• Other (please describe):

Related Task(s)

• https://phabricator.vyos.net/T4919

Component(s) name

config

Proposed changes

• Add module vyos.tpm for interacting with TPM device.
• Add encryption op-mode commands:
  • encryption enable generates an LUKS encrypted volume and stores one key in the TPM and also provides a recovery key to the user. /config contents is migrated to the volume and is mounted over /config.
  • encryption disable takes either the TPM key, or prompts for a recovery key to load the volume (if volume not already mounted), migrates config data to /config on rootfs and clears the TPM and removes volume.
  • encryption load allows for loading the encrypted config volume if VyOS failed to decrypt the volume on-boot.

Related PRs:

• config: T4919: Add emulated TPM encryption test vyos-build#297

How to test

Success boot message:

[   27.987068] vyos-router[1114]: Waiting for NICs to settle down: settled in 0sec..
[   31.555678] vyos-router[1114]: Mounting VyOS Config...done.
[   34.480597] vyos-router[1114]: Mounted encrypted config volume
[   39.571402] vyos-router[1114]: Starting VyOS router: migrate configure.
[   40.017721] vyos-config[1124]: Configuration success

Failed boot message:

[   19.619459] vyos-router[1008]: Waiting for NICs to settle down: settled in 0sec..
[   23.399971] vyos-router[1008]: Mounting VyOS Config...done.
[   23.797441] vyos-router[1008]: ERROR: Failed to fetch encryption key from TPM. Encrypted config volume has not been mounted
[   23.799499] vyos-router[1008]: Use 'encryption load' to load volume with recovery key
[   23.800669] vyos-router[1008]: or 'encryption disable' to decrypt volume with recovery key
[   35.614991] vyos-router[1008]: Starting VyOS router: migrate configure.
[   36.577641] vyos-config[1017]: Configuration success

(Note: configuration success because VyOS default config.boot is created and loaded)

Installing from ISO over an existing install with an encrypted config:

Install the image on? [sda]:

This will destroy all data on /dev/sda.
Continue? (Yes/No) [No]: yes

Looking for pre-existing RAID groups...none found.
Looking for config files from previous installations on sda1...
Looking for config files from previous installations on sda2...
Looking for config files from previous installations on sda3...
I found the following encrypted config volumes on sda3:
  1: 1.4-rolling-202301032140
Would you like to save config volume from it? (Yes/No) [Yes]
Saving config volume from image 1.4-rolling-202301032140.
Done.
How big of a root partition should I create? (2000MB - 4294MB) [4294]MB:

Op-mode commands:

vyos@vyos:~$ encryption enable
Automatically generate a recovery key? [Y/n]
Enter size of encrypted config partition (MB):  (Default: 512)
Encrypted config volume has been enabled
Backup the recovery key in a safe place!
Recovery key: eJIlCbNm_nptQ_joEEMCqtc4vtoIQyaRLlG5G3lRTVQ=

vyos@vyos:~$ encryption disable
Moving existing /config folder to /config.old
Encrypted config volume has been disabled
Contents have been migrated to /config on rootfs

(Below was run after clearing TPM and rebooting with failed boot decryption)
vyos@vyos:~$ encryption load
Failed to read key from TPM, recovery key required
Enter recovery key: eJIlCbNm_nptQ_joEEMCqtc4vtoIQyaRLlG5G3lRTVQ=
Encrypted config volume has been mounted
Use "load /config/config.boot" to load configuration

Checklist:

• I have read the CONTRIBUTING document
• I have linked this PR to one or more Phabricator Task(s)
• I have run the components SMOKETESTS if applicable
• My commit headlines contain a valid Task id
• My change requires a change to the documentation
• I have updated the documentation accordingly

[c-po]

Can we somehow test this using a simulated TPM like smoketesting in QEmu?

Can we also extend it like on Debian by simply using a passphrase to encrypt?

[sarthurdev]

Can we somehow test this using a simulated TPM like smoketesting in QEmu?

Should be possible, will investigate and add smoketest if possible.

Can we also extend it like on Debian by simply using a passphrase to encrypt?

Do you mean allowing a passphrase to encrypt without using the TPM? If so, I'm not sure how we could implement the passphrase prompt on boot, using a TPM to store a key and have no boot interruption seems the best approach imo.

[andamasov]

virtual tpm available on VMware, not sure about quemu

[c-po]

Do you mean allowing a passphrase to encrypt without using the TPM?

Exactly

My requirement is like you get in Debian with an encrypted rootfs where you are prompted for a password on bootup from the serial/KVM console. I know this sounds stupid as it does not make the router reboot-safe but imagine a random cloud provider which only supports KVM access and no TPM - you still could encrypt your stuff.

One might ask what happens if the router crashes as it would reboot automatically - the answer is simple - it should not crash at all ;)

What you think?

[sarthurdev]

My requirement is like you get in Debian with an encrypted rootfs where you are prompted for a password on bootup from the serial/KVM console. I know this sounds stupid as it does not make the router reboot-safe but imagine a random cloud provider which only supports KVM access and no TPM - you still could encrypt your stuff.

I think best solution for that is to allow the encryption enable command to work without a TPM - just a recovery key, on boot it'll boot into VyOS with a default config, and you can then KVM/Serial in with default vyos/vyos login, use encryption load to load the encrypted volume and load the now decrypted proper config.boot

What do you think to that?

[zdc]

@c-po @sarthurdev is there anything that we can do to move this further? The feature is interesting.

[sarthurdev]

@zdc Haven't tested it for a while, Bookworm upgrade took priority recently.

I think we need to discuss some design choices for TPM support: how to handle image upgrades, default (and user-specified) criteria for verifying integrity, handling decryption failure (or is it up to the end user to ensure devices are reachable in event of failed config load).

I am also curious if #1768 is close to merge as it would make the install/upgrade aspect of this PR much easier to deal with.

[giga1699]

I am in agreement with @c-po on being able to manually enter encryption key, especially in virtual environments. There have been some documented instances of virtual hard drives containing data from a previous tenant. A malicious cloud employee could also steal the virtual drive if they thought the data on it was valuable.

While a memory capture could lead to encryption key exposure, it's a higher bar to attain than just pulling the virtual disk off the storage network. Would it maybe be prudent to have some kind of message about encryption passphrase use versus TPM use?

Things like crypto keys could potentially be stolen if the config were not encrypted at rest. While keys can be rotated, any previous encrypted traffic that may have been captured could then be decrypted with the old key.

It may be an annoying extra step for some to have to login to the console with the cloud provider, but it could be very beneficial for some threat models.

This would also set VyOS apart from many other networking platforms that generally don't do any configuration encryption at rest.

[dmbaturin]

Let's merge when 1.4 is branched off.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions]

Conflicts have been resolved. A maintainer will review the pull request shortly.

[sever-sever]

@sarthurdev Let us know if the task still in progress

[sarthurdev]

Will pick this back up after Kea implementation has most issues resolved.

[dmbaturin]

Can we put it under set, together with set system image default-boot?

[sarthurdev]

No problem, do you agree with set system encryption ...

[sarthurdev]

Only issue with using the set node, is then encryption load would need to move to a separate node. set system encryption load wouldn't really make sense.

[dmbaturin]

Maybe mention the TPM part explicitly? Manage configuration encryption using TPM

[sarthurdev]

I wasn't going to mention TPM explicitly as @c-po has requested that perhaps we can also accept encryption without a TPM, requiring a password instead on boot.