電子論文-基于短消息的OTA數(shù)據(jù)傳輸安全機制.doc

解決方案基于短消息的OTA數(shù)據(jù)傳輸安全機制鄭 琦（西南交通大學信息科學與技術(shù)學院，成都610031）摘要：OTA技術(shù)的應(yīng)用，使得移動通信不僅能夠提供語音和數(shù)據(jù)服務(wù)，還能提供更便捷的增值服務(wù)。依靠基于短消息的OTA技術(shù)，應(yīng)用及內(nèi)容服務(wù)商就可以很方便地不斷開發(fā)出更具個性化、更貼近用戶需求的服務(wù) 。然而，基于短消息的OTA技術(shù)的實現(xiàn)，依賴于OTA平臺和用戶卡之間大量的數(shù)據(jù)交互，所以對數(shù)據(jù)傳輸安全有特定要求。針對這個問題，本文結(jié)合中國聯(lián)通OTA規(guī)范，對基于短消息的OTA數(shù)據(jù)傳輸安全問題，及其最重要的有效性和可靠性等特性的實現(xiàn)進行了分析。關(guān)鍵字：OTA 序列號 MAC值一、OTA技術(shù)及OTA數(shù)據(jù)傳輸安全概論OTA（over the air）空中下載技術(shù)是一項基于無線數(shù)據(jù)傳輸機制的技術(shù)。這項技術(shù)通過用戶手機卡和OTA服務(wù)器之間的無線數(shù)據(jù)交互，實現(xiàn)了用戶手機卡(OTA卡)內(nèi)增值業(yè)務(wù)菜單的動態(tài)下載、刪除與更新，方便了用戶獲取個性化的增值服務(wù)，如信息點播、互動娛樂、位置服務(wù)以及銀行交易等。OTA的無線數(shù)據(jù)傳輸可以采用短消息、WAP、GPRS、CDMA1X等技術(shù)。因用戶習慣于通過短消息來接收數(shù)據(jù)業(yè)務(wù)，基于短消息的無線傳輸方式成為了OTA技術(shù)中最為流行的方式。這種方式，也是目前2G中最為實用、投資最少的一種方式，它滿足了用戶對業(yè)務(wù)簡單性、易用性、可下載性三方面的要求，成為了OTA技術(shù)強大的推動器。通過基于短消息的OTA空中下載技術(shù)，手機用戶只要進行簡單操作，即上發(fā)短信請求，就可以按照個人喜好把各種增值業(yè)務(wù)菜單下載到手機卡中，進而根據(jù)自己的意愿訂制菜單中的各種增值業(yè)務(wù)。OTA技術(shù)的實現(xiàn)依賴于無線數(shù)據(jù)傳輸，而數(shù)據(jù)傳輸在空中接口可能會遭受信道監(jiān)聽、信息篡改等攻擊，造成信息的泄露和丟失，因此OTA數(shù)據(jù)傳輸安全性的問題尤為重要。OTA數(shù)據(jù)傳輸安全性主要包括：數(shù)據(jù)的保密性、完整性、有效性、可靠性、不可抵賴性、可控制性和可審查性。 中國聯(lián)通OTA 規(guī)范結(jié)合GSM03.48 以及用戶手機卡的定義規(guī)則，形成了一套完整的OTA數(shù)據(jù)傳輸安全機制。其中，通過序列號比對（同步控制）和MAC值校驗的方式實現(xiàn)了數(shù)據(jù)傳輸安全中最重要的兩個特性有效性和可靠性。要實現(xiàn)基于短消息的OTA數(shù)據(jù)傳輸，實現(xiàn)OTA下載服務(wù)器與用戶卡之間的數(shù)據(jù)交互，數(shù)據(jù)必須按照特定的格式組合，即參照三種報文格式：OTA業(yè)務(wù)上行報文、下行報文和遠程文件更新下行報文格式。三種報文格式中都包含各種安全應(yīng)用數(shù)據(jù)項，用于記錄實現(xiàn)數(shù)據(jù)安全傳輸?shù)臄?shù)據(jù)值，安全應(yīng)用數(shù)據(jù)項包括序列號，MAC值和隨機數(shù)等。三種報文格式分別如表1、表2和表3所示。表1 上行報文標識長度（字節(jié)）值說明安全應(yīng)用數(shù)據(jù)卡商代碼1HEX用戶品牌標識2HEX卡片ICCID8HEX“00”+ICCID的后14個字符序列號5HEX隨機數(shù)4HEXMAC4HEX命令數(shù)據(jù)命令類型1HEX命令長度1HEX本條短信中命令參數(shù)的長度。命令參數(shù)XHEX表2 下行報文標識長度（字節(jié)）值說明安全應(yīng)用數(shù)據(jù)UDHL10x02信息標識長度IEIa10x70安全頭標識IEIDLa10x00信息長度CPL2后續(xù)數(shù)據(jù)長度,從CHL到最后CHL10x11安全報文頭長度，從SPI到CCSPI20x02只使用第一字節(jié)bit1,bit2。0x00KIc10x00不使用加密。KID10xX1DES CBC，高4位為密鑰編號TAR30xB0 00 10OTA業(yè)務(wù)下載CNTR5參見計數(shù)器的管理PCNTR10x00參見GSM03.48 。CC4使用MAC，參見MAC算法。隨機數(shù)4HEX密鑰分散及密鑰選擇用，不能加密序列號類型標識1HEX命令數(shù)據(jù)命令類型1HEX命令長度1HEX本條短信中命令參數(shù)的長度。命令參數(shù)XHEX表3 遠程文件更新下行報文標識長度（字節(jié)）值說明安全應(yīng)用數(shù)據(jù)UDHL10X07信息標識長度IEIa10X00級聯(lián)標識IEIDLa10x03級聯(lián)信息長度IEDa30xXX XX 01 批次、短信總數(shù)、短信索引IEIb10x70安全頭標識IEIDLb10x00信息長度CPL2后續(xù)數(shù)據(jù)長度,從CHL到最后CHL10x11安全報文頭長度，從SPI到CCSPI20x06只使用第一字節(jié)bit1, bit2, bit3。0x00KIc10xX53DES CBCKID10xX1DES CBC，高4位為密鑰編號TAR30xB0 00 1F遠程文件管理RFMCNTR5參見前向序列號的管理PCNTR10xXX參見GSM03.48 。CC4使用MAC，參見MAC算法。隨機數(shù)4HEX密鑰分散及密鑰選擇用,不能加密二、OTA數(shù)據(jù)傳輸有效性的實現(xiàn)序列號比對實現(xiàn)數(shù)據(jù)傳輸有效性大量的用戶不斷上發(fā)短信請求，OTA下載服務(wù)器就要不斷對這些請求做出下行響應(yīng)。由于OTA服務(wù)器性能的限制，響應(yīng)不免會出現(xiàn)時延，以至于用戶暫時接收不到響應(yīng)而重復發(fā)起同種上行請求。為了防止OTA服務(wù)器重復響應(yīng)相同的上行請求，在響應(yīng)前，會比對上行報文與本地OTA服務(wù)器的序列號值。同理，為防止OTA服務(wù)器發(fā)生故障或者人工誤操作對用戶卡端的大量重復響應(yīng)，卡端也會比對下行報文中的序列號與卡端的序列號值，具體實現(xiàn)方法如下。序列號分為前向序列號和反向序列號，用戶卡端和OTA服務(wù)器端共同維護這兩種序列號。反向序列號對應(yīng)于此次操作源于用戶卡端發(fā)起的請求，包括所有上行短信及服務(wù)器端對該上行短信的響應(yīng)。前向序列號對應(yīng)于此次操作由服務(wù)器端發(fā)起的請求。（1）反向序列號用戶卡端產(chǎn)生上行數(shù)據(jù)時，應(yīng)以當前用戶卡端的反向序列號值填充上行報文中的序列號數(shù)據(jù)項；在收到下行報文時（該下行數(shù)據(jù)是該上行數(shù)據(jù)的響應(yīng)），若下行報文中的序列號值與當前卡端反向序列號的值相等或比當前卡端反向序列號值大1，則此次數(shù)據(jù)合法。在完成該次OTA下載過程后將卡端反向序列號的值加1。OTA下載服務(wù)器收到上行報文時（若該上行數(shù)據(jù)需要響應(yīng)），當上行報文中序列號值與當前服務(wù)器反向序列號值相等，則將下行數(shù)據(jù)發(fā)送給用戶卡，在發(fā)送完該次應(yīng)用下載的全部下行數(shù)據(jù)后，OTA下載服務(wù)器應(yīng)將當前反向序列號值加1。若上行報文中序列號值比服務(wù)器當前反向序列號的值小1 ，應(yīng)以當前服務(wù)器反向序列號的值填入下行數(shù)據(jù)中的序列號數(shù)據(jù)項，并將下行數(shù)據(jù)發(fā)送給用戶卡端，在發(fā)送完該次應(yīng)用下載的全部下行數(shù)據(jù)后，OTA 下載服務(wù)器應(yīng)保持當前本地反向序列號的值不變。反向序列號比對流程如圖1所示。用戶卡端：產(chǎn)生上行數(shù)據(jù)反向序列號：A1OTA服務(wù)器反向序列號：B1A1=B1數(shù)據(jù)不合法OTA服務(wù)器：產(chǎn)生下行報文反向序列號：B1=A1OTA服務(wù)器：產(chǎn)生下行報文反向序列號：B1=A1+1A1+1=B1用戶卡端：收到下行報文反向序列號：A1數(shù)據(jù)不合法A1=B1完成數(shù)據(jù)交互：用戶卡端和OTA服務(wù)器反向序列號加1完成數(shù)據(jù)交互：用戶卡端反向序列號加1A1=B1-1圖1 反向序列號比對流程圖（2）前向序列號服務(wù)器主動下發(fā)數(shù)據(jù)時，當下行報文中前向序列號值大于用戶卡中前向序列號的值，該下行數(shù)據(jù)才可以被卡接受，用戶卡端在收到該次應(yīng)用下載的全部下行數(shù)據(jù)后，用下行報文中序列號的值更新卡端前向序列號的值。完成此次下行過程，將服務(wù)器端前向序列號的值加1。前向序列號比對流程如圖2所示。OTA服務(wù)器端：產(chǎn)生下行數(shù)據(jù)前向序列號：A1用戶卡端前向序列號：B1數(shù)據(jù)不合法完成數(shù)據(jù)交互：用戶卡端前向序列號等于A1，OTA服務(wù)器前向序列號加1A1B1圖2 前向序列號比對流程圖三、OTA數(shù)據(jù)傳輸可靠性的實現(xiàn)MAC值比對實現(xiàn)OTA數(shù)據(jù)傳輸?shù)目煽啃曰诙滔⒌腛TA數(shù)據(jù)傳輸，通過MAC值的比對，可以避免數(shù)據(jù)在傳輸途中遭到惡意的修改，保證上行到OTA下載服務(wù)器的數(shù)據(jù)和下行到用戶卡的數(shù)據(jù)可靠性。OTA下載服務(wù)器收到上行數(shù)據(jù)后，計算該上行數(shù)據(jù)的MAC值，并與上行報文中所存放的MAC值進行比較。若兩者相同，則數(shù)據(jù)在傳送過程中未被修改、刪除或者重組，該上行數(shù)據(jù)合法；否則，丟棄該上行數(shù)據(jù)。同理，用戶卡端收到下行數(shù)據(jù)后，計算該下行數(shù)據(jù)的MAC值，并與下行報文中所存放的MAC值進行比較。若兩者相同，則數(shù)據(jù)在傳送過程中未被修改、刪除或者重組，該下行數(shù)據(jù)合法；否則，丟棄該下行數(shù)據(jù)。特別的，當下行數(shù)據(jù)類型是遠程文件更新時，要將指定的安全數(shù)據(jù)項SPI設(shè)置為1。并且在計算完MAC值后，還需要對下行數(shù)據(jù)進行加密，加密采用標準DES-CBC算法，所以，用戶卡端收到下行數(shù)據(jù)后，先要對下行數(shù)據(jù)解密，再進行MAC值比對。計算MAC值，需要先得到一組安全數(shù)據(jù)值，包括：隨機數(shù)，主密匙Km，會話密匙Kc。（1）隨機數(shù)產(chǎn)生產(chǎn)生隨機數(shù)，是為了保證此后計算MAC值的隨機性與唯一性。用戶卡和OTA下載服務(wù)器在上行和下行數(shù)據(jù)前，都會產(chǎn)生一個隨機數(shù)，放入對應(yīng)的隨機數(shù)安全數(shù)據(jù)項。產(chǎn)生的隨機數(shù)連續(xù)兩次操作絕對不能相同，否則拋棄處理。得到隨機數(shù)以后，通過對隨機數(shù)的操作，選出主密匙Km。具體操作為，選取隨機數(shù)第四字節(jié)與“0X07”進行“與”操作，再對其結(jié)果取模5的值，模5的結(jié)果（04之間）即為所要選擇的主密匙索引號。主密匙組由聯(lián)通公司提供，是一組（5個）十六字節(jié)十六進制數(shù)。具體程序如下：sms1=sms2=random(0xff); / 產(chǎn)生四字節(jié)隨機數(shù)sms3=sms4=random(0xff);keyindex=fmod(sms26 & 0x07),5);/選取Km（2）會話密匙Kc生成選擇主密鑰Km之后，采用標準的PBOC密鑰分散算法對主密鑰進行兩級分散操作。分散因子包括“00”+用戶卡ICCID后14位和隨機數(shù)。流程如圖3所示。根據(jù)隨機數(shù)選擇一支主密匙KmPBOCPBOC會話密匙Kc“00”+ICCID后14位隨機數(shù)圖3 密鑰分散算法求Kc示意圖其中，PBOC算法流程描述如下：設(shè)主密鑰為Km（16Bytes），分散因子為X（8Bytes，不足右補空格0X20），生成的分散密鑰為Kc（16Bytes）。Km的左半部分（前8Bytes）為Kml，Km的右半部分（后8Bytes）為Kmr。Kcl=3DES（Km，X），Kcr=3DES（Km，NOT X），其中3DES為3DES ECB類型。Kcl為Kc的左半部份，Kcr為Kc的右半部分。（3）MAC值計算計算MAC值采用標準的DESCBC算法，初始密鑰KEY為會話密鑰Kc的左8個字節(jié)。上行與下行數(shù)據(jù)計算MAC值時，都應(yīng)包含所有上行報文中的安全數(shù)據(jù)項。除此，上行還應(yīng)包括，卡商代碼及協(xié)議版本號、卡功能標識、ICCID等項；下行還應(yīng)包括，命令類型、命令長度、命令參數(shù)等項。具體MAC值計算方法是，將所有原始數(shù)據(jù)按照每8個字節(jié)一組進行分組，若原始數(shù)據(jù)不是8的整數(shù)倍，則需要根據(jù)實際的數(shù)據(jù)長度在命令數(shù)據(jù)末尾填充17字節(jié)的“0x20”數(shù)據(jù)。計算MAC所需填充的數(shù)據(jù)不包含在上、下行報文數(shù)據(jù)中，由用戶卡和OTA下載服務(wù)器在計算MAC碼時根據(jù)上行、下行數(shù)據(jù)長度自行填充。 以初始密匙KEY作為DES算法的密鑰，初始數(shù)據(jù)為8字節(jié)的“0X00”，對第一分組數(shù)據(jù)與初始數(shù)據(jù)異或后的數(shù)據(jù)進行運算，DES算法的輸出數(shù)據(jù)與第二分組數(shù)據(jù)異或后，繼續(xù)以KEY為密鑰進行DES運算，依次做下去直至最后一個分組處理完畢。MAC碼取最后一次DES運算的8字節(jié)輸出數(shù)據(jù)的最左邊4字節(jié)數(shù)據(jù)。初始數(shù)據(jù)Block #1Block #2Block #3Block #NXORXORXORXORDESDESDESDESKEYKEYKEYKEYMACMAC算法流程如圖4所示。圖4 MAC算法示意圖四、結(jié)束語基于短消息的OTA數(shù)據(jù)傳輸方式，用戶可以方便地利用短消息更新卡內(nèi)的增值業(yè)務(wù)菜單，彌補了以前SIM卡固化業(yè)務(wù)的缺陷。因其簡單易用，基于短消息的OTA數(shù)據(jù)傳輸方式得到了廣泛的應(yīng)用。目前，OTA業(yè)務(wù)主要用于SIM卡，隨著3G業(yè)務(wù)的發(fā)展，網(wǎng)絡(luò)條件的便利，增值業(yè)務(wù)必然會對處理速率、儲存空間等提出更高要求，也必然會對當前的OTA數(shù)據(jù)傳輸安全模式提出更高求。因此，新的安全解決方案將成為今后OTA技術(shù)的研究方向。參考文獻1 中國聯(lián)通OT