Posted by Lawpig on 5月 31, 2017 | 1 comment

IEEE 802.16寬頻無線網路安全技術介紹

一， 前言

隨著近年來Wi-Fi(802.11x)產品的日漸普及與3G無線通訊技術的推波助攔下，無線行動通訊技術一直都是大家所注目的焦點，而由Intel所主導成立的WiMAX聯盟，則在此波技術更迭進程中，緊抓住了IEEE 802.16寬頻無線網路技術的浪潮，提供傳輸距離約四十八公里，每秒傳輸速度可達70Mbps無線傳輸技術。依據目前規劃，在2005年底前消費市場上將有機會看到802.16相關產品問市，值此同時，也正意味著寬頻長距離的無線網路技術，將更生活化的融入使用者的生活中。

雖然，新的技術應用將醞釀進而促成市場興起，相對於消費者與企業所關注的層面，還包括無線網路安全性之議題，而本文所著重之802.16無線網路技術，將針對802.16無線網路在安全層面的技術議題，作一完整之剖析，其中包括部分相對於802.11技術之比較，與802.16在使用者認證、金鑰協議與加密技術之介紹，並作技術層面探討，希望可以對產業界投入此項產品開發有所助益。

筆者在本文中所有討論之802.16安全技術內容，主要依據以下兩份802.16標準

(1) IEEE P802.16-REVd/D5 May 2004

(2) 802.16e/D4 August 2004

二， 802.16 Security 系統架構

由於802.16會將每個網路傳輸連線賦予一個CID(Connection ID)，並且可根據連線時的需求，訂定不同之安全性參數。也因此，相對於802.11i的無線網路安全標準而言，802.11i對於每位使用者，只有兩種不同的加密金鑰，分別用在使用者本身的Pairwise Key與針對群組廣播之Group Key，並無法針對使用者單一連線，獨立的分配一金鑰，在802.11i Access Point端主要仍是以MAC Address來區分使用者連線上網之網路封包，因此對於支援同一使用者多連線與多加密金鑰之應用上，仍有其先天不足之處。

相對於802.11i之問題，802.16在線連初期會建立三個Management Connection，同樣的每個連線都會分配到CID(Connection ID)，如下圖(一)所示，在建立Primary management connection後，使用者端(SS)會與基地台端(BS)進行認證程序，認證過程中會確認使用者憑證與驗證使用者身份，並由基地台端(BS)根據使用者端(SS)提供所支援之加密能力，選擇對應之組合，並給予SAID(Security Association ID)之分配，其中三個Management Connection，只有Secondary Management Connection會分配到加密之SAID，其餘兩個Management Connection是完全不加密的，而往後每個使用者各自建立之Transport Connection可以依據使用者需求，選擇所欲使用的加密技術與其對應之SAID。

圖(一)，802.16連線建立與SAID產生示意圖

接下來，我把802.16所支援的認證與系統架構分為三類加以說明，首先如下圖(二)所示，是802.16在PMP(Point-to-MultiPoint)模式下所採用之認證架構，每個使用者端(SS)都會包括由設備業者或是系統業者所提供之使用者憑證(User CA，X.509格式)，在使用者連線到基地台端(BS)時，首先會送出 Authentication Information封包，其中主要包括使用者憑證資訊(但不包括金鑰)，之後緊接著使用者端(SS)會送出Authorization Request (包括使用者憑證資訊與金鑰、SS所支援之加密能力與Primary SAID)，其中根據目前802.16e/D4所訂定之內容所示，802.16將可支援如表(一)所示之加密能力。

在基地台端(BS)收到使用者Authorization Request封包後，會確認使用者的憑證，並產生AK(Authorization Key)，之後會透過使用者憑證所包含之金鑰(Public Key)，經由RSA演算法加密AK，再透過Authorization Reply封包傳回包括加密後的AK、Key Lifetime(in seconds)、AK Sequence Number (PKM1 為4bits 但 PKM2則加長至 64bits)、同意使用者端採用之加密認證技術(包括對應之SAID)與PKM相關設定(主要為認證階段的Timer與更新Key階段等待與逾時時間參數設定)，可用來確保在認證與換Key的過程中，兩端等待時間週期的一致。

