
Show HN: Kryptonite – a new home for your SSH private key - 4kevinking
https://krypt.co
======
shmel
It sounds very hipster and all, but how is a phone more trustworthy than a
Linux PC? Cool, we don't need to trust a PC, now we have to trust a phone and
pretend that malware for smartphones don't exist at all. Hardware USB token
looks much better as its attack surface is so much smaller than iOS/Android.

~~~
tptacek
* Every application on the phone is sandboxed.

* The disk is encrypted by default, and the OS is aggressive about _keeping it encrypted_ ; a booted-up computer is almost always decrypted.

* The language runtimes on the phone are hardened.

* The phone's kernel, in addition to being more important attack surface than the Linux kernel (because of the jailbreak market, among other things), is auto-updated.

* The phone's users, at least on secure phones, are never superuser.

* Virtually all of the shell command attack surface is gone, since you can only install apps through the one app-install interface approved by the phone vendor.

I could go on, and I'm probably missing a big one. Phones are more secure than
"computers". They kind of have to be: their OS design benefits from 2 decades
of security architecture lessons learned.

I use a Y4 for some of my SSH keys, but it's a gigantic pain in the ass, and
one that Egor Homakov is not entirely wrong about calling a marginal bit of
security theater (whoever owned up your computer also owned up your ssh
binary). It's true that the phone software token doesn't fix that, but it also
doesn't cost anything.

~~~
user5994461
>>> The phone's kernel, in addition to being more important attack surface
than the Linux kernel (because of the jailbreak market, among other things),
is auto-updated.

Most android phones are not updatable at all since manufacturers don't publish
any update.

That, alone, should be enough to put phones among the most vulnerable devices
on the planet.

~~~
tptacek
It puts _those Android phones_ among the more vulnerable devices. Don't use
those Android phones. I recommend iPhones to anyone concerned about security,
but you can substitute the Google phone of your choice; I don't want the
argument today.

~~~
packetized
What's cheaper - an iOS phone, or an Android phone + a Yubikey?

~~~
prewett
Tptacek is telling you that the most secure phone is iOS. If what's most
important to you is price (and, therefore not security), yeah, you might find
something else to be more compelling. That fact your different value system
leads to a different choice has no relevance to the discussion.

If your assumption is that Android + yubikey is as good as iOS, you need to
state that. Tptacek disagrees with that elsewhere in this thread, anyway.

~~~
ithkuil
My read is that tptachek claims that not all android phones are insecure. You
should avoid those android phones whose vendors don't do serious security
updates. Among the vendors that are well known to care about updating their
phones there is Google. So, he seems to say that an android phone branded
directly by Google (e.g. Nexuses, pixels) is a valid alternative to iPhones as
far as this topic is concerned.

~~~
0xCMP
He did not say that, but it's natural to assume that. All android phones run
android (naturally) so if for whatever reason you believe iOS to be more
secure and you also know most android phones do not receive updates correctly
then it's probably easier to avoid all android phones than try to accurately
predict the development roadmaps for companies other than Google's flagship
phones.

Personally, I think Android itself was not designed with as strong security as
iOS because it was designed for openness and this has turned out to be a
problem. One which iOS has to a much lesser extent.

~~~
sangnoir
> Personally, I think Android itself was not designed with as strong security
> as iOS because it was designed for openness and this has turned out to be a
> problem.

Openness and security are orthogonal - it is possible for a software to be
both open _and_ secure: see OpenBSD.

~~~
0xCMP
I completely agree, by "openness" I meant the lack of ACL/permissions for
different data. This is improving on Android, but I don't keep up with it
anymore so I'm not sure how much they've caught up or if what is
released/planned is marketing hype.

Of course, Android has always sandboxed and prevented apps from talking to
each other directly, but the restrictions on iOS have also always been much
higher. iOS has never had the issues Android has had with SD cards. As someone
who became an Android developer almost right after it came out, it was this
freedom that attracted me.

