NFC“卡模擬”技術(shù)是NFC手機(jī)上進(jìn)行卡模擬的新方法。最早由RIM公司在黑莓平臺(tái)上引入。在支持多種安全單元之外，黑莓7平臺(tái)支持通過手機(jī)應(yīng)用控制器模擬NFC標(biāo)簽和智能卡。

通過指定一條NDEF消息，應(yīng)用程序能夠模擬NFC Forum 類型4的標(biāo)簽，該消息可以保存在一個(gè)虛擬標(biāo)簽中。這種類型4標(biāo)簽協(xié)議由黑莓系統(tǒng)自動(dòng)處理。工作在該模式下的NFC設(shè)備可用于與另外一個(gè)工作在讀寫器模式下的NFC設(shè)備交換數(shù)據(jù)。

應(yīng)用程序也可以全方位的模擬符合ISO/IEC 14443-4標(biāo)準(zhǔn)的智能卡，包括類型A和類型B。應(yīng)用程序可以指定模擬卡的靜態(tài)屬性(例如唯一ID(UID) 以及ISO/IEC 14443 Type A卡的歷史數(shù)據(jù))，并在ISO/IEC14443-4規(guī)定的塊交換協(xié)議基礎(chǔ)上進(jìn)行信息協(xié)議數(shù)據(jù)單元交換(盡管API允許應(yīng)用程序隨便定義UID，但考慮到安全因素，在現(xiàn)存設(shè)備上沒有提供該功能)。開發(fā)人員可以通過在黑莓系統(tǒng)上進(jìn)行注冊(cè)將應(yīng)用程序模擬為智能卡。當(dāng)從外部RFID/NFC讀寫器得到命令時(shí)，系統(tǒng)通過一個(gè)回調(diào)函數(shù)通知該應(yīng)用程序，并將得到的命令作為參數(shù)傳遞給該回調(diào)函數(shù)。應(yīng)用程序可以通過參數(shù)進(jìn)行相應(yīng)的處理，該回調(diào)函數(shù)的返回值可以返回到NFC讀寫器。

卡模擬被視為NFC技術(shù)中最具前景的領(lǐng)域。主要原因是相比其它工作模式，卡模擬最有盈利的前景。而且，現(xiàn)存的支付，票務(wù)，門禁等智能卡系統(tǒng)一般由固定的讀寫器設(shè)備和帶有智能卡/非接觸標(biāo)簽的用戶組成。因此將用戶端功能(智能卡/非接觸標(biāo)簽)加入手機(jī)中是一個(gè)現(xiàn)實(shí)和迫切的要求。

盡管NFC社區(qū)一直要求提供卡模擬功能，但是，卡模擬，特別涉及安全單元的卡模擬一直是個(gè)復(fù)雜的領(lǐng)域。到目前為止，嵌入式系統(tǒng)中的安全單元通常在手持設(shè)備制造商控制中或TSM的運(yùn)營下。如果將UICC(SIM)作為安全單元，則是移動(dòng)網(wǎng)絡(luò)運(yùn)營商(Mobile Network Operator MNO)控制著安全單元。NFC手機(jī)中的安全單元控制權(quán)之爭早已打響。

因此實(shí)現(xiàn)對(duì)安全單元訪問的第一個(gè)障礙就是不同的安全單元由不同的部門控制。

另一個(gè)障礙是一個(gè)安全單元的運(yùn)營商不太可能允許其競爭對(duì)手在他們的模塊中運(yùn)行類似的服務(wù)。例如谷歌錢包不太可能與Isis錢包中一個(gè)手機(jī)中共存，尤其是共享一個(gè)安全單元。

第三個(gè)障礙是應(yīng)用程序訪問安全單元的開銷。除了安全單元上存儲(chǔ)空間的開銷外，共存在一個(gè)安全單元上的安全相關(guān)的應(yīng)用程序應(yīng)該需要某種模式的安全認(rèn)證。

所有這些障礙限制了一般開發(fā)人員的應(yīng)用程序使用安全單元的可能性(也許在手機(jī)和支付領(lǐng)域的巨頭可以除外)。作為上述問題的解決方案，RIM在其黑莓手機(jī)上提供了軟件卡模擬方法。在這種模式下，任何開發(fā)者都可以開發(fā)基于卡模擬技術(shù)的應(yīng)用程序，為開發(fā)與現(xiàn)存具有固定讀寫器的基礎(chǔ)設(shè)施交互的應(yīng)用程序的提供了可能。也就是說，開發(fā)者可以開發(fā)基于手機(jī)的門禁，支付，公共交通和票務(wù)應(yīng)用程序，用于使用RFID票卡和智能卡的系統(tǒng)中。

軟件卡模擬的另外一個(gè)好處是可以實(shí)現(xiàn)與不具備全功能點(diǎn)對(duì)點(diǎn)模式的NFC設(shè)備通訊。例如，Android系統(tǒng)僅支持Android Beam來實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)通訊。然而Android Beam是基于谷歌的NDEF推協(xié)議 (NDEF Push Protocol NPP)和簡單NDEF交換協(xié)議 (Simple NDEF ExchangeProtocol SNEP)，在兩個(gè)NFC手機(jī)接觸時(shí)僅能實(shí)現(xiàn)單方向單條的消息通訊。因此，軟件卡模擬可以作為NFC手機(jī)之間點(diǎn)對(duì)點(diǎn)通訊的替代方式。另外許多基于PC平臺(tái)的非接觸智能卡讀寫器也不支持點(diǎn)對(duì)點(diǎn)模式。例如 Reiner SCTcyberJack RFID basic (在新的德國身份證系統(tǒng)中使用)和HID OMNIKEY 5321。但是，這些設(shè)備可以與卡模擬方式下的NFC手機(jī)進(jìn)行通訊，因此，不需要增加額外的NFC硬件，軟件卡模擬方式能夠?qū)崿F(xiàn)了手機(jī)與這些PC系統(tǒng)的通訊。

更進(jìn)一步的好處是相比點(diǎn)對(duì)點(diǎn)模式，在PC平臺(tái)上對(duì)軟件卡模擬的軟件和驅(qū)動(dòng)支持更好。非接觸智能卡讀寫器在PC/SC上已經(jīng)標(biāo)準(zhǔn)化，而且缺省的集成到大多數(shù)操作系統(tǒng)中。即使Java SE這樣的平臺(tái)也具有非接觸式智能卡的標(biāo)準(zhǔn)API。點(diǎn)對(duì)點(diǎn)模式則只有有限的支持，而且僅僅被有些第三方庫，例如libnfc4和libnfc-llcp5 支持。另外，NFC點(diǎn)對(duì)點(diǎn)模式協(xié)議棧為應(yīng)用層協(xié)議(NDEF消息)基于NPP，SNEP (或者直接使用另外的應(yīng)用層協(xié)議)基于

LLCP (NFC LogicalLink Control Protocol NFC邏輯鏈路控制協(xié)議)基于

NFC-DEP (NFC DataExchange Protocol NFC數(shù)據(jù)交換協(xié)議，例如符合ISO/IEC 18092的底層點(diǎn)對(duì)點(diǎn)通訊協(xié)議)

比較而言，下面的讀寫器模式的協(xié)議棧更簡單：

應(yīng)用層協(xié)議 (符合ISO/IEC 7816-4)基于

ISO-DEP (符合ISO/IEC 14443-4定義的通訊協(xié)議)

總體來講，軟件卡模擬方式是一般開發(fā)者，而不是那些“業(yè)界巨頭們”，能夠從簡單的NFC標(biāo)簽應(yīng)用上進(jìn)行功能擴(kuò)展的很好契機(jī)。