3 ms·

From the linked documentation: > The code transparency file does not verify resources, assets, the Android Manifest, or any other files that are not DEX files

From the linked documentation: > The code transparency file does not verify resources, assets, the Android Manifest, or any other files that are not DEX files or native libraries contained in the lib/ folder. > Important: The Android OS does not verify code transparency files at install time, and continues to rely on the APK signing schemes for verification of any installed APKs. Do I understand it right that it basically means user's device doesn't care about this signature at all? Wouldn't that make it pretty easy to supply modified versions of app to specific devices without them noticing, unless users decide to check signatures by themselves?

ridaj 5y ago
Right, it's not checked by the device. Its purpose seems to be more forensic: say an app version turned out malicious, and the developer said it wasn't me, Google was pwn3d and used my keys to sign malware. Code transparency would allow a developer to prove that tampering had occurred between their build of the app bundle and the user installation. It looks more like an accountability mechanism in case of failure than a protection.
the-rc 5y ago
That's right, the transparency signature is not checked during installation. If you think somebody at Google might be out to get you and has all those powers and resources, there are many ways other than serving bespoke bundles, even with good old APK. Since they control the store and the system software that goes with it, they could download and save the original APK to give you some false sense of security, but apply a patch before extraction or code compilation. Or they could just crack the developer's signing key by using spare processing resources across their fleet, at least for anything comparable to RSA-1024 or lower. Those three attacks are theoretically feasible, but, I think, all equally hard to pull off without detection inside or outside the company.

ridaj 5y ago

Right, it's not checked by the device. Its purpose seems to be more forensic: say an app version turned out malicious, and the developer said it wasn't me, Google was pwn3d and used my keys to sign malware. Code transparency would allow a developer to prove that tampering had occurred between their build of the app bundle and the user installation. It looks more like an accountability mechanism in case of failure than a protection.

the-rc 5y ago

That's right, the transparency signature is not checked during installation. If you think somebody at Google might be out to get you and has all those powers and resources, there are many ways other than serving bespoke bundles, even with good old APK. Since they control the store and the system software that goes with it, they could download and save the original APK to give you some false sense of security, but apply a patch before extraction or code compilation. Or they could just crack the developer's signing key by using spare processing resources across their fleet, at least for anything comparable to RSA-1024 or lower. Those three attacks are theoretically feasible, but, I think, all equally hard to pull off without detection inside or outside the company.