WebAPI/Security/WebNFC

From MozillaWiki
< WebAPI‎ | Security
Revision as of 16:29, 27 March 2015 by Arroway (talk | contribs) (add threat model)
Jump to navigation Jump to search

Name of API: WebNFC API Reference:

Brief purpose of API: Allow core (certified) and privileged apps to interact directly with NFC devices

General Use Cases: sharing content (media files, contacts) with NFC pairing, read/write NFC tags


Inherent threats:

  • Theft of sensitive data
  • Device compromise (configuring NFC device)
  • Potential for financial impact (payments via NFC) - cf the Secure Element API

Threat severity: Critical

Regular web content (unauthenticated) Use cases for unauthenticated code: None

Authorization model for normal content: None

Authorization model for installed content: None

Potential mitigations: N/A

Trusted (authenticated by publisher)

Same as for installed unauthenticated app

Certified (vouched for by trusted 3rd party)

Use cases for certified code:

  • Configure, enable/disable NFC devices.
  • Interact with NFC devices.
  • Manage NFC payments.

Security Review

Scope of Review

Gaia

  • System Application changes
  • Web Activities
  • System messages
  • Communication between system app and NFC client app
  • Certified NFC applications
  • 3rd party NFC apps

Out of scope for now:

  • Wallet Application (see Secure Element API)
  • Certified transportation/miFare applications

Gecko

  • mozNfc APIs
  • Gecko Permissions
  • Messaging (NFC:* messages, system messages)
  • NFC System worker
  • Interface to nfcd on IPC socket

Out of scope:

  • Secure elements
    • access control
    • integration with RIL

Gonk

  • NFC Daemon (nfcd)
  • Interface to lib

Documentation and reference

Key Bugs

Security Review: WebNFC bug 749325
Feature Bug (meta): https://bugzilla.mozilla.org/show_bug.cgi?id=860906
Dependent bugs: https://bugzilla.mozilla.org/showdependencytree.cgi?maxdepth=2&id=860906&hide_resolved=0


Gonk
NFC Daemon for B2G (daemon for supporting lib-nxp): bug 860907
B2G NFC: NFC Daemon for supporting libnfc-nci (daemon for supporting lib-nci): bug 906579
B2G NFC: Define protocol to communicate between nfcd and b2g: bug 897312

Gecko
WebNFC (near-field communication): bug 674741

Gaia
B2G Gaia Integration for NFC: bug 860910

Secure Element Support
NFC Secure Element Support: bug 879861 Support Nfc Access Control for Secure Element Access: bug 884594

Documentation about the NFC API:

https://developer.mozilla.org/en-US/docs/Web/API/NFC_API
https://developer.mozilla.org/en-US/docs/Web/API/NFC_API/Using_the_NFC_API
https://developer.mozilla.org/en-US/docs/Web/API/NFC_API/Using_the_NFC_emulator

Gaia

(Review Guidelines for app reviewers)

