一， 前言
隨著近年來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=0×53 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金鑰加密技術 |
|
|
0×000001 |
No data encryption |
no data authentication |
3-DES,128bits |
|
0×010001 |
DES CBC-Mode, 56bits |
no data authentication |
3-DES,128bits |
|
0×000002 |
No data encryption |
no data authentication |
RSA,1024bits |
|
0×020002 |
DES CBC-Mode, 56bits |
no data authentication |
RSA,1024bits |
|
0×020103 |
AES CCM mode, 128bits |
AES CCM mode,128bits |
AES ECB mode,128bits |
|
0×800003 |
AES CTR mode, 128bits |
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 |
|
1-5 |
為封包的前5 bytes Generic MAC Header |
|
6-9 |
預設為0 |
|
10-13 |
為每個封包不斷增加的Packet Number數字，並循序遞增，Downlink數字由0×00000001 至 0x7fffffff 而 Uplink由0×80000001 至 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數字由0×00000001 至 0x7fffffff 而 Uplink由0×80000001 至 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.16 AES-CTR加密演算法
由於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
