Load signing key and verify signature of installer before running dpkg

[bgpugh]

Related to #2064, the install page should walk the user through installing the keybase pubkey and validating a signature on the install package prior to running installation to ensure the download hasn't been tampered with.

See: https://www.torproject.org/docs/debian.html.en

[bgpugh]

Borrowed from tor's instructions, but substituting data from postinstall & other scraped sources. I haven't tested, as I don't have a debian machine in front of me at the moment:

Add the following entry in /etc/apt/sources.list or a new file in /etc/apt/sources.list.d/:

deb http://dist.keybase.io/linux/deb/repo/ stable main

Then add the gpg key used to sign the packages by running the following commands at your command prompt:

$ gpg --recv-keys 656D16C7
-or-
$ curl https://keybase.io/docs/server_security/code_signing_key.asc | gpg --import

$ gpg --export 222B85B0F90BE2D24CFEB93F47484E50656D16C7 | sudo apt-key add -

You can install it with the following commands:

$ sudo apt-get update
$ sudo apt-get install keybase

[bgpugh]

It doesn't look like the RPM packages are signed whatsoever…

[oconnor663]

RPM packages are signed with rpm --addsign, which stores a signature in the package itself somehow, though I don't know the details. Here's the script that does it. If I didn't make any terrible mistakes, both .deb and .rpm updates should get verified automatically by your package manager and gpg.

As for the initial install flow, I agree that it's vulnerable, but I'm not sure how to make it better. Here are a few problems I see:

1. Meaningful security steps are very difficult for most people to follow. Step one of the Tor instructions is "You need to add the following entry in /etc/apt/sources.list...", which assumes a lot of knowledge.
2. The RPM story for this is more complicated than the Debian story. RPM package managers are much less consistent across distros than apt-get.
3. It's not clear to me that these steps meaningfully improve security.

Here's my thinking with # 3: You're already downloading the packages over TLS, so if you trust our server (and Amazon), then you're fine. If you don't trust our server, but you still trust our code signing key, then in theory you could verify our signature by hand. But if you haven't already memorized the steps for how to do that, then you're in the awkward position of following instructions given to you by a server that you don't trust. In particular, the server could easily lie about our code signing fingerprint.

I don't know a solution to this. One option is to get ourselves included in official distro package repos. (In fact the fine folks over at Arch Linux have already done this for us!) You have to be willing to trust your distro maintainers, but that's always true anyway. The bigger downside is that most distros are much slower than Arch at updating packages, so using official packages really isn't practical.

[bgpugh]

From the extraction I did on the rpm package, it looked like it didn't have any sort of signature or manifest or anything… just the binary. Though, that could easily be my toolchain, and I don't have the domain knowledge on the format.

The issue as I'm proposing it is that you can't verify that the initial package downloaded was genuine except by trusting the SSL connection. Let's take the debian case:

1. .deb file is downloaded over SSL
2. Package is checked by dpkg to verify it has some valid signature (though not from whom, since the signing key isn't in apt-key)
3. Once installed, the codesign pubkey is added, the repository is added to the sources list, and further updates are checked that the update isn't tampered with

which covers the user going forward if your first install is clean, but if I've modified the package to use my key and repo and installed a malicious root cert in the device I can then bypass this security.

At least with giving the user the option of using HKP you can choose which keyserver you'd like to connect to (or ask multiple key servers for the same key) and then exporting the specific fingerprint into apt-key to ensure you're using the precise key.

With the current instructions, the user is still copy/pasting commands that they might not understand so it's not an improvement, but this would give the more sensitive users a more direct hand in verifying the package if they'd like to deviate from the standard path.

Add the keybase apt repository with:

$ echo "deb http://dist.keybase.io/linux/deb/repo/ stable main" > /etc/apt/sources.list.d/keybase.list

Then add the gpg key used to sign the packages by running the following commands at your command prompt:

$ gpg --recv-keys 656D16C7 && gpg --export 222B85B0F90BE2D24CFEB93F47484E50656D16C7 | sudo apt-key add -

If the above two commands are successful, you can install keybase:

$ sudo apt-get update && sudo apt-get install keybase

(plus, if you're using apt-get for the initial install, you don't need to worry about if you're 32 or 64 bit, which IMHO is a larger barrier to entry to the user with the current instructions)

[oconnor663]

From the extraction I did on the rpm package, it looked like it didn't have any sort of signature or manifest or anything… just the binary.

Run rpm -K ... to check the signature on a package file. In my experience this only works after you've installed at least one update, because yum/dnf fetches our key on update, but YMMV.

At least with giving the user the option of using HKP you can choose which keyserver you'd like to connect to (or ask multiple key servers for the same key) and then exporting the specific fingerprint into apt-key to ensure you're using the precise key.

I don't think this helps you if you're getting the fingerprint from our web page.

if you're using apt-get for the initial install, you don't need to worry about if you're 32 or 64 bit, which IMHO is a larger barrier to entry to the user with the current instructions

We've been talking about getting rid of 32-bit builds entirely on Linux. Chrome just did. If we keep supporting it, we'll probably want to make it a very small link, to avoid confusing people.

[bgpugh]

I don't think this helps you if you're getting the fingerprint from our web page.

It does if you're also checking signatures or believe in WoT (which is a whole 'nother ball of wax beyond this issue 😑)

You're right though. In either case, your initial trust is bootstrapped by SSL trust. In the "import the key first" method, you at least can verify your download pre-install. Plus, if the codesigning key has validations (for example WoT signatures or keybase proofs) then it has additional trust mechanisms built in that SSL doesn't provide.

[tildelowengrimm]

It definitely helps when getting the fingerprint from the webpage. I can confirm that fingerprint with other keybase users (even if they downloaded a totally-different installer file at a different time). I can also decide to trust the key this time, note the fingerprint, and then rely on it for future installs on other machines. Not everyone will manually verify the installer, but I think it's important that it's possible.