Posted by Lawpig on 5月 31, 2017 | No comments

IEEE 802.15.3 超寬頻短距離無線通訊安全技術剖析

一，前言

隨著無線通訊技術的發展，目前普及率最高的無線網路技術，應以無線區域網路IEEE 802.11標準為尤，無線通訊的技術應用正逐步的由企業用戶的需求邁入到家庭與一般使用者生活中。隨著使用者需求的多樣性，長距離無線寬頻通訊技術IEEE802.16也隨之興起，藉以滿足使用者在辦公室、居家甚至是在戶外移動的數據傳輸需求。然而無線通訊技術不僅止於目前所觸及的區域與長距離通訊需求，更進一步的，符合個人化需求的無線通訊技術應運而生，而IEEE 802.15.3 UWB (Ultra Wideband)即是其中備受矚目的應用之一。

目前，IEEE 802.15系列短距離無線通訊(Wireless Personal Network)技術包括了，

(1) IEEE 802.15.1 e 藍芽(Bluetooth)通訊技術

(2) IEEE 802.15.2 e 解決802.15系列與其它無線通訊技術互通性的問題

(3) IEEE 802.15.3 e UWB 短距超寬頻無線通訊技術

(4) IEEE 802.15.4 e Zigbee 短距低功率無線通訊技術

分別滿足使用者省電、高低速傳輸與多媒體周邊應用上的需求，然而眾多無線通訊技術出現在我們生活中，而無線通訊並不若傳統有線傳輸技術般，惡意入侵者需透過實體接線方式，才得以擷取傳輸的封包資料，也因此無線資訊傳輸的安全性，一直以來便在IEEE 802無線通訊技術中，扮演極具關鍵的角色。

若以目前主要的無線網路技術安全性進一步分析，我們可以將技術內容大致區分如下圖(一)所示

圖(一)，802.11/15.3/16安全性技術分析

其中包括了

(1) Encryptione包括各類加密技術，例如: 802.11 封包加密技術採用WEP/TKIP/AES-CCM、802.15.3 封包加密技術採用AES-CCM/AES-CTR與802.16封包加密技術採用AEC-CCM/AES-CTR/DES-CBC

(2) Key Management Protocole主要為屬於 Layer 2 MAC 的金鑰管理與交換通訊協定

(3) AAA (Authentication / Authorization / Accounting )e主要為屬於 Layer 3 的認證、授權與計費通訊協定

而目前802.11i與802.16e所制訂的安全技術標準中都定義並且包括了這三塊的技術內容，從使用者身份認證到金鑰協議到加密技術，都有一完整的規範。 然而目前802.15.3的技術內容中，主要定義了加密技術與部分金鑰協議的技術規範，對於裝置認證授權與裝置間安全性關係的建立仍尚未完整，此部分之內容將是未來IEEE 802.15.3產品在進入市場同時，所需要面對的關鍵議題。

二，系統架構

如下圖(二)所示，一個IEEE 802.15.3 Piconet會包括一個PNC與一個或一個以上的DEVs，IEEE 802.15.3的無線網路資源管理機制主要透過PNC集中管理，因此一個Piconet的形成必須要有一可成為PNC之裝置，該裝置亦可在Piconet中擔任DEV的角色。同時，在一個Piconet 的架構下，每個DEV都會透過PNC的Beacon訊息所包含的Time Token進行時間同步，而PNC與DEV間或是DEVs之間都可以彼此互相傳遞資料。

圖(二)，IEEE 802.15.3 Piconet 範例

目前IEEE 802.15.3支援兩種Secuirty模式，分別為

(1) Security 0e不加密

(2) Security 1e加密模式採用128-bits AES Key，其中驗證封包完整性透過AES-CCM (Advanced Encryption Standard-Counter with CBC-MAC mode) 64-bits Integrity Code，加密封包部分透過AES-CTR(Advanced Encryption Standard -Counter mode)加密演算法，。

