-
Notifications
You must be signed in to change notification settings - Fork 27
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
Comments
Good idea ! This is useful for non-database applications. |
This is especially desirable since, as per
|
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. |
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. |
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. |
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. |
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. |
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? "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. |
Apps from Obtainium downloaded from Github for example fit that category of secure app store? |
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. |
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. |
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. |
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. |
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. |
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. |
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). |
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." "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" |
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. |
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). |
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.
The text was updated successfully, but these errors were encountered: