On 06/24/2014 06:28 PM, Mark Murphy wrote: > On Tue, Jun 24, 2014, at 18:06, Hans-Christoph Steiner wrote: >> I have the first working version of the TrustedIntents library. > > Very cool! > > Your "trusted chooser" will be important. I would expect as much, if not > more, malware to be packaged under package names different than their > original ones. Users don't see package names, after all. So, if a user > has installed a hacked Twitter client, it's important that they *don't* > see that client come up in the trusted chooser, both to avoid using it > and to start wondering "hey, why isn't my Twitter client showing up?". > While the trusted chooser might not be warning them that they installed > a hacked Twitter client, since it is under some other package name, the > user at least gets a bit of a clue that something is amiss.
Yeah, that's a nice idea, I hadn't thought of that. So a pre-cooked version of Intent.createChooser() that includes a whitelist of package names and their associated signing keys. I'll give that a shot right now. > I was doing some brainstorming recently in an adjacent space: > crowdsourcing some herd immunity against hacked apps. While I haven't > come up with a workable plan yet, one idea that I had might be relevant > to you. For developers that actually follow the guidance of using > reverse domain names as the basis for package names, we could adopt an > SPF-type system, where the SHA-256 hash of the signing key is available > as a DNS entry for the corresponding domain name. So, for example, if I > published com.commonsware.this.app.is.cool as an app, a > specially-crafted TXT entry for cool.is.app.this.commonsware.com would > contain the signing key hash for that app. This would give us a means of > validating the installed app's signature beyond whatever known good > hashes are baked into the library or app. It's not as strong as I'd > like, insofar as an Android app package name is not as tightly tied to a > domain name as is a Web site. But, it might be a useful lookup as part > of helping the user confirm whether the app is OK. > > Anyway, just a thought. Also, bear in mind that I am not a security > expert, so take this idea with a fairly large grain of salt. There are a number of similar proposals out there, I think this could be useful. The way I think about is related to TOFU/POP (Trust On First Use/Persistence of Pseudonym aka ssh-style verification). So TOFU/POP is dead simple and has quite a good track record. But for higher risk situations, it is not as easy as it should be to verify the key on First Use is indeed the key you expect. So while this DNS method would not provide an infallible verification method, it would provide a transparent way to improve the situation. I've been thinking about applying a similar idea to TLS/HTTPS using the regular CA infrastructure. Basically just add TOFU/POP to TLS/HTTPS so that when making a TLS connection, an app first verifies using its local TOFU/POP store. If it is presented with a domain is doesn't have a POP certificate for, it then queries the CA, and if the CA says its valid, it adds it to the TOFU/POP list. This means you only have to trust the CA the first time you connect to a new site, not every time. My notes are here: https://dev.guardianproject.info/projects/bazaar/wiki/Chained_TLS_Cert_Verification Also, Werner Koch's STEED proposal includes a similar idea using DNS: http://g10code.com/steed.html .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 _______________________________________________ Guardian-dev mailing list Post: [email protected] List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: [email protected] Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/archive%40mail-archive.com You are subscribed as: [email protected]