如下圖(三)所示，一個完整的IEEE 802.15.3封包格式主要包括前面2-bytes的Frame Control、2-bytes的Piconet ID、1-byte Destination ID、1-byte Source ID、3-bytes Fragmentation Control、1-bytes Stream Index共10bytes長度的IEEE 802.15.3 Header，並在 Frame最後加上4bytes 的Frame Check Sequence，與其中長度不等的Frame Payload。

若為Security Mode 0，則一個Frame的組成為10-bytes的IEEE 802.15.3 Header、長度不定的Frame Payload與Frame結尾的FCS值。

若為Security Mode 1，則Frame Payload將經過AES-CTR演算法加密，並透過AES-CCM演算法產生8-bytes的Integrity Code，並加上2-bytes的SECID (Secure Session ID)用來辨識此次加密所用的128-bits Key與2-byts的SFC(Secure Frame Counter)用來區隔同一把128-bits AES Key 在不同時間加密過程產生的加密封包與Integrity Code。

圖(三)，IEEE 802.15.3 加密後封包格式

如下圖(四)所示，對於接收端而言，在收到一個IEEE 802.15.3封包時，需要先確認16-bits 的Frame Control中SEC欄位是否為1，若是則表示此封包是有經過加密程序保護的.

圖(四)，Frame Control 欄位

如下圖(五)所示，一個經過加密程序處理過的IEEE 802.15.3封包，會包括SECID欄位，而此欄位主要的目的就是用來區隔每個不同加密金鑰產生者所產生的不同加密金鑰，由於IEEE 802.15.3 Piconet同時可以包括一個PNC與多個DEVs，而每個PNC-DEV與DEVs之間認證加密的金鑰都是各自獨立，也就是說同一個DEV對不同的DEV所產生的資料加密金鑰都是各自獨立不同的，只要其中的PNC 或是DEV可以成為金鑰發行者(Key Originator)角色即可。而同一個PNC對所屬同一個Piconet的所有DEVs所產生的群組資料加密金鑰(Group Data Key)都是相同的，也因此相對於同一個PNC而言， 群組資料加密金鑰是可以用來當作 Broadcast訊息加密之用。但若是PNC與DEV之間欲傳遞之資料非Broadcast需求之用，則會產生此時PNC-DEV之間專屬之資料加密金鑰(Peer-to-Peer Data Key)，而各自DEV之間所建立的資料加密金鑰(Peer-to-Peer Data Key)也是各自獨立，用以提供不同DEVs之間用來傳遞私密資料之用。

SECID欄位，前8-bits代表的是金鑰發行者(Key Originator)的8-bits ID，而後8-bits代表相對於此金鑰發行者所發行的每把金鑰的專屬8-bits ID，對同一個金鑰發行者而言此8-bits 金鑰ID必須是不重複的。

圖(五)，SECID 欄位

三，加密技術剖析

IEEE 802.15.3在加密與產生認證資料時，會加入一隨著時間改變的TimeToken數值，也就是說隨著時間的變動，同一把128-bits AES Key在每次加密過程後都會產生不同的結果，主要原因就是Nonce數值將會加入TimeToken在每次加密或是產生認證資料時動態產生Nonce，並且加入AES-CCM與AES-CTR運算中，用來增加駭客惡意破解的難度。 也因此，TimeToken數值對於整個Piconet而言是要隨時保持同步並且動態更新的，因此每個在 Piconet中的DEV都會隨時接收來自PNC傳送的Beacon Frame，並判斷其中所包含的TimeToken正確性，並更新DEV本身同步的TimeToken Value. 因此在同一個Piconet中，不論是DEV<->PNC或是DEV<->DEV之間的傳輸，都會參考到同樣的TimeToken數值，並藉此同步兩邊的Nonce 數值，對於意圖入侵者而言，在入侵前就必須要間聽Beacon Frame，先取得TimeToken的內容，建立基本Nonce數值的參數。

如下圖(六)所示，每一個IEEE 802.15.3 DEV都會透過接收來自PNC的Beacon Time Token欄位與PNC進行時間參數的同步，每個IEEE 802.15.3 DEV會隨時更新同步兩個重要的Time Token變數，分別為

LastValideTimeToken e儲存上一次接受到來自Beacon Frame 有效的 Time Token

CurrentTimeTokene為目前IEEE 802.15.3 DEV的 Time Token

