MozillaWiki

WebAPI/Security/WebNFC: Difference between revisions

Page Discussion

WebAPI/Security/WebNFC (view source)

Revision as of 16:41, 27 March 2015

5,265 bytes added ,  27 March 2015
gonk review
(add threat model)
(gonk review)
Line 174: Line 174:


== Gonk ==
== Gonk ==
General info about low-level NFC architecture (schemas, protocol stack, etc): http://mp-nfc.org/nfc_near_field_communication_architecture.html
3 operating modes: http://nfc-forum.org/our-work/specifications-and-application-documents/specifications/
{| class="wikitable"
| Mode || Description || Exchanged data || Protocols || Role || Notes
|-
|peer-to-peer
|| communications between two NFC enabled phone
|| NDEF data
|| LLCP<br/>
SNEP (application-level)
|| active: bidirectional com’
|-
| reader/writer
|| phone reads, retrieve, alter data stored in NFC tags
|| NDEF data
|| Tag operations [1]
|| active:
phone initiates unidirectional connection
|| 4 tag types:<br/>
* 1 & 3: signed
* 2: not signed (MIFARE)
* 4: variable
|-
|card emulation
|| phone acts as a smart card (emulates or embeds a smart card)
|| Interact with SE
|| Same as smart card digital and analog protocols
|| passive:
external NFC reader initiates the connection
[2]
|}
[1] Different tags can be used according to their use (sms, number phone shortcut, smart poster, bluetooth pairing…): see http://mp-nfc.org/nfc_near_field_communication_nfc_tag_types.html
When exchanging voluminous data, the tag initiates the bluetooth pairing for performing the actual data exchange.
[2] Communications with SE more secure when smart card is emulated?
====Threats and counter-measures:====
* data corruption while transferring: can be avoided if the NFC device checks the RF field while the data is transmitted (to corrupt the data, the RF field will be significantly bigger)
* eavesdropping and data modification: establish a secure channel. Passive connections are more difficult to attack. Tags of type 2 are insecure (not signed).
* ata insertion: answer without delay or establish a secure channel.
(additional security which can be implemented: NFC specific key agreement)
==== Standardized security protocols used in Peer-to-Peer protocol: ====
* NFC-SEC: NFCIP-1 Security Services and Protocol (http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-340.pdf), ECMA-385:
* NFC-SEC-01: Shared Secret Service and Secure Channel Service (Cryptography Standards (EDCH, AES)
Both are implemented in the NFC core library
==== Source code: ====
Android has its own NFC API. (<> Open NFC API)
Android source code for reference:
* High-level app: https://android.googlesource.com/platform/packages/apps/Nfc/+/master
* Native code: https://android.googlesource.com/platform/packages/apps/Nfc/+/master/nci/jni/ (// content ported to B2G/system/nfcd/broadcom)
* https://android.googlesource.com/platform/external/libnfc-nxp/+/master
* https://android.googlesource.com/platform/external/libnfc-nci/+/master
==== Interesting Firefox OS code: ====
* Portable NFC core library: B2G/external/libnfc-*   
* NFC Daemon: system/nfcd (ported from Android)
* Conf files for broadcom chips on Nexus 4: /device/lge/mako/nfc (not security sensitive from what I’ve read)
==== Data manipulation: ====
NDEF is a binary message format to encapsulate one or several application payloads into a single message construct. (specs: http://www.cardsys.dk/download/NFC_Docs/NFC%20Data%20Exchange%20Format%20%28NDEF%29%20Technical%20Specification.pdf)
* A NDEF message contains one or several NDEF records (payload length, type and optional identifier) which each contains payload of arbitrary type.
* Payload type can be: URI, MIME, NFC-specific type formats.
* Error handling is the responsibility of the NDEF parser.
In Gonk, NDEF messages are implemented in interface/NdefMessage.cpp, and interface/NdefRecord.cpp.
The NFC chip receives NDEF data: if it is raw data (NDEF PDU) it is  converted to NDEF messages. Then messages are serialized to JSON to be sent to Gecko.
'''Checking''':
payload size is checked against MAX_PAYLOAD_SIZE when messages are sent or received: OK
don’t trust data input: (data type is of not importance at this stage: is either binary stream of NDEF messages)
JSON serialization
Tags data handling
'''P2P mode''': broadcom/PeerToPeer.cpp
* Send and receive byte buffers through the LLCP protocol, called from the SnepMessenger.
* Received bytes are put into a SnepMessage (the payload is put in a Ndef message, calling parse() so MAX_PAYLOAD_SIZE is checked)
* Writing NdefMessage to byte buffers to send data via LLCP: call NdefRecord.writeToByteBuffer() (NdefMessage.toByteArray)
* /!\ When sending NDEF raw data, the data is put in a std::vector<uint_8> without checking size limit -> bad ? or is content size checked before when creating a NDEF message => yes, when it’s called from SnepMessanger, the method is called with a snepMessage as an argument (which was constructed checking the max size of the payload)   
'''Reader/writer mode''': broadcom/NfcTagManager.cpp
* Read and write NDEF messages
* When the phone reads a tag, a NdefMessage is filled with data (doReadNdef()) calling NdefMessage.parse():  initialize NDEF message with NDEF binary data, * MAX_PAYLOAD_SIZE is checked when receiving raw data: 10MB payload limit
'''Communications''':
Checking:
implementation of a secure channel, mitigating data corruption: OK, if trusting the NFC core library
In P2P mode, power off disconnects the device from all clients/servers: OK


== General notes about the UX/UI of NFC ==
== General notes about the UX/UI of NFC ==
Line 191: Line 291:
Ref: https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risks
Ref: https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risks


Communication: 4cm and less
Communication: 4cm and less<br/>
Possible sources for content:
Possible sources for content:
* NFC cards (passive)
* NFC cards (passive)
Arroway
Confirmed users
152

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1064892"