Opened 5 years ago

Closed 4 years ago

#13407 closed task (fixed)

Transition smoothly away from Erinn's signing key for the coming releases

Reported by: gk Owned by: erinn
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: security, usability
Cc: lunar, mikeperry, gk, mrphs, mcs, boklm, ilf@…, adrelanos@…, micahlee, u@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We should find a good transition away from Erinn's signing key. There are already different proposals on the table with different kinds of efforts involved:

1) Move on to a different key of one of the Tor people.
2) Move away from single points of failure and use the sha256sums verification we already describe on https://www.torproject.org/docs/verifying-signatures.html.en#BuildVerification
3) Create a role key for signing the bundles to be not dependent on single people available signing the release.

...

Child Tickets

TicketStatusOwnerSummaryComponent
#13960closederinnDocument key creation processApplications/Tor bundles/installation
#14213closedSebastianUpdate the signing key page with the new Tor Browser signing keyWebpages/Website
#14626closedtbb-teamApply OpenPGP Best Practices for Tor Browser Developers Signing KeyApplications/Tor Browser

Attachments (1)

0001-Bug-13407-Update-signature-verification.patch (6.3 KB) - added by gk 4 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 5 years ago by lunar

I'm strongly in favor of creating a role key and continue to sign files individually.

comment:2 Changed 5 years ago by mrphs

Cc: mrphs added
Keywords: security usability added

I vote for option 3. A master key* with rotating Subkeys.

*Lunar mentioned people use gfshare to keep the private-key collectively. I think it's super badass if we can do something like that :)

comment:3 in reply to:  1 ; Changed 5 years ago by gk

Replying to lunar:

I'm strongly in favor of creating a role key and continue to sign files individually.

  1. How should we handle that role key in a sane way given how distributed we are?
  2. What are the blockers you see for giving all users the full benefits of reproducible builds?

comment:4 in reply to:  3 ; Changed 5 years ago by lunar

Replying to gk:

Replying to lunar:

I'm strongly in favor of creating a role key and continue to sign files individually.

  1. How should we handle that role key in a sane way given how distributed we are?
  • Define a set of trusted people.
  • Have a computer hardened as possible to do key manipulation with the master key. Hardened X60 + Tails + air gap?
  • After the master key has been generated, use gfshare to split it so that a subset of the trusted people will be needed to ever reconstitute the master key again.
  • Use the master key to create subkeys that will go on smartards. Have some people in the Tor Browser team carry these smartcards. Maybe 2 or 3 smartcards not in the same part of the world. Optionally other people in the team could carry revocation certificates for these subkeys.
  • Every year, have enough trusted people meet to be able to rotate the subkeys.
  1. What are the blockers you see for giving all users the full benefits of reproducible builds?

I would rather postpone that for another time. Right now there's a hell lot of documentation out there that assumes that files are signed individually. I'm interested in finding the best ways to continue doing so.

comment:5 Changed 5 years ago by mcs

Cc: mcs added

comment:6 in reply to:  4 Changed 5 years ago by gk

Replying to lunar:

Replying to gk:

  1. What are the blockers you see for giving all users the full benefits of reproducible builds?

I would rather postpone that for another time. Right now there's a hell lot of documentation out there that assumes that files are signed individually. I'm interested in finding the best ways to continue doing so.

Huh? I fail to see why "there's a hell lot of documentation out there that assumes that files are signed individually" should prevent *enumerating* the blockers for moving to a different verification scheme. But it seems at least the amount of documentation relying on single keys is one of the blockers (which is, btw, kind of a catch-22 situation as we won't get new documentation if we are not switching the verification scheme). Good, what else?

comment:7 Changed 5 years ago by boklm

Cc: boklm added

comment:8 Changed 5 years ago by nickm

A few stupid thoughts as I am distracted from other things:

There doesn't need to be a single unitary solution here. Suppose that our we believe that what we'd really like to do (were usability not an issue) is sign everything using threshold postquantum signatures over blake2 + cubehash, with a drum solo to drive away the evil spirits. And suppose that from a usability POV we have no idea how to make that usable, and we think that we need to do gpg signatures for the forseeable future if we want any hope of users actually checking these things.

What stops us from doing both? Give people a high-security way to check packages and a high-usability way if we don't believe we can make a single way that has both properties.

comment:9 in reply to:  8 Changed 5 years ago by gk

Replying to nickm:

What stops us from doing both? Give people a high-security way to check packages and a high-usability way if we don't believe we can make a single way that has both properties.

Nothing is stopping us from doing both. In fact, we do both already. There was just the thought that we maybe could drop the high-usability only way and have a high-security AND, say, usability way of doing things instead.

comment:10 Changed 5 years ago by gk

As Mike noted today on IRC we are hopefully soon able to ship signed MAR files for the updater which means that it might not be worth all the fancy efforts in trying to safeguard a role signing key given that we need to include that one MAR signing key into our Tor Browser which creates yet another single point of failure... (granted I am simplifying a bit given the certificate pinning but still...).

comment:11 Changed 4 years ago by gk

Here we go:

  pub  4096R/93298290 2014-12-15            
	 Fingerprint=EF6E 286D DA85 EA2A 4BA7  DE68 4E2C 6E87 9329 8290 

uid Tor Browser Developers (signing key) <torbrowser@torproject.org>

http://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&search=0x4E2C6E8793298290&fingerprint=on It is signed by my current key and will be used from now on unless we fuck things up trying to get the secret master key in Mike's dungeon.

comment:12 Changed 4 years ago by ilf

Cc: ilf@… added

comment:13 Changed 4 years ago by proper

Cc: adrelanos@… added

comment:14 Changed 4 years ago by proper

Since there are various TBB downloaders (tb-updater and torbrowser-launcher), please excuse the following question to make sure.

In future files such as https://dist.torproject.org/torbrowser/4.5-alpha-2/tor-browser-linux64-4.5-alpha-2_en-US.tar.xz.asc will be signed by the above rather than Erinn's key, right?

comment:15 Changed 4 years ago by gk

At least the *.xz, *.exe and *.dmg bundles will be signed by the new key, so, assuming that is what you meant, yes.

comment:16 in reply to:  15 Changed 4 years ago by gk

Replying to gk:

At least the *.xz, *.exe and *.dmg bundles will be signed by the new key, so, assuming that is what you meant, yes.

Or, more exact, they will be signed by one of its subkeys.

comment:17 Changed 4 years ago by micahlee

Cc: micahlee added

comment:18 Changed 4 years ago by proper

Created two related tickets:

  • #14625 set expiration date for Tor Browser Developers signing key
  • #14626 Apply OpenPGP Best Practices for Tor Browser Developers Signing Key

comment:19 Changed 4 years ago by u

Cc: u@… added

comment:20 Changed 4 years ago by gk

OK. I updated our verifying signatures instructions with the attached patch. We are ready for the switch on the stable series then.

comment:21 Changed 4 years ago by gk

Resolution: fixed
Status: newclosed

Not as smooth as I had hoped but, hey, we made it.

Note: See TracTickets for help on using tickets.