[DrStalker]

That wouldn't help when there is a bug that lets an attacker read your server's memory; you'd still need to reissue your certificates as a preventative measure because you couldn't guarantee that the bit of memory used by the software HSM hadn't been compromised.

[teacup50]

The keychain operates out-of-process.

[remosi]

But not out of user. If I can run code as your user, I can attempt to retrieve those keys, although I assume MacOS prevents you from attaching a debugger to the keychain.

Linux has Gnome-keyring, which, amongst other interfaces, operates as a PKCS#11 softhsm (I think), but it still runs as your user.

[teacup50]

Of course. If you can run code as the user, then solutions intended to protect against arbitrary memory read bugs don't apply.

That doesn't mean that the solution is worthless. It simply means that it doesn't cover an unrelated class of bugs.

Migrated to hardware-based tokens, or Intel SGX-protected software tokens, would extend the solution to cover the case of arbitrary code execution. That doesn't eliminate the value of the software-only solution.

[DavidSJ]

Perfect security doesn't exist; the goal is to reduce the area of the attack surface. The class of attacks you're talking about is different than the class of attacks an out-of-process keyring protects against.

[dunham]

OSX keychain runs as root. The user is prompted if an app asks for an entry in the keychain that it has not created the entry and has not explicitly been granted access to the entry

You need root to get at the keys otherwise. There is code to do it here: https://github.com/juuso/keychaindump

(This pulls the key wrapping key out of the process and then decrypts the keychain file directly.)