8

According to Keybase's documentation:

[The] keybase clients in the wild play a crucial role in keeping the Keybase server honest. They check the integrity of user signature chains, and can find evidence of malicious rollback. They alert Alice when her tracking of Bob breaks, if either Bob or the server was compromised. They check the site's published Merkle tree root for consistency against known signature chains. And they sign proofs when all these checks complete, setting up known safe checkpoints to hold the server accountable to in the future.

And a bit later:

We fully understand that users of the Keybase Web client don't get these guarantees. But our hope is that enough users will use the Keybase command-line client to keep the Web users safe, by catching server misbehavior in the case of a compromise.

If you use the website to sign, verify, decrypt, or encrypt a message, you have to give up your private key and use your passphrase each time. Obviously, that's a risk. But if you sometimes use the website, will using the command line client verify the integrity of the server? Or do I need to trust keybase.io to not get hacked if I ever let it have my private key?

Community
  • 1
Ericson
  • 81
  • 1

1 Answers1

1

The keybase client DOES NOT verify the integrity of the keybase server. The client can to some extent verify behavior of the server to make sure, it is not providing wrong information to clients. That only includes withholding data, for example not saying Alice revoked her key and therefore allowing the compromised key to be exploited. It does not help against the server stealing keys, metadata or any other compromise.

Also, it is important to note, that the server can still pretend to Alice that it is unavailable to prevent her from ever submitting her revocation. While Alice would detect this, no-one else would. Alice would have to inform everyone and somehow prove this, which may be difficult.

Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
  • This is not (always) true. A server can not only prove to a client the software that it is running (from the kernel to the shell), but also prove that that software is up to date. This is a process called remote attestation. However, I don't believe Keybase does that... – forest Apr 22 '18 at 13:10
  • @forest sorry, I was talking about the keybase client, not in general. That is why as used The. Also, remote attestation is a bit dodgy IMHO. There are many ways it could go wrong. Though better than nothing. – Peter Harmann Apr 22 '18 at 13:16
  • Then I suppose I misunderstood your "can not" (it seems more correct to say "does not", since, in theory, it can). As for remote attestation, it's actually extremely solid. The only thing it relies on is the security of a TPM and its EK. As long as those work, the TCB is reduced to the point that you do not need to trust any other part of the system. – forest Apr 22 '18 at 13:18
  • @forest May want to read about Intel ME, which completely back-doors the whole thing and was found vulnerable in the past. As for the "can not", I meant the server does not provide the necessary data/api. I will edit it though. It makes more sense to say does not. Also, the TPM certificate must be signed by someone, does it not? You must trust both Intel and the CA, which I don't, at least not absolutely. – Peter Harmann Apr 22 '18 at 13:23
  • The CSME can have vulnerabilities the same as any other firmware, but it is far from a backdoor (or at least, it is no more a backdoor than any other parts of the PCH, or the chipset in general). Additionally, it can be disabled in several ways. Remote attestation can allow a server to prove that fact to a client (assuming it switches to a dTPM, because the CSME is what is in charge of the fTPM). – forest Apr 22 '18 at 13:25
  • @forest You can not disable the Intel ME completely and when Intel has to provide special versions of the CPU to military and intelligence agencies that does not have the Intel ME, but refuses to sell these to the public, I am calling it backdoor, no matter what they say. Also, the large amount of effort spent on making the ME hard/impossible to disable and or modify also makes it hard to believe it is not malignant. – Peter Harmann Apr 22 '18 at 13:27
  • You certainly can disable it, either by overwriting the first 4 KiB of the firmware (which exploits a bug, causing it to lock up), or via HAP and similar chicken bits/toggles (which cause it to shut itself down). The do not sell HAP to governments, they provide the feature in _all_ their CPUs to disable it, and they were asked by the gov't to create it (for their "high assurance" platform, which may disallow co-processors). Anyway, by that logic, every single component of the CPU is a backdoor (they provide _far_ more to the government and big companies than you or I. 10,000+ page datasheets). – forest Apr 22 '18 at 13:30
  • @forest First of all, if you disable it completely, the CPU can't boot as there is a part of the ME that helps with initialization. This part can't be disabled in any method, as without it, the CPU does not work. As for the government, they are already producing the chips without the ME. Refusing to sell them to the public is IMHO different than not providing documentation that may contain trade secrets. – Peter Harmann Apr 22 '18 at 13:33
  • Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/76401/discussion-between-peter-harmann-and-forest). – Peter Harmann Apr 22 '18 at 13:33