Windows Hello–style authentication for Linux.
Hardware-backed secrets, local authentication, and a cleaner security experience built around TPM2, Secure Boot, and native Linux tools.
MyKey is a Linux security platform that brings authentication, secret storage, and secure local workflows together into one system.
Instead of juggling separate tools for browser authentication, desktop keyrings, local unlock, and PIN, biometric, and security-key flows. MyKey is designed to make those pieces feel like one coherent experience.
At a high level, MyKey aims to give Linux users:
- 🔐 hardware-backed authentication
- 🧠 TPM-sealed secret storage
- 🗝️ a Secret Service provider
- 🔄 a migration path from existing keyrings
- 🔑 future cross-platform passkey and authenticator support
- 🔢 a Windows Hello-style local PIN path
Simple to use. Serious about security. Built for Linux first.
If you want the more technical breakdown of how MyKey is designed, how the
pieces fit together, and where the project is headed, start in
docs/.
MyKey is moving fast and changing often.
For the most accurate picture of what is done, what is in progress, and what is
coming next, check PROJECT_STATUS.md. That file is kept
up to date alongside the work itself.
Linux already has strong security building blocks. The problem is that they are often split across different tools, desktop environments, and workflows.
MyKey tries to make that experience feel more unified.
The goal is not to hide how security works. The goal is to make the important parts easier to use without turning them into mystery boxes.
If Windows Hello made local authentication feel modern and straightforward, MyKey is trying to bring that same spirit to Linux using open tools and real hardware protections.
MyKey is made up of focused modules that work together.
The top-level terminal control surface.
Use it first when you want to discover or route into the installed MyKey tools:
mykeymykey helpmykey status
The security core of the project.
It handles:
- TPM interaction
- Authentication decisions
- Caller validation
- Secure policy checks
- Privileged operations used by the rest of MyKey
The local authentication subtree that groups MyKey’s system authentication pieces.
It contains:
mykey-pamPAM facing local auth layer and dedicated elevated password verificationmykey-pinPIN management and fallback authenticationmykey-biometricsBiometric setup and policy management on top offprintdandhowdymykey-security-keySecurity-key enrollment, status, test, and unenroll flows on top ofpamu2fcfgandpam_u2f
An optional local PIN-based authentication path.
The long-term goal is a Windows Hello–style local authenticator for Linux:
- Device-bound
- Optional
- TPM-aware
- Separate from the user password
MyKey's first-wave security-key management command.
It currently handles:
- Security-key enrollment through
pamu2fcfg - TPM-sealed MyKey metadata for enrolled keys
- A shared MyKey-owned
pam_u2fauthentication file - Dedicated test verification through
pam_u2f
MyKey's biometric enrollment and policy management surface.
It manages:
fprintdandHowdyenrollments- TPM-sealed MyKey metadata for biometric registrations
- Biometric backend status
- Biometric provider removal
- Daemon-owned biometric policy updates
An optional tray app that provides component status updates and quick interactions.
A Secret Service provider backed by MyKey's hardware-centered design.
This is intended to act as a secure alternative to traditional software encryption keyring providers.
A migration tool that can move secrets between MyKey and existing Secret Service providers such as GNOME Keyring, KWallet, and KeePassXC.
MyKey is designed around a few clear ideas.
Secrets and security-sensitive operations should be tied to the machine through TPM2 wherever possible.
MyKey PIN is meant to be a local device authenticator, not a network password and not something that should leave the machine.
MyKey relies on a known-good boot chain. That is why Secure Boot, TPM measurements, and predictable boot configuration are part of the design.
Convenient daily authentication and elevated security actions are different categories.
MyKey follows this model:
- 👆 Normal local auth: Biometrics, security sey, or MyKey PIN
- 🔐 Elevated actions: Linux account password through a dedicated password-only PAM service for setup, reset, and recovery flows
MyKey is intentionally opinionated.
It is currently designed for a specific security-focused Linux setup with the following requirements:
- TPM 2.0
- Secure Boot (enabled and enforcing)
- UEFI firmware
- systemd
- PAM
- D-Bus
- polkit
- systemd-boot
- sbctl
- UKI-based boot image
MyKey seals data against platform state. That only works reliably when the boot chain and local trust model are predictable.
If the platform configuration drifts too far from the expected model, sealed data may fail to unlock. That is not a bug in the security model. That is part of how the protection works.
For a clearer explanation of why MyKey is opinionated about these requirements, see the threat model.
MyKey is available on the AUR in two variants:
mykey- Stable release builds recommended for most usersmykey-git- Development builds tracking the latest commits
Install from the AUR with your preferred AUR package manager:
yay -S mykeyor
yay -S mykey-gitYou can install the developmental mykey-git package directly from GitHub using the Arch package scaffold:
git clone https://github.com/JamesFromFL/mykey
cd mykey/packaging/arch
makepkg -sirBefore removing the package, undo any runtime integrations you enabled:
mykey migrate unenroll # if MyKey owns Secret Service
sudo mykey auth disable # disables MyKey-managed PAM targets
sudo mykey biometrics # if you enabled biometric policy and want to remove it interactively
mykey tray disable # if the tray was enabledUninstall MyKey using pacman.
For stable release:
sudo pacman -Rns mykey mykey-debugFor development builds:
sudo pacman -Rns mykey-git mykey-git-debugCurrent real-world testing has focused on:
- Secret creation, storage, and recall through the Secret Service API
- Migration to and from GNOME Keyring
- Migration to and from KWallet
- KeePassXC provider handoff and migration readiness, with deeper validation planned
- Daemon-backed MyKey PIN flows
- Helper-backed PAM authentication
- Dedicated elevated-password gating for PIN setup/reset and biometric management actions
Testing coverage is improving, but this is still an active project and not a completed security product.
MyKey is still under active development.
That means:
- it has not been formally audited
- it is still changing
- it is stable for local everyday use
- it should not be treated as production-ready security software for critical or professional environments yet
If you use it, do so carefully and with the understanding that the project is still being developed and hardened.
If you find a security issue or bug, please report it responsibly.
Parts of this project were developed with the help of AI tools.
Architecture direction, review, validation, and all final decisions have and will remain human.
MIT — JamesFromFL, 2026