若此次順利接收Beacon Frame的資料，就會同步更新 LastValideTimeToken與CurrentTimeToken，而用來判別Beacon Frame 所包含的 Time Token 是否正確，主要依據此數值是否介於LastValidTimeToken + “最大Time Token改變值“ 與 CurrentTimeToken之間。 對接收端而言，若無法用此時的CurrentTimeToken解回所收到的資料封包，則CurrentTimeToken就會增加，用以試圖在下一次的封包解密中，解出正確的資料。

圖(六)， Time Token 判斷示意圖

如下圖(七)所示，筆者假設在連續送出四個Beacon的期間，在Beacon n與Beacon n+1 期間，由於成功接收到Beacon n的Time token ，因此在這Beacon區間中，送端將使用此一Time token搭配隨著每一個Frame送出時增加的SFC(Secure Frame Count)來加密每一個封包. 然而在Beacon n+1與Beacon n+2 的區間中，由於接收端沒有成功收到 Beacon n+1 所帶的Time token，因此在這區間中的LastValidTimeToken與CurrentTimeToken仍舊是Beacon n的Time token，在接收端試圖解出第一個Frame失敗後，便會增加CurrentTimeToken的值，再用來解下一個Frame，直到可以正確解出Frame，與Beacon n+1的 TimeToken同步為止，或是等到下一個Beacon n+2發出，重新使得LastValidTimeToken=CurrentTimeToken=Beacon n+2 Time token.才得以解出 Beacon n+2 之後的封包。

圖(七)，透過Beacon Frame 同步Time Token與修正CurrentTimeToken示意圖

如下圖(八)所示，在一個Piconet中，DEV與DEV資料的加密傳輸主要需要兩把Key，分別為用來加密DEV<->DEV相關資訊的Peer-to-Peer Management Key，並且透過Peer-to-Peer Management Key加密稍後用來傳送 DEV<->DEV Data Frame的Peer-to-Peer Data Key。

而在DEVs彼此傳輸資料前，必須先由一端向可成為金鑰發行者(Key Originator)的DEV發出經過Peer-to-Peer Management Key 加密之Request Key　Command Frame。金鑰發行者在收到這個要求後，會產生新的128-bits AES Key與對應之SECID，並透過被Peer-to-Peer Management Key 加密後之Request Key Response Command Frame送回給要求金鑰之DEV端。完成這個程序後，欲傳輸加密資料的DEVs兩端就可以將此128-bits AES Key作為稍後要用來加密之Peer-to-Peer Data Key，用以加密之後兩端傳輸之Data Frame。

圖(八)，DEVs之間的Management Key與 Peer-to-Peer Data Key

如下圖(九)所示，在一個Piconet中，DEV與PNC資料的加密傳輸主要需要同步兩把Key，分別為用來加密DEV<->PNC連線的PNC-DEV Management Key與用來傳送Broadcat資料的Group Data Key。

DEV同樣可以將PNC視為金鑰發行者(Key Originator)，經由Request Key　Command Frame要求新的128-bits AES Key。而PNC 亦可透過經由PNC-DEV Management Key加密後之Distribute Key Request Command Frame傳輸欲DEV採用之Data Key，而此Data Key 可以為PNC與該DEV之間傳輸之Peer-to-Peer Data Key，亦可為PNC傳送給DEVs用來傳送Broadcast資料之Group Data Key。

圖(九)，PNC與DEVs之間的Management Key與 Group Data Key

對於Piconet中PNC角色的轉換與Security 資訊的交換，所牽涉到的Command Frame還包括Security Information Command Frame 與 Security Message Command Frame，這部分筆者就不在本篇文章中多所著墨，各位可自行參閱IEEE 802.15.3的標準文件。

如下圖(十)所示，在IEEE 802.15.3進行認證或是加密資料的運算前，需要由所傳輸的Frame中取得相對應的資料，藉以產生之後要用在加密過程中之13 bytes Nonce值，根據目前IEEE 802.15.3所定義的Nonce取得方式，總共有四個欄位會關係到Nonce的取得，分別為

(1)8-bits 的 Destination ID

