Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

krypt.co

Post reply on HN
Print view View original

211–220 of 227 posts

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

#211

Post by 0xCMP »

sangnoir wrote: post #191
0xCMP wrote: post #185

Earlier quoted context omitted.

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 its…

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

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.

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

#212

Post by xaduha »

j_s wrote: post #209
xaduha wrote: post #190

Earlier quoted context omitted.

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.

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!

To read a bit of info about your credit card you can use this 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.

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

#213

Post by j_s »

xaduha wrote: post #212
j_s wrote: post #209

Earlier quoted context omitted.

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!

To read a bit of info about your credit card you can use this 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:…

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

Thanks much for the pointer!

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

#214

Post by dv_dt »

tptacek wrote: post #202
dv_dt wrote: post #197

Earlier quoted context omitted.

That Boing Boing article did reference actual CVEs. Though I like him as an author, Doctrow's writing style in articles rub me the wrong way too. I'm not privy to HSIC details for phones, but most high-speed chip interconnects I've seen are a proprietary, vendor unique solutions with little global commonality, and some of them do feature direct memory access too. So, though I'm speaking with a fair amount unknown on…

HSIC is USB. It's an industry standard. In modern flagship phone designs, the baseband is an adversarial component. It isn't trusted with access to AP memory. It's accessed like a peripheral. Nobody doubts that there are vulnerabilities in baseband processors. There certainly are. What I object to is the accompanying story that an exploit in the baseband gives you unfettered access to memory on the phone. I don't kno…

Ah, thanks! It was my misunderstanding confusing HSIC with a more generic chip interconnect.

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

#215

Post by ryukafalz »

derefr wrote: post #111
ryukafalz wrote: post #107

Earlier quoted context omitted.

>Yes, you'll never lose the actual RSA key bits to an attacker. But that'll be cold comfort after an attacker uses a hijacked SSH process to compromise every account you log into. But if you enable (and require) the touch feature, it'll be pretty obvious if someone's trying to use your agent to authenticate somewhere else, no? I'd certainly notice if I had to press the button twice while I'm logging into a machine th…

They don't have to use your agent to authenticate again. They just feed commands to your SSH client binary that it then sends over the wire in your existing SSH session-context, with the SSH pty temporarily set to not echo input and discard output (or return it over the network to the attacker, but not render it in the local PTY character-buffer.) A hijacked SSH binary can even detect an elevation-requiring command y…

Right, and that's still a problem, but not as much of a problem as if they were able to then use your key to authenticate to every other machine you have access to. The problem is at least contained to a single system at a time.

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

#217

Post by agrinman »

Corrado wrote: post #216

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.

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

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

#218

Post by tptacek »

peterwwillis wrote: post #210
tptacek wrote: post #172

Earlier quoted context omitted.

I didn't bother reading the Android list. If you're concerned about Android security, as I am, don't use Android phones. Your iPhone list has virtually nothing to do with the difference in security between phones and computers. It's just a bunch of things you don't like about phones. What on earth does A5/1 have to do with any of these issues? Cracking A5/1 keys doesn't break your IP sessions.

There are more ways to exploit a phone than a computer, and you can't control how it works. A computer you can pretty much completely control. Moreover, it is easier to surreptitiously own a phone. It's this false sense of security that's dangerous. If you break the encryption you can intercept 2fa at the least. Any time encryption is broken security assumptions have to be re-evaluated. Your HTTPS session might be se…

No, this is in fact why everyone says not to use SMS as an authentication factor. When you use TOTP applications like Google Authenticator on your phone, you are no longer relying on the security of the GSM network. I don't think your arguments here are very coherent.

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

#219

Post by peterwwillis »

tptacek wrote: post #218
peterwwillis wrote: post #210

Earlier quoted context omitted.

There are more ways to exploit a phone than a computer, and you can't control how it works. A computer you can pretty much completely control. Moreover, it is easier to surreptitiously own a phone. It's this false sense of security that's dangerous. If you break the encryption you can intercept 2fa at the least. Any time encryption is broken security assumptions have to be re-evaluated. Your HTTPS session might be se…

No, this is in fact why everyone says not to use SMS as an authentication factor . When you use TOTP applications like Google Authenticator on your phone, you are no longer relying on the security of the GSM network. I don't think your arguments here are very coherent.

I will try to simplify; it doesn't make any more sense, I give up.

First argument: If your token generator or private keys are on a device connected to a network, they will eventually get compromised, given enough time and resources. The more attack vectors there are, the more likely a compromise is. Phones have more attack vectors than non-phone computers, so they are more likely to get compromised.

Second argument: Of the computing devices available today, phones tend to have at least as bad a security track record as modern non-phone computers. The average user can generally harden a non-phone computer's security* and pick more secure hardware, to improve their security position. But the user cannot generally do the same with a phone.* *

Summary:

Non-phone computers are not only more secure due to having less attack vectors, but their ability to be secured more than a phone makes them even more trustworthy. If you had to pick a place to keep keys, a non-phone device is more secure than a phone.

* by extending existing os security features or using 3rd party software

* * or at least, I'm not aware of comparable methods for phones; there may be some software hardening tools out there for phones, but the hardware is much more limited

Post reply on HN