
Kryptonite – A new home for your SSH private key - flylib
https://krypt.co
======
quickben
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.

Ofering 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.

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

Overall, interesting concept, but perhaps rebrand the product to dodge the
above and various others holes in the design?

Maybe advertise this as a convenience SSH sign on?

~~~
4kevinking
> 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...](https://developer.apple.com/reference/security/ksecattraccessibleafterfirstunlockthisdeviceonly)),
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.

