基于SWP接口的HCI協(xié)議分析與實現(xiàn)*

魏貴鵬，馮乃琪，謝 演

（成都三零嘉微電子有限公司，四川 成都 610041）

0 引 言

隨著移動互聯(lián)網(wǎng)、物聯(lián)網(wǎng)的飛速發(fā)展，智能手機、物聯(lián)網(wǎng)設(shè)備大量普及，移動支付、近場支付、電子錢包等應(yīng)用也得到了大量用戶的認(rèn)可。智能手機、物聯(lián)網(wǎng)設(shè)備不僅可以作為通信、娛樂或收集特定數(shù)據(jù)的設(shè)備，也慢慢變成了人們隨身攜帶的錢包以及各種卡的替代物品，成為人們可信賴的支付工具。

作為電子錢包、公交卡使用，手機和物聯(lián)網(wǎng)設(shè)備可以采用二維碼支付、近場支付的方式。在近場支付場景中，多會用到NFC（Near-field Communication，近場無線通信）這種通信技術(shù)。設(shè)備中會內(nèi)置NFC通信所需要的CLF（Contactless Front-end，非接觸式前端）芯片，并普遍使用由ETSI（歐洲電信標(biāo)準(zhǔn)協(xié)會）所定義的SWP（Single Wire Protocol）接口與這種芯片連接。

SWP接口通過一根數(shù)據(jù)線來實現(xiàn)智能卡與CLF間的數(shù)據(jù)通信，然后通過NFC的方式與其他終端設(shè)備進(jìn)行數(shù)據(jù)交互，從而達(dá)到通過非接觸的方式使得帶有智能卡的設(shè)備與其他終端設(shè)備通信。參考OSI（Open System Interconnection）中所描述的系統(tǒng)互聯(lián)，SWP對應(yīng)著OSI模型的物理層和數(shù)據(jù)鏈路層的實現(xiàn)。在它的基礎(chǔ)上，通過實現(xiàn)HCI（Host Controller Interface）協(xié)議，能夠使帶有SWP接口的設(shè)備具備不同的應(yīng)用功能，從而滿足不通的應(yīng)用場景。

HCI同樣也是由ETSI制定，定義的是一種邏輯接口，可運行于SWP硬件接口上，對應(yīng)著OSI模型中的網(wǎng)絡(luò)層。在此協(xié)議中，定義了系統(tǒng)中各物理連接設(shè)備的邏輯功能、組成、屬性，定義了傳輸數(shù)據(jù)包的格式、管理設(shè)備間的邏輯通道和數(shù)據(jù)路由。

1 HCI協(xié)議分析

1.1 HCI協(xié)議棧

HCI協(xié)議中定義了系統(tǒng)中各設(shè)備所具備的邏輯組成。一個支持HCI標(biāo)準(zhǔn)的設(shè)備，首先是要有明確的設(shè)備類型（Host Type），不同設(shè)備類型的內(nèi)部需要包含不同功能的門（Gate）、屬性記錄（Registry），響應(yīng)不同的事件和消息。這樣不同類型的設(shè)備就具備了各種不同的功能。同時，HCI也定義了系統(tǒng)中各設(shè)備的邏輯連接。設(shè)備間的連接本質(zhì)是設(shè)備間門與門的連接，而門與門的連接是通過管道（Pipe）實現(xiàn)的。管道是用于傳輸設(shè)備間交互信息的邏輯通道，而HCP（Host Controller Protocol）包則定義了交互信息的數(shù)據(jù)組成[1]。

圖1只描述了兩個門的連接，在實際場景中存在的連接數(shù)遠(yuǎn)不止于此。HCI協(xié)議包括了圖1中的三個層級的內(nèi)容——門、HCP消息、HCP路由。門與門之間通過管道交互命令、事件、響應(yīng)。HCP消息為門與門間傳遞的數(shù)據(jù)的載體，它包含上述命令、事件、響應(yīng)的內(nèi)容等。HCP路由機制則是確定HCP包傳遞的路徑。

圖1 HCI結(jié)構(gòu)

1.2 關(guān)鍵對象

