Live data from Hacker News

Show HN: Kryptonite – a new home for your SSH private key

krypt.co

181–190 of 227 posts

Re: Show HN: Kryptonite – a new home for your SSH private key

#181
post #158

Earlier quoted context omitted.

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

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

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.

Re: Show HN: Kryptonite – a new home for your SSH private key

#182

Earlier quoted context omitted.

Use a Google or Apple phone and stop worrying about their basebands, which are effectively USB peripherals.

The radio typically has DMA on the primary CPU, and remotely exploitable vulnerabilities.

Which phone are you talking about, and which vulnerability?

Re: Show HN: Kryptonite – a new home for your SSH private key

#183
post #46

Earlier quoted context omitted.

* 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 us…

>> Every application on the phone is sandboxed Note that you are trusting this app with your private key. While other apps are sandboxed away from having access, all it takes is one update to the app to sneak away your private key to any remote server. You have to trust the publisher of this app, including their entire chain of source code repository management and app build/release process. It takes a single instanc…

>> Note that you are trusting this app with your private key.

On Android, the Kryptonite code uses the AndroidKeyStore to store the private key, which means that the app does not have access to it. At a minimum (on old devices), AndroidKeyStore keeps the private key material in a separate process, so it never exists in the app's process space. On newer devices (launched with M or later), the private key material is kept in the Trusted Execution Environment, so nothing in Android user or even kernel space has access to it.

EDIT: Actually, there's one small flaw in the Kryptonite code that may make the private key accessible to a sophisticated attacker who compromises the app. The key allows signing without using a hash function. Signing a sequence of carefully-chosen plaintexts can reveal the private key. I filed an issue and sent a pull request.

Re: Show HN: Kryptonite – a new home for your SSH private key

#184
post #178

Earlier quoted context omitted.

This is simply not true. No matter how often you patch your Linux desktop, it is less secure than an iPhone.

Conflating secure with up-to-date is wrong in such a broad and sweeping statement such as 'your Linux desktop is always less secure than an iPhone'. Updates software does not instantly mean more secure, which I am sure you are aware of. As you stated, for the generalists, yes, an out-of-the-box iPhone has more hardening than an OOTB Linux desktop, but for the type of person on HN, this is not necessarily true at all.…

I disagree, but that's fine.

Re: Show HN: Kryptonite – a new home for your SSH private key

#185

Earlier quoted context omitted.

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…

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.

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.

Re: Show HN: Kryptonite – a new home for your SSH private key

#186

Earlier quoted context omitted.

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... 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 le…

From your blog: If you have a passphrase encrypted key, you can see this for yourself: $ eval `ssh-agent` # make sure an empty agent is running $ ssh user@server # enter passphrase on first login $ ssh user@server # passphrase no longer needed This is wrong. Keys not added explicitly with `ssh-add` to ssh-agent will not be available unless you explicitly enabled AddKeysToAgent in ssh_config. [0] Forgetting something…

Some distros do this automatically for you. I know macOS did until the recent major update.

Re: Show HN: Kryptonite – a new home for your SSH private key

#187

Earlier quoted context omitted.

The radio typically has DMA on the primary CPU, and remotely exploitable vulnerabilities.

Which phone are you talking about, and which vulnerability?

A specific list requires a lot of research to produce, and I don't have one handy. It's generally understood that the answer is "most" phones.

As for vulnerabilities, I'm just assuming here, but it's a pretty reasonable assumption. Radio firmwares are old legacy code, written by hardware people, likely in C or even assembly, closed source, and are highly guarded secrets. We already know that they, you know, have a radio in them, and that LE can use devices like stingrays to spoof towers. This sounds like a disasterous combination of factors for security. I'm 99% certain that most phones have an RCE waiting to happen, and most of them will have DMA on the primary CPU.

Re: Show HN: Kryptonite – a new home for your SSH private key

#188
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)

Re: Show HN: Kryptonite – a new home for your SSH private key

#189

Earlier quoted context omitted.

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 :)

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

works perfect -- this is really slick!

Re: Show HN: Kryptonite – a new home for your SSH private key

#190
post #173
post #160

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 3. Works with OpenSC

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!

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.
Post reply on HN