------
4kevinking
Hey HN! We've built a way to generate an SSH key on your phone and use it from
your computer such that the private key never leaves the phone. We were
inspired by the threat model of USB HSMs like the Yubikey and set out to build
a free, public source, and easier to use BYOD alternative. Looking forward to
your questions!

~~~
pquerna
I love the transparency of having your source on Github, but the license
ambiguity isn't ideal when revealing this to the world:

    
    
      We are currently working on a new 
      license for Kryptonite. For now, 
      the code is released under All 
      Rights Reserved.
    

[https://github.com/KryptCo/kr#license](https://github.com/KryptCo/kr#license)

Soon as I see that, I've got to close the tab, so does anyone who cares about
IP.

(disclaimer: i'm a co-founder of ScaleFT)

~~~
dudus
Is proprietary code even allowed on GitHub?

~~~
stordoff
You grant some rights to other users of GitHub, but I'm not seeing anything
that prevents proprietary code:

> If you set your pages and repositories to be viewed publicly, you grant each
> User of GitHub a nonexclusive, worldwide license to access your Content
> through the GitHub Service, and to use, display and perform your Content,
> and to reproduce your Content solely on GitHub as permitted through GitHub's
> functionality. You may grant further rights if you adopt a license.

[https://help.github.com/articles/github-terms-of-
service/](https://help.github.com/articles/github-terms-of-service/)

To anyone more versed in US law than me, what usage specifically does "use,
display and perform your Content" permit?

------
lucb1e
In terms of possible compromise, I rate the possibility that my phone is
compromised way higher than my laptop. Adding a factor is a good idea in terms
of security (not in terms of availability and ease of use, but definitely in
security), but replacing it entirely... No.

Why'd I even _want_ to remove id_rsa? What's the problem being solved here?

~~~
agrinman
The problem is that your private key stored in ~/.ssh/id_rsa can be read by
any user-level application. The private key is even vulnerable if you
passphrase encrypt it. See our deep dive into the threat model:
[https://blog.krypt.co/why-store-an-ssh-key-with-
kryptonite-9...](https://blog.krypt.co/why-store-an-ssh-key-with-
kryptonite-9f24c1f983d5)

This is why we move it off the computer and onto a phone. The security is
comparable to using a Yubikey. I'm not sure why you say your phone is less
secure than your laptop. On the phone, apps are sandboxed and the private key
never leaves the Kryptonite sandbox.

~~~
claudius
Neither Google nor Apple have root access on a Yubikey, nor does that key have
some sort of wireless transmitter included which would allow for unnoticed
data transfer to or from the key.

Furthermore, it is nowadays largely trivial to set up sandboxing within a
single user (using SELinux, Apparmor or whatever else) or to use multiple
users and classical privilege separation to achieve the same effect.

It is also telling that your "Threat Models" in the link above do not discuss
attacks against the phone at all.

Edit to add: _You_ currently also do not have the ability to use my keys. If I
were to install the app (and set it to auto-update as suggest so vigorously
elsewhere), all it takes is for a tiny little update by _you_ with no public
oversight to own every server I have access to. How is that _possibly_
improving security?!

~~~
forgotpwtomain
Thanks for the one sane post in this thread, as opposed to the _iPhone is more
secure than your Linux desktop_ FUD that tptacek seems to be spreading here.

------
xg15
The faq says there is intentionally no way to extract the private key due to
security. But this means I need a second account in case my phone gets lost -
the key of which I once again need to secure.

How is that more secure than letting me backup the private key in the first
place?

~~~
4kevinking
The current version is designed for hosted services like GitHub, redeployable
infrastructure, and servers to which multiple people have access. We totally
understand your use case and are actively working on implementing transferring
a key to another device or printing out a paper backup.

~~~
xg15
That makes sense. Looking forward to the development of your product then!

------
tptacek
I haven't reviewed the implementation, but this is a really good idea. I want
one.

~~~
patio11
I will likely end up using this in personal capacity, and would _also_
appreciate if the UX of using Google Authenticator were more similar to this,
rather than requiring me to screenscrape my phone with my eyeball and then
type information into another device (or, more painfully, another window on
the same phone).

The easiest way to do that probably results in a callback to Big Daddy G every
time I access anything sensitive _and I 'm cool with that_.

~~~
jitl
With Apple's devices, you can copy-paste your 2nd factor token between
devices, which makes things much more convenient. Although cloud copy-paste is
still significantly slower than tapping "Allow" in a notification, it's lower
friction than manually typing those numbers.

Although the security of cloud copy-paste I haven't investigated...

~~~
mhw
I've not checked how it works, but I don't think Universal Clipboard pushes
the data that's being copy-pasted via the cloud. I've certainly used it to
copy Wifi access codes from my phone to laptop when neither device had
internet access, so I think it's implemented using peer-to-peer
Bluetooth/Wifi.

------
y7
Clever that it uses the client instead of the server! I've dabbled with phone-
based authentication via a server-side PAM module before, but you generally
don't have full control over the servers you SSH into.

Although the question remains: is this more secure than just storing your key
on your computer? If you're assuming your machine to be compromised, then as
soon as you login to another server you've basically given your attacker
potential access there as well.

~~~
sdca
You've hit the nail on the head. If your computer's ssh binary can be
compromised so can krd.

If the main objective is to prevent other apps in user space from reading
unlocked private keys, why not just ssh/sudo into a secondary account where
the default shell is set to an ssh client?

~~~
yzmtf2008
The point is, even when krd is compromised, the malicious party cannot gain
access to your private key. They key is only stored on your phone and you have
to physically confirm the login from your phone.

~~~
xorfish
Is the private key still worth something if the attacker has access to the
server?

~~~
gnur
Yes, because the key is still private. Any other machine to witch you can
login with that private key is still off limites.

~~~
xorfish
Ah, I was under the assumption that it is standard practice to have a
different key for each machine that you log into.

~~~
snorremd
I think there are no real standard practice or consensus regarding ssh keys
and where you need different keys. Some people use one key for each ssh client
machine (the machine logged in _from_ ), some one key for each ssh server,
some use Yubikey to store a single ssh key, etc.

Personally I think one key per client is a good way when not using a hardware
security module (e.g. yubikey) as the public key then identifies a unique
client machine (e.g. your work laptop). This would help identify which client
was breached in an eventual attack. I do think however that I would prefer the
Kryptonite solution or using a Yubikey going forward.

------
Artemis2
Hi, that looks good! I'll probably try it out soon.

One suggestion regarding PCI DSS: you should probably make a page/whitepaper
that outlines the compliance story of Kryptonite. ScaleFT has a great one:
[https://www.scaleft.com/use-cases/pci-dss/](https://www.scaleft.com/use-
cases/pci-dss/). By the way, have you checked that you do not need to be
compliant yourself?

~~~
ShakataGaNai
Theoretically this solution could be classified as a mutlti-factor
authentication, which covers PCI DSS Requirement 8.2. See also
[https://www.pcisecuritystandards.org/pdfs/Multi-Factor-
Authe...](https://www.pcisecuritystandards.org/pdfs/Multi-Factor-
Authentication-Guidance-v1.pdf)

Beyond that, there isn't much else this does regarding PCI. SSH does the rest.

------
snowpalmer
Looks interesting. However, it seems to maybe assume you're using bash? Using
the fish-shell it seems to have simply broken ssh and git operations with
incorrect syntax. I had to run `kr uninstall` to get things back to normal (it
fails when it's running fish or if I drop into bash so it's somehow looking at
my default shell.)

I submitted a ticket on the repo.

~~~
4kevinking
Thanks, will fix this asap. We have tested on bash, zsh, and fish on macOS but
it seems we missed an edge case. I'll follow up with your ticket.

~~~
nyolfen
came here to make note of this as well. thanks for the prompt fix, i'll check
it out again in a couple of days :)

~~~
4kevinking
fish shell should be working now, let us know if you have any other issues!

~~~
rdavis
It's working great in my fish shell now. Thanks for the speedy update!

~~~
4kevinking
great to hear, thanks!

------
xaduha
Looks like you're using pkcs11 instead of inventing your own stuff, so kudos
for that at least.

But I wish people would be aware of smartcards more, they are all around us,
but sort of invisible and unnoticed.

1\. But cheap blank "Java" smartcards, more or less disposable

2\. Install this applet on it
[https://github.com/philipWendland/IsoApplet](https://github.com/philipWendland/IsoApplet)

3\. Works with OpenSC

~~~
j_s
Is it possible to use a chip/EMV credit card as an X.509 certificate? Let the
credit card company know your private key (paranoid assumption; not
necessarily true) & skip straight to step 3!

~~~
xaduha
Look, I'm not an expert, I just dabble a bit. In theory there's no need for
anyone to know your private key, it is generated on the card and kept there,
unextractable. As I understand it there's nothing stopping credit card
companies from allowing you generate your own keys on it (on a technical side
that is), it just wasn't done AFAIK.

~~~
j_s
I have a smart card so I have the reader, but when I put in my credit card it
doesn't even appear as though it can read it. I would love to use my "always-
with-me" credit card for home PC sign-on and whatever else but there's nothing
out there on the integration. Any pointers would be appreciated!

~~~
xaduha
To read a bit of info about your credit card you can use this
[https://github.com/martinpaljak/GlobalPlatformPro](https://github.com/martinpaljak/GlobalPlatformPro),
it will output something like

Card CPLC:

ICFabricator: 4790

ICType: 5049

OperatingSystemID: 8241

OperatingSystemReleaseDate: 2218

OperatingSystemReleaseLevel: 1520

ICFabricationDate: 3086

ICSerialNumber: 06575696

ICBatchIdentifier: 6664

ICModuleFabricator: 4810

ICModulePackagingDate: 3086

ICCManufacturer: 1180

ICEmbeddingDate: 3086

etc

I guess it's enough information to concoct some kind of 2-factor auth, but
what is stopping you from promoting your real smart card into "always-with-
me"? Or one of smartcards, since you can have many.

NFC-capable phones can act as a card reader for contactless smartcards AFAIK,
so that's something you can look into also.

~~~
j_s
I don't spend with my smart card, so it's not "always-with-me".

Thanks much for the pointer!

------
V-eHGsd_
> The private key is stored on your phone

i'm reminded of theo deraadt's answer to a slashdot question back in the say
about making a bootable openbsd firewall on a floppy. his response was along
the lines of, "firewalls are supposed to be among the most reliable things.
floppy drives are among the least reliable things."

------
trizic
Your FAQ says you cannot backup your private key. So does that mean if your
service gets attacked by DDoS or has unexpected downtime, you will not be able
to SSH into your server?

~~~
agrinman
Kryptonite works over bluetooth too, so even if AWS SQS is down, you'll still
be able to use your private key

------
bizzleDawg
Obvious question - What happens when the phone containing the private key is
lost?

~~~
daveloyall
[https://krypt.co/faq/](https://krypt.co/faq/)

~~~
vorotato
First make sure you remove the old SSH public key from any of your accounts.
Once you have Kryptonite installed on your new phone, add the new public key
to the accounts you were using SSH with before.

~~~
elahd
Sounds like you ultimately need a backup method for logging into your server
-- probably a second, non-Kryptonite key (or another admin user). Is that
correct?

~~~
4kevinking
That is correct. We will also soon release a way to copy a key from one device
to another by scanning a QR code.

------
hosh
I have read through the FAQ and many of the comments on the thread. They seem
rational to me. I have mixed feelings about this, mostly around the emotional
inertia for changing something.

On the other hand, I can see an immediate use-case for this for me. I use mosh
to log into my cloud dev environment and since mosh doesn't support ssh-agent
forwarding (and unlikely to ever to support it) ... this seems much a much
better alternative.

------
sweis
Why are you doing this instead of SHA[N]withRSA?
[https://github.com/KryptCo/kryptonite-
android/blob/master/ap...](https://github.com/KryptCo/kryptonite-
android/blob/master/app/src/main/java/co/krypt/kryptonite/crypto/SSHKeyPair.java#L60)

~~~
4kevinking
We do the hashing ourselves so that it's easy to use any hash function in the
future. If you create a Keystore key but decide to use a hash function you
didn't specify at generation time, it will be rejected by the API.

~~~
sweis
I don't know if you've done it correctly.

You can use the built-in signature digest support and still add support for
whatever you want in the future.

------
wwwv
How does this handle SSH session re-keying, does that need further
authentication from the device? openssh does this pretty infrequently, I can't
immediately remember if that needs participation with the asymmetric key or
not.

ED: Seems it's just as if you re-did the cipher negotiation, so no asymmetric
interaction.

------
cyberferret
Seems pretty cool - I've just installed it and having a play with it. A couple
of questions:

1\. So I have to update all my servers to use my Kryptonite SSH key from the
current Private Keys that I have?

2\. This solution still doesn't allow me to SSH into my servers from another
machine that doesn't have my private keys on it (such as a colleague's Mac),
does it?

~~~
agrinman
1\. You have to upload your Kryptonite public key to ~/.ssh/authorized_keys on
all the servers you want to access with your Kryptonite key. Take a look at
the unlisted command `kr add`to help with this. It automatically adds your
kryptonite public key to a server you specify: i.e. `kr add user@server` add
your Kryptonite public key to the authorized_keys file for account `user` on
`server`.

2\. It does actually. All you need to do is pair with your colleague's mac.
Run `kr pair` on their machine, Kryptonite can be paired with unlimited
computers such as your work and home computers. You'll be able to ssh to all
your servers using the Kryptonite key.

~~~
cyberferret
Ah! Great - thank you. Overall, I am amazed at the simplicity of managing keys
using this platform.

~~~
ams6110
Well as of now it apparently manages one key.

------
0xCMP
It'd would be nice if Kryptonite supported ssh clients on mobile devices too.

i.e. On iOS there is the opensource Blink client.

Not sure how the protocol would change, but it'd be nice if Kryptonite could
store the keys in one place focused on securely storing the keys and then ssh
clients can use them as needed. (Also for things like an iPad using a key on a
phone)

------
tscs37
This looks interesting but until Ed25519 on Android, importing existing keys
and Paper Backups are supported it's a no-go for me.

For some things I trust a paper backup in a fireproof safe over some nebulous
cloud thingy on my phone.

Atleast everything is open source, I'll favorite it and check back some time
in the future.

------
jorangreef
Would iTunes Sync or iCloud Backup include app data for Kryptonite (possibly
including the private key)?

~~~
elahd
Assuming Kryptonite does back up data to iCloud, there are two things to note:

1\. iCloud backups are encrypted.

2\. If you're not comfortable with #1, you can manually exclude an individual
app from iCloud backups through Settings > Storace & iCloud Usage > Manage
Storage (in the iCloud section). Click on your device in the Backups section.
Turn off Kryptonite in the "Choose Data to Back Up" section.

------
akerl_
Are the communications between the phone and the computer going via the
kryptonite servers?

~~~
4kevinking
No -- we treat every communication channel as untrusted. All communication
between the phone and computer is encrypted with session keys established when
you pair by scanning the QR code in the terminal. Check out our architecture
post for more details: [https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa3...](https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa336)

~~~
akerl_
If I'm reading this, the answer is actually ~Yes? The requests pass via
SQS/SNS run by Kryptonite, or via Bluetooth not run by kryptonite?

~~~
4kevinking
Indeed, (encrypted) requests pass through SQS/SNS with credentials owned by
us. We can see the amount of traffic, but not any of its contents or who sent
it.

~~~
henryfjordan
Follow-up: Since it seems all the code is open-source, is it possible for me
to run this service on my own server (or at least in my own AWS setup)?

~~~
bobwaycott
The lack of a license leaves this very unclear.

~~~
elahd
GitHub's user agreement allows for the free use of any code posted in a public
repo.

~~~
akent
No, it doesn't. Standard copyright applies if there is no licence.

GitHub user agreement allows other users to view and make copies of your
content _on github_ but not for "free use" in general.

[https://help.github.com/articles/github-terms-of-
service/#5-...](https://help.github.com/articles/github-terms-of-
service/#5-license-grant-to-other-users)

------
shusson
I love the concept, but I think the added complexity is hard to trust, at
least for now.

------
eof
Why do I want my private key on my phone instead of the computer where I am
using it?

~~~
4kevinking
Any user-level application on your computer can read the SSH key -- you'll
never know if it's used or sent off somewhere. Even passphrase encrypted keys
are vulnerable. Check out this blog post for a deep dive on our threatmodel
and why you should store your SSH key on your phone
[https://blog.krypt.co/why-store-an-ssh-key-with-
kryptonite-9...](https://blog.krypt.co/why-store-an-ssh-key-with-
kryptonite-9f24c1f983d5)

~~~
gkya
Well the phone is at least equally insecure, given it's often way more opaque
than a computer.

~~~
tptacek
No, the opposite is true. See upthread.

------
jmuguy
Set this up earlier for github and a few servers. It's very convenient, and I
like having the kr commands for adding the public key to whereever. As others
commented, the licensing is important to get worked out

------
Corrado
What, if any, integration points do you have with Keybase.io? One of the
things that I think Keybase got right is the sharing of public key information
and it would be awesome if you guys could work together.

~~~
agrinman
We'd love to do an integration with keybase.io: i.e. add your Kryptonite SSH
public key to your Keybase profile.

------
daveloyall
Does this allow me to ssh into my server, for example, a shell server on the
internet?

If so, how does the server contact my phone? Through your server, right?

What software do I install on the server for that?

~~~
daveloyall
I found the answer on your blog:

    
    
        > Our system consists of three components:
        >   (1) the Kryptonite phone app for iOS and Android,
        >   (2) the krd daemon that runs in the background on a macOS or Linux computer, and
        >   (3) the kr command line utility that manages krd.
    

...from [https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa3...](https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa336)

Sounds like `krd` is why I likely won't be using this.

Try implementing it as a PAM module or something.

[edit: formatting]

~~~
daveloyall
Ok, `krd` is an alternative `ssh-agent`, I see.

So my suggestion re: PAM is irrelevant because you aren't changing the server,
you're changing the client.

Ok, I'm interested ...maybe... I'll wait until people more familiar with ssh-
agent chime in. :)

------
falcolas
Seems quite similar to using a Yubikey to house your SSH key, just with
bluetooth and your phone. A bit less secure, but still quite the interesting
tool.

------
feld
They certainly seem to have a marketable product for easy ssh key management.
They'll make buckets of money on this I bet.

------
vikeri
Great stuff! Could there be an option to disable the notification for certain
"less security critical remotes"?

------
libeclipse
Looks cool, but I don't believe it's mature enough at the moment for me to use
it.

Will be keeping an eye on it though.

------
sleepychu
Is one of these repositories the server?

------
bartvk
That looks pretty cool. You do have to make sure to back up your phone.

------
woodylondon
Nice idea - played a bit. Any plans to add Linode.com ?

------
jamiesonbecker
Can this work with Userify to distribute the public key?

~~~
4kevinking
Yep! Just type 'kr me' to print your public key, or 'kr copy' to copy it right
to your clipboard.

------
exabrial
I don't have root access on my phone, and Samsung only releases patches if
their phones catch on fire. No thanks. Good idea though, but flawed execution.

~~~
pvg
That sounds more like a flawed phone.

~~~
exabrial
... Exactly my point?

~~~
cynix
There are better phones out there, and nobody is stopping you from using them.
You can't say this app/service is flawed just because some people might use a
flawed phone.

------
dffds
Very cool!

------
netsec_burn
So the new way to secure your private keys is in a location you DON'T control
and validation by text message? It's May 1st not April 1st.

~~~
4kevinking
I think you may have misunderstood our architecture. SMS doesn't play any role
in Kryptonite and all communication between the phone and computer is
encrypted and authenticated. Check out a full explanation of the architecture
here: [https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa3...](https://blog.krypt.co/the-kryptonite-
architecture-a385e7aaa336)

