Insecure/Insufficient Signing Key Length

[mottla]

I am worried about the signing scheme applied to sign the apk files. (I assume its the same for windows and mac as well)

Currently: Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 1024-bit RSA key

My opinion: 1)This key length is too close to the most recent published successful rsa modulus factorizations. According to Wikipedia https://en.wikipedia.org/wiki/Integer_factorization_records 795 bits in 2019. The budged of the publishers is insignificant in comparision to some well known agencies. Assuming that 1024 bits are still secure is unwise.

2)regarding the use of SHA1: Google has advocated the deprecation of SHA-1 for many years. Collisions were found and forged as well. SHA1 is not a cryptographic building block. Better get rid of it immediately!

Since I deeply appreciate your work, I beg you to update your signing procedure. Publish a pgp key with at least 2k bit security and sign the ENTIRE projects sha256 hash, as its done commonly.

[johanw666]

I could not find your signing key somewhere.

Of course not, that key is kept private. Otherwise everyone could build a backdoored Signal and sign it with their official key so Android would accept it as being genuine.

According to APK Info the key uses a SHA-256 hash.

The apk uses 3 signatures, v1, 2 and 3. If you want the apk to work on Android 6 and below it needs to be also signed with jarsigner according to https://source.android.com/security/apksigning/v2

[mottla]

Thanks for the info! A signing key consists of two parts. one is public and one is supposed to be kept private. If someone writes "i could not find your key", he or she usually refers to the public part.

According to APK Info the key uses a SHA-256

keytool -list -printcert -jarfile Signal-website-release-4.1X.apk tells me its sha1

[johanw666]

A public key does not have a hash, tat's something completely different. You can calculate any hash from the public key, even CRC32 if you like. Your command on the latest apk shows me this:

keytool -list -printcert -jarfile Signal-Android-play-armeabi-v7-4.53.7.apk
Signer #1:

Signature:

Owner: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pit
tsburgh, ST=PA, C=US
Issuer: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pi
ttsburgh, ST=PA, C=US
Serial number: 4bfbebba
Valid from: Tue May 25 17:24:42 CEST 2010 until: Tue May 16 17:24:42 CEST 2045
Certificate fingerprints:
         MD5:  D9:0D:B3:64:E3:2F:A3:A7:BD:A4:C2:90:FB:65:E3:10
         SHA1: 45:98:9D:C9:AD:87:28:C2:AA:9A:82:FA:55:50:3E:34:A8:87:93:74
         SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0:EA:FB:A2:DA:35:
AF:35:C1:64:16:FC:44:62:76:BA:26
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 1024-bit RSA key
Version: 3

AFAIK the SHA1withRSA is mandatory for Android apk signing. at least for the v1 signatures. But please correct me if I'm wrong here.

[mottla]

Thank you again. Yes hashfunctions and asymetric crypto are tools which rely on different assumptions, however often used in combination.

AFAIK the SHA1withRSA is mandatory for Android apk signing. at least for the v1 signatures.

So youre indicating that its mandatory for Signal to have an highly vulnerable distribution mechanism? But please correct me if I'm wrong here.

[Safari77]

Android 9 supports APK Signature Scheme v3, and with the APK key rotation feature the 1024 bit key could be upgraded.

Supported keys sizes and EC curves: RSA: 1024, 2048, 4096, 8192, 16384 EC: NIST P-256, P-384, P-521 DSA: 1024, 2048, 3072

https://source.android.com/security/apksigning/v2 https://source.android.com/security/apksigning/v3

[mottla]

Thank you Safari! So Signal uses version 3 with the weakest possible choice of signing key lenght and a self signed certificate. (DSA 1024 might be less secure, but I didnt check weather solving DLP is harder then factoring)

[drduh]

RSA 1024 and SHA-1 are not secure for signing production releases. Please upgrade the APK signing key ASAP. Alternatively, please provide hashes of APK releases signed using stronger cryptographic primitives. Ref: https://github.com/signalapp/Signal-Android/issues/6833

[pgnd]

RSA 1024 and SHA-1 are not secure for signing production releases. Please upgrade the APK signing key ASAP. Alternatively, please provide hashes of APK releases signed using stronger cryptographic primitives. Ref: #6833

Has there been any further decision/progress/clarification on this?

Just installed Signal 5.9.2 -- on several Android 10 phones -- and happened to be checking APKs' signing algos. Many report as SHA256withRSA

Signal 5.9.2 reports: SHA1withRSA, as do some others.

https://github.com/signalapp/Signal-Android/issues/6833 still seems unresolved.

Is this languishing/ignored & we should be concerned, or @cody-signal is there a legit reason for remaining on 'insecure' SHA1-signed Signal app?

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[drduh]

This isn't stale. It's a security issue and a pretty severe one at that.

[DiagonalArg]

Not only severe, but in discussion since 2017. For me, at least, this really brings into question the commitment to security of this project.

[johanw666]

