You can program NFC in different modes. The mission is to send bi-directional messages. In NFC there are multiple combined operation modes you can use to accomplish this:
I have two questions in different aspects:
Usage aspect
With all three options you have bi-directional communication and you can send basically whatever you want. Why wouldn't you use one option above the others?
Security aspect
Security in the sense of vulnerability for abusing like eavesdropping, data destruction, data modification and man-in-the-middle-attacks.
I read option 3 (HCE) is also used for e.g. mobile payment. Is this the safe option, or is option 1 also safe, when you use additional measures like data encryption?
Thanks!
Why are there different operating modes?
The initial idea behind NFC is to combine existing standards (specifically ISO/IEC 14443 contactless smartcard technology and FeliCa/JIS X 6319-4) into a system that can both communicate with existing transponders/smartcards/tags, with existing reader infrastructure and that can be used to easily communicate with dedicated NFC devices.
The initial NFC standard (ISO/IEC 18092) therefore defines the peer-to-peer communication mode based on those existing protocols. In addition to being backwards compatible, the NFC standard allows two NFC devices to (automatically) handshake a connection between two NFC devices. This is not possible in a reader+card setup: neither two readers nor two cards can communicate with each other, so roles have to be predefined in a reader/card scenario.
Therefore, initially, reader writer mode was only intended to access NFC tags (passive data storage devices) and possibly contactless smartcards. Card emulation mode (HCE or SE based) was intended for interaction with existing ISO/IEC 14443 (or FeliCa) infrastructure (e.g. readers that were already in place before the evolution into NFC). And peer-to-peer mode was introdcued specifically for the communication between NFC devices.
Why can all modes nowadays be used for pretty much any scenario?
I guess that one of the driving factors for this development was that peer-to-peer mode on Android lacks API support. On Android peer-to-peer mode is only accessible through Android Beam and consequently not really usable for bidirectional communication. Another factor might be that the peer-to-peer mode protocol stack is more complex than that of reader writer mode (NFC-DEP + LLCP (+ SNEP) + application protocol vs. ISO-DEP + application protocol).
So option 1 is mainly used because it was (before Android 4.4) the only option to implement bidirectional communication over NFC. Since Android 4.4 also option 3 could be used to build similar scenarios.
Is option 3 more secure than the other options?
No, not at all. In all three scenarios, security must be handled by the application layer. The underlying communication protocols do not employ any encryption/integrity protection/etc. mechanisms.
The reason why option 3 is prefered for mobile payment is simply the backwards compatibility aspect: Using HCE you could implement an application that interacts with existing contactless smartcard readers (e.g. as they are used in EMV payment systems).