1024-bit signing keys should be deprecated

[deutrino]

1024-bit RSA was deprecated years ago by NIST[1], Microsoft[2] and more recently by others[3].

1024-bit signing keys are insufficient to guarantee the authenticity of software distributed from Launchpad.net including PPAs. There should be a mechanism to refuse signing keys below a minimum key length based on key type. 1024-bit signing keys should be deprecated and removed from Launchpad.net itself ASAP. Future projects and PPAs should be disallowed from using 1024-bit signing keys.

1. http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
2. http://blogs.technet.com/b/pki/archive/2012/06/12/rsa-keys-under-1024-bits-are-blocked.aspx
3. https://threatpost.com/mozilla-1024-bit-cert-deprecation-leaves-107000-sites-untrusted/108114

[Micah Lee (micahflee)]

+1, I agree that this is very important.

[Patrik B. (inoki-deactivatedaccount)]

Agreed and supporting the idea. +1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Seth Arnold (seth-arnold)]

It might be nice if apt could be configured with "minimum accepted algorithms" or "required algorithms", to allow administrators to require e.g. sha256 or sha3 or blake2b, or rsa 4096 or ed25519, etc.

[William Grant (wgrant)]

Launchpad has used 4096-bit RSA keys for new PPAs since bug #1240681 was fixed. Allowing PPA owners to replace the old 1024-bit keys is bug #1331914.

[deutrino (deutrino)]

I disagree with the "no longer affects" Launchpad. This is a matter of policy and as such very definitely DOES affect Launchpad, regardless of the resolution of bug #1331914.

[Bob Freeman (bobfreeman)]

Updates usually run automatically in the background, including from PPAs, and are unencrypted. This means a man-in-the-middle can gain root access, just by inserting their own version of one of the packages into this network traffic, because updates run as root. They can first obtain the public 1024 bit key from the PPA, then spend as long as they want working out the private key, then sign their false updates with the real private key.

A bug that allows complete compromise of most Ubuntu machines without requiring any user involvement is a very serious bug. Why hasn't this even been assigned to anyone, nearly 2 years after it was reported?

This makes many PPAs unusable.

https://en.wikipedia.org/wiki/Key_size#Asymmetric_algorithm_key_lengths
'RSA claims that 1024-bit keys are likely to become crackable some time between 2006 and 2010'
https://www.symantec.com/page.jsp?id=1024-bit-migration-faq#issue
In compliance with Certification Authority/Browser forum requirements based on NIST Special Publication 800-131A, at the end of 2013 all web browsers and Certification Authorities (CAs) will no longer sell or support 1024-bit RSA certificates. All certificates less than 2048-bit key length will need to be revoked and replaced with certificates with a higher encryption strength.

Network connections are secured with at least 2048 bits. Installing software allows root access and should probably be secured with at least 4096 bits.

Any system using keys has to have a way to change to a new key, that's a basic requirement.
You could force all 1024 bit keys to 4096 bits - this might break existing updates, but they are already 'broken' by being vulnerable. Or sign with 2 keys, so a new subscriber will only use the newer one, but old subscribers who don't do anything about it will still use the old key. Or re-issue the entire PPA namespace, ie ppa2:... Or do some other such thing, eg update the client to include a newer protocol version number in its requests.

A simple workaround for launchpad to apply would be to change the urls in files in /etc/apt/sources.list.d/ to use https://ppa.launchpad.net/ instead of http://ppa.launchpad.net/ (and change the server to support it). This would only need to be done for any PPA still using a 1024 bit key. Then at least the packages would be authenticated by TLS, which already uses 2048 bit keys.

[Bob Freeman (bobfreeman)]

Launchpad could *automatically* create a mirror of any PPA that still uses a 1024 bit key, with a standard suffix to the name, eg xyzppa gets mirrored as xyzppa-newkey. It could then link to it from the page for the original PPA. It would always have all the same source, built files and other content, and the content would only need to be stored once on the server. It would just be a different way of accessing the same PPA.

[deutrino (deutrino)]

> This means a man-in-the-middle can gain root access, just by inserting their own version of one of the packages into this network traffic, because updates run as root. They can first obtain the public 1024 bit key from the PPA, then spend as long as they want working out the private key, then sign their false updates with the real private key.
>
> A bug that allows complete compromise of most Ubuntu machines without requiring any user involvement is a very serious bug. Why hasn't this even been assigned to anyone, nearly 2 years after it was reported?

I suppose people will be wondering why it wasn't fixed once a Snowden-style leak drops showing that this vulnerability was exploited for years.

[Julian Andres Klode (juliank)]

APT currently rejects all non-SHA2 hashes, which excludes 1024 bit DSA keys (the only 1024 bit keys in use, really). All repositories were told to update to 2048 or 4096 bit RSA keys.