使用者端(SS)在收到Authorization Reply後，在透過本身使用者憑證之私鑰透過RSA演算法解回AK值，在此階段，兩端均已取得往後加密過程中最主要之AK值，接下來便是為使用者每個連線產生獨立之加密金鑰TEK(Temporal Encryption Key)，若使用者要建立三個資料傳輸連線，便需如圖(二)所示，在建立資料傳輸連線的過程中，額外進行三次Key-Request與Key-Reply的動作，透過原先取得的AK值，為三個資料傳輸連線，產生獨立的三份TEK值，以便用來加密新建立之資料傳輸連線。

首先，使用者端(SS)要送出Key Request (包括所使用AK Sequence Number、SAID(對應到使用者所支援之加密與認證技術能力)與用來確保Key-Request封包完整性之160bits HMAC-Digest，在基地台端(BS)收到封包後，會先透過SHA演算法計算整個封包之HMAC-Digest數值。在PMP 模式下，Downlink的HMAC-Digest為 HMAC-Key 64bytes 0x3a array | AK後，經由SHA演算法計算整個封包，所產生之160bits數值(Uplink 部分則把 0x3a 改為 0x5c )，如此可供基地台端確認目前連線之使用者端是否擁有正確之AK值，作為判別是否為合法使用者端之依據。

在基地台端確認Key Request封包完整無誤後，會根據所要求之AK與SAID，產生該連線之後加密要使用之TEK值，再透過Key Reply回傳給使用者端。由於802.16 PKM提供使用者端(SS)與基地台端(BS)在兩把TEK Key更新過程中的緩衝機制，應此在回應時，若使用者原本就已建立TEK連線，基地台端將回應使用者端舊的TEK參數與新的TEK參數，其中會包括經由KEK(Key Encrypt Keys)加密後之TEK數值、TEK lifetime、TEK Sequence Number與供DES CBC mode加密使用之64bits CBC-IV值(若使用者選擇用DEC-CBC演算法加密資料傳輸封包，才會包括此欄位，並且此時TEK值將只有64-bits)。其中KEK(Key Encrypt Keys)所指的是用來加密Key的Key，在802.16中KEK可由AK計算取得，並可用來加密在之後傳輸的TEK值，以避免TEK值在傳輸過程中被惡意擷取。

在使用者端收到Key Reply封包後，同樣的要驗證HMAC-Digest數值，判別目前所接收的Key-Reply封包是否來自合法認證的基地台端，在確認無誤後，就會透過KEK(Key Encrypt Keys)解回TEK正確數值，並應用在後續資料連線中。

目前802.16 TEK主要可以用以下三種方式加密

(1)3-DES EDE (Encrypt-Decrypt-Encrypt)

(2)AES ECB (Electronic Codebook)

(3)RSA 1024-bits

其中(1)與(2)的KEK值需透過3-DES KEKs (Key Encrypt Keys)演算法，如下所示

KEK = Truncate (SHA(K_PAD_KEK|AK，128)

K_PAD_KEK=0x53 repeated 64 times (512-bits string)

這邊所使用的AK值，便是剛剛在Authorization Reply中所取得之AK值。而關於TEK詳細的加密機制(ex: RSA、3-DES EDE or AES ECB)，筆者在此便不累述，各位可進一步參閱IEEE 802.16d/e相關標準。

圖(二)，802.16 in PMP mode

表(一)，802.16支援之加密&認證技術

對應Cryptographic Suite參數	加密認證技術說明
	資料加密技術	資料認證技術	TEK金鑰加密技術
0x000001	No data encryption	no data authentication	3-DES,128bits
0x010001	DES CBC-Mode, 56bits	no data authentication	3-DES,128bits
0x000002	No data encryption	no data authentication	RSA,1024bits
0x020002	DES CBC-Mode, 56bits	no data authentication	RSA,1024bits
0x020103	AES CCM mode, 128bits	AES CCM mode,128bits	AES ECB mode,128bits
0x800003	AES CTR mode, 128bits (for MBS with 32bits Nonce)	no data authentication	AES ECB mode,128bits

MBS: Multicast Broadcast Service

相對於PMP 模式，802.16亦提供Mesh模式作為無線網路建置基礎選擇之一，如下圖(三)所示，當802.16裝置在Mesh模式時，允許使用者兩端彼此認證，首先同樣的送出Authentication Information與Authorization Request，並由另一端使用者送出Authorization Reply (包括Operator Shared Secret、Key life-time、Key Sequence Number、允許支援加密認證技術、PKM相關設定參數)，其中Operator Shared Secret為使用者預先輸入之數值用來取代AK值，作為在Mesh模式下所有使用者電腦共同採用之AK值。

在取得AK之後，接下來便如同原本PMP模式一般，為每個資料傳輸連線建立個別之TEK與選擇SAID，提供安全性之資料傳輸。

圖(三)，802.16 in Mesh mode

由於之前提到的兩種架構，都沒有牽涉到後端使用者認證伺服器運作，然而針對公眾網路之應用，802.16擁有更為長距之無線網路服務涵蓋面，極可能成為公眾網路佈建服務必要應用技術，甚至成為目前802.11 HotSpot之骨幹網路，也因此802.16e特別針對AAA(Authentication、Authorization and Accounting)與後端伺服器認證架構，有相關支援，如下圖(四)所示

圖(四)，802.16e 無線網路認證示意圖

如同802.11i，802.16e也採用EAP認證(包括 TLS/TTLS/PEAP….etc)為基礎，透過MAC Layer新訂定之PKM-Req-EAP Transfer Request Message與 PKM-Rsp-EAP Transfer Reply Message來傳送使用者端(SS)與基地台端(BS)之EAP訊息，在基地台端(BS)之後則透過Radius(或 Diameter)協定 與後端認證伺服器進行使用者身份認證。在EAP認證成功後，使用者端(SS)會經由EAP所採用演算法(例如：TLS)取得一組EAP Master Key (取其前32 bytes)，而基地台端在剛剛認證的過程中，完全屬於轉送者的角色，並不參與其中認證演算法的過程，因此在收到後端認證伺服器所送的Radius Access-Accept訊息後，便需要計算出長度為32 bytes的MS-MPPE-Recv-Key值(透過基地台端(BS)與後端認證伺服器(Radius Server)之Shared Secret、Radius 封包中之128-bit Request Authenticator與2-bytes的Salt值計算取得)，而這32-bytes MS-MPPE-Recv-Key與使用者端取得自EAP Master Key中的32-bytes資料完全一致，也就是之後PRF-384加密使用的32-bytes PMK(Pairwise Master Key)值。關於取得MPPE-Key方式跟802.11i一致，各位若有興趣可以進一步參閱參考資料(3)、(4)與(5)。

在使用者端與基地台端各取得相同32 bytes Key值後，便要透過PKM EAP PRF-384的演算法取得KCK(Key Confirmation Key，128 bits)與AK(Authorization Key，160bits)，PKM EAP PRF-384演算法如下所示

PRF-384(PMK, “Pairwise key expansion”, Min(BSID,SSID) || Max (BSID,SSID)|| Min(BSNonce,SSNonce) || Max(BSNonce,SSNonce))

其中PMK(Pairwise Master Key)為剛剛所取得的 32-bytes Key值，SSID與BSID則為802.16連線兩端48-bits長度之ID，後面的SSNonce與BSNonce則為圖(四)，EAP-Establish-Key Request與EAP-Establish-Key Reply所交換的32 bytes長度 Nonce。

首先，在基地台端收到Radius Access-Accept後，確認該使用者已成功通過後端認證伺服器之使用者身份驗證，便會隨機產生32bytes 的BSNonce透過EAP-Establish-Key Request傳送給使用者端(SS)，使用者(SS)端在收到EAP-Establish-Key Request取出BSNonce後，也會自行產生任意32bytes的SSNonce，透過PRF-384演算法即可取得KCK與AK，再透過EAP-Establish-Key Reply 傳送給基地台端(BS)，即可讓兩端取得之後要用來產生每個連線TEK加密金鑰的AK值。在整個過程中，兩端所交換32-bytes Nonce值是不加密的，真正隱藏的為32-bytes的PMK(Pairwise Master Key)，因此若PMK值被Hacker所擷取，則整個802.16e加密架構即有暴露之風險。

如下圖五所示，PRF-384演算法會先比較使用者端(SS)與基地台(BS)兩端之ID(長度為48 bits)，與各自產生的32 bytes Nonce值，由小至大連接成一個Buffer。之後如圖六所示，將“Pairwise key expansion”、補零與剛剛組成的Buffer並在最後補零，共同連結在一起成為hmac_sha1所加密之資料，並透過認證過程中產生的32-bytes PMK進行運算，每次均會產生160bits資料。因此PRF-384要產生出384bits資料共要運算三次，每運算完一次，並要把剛剛產生的Buffer最後一個byte加一，即可得出PRF-384運算結果。其中前128bits為KCK(Key Confirmation Key)值而最後160bits為AK(Authorization Key)，中間96bits暫不使用。

圖(五)，PRF-384 演算法1/2

圖(六)，PRF-384 演算法2/2

802.11i與802.16 Security不同之處在於，802.11i透過原本802.1x所定義的EAPOL封包格式傳送上層EAP 認證程序封包，再認證成功後，透過802.11i新訂定之EAPOL-Key封包格式(不同於802.1x所定義之EAPOL-Key格式)進行加解密金鑰的交換程序(4-way pairwise-key handshaking and 2-way group-key handshaking)。

三， 802.16 加密技術解析

相對於802.16來說，802.11i改變了原本802.11x使用WEP(RC4)加密演算法時，因同一把WEP Key在長時間使用下被駭客蒐集重複IV值，進而運算解回WEP Key的弊病，將原本的WEP加密技術進一步修改成為TKIP的演算法，透過兩端固定的Key值，依據每個封包產生各自加密的TKIP Key，提供了每個封包不同加密Key的能力，與駭客惡意突破的複雜度。但為了提供更高的安全性，802.11i更支援了AES-CCM(Advanced Encryption Standard-Counter with CBC-MAC mode)，而802.16亦採用AES-CCM作為資料傳輸加解密演算法，但除了AES-CCM外，802.16針對一般資料傳輸上，還可選擇複雜度較低的DES-CBC(Data Encryption Standard-Chain Block Ciphering)加密演算法，而針對Broadcast/Multicast的需求，802.16e亦採用較適合於群組廣播使用的AES-CTR(Advanced Encryption Standard -Counter mode)加密演算法，接下來，筆者將進一步為各位介紹802.16所採用的這三種加密演算法。

首先，在802.16支援的資料傳輸加密演算法為DES-CBC，透過KEY-Request/Reply 階段所產生的64bits TEK Key與 TEK Parameters中的64-bits CBC-IV值，可經由DES演算法進行加密，如下圖(七)所示，在資料傳輸時，將資料分為64-bits的區塊(最後若不足64-bits亦算一個區塊)，並將64-bits CBC-IV與第一個區塊的64-bits資料進行XOR運算，之後以TEK前54-bits值為Key透過DES加密演算法產生64-bits加密後的資料，並儲存到資料加密後的暫存位置，在處理下一個64-bits區塊時，便把前一個加密後的64-bits區塊與目前尚未加密過的64-bits區塊進行XOR運算，並以TEK前54-bits值為Key透過DES加密演算法同樣產生64-bits加密後的資料，依此類推直到把整個封包依序加密為止。而接收端，只要擁有相同的64-bits CBC-IV與64-bits TEK值就可以依序把封包解回了。

圖(七)，802.16 DES-CBC加密演算法

相對於DES-CBC的演算法，802.16亦採用了更進一步的AES-CCM加密演算法，提供更高程度的保護，基本上802.16 AES-CCM可以分為兩個部分，一個是加密階段，一個是認證階段，如此可以提供接收端在解回封包時，進一步的驗證封包在傳輸過程中是否有經過任何的修改，確保接收兩端更高程度的資料保護機制。

如下圖(八)所示，為AES-CCM認證部分的演算法示意圖，首先要產生16-bytes的Block(0)區塊，作為產生認證資料的第一個Block，在這個區塊中可以分為五個部分，分別為

Bytes Offset	意義
0	主要分為以下兩部分 (1)MIC_LENe表示確認封包完整性欄位的長度(ICV，Integrity Check Value)，如圖所示的ICV長度為8bytes，所以套用公式(M-2)/2後為 (8-2)/2 = 3 (2)DATA LENe表示封包實際傳輸資料長度要用多少Bytes來表示，如圖所示為2 bytes，表示資料長度最長為2^16 = 65536bytes
1-5	為封包的前5 bytes Generic MAC Header
6-9	預設為0
10-13	為每個封包不斷增加的Packet Number數字，並循序遞增，Downlink數字由0x00000001 至 0x7fffffff 而 Uplink由0x80000001 至 0xffffffff ，若數字達到快要增加到臨界值時，就必須要強制更新新的TEK值。若無法更新TEK值，將造成同一個TEK值與重複使用的Packet Number，進而成為駭客蒐集重複封包攻擊的目標，因此若無法即時更新新的TEK時，兩端將暫停送出封包。
14-15	用來儲存目前封包實際傳輸資料的長度。

在取得Block(0)區塊後，還需把要傳輸的封包資料依據每16 bytes為一區塊切割，到最後不足的部分則補0，之後從從Block(0)開始，以128 bits TEK 值帶入AES演算法Key開始加密，並將加密後16 bytes的值與依序每一個16bytes資料進行XOR運算，並同樣的透過128 bits TEK Key AES演算法加密，如此依序直到整個封包資料都經過運算後，最後再取最終運算值的最小8bytes (8bytes為筆者所採用的例子，可以依據情況選擇採用4、6、8、10、12、14或16 bytes長度的ICV值)作為最後要送出的ICV值。

圖(八)，802.16 AES-CCM認證演算法

再取得8bytes的ICV值之後，接下來就要把實際的傳輸資料進行加密，如下圖(九)所示，即為802.16 AES-CCM加密封包的示意圖，首先要產生16 bytes的Block(0)，每個部分意義如下

Bytes Offset	意義
0	主要為 DATA LENe表示封包實際傳輸資料長度要用多少Bytes來表示，如圖所示為2 bytes，表示資料長度最長為2^16 = 65536bytes 其餘部分皆為 0
1-5	為封包的前5 bytes Generic MAC Header
6-9	預設為0
10-13	表示每個封包不斷地增的Packet Number數字，為循序遞增，Downlink數字由0x00000001 至 0x7fffffff 而 Uplink由0x80000001 至 0xffffffff ，若數字達到快要增加到臨界值時，就必須要強制更新新的TEK值。
14-15	初始值為0，每經過AES加密使用一次，便加一

在取得Block(0)區塊後，首先以128 bits TEK 為Key透過AES加密，並與之前計算得到的8-bytes ICV值進行XOR運算。在結束ICV部分的加密動作後，接下來，便是對每一個實際傳輸資料的16-bytes區塊進行加密，此時Block(i)中的Count數值則由1開始累加，因此對第一個區塊為Block(1)、第二個區塊為Block(2)….依此類推，並且把每一個產生的區塊都透過128 bits TEK Key AES加密演算法產生一組16-bytes資料，並與所對應的實際傳輸資料16-bytes區塊進行XOR運算，直到整個封包都處理過，則完成傳輸資料封包的AES-CCM加密動作。

圖(九)，802.16 AES-CCM加密演算法

如下圖(十)所示，原本的802.16傳輸資料封包在經過AES-CCM認證與加密流程後，會增加大約12-bytes的資料長度(但ICV值是可以調整的，範圍為4-16 bytes，所以增加的長度可以為8-20bytes，視系統要求情況而定)。

圖(十)，經過802.16 AES-CCM加密後之封包格式

目前為止我們提到的加密技術都只限於802.16每位使用者各自獨立的網路傳輸連線，尚未涉及 Broadcast/Multicast的層面，802.16e為了提供高安全性與有效率的加密技術，同樣的也針對這樣的需求制訂出所需的加解密技術AES-CTR。

如下圖(十一)所示，為IEEE 802.16e Draft 4中所附之圖片，說明在AES-CTR加密技術下，經過處理的802.16e Broadcast/Multicast封包，在傳輸時將會多出額外的4 bytes Nonce欄位，用來搭配兩端經過Key-Request/Reply程序取得的128-bits TEK，進行AES-CTR運算。

圖(十一)，802.16 Multicast Broadcast Service 透過AES-CTR加密後封包格式 (取自IEEE 802.16e/D4 August 2004)

如下圖(十二)所示，AES-CTR同樣也需要產生一個Block(i)作為初始加密用的區塊，這16-bytes區塊全部由802.16 Broadcast/Multicast封包所加入之4-bytes Nonce連結而成16-bytes產生，同樣的把實際傳輸的資料分為每16-bytes為一個區塊，並把區塊最後一個byte加一成為Block(1)，每透過一次128-bits TEK為Key加密的AES運算後，便再把最後一個byte加一，成為Block(2)，而經過AES運算所產生的16-bytes資料，便與802.16 Broadcast/Multicast封包對應的16-bytes資料進行XOR 運算，最後把每個區塊運算後的值結合，即可成為最後要送出加密後的Broadcast/Multicast封包。

由於802.11i並沒有針對不同使用者連線定義不同加解密演算法之能力，因此若使用者決定採用802.11i TKIP 或是AES-CCM時，所有連線都將採用同一種加解密機制，而802.16可以針對使用者端與基地台端所支援的加密能力，同時提供多種加解密技術組合，例如針對一般802.16連線支援複雜度較低之DES-CBC加密技術，在傳送重要資料時可以建立AES-CCM加密連線，而在接收Multicast視訊串流資料時，可以在額外建立支援AES-CTR之加密連線，提供使用者依據不同服務與需求之安全等級選擇。

四， 結語

本篇文章雖然涵蓋了802.16主要的加密與認證流程，但篇幅所限筆者並不容易非常完整的細述所有認證、加密演算法與802.16e新訂之PKM2細節，希望可以透過這篇文章吸引更多對802.16無線通訊加密技術有興趣的同業加入相關產品開發工作，讓台灣的無線網路研發的工作能夠更為深入與紮實。

目前802.11(Wi-Fi)技術在國際大廠(Intel)推波助瀾下，不論是在使用或是普及上，均將無線網路應用層面大幅提高，從VoWi-Fi、Cellular Convergence到各種多媒體技術的應用，無線網路在未來極可能成為各種傳輸服務重要媒介，也因此從802.11、802.15、802.16到802.20，各種長中短距離的無線網路技術應運而生，相信隨著無線技術不斷演進，不久的未來我們都將身處於資訊傳遞更為即時與便捷的世界，可惜的是國內的WLAN(Wi-Fi)產業，雖然佔據全球超過90%出貨量，然而在高階產品與標準訂定的領域，卻遲遲未能與國際大廠相抗衡，仍舊必須面對低價與大量製造的競爭模式，長期而言對國內產業影響甚鉅，期許不久的未來相關業者都能有所自覺，共同為台灣的無線網路技術貢獻心力。

五， 參考資料

1，IEEE P802.16-REVd/D5 May 2004

2，802.16e/D4 August 2004

3，RFC 2548 – Microsoft Vendor-specific RADIUS Attributes，http://www.scit.wlv.ac.uk/rfc/rfc25xx/RFC2548.html
4，RFC 3079 – Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)，http://www.faqs.org/rfcs/rfc3079.html
5，RFC 3078 – Microsoft Point-To-Point Encryption (MPPE) Protocol，http://www.faqs.org/rfcs/rfc3078.html

6，無線網路WPA安全機制剖析，http://www.lee-1.com/hlchou/WLANWPA.htm

7，WiMAX Forum,http://www.wimaxforum.org