OEM-> User transfer of devices ownership wizard, triggered by the presence of an empty /boot/oem file

[tlaurion]

UPDATE: see QubesOS OEM to user transfer of ownership below for current state.

Advanced menu addition:
GPG card: factory reset, set key-attr to 4096bits, set passwords, generate keys, remove old keys from rom and insert public and trustdb back, and flash it.
Cryptsetup-reencrypt: reencrypt device and change recovery disk passphrase.

Please review. This is first draft. Everything works but it could be more beautiful and menus should probably be seperated.

@kyle: I was thinking of a oem file being present under /boot to engage a wizard or something.

[tlaurion]

@kylerankin : Not ideal. Suggestions?

[tlaurion]

@kylerankin @flammit : please comment and suggest improvements in the functional code.

TODO:
For the OEM GPG part, I was thinking about asking input all at once to the user and store the results of input under /tmp/secret/ files:

• gpg_card_user_password
• gpg_card_admin_password
• gpg_card_full_name
• gpg_card_email
• gpg_card_comment

And create subfunctions to create only one task, taking input from those /tmp/secret files if present, else ask for the information from the console for each of the actions ( Set user and admin passphrases and generate keys).

And then create different Whiptail menus for:

• factory reset and set-attr
• generate keys and import public and otrust
• metamenu to call encompass them

For the drive reencryption code, I was thinking into splitting actual code into two submenus:

• LUKS container reencryption (uses current Recovery passphrase and reencrypts everything)
• LUKS Recovery key passphrase change
  And then create a meta menu that can do both manually, while oem code calls the functions directly.

[itay-grudev]

We need to remove the two CONFIG_GPG=y lines in the Librem config files. When I added the CONFIG_GPG2=y lines I wasn't sure if the old one should be removed or not, so I didn't do it.

[tlaurion]

So at this point, here is what we have. I know, I need a better camera. That will happen soon. :)

OEM/tech-savvy user common parts:

• Generate Heads ROM ( in the case of x230: make BOARD=x230-flash && make BOARD=x230). And flash it externally to hardware.
  • x230: Backup 4mb SPI flash chip, reflash x230-flash Heads rom on it, Backup 8mb SPI flash chip, apply me_cleaner on it and reflash it externally.
  • x230: On first boot of x230-flash Heads, mount-usb && flash.sh /media/coreboot.rom (12mb rom generated with make BOARD=x230)
• On first boot of Heads, the user is given an error that Heads couldn't find any GPG keys in the keyring. He is invited to Add a GPG key to the running BIOS from a USB drive if the GPG card was preowned externally, or to Factory reset, own GPG card, generate and add key into running BIOS to do the whole process from inside of Heads, with generated key and trustdb being backuped onto USB drive under gpg_keys directory for further use, before taking a backup of running rom, deleting actual user keys found in it, and injecting generated public key and trustdb into that rom prior to flashing it back into SPI flash internally.
  
  • The GPG generated public key is valid for one year and that validity can be extended by the user. The key /gpg_keys/public.key can be published online and is a 4096 bits RSA key, ready to use, combined with it's private key, secured inside of the GPG card. By selecting Factory reset, own GPG card, generate and add key into running BIOS, the user also injected otrust.txt (trustdb: trusted keyring) inside of the rom, which is imported at each reboot, ultimately trusting generated user key.
• On next reboot, the user/OEM is warned that Heads couldn't generate the TOTP code and is invited to Reset the TPM if he didn't own it yet with its own passphrase, or to Generate new TOTP/HOTP secret, to seal BIOS integrity attestation measures into the TPM and into GPG card with its previously chosen admin password.
  
• At this point, the BIOS attestation with HOTP/TOTP is done and any modification done to it will detected. Here is a video demonstration of the user experience of LibremKey/Nitrokey Pro v2 in practice.
  
• OEM/User then installs QubesOS from Heads (Whiptail) from Advanced Settings-> Other Boot Options -> USB boot which validates integrity of the ISO with companion .asc downloaded checksum signed file, while Heads validates that checksum authenticity with Heads included distro signatures keys
  
  
  
• On next reboot when the OEM/user will attempt to select a default boot option from normal boot menu, he will receive an error saying that The file containing hashes for /boot is missing and will be prompted to update the checksums and sign them with his GPG card and linked user chosen password (PIN).
  
  
• On next reboot, the user/OEM will be prompted to select a default boot option and Make it the default. By doing so, the user/OEM will enter Disk Recovery key passphrase chosen at OS installation, and will be prompted to choose a distinct Disk Unlock key, that will be released in LUKS slot 1 (instead of slot 0 by the Recovery Key) by the TPM only if it attests BIOS integrity. This is important for data privacy. By doing so, even if the user is filmed typing its Unlock disk passphrase (instead of typing otherwise his Disk Recovery Key), an attacker would only be able to access the disk content on this computer, and won't be able to clone that disk content and use that same passphrase to unlock it. Consequently, if the BIOS is tampered with/upgraded/modified, attempting to boot the default boot option while typing Disk Unlock Key passphrase won't work, which is an additional safeguard against external tampering.
  
  
  
  
  
  
  

OEM specifics:

• After having done all the previous steps, the OEM enters recovery shell and enters: mount -o remount,rw /boot && touch /boot/oem && umount /boot && reboot
• The OEM then ships the GPG card and computing hardware separately.

OEM-> user devices transfer of ownership:

• The user plugs in the LibremKey/NitroKey Pro v2 and boots the hardware and gets the following:
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

@marmarek @mfc @andrewdavidwong @kylerankin @osresearch @flammit : Your input would be more then welcome. I'm going to use this PoC as it is for a start, but would love it to be mainstreamed and merge efforts to ease remote support of users.

This seals my PoC to go forward with the QubesOS Hardware Certification.
I await from you guys what kind of partnership/collaboration can be constructed to facilitate QubesOS adoption to a larger user base, mostly those who really need it.

[tlaurion]

replaced by #511