Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mark Apps as Verified After Signature Verification #153

Open
NarwhalPrince opened this issue Apr 7, 2024 · 20 comments
Open

Mark Apps as Verified After Signature Verification #153

NarwhalPrince opened this issue Apr 7, 2024 · 20 comments
Labels
enhancement New feature or request

Comments

@NarwhalPrince
Copy link

It would be helpful to add the ability to mark Apps as "verified" once the signature has come back with "Success" when manually verifying.

It could be an option presented after achieving a successful verification, but not automatic or mandatory.

@ghost
Copy link

ghost commented Jun 19, 2024

Good idea !
AppVerifier can save the pasted signature.
If it's matches with the pasted signature, you can show a new success icon with a different color.

This is useful for non-database applications.
Thanks

@soupslurpr soupslurpr added the enhancement New feature or request label Jul 5, 2024
@hseg
Copy link

hseg commented Nov 19, 2024

This is especially desirable since, as per CONTRIBUTING.md

Contribution of new apps to the internal verification info database won't be accepted at this time.

@epicalxyz
Copy link

I fail to understand whats the purpose of this app if I can't compare an APK with an installed app and have a way to know what I have verified already or not. Hopefully someone comes up with a fork or something.

@NarwhalPrince
Copy link
Author

@epicalxyz

The purpose of the app is not nullified by not having this feature. You can make sure to verify apps using the certificate hash as you sideload apps. Feel free to keep a note of which are verified.

@epicalxyz
Copy link

Not nullified but I don't get whats the point of it at this current state. Is it supposed for us to just wait for you to add apps to the database and have some verifications while missing 90% of the user apps.
Even if i verify an app theres no indication of it. I'm pretty sure you can download an apk from a trusted source and compare it with the installed one, that should be a valid method of verification. But without a record of whats been verified or not whats even the point. That app list could show the database verifications as well as the manually verifications from downloaded apks and when an app updates that could be re-verified using a previous knowledge of the app version and the existing certificate, keeping track of any changes in the certificates. A change doesnt mean that theres an issue because of rotations but could indicate something.

@soupslurpr
Copy link
Owner

Features require time and effort to develop. As @NarwhalPrince said, you can manually take note of which apps you verified yourself. Ideally all your apps come from secure app stores so that they're already verified.

@NarwhalPrince
Copy link
Author

The point is still there without having a verification mark. Where you have the verification mark is completely arbitrary, whether it's in the app or in a note you keep on the side.

You don't verify after updates and there is no need to re-verify apps after installing them. The entire point of this is to verify APKs before installation or immediately after installation using a signing key certificate hash to verify the authenticity and that it is signed correctly. You don't re-verify after updates because the OS prevents updates to apps that have mismatched fingerprints.

When you install an app, the certificate is pinned across the entire system. This is Trust on First Use. App Verifier exists as a stopgap for sideloading when you don't have the benefit of an app store which verifies the authenticity for you.

@epicalxyz
Copy link

Thanks for the explanation on the lack of need to do re-verifications.

I guess the mark would be to keep track, is that or a paper, but if I'm making notes on "paper" why even use an app?
Just manually compare hashes o paper too while you're at it.

"The entire point of this is to verify APKs before installation or immediately after installation" or when you want. Many of us had apps installed before knowing about this app, and we want to verify them all and in an organized manner without using paper if possible.

I guess what I'm talking about is basically in adding more methods of verification and a way to keep track of what's been verified.

@epicalxyz
Copy link

epicalxyz commented Jan 28, 2025

Features require time and effort to develop. As @NarwhalPrince said, you can manually take note of which apps you verified yourself. Ideally all your apps come from secure app stores so that they're already verified.

Apps from Obtainium downloaded from Github for example fit that category of secure app store?

@NarwhalPrince
Copy link
Author

Apps from Obtanium do not fit that category. Obtanium is essentially a web scraper and you are sideloading, not getting apps from an app store that does secure verification of uploads and verification of what is downloaded to your device. You have no chain of trust. Secure app store examples would be Accrescent or the Google Play Store.

Also, it's probably a lot faster to just keep a running list of which apps are "checked off" than to write down and compare all the hashes. Just imo.

@epicalxyz
Copy link

One more reason that we should compare hashes and verify if the app we're getting is like the one from a secure app store.

@NarwhalPrince
Copy link
Author

That is actually why we should stick to only downloading from secure app stores, but that's another conversation. I'll stop clogging up this issue thread.

@epicalxyz
Copy link

