雜湊機制

本小節所介紹中央集權式雜湊驗證機制，在 RFID 電子標籤內儲存識別ID 資料以及Secret Key，執行標籤驗證時系統將電子標籤內所存資料利用SHA1雜湊 函數運算其摘要值後，將此摘要值傳送至Back-End Server驗證該標籤合法性，接 下來說明該機制的符號定義以及細部運作流程。

在表六中Back-End Server存放RFID電子標籤序號(ID1~n)以及RFID電子標籤 金鑰(K1~n)，當Back-End Server收到RFID讀寫器所傳送的RFID標籤摘要值時，便 使用SHA1雜湊函數以及資料庫內的ID1~n、K1~n驗證標籤正確性。IRq、IRs以及 SRq為資料清單請求格式被定義在 ISO/IEC1800-3[4] ，在驗證系統傳遞機密資 訊時利用ISO/IEC1800-3所定義的資料格式封裝後，在傳送至目的端可增加資料 傳送時的安全性。

17

定義符號：

Tag RFID 電子標籤 Reader RFID讀寫器

Back-end Server 為一資料庫其內容包含電子標籤序號(ID1~n)、電子 標籤金鑰(K1~n)以及電子標籤所存資料

Ki、K0 每一個Tag與server間皆有一對Secret key,K0為share key

H 雜湊函數

S 雜湊值(S = H(r))

IRq Inventory request format with S HT1 雜湊值(H(S || K1 || D1))

IRs Inventory request format with HT1 SRq Inventory request format with K0

表 六：中央集權式雜湊驗證協定符號定義 驗證流程圖：

驗 證 機 制 如 圖 八 所 示 是 建 立 在 三 次 的 挑 戰 與 回 應 (three-way challenge response)，首先由RFID讀寫器產生亂數(r)封裝後傳送至RFID標籤，而後RFID標籤 發出回應的資料傳送回RFID讀寫器。此機制所使用的亂數是由RFID讀寫器所產 生，在傳統的雜湊驗證機制中亂數皆是由RFID標籤所產生[2] ，所以我們可以比 傳統的雜湊驗證機制[2] 使用成本更低的RFID標籤。

圖 八：中央集權式雜湊驗證機制

18 可以保護man-in-the-middle-attack行為。

步驟3： 對用以驗證RFID標籤是否合法，若合法則後台伺服器會傳送K0以及data 其中K0 = H(K1 || S)，data為RFID標籤所存的資料。在此步驟RFID讀寫 器的驗證已完成，而所傳送的K0是用來驗證RFID標籤，且在伺服器中 所存的K1也會改變。K1 = K0 + ID1。

步驟5：

RFID讀寫器使用K0重新建構延伸選擇請求的資料格式(eSRq = SRq & K0)，然後將此eSRq傳送至RFID標籤，SRq詳細資料欄位如表 九 所示。

步驟6：

RFID標籤計算出K’0(H(K1 || S ))，接下來比對K’0與所接收到的K0

是否相同，若相同則更新RFID標籤內所儲存的K1。K1 = K0 + ID1，因此 RFID標籤可避免重現攻擊。

19

協定中所使用的延伸資料格式：

在ISO/IEC 18000-3規格書中主要是在描述頻率13.56Mhz的RFID標籤與 RFID讀寫器之間的溝通[4] [5] 。在請求與回應的訊息其資料欄位皆包含 Start-of-Frame (SOF)以及End-of-Frame (EOF)，在一般的請求訊息欄位是由SOF、

Flag、Command Code、Parameters、Data、CRC以及EOF所組成。

Command Code主要是由四個命令型態所組成，其命令定義為Mandatory、

Optional、Custom以及Proprietary。在驗證的機制中主要會使用到定義在Mandatory 以及Optional型態裡的Inventory及Select指令來達成兩個裝置之間的溝通。在表 七的資料格式為更改規格書裡所定義的Inventory request format(IRq)資料欄位，將 本機制所產生的雜湊值S加入到IRq中，形成本機制所需的elRq資料欄位。

SOF Flags Invent Opt.

在規格書中請求訊息的內容欄位包含Flags、Inventory、Optional AFI、Mask Length、Mask Value 以及 CRC。而在延伸的版本中只是單純的將雜湊值 S 加入 到欄位裡，然後將此elRq 資料傳送至 RFID 標籤。當 RFID 標籤收到 elRq 後，

在規格書中清單回應訊息欄位包含Flags、DSFID、UID 以及 CRF，但是在 延伸的欄位格式中我們將UID 的欄位替換成 HT1。此 64-bits 的 HT1 主要是用來 驗證RFID 標籤所送的回應訊息真偽，因此在圖 八所示的驗證機制，就算延伸 清單回應訊息被攻擊者所截取，對於本驗證機制並不會造成任何的威脅，因為對 於攻擊者來說延伸清單回應訊息裡的所有資料皆是無用的。

20

在延伸選擇請求封包格式是由ISO/IEC 1800-3規格書中所定義的選擇請求欄 位插入K0所更改而成的，詳細的資料欄位如表 九所式：

SOF Flags Select UID K0 CRC EOF

8bits 8bits 64bits 16bits 16bits

表 九：包含 K⁰延伸選擇請求資料格式

在ISO/IEC 1800-3規格書中選擇請求資料欄位包含Flags、Select、UID以及 CRC，而在本延伸的版本中只是將K0附加進此資料欄位裡。在本機制裡K0是由

在表十中所定義的亂數(r、i)表示長度不可超出 TagID(S)，因為亂數(r、i)是 用來指定本次Session 要取出 TagID(S)的哪些欄位做互斥的運算，以產生標籤驗 證的資料。Back-End Server 在本機制所存放的資料為 RFID 標籤的 Serial Number(S)，在收到 RFID 讀寫器所傳送的資料後，運算內部所存的 RFID 標籤 Serial Number 是否有相符。