Quick overview and security highlights: (see for more details about how to use the API: https://developer.mozilla.org/en-US/docs/Web/API/NFC_API/Using_the_NFC_API)

An app using the NFC API to interact with NFC messages has to the declare in the manifest: the nfc permission (with readonly, readwrite or none if the app only receive data from the activity itself). the nfc-ndef-discovered activity: "activities": { 

   "nfc-ndef-discovered": {
         "filters": {
               "type": "url",
               "url": {
                     "required":true, "pattern":"https?:.{1,16384}", "patternFlags":"i"
                    }
             }
       }
     }

Types can be: text, text/vcard, uri, smartposter.

shared/js/nfc_utils.js provides methods for coding and decoding NDEF record payloads such as Wellknown, URI, Text, SmartPoster, MIME. The handler for the nfc-ndef-discovered should filter content and match what is expected in the “type” filters defined in the manifest.

Thee application can get new content through NFC by the following ways:

  • getting content by reading a tag:
  • getting a tag: var tag = navigator.mozNfc.getNFCTag(data.sessionToken);
  • getting shared contact via a mozNfcPeer:
   navigator.mozNfc.onpeerready = function (evt) {
     var peer = navigator.mozNfc.getNFCPeer(evt.detail);
     console.log(peer instanceof MozNFCPeer); // should print true;
   };


One thing to keep in mind: sharing a file with a NFC handover as explained here: https://developer.mozilla.org/en-US/docs/Web/API/NFC_API/Using_the_NFC_API#Sending_a_Blob_to_another_MozNFCPeer_by_NFC_handover means a NFC handover between two devices will initiate a Bluetooth connection to send the file.

Other permissions that applications should NOT request: nfc-share, nfc-manager, nfc-hci-event


Gecko

1. Receives IPC messages from NFCd 2. Broadcasts system messages to all apps (which have nfc-manager permission) nfc-tech-discovered nfc-tech-lost nfc-manager-send-file The patch also adds the following? bluetooth-hfp-status-changed bluetooth-sco-status-changed

3. IPC NFC:* messages Parent listens to const NFC_IPC_MSG_NAMES = [ 

 "NFC:SendToNfcd",
 "NFC:NdefDetails",
 "NFC:NdefRead",
 "NFC:NdefWrite",
 "NFC:NdefPush",
 "NFC:NfcATagDetails",
 "NFC:NfcATagTransceive",
 "NFC:Connect",
 "NFC:Close"

];

Child Listens to: const NFC_IPC_MSG_NAMES = [ 

 "NFC:TechDiscovered",
 "NFC:TechLost",
 "NFC:NDEFDetailsResponse",
 "NFC:NDEFReadResponse",
 "NFC:NDEFWriteResponse",
 "NFC:NDEFPushResponse",
 "NFC:NfcATagDetailsResponse",
 "NFC:NfcATagTransceiveResponse",
 "NFC:ConnectResponse",
 "NFC:CloseResponse"

];


Gonk

General notes about the UX/UI of NFC

Contrary to Bluetooth, the idea behind the UX of NFC if to have a “quick and easy” way to share content:

  1. Enable NFC
  2. Tap the phones
  3. Share content (Sharing UI)
  4. Display the content

Because phones have to be very close from each other to be able to share content, user prompts are almost not used except for the Sharing UI. Especially, a user isn’t prompted to to accept to receive the content. In the case of URL sharing, the Browser is automatically launched to display the content hosted at the URL. One risk could be that a user let their phone on the corner of a desk or in their pocket while NFC is enabled, and that somebody share content without them to be aware of it (in the street, in the office, etc). This is mitigated by the fact that NFC is disabled automatically when the screen is off and/or locked.

Use cases / Security & Privacy considerations

Ref: https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#risks

Communication: 4cm and less Possible sources for content:

  • NFC cards (passive)
  • NFC tags (passive)
  • Device with NFC enabled (active)
 Action User prompt Potential threats Mitigations
 Reading a tag no 

works when screen off: no
works when screen locked: no

Loading malicious content the user is unaware of:
  • Browser loading a malicious URL
  • Adding a contact to the Contact list
 NFC is disabled when the screen is off
Sharing content (writing on a tag / NFC handover + BT) yes (sharing UI)


works when screen off: no
works when screen locked: no
NB: A photo taken from the Camera while the phone is still PIN-locked can’t be shared from the Preview panel

Receiving shared content (NFC handover + BT) no (notification after file is received)

works when screen off: no works when screen locked: no

Devices stayed paired for BT: no forced browsing?
App spoofs a web activity associated with NFC (e.g. sends nfc-ndef-discovered)   Probably ok
User places phone on something which is a NFC enabled. NFC device spams phone with unwanted material. no E.g.: stick an nfc tag to the back of someones phone, it will also navigate to a url when you unlock.
NFC enabled bluetooth for file transfers. Can an attacker take advantage of this? BT turned off after transfer is done if it was off in the settings.

In the case of the use of BT with a NFC handover, the risks applicable to the use of Bluetooth apply to NFC use cases too : https://webbluetoothcg.github.io/web-bluetooth/use-cases.html#security_privacy

Retrieved from "https://wiki.allizom.org/index.php?title=WebAPI/Security/WebNFC&oldid=1064889"