[liberationtech] From Snowden's email provider. NSL???

[Michael Rogers]

> The app store can't substitute a different binary (no developer signing key), users can verify that the app was what the developer produced (via pulling the binary and checking the hash), and advanced users can verify that what the developer produced is what they produce via the replicable build process.

I don't know how the Apple or Chrome app stores work, but on Android the user doesn't have a standard way to obtain the developer's key, so the app store could sign a modified binary with any key.

In any case, verifying a signature or hash against a public key or expected hash (obtained how?) is currently a manual process that non-experts can't be expected to carry out, let alone understand. What I'm looking for is a way to automate that process to protect non-experts.

As far as I can see, locked-down platforms like iOS and ChromeOS make it impossible in theory to tell whether the trust root (Apple/Google) is providing binaries built from published source code, because there's no way to get a verifier onto the device unless it's also approved (and potentially tampered with) by the trust root. But I think the situation for browser-downloaded software and Android apps might be less bleak.

One aspect that concerns me is rollback attacks: if the verifier accepts binaries that aren't listed in the public log, can the adversary tamper with the identifying attributes of the tampered binary (name, URL, etc) so the verifier doesn't realise there's a log entry that the binary should match?

Cheers,
Michael