What is Heads

Heads is a secure runtime environment and a build system; a build recipe cookbook, which boards configurations instructs which modules to be incorporated in the mix needed for specific platform board configuration.

Heads takes advantage of the linux kernel and common linux tools to create its runtime environment, including kexec, busybox, whiptail, cryptsetup, flashrom, LVM, the GPG toolstack, and other important and already existing tools to empower its runtime environement.

The typical output of a build are a packed initramfs and kernel, included inside a coreboot ROM image as its payload. Depending on the architecture/chipsets of a platform, it also integrates neutered/deactivated Intel ME/CSME binary blob (platform dependent), generated Gigabit Ethernet (GBE) configuration blob and an unlocked descriptor (IFD). The produced firmware images requires the platform to be flashed once externally to overwrite the origin flash chip(s) content, more specifically to overwrite locked IFD and ME/MCSE regions and to maximize the BIOS region to the extent of liberated Intel ME firmware region. Heads firmware upgrades can then happen internally for the lifetime of the platform.

Why Heads

Heads take advantage of coreboot measured boot in Static Root of Trust (SRTM) mode as a measurement base, which currently measures itself as early as possible, normally from bootblock(or romstage) into TPM a singleregister (PCR2). Heads payload is then executed after measured and extends TPM with its own measurements in distinct PCRs in the goal of sealing secrets in TPM's distinct NV regions. Kernel modules are measured prior to being loaded, LUKS drive(s) headers are measured if a TPM disk encryption key is configured, while going to the Recovery shell invalidates the TPM measurements by the same TPM extend mechanism.

From a user standpoint, those sealed secrets enables oneself to validate the integrity of the firmware either through TOTP code shown on screen on its smartphone or through HOTP (which challenges validity against supported enabled HOTP USB Security dongles). Another TPM sealed secret enables the user to release an additional LUKS disk encryption key only if the firmware is intact, that kernel modules loaded and Headers are consistent to sealed state and only if provided passphrase matches. Heads also validates user detached signed /boot digests against its fused in rom public key, which guarantees both integrity and authenticity of the trusted boot configuration prior of kexec’ing into it.

A lot happened since 2020... Let’s cover current state and where the project is heading!

What’s new?

• Maximized boards vs Legacy boards, or how to dodge blob redistribution legal limitations
• Whiptail/FBWhiptail: one graphical interface (GUI) to rule them all!
• OEM Factory reset/Re-Ownership wizard upstreamed
• QEMU/KVM board configurations with swtpm and USB Security dongle support to ease development/testing

What's next?

• TPM2 support on QEMU/KVM and SWTPM.
• A better build system to guarantee reproducible builds based on NixOS if everything goes well...
• Clean room, in ram GPG key generation with backup/restore/USB thumb drive emergency usage capabilities from encrypted LUKS container to restore GPG key material on USB Security dongles upon replacement reception/acquisition later on (No more USB Security dongle strong requirement to use Heads while still highly recommended).
• Authenticated Heads recovery shell, USB boot and more!
• Finally: flash write protection options!
  • Platform chipset locking (only Heads can flash firmware)
  • SPI Write protection, permitting to write protect coreboot’s bootblock region (requires external flashing when coreboot version bumps happen under Heads. For the most paranoid only!)
• International keyboard support
• On demand MAC randomization inside of Heads, overwriting GBE region inside of firmware. Persistence across firmware upgrades.

References:

• Differences between linuxboot, Heads NERF
• Heads conference (Hudson, 33c3, 2016)
• Linuxboot conference (Hudson, 34c3, 2017)
• Heads: a call for collaboration on producing more trustworthy systems locally (Laurion, FOSDEM, 2020)
• Coreboot measured boot, SRTM mode (coreboot doc)
• Heads current measured boot scheme (Heads doc)

Project homes

• Heads searchable documentation
• Heads project's home (GitHub code/features/issues)
• Heads documentation's home (GitHub documentation/issues)
• Heads community direct link

Insurgo had engaged itself in the adventure of facilitating security accessibility and received NlNet funding to do exactly that. Now it wants to get developers involved and expand funding.

The goal of this is to bridge the gap between reasonably secure OS (QubesOS) and slightly more secure hardware (Heads) to help privacy-focused users and those that are vulnerable. But we need to prepare for the future now!