HCI協(xié)議中定義了設(shè)備、門、屬性記錄和管道四種主要的邏輯對象類型和一種消息包結(jié)構(gòu)——HCP包。一個設(shè)備中含有多個門，但是必須有一個主管門（Administration Gate）、一個身份管理門（Indentify Management Gate）和一個回送門（Loop Back Gate）。設(shè)備控制器還必須有一個鏈接管理門（Link Management Gate），而每一個門有零或多個屬性記錄，每一個通道的建立會產(chǎn)生門的一組屬性記錄備份。換句話說，對于連接到門的每一個通道，門都會針對這個通道創(chuàng)建自身屬性記錄的一個實例。表1為HCI對象介紹及相關(guān)示例。

圖2中展示了由一個設(shè)備控制器和兩個其他類型設(shè)備組成的系統(tǒng)，用以說明各對象類型間的邏輯關(guān)系。

2 SWP接口原理

2.1 SWP接口特性

SWP是ETSI定義的智能卡設(shè)備與CLF連接的接口，包只含三個物理連接點——VCC、Gnd、SWIO。這樣在實際情況下就僅僅需要一個SWIO接口，與其他的通信接口相比減少了設(shè)計及硬件成本，提高了應(yīng)用的便捷性。同時，SWP接口工作的功耗低，譬如SWP接口在Class C模式下電壓最小值為1.62V，最大值為1.98V，電流的最大值5mA[2]。對于智能手機、便攜的智能設(shè)備等這類對電量比較敏感的設(shè)備，這無疑是一種好的選擇。

2.2 SWP接口連接方式

智能卡設(shè)備與CLF物理上的連接方式，如圖3所示。

表1 HCI對象介紹及示例

圖2 門與管道關(guān)系

圖3 SWP接口連接示意圖

圖1 所示的SWIO（Single Wire protocol Input/Output）C6是CLF與智能卡的數(shù)據(jù)傳輸接口。VCC（供電電壓）C1與Gnd（地）C5是智能卡供電接口。

2.3 SWP數(shù)據(jù)傳輸原理

SWP的傳輸協(xié)議是點到點的、按位傳輸?shù)娜p工數(shù)據(jù)傳輸協(xié)議。圖4為SWP數(shù)據(jù)傳輸。S1信號通過電壓的數(shù)值調(diào)制（低或高）來傳送從CLF到智能卡的數(shù)據(jù)，S2信號通過對電流的數(shù)據(jù)調(diào)制（低或高）來傳送從智能卡到CLF的數(shù)據(jù)。

圖4 SWP數(shù)據(jù)傳輸

2.4 基于帶SWP接口安全芯片的應(yīng)用

隨著移動支付、近場支付在當(dāng)今生活中的普及，用戶對支付安全提出了要求，隨之出現(xiàn)的安全解決方案也慢慢開始流行，越來越多的智能手機和物聯(lián)網(wǎng)終端設(shè)備中加入了帶SWP接口的安全芯片。安全芯片通過SWP接口與CLF連接，安全芯片的固件中實現(xiàn)了HCI規(guī)范定義的終端類型，并利用其安全性，為支付過程提供數(shù)據(jù)保護(hù)、身份認(rèn)證等功能。

圖5中，終端設(shè)備AP（Application Process）為設(shè)備的應(yīng)用處理器。它作為主控端，可以通過SPI、UART、7816等接口與安全芯片連接，而安全芯片采用SWP接口同CLF連接。

圖5 SWP應(yīng)用連接

3 HCI協(xié)議的實現(xiàn)

對于HCI協(xié)議的實現(xiàn)，關(guān)鍵是抽象出協(xié)議中關(guān)鍵的對象類型，實現(xiàn)它們之間的關(guān)系和對HCP消息的處理。

本章中采用C語言對HCI協(xié)議進(jìn)行實現(xiàn)，依賴的硬件平臺是成都三零嘉微電子有限公司開發(fā)的安全芯片JW17051。安全芯片的SDK提供了底層硬件相關(guān)的接口。HCI協(xié)議實現(xiàn)需要調(diào)用SWP接口部分的API來初始化SWP接口，并通過SWP接口發(fā)送和接收數(shù)據(jù)。安全芯片與CLF的連接如圖5所示。

