Framework Vault Module - V0 proposal

Creators & Developers Expansion Card
1

:locked_with_key: Proposal: Framework Vault Module

A user-owned, built-in hardware vault for keys, passwords, and digital identity

Summary

This proposal explores a Framework-compatible, internal hardware vault module designed to securely store cryptographic keys, passwords, and passkeys inside the laptop, without relying on USB dongles, vendor-locked TPM implementations, or cloud services.

The idea is not to replace TPM, but to complement or bypass it when needed, restoring user ownership over digital trust, in the same way Framework already restored ownership over hardware.

The current situation (and the gap)

Today, users typically choose between:

1. TPM-based security

  • Often closed firmware

  • Vendor- and motherboard-bound

  • Not portable across machines

  • Limited transparency and user control

2. USB security keys (dongles)

  • Easy to lose or forget

  • Occupy valuable USB ports

  • External, fragile, and not integrated

  • Often closed hardware or opaque firmware

3. Software password managers

  • Convenient, but ultimately host-compromisable

  • Rely on OS integrity

  • Increasingly cloud-dependent

For a community that values repairability, openness, and user agency, this is an unsatisfying trade-off.

The core idea

Framework Vault Module
A built-in, user-controlled hardware trust module, installed internally (e.g. via M.2), that:

  • Stores secrets in hardware, not in the OS

  • Never exposes raw keys to the host

  • Works with or without TPM

  • Is unlocked via phone-based push approval (no USB, no typing)

  • Uses open firmware and documented protocols

  • Is portable across laptops

TPM belongs to the system.
The Vault belongs to the user.

What the Vault does (V0 scope)

  • :key: Hardware-backed storage for:

    • Password vault entries

    • SSH / GPG keys

    • Passkeys (WebAuthn)

  • :locked_with_key: Cryptographic operations happen inside the module

  • :mobile_phone: Unlock via phone push approval

    • No USB dongles

    • No code typing

    • Presence-based security

  • :repeat_button: Safe firmware updates via A/B firmware slots

  • :recycling_symbol: Recoverable by split key shards (no single point of failure)

What it is not

  • :cross_mark: Not a TPM clone

  • :cross_mark: Not a DRM or attestation enforcement tool

  • :cross_mark: Not cloud-locked

  • :cross_mark: Not mandatory for the system to boot

This is opt-in, user-owned security.

Why this fits Framework specifically

Alignment with Framework values

  • :puzzle_piece: Modularity – a replaceable, optional component

  • :unlocked: Openness – FOSS firmware, auditable behavior

  • :recycling_symbol: Sustainability – no disposable dongles

  • :brain: User ownership – keys move with the user, not the motherboard

This extends Framework’s philosophy from hardware freedom into digital trust freedom.

Benefits for the community

For users

  • No more dongle chains

  • No vendor lock-in

  • Stronger security than software-only solutions

  • Security that survives laptop upgrades

For developers and power users

  • Hardware-backed SSH/GPG without TPM pain

  • Scriptable, auditable trust model

  • Linux-first, but browser-compatible via passkeys

For privacy-focused users

  • No cloud dependency

  • No biometric requirement

  • Phone used only as presence confirmation

Benefits for Framework

  • A unique differentiator among laptop manufacturers

  • Minimal platform risk (external, optional module)

  • Strong community engagement and discussion

  • Reinforces Framework’s reputation as the user-first laptop company

Even as a community-driven accessory, this would be a visible statement.

Limitations and honest trade-offs

Limitations

  • Not a drop-in enterprise TPM replacement

  • Does not satisfy Microsoft-style attestation requirements

  • Initial scope likely Linux-first

Why that’s acceptable

  • Framework users already value control over compliance

  • WebAuthn/passkeys enable cross-platform usefulness

  • Enterprise features can be layered later if desired

Why this matters beyond Framework

Many laptops:

  • Have no TPM

  • Have TPM 1.2 only

  • Have locked-down firmware

  • Are still perfectly usable hardware-wise

A built-in, user-owned vault could extend the usable lifetime of millions of devices, aligning with sustainability goals far beyond a single product line.

Open questions for the community

Questions for users

  1. Would you prefer an internal security module over USB dongles?

  2. How important is portability of your keys between laptops?

  3. Would phone-based approval feel acceptable or preferable to USB keys?

  4. What would make you trust such a module?

Questions for engineers / hackers

  1. Would open firmware and reproducible builds be a requirement for you?

  2. How do you feel about TPM coexistence vs. replacement?

  3. Would an M.2-based module be acceptable, or would you prefer an Expansion Card?

  4. What security assumptions would you not be willing to make?

Closing thought

Framework proved that laptops don’t have to be disposable or locked down.

This proposal asks a simple follow-up question:

If users can own and repair their hardware,
shouldn’t they also own and control their digital keys?

2 Likes
2

While I like the idea overall, I have doubts about its security model.

Hardware tokens like Yubikey, smart cards, and TPM all implement some sort of two-factor authentication:

  • smart cards and other tokens - something you have (card/token) and something you know (PIN)
  • TPM - something you have (piece of hardware) and that hardware’s state attestation (it hasn’t been tampered with)

With your proposal, presumably phone approval is the equivalent of “something you know” or “hardware state”, except how exactly is that approval process supposed to be happening? Is there some sort of communication between the module and phone, or some pre-seeded pseudo-random sequence like what was used in the once popular keychain authenticators? Devil (or security flaws) is in the details.

Second, what about those of us who have eschewed phones altogether due to the privacy concerns around them? Your phone requirement seems to me to be in direct conflict with your claims of privacy focus.

How exactly is the split key shards supposed to be handled? Is the idea for them to be handled by software, or they are small and simple enough to be transcribable by hand, like in case of BitLocker recovery keys?

And a comment - as someone who works on enterprise B2B services, attestation requirements are very important in that space. E.g., is the system compliant with all the policies and regulations regarding PII handling, is it configured in a secure way (firewall enabled, storage encrypted, etc.), does it have anti-malware software like Crowdstrike Falcon running, are the OS and applications up-to-date?

P.S.: maybe don’t rely on AI as much to write your proposals for you?

3 Likes
3

Expansion Card all the way. An M.2 would be asking FW to make room for that on all their mainboards in order to support this. Feels like a non-starter. They have already squeezed as much as they can fit into their mainboards, and would be competing with other user desires.

Maybe a USB-C port could be squeezed in, plus the required usb hub chip. So that it wouldn’t fully take up the slot. To be clear, a limited USB-C port with no PD charging support, it wouldn’t fit.

1 Like
4

I like the combo of:

Passkeys (WebAuthn)

Cryptographic operations happen inside the module

Unlock via phone push approval

if that’s possible, with caveat on #2: beware side channels from a compromised host.

It would need “companion” apps on the phone and probably also the host side:

  • Passphrase bootstrap: module’s contents protected by passphrase that’s required on host boot and periodically after that. Choice on which we distrust less for this: Phone or host (maybe need passphrases on both?)
  • Phone: Can also act as second factor, integrate with phone OS attestation (including biometrics, for ease of use, if acceptable).

Basically, a watered down (but easier to obtain/use) version of bunnie’s betrusted.

5

That’s nothing new, standard for TPM, PIV smart cards, other security tokens like Yubikey.

Only if it is 100% optional without losing any security-critical functionality.

1 Like
6

1) What exactly is “phone approval”?
It’s not a vague signal or pre-seeded OTP chain. The intended model is standard asymmetric challenge–response:

  • The Vault stores public keys of one or more approval devices (phone app, optional USB key, second vault, etc.).

  • On unlock, the Vault generates a fresh challenge.

  • The approval device signs it with its private key.

  • The Vault verifies the signature and grants a time-limited session.

Transport (QR, LAN, BLE) is just a carrier; security is in the signature. No shared secrets, no replayable OTPs.

2) What about users who avoid phones for privacy reasons?
Phones are optional, not mandatory. They’re offered because they avoid USB dongles and extra hardware.

Alternatives include:

  • USB approval token (non-biometric)

  • Second Vault module

  • PIN-only mode with reduced trust score

  • Offline recovery shards

The phone is a convenience factor, not a trust root.

3) How are split key shards handled?
The intent is Shamir-style split keys with integrity verification, not cloud escrow.

  • Master key is split (e.g. 3-of-5).

  • Shards can live in the Vault, an approval device, offline print/QR, or removable media.

  • Recovery reconstructs the key and verifies it against a stored hash commitment.

This is closer to BitLocker recovery keys or RAID parity logic than software backup.

4) Enterprise attestation concerns
This proposal is not trying to replace TPM-based enterprise attestation (Secure Boot state, EDR presence, compliance posture, etc.).

TPM can continue handling platform attestation.
The Vault is intentionally scoped to user-owned secrets and identity, portable across machines, and outside vendor-locked compliance enforcement.

Trying to merge those roles usually satisfies neither use case.

Summary
This isn’t a TPM clone or a dongle replacement — it’s a complementary, user-owned trust layer. TPM remains valid; this fills a gap where TPM and USB tokens don’t fit well.

7

You really ought to learn to write yourself instead of being a mere avatar of AI…

For phone approval via challenge-response - so essentially you want to use phone as a FIDO2 authenticator for your vault module release requests. Makes sense from security viewpoint, not yet convinced on the privacy part, so still don’t see much of an advantage over, say, certain Yubikey or Feitian models. The other two points make sense to me. For the enterprise use cases - make up your mind whether you want to “layer later” their support, or you don’t target them at all, but make sure that by not targeting them during your initial design you don’t end up walking through any one-way doors that preclude you from “layering” the necessary features later on.

Final comment is physical form factor. If your vault module were to provide pass-through USB port, that would deal with “avoid USB dongles and extra hardware” even if were to use another token via USB port for approval. If your module were to not offer any pass-through ports, it would in itself use up a valuable port. Final food for thought - there are security tokens with their own hardware PIN pad, meaning while release is PIN-based, it’s not influenced by the system OS.

And for the sake of anything of value in this world, please learn to write yourself instead of leaning on AI crutch all the time. You don’t endear yourself to anyone by sounding like they may as well talk to a robot directly instead of going through you.

3 Likes
8

Not just an app, push requires intermediate services. A server. Anyone who does a significant amount of self-hosting knows the options there are pretty limited.

1 Like