User reownership of OEM shipped hardware wizard, based on /boot/oem file presence #511
Conversation
To help with onboarding new users to Heads, this change will detect when Heads does not have any keys in its keyring and will guide the user through adding a key to the running BIOS. It's important that this happen *before* guiding them through setting up an initial TOTP/HOTP secret because adding a GPG key changes the BIOS, so the user would have to generate TOTP/HOTP secrets 2x unless we handle the keyring case first. In addition to this change I've simplified the main menu so that the majority of the options appear under an 'advanced' menu.
We want to catch the missing GPG keyring error regardless of TPM failure or even in the case of a system without a TPM at all so we need to move that section up above the TPM check.
The Librem coreboot is labeled with the current version and is visible from dmidecode and is supposed to reflect the current version of coreboot, however it was out of date and reflected 4.7 when Heads has moved on to 4.8.1. I've also added a simple change to further simplify onboarding by warning users who have Librem Key configured when they boot without it being inserted.
…lly work, tools and libs updated to latest versions
…ty is used to enter passphrase. Else, gpg complaints of not being able to open /dev/tty, even though GPG_TTY environmenent variable is forced in init
…lled; trying to get console tty from the tty returns "no console". NEEDs BETTER FIX.
gpg2 needs GPG_TTY set to function properly. We set it in /init so it is inherited by all children. The call to $(tty) must be after /dev and (preferably) /dev/pts are mounted. Signed-off-by: Jason Andryuk <jandryuk@gmail.com>
… rom .ash_history: add examples to generate keys and otrust in rom flash-gui: export otrust and import it in rom key-init: import otrust.txt if present to supress warning about user public key being untrusted
else: make[4]: Entering directory '/home/user/heads/build/pinentry-1.1.0/qt' g++ -DHAVE_CONFIG_H -I. -I.. -I//include -I//include -I.. -I../secmem -I../pinentry -Wall -I/home/user/heads/install/usr/include -I/home/user/heads/install/usr/include/QtCore -I/home/user/heads/install/usr/include/QtGui -DQT_SHARED -g -O2 -MT pinentrydialog.o -MD -MP -MF .deps/pinentrydialog.Tpo -c -o pinentrydialog.o pinentrydialog.cpp In file included from pinentrydialog.cpp:24: pinentrydialog.h:27:10: fatal error: QDialog: No such file or directory
…ing_detection-Factory_reset_option
gui-init: Adds file selector, LUKS reencryption and GPG factory reset option.
tlaurion
force-pushed
the
oem_reownership
branch
from
ede3bb9
to
9396556
Compare
GPG factory reset: -Simplified USB Disk confirmation prompt in GPG card factory reset. -Aesthetic correction (spacing)
tlaurion
force-pushed
the
oem_reownership
branch
from
9396556
to
571c8f4
Compare
|
@marmarek @mfc @andrewdavidwong @kylerankin @osresearch @flammit : Here is how the actual reownership looks like from a UX perspective. The OEM:
Once the user receives his hardware, he plugs the GPG card in the hardware and boots. He gets the following:
|
no gpg
|
Is it correct that attacker that intercept both laptop and nitrokey could forge integrity protection? If so, it may be worth adding (optional) extra measurement - for example let the user send their public key and provide back encrypted HOTP/TOTP secret, so it would be possible to verify platform integrity with yet another tool. Since the secret is reset during re-ownership process, it shouldn't be such a big problem that it ever leaved measured environment (of course as long as attacker wouldn't be able to extract it too). Another thing to verify here - OS (especially unverified one), even when booted with unmodified firmware, should not be able to extract TOTP/HTOP secret. This apply to both RAM (all copies of the secret should be wiped from RAM before booting OS) and also unsealing it again from TPM. One way to achieve the latter would be extending relevant PCR with xen+kernel(+initrd?). Maybe it's already there? |
I really like this suggestion. Are there step-by-step end user instructions that customers would follow? I'd like to put myself in the shoes of a security-minded potential customer and go through each step of the process to see whether there are any red flags from that point of view. (E.g., "This step leaves me vulnerable to interdiction," or "This step requires unnecessary trust in a third-party." It could be that there are already security measures in place to guard against these things, but potential customers may not be aware of them or understand them.) |
|
@marmarek First of all, sorry for the delay answering. So we talk about a couple of things here that should be addressed separately as necessary.
The Firmware integrity/boot configuration cannot be compromised without the user knowing. So even if both the LibremKey and firmware were compromised (we will get into that later), the user can still attest integrity by the laptop alone and it's TPM. The HOTP seal is implemented in TPMTOTP and depends on the TPM measurements. On hardware that doesn't provide a TPM (which is not the case here by board configuration) the HOTP measurement is currently based on checksumming an internal SPI dump. To make it short, HOTP is just an easier way of confirming integrity by inserting user's GPG Card and validating green LED flashing instead of manually validating the TOTP code on his phone. Additionally, when the user sets a disk unlock passphrase, TPMTOTP attestation is done without him knowing, since the integrity measurements need to be valid to release the key to be used as an additional initrd file. As for the possibility of compromising both the firmware and the GPG card, it is near impossible and don't see how it could be possible without user knowing. The OEM's public GPG key inserted into the ROM is generated on the GPG card and is bound to it for signing operations. That public key fingerprint is shown to the user at each boot. Factory resetting the key would wipe the keys present in the card and reinject a public key different then the one provided by OEM. Any modification to the firmware would change the PCRs measurements and invalidate HOTP/TOTP integrity measurements, and the TOTP and HOTP unsealing would fail. The user has only 3 bad attempts before the card locks user's/admin's individual PIN operations from the card, after which he would have to factory reset the card, which would change inserted user's public key in the rom, invalidate files signature validation and inform the user of compromise.
The sealing of HOTP/TOTPM is an operation that requires to reboot. Every time the user attempts to enter recovery, files are deleted. They could be shredded I guess, since the ramfs is not journalized. You think it would be required? |
|
I will update this PR once the staging branch is considered stable. |
@andrewdavidwong : The user is guided through a wizard for reownership. I could definitely do screenshots in a guide if that is considered required. |
Ok, this was the part I missed. Looks good.
Maybe, depending how ramfs (tmpfs?) implements file removal, but I guess the actual content stays in RAM, until used for something else. And the same before booting the OS (especially the one from USB). |
As a potential customer, I would consider it required. I think that most customers will want to know what to expect and to understand what they're actually buying. I think that the guide should begin when the user actually places the order or, at least, before the package is received. It would be nice to have some assurance that the entire package wasn't replaced with a malicious one, for example. |
@marmarek : From what I get, rootfs, is an instance of tmpfs by default:
So in our case, So the secrets of concern are the one happening when sealing/unsealing: Since we use tmpfs, it seems that using shred would do the trick, and is compiled in busybox. So basically, it would be to replace
@marmarek : shredding instead of removing secret related files would address your concerns? |
|
(design considerations for future work on platform security lifecycle management, please let me know if there's a better place to post this) There are supply chain management and support scenarios where an enterprise customer with geographically distributed offices would like new devices to ship from the OEM to a local support consultant that is trusted to install or replace a device at their local office. This reduces the need for IT staff (who may not exist at a small office) to provision devices. It also provides a business model for local consultants to develop expertise in platform security for customized enterprise workflows. Topics to consider:
|
@stacktrust Those are all really interesting questions that all seem more linked to QubesOS then linked to this particular pull request. One thing I tried to push to address most of your points is to implement an additional remotely manageable AdminVM.. The idea behind this is that an additional on-demand remotely manageable AdminVM would have permissions over a really limited and precise scope (deploy additional templates and salt recipes to create and manage additional qubes, that would solely depend on deployed templates, not the one deployed and managed through dom0, while dom0 could still have control over templates and qubes deployed by additional AdminVM). It's not possible right now, so the remote manageability that would be possible right would be to give dom0 access from an onion hidden service, with all dom0 access that comes with it; requiring a total trust to a 3rd party from the user. That is not really seducing to me. You are more then welcome to open that ticket on QubesOS github issues tracker |
@tlaurion Thanks for the helpful pointers. We did some preliminary work in http://OpenXT.org to support multiple admin VMs: one per "virtual platform" = group of VMs and related policy, with a dedicated VPN or network path to the remote mgmt server. E.g. OpenXT has a file transfer mechanism (https://github.com/OpenXT/icbinn which uses Xen v4v/Argo) to allow an admin VM to deploy multi-gigabyte virtual disks to dom0. The access control pieces are not yet implemented to isolate admin VMs. I'll look at SaltStack and QubesOS admin VMs to see if there is overlap in goals/approach. |
(editorial tangent ahead ... ) QubesOS, XenClient, Moka5, Virtual Computer, OpenXT, Bromium, Hysolate and Windows Sandbox enabled multi-VM endpoints. The next step is multi-MDM (mobile device management). Microsoft 365 is moving towards a single subscription price that covers the device hardware lease, Windows license, Office license and security updates. Microsoft Azure Sphere IoT device purchase price includes a license to 10 years of Linux security updates, i.e. remote OS management even if the device/app vendor goes out of business. This mgmt isolation was baked into Sphere silicon, OS and app packaging design for IoT/edge. The boundaries between OEM firmware, OEM factory image, OS vendor updates, OS-mandated app store and owner-managed enterprise apps are evolving. Users are one remote update away from a workflow-impacting (feature, security) change. As supply chain complexity increases, these remote parties will need to be isolated, granted minimal permission, and monitored by the owners of endpoint devices. |
|
Will make a PR including just the changes related to the reownership process and force push. |
|
replaced by #551 |
EDIT: I will update this PR once the staging branch is considered stable. Staging builds can be downloaded here.
Straightened #507 replacement.
Depends on #510. Fixes #475.
Modifies this PR (Empty Keyring Detection) to interact directly with /boot/oem file, dropped in place by the OEM once TOTP/HOTP firmware is sealed and /boot files are signed with OEM's owned LibremKey/NitroKey Pro v2. The OEM then ships the devices separately.
As a result, QubesOS or any other Linux distribution can be preinstalled and firmware and boot integrity is attested at first boot by the user received OEM hardware. He then reowns the hardware himself by reencrypting encrypted drive (LUKS container), reowning the TPM, reowning LibremKey/Nitrokey Pro v2, and recreates /boot checksums and sign them with his newly reowned GPG card prior to first booting preinstalled OS.