In my setup, a minimal SSH agent daemon would run in an enclave, only the necessary parts for key operations. The rest of the agent (protocol parsing etc.) would run in normal userspace and communicate over a channel (through the kernel or some other API, I don't know enough about low level system's programming to come up with the right abstraction).
Even if the user mode side of the agent would be hijacked, all it could do is ask the secure part to sign requests; the key itself would never leave the enclave. The same would be true for other authentication protocols, such as FIDO2/U2F daemons. In effect, once you've found out about a malicious program, you wouldn't need to worry about someone else reusing your key afterwards. Just analyse, then kill all the open sessions for that user and you don't even need to roll over your keys if you trust the enclave well enough.
For password managers the main key store would he handles by the enclave and only the necessary passwords would leave the enclave and cross over to system space. This way you can't just keylog the passphrase and upload the key store to a server, you could at most extract a few passwords per minute by having a malicious daemon run in the background. Granted, this is a lot less practical or secure than the other methods.
The biggest challenge for this all is to get some kind of secret into the system that the normal CPU can't see, but the secure enclave can. I theorise that the TPM would be an excellent place to do this in, but an enclave can contain its own secret store for all I care. If the enclave can do encrypted I/O with its super secret key, the files on the file system would be difficult to tamper with and configuration and state could even be stored safely on a non-encrypted disk! Reusing old, valid credentials would work, of course, but for that a secure counter or whatever may be implemented to mitigate that. The enclave would also need to run each program in complete isolation of each other (basically no multi threading or caches to prevent side channel attacks) but your average computer wouldn't be running more than two or three daemons anyway. Another challenge is to prevent modification of the loaded agent code itself but that again could be secured by a hash stored on the TPM after the program first loads. Associate the secret key with the hash of the program and allow a hash-secured program to upgrade the hash and you've got a pretty difficult to break system, I reckon, without necessitating the use of manufacturer provided certificates and keys like Intel likes to require. You would need a code execution bug in isolated program on the enclave.
I don't really see how you could lock down a secure input path unless you use PS/2. USB input devices are complex and need some level of drivers to work right, especially ones that do more than your cheap plastic office keyboard. I believe Intel does have such a system when their iGPU is used, I believe it has to do with its enterprise remote access tools, but I think this would be too much of an attack surface for general purpose use.
You can do that sort of thing with SGX very easily indeed. SGX enclaves can generate key material internally that's accessible only to themselves, sealed under the enclave identity, so no TPM is necessary. Actually SGX obsoletes TPMs for some use cases, they're independent technologies.
The way it'd work is you'd just use the public key emitted by the enclave. Grab a Xeon workstation and you can even do such a thing from your desktop.
If you want, you can even prototype such a thing right now. My guess is I could implement that in about an afternoon's worth of work using Conclave:
The thing is, if all it's doing is avoiding key rotation in case of compromise it's a bit hard to justify. Yes, HSM vendors have built a whole business on that, but in practice I'm not sure people are willing to rely on it. Compromised CAs get revoked, right, root store ops don't say "well luckily the HSM means the compromise was only temporary".
Intel did in the past prototype USB keyboards that could do a D/H key exchange and submit encrypted keystrokes. Likewise, apps can do D/H key exchange to tunnel encrypted bitmaps to the GPU where they get composited onto the screen, that's secure video path. Unfortunately there is a long history of them running out of steam before managing to get this stuff deployed in the real world. Seems to be the general PC problem of too many different vendors too coordinate, and PC vendors mostly care about cost reduction rather than new features. Apple is in a better place to do such tech but their whole model is closed-by-default, so they have a secure enclave like tech but only they are allowed to use it. Intel is still the best bet.
Unfortunately the developer experience without something like Conclave is pretty terrible, still. Disclaimer: I started the Conclave project, though I don't work on it anymore.
Even if the user mode side of the agent would be hijacked, all it could do is ask the secure part to sign requests; the key itself would never leave the enclave. The same would be true for other authentication protocols, such as FIDO2/U2F daemons. In effect, once you've found out about a malicious program, you wouldn't need to worry about someone else reusing your key afterwards. Just analyse, then kill all the open sessions for that user and you don't even need to roll over your keys if you trust the enclave well enough.
For password managers the main key store would he handles by the enclave and only the necessary passwords would leave the enclave and cross over to system space. This way you can't just keylog the passphrase and upload the key store to a server, you could at most extract a few passwords per minute by having a malicious daemon run in the background. Granted, this is a lot less practical or secure than the other methods.
The biggest challenge for this all is to get some kind of secret into the system that the normal CPU can't see, but the secure enclave can. I theorise that the TPM would be an excellent place to do this in, but an enclave can contain its own secret store for all I care. If the enclave can do encrypted I/O with its super secret key, the files on the file system would be difficult to tamper with and configuration and state could even be stored safely on a non-encrypted disk! Reusing old, valid credentials would work, of course, but for that a secure counter or whatever may be implemented to mitigate that. The enclave would also need to run each program in complete isolation of each other (basically no multi threading or caches to prevent side channel attacks) but your average computer wouldn't be running more than two or three daemons anyway. Another challenge is to prevent modification of the loaded agent code itself but that again could be secured by a hash stored on the TPM after the program first loads. Associate the secret key with the hash of the program and allow a hash-secured program to upgrade the hash and you've got a pretty difficult to break system, I reckon, without necessitating the use of manufacturer provided certificates and keys like Intel likes to require. You would need a code execution bug in isolated program on the enclave.
I don't really see how you could lock down a secure input path unless you use PS/2. USB input devices are complex and need some level of drivers to work right, especially ones that do more than your cheap plastic office keyboard. I believe Intel does have such a system when their iGPU is used, I believe it has to do with its enterprise remote access tools, but I think this would be too much of an attack surface for general purpose use.