There are many sources of trusted apps that aren't secure app stores. For example, WhatsApp website has a direct link to its APK, many devs in GitHub release Google Play versions in its repos, maybe the same versions they send to Google Play. Bitwarden has its own F-Droid store and also release those in GitHub. Now, if we just had an app to verify if they are the same and maybe keep track of it, that would be nice.

@NarwhalPrince
Copy link
Author

I think there is a slight misunderstanding. The whole point is that they apps are acquired through an app store with proper security measures. It doesn't matter if the same app is posted as a download link as the version that exists in the Play Store. The issue is that you are downloading an asset directly from a site where they may not be verifying the file was uploaded by the original app signer, and then you are not verifying the APK file that you actually download. This is open to attacks.

Downloading an app from a website, GitHub, random app repo, are all variations of sideloading which lacks a chain of trust.

On most stock OSes, you typically have the Google Play Store which is installed as a system privileged app, and is verified along with the OS by verified boot. Then the Play Store verifies everything in it and what is actually downloaded to your device. This is the chain of trust that is lacking when you sideload.

@epicalxyz
Copy link

As I understand it, every APK is signed with a developer's private key before distribution. This signature is included in the APK and ensures that the file hasn't been tampered with after signing. The corresponding certificate fingerprint acts as a unique identifier for the developer.

If an APK is modified, the original signature becomes invalid. To re-sign the altered APK, the developer's private key is needed.

When verifying an APK, tools or systems check the signature's validity and compare the certificate fingerprint with a trusted source. A mismatch indicates the APK has been tampered with or is signed by someone else.

AppVerifier could verify if the APK is from a trusted source, and that trusted source could initially be from a safe origin like Google Play and stored locally, giving the responsibility to the user to keep safe.
In other words, if the maximum trust comes from Google Play, then get the initial certificate fingerprint from there and from that point on it doesn't matter if the APK comes from GitHub or a random USB Pen you find on the street, if the hash matches the developer was the same.

@NarwhalPrince
Copy link
Author

NarwhalPrince commented Jan 28, 2025

You've got it there for the most part. But App Verifier can't "know" that any particular APK is verified to be from a "trusted source" only that it has the expected certificate fingerprint. Which brings us back to how it's implemented now, which is that some app fingerprints are in the internal database.

The next issue is that Play Store signing is becoming more prevalent causing the issue that an app might be distributed via sideloading or Accrescent (for example) and have the developer's signing key certificate, but the Play Store doesn't match that, so can't be used for a point of reference or verification. The best case then would be that the app developer provided the certificate hash out of band from where the app is provided for the sideloading methods (not Accrescent).

@epicalxyz
Copy link

epicalxyz commented Jan 28, 2025

First let me say that no solution will be perfect, but I think it can improve a lot.

"But App Verifier can't "know" that any particular APK is verified to be from a "trusted source" only that it has the expected certificate fingerprint."
This is exactly what I mean. AppVerifier doesn't know anything, the user is the one that has to get the initial source of truth from a secure origin like Google Play or a certificate hash from the dev itself.

"Which brings us back to how it's implemented now, which is that some app fingerprints are in the internal database."
Do you have an example of app that we cant source the certificate hash from?

"The next issue is that Play Store signing is becoming more prevalent causing the issue that an app might be distributed via sideloading or Accrescent (for example) and have the developer's signing key certificate"
If the dev releases an app with a different signing key is something you will know and either contact the dev to provide the certificate hash like you said or just verify against itself. If you trust the dev.

@mariaa144
Copy link

I use Obtanium on GraphineOS without the Play Store installed. I expected to be able to verify the hash of the APK before installation so I could have some reassurance that the app was what the developer intended to be published over simply downloading it from Github, FDroid or the app website.

@NarwhalPrince
Copy link
Author

I use Obtanium on GraphineOS without the Play Store installed. I expected to be able to verify the hash of the APK before installation so I could have some reassurance that the app was what the developer intended to be published over simply downloading it from Github, FDroid or the app website.

You achieve that by installing the app from a secure, trusted store like Accrescent or Play Store. App Verifier exists to mitigate some of the security issues with sideloading, not to replace app stores when used with Obtanium.

@mariaa144
Copy link

mariaa144 commented Feb 12, 2025

That's too bad because many apps are not on Accrescent that I use and I prefer not to use the Play Store because of privacy issues with Google. I feel like AppVerifier would have been a good fit with Obtanium for installing apps not available on Accrescent (and the Play Store in many cases).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

5 participants