Insurgo has challenged the status quo that has been prevalent since 2015 and has made it possible for OEMs to preinstall QubesOS, thanks to the Heads Open Source Firmware (OSF) and his own PrivacyBeast QubesOS certified branch, not yet merged upstream, due to the lack of time and resources of a single man effort needing additional collaboration.

The integrity of the firmware and boot files is already remotely sealed and can be attested over smartphone (TPMTOTP) and from the bundled Librem Keys/Nitrokey Pro 2 (HOTP), prior to shipping. Thanks to HOTP-enabled USB security dongles bounded to shipped products, the user can visually validate that the hardware they've received is in OEM attested state, prior to complete reownership which is regenerating all required secrets from a trustable recovery environment (Heads OSF) thanks to a re-ownership wizard that guides the user until completion.

This is just the beginning of the adventure and the road ahead requires your help. Insurgo wants to propel this movement forward.

Today's secure hardware (REAL open source initialized hardware, eg. the RYF KGPE-D16, replicant supported phones, Sandy bridge/Ivy bridge based boards, eg. x230) struggle to stay current with upstream code and compliance requirements. LineageOS dropped support of the i9300. Coreboot dropped support of the KGPE-D16 platform. And the list will expand if no measures are taken to support maintainership of privacy focused projects that are taken for granted until support is finally dropped. This is a real problem requiring real solutions.

New efforts to support future, REAL Open Source Hardware (newly Respect Your Freedom [RYF] certified hardware, eg. Talos II from RaptorEngineering, future Power10 based hardware) are neither currently under active development nor currently supported by QubesOS. This needs to change. Now.

There is an opportunity for transition. This requires leadership, developers and funding. This is why we've created the Insurgo Initiative on the OpenCollective platform.

This is where transparent funding will be available to the public for open source R&D. Please consider participating through code contributions!

Insurgo is making today's most trustworthy hardware available (TRUELY Neutered+Deactivated Intel ME, no FSP, no binary blobs whatsoever but EC firmware in the Root of Trust) to the masses through remote attestation over Heads OSF.

NlNet is helping Heads to be compatible on the T530, T430, T420 and X220, which are widely available, binary blob-free hardware platforms, thanks to a partnership with 9elements under NlNet grant. NlNet funds is also permitting development of remote administration of QubesOS over tor hidden services when needed, thanks to an ongoing partnership with both the Qubes OS Project & Whonix.

But what about other work needed to ease accessibility of tomorrow's secure hardware and technologies?

Insurgo decided to give back to Open Source Firmware (OSF) related communities and will publicly announce novel approach to support required open source projects. In premiere, we plan to give back 25% of Insurgo's net profit on sales to the Insurgo Initiative, hosted on OpenCollective.

Those funds will be available to Open Source projects in the form of bounties, to be paid out upon proof of work of agreed contributions.

The idea here is that open source tickets (issues) can be used as bounties and if knowledgeable people knew funds were available for needed work, they'd be more incentivized to address them. Developers could then be rewarded for their efforts and paid for completing tasks similiar to how Open Source Funds (OpenTech, NlNet, etc) provides funds for larger projects.

The Insurgo Initiative will be self funded and potentially expanded through international partnerships, while the goal stays the same: supporting a future where security is more accessible to the public.

Here are some projects needing additional funding and more developer awareness, right now. Big funds and grant application are great. But the funding process has issues. Not every developer wants to go through the application process, which requires management skills and requires a process that is not just about coding. There are awesome developers out there whose help would be greatly needed.

How do we appropriately match developers with pertinent issues? We can fix this with the right mission and funding. Insurgo's mission is for accessible security.

Bounty tags are being added to projects that lack the funding and to help address the current problems they face for completion:

• PPC64le QubesOS support for upcoming Power10 laptop and Talos II RYF hardware

• Heads needs more community developers and maintainers

• QubesOS bounty tagged issues

• Whonix needs more collaborators or it might die

The main problem we seem to face with many projects can be seen over and over again: a lack of maintainership.

No one can carry on a project for too long without becoming overwhelmed/drained by it. We need to fairly distribute this work and make sure contributions are incentivized and fairly paid.

In this talk, I will go quickly over past work. The current situation. And where Insurgo wants to go.

Welcome aboard!