Kryptonite – A new home for your SSH private key

> If the machine is silently compromised, moving the private key one step away doesn't matter much; kryptonite will serve the signature regardless, and the attacker can cherry pick the active session keys. Yes, it's a partial break, but given the fact that the private key can be stolen from the phone too, using kryptonite just increased the attack surface overall.

Malware with root-level privileges can hijack any sessions signed by Kryptonite (this is true for any HSM or two-factor solution), but the same malware could not, say, connect to every machine your key has access to. If malware does not have root privileges, it cannot steal session keys and would have to request signatures of its own. One of the main benefits is pulling the private key out of a directory that any running process, malware or not, can read.

>Offering no private key backup isn't a simple matter of 'just reupload your public key'. This works for services that have parallel user/pwd backup, but it stops there.

We are working on the best way to allow users to backup keys, but of course backing up a key reduces its security to the security of the backup. Generally, servers are accessible by more than one person and someone that still has access can upload your new public key. If your key was the only one, then ideally that infrastructure can be rotated easily.

>How do you stop the auto upload of the key to Apple/Google if the user has a global app data backup sync?

On iOS, we store the key with the `kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly` accessibility constant (described https://developer.apple.com/reference/security/ksecattracces...), such that the key is never backed up to iCloud. On Android (which will be available soon), we store the key in the AndroidKeystore and disable backup.

Thank you for the discussion! Our full architecture, threat model, and source code will soon be available. We'd love to hear any other thoughts you have.