[jitsi-dev] [jitsi] Repository signing key is relatively weak (1024-bit DSA) (#203)


#1

The key that is used to sign the Release file / Debian packages in the apt repository at http://download.jitsi.org/ is a 1024-bit DSA key dating from 2008, when Jitsi was known as SIP Communicator.

(1)	SIP Communicator (Debian package) <deb-pkg@sip-communicator.org>
	  1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20

Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably close to that which might be able to be cracked by a well-resourced attacker with lots of computational resources.

In addition, there could possibly be concerns about how the private key has been managed over the years, how many online systems it's lived on, etc. Keeping the private key offline or on an air-gapped system would be ideal, but it's also prudent to rotate signing keys after so many years (in this case, 8).

Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR, making it appealing to communities with a need for secure communications. These people also would love to see the processes behind the delivery, verification and installation of your software be as "secure" as possible.

In conclusion, I recommend that Jitsi generate a new signing key, ideally 4096-bit RSA.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203


#2

What will happen if we change the key on the current repository? I mean
what will the user see, a user which had already add the old key?

···

On Wed, Jan 13, 2016 at 6:01 PM, Kevin M. Gallagher < notifications@github.com> wrote:

The key that is used to sign the Release file / Debian packages in the apt
repository at http://download.jitsi.org/ is a 1024-bit DSA key dating
from 2008, when Jitsi was known as SIP Communicator.

(1) SIP Communicator (Debian package) <deb-pkg@sip-communicator.org>
      1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20

Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably
close to that which might be able to be cracked by a well-resourced
attacker with lots of computational resources.

In addition, there could possibly be concerns about how the private key
has been managed over the years, how many online systems it's lived on,
etc. Keeping the private key offline or on an air-gapped system would be
ideal, but it's also prudent to rotate signing keys after so many years (in
this case, 8).

Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR,
making it appealing to communities with a need for secure communications.
These people also would love to see the processes behind the delivery,
verification and installation of your software be as "secure" as possible.

In conclusion, I recommend that Jitsi generate a new signing key, ideally
4096-bit RSA.


Reply to this email directly or view it on GitHub
<https://github.com/jitsi/jitsi/issues/203>.

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-171681160


#3

+1

···

----- Am 14. Jan 2016 um 1:01 schrieb Kevin M. Gallagher notifications@github.com:

The key that is used to sign the Release file / Debian packages in the apt
repository at http://download.jitsi.org/ is a 1024-bit DSA key dating from
2008, when Jitsi was known as SIP Communicator.
(1) SIP Communicator (Debian package) <deb-pkg@sip-communicator.org>
     1024 bit DSA key 0xC697D823EB0AB654, created: 2008-06-20

Today, in 2016, 1024-bit DSA is generally regarded as being uncomfortably close
to that which might be able to be cracked by a well-resourced attacker with
lots of computational resources.

In addition, there could possibly be concerns about how the private key has been
managed over the years, how many online systems it's lived on, etc. Keeping the
private key offline or on an air-gapped system would be ideal, but it's also
prudent to rotate signing keys after so many years (in this case, 8).

Software like Jitsi supports encrypted protocols like ZRTP/SRTP and OTR, making
it appealing to communities with a need for secure communications. These people
also would love to see the processes behind the delivery, verification and
installation of your software be as "secure" as possible.

In conclusion, I recommend that Jitsi generate a new signing key, ideally
4096-bit RSA.


Reply to this email directly or view it on GitHub .

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Mit freundlichen Grüssen / Kind regards

Rainer Schuth

VNC - Virtual Network Consult GmbH
Professional Services

Pariser Platz 4a, D-10117 Berlin
Tel.: +49 (30) 3464615-20
Fax: +49 (30) 3464615-59

VNC - Virtual Network Consult AG
Poststr. 24, CH - 6301 Zug
Tel.: +41 (41) 727 52 00
Fax: +41 (41) 727 52 09


#4

Seems like it might require some time where there are two official repositories, one with the old key, one with the new key.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-171818740


#5

So yeah, the key transition here will be tricky. I've just experimented with signing the "Release" file in an apt repository with two different keys, but that isn't a solution since both keys are required to be present in the apt keyring in order to verify, and even then it's read as invalid/bad.

It appears that on http://download.jitsi.org/nightly, every package is individually signed, rather than the contents of the whole repo (i.e. the Release file I just referred to). I'm not as familiar with this type of setup personally—also not sure how the repo is being generated or how the signing is performed.

Switching the [repository signing key](https://download.jitsi.org/nightly/deb/unstable/archive.key), without users updating their keyring, will obviously result in errors. The user will see the message "The following signatures couldn't be verified because the public key is not available" when they run `apt-get update`. If they attempt to proceed with installation, they'll see `WARNING: The following packages cannot be authenticated!` and a prompt asking them if they want to proceed without verification.

I am not sure if it makes sense to maintain two repositories during the transition period.

If the Jitsi maintainers want to move forward with transitioning to a stronger key, then it's going to hurt a little. Things will be broken for many people for a while. Admins will begin to see these errors and will hopefully realize that action is required. Other projects have done this before, however, so don't be dismayed.

The best thing that can be done is to prepare for this as fully as possible.

1) Publish a key transition statement, announcing the new key, and providing a couple commands that people can be copy&paste into their shell to update it. (i.e. sudo `apt-key adv --recv-keys KEYID`)
2) Give advance notice (at least a month) to the community, users and developers through as many avenues as possible. Make the notice prominent on the website, GitHub etc.
2) Switch the signing key and re-sign all of the packages in the repository.
3) After a little more time has passed, you can revoke the old key or set it to expire, then propagate the expiry or revocation to keyservers.

If you anticipate that a future key transitions may be necessary again, then encouraging people to install a keyring package ([one such example here](https://github.com/freedomofpress/securedrop-keyring)) alongside their software, which updates the signing key in the apt keyring when that package itself gets updated, could make all this less of a headache.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-171912700


#6

Can't the new key be added to the local repo while the server repo is still signed with the old one?

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-171942422


#7

As I noted earlier, the Jitsi developers have chosen to sign packages individually instead of signing the 'Release' file in the repository, which is unconventional I believe. This results in the following error if you add the repo without having the key:

W: The repository 'http://download.jitsi.org/deb unstable/ Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.

It also appears that right now (1/20/16) things are in a weird state, or the latest packages are unsigned. When I just installed Jitsi from 'deb/unstable', with the signing key definitely in my apt keyring, apt could not find a signature and prompted me to install without verification.

In a previous comment, I also mentioned the utility of a keyring package. It seems that there is already a [SIP communicator keyring .deb](https://download.jitsi.org/deb/unstable/sip-communicator-keyring-udeb_2008.06.23.1_all.udeb) which I hadn't noticed.

···

---
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-173349556


#8

In apt 1.2.11, there is also a warning about the SHA1 digest algorithm used in the Release.gpg signature.

···

---
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-216350428


#9

Here's the present error being thrown by the unstable repo.

W: GPG error: http://download.jitsi.org/deb unstable/ Release: The following signatures were invalid: 040F57608F84BAF1BF844A62C697D823EB0AB654
W: The repository 'http://download.jitsi.org/deb unstable/ Release' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-275179232


#10

Yep this is the old repo which is not used anymore. Try this one:
deb https://download.jitsi.org unstable/

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#issuecomment-275195816


#11

Closed #203 via 2b1dc3757081dd582049fb16a8421f486ae162df.

···

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/jitsi/jitsi/issues/203#event-952079140