Server Security | Hacker News Reader

Server Security

keybase.io

51 pointsjashkenas17 comments

Hey mods editing this post — this isn't a general article about server security, this is a specific article about "Keybase.io's Server Security", which was the original, more appropriate, more useful, title. Why fix what ain't broke?

Based on the lack of human sensibilities, it could be a robot implemented by someone who believed the heuristic was acceptable.

So here's how I would make a Keybase.io that is resistant to server compromise.

1. don't store private keys (of users). 2. distribute the organization around the globe; different datacenters, different states/countries, different peers/service providers. 3. use different infrastructure, hardware/software, hardened, with tripwires. 4. make your clients auth all the sources, with a minimum of N/3 valid, identical responses from distinct parts of the network. 5. implement the rest of the service's functionality as described in the post.

As long as you have a shit-ton of distributed locations you can survive internet outages, state actor intervention, service provider compromise and server compromise. It would all have to be highly available mesh network, of course, but it's feasible and should be pretty low on resource use as it's just public keys you're copying around.

Yes, you can architect a system that's more difficult to compromise or knock offline, but a better solution would be to remove the need to trust the server or to have it constantly online. To their credit, the Keybase guys have done this - their client fetches information about a user from the Keybase server, but performs the verifications itself and deposits the public key into your PGP keyring if successful. Once that's done, you don't need Kebase at all in order to communicate with that person securely.

Wouldn't a server compromise allow someone to "lie" to the web client only, while continuing to give correct answers to the standalone client? Seems like that would be very difficult to catch.

(or, just hack the web client so it lies, independent of what it actually sees from the server)

Server compromise wouldn't even need to take place on the server itself.

I'm really enthusiastic about Keybase and am hopeful that it will succeed where others have failed to push mainstream adoption of PGP.

I've been trying to think of innovative applications of the Keybase API [1], which exposes much (most?) of the functionality available via the command line client.

I've got a few vague projects in mind but would love to hear more ideas. I've got a few Keybase invites left and will give them while they last to anyone who proposes an interesting use of the API, as long as Keybase doesn't object to this type of "contest" [2].

1. https://keybase.io/docs/api/1.0

2. maxtaco and malgorithms, please let me know if that's an inappropriate use of the invites and I'll rescind the offer.

Totally appropriate. I should say that we don't really want to be in the business of building general crypto apps ourselves, but Keybase identity proofs can make a bunch of things possible. Anything from financial transactions (send a BTC to twitter user X and know it's going to an address they control) to data access (let Keybase/github/twitter user Y access this server/file/whatever). The idea here is that any app can (1) ask Keybase for a user's key and identity proofs, and then (2) verify it all.

The API is not done, btw. If another call is needed, and you're really serious about building it, we will expand the API.

>send a BTC to twitter user X

Exactly. I've had my eye on Keybase issue #218 [1], and I'm hoping that you all will provide a way for users to provide a confirmed Bitcoin payment address.

You could just generate a unique message for the user to sign with the address using their Bitcoin client. Most bitcoin-qt and most other GUIs even have a menu option now for signing, so it should be easy for users to do.

To preserve privacy, a user could even post a stealth address, to the extent that stealth addresses are supported in the user's client software. Most clients aren't there yet, but I think more will start supporting stealth addresses this year.

1. https://github.com/keybase/keybase-issues/issues/218

I love Keybase and the possibilities are endless with it. I've already started working on an end-to-end, encrypted filesharing app utilising the keybase API and I've got 2-3 ideas for other apps already. It's amazing what having easy access to PGP can do.

I think the biggest nut to crack is going to be making the onboarding process as simple as signing up for an email account. I dream of a day where the majority of people have PGP keys and while I think keybase's signup flow was straightforward, I can see how it would be very confusing for an average computer user.

Why not use Oauth to verify someone on Twitter instead of having someone post a tweet?

How many people are automatically logged in?

The only thing is that you would see the keybase message that you didn't send but it is Twitter and most people don't look back on their recent tweets.

Tweets can be seen publicly, unlike OAuth connections. This is true for the other Keybase proofs too.

yes, the premise here is that the Keybase server can be caught lying. If you want twitter user X's public key, Keybase can tell you the key and which tweet to look at to verify it. Then you can check it yourself. OAuth doesn't allow this.

did anyone think there ought to be a similar way to hash-chain all the /etc files on a server - a 'tripwire' approach (hmmm, I seem to remember tripwire doing hashes but not as a chain)

For the untrained eye, this looks like a partial implementation of a Bitcoin blockchain, just without the proof-of-work. Or like a git repository without forking.

Am I right or did I pick up something wrong?

It's more like Git where the latest action is linked to all previous action + data is organized in a tree so any piece can be efficiently demonstrated as a part of the trusted whole (via a merkle branch).

Yes; here's a tl;dr: for a given user, all of their signatures form a chain of signed statements, where each one points at the previous statement. They don't have to be the same kind of statement: your identity proofs, your tracker statements, etc.

And then each user's chain is itself pointed at in a leaf node of the signed merkle tree. (The tree is signed by Keybase).

So you as a client can verify any individual's personal signature chain, and you can verify Keybase's merkle tree. Finally, and this is the more subtle connection, each user's signature chain has statements about the merkle tree itself, so you can verify all these users are seeing the same Keybase-signed merkle tree.

A lot of the same techniques. No need for proof-of-work since there's no contention for a scarce resource.

We might, in the future, periodically write our root block to the Bitcoin blockchain as a further protection against forking attacks.

Reply on news.ycombinator.com