W3C home > Mailing lists > Public > public-nfc@w3.org > February 2015

[nfc] Verify security model

From: Jonas Sicking via GitHub <sysbot+gh@w3.org>
Date: Wed, 18 Feb 2015 11:58:59 +0000
To: public-nfc@w3.org
Message-ID: <issues.opened-58058998-1424260738-sysbot+gh@w3.org>
sicking has just created a new issue for https://github.com/w3c/nfc:

== Verify security model ==
One of the most critical pieces of the NFC API will be the security 
model. Some thoughts on that below:

My basic assumption is that any existing NFC tags and NFC devices 
assume that the code that is running on the users device has been 
trusted by the user. I.e. that the user trusts the "app" that is 
communicating with the NFC tag.

Hence they can assume that whoever is reading/writing/communicating 
has the permission to do so from the user, and that the user wants 
whatever data is sent to be sent.

Unfortunately this is not true for webpages. Users quite commonly 
visit webpages that they don't "trust". This is one of the 
foundational principles of the web security model.

Hence we explicitly don't want webpages to be able to 
read/write/communicate with existing NFC tags that exist out there in 
the world today. Because we don't know if harm will come out of that.

This was a similar problem that WebSocket had. While there are lots of
 cool and interesting hardware and software out there that speak TCP, 
a lot of them assume that the code that is initiating the TCP 
connection is trusted by the user.

What WebSocket did to solve this, is that it created a protocol that 
was different enough from anything known to exist, that no existing 
hardware or software could be mistaken for using that protocol.

I.e. a client attempting to connect to a WebSocket server could never 
mistakenly think that that server support the WebSocket protocol. So 
any time that it detected a WebSocket server, it could be sure that 
the server had been authored intentionally as a WebSocket server.

Additionally, WebSocket added in the protocol some explicit security 
information. So that it would be hard for someone to accidentally 
implement a server which intended to only accept data from the 
`www.bunnies.com` website, but accidentally also accept data from any 
other website.

The websocket protocol and API explicitly define that these checks are
 required and define that if the server, or client, doesn't send the 
expected information, that the connection is immediately closed and 
that an error is signaled.

This is what I think we need to do for WebNFC as well.

So we should come up with an NFC format which explicitly is different 
enough from any tags that are in existence today, that it's very 
unlikely that any existing tags can be mistaken for WebNFC tags.

The WebNFC specification should mandate that tags use this format, and
 mandate that the API should signal an error if the tag does not use 
this format. (Alternatively we can simply indicate that no tag has 
been found).

This is especially important when writing tags and when engaging in 
P2P communication. Since both those could have lasting effects on the 
behavior of the tag which the user did not intend.

For reading tags we could possibly make an exception to this. Since 
reading a tag at worst can cause private data to be exposed to a 
website, but otherwise no other lasting effects to happen, it might be
 ok to simply ask the user if it's ok for this website to read NFC 
tags.

I don't know if sticking a URL in the `id` NDEF record fulfills the 
requirement that no existing tags can be confused for WebNFC tags. If 
not we might need to adjust the WebNFC format.

See https://github.com/w3c/nfc/issues/76
Received on Wednesday, 18 February 2015 11:59:18 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 February 2015 11:59:19 UTC