(2)8-bits 的 Source ID

(3)24-bits 的 Fragmentation Control

(4)16-bits 的Secure Frame Counter

圖(十)，MAC Frame Field about Nonce

將下來，讓筆者用實際的例子來介紹IEEE 802.15.3的認證技術(Integrity Code)，IEEE 802.15.3承襲了AES-CCM計算64-bits Authentication Code的技術，提供收送封包兩端在加密通訊的過程中可以驗證兩端使用者封包的正確性與完整性，讓收端使用者可以進一步的確認封包內容是否有被更動過或是預防惡意的駭客嘗試入侵。如下圖(十一)所示，AES運算前會先取得長度為13-bytes的Nonce值

圖(十一)，AES Nonce Value Format

如圖(十三)所示，由於AES-CCM產生Authentication Code的方式為，先將要運算取得Authentication Code的資料區塊，依序切割為多筆128-bits長度的資料區塊。再產生Block(0)，並將Block(0)透過目前使用的128-bits AES Key加密，並將加密後之128-bits資料與第一個128-bits資料區塊進行XOR運算，再將經過XOR運算的結果，透過128-bits AES Key再度加密，同樣會產生128-bits長度的加密後區塊，再跟下一個切割出來長度為128-bits尚未處理過的資料區塊進行XOR運算，依此類推，直到最後一個區塊運算結束為止。若最後一筆資料不滿128-bits，就會把不滿的部分補0，同樣與前一筆經過128-bits AES Key加密後得到的128-bits長度的加密後區塊進行XOR，如此即可取得長度為128-bits的加密後區塊值，最後用來當作64-bits Authentication Code的區塊則取自這128-bits區塊的最低64-bits區塊。

而128-bits Block(0)資料格式，主要如下圖(十二)所示，L值等於資料長度欄位所需的位元數(一般而言L=2 bytes)，l(m)欄位儲存的是送出資料的長度，Flags欄位在此主要是用來表示是否此次Integrity Code運算，有包含Authentication Data、Integrity Code(如圖(十三)範例中，M=4)與資料長度欄位((如圖(十三)範例中，L=2)

圖(十二)，AES-CCM Authentication Code Block0

然而，針對IEEE 802.15.3的需求，要用來計算64-bits Integrity Code的資料段落還包括有，長度為 2、6或10bytes的 “l(a)” 參數、Frame Header、SECID(Secure Session ID)與SFC(Secure Frame Counter)。根據目前Specification的定義，l(a)值為此次欲送出的Frame Authentication 資料的長度，如下表(一)所示

表(一)，根據Frame Type所對應之l(a)數值

Frame type	Authentication Data	Authentication Data Length
Data Frame	10 bytes Frame Header + 2 bytes SECID + 2 bytes SFC	14 bytes
Beacon Frame	10 bytes Frame Header + 2 bytes SECID + 2 bytes SFC + 13 bytes Piconet Synch. Parameters	27 bytes + Total length of information element
Command Frame	10 bytes Frame Header + 2 bytes SECID + 2 bytes SFC + 2 bytes Command type + 2 bytes Length Field	18 bytes

而Frame Authentication資料內容，主要就包括Frame Header、SECID(Secure Session ID)與SFC(Secure Frame Counter)與依據Frame type所相對應之額外資料區塊，在計算Authentication Code時，需額外針對Frame Authentication資料內容切割為各自獨立的128-bits區塊，並針對最後不足128-bits的部分補0。

而根據 l(a)值所對應的結果，我們就可以決定此次要參與AES-CCM Integrity Code計算的l(a)欄位所需代表的長度是2、6或是10bytes，如下表(二)所示

表(二)，根據l(a)數值所對應之Length Encoding

l(a)	Length Encoding	First 2 bytes	Followed by
0 < l(a) < 2^16-2^8	2 bytes	0x0001…0xFEFF
2^16-2^8 < l(a) < 2^32	6 bytes	0xFFFE	4 bytes l(a)
2^32 < l(a) < 2^64	10 bytes	0xFFFF	8 bytes l(a)

圖(十三)，AES-CCM 認證技術

在透過AES-CCM計算取得64-bits Integrity Code後，接下來便要透過AES-CTR加密演算法進行資料加密的動作。如下圖(十四)所示，在正式進行AES-CTR加密運算前我們同樣需取得之後要用來參與運算過程的128-bits Block(i)，其中最大的不同在於第一個byte為Counter，每處理過一個128-bits的資料區塊後，這個Counter數值就要加一，而其中要注意的就是當Counter為0時，主要是用來加密資料最後所附加之64-bits Integrity Code，其它欲加密之128-bits資料區塊，就從Counter為1開始，依此類推。

圖(十四)，AES-CTR Message Encryption Block Ai

如圖(十五)所示，在進行AES-CTR加密運算時，我們須先將欲送出之資料區塊依據128-bits資料長度分割，將Block(i)透過128-bits AES Key加密，並把Counter=1時，經過AES運算加密後之結果，與第一個128-bits資料區塊進行XOR運算，得到第一筆加密後區塊。接下來循序將Count=2之Block(2)，經過AES運算加密後之結果，與第二個128-bits資料區塊進行XOR運算，得到第二筆加密後區塊。將Count=3之Block(3)，經過AES運算加密後之結果，與第三個128-bits資料區塊進行XOR運算，得到第三筆加密後區塊。直到所有資料均經過加密運算後，則可得到欲送出之加密後IEEE 802.15.3封包資料。並且在資料送出前，加上SECID與SFC值至Frame Header，其中SECID指的是此次加密所使用之128-bits AES Key而SFC則須在資料送出後加一，用以區別同一把128-Bits AES-Key與同一個Time Token 在不同時間所加密送出之資料。

由於IEEE 802.15.3所能支援之傳輸速率甚高(在未來甚至可達1Gbits)，因此在加密運算的過程中，若透過軟體實做將影響系統效能甚鉅，也因此透過硬體實現加密演算法的動作，將成為目前主要的設計趨勢，而透過AES-CTR的好處在於，AES-CTR運算可以在取得Block(i)格式後，透過硬體平行運算每一個128-bits區塊各自對應的Block(i)，進而在最短時間內計算完整個欲加密資料結果。

圖(十五)，AES-CTR 加密技術

經過上述的文章介紹，我們可以發現以安全性而言IEEE802.15.3無疑是已具備相當水準之驗證與加密機制，然而針對未來實際應用到市場上商業化產品，尚有許多不足之處，例如

(a) 針對DEV與PNC之間如何建立安全性群組關係(Security Membership)

(b) Management Key之取得建立流程

(c) 是否針對Application Specific OUI(Organizationally Unique Identifier)應用，有一完整產品互通測試認證機制 (例如: WLAN Wi-Fi聯盟此類，強而有力之機構統籌與訂定測試認證標準)

整個IEEE 802.15.3 所形成之加密安全機制，主要建立在Time Token與SFC值的動態變化上，也因此對於惡意入侵之駭客而言，所形成之高複雜性，不言可喻，然而在正式部署的過程中，如何有效的取得Management Key與建立安全性群組關係，將是急需解決之課題.

四，結語

在可預見的未來，數位化家庭的生活將逐步在我們周遭實現，而各類無線通訊的技術無不在此時摩拳擦掌等待切入市場時機，以目前普及率甚高之802.11a/b/g商品所支援最高傳輸速率54Mbps，到近來業者領先標準推出之Pre-802.11n產品，無不針對無線高速傳輸與未來數位家庭市場提早佈局。

而IEEE 802.15.3挾其480Mbps高速傳輸之特性，與未來相關技術標準可達1Gbps之利基點，正由各類業者積極推動，在近期也將有各類產品陸續推出，可預見的未來數位家庭將會是國際各大業者積極爭取並拓展市場之領域。而安全性，無亦是各類無線通訊應用上最需關注之議題，期許可以藉此文章將IEEE 802.15.3短距無線通訊技術安全議題為各位有一清晰之剖析，並對產業有所助益。

五，參考資料

(1) IEEE 802.15.3 Wireless Medium Access Control and Physical Layer Specifications for High Rate Wireless Personal Area Networks