You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Mozilla Standards Position discussion on Web NFC has raised the possibility of exploits based on multiple NFC tags in close proximity. Browsing the spec's threats section I couldn't see these scenarios being explored in depth but it might be worthwhile considering doing so.
One such scenario which could exploit close-proximity multiple tags I'd imagine would be when the attacker created concealed NFC tags (e.g. transparent stickers) applied over legitimate NFC devices, such as smart posters, in a way that would make these "tag-in-the-middle" malicious NFC tags hardly noticeable. Differentiating between the tags in this scenario (or, at a bare minimum, notifying the user of the presence of multiple tags) would be a desirable feature of user agent implementations.
According to my short chat with @zolkis, detecting and differentiating between multiple "concurrent" NFC reads should be generally possible using data exposed by the underlying NFC stack, but implementations need to be aware of this and in certain cases mitigations may need to be deployed.
My understanding is, that since we are talking about physics & radio technology (and due to how the NFC protocol is constructed) there is always some inherent "uncertainty" in such concurrent cases (as they are not truly concurrent, in most hardware implementations, and are exposed as separate sessions in the software stack).
The text was updated successfully, but these errors were encountered:
Thanks! We will update the security section with this threat and mitigation.
Usually NFC readers can detect multiple tags, but have to create a separate communication session with each of them. However, the way it's exposed to application may depend on the HW/SW and tag tech. Some of the readers may be able to read multiple tags concurrently but then AFAIK they have to implement (low level) anti-collision.
Anyway, even if they appear as concurrent reads to the end user, they must be done in different sessions.
Therefore I expect that Web NFC implementations will get separate NDEF messages in the reading algorithm.
We can track the relevant experiences in this issue.
The Mozilla Standards Position discussion on Web NFC has raised the possibility of exploits based on multiple NFC tags in close proximity. Browsing the spec's threats section I couldn't see these scenarios being explored in depth but it might be worthwhile considering doing so.
One such scenario which could exploit close-proximity multiple tags I'd imagine would be when the attacker created concealed NFC tags (e.g. transparent stickers) applied over legitimate NFC devices, such as smart posters, in a way that would make these "tag-in-the-middle" malicious NFC tags hardly noticeable. Differentiating between the tags in this scenario (or, at a bare minimum, notifying the user of the presence of multiple tags) would be a desirable feature of user agent implementations.
According to my short chat with @zolkis, detecting and differentiating between multiple "concurrent" NFC reads should be generally possible using data exposed by the underlying NFC stack, but implementations need to be aware of this and in certain cases mitigations may need to be deployed.
My understanding is, that since we are talking about physics & radio technology (and due to how the NFC protocol is constructed) there is always some inherent "uncertainty" in such concurrent cases (as they are not truly concurrent, in most hardware implementations, and are exposed as separate sessions in the software stack).
The text was updated successfully, but these errors were encountered: