Re: [android-developers] Re: NFC send Photo

2011-05-29 Thread Nikolay Elenkov
On Mon, May 30, 2011 at 11:41 AM, Zsolt Vasvari zvasv...@gmail.com wrote:

 I wonder if those stickers Google promised to retrofit phones for
 Google Wallet would be usuable for general purpose NFC applications.

Most probably not. A sticker is just an NFC chip that you can glue to
your phone or anything else for that matter (we've had those for iPhone
for a while). Since the phone has no NFC reader-writer, you need an
external device to communicate with those. Plus the Wallet once will be
probably be single purpose, so you'd probably not be able to change anything.

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


Re: [android-developers] Re: NFC send Photo

2011-05-29 Thread Nikolay Elenkov
On Mon, May 30, 2011 at 12:51 PM, Bob Kerns r...@acm.org wrote:
 Don't worry about the terminology -- ad hoc wifi network is what you're
 looking for. I just wanted to figure out what you intended to say.

 Hmm, peer-to-peer and sensitive financial data has me a bit concerned.
 I don't advocate sending sensitive data, via servers or not, unencrypted. I
 hope you're using some sort of public key encryption, with a secure key
 exchange, such as Diffie-Hellman. If all I have to do is eavesdrop on your
 NFC communications (The role of the public key encryption part is to
 give you a way to strongly identify the recipient you're exchanging the
 encryption keys with).


It might actually be easier and more secure to exchange just URLs, and
have the app get the data via https *and* authenticate to the server, rather
than trying to implement a secure protocol on top of NFC. That way the app
can be sure it's talking to the right server (server certificate) and
the server
can be sure it's giving the data to the right person (Google account, etc.
authentication).

-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en


Re: [android-developers] Re: NFC send Photo

2011-05-29 Thread Bob Kerns
Note that using HTTPS does not give you end-to-end security in this 
scenario. The server is a man-in-the-middle. It's not a surreptitious one, 
but it is a man-in-the-middle nonetheless. The cert only serves to ensure 
it's the *right* man in the middle.

So you'll still want to encrypt the payload when using a server this way, 
unless you're going to make the server a trusted partner. And -- for 
liability reasons, if nothing else -- you'd like to avoid that unless it's 
essential to the service being provided.

A secure key exchange requires at least a pair of bidirectional messages. 
You're going to have to do that as well. Basically, to communicate securely 
any untrusted channel, you'll have to do something like what TLS does under 
HTTPS -- verification of the identity of the other end of the exchange, 
secure key exchange, and subsequent encryption. You also have to pay 
attention to key lifetimes, etc. HTTPS between you and the server really 
isn't buying you much toward end-to-end security.

Having the server handle authentication does simplify the picture in various 
ways. And a secure server in the middle can let you address various security 
issues with mobile devices, like revoking access more strongly than is 
possible with certificate revocation lists.

There are no simple answers in security. Everything ends up being 
complicated.

On Sunday, May 29, 2011 9:14:11 PM UTC-7, Nikolay Elenkov wrote:

 It might actually be easier and more secure to exchange just URLs, and
 have the app get the data via https *and* authenticate to the server, 
 rather
 than trying to implement a secure protocol on top of NFC. That way the app
 can be sure it's talking to the right server (server certificate) and
 the server
 can be sure it's giving the data to the right person (Google account, etc.
 authentication).


-- 
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en