3.1 關(guān)鍵對象數(shù)據(jù)結(jié)構(gòu)實現(xiàn)

3.1.1 設(shè)備（Host）

設(shè)備類型如表2所示，采用HCI協(xié)議中規(guī)定的HID（Host Identifier）進(jìn)行區(qū)別。

程序中通過宏定義來表示設(shè)備的類型。根據(jù)不同的應(yīng)用場景，通過設(shè)置程序中代表設(shè)備類型的變量來創(chuàng)建不同的門。

表2 設(shè)備類型

3.1.2 門（Gate）

門包含了一系列屬性記錄以及可支持的命令和事件，所以只要能夠根據(jù)協(xié)議中定義的GID（Gate Identifier）判斷出門的類型，就能夠處理基于這個門的管道創(chuàng)建和事件、命令。

門類型如表3所示。同設(shè)備類型一樣，程序中通過宏定義來表示門的類型。當(dāng)連接到這個門上的管道建立時，建立根據(jù)門類型建立屬性記錄，并在接收到命令和事件時通過判斷GID來確定當(dāng)前門是否支持各種事件或命令。

表3 門類型

3.1.3 屬性記錄（Registries）

不同的設(shè)備會有具備不同功能的門，而不同的門會有不同的屬性記錄。由于門的種類較多，下文將以身份管理門（Identity Management Gate）的屬性記錄為例來展示其定義，如表4所示。

表4 身份管理門屬性記錄

表4中訪問權(quán)限‘RO’為只讀；長度‘N0’長度不超過20 Bytes；‘N1’為一個不定長的鏈表，也可以分配一個固定的長度的數(shù)組來保存設(shè)備中支持動態(tài)管道門的GID。

對于門的屬性，實現(xiàn)采用一個指針數(shù)組來保存每一個屬性的數(shù)據(jù)的存儲指針，即指針數(shù)組中的每一個數(shù)據(jù)對應(yīng)著每一項屬性的存儲空間。屬性數(shù)據(jù)指針的存儲順序按屬性的標(biāo)識來排列。在指針數(shù)組中，標(biāo)識設(shè)置為空，使得可以按順序的方式訪問到屬性，并不再存儲各個屬性的標(biāo)識以解決空間。

屬性的詳細(xì)結(jié)構(gòu)如圖6所示。

圖6 屬性存儲

3.1.4 管道（PIPE）

管道是門與門間事件、命令、響應(yīng)傳輸?shù)倪壿嬐ǖ?，分為靜態(tài)和動態(tài)兩種類型。靜態(tài)管道不需要創(chuàng)建，是設(shè)備初始化后產(chǎn)生的，包括主管門（Administration Gate）間和鏈接管理門（Link Management Gate）間管道兩類。PID（Pipe Identifier）分別是0x01和0x00。靜態(tài)管道不可以被刪除，而動態(tài)管道可以根據(jù)應(yīng)用場景實時地創(chuàng)建和刪除。在創(chuàng)建管道的同時，管道所連接門的屬性實例同時被創(chuàng)建。在刪除管道的同時，管道所連接門的屬性也將會被同時刪除。

管道的數(shù)據(jù)結(jié)構(gòu)實現(xiàn)如下：

typedef struct pipe

{

//pipe identifier

unsigned char pid;

//source host identifier

unsigned char src_hid;

//source host gate iendtifier

unsigned char src_gid;

//destination host identifier

unsigned char dest_hid;

//destination gate iendtifier

unsigned char dest_gid;

//open or close

unsigned char state;

//dynamic or static

unsigned char type;

//registers’ pointer array

unsigned char ** registries;

} PIPE_T;

3.2 HCP包分解

圖7為HCP包結(jié)構(gòu)示意圖。

圖7 HCP包結(jié)構(gòu)

HCP包頭：大小1 Byte，包括CB（Chaining Bit）和PID。CB占用包頭的最高位（bit8），PID占用剩下7位數(shù)據(jù)。當(dāng)CB為1時，表示當(dāng)前包為最后一個HCP包或本次消息傳輸有且僅有這一個包；當(dāng)CB為0時，表示當(dāng)前包不是最后一個HCP包，后續(xù)還有本次消息傳遞相關(guān)的包發(fā)送，直到CB為1。

