[guardian-dev] first working version of TrustedIntents library

Hans-Christoph Steiner hans at guardianproject.info
Wed Jun 25 10:39:33 EDT 2014



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


More information about the Guardian-dev mailing list