What can they do? Change key? That would make almost all updates impossible. And besides, with current Google policy they will be forced to deliver Signal as an app bundle then and give their signing key to Google. A much more serious security breach becaus it would permit (some government to force) Google to send a backdoored version to selected individuals.

[DiagonalArg]

What can they do? Change key? That would make almost all updates impossible.

Why would this be?

And besides, with current Google policy they will be forced to deliver Signal as an app bundle then and give their signing key to Google. A much more serious security breach becaus it would permit (some government to force) Google to send a backdoored version to selected individuals.

That is grim. I hadn't understood this issue.

A friend is also telling me they are already forced to link to the Google Mobile Services library at runtime.

Perhaps it should only be installed as an .apk from the website?

[ehdis]

Current status:

$ LANG=C keytool -printcert -jarfile Signal-Android-website-prod-universal-release-5.40.4.apk 
Signer #1:

Signature:

Owner: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Issuer: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Serial number: 4bfbebba
Valid from: Tue May 25 17:24:42 CEST 2010 until: Tue May 16 17:24:42 CEST 2045
Certificate fingerprints:
     SHA1: 45:98:9D:C9:AD:87:28:C2:AA:9A:82:FA:55:50:3E:34:A8:87:93:74
     SHA256: 29:F3:4E:5F:27:F2:11:B4:24:BC:5B:F9:D6:71:62:C0:EA:FB:A2:DA:35:AF:35:C1:64:16:FC:44:62:76:BA:26
Signature algorithm name: SHA1withRSA (weak)
Subject Public Key Algorithm: 1024-bit RSA key (disabled)
Version: 3

Warning:
The certificate uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update.
The certificate uses a 1024-bit RSA key which is considered a security risk and is disabled.

Does someone has an activity plan for the necessary steps to address this issue? Thanks.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been closed due to inactivity.

[cody-signal]

Hi there, we are aware and planning to do this soon.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Ammako]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[oven8Mitts]

The Shattered.io SHA1 hash collision attack took 9,223 Petahashes to create a SHA1 hash collision with 2 PDF files. An RTX 4090 can compute 50.6 gigahashes per second, give or take. This is 135 petahashes per month.

This gives a grouping of 10 RTX 4090 video cards about 7 months before Signal's signature is permanently comprised for that specific release.

This is well within the range for a University or cryptocurrency miner to accomplish, and it is approaching the range for the average person to accomplish as well. Obviously this is a rough estimate.

Can a government acquire 100-200 RTX 4090 video cards and accomplish this in a half a month? Sure. I could show you cryptocurrency mining warehouses with more video cards than that.

When does Signal plan on resolving this issue?

[rusty-snake]

I'm not an cryptography expert. But I have to note that finding two PDFs with the same hash is easier than finding a PDF (or key or whatever) that has a wanted hash.

https://en.m.wikipedia.org/wiki/Birthday_problem

[oven8Mitts]

I'm not an cryptography expert. But I have to note that finding two PDFs with the same hash is easier than finding a PDF (or key or whatever) that has a wanted hash.

https://en.m.wikipedia.org/wiki/Birthday_problem

Per Google, this is the first ever Sha1 collision. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html?m=1 The Shattered.io paper, coauthored by Google, also accounted for the birthday paradox and identified it as infeasible.

[rusty-snake]

TIL

The birthday paradox does not apply there because it's a chosen prefix collision.

[askAvoid]

Hi there, we are aware and planning to do this soon.

We're coming up on the two year anniversary of this comment.

I think Signal users are long overdue for an update to this obvious security vulnerability.

[johanw666]

If you followed the commits you'd known that Signal "solved" this. They use a stronger apk signing key now. But according to Google Play rules, that means they had to switch to split apk's and give this key to Google to sign the parts so this only possible "solution" isn't really an improvement IMO.

[cody-signal]

As of version 7.10, which finished rolling out on July 8th, Signal Android is now signed with a 4096-bit key and the reproducible build instructions have been updated to support App Bundles too.

In addition to reproducible builds, we are also utilizing Android's code transparency mechanism, and you can continue to verify that our application code is signed by us (with a key unknown to Google) by following these instructions.

App Bundles can be dual-signed in Android’s v3.1 signature scheme, and users on older versions of Android that haven't been updated can still use the legacy 1024-bit signature.

Due to improving attacks and the smaller size of the original signature key, we also felt we needed to upgrade. Unfortunately, Google currently only supports rotating keys after switching to App Bundles, and App Bundles currently require Play App Signing support too. We attempted to rotate our signing key directly without going through the App Bundle process several times only to repeatedly discover that Google Play does not support this. This appears to be part of a larger initiative at Google towards App Bundles, which have been required for all new apps on the Play Store since August 2021.

We will happily rotate to another signature scheme and key in the future if Google ever addresses these limitations — and we encourage them to do so. While we wish Google had made this process easier, we felt the smaller 1024-bit signature size was becoming a greater concern.