消息包頭：消息包頭長度為1Byte，類型占用最高位和次高位（bit8和bit7）兩位，指令占用剩下的6位。

消息類型：消息類型分為命令（0x00）、事件（0x01）和響應(yīng)（0x02）三類。

指令類型：指令類型根據(jù)消息類型的不同而不同。

消息包的實現(xiàn)采用數(shù)組，以宏定義表示規(guī)范中定義的各類屬性和命令，當(dāng)需要發(fā)送數(shù)據(jù)時，如數(shù)組中對應(yīng)的位置。

3.3 命令和事件的發(fā)送和處理

設(shè)備啟動后會對硬件進(jìn)行初始化。當(dāng)然，SWP接口的相關(guān)配置也包含在此過程中，然后創(chuàng)建靜態(tài)管道，開始一個循環(huán)過程，獲取SWP接口上的消息，并根據(jù)消息內(nèi)容調(diào)用不同的處理函數(shù)，如圖8所示。

圖8 HCI函數(shù)調(diào)用流程

當(dāng)設(shè)備收到建立管道的命令后，命令參數(shù)中指定的門之間將建立管道。這樣設(shè)備間就能夠通過新建的動態(tài)管道發(fā)送和接收HCP包。然而，不同類型的門接收、處理命令和事件又各不相同，所以收到HCP包后，首先要判斷是否是門能夠支持的命令類型。

圖9以回放測試（Loop Back Testing）的處理流程來說明采用HCI協(xié)議的系統(tǒng)中的一個交互流程并列出了主要函數(shù)，終端設(shè)備A采用JW17051安全芯片。

圖9 命令與事件發(fā)送處理流程

首先，設(shè)備A作為業(yè)務(wù)的發(fā)起者調(diào)用hci_create_pipe創(chuàng)建一個通道。

其次，設(shè)備A調(diào)用hci_open_pipe打開剛剛創(chuàng)立的通道。

最后，設(shè)備A調(diào)用hci_post_data發(fā)送數(shù)據(jù)到設(shè)備B。

流程中的主要函數(shù)及參數(shù)說明如下。

unsigned char hci_create_pipe(unsigned char src_gid,unsigned char dest_hid,unsigned char dest_gid,unsigned char* pid)

說明：向設(shè)備控制器主管門發(fā)送建立通道的ADM_CREATE_PIPE命令。

參數(shù)：

unsigned char src_gid：發(fā)送命令的GID；

unsigned char dest_hid：目標(biāo)設(shè)備HID；

unsigned char dest_gid：目標(biāo)設(shè)備GID；

unsigned char*pid：創(chuàng)建的PID；

返回值：函數(shù)執(zhí)行返回碼。

unsigned char hci_open_pipe(unsigned char pid)

說明：向設(shè)備發(fā)送打開通道的ANY_OPEN_PIPE命令。

參數(shù)：

unsigned char pid：要打開通道的PID；

返回值：函數(shù)執(zhí)行返回碼。

unsigned char hci_post_data(unsigned char pid,unsigned char data_length,unsigned char* data_buffer)

說明：向設(shè)備發(fā)送EVT_POST_DATA事件，并發(fā)送數(shù)據(jù)。

參數(shù)：

unsigned char pid：采用的通道；

unsigned char data_length：發(fā)送數(shù)據(jù)的長度；

unsigned char* data_buffer：發(fā)送的數(shù)據(jù)；

返回值：函數(shù)執(zhí)行返回碼。

4 結(jié) 語

本文介紹了SWP結(jié)構(gòu)，描述了HCI協(xié)議的實現(xiàn)，通過編譯成C語言的庫，預(yù)留了硬件的回調(diào)函數(shù)接口，做到了硬件無關(guān)性，即可以在不同的SWP硬件上使用。當(dāng)前，智能手機等移動設(shè)備得到了普及，小額移動支付、公交一卡通方面的解決方案也成為熱點，而NFC+SWP技術(shù)將在該領(lǐng)域得到更充分的應(yīng)用。