Write-only Web NFC variant proposal

[cyberphone]

"A Better QR"

Using QR codes on the Web together with mobile phones acting as Identity Tokens or Wallets has been a huge success.

There is essentially only one but rather obvious snag; you need to start a specific QR- or QR-enabled application in order to use such a system.

However, if you scratch a bit under the surface of these systems you will find that they suffer from a fairly ugly security flaw: There is no secure binding between the page showing the QR-code and the QR-code itself. This fact has recently been successfully exploited by criminals who with simple phishing scams have lured people logging in to their bank for "Important Information" giving the phisher access to the account rather than the user. There is currently no publicly documented workaround for this vulnerability.

Note: even the most advanced systems out there using Security Elements and Asymmetric Key Cryptography exhibit this problem.

AFAICT, a Dedicated, Write-only Web NFC variant could be a great replacement for inconvenient and security-broken QR schemes. I don't see that a strict enforcement of the Web Security Model would be necessary since the Web service doesn't get any information from the user (via NFC).

This is how most QR based schemes work today:

1. The user wants to login or have reached a Web page asking for a payment. Note: using a PC
2. The service offers a (preferably one-time) QR code in a Web page
3. The user starts a QR enabled application. Note: using a Phone
4. The applications scans the QR code aided by the user doing the focusing
5. The QR enabled application performs the authentication or transaction using OOB communication based on the read QR data

[anssiko]

@cyberphone, please give this issue a more descriptive name, such as "Proposal for a write-only Web NFC variant", and provide further technical details in this issue to allow the group understand and evaluate it better.

I don't see how QR codes are relevant to the technical discussion around Web NFC API. The scope of this group is defined in https://w3c.github.io/web-nfc/charter/#scope-of-work and discussion on QR codes is out of scope.

[cyberphone]

@anssiko If the people reading this issue are unfamiliar with how QR-codes are used on the Web, there seems to be little point developing a detailed technical description. BTW, I'm not an expert on NFC. A fruitful outcome would IMO require a dialog between platform and application folks. The people owning the aforementioned QR-powered systems usually do not talk to platform developers, making this task slightly challenging :)

The issue title is deliberately somewhat "non-technical" because the same title and content have gotten quite a bunch of views (and 👍) by bank people on LinkenIn who I also hope will monitor possible progress on this topic which already affects several hundreds of millions of users. An important part of this use case is that the same scheme with moderate adjustments would also be used in the physical (non-Web) world including POS terminals, ATMs, and Gas stations.

Now to the technical side of things as seen from an application point of view. A QR-code provides "data" having no pre-defined function. A Better QR using Web NFC would do the same, with one major difference: The security context (URL + Certificate) of the invoking Web page must also be available so that the OOB communication performed by the App in the phone can prove where it got its invocation from to the server it typically calls. There is normally "nonce" information involved as well but that belongs to the "data" provided by NFC.

[Liryna]

The security context (URL + Certificate) of the invoking Web page must also be available so that the OOB communication performed by the App in the phone can prove where it got its invocation from to the server it typically calls.

NFC is not made to be secure. Do not expect to use it for banking or any data that require secure transaction. Even with a context or unique data, the transaction can be caught and replay by anyone.

[alexshalamov]

@cyberphone

BTW, I'm not an expert on NFC.

Could you check whether NFC Signature Record Type Definition (RTD) would be sufficient for your use-cases?

[cyberphone]

@Liryna wrote:

NFC is not made to be secure. Do not expect to use it for banking or any data that require secure transaction. Even with a context or unique data, the transaction can catch and replay by anyone.

An attacker standing behind the user or having a telescope can indeed take over the session after step 2. NFC would make this harder but as you say, not impossible. However, such an attack is (AFAICT...), not extremely useful, because it either authenticates the attacker or let him/her pay.

[cyberphone]

@alexshalamov wrote:

Could you check whether NFC Signature Record Type Definition (RTD) would be sufficient for your use-cases?

If signing data would be enough, signed QR data would do as well.

The core problem is that the QR applications this issue refers to must know which page the information is emitted from in order to "simulate" in-bound communication. Using the NFC based QR replacement: If a page is phished, the phisher's security context will be supplied with the "data" which in the case of authentication will (in a properly designed service NB), generate an authentication that only works in the phisher's domain or be stopped already at the phone client level.

[Liryna]

or having a telescope

For NFC this would be a strong antenna. With a specific hardware, you can communicate to some meter with the badge.

Why don't you look at a mutual authentication between the web page and a badge ? With this you would be sure that the communication is secured and that both device has the right to communicate to each other without MITM ?

[zolkis]

So you want to include a page id (origin/hash etc) in a read-only tag that guarantees integrity, so that any app can be sure the tag is associated with the given origin.
However, it is still vulnerable to MitM and replay attacks.
OOB channels are possible with devices, but not with tags.

[cyberphone]

@zolkis wrote:

So you want to include a page id (origin/hash etc) in a read-only tag that guarantees integrity, so that any app can be sure the tag is associated with the given origin.

Essentially that is it.

However, it is still vulnerable to MitM and replay attacks.

Would it be possible describing a MitM attack?
Replay is thwarted at the application level using one-time challenges that are invalidated after being used.

OOB channels are possible with devices, but not with tags

Right. See updated use case: #128 (comment)

[zolkis]

Would it be possible describing a MitM attack?

It is possible to sniff NFC reads from up to 30 meters. Then it's a race condition. Also (read on below)...

Replay is thwarted at the application level using one-time challenges that are invalidated after being used.

The tags will still contain the same info, since we can't update the tags. Read it once, and you're as good as the tag itself, and on the copies of the tag you can change the info associated with the origin.

[zolkis]

So I think we can limit this use case to devices.

[cyberphone]

It is possible to sniff NFC reads from up to 30 meters. Then it's a race condition

I believe I covered that in: #128 (comment)

Anyway, this belongs to "Security Considerations" where application developers should consider the effect of a possible session takeover. In most current QR use-cases this does not create a security problem.
Personally, I think this is an issue the NFC Community should address since it is fully universal.

Regarding the other attacks which seem to be about malicious device software, this is out of scope for this proposal and most other security related specifications as well including TLS. Signed data (a possible option) would invalidate modified tags.

[Liryna]

It is possible to sniff NFC reads from up to 30 meters. Then it's a race condition
I believe I covered that in: #128 (comment)

I do not see how this is covered.

this belongs to "Security Considerations" where application developers should consider the effect of a possible session takeover

Developers do not use NFC for security purpose I believe.

NFC Community should address since it is fully universal.

They do not do it probably because there are other standards made for this purpose (like ISO7816). Or if you are talking about reading distance, this is another layer level (hardware).