We're committed to supporting reproducible builds and code transparency verification on Android, and you can still get our Android APK directly from us here as a larger "universal" APK (instead of an App Bundle) that can be installed on all devices.

[askAvoid]

The previous comment makes very little sense.

I am using the latest Ubuntu 24, I installed apksigner and android-sdk from apt then ran the verification command

apksigner verify -v --print-certs --min-sdk-version 24 Signal-Android-website-prod-universal-release-7.13.4.apk
Verifies
Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): false
Verified using v4 scheme (APK Signature Scheme v4): false
Verified for SourceStamp: false
Number of signers: 1
Signer #1 certificate DN: CN=Whisper Systems, OU=Research and Development, O=Whisper Systems, L=Pittsburgh, ST=PA, C=US
Signer #1 certificate SHA-256 digest: 29f34e5f27f211b424bc5bf9d67162c0eafba2da35af35c16416fc446276ba26
Signer #1 certificate SHA-1 digest: 45989dc9ad8728c2aa9a82fa55503e34a8879374
Signer #1 certificate MD5 digest: d90db364e32fa3a7bda4c290fb65e310
Signer #1 key algorithm: RSA
Signer #1 key size (bits): 1024
Signer #1 public key SHA-256 digest: 75336a3cc9edb64202cd77cd4caa6396a9b5fc3c78c58660313c7098ea248a55
Signer #1 public key SHA-1 digest: b46cbed18d6fbbe42045fdb93f5032c943d80266
Signer #1 public key MD5 digest: 0f9c33bbd45db0218c86ac378067538d
WARNING: APK Signature Scheme v3 signer #1: Unknown additional attribute: ID 0x559f8b02

The output indicates the package is still signed with a 1024-bit key. So I think the verification documentation still needs additional work to address the concerns raised.

[johanw666]

The apk is ALSO signed with the old key to allow installation on older Androids and upgrades without having to reinstall.

[askAvoid]

So nothing is really fixed: an adversary can still factor a single RSA 1024 key to impersonate Signal as before.

We got a word salad from @cody-signal and no real discussion, threat analysis, nor technical documentation from the team for why this risk continues to exist.

@johanw666 I don't follow your comments -

with current Google policy they will be forced to deliver Signal as an app bundle then and give their signing key to Google. A much more serious security breach becaus it would permit (some government to force) Google to send a backdoored version to selected individuals.

that means they had to switch to split apk's and give this key to Google to sign the parts so this only possible "solution" isn't really an improvement IMO.

So the existential risk of handing the signing key to Google you voiced in 2022 already did take place? Or would need to take place to address the risk of weak keys? Please clarify.

Bottom-line: what is the safe way to install Signal on Android without access to Play Services?

[greyson-signal]

Hi @askAvoid. I encourage you to read up on the key rotation process for Android. https://source.android.com/docs/security/features/apksigning/v3-1

We use a newer, stronger key that is validated on newer versions of android. Older versions of android don't understand the v3.1 signature and will therefore use the older signature. Regardless, even for newer versions of android, we need to include the older signature so that a user can upgrade from a build signed with the older key.

This is the standard and recommended process for upgrading an Android signing key.

If you'd like to install a version of the app without using the Play Store, you can get it directly from us on our website.

At the bottom of that download page, you'll see instructions on how you need to use the latest version of apksigner to see the new 4096-bit signature. The version of apksigner that you get from apt is unfortunately pretty out of date, which is why you're not seeing it. This is indicated in the last line of the console output you shared:

WARNING: APK Signature Scheme v3 signer #1: Unknown additional attribute: ID 0x559f8b02

Regarding the rest of your comments, I think @cody-signal's write-up is relatively clear and covers everything else.

[askAvoid]

I just told you I'm using Ubuntu 24, which is the most popular version of desktop Linux in use.

And you respond by saying it ships with broken tools which make verifying the 4096-bit signature infeasible.

Do you really not see the need to improve your documentation? Or do you just not care?

Please update to the latest version of the Android SDK Build Tools for the best experience.

How about mentioning the fact there is a critical security vulnerability, and how to address it, instead of the weird "best experience" euphanism for a start?

[rusty-snake]

Ubuntu ships horribly outdated tools? I'm not surprised.

[ehdis]

Further informations:

https://source.android.com/docs/security/features/apksigning/v2?hl=en#rollback-protections

https://source.android.com/docs/security/features/apksigning/v3?hl=en#verification

If there are concerns about security, then the user should not use an old android runtime, obviously.

[greyson-signal]

Thanks for the additional documentation links! I think at this point I'm comfortable saying that this issue has been fully resolved to the best of our ability using standard practices.

Verifying signatures, knowing the difference between 1024-bit and 4096-bit keys, understanding android signature schemes -- these are all relatively technical things. In order to get value from them, one needs to take the time to understand what they are, how they work, and why they're useful. I think the level of documentation we provide is appropriate in that context.

I'm going to lock this issue because I don't think any further discussion will be constructive. Thank you all!