[guardian-dev] NFC performance (was: Discovery and user rights)

Dominik Schuermann dominik at dominikschuermann.de
Tue Apr 21 13:36:51 EDT 2015


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

the NFC ring project collects heat maps where the nfc "antenna" works
best. You can look these up on http://nfcring.com/sweetspot/

Also, the Sony Z3 has a NFC sign on the back where the "antenna" is
integrated. It worked better than all other devices I tested in our lab.

Keep in mind that NFC is based on induction, so traditional antenna
design does not apply here.

Regards
Dominik

On 04/21/2015 06:58 PM, Yaron Goland wrote:
> For what it's worth we did some experimenting with NFC and
> eventually gave up. The reason is that the range is so outrageously
> small that if we didn't exactly line up the NFC transceivers we
> couldn't get data flowing. The result was a sort of rubbing dance
> with the phones that didn't result in a great user experience. None
> of this, btw, is unsolvable. I could imagine having a NFC  logo
> that identifies where the NFC transceivers are on the phone or
> maybe increasing their power a tiny bit so they don't have to be so
> outrageously close. But for our scenarios we actually want range
> since the point is to allow people to collaborate over as long a
> distance as their radios will support.
> 
> Never the less I still ended up in a similar place to your mail
> below about range restrictions.
> 
> I published an article on my blog,
> http://www.goland.org/localdiscoverybillofrights/, where I try to
> define what I believe are the rights that a user should have in
> terms of controlling presence. In one of the points I talk about
> how users should be able to have a policy that lets them only be
> discovered based on distance.
> 
> In other words there might be someone who is harassing me at work.
> I don't want to walk around with an electronic leash on my neck
> constantly telling them where I am. But I still need to work with
> them. So I could imagine having logic that could measure the
> strength of the signal I'm getting from the harasser. I could then
> say things like "This person is only allowed to discover me if they
> are within 5 feet." At that distance (baring walls :( ) they can
> just see me. Also by having some connectivity it will be slightly
> harder for them to know I've essentially "un-friended" them.
> 
> But I also realize that I'm just playing games. A determined
> attacker is going to be able to discover where people are and who
> has unfriended them. In my longer technical article that I'm still
> working on I talk about a bunch of these attack scenarios. But
> fundamentally if the person you are trying to avoid is part of your
> social group then there are just too many channels for them to use
> discovery to find you. I don't know if that problem is solvable.
> It's one thing to hide from strangers, but it's extremely difficult
> to hide from the friends of your friends.
> 
> Yaron
> 
> ________________________________________ From: guardian-dev
> <guardian-dev-bounces+yarong=microsoft.com at lists.mayfirst.org> on
> behalf of Hans-Christoph Steiner <hans at guardianproject.info> Sent:
> Tuesday, April 21, 2015 8:33 AM To:
> guardian-dev at lists.mayfirst.org Subject: Re: [guardian-dev]
> Discovery and user rights
> 
> Sounds right on topic for us! We're working with the exact same
> issues and tech.
> 
> I'd like to throw out on related idea, just to get the ideas
> flowing.  I've been trying to think about how to keep the range
> small enough so that we can rely on inter-personal skills for
> handling some of the privacy issues.  NFC is perfect for that,
> Bluetooth and local WiFi are also pretty good, but can be locally
> monitored.
> 
> This is a core idea of the FDroid app swap process.  The
> authentication comes from actually physically exchanging with the
> other people, and having that session last as long as the people
> are physically present in the same room. That maps concretely to
> our experience of agreeing to be in the same room with people, and
> choosing who in that room to talk to.
> 
> There are of course large limitations to working like this, so it
> won't work for lots of use cases where local data transfer can be
> useful.
> 
> .hc
> 
> Yaron Goland:
>> Guardian Folks,
>> 
>> 
>> First off I sincerely apologize if this is the wrong mailing list
>> to bring this issue up on. I know y'all are working in this area
>> and so I was hoping we might share notes. But if this isn't the
>> right place please tell me and I promise to cease and desist.
>> 
>> 
>> Right now I'm working on an design for how to use technologies
>> like BLE to enable discovery in ways that respect user rights and
>> don't kill user batteries.
>> 
>> 
>> To this end I've written (and will soon publish) a Users Bill of
>> Rights for discovery based on Kim Cameron's Laws of Identity. One
>> of the key rights is the right to decide who can discover you.
>> 
>> 
>> For example, imagine that you are part of a group of 100 or 200
>> people. It's a big discussion list. The contents of the list are
>> being passed around via BLE/Wi-Fi. Specifically, BLE is used to
>> discover people around you and if they aren't people you have
>> sent your post to then you will contact them over Wi-Fi Direct
>> (or Bluetooth or Multi-Peer Connectivity or whatever) to pass the
>> data.
>> 
>> 
>> However there is someone in the group who has been harassing you
>> and you don't want them to be able to find you via your
>> telephone. In other words, you don't want your phone to tell them
>> you are "in the area". So you go to your app and say "Exclude
>> person X from notifications".
>> 
>> 
>> Now you post to that group of 100 or 200 people. In theory if
>> your phone discovers someone who is a member of the group who you
>> haven't already sent a copy of the post to then your phone should
>> transmit it automatically.
>> 
>> 
>> The easiest way to do all of this is to just announce your
>> identity (in our case a public key). That way if you see someone
>> else's public key that you know you haven't updated yet then your
>> device can contact them. But of course the inverse is a big
>> problem. That is, if your phone is constantly advertising your
>> public key then the person you want to exclude will see it and
>> know you are in the area.
>> 
>> 
>> In theory the answer to this is to not advertise your key
>> directly but rather to take your key and then encrypt it with the
>> keys of the people you are trying to reach. In other words if you
>> want to send out 200 updates then you would advertise, over BLE,
>> 200 values. Each value is your identity encrypted with each
>> person's key.
>> 
>> 
>> Which means that someone receiving your advertisement would see
>> 200 values and have no idea if any of those values are for them.
>> So they would have to try to decrypt each and every one using
>> their private key to see if any match. If they do then they know
>> who is looking for them.
>> 
>> 
>> The benefit of this approach is that if someone is advertising
>> out they can simply not advertise to any member of the group they
>> have excluded. Similarly if someone receives an advertisement
>> from someone they excluded then they can just ignore it.
>> 
>> 
>> The problem is that this approach will almost certainly end up
>> being a DOS attack on the low bandwidth BLE channel and
>> potentially turn each device into a toaster oven as it tries to
>> process potentially hundreds of tokens from 10 or 20 different
>> sources (depending on how many devices are in range).
>> 
>> 
>> BLE is unbelievably slow. In practice I'm told that you aren't
>> going to get much about 35KB/s and that's on a clear channel
>> (which this isn't).
>> 
>> 
>> Furthermore we are processing these trial decryptions on battery
>> powered devices. The good news is that modern phones generally
>> use processors that have built in support for encryption
>> operators. But I'm not clear how much of modern crypto software
>> for iOS/Android actually uses those instructions. Even so,
>> performing literally 1000s of public key decryptions over a
>> period of a few hours isn't going to make anyone happy.
>> 
>> 
>> So I did think of an optimization. The optimization is that we
>> could try to create pairwise keys between all members of the
>> group. In that case what someone would advertise is some value
>> encrypted with the key shared with that person. We could then use
>> something like AES-128/GCM to do the encryption. This has a
>> couple of benefits. The encrypted value instead of being measured
>> in K as it would with say RSA 4K keys, would instead be around 40
>> or so bytes. Also the expense of "testing" each value will go way
>> down, especially if we use code that supports the ARM processor's
>> support for AES. [1]
>> 
>> 
>> AES-128/GCM/SHA-256 is what higher end TLS implementations use
>> and mobile processors these days are largely optimized to handle
>> it quickly for that reason. But to be fair the performance
>> profile is likely to be very different than TLS because we are
>> talking about large numbers of short encryptions/decryptions and
>> most of those are going to fail. Unexpected results do awful
>> things to desktop processor pipelines, I don't know enough about
>> ARM's architecture to know what to expect. But I suspect it won't
>> be pretty.
>> 
>> 
>> 
>> 
>> 
>> 
>> [1] Another option would be use to HMAC-SHA256 but I think this
>> would require an initialization vector to make the resulting hash
>> not be invariant and thus act as a beacon. I'm not clear if this
>> would really provide any meaningful savings.
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________ List info:
>> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To
>> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
>> 
> 
> -- PGP fingerprint: 5E61 C878 0F86 295C E17D  8677 9F0F E587 374B
> BE81 
> https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 
> _______________________________________________ List info:
> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To
> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org 
> _______________________________________________ List info:
> https://lists.mayfirst.org/mailman/listinfo/guardian-dev To
> unsubscribe, email:  guardian-dev-unsubscribe at lists.mayfirst.org
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJVNoqzAAoJEHGMBwEAASKCSO0H/2vsYvtBUkvYTgJ5ptZ0SkAk
1ad9/y/QZm+9BWI0mpnAe1b6wa4IZ2EdZpd7LMxu99/D5xtB6V/Mwp5HV3UQQY70
OOOaQLOb3aBFP8pychrdtOTe4uauXKZSu2onKjts40yzD7k9R4l4ookuXM4gaX0M
MqMwwQF4ugD19AWlxq4FBbRU1WBWntFLvltsPN/5PGmMgkl4kRECxsuquWVmxTCN
kXfHSF2mUD/BQ4EvfAbaO8o2Jr+WafdPcNd6RHMc0jgUWZUHHs38yjSnoMcDs7Si
Z+p8gtAjjcY/DsO8X67auFwQPef6GYY+FmUJ09EZlB37+qWhjgknxFr9ZX3VhBg=
=wK82
-----END PGP SIGNATURE-----


More information about the guardian-dev mailing list