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

Adding cryptsetup-reencrypt support. First step into getting OEM predeployed QubesOS machines #464

Merged
merged 1 commit into from Nov 7, 2018

Conversation

tlaurion
Copy link
Collaborator

@tlaurion tlaurion commented Oct 8, 2018

This addition permits deployment of customized OEM shipped QubesOS deployments.

The idea behind this is to be able to deploy preinstalled QubesOS trusthworthy machines and permit remote support over them on demand. This is an attempt to relaunch the idea behind QubesOS librem OEM install disk, but this time, including the deployment of a second AdminVM, permitting remote management, by a third party, on demand, through a tor hidden service. This onion hidden service is only available to remote management when both hidden hostname and attached public key are shared, and can be revoked at any time, while the AdminVM needs to be launched to permit remote management as a whole, leaving the user able to bypass and control that AdminVM deployments through dom0, on which the user controls everything. The Admin is an helper, not a complete machine owner: the user is the only one being truely in control of the system the whole time.

To do so, that second AdminVM, remotely SSH manageable through an hidden tor service would permit additional persona deployments through customized salt recipes.

The actual unresolved problem with OEM deploying QubesOS offline and not before user's eyes is that the user doesn't own his LUKS encrypted volume with delivered laptop. By using cryptsetup-reencrypt through Heads, the volume is reencrypted with user's keys upon reception and denies OEM responsibility of knowing LUKS original encryption key.

Even with SSD deleted pool related risks, the only data previously written to disk with precedent encryption key would be templates and base VMs deployements being deleted (deleted pools), so there is no real risks. Reencrypting a 240GB SSD drive takes 25 minutes from the user to really own his laptop, which IMHO is not a real problem considering the gains.

Heads' advanced menu could now include an option to reencrypt the LUKS encrypted volume.

The use case this fits in is:
OEM preparation of laptop and LibremKey/Nitrokey Pro V2:

  • Possibility to create a QubesOS OEM disk images that would deploy remote-mgmt-AdminVM (basic idea here) which would replace QubesOS librem OEM install disk
  • Possibility for the OEM to clone that resulting QubesOS disk to other machines disks without security risks.
  • Flash Heads on hardware, including GPG2 support.
  • LibremKey/Nitrokey Pro 2 is paired with laptop for measured boot firmware and boot integrity attestation.
  • LibremKey/Nitrokey Pro 2 and laptops are shipped in different packages/different shippers to client

Client ownership:

  • Client boots received hardware with received Librem/Nitrokey Pro 2 connected.
  • Client validates attested integrity (green lights on the LibremKey/Nitrokey) and then owns his Librem/Nitrokey Pro 2 GPG smartcard from within Heads recovery. He generates/import his keys with the help of GPG2 from the Heads recovery, once.
  • Client reencrypts his LUKS encrypted volume with his own passphrase, from Heads recovery, once.
  • Client owns hardware TPM, signs his configs with his LibremKey/Nitrokey Pro v2, sets a default boot entry and defines a boot TPM bound decryption key into LUKS slot 1 through Heads enrollment (when fixed and merged)
  • Client boots default config, changes his QubesOS user password from within QubesOS, once.

Client support:

  • Client in need fires up remote-mgmt-AdminVM on demand/at boot and asks for support to his OEM through predefined support channels.

Client is happy with his trustworty hardware and is feeling supported if in need.

@tlaurion
Copy link
Collaborator Author

@kakaroto @flammit @mfc @osresearch @kylerankin: Please challenge this idea ASAP.

@kylerankin
Copy link
Collaborator

@tlaurion I'm personally fine with allowing luks re-encryption. One approach we are working toward was using the Librem Key for decryption by adding OpenPGP smartcard support to LUKS. We are currently working with Debian toward this goal: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903163

How do you think this approach would mesh with yours?

I'd love to have an OEM-ready Qubes installer. The challenge with Qubes OEM images in the past was having resources with the expertise to build it. The Qubes team could do it but you would need to be willing to set up a consulting agreement with them and fund the effort.

@tlaurion
Copy link
Collaborator Author

@tlaurion I'm personally fine with allowing luks re-encryption. One approach we are working toward was using the Librem Key for decryption by adding OpenPGP smartcard support to LUKS. We are currently working with Debian toward this goal: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903163

How do you think this approach would mesh with yours?

Perfectly :)

I'd love to have an OEM-ready Qubes installer. The challenge with Qubes OEM images in the past was having resources with the expertise to build it. The Qubes team could do it but you would need to be willing to set up a consulting agreement with them and fund the effort.

Apart from reencrypting OEM deployment from Heads, I think the solution would be to permit deployment of additional salt recipes in QubesOS installer's second stage. By permitting to import them from a USB key, OEM customization would be possible:

@kylerankin : What you think?

@tlaurion tlaurion changed the title Adding cryptsetup-reencrypt support Adding cryptsetup-reencrypt support. First step into getting OEM predeployed QubesOS machines Oct 17, 2018
@osresearch osresearch merged commit 1d2fb02 into linuxboot:master Nov 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants