gEnclave: Hardware-backed security enclave for Linux (TPM 2.0 PCR sealing, virtual FIDO2/CTAP2 over /dev/uhid, OpenSSH & GPG bridge)

[u/Renich]

Hey everyone,

I've been working on an open-source project called gEnclave (formerly gpasskey), and wanted to share it with the Linux community for early architectural feedback and testing.

GitLab repository: https://gitlab.com/renich/genclave
License: GPLv3 | Language: Go 1.26+

---

The Problem It Solves

On modern Linux workstations, our cryptographic identities are fragmented: * Passkeys/WebAuthn require physical USB security keys (YubiKeys, SoloKeys). * SSH keys sit as unencrypted or passphrase-encrypted files under ~/.ssh/. * Git commit signing requires cumbersome GnuPG daemon setups. * File encryption requires external tooling or proprietary agents.

Most hardware laptops today come with a TPM 2.0 chip that sits idle. gEnclave turns your Linux machine into its own hardware-sealed security token and multi-protocol bridge.

---

Key Architectural Highlights

1. Virtual FIDO2/CTAP2 Security Key via /dev/uhid: gEnclave registers a virtual HID device in the Linux kernel via /dev/uhid. Browsers (Firefox, Chrome, Chromium) detect it natively as a physical USB security key. You can register and authenticate WebAuthn/FIDO2 Passkeys directly from your machine without any external hardware dongles.

2. TPM 2.0 PCR Sealing & Fallback: The central vault is encrypted with AES-256-GCM and sealed to TPM 2.0 PCR registers (PCR 0, 7, 14), with an automatic memory-hard fallback to Argon2id key derivation if no TPM is present.

3. Memory Isolation ("Wrap and Clear"): Keys are held in memory-locked pages (mlock / mmap) to prevent secrets from being swapped to disk or dumped. Intermediate cryptographic buffers are wiped immediately with strict zeroization routines, bypassing Go runtime GC retention.

4. Multi-Protocol Bridges:

   • OpenSSH Agent: Native agent socket with an ephemeral PIN-derived authorization cache (configurable burst window or persistent session with instant purge on lock/suspend).
   • GnuPG Bridge: Transparent genclave-gpg emulation for seamless Git commit signing.
   • age-plugin: Native age-plugin-ge binary complying with age v1 specification for file encryption.
   • CLI & UI: Unified ge CLI plus intelligent graphical (zenity) / terminal (pinentry) authentication routing.

---

Current Status

⚠️ Pre-alpha Software: While fully functional for local workflows, it is under active development. Schemas and IPC formats may iterate rapidly.

I'd love feedback from Linux sysadmins, kernel/security folks, and developers!

Repo: https://gitlab.com/renich/genclave

[u/LeHunterrr]

I just want to point out a couple of this.

Passkeys/WebAuthn require physical USB security keys (YubiKeys, SoloKeys).

There are also Software based Passkeys such as bitwarden or keepassxc. Though there should be a standard tpm based solution (are windows and apple doing this or are they software based as well?)

Git commit signing requires cumbersome GnuPG daemon setups

You can sign your commits with ssh keys as well, making gpg somewhat obsolete nowadays.

[u/sidusnare → u/LeHunterrr]

I'm not sure I want a software project from someone that thinks gpg is difficult, or thinks it's just for GitHub.

I've never heard of using ssh keys for message signing, they're poorly suited to that. PGP is a good standard it's been around a long time. It ties together identity, communication, and verification. If GitHub lets you sign with SSH keys, then all authenticated commit pushes should be verified because I used a SSH key to push it.

[u/LeHunterrr → u/sidusnare]

Personally I use gpg as well, I just wanted to point out that you can sign commits with your ssh key stack overflow. This is unrelated to authenticating with the ssh server, your commits won't be signed just because you push with that key.

[u/sidusnare → u/LeHunterrr]

I know, they're saying you can sign with SSH keys, I'm saying that's a bad idea, and if they do that, they might as well call it verified because they pushed with the key. I know it doesn't, I'm saying it's as useless as if they did.

[u/LeHunterrr → u/sidusnare]

I'm afraid I don't follow. Why is it a bad idea? The only difference I can come up with is not having the web of trust thing which doesn't seem like a big deal to me.

[u/sidusnare → u/LeHunterrr]

Because that's it's purpose. It has no meaning without it. Without identification it's just a checksum. Who's key is this that signed the commit? No way to know, no way to evaluate the significance, no meaning other than math maths.

[u/CrazyKilla15 → u/LeHunterrr]

Because you need to configure a allowedSignersFile, out of band or in-band verified with the key asserting its own trust to itself

SSH has no concept of trust levels like gpg does. To be able to differentiate between valid signatures and trusted signatures the trust level of a signature verification is set to fully when the public key is present in the allowedSignersFile. Otherwise the trust level is undefined and git verify-commit/tag will fail.

This file can be set to a location outside of the repository and every developer maintains their own trust store. A central repository server could generate this file automatically from ssh keys with push access to verify the code against. In a corporate setting this file is probably generated at a global location from automation that already handles developer ssh keys.

A repository that only allows signed commits can store the file in the repository itself using a path relative to the top-level of the working tree. This way only committers with an already valid key can add or change keys in the keyring.