'Reasonably Secure Hardware' (Stateless Laptop Progress & More)

This is a long thread relating to future hardware design for secure Mobile (Laptop) End User Devices.
The purpose is to create a start a discussion with the aim of gathering ideas for a possible future reasonably secure hardware framework for EUDs.

  1. Statelessness
    Not much seems to have been done here, such a shame. I would like to know, with current complexity of SSDs and future RAM (see OpenPower issues), is statelessness going to be possible (i.e: will it be unfeasible without new component standards specifically designed to enable statelessness)? In addition how could statelessness remain secure and user-friendly when we start to compartmentalise hardware (i.e. dedicated router) - can one ‘trusted stick’ be used for separate ‘computers’ in the same device?

  2. Compartmentalisation of Hardware

NSA mandates dedicated hardware routers for EUDs

The NSA via the CSfC program has publicly declared it does not trust the underlying hardware in EUDs for access to Black Networks. It thus mandates what it calls a ‘retransmission device’ - a dedicated hardware router, to be used to access such networks. The purpose is to ensure that, in case of EUD hardware compromise, the dedicated router continues to securely tunnel traffic protecting from eavesdroppers and safeguarding the network location of the end-user.

There is at-least one company I know of that has integrated this design inside the laptop chasis, see:


The Archon SideArm internal retransmission device (IRD) is a self-contained router (wired, wireless,
and LTE) integrated right into the Archon Zero Vulnerability (ZV) laptop. With its own processor,
memory, Wi-Fi chip, LTE chip, and separate firewalls for Wi-Fi, cellular, and Ethernet, Archon SideArm
relies on the laptop only for power.

The question here is, with our current knowledge - given the current insecurity and complexity of hardware (SSD and RAM essentially becoming mini-computers), which is only increasing - what mechanisms ought to be in place to compartmentalise these different components - thus what standard can we create? Joanna briefly mentioned integrating a ‘proxy’ into the trusted stick, see


Schedule 32. Chaos Communication Congress

Abstractly I would propose splitting the motherboard into standard form-factor isolated boards, with some-sort of dumb KVM switch connecting the keyboard and screen to each for management. The compute board would be conected via a standard high speed interface to the router board. Of-course with power-based hardware switches (for camera, microphone, speakers, network cards, etc) for when not needed.

This, however, is already becoming standard in implementations such as CSfC above, so I’m thinking what further is needed - and, how can it remain easily managable for the user (assuming an ‘advanced’ user, i.e. someone who is already ok using Qubes)?

I am trying to think of practical solutions for the future. Yes there’s RISC-V etc but if we want ‘reasonably secure’ then blindly trusting the CPU seems like a very bad idea. Thus, at the very least, to maintain security whilst using an external network a dedicated router is necessary.

  1. Passive Intercept/Logging
    Passive intercept/logging undeniably has a value in identifying advanced attacks. The question here is not how difficult it is, for it would be rather simple to do with today’s small form factor technologies. The question is, given a reasonably secure hardware design - how useful would passive intercept be?
    I can only think, assuming interfaces between boards/components/compute-devices are encrypted, the only real use of passive intercept would be post network-card transmission (i.e. passive monitoring of the U.FL cable for the wireless card, passive monitoring of the ethernet cable for the wired card). This would catch any comms not being securely tunneled*.

*Though, of course, it doesn’t stop the local access point names from being broadcast via the secure tunnel somehow in an encrypted format - passive monitoring would /enable/ any sort of metadata steganography to be caught and this is not a trivial attack.

An example ‘standard’:
Hot-swap NVME SSD drives with readonly switch

Easy removal of drives, quick destruction of data.

Standard form factor for router board, easily replaceable
Standard form factor for passive monitoring board, easily replacable
Standard form factor for network cards
Two wireless network card M.2 slots with C.FL/U.FL to SMA/external-connectors

(useful for SDR stuff, wireless pentesting).

Hardware (power-based) switches for:
Network cards
RAM wipe switch
Trusted Boot Port (for trusted stick - containing firmware and readonly partitions)
DUMB I/O switch (to switch between router/computer/passive-monitoring device management)

That’s a really high-level list of requirements, the purpose here is not merely to refine those - but to discuss how they would be technically implemented. (As above, i.e: passive tap on the C.FL and ethernet cables).

This has probably come out as a long ramble, my apologies, I don’t expect many to read, letalone reply.


I don’t have much to contribute, unfortunately. Just wanted to add here a link to Joanna’s post that is very much related (I think).


Do you know of any advances since:


yes. heads is usable, yet still considered to advanced users: https://osresearch.net/
there are 2 company’s that sell laptops with heads installed (insurgo and nitrokey). T430 from lenovo (used)
You can buy a x230 or t430 and build heads rom and flash it.

1 Like

And Purism, their pureboot is just rebranded heads

1 Like

Pureboot is not rebranded Heads, it’s Heads + Coreboot + Neutralized ME + Librem Key

ok, my bad for the language. What I meant to say is that Pureboot is based mostly on Heads.
As for the other components of Pureboot, is it actually possible to use Heads without Coreboot? My x230 also has a neutralized ME and the the only difference I see with the L14 with Pureboot is that the librem key actually flashes instead of me having to manually check the TOTP every time. So basically, it is a good Heads configuration with a key that flashes.

1 Like

there are several tastes of heads you can choose, if you build, including (or not) integration with librem key or nitrokey. Meaning, you could buil yourself the ROM with the same feature.
You can even switch between them if you find advantage in one of them (except between maximized and non maximized ROMs)

@fsflover wrote:

Heads + Coreboot + Neutralized ME

Heads is a Coreboot payload, so they always come together. When building
HEADS/Coreboot one also neutralizes the ME for ones particular machine
(it’s part of the make/build process).

  • Librem Key

… or any other method like TOTP or Nitrokey. Librem Key BTW is a
rebranded Nitrokey. I find it entirely fair to call “pureboot” a
“rebranded HEADS”. What did they add that wasn’t there already?

That being said. Heads + Coreboot + Neutralized ME + Librem/Nitrokey is
awesome. :slight_smile:


I myself don’t even use all that (yet), but I suspect that they at least have been improving the UX and compatibility between all those things.

@Quser59 another great post with very important points (thanks for sharing info about Archon). My $0.02 would be that we have huge problem with user adoption of advanced hardware security. I already mentioned that on frame.work forum. We not only need hardware that give ability to build trustworthy systems, but we also have to do that in way that is acceptable by users. So far we have huge problems with that eg. please take a look about coreboot, heads, Qubes OS deployment procedures, UI/UX complains etc.

Having hardware that enables security is one thing, enabling security is other thing. What we see with Archon is that only gov level players can afford such stuff, and maybe only them have that threat model. Of course there is potential in digital currency environment to rise awareness, but still that would target rather infrastructure (good example is is 15k EUR pledge from Immunefi).

EUD market seem to be reasonably well handled by Arm presence on mobile market and I’m not sure if we can do anything with that. It maybe even not so bad for customers. Also if we consider ARM superiority to x86 (with maybe RISC-V and OpenPOWER being next in line), then it may happen we will get reasonably secure (or maybe stateless) hardware soon.

Finally, pushing all above very hard may mean wasted resources in face of massive capital that companies driving this business. 3mdeb always repeat we should not underestimate connections between SV, IBV, ODM or OEM unless we can, or partner with someone who can, offer something competing.