Adding cryptsetup-reencrypt support. First step into getting OEM predeployed QubesOS machines #464
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
Client ownership:
Client support:
Client is happy with his trustworty hardware and is feeling supported if in need.