GPG does not provide a way for APT to validate key lengths when the signature is verified, so we did all we could do here. Any future change needs to be made in gpg (reject all DSA/RSA keys less than 2048 bit).

[Julian Andres Klode (juliank)]

Side note: It's incredibly funny how the bug report talks about 1024 bit RSA keys, when such keys have likely never been used by anyone (all 1024 bit keys I know about were DSA).

[Julian Andres Klode (juliank)]

Regarding launchpad: I'm not sure what that bug is achieving. The proposal with the rename is fairly useless, you could just add the safe key to the existing repository. The biggest problem in practice is rolling out a new key to users, as there is no mechanism for that.

[Colin Watson (cjwatson)]

Julian, I'm afraid that for better or worse Launchpad did generate 1024-bit RSA keys for PPAs for quite some time, and that wasn't an entirely silly decision back when it was first made - even then DSA had known weaknesses. It's a problem, but as you say we'd need to work out a rollover mechanism. Signing with two keys is certainly a possibility (we did that with the Ubuntu archive for a while, so it's battle-tested), and I expect that any solution to this would involve that, but there's no clear way to end the transition.

Bob, I'm afraid that your proposed "simple" workaround is no such thing (a naive implementation would expose launchpad.net to XSS attacks from user-supplied content on ppa.launchpad.net). I listed the issues that would need to be solved in bug 1473091. Anyway, TLS is a side issue here and this bug shouldn't be derailed into that.

We are very unlikely to do any of the proposed renaming/mirroring hacks; they would be a mess and likely a cure worse than the disease.

[Bob Freeman (bobfreeman)]

Sign with two keys then, and try to tell people. After a period of time you could disable the old key (ie no longer sign anything with it) - for anyone who still hasn't updated their configuration their system will still work, but instead of updates they would get errors. Then they would update their config.

(Note that all PPA packages are already available through TLS, eg https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/+build/8797131/+files/cmake-qt-gui_2.8.12.2-3_amd64.deb but only for manual download. It is not used automatically by apt, so to be secure you have to identify and manually download a lot of packages. These can be found through the 'View package details' link at the top right on all PPA main pages)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bob Freeman (bobfreeman)]

> GPG does not provide a way for APT to validate key lengths when the signature is verified, so we did all we could do here.

Some pages, like https://launchpad.net/~fnu/+archive/ubuntu/main-fnu/ say "Signing key: 1024R" when you click on "Technical details about this PPA". So launchpad clearly knows, and at the very least it *must* put a big warning on such pages, so as not to fool users into compromising the security of their computers. It's not true to say there's nothing launchpad can do.

Since the underlying problem is clearly real, why is this launchpad bug still 'New' and not 'Confirmed' after more than 6 years 2 months?

[Martin (c0rn3j)]

Why is this still a thing, nearly a decade after NIST disallowed the usage? [1]

Why is it not possible for users to regenerate their signing keys? [2]

What if someone believes their key is compromised? Do they have to burn their work and create an entirely new page and direct their users there?

What if someone created a key with RSA 1024 and would like to migrate it to a secure variant? Looks like they can't. [2]

And it shows, because even very popular PPAs like ondrej/php are using RSA1024 keys from 2009, and it does not look to be their fault. [3]

[1] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/announcements/2013-announcements
[2] https://bugs.launchpad.net/launchpad/+bug/1331914
[3] https://github.com/oerdnj/deb.sury.org/issues/1429#issuecomment-656190271

[Julian Andres Klode (juliank)]

What I'd like to see is that

1. launchpad starts dual-signing repositories
2. ubuntu-release-upgrader gets a quirk that replaces any unsafe PPA keys on upgrade to kinetic+ (jammy backport possible too, but arguably people might have already upgraded)
3. Drop 1024 bit keys for kinetic+

This will lead to everyone running kinetic and newer to at least use RSA keys.

[Jake Lepere (jrlepere)]

Enabling FIPS on Ubuntu Pro 22.04+ machines [1] drops rsa1024 as an available encryption key because rsa1024 isn't FIPS compliant. Therefore, adding rsa1024 signed apt keys here isn't possible.

Does anyone have suggestions to work around this? I've asked if maintainers could resign apt keys for relevant repos but haven't heard back. Additionally, adding apt keys before enabling FIPS works, but future apt updates unfortunately fail afterwards.

[1] https://ubuntu.com/security/certifications/docs/fips-enablement

[Seth Arnold (seth-arnold)]

Jake, some progress is underway for Launchpad to automatically sign PPAs with RSA4096 keys https://discourse.ubuntu.com/t/new-requirements-for-apt-repository-signing-in-24-04/42854

It's also possible to dual-sign non-ppa repositories, eg:

curl -s http://archive.ubuntu.com/ubuntu/dists/focal-updates/InRelease | gpg --verify

This can really help migrating from unsafe key sizes to safe key sizes.

Thanks