> Keys like this should never be used by a team. They should never touch a developer or devops workstation.

That's the point of KeyMux: keys never leave a secure enclave. In fact, KeyMux has no logic to load private keys or to perform key operations in-memory, except in the context of ephemeral TLS. The TLS layer does support using HSM keys for mTLS authentication, so you can use a security token for peer mTLS authentication to a network attached HSM.

That's the whole point--you can use all the tools built and commonly used with in-memory keys, but using enclaved keys, instead.

A follow-on idea I'd like to spend time on, if I have the chance, is to write modules for Vault and/or some KMIP implementation that integrate with the app so that authorization for key operations on a networked-attached key store require the consent of multiple parties (with that consent using local secure enclave-based authentication, of course). So, for example, if you're going to roll a release, one developer or an automated pipeline submits the request but the signing awaits confirmation from other team members.

> High performance HSMs capable of handling 10k+ transactions/second are well within the price range of a well funded startup.

Microsoft knows this, and even offers HSMs as a cloud service.

HSMs simply don’t scale up to something the size of azure AD. Even if you could use 10K+ of them in a global cluster, copying keys between HSMs inherently exposes the master keys anyway. And how do you secure access to the HSMs, with another secret shared on every validation server? Turtles all the way down.

I had to draw a line so I could actually release something. But Windows and Linux support is definitely a target. In fact, the core software was originally developed on both macOS and Linux with PC/SC smart cards (both PIV and OpenPGP) and Vault as key stores, but without any GUI components--everything compiled into a set of PKCS#11 (for OpenSSH, OpenSSL ENGINE, etc) and PC/SC modules (for GnuPG). And I stayed away from macOS and Linux APIs as much as possible to ease a Windows port.

But friends and coworkers I explained and showed the idea to didn't get it conceptually (e.g. people have the idea of key rotation drilled into their head as if that's the alternative to HSMs, instead of it being a mitigation for a fundamentally broken key management ecosystem), plus most people just wanted something they could point SSH_AUTH_SOCK at, so there needed to be a daemon/menubar/taskbar service. Ultimately the hard part was modeling and building a GUI around the concept, so it would be easier to understand and use. To get something out the door I targeted my daily desktop environment, macOS. It's using Yue as the GUI toolkit, which supports Linux/Gtk, macOS, and Windows.

I took a year off of work to finally get the idea out of my head, which I had been mulling over for many years. But now I find myself in the middle of a downturn in the software engineering job market (anybody hiring or interested in investing?), so while I have work in progress to round out the macOS app features, Linux and Windows (which is really where the commercial viability exists, I think), will need to wait until I have some cashflow.

I'd like to eventually release the Linux work as open source. But FWIW if someone has a specific use case in mind and is willing to fund development, I could very quickly build and release a [non-GUI] Linux package. PKCS#11 and PC/SC Linux modules still build in the tree, and adding a TPM key store adapter along side the other internal adapters would be relatively simple. In fact, a Linux PKCS#11 module for accessing Vault Transit Engine keys with TPM 2.0 mTLS authentication would be maybe 1-2 weeks of effort; slightly less if just straight TPM 2.0 support. Most of the implementation is already there, but polishing and testing something which can be supported long-term takes some effort.