<strike id="tpvd9"><dfn id="tpvd9"></dfn></strike>

        <em id="tpvd9"></em>

          <address id="tpvd9"></address>
            <dfn id="tpvd9"><sub id="tpvd9"></sub></dfn>

            <thead id="tpvd9"><noframes id="tpvd9">
            <ruby id="tpvd9"></ruby>

                  <thead id="tpvd9"></thead>
                  歡迎您訪(fǎng)問(wèn)鄭州興邦電子股份有限公司官方網(wǎng)站!
                  阿里巴巴誠信通企業(yè)
                  全國咨詢(xún)熱線(xiàn):40000-63966
                  興邦電子,中國水控機第一品牌

                  聯(lián)系興邦電子

                  全國咨詢(xún)熱線(xiàn):40000-63966

                  售后:0371-55132951/55132952

                  工廠(chǎng):河南省 鄭州市 高新區蓮花街電子電器產(chǎn)業(yè)園

                  基于智能卡的短消息端到端的安全通信機制

                  文章出處:http://psychicreadingswithdeb.com 作者:賈凡 楊義先 彭俊好&nbsp;&nbsp; 人氣: 發(fā)表時(shí)間:2011年09月26日

                  [文章內容簡(jiǎn)介]:提出了一種基于SIM卡的端到端短消息加密通信的機制。該機制利用智能卡的數據加密能力與主動(dòng)式命令等特性, 巧妙地在其上實(shí)現了短消息的編輯、加密和發(fā)送, 很好地滿(mǎn)足了那些對敏感數據傳輸的安全要求; 同時(shí)對于移動(dòng)網(wǎng)絡(luò )和手機終端都沒(méi)有特別要求, 通過(guò)OTA 技術(shù)可以很方便地下載到用戶(hù)SIM 卡中, 易于在現有的移動(dòng)網(wǎng)絡(luò )中實(shí)施。

                      0 引言 

                      短消息( Short Message Service, SMS) 是GSM網(wǎng)絡(luò )所提供的一種端到端的數據通信方式; 它可以是文本、語(yǔ)音或者是圖片等信息。SMS 采用了存儲轉發(fā)機制, 即當手機用戶(hù)發(fā)送一條SMS消息時(shí), 這條消息并不是由接收者直接收到, 而是由用戶(hù)所在網(wǎng)絡(luò )的短消息中心先接收到, 然后短消息中心向接收者發(fā)送一條通知指令, 通知接收者從短消息中心下載消息。這種機制具有很好的方便性、靈活性, 使其很快成為手機用戶(hù)一個(gè)重要的交流方式。

                      盡管短消息設計初衷是作為語(yǔ)音E-mail 的提示, 但它很快成為了個(gè)人和商業(yè)人群之間非常流行的通信方式 。目前很多地方開(kāi)展了通過(guò)短信辦理銀行業(yè)務(wù)的服務(wù), 或者發(fā)送與商業(yè)相關(guān)的信息。當發(fā)送銀行賬號、密碼以及身份識別碼等這些敏感信息時(shí), 人們最擔心的就是這些信息可能會(huì )被截獲或是誤發(fā)給一些詐騙此類(lèi)信息的人?,F有的GSM短消息通信所采用的消息格式是開(kāi)放可預知的, 其源地址具有可偽造性 , 而且在整個(gè)傳輸過(guò)程中是明文的, 因此目前短信通信并非總是可信的。針對這些敏感應用, GSM用戶(hù)應該能夠選擇一種保密通信來(lái)保證這些信息不被正確讀取和偽造, 因此在手機端提供一種加密通信方法是必要的。 

                      目前對短消息加密的實(shí)現主要有兩種: ①基于終端和服務(wù)器之間的加密通信。它需要服務(wù)器配合實(shí)現, 而且在核心網(wǎng)內短信還是以明文傳輸, 仍存在被截獲的風(fēng)險。②端到端的加密通信。它需要在手機終端或卡上進(jìn)行相應的設計, 實(shí)施的代價(jià)相對較小, 而且安全強度更高。本文給出了一種基于智能卡實(shí)現加密短信通信的方案, 具有與手機終端無(wú)關(guān)的特性和更好的實(shí)用性。

                      1 短消息通信網(wǎng)絡(luò )結構 

                      GSM短消息通信是通過(guò)信令通道傳輸數據的, 根據其發(fā)送和接收短消息可以分為移動(dòng)起始( MO) 和移動(dòng)終止( MT) 兩種類(lèi)型。其發(fā)送接收的過(guò)程可以描述為: 短消息發(fā)送方將MO短消息提交給短消息服務(wù)中心( SMSC) , 它負責在基站與SME間中繼、儲存或轉發(fā)短消息; 移動(dòng)臺( MS) 到SMSC 的協(xié)議能傳輸MO 或MT的短消息, SMS 網(wǎng)關(guān)接收由SMSC 發(fā)送的短消息,向HLR 查詢(xún)路由信息, 并將短消息傳送給接收者所在基站的交換中心, 由其來(lái)完成短消息數據的交換建立。下面給出短消息通信的GSM網(wǎng)絡(luò )結構。GSM標準中定義的點(diǎn)—點(diǎn)短消息服務(wù)使得短消息能在移動(dòng)臺和短消息服務(wù)中心之間傳遞。這些服務(wù)中心是通過(guò)稱(chēng)為SMC-GMSC 的特定的移動(dòng)交換中心( MSC) 與GSM網(wǎng)絡(luò )聯(lián)系的, 如圖1 所示。

                  短消息通信體系結構

                  圖1 短消息通信體系結構

                      其中, VLR( Visitor Location Register) 是訪(fǎng)問(wèn)位置寄存器, 含有用戶(hù)臨時(shí)信息的數據庫; HLR( Home Location Register) 是歸屬位置寄存器, 用于永久儲存管理用戶(hù)和服務(wù)記錄的數據庫, 由SMSC 產(chǎn)生。 

                      短消息在GSM網(wǎng)絡(luò )上傳輸, 網(wǎng)絡(luò )本身沒(méi)有提供相應的諸如互認證、端到端安全、不可否認性以及用戶(hù)匿名等安全機制。因此目前短消息網(wǎng)絡(luò )不滿(mǎn)足安全通信的三個(gè)基本要求, 即信息的完整性、機密性和有效性。

                      2 加密算法與其在智能卡上的實(shí)現 

                      上述的通信安全問(wèn)題可以借助于信息加密技術(shù)來(lái)解決。目前信息加密多采用基于密鑰的方法, 這類(lèi)方法主要有對稱(chēng)密鑰和非對密鑰兩種體制。 

                      常見(jiàn)的對稱(chēng)密鑰算法有AES、DES、3DES 和IDEA。對稱(chēng)密鑰的特點(diǎn)是解密與加密密鑰相同。這類(lèi)算法具有加/ 解密速度快、運行時(shí)占用空間小等優(yōu)點(diǎn), 但是存在著(zhù)密鑰交換和密鑰管理復雜等缺點(diǎn)。典型的非對稱(chēng)方法是RSA, 它基于整數分解原理, 采用了模數運算的方法。非對稱(chēng)方法的信息保密程度取決于求解指定數學(xué)問(wèn)題的難度, 目前涉及有指數分解、離散對數問(wèn)題等, 算法的破解難度與相應的所解數學(xué)問(wèn)題難度成正比。與對稱(chēng)方法不同, 非對稱(chēng)方法同時(shí)采用私鑰和公鑰。公鑰可以對所有用戶(hù)公開(kāi), 發(fā)送方用公鑰加密, 接收方用私鑰解密。這種方法安全性高、密鑰管理方便, 在商業(yè)系統中有廣泛的應用前景。

                      SIM卡是在GSM用做承載用戶(hù)識別信息的智能卡。智能卡是一種計算能力相對較弱的小設備, 它通常采用DES、3DES、RSA 等加/ 解密算法來(lái)提高系統安全性能。對于DES 和3DES對稱(chēng)密鑰算法其主要是做簡(jiǎn)單的移位操作, 因此用普通智能卡就可以很好地實(shí)現。而在實(shí)現RSA 算法時(shí)要進(jìn)行對運算速度要求很高的大指數模運算, 8 位CPU難以勝任。因此,在一些高安全性加密微控制器卡芯片中( 如AT90SC1616C) ,均設置有專(zhuān)用加/ 解密運算的協(xié)處理器CAU。圖2 給出了一種帶有協(xié)處理器的智能卡芯片結構圖[ 3]。隨著(zhù)非對稱(chēng)密鑰算法研究的深入和32 位CPU卡的推出, 在沒(méi)有協(xié)處理器的智能卡上也可以很好地實(shí)現ECC 等公鑰算法[ 4] 。

                  具有協(xié)處理器的智能卡

                  圖2 具有協(xié)處理器的智能卡

                      利用智能卡上這些可實(shí)現的加密算法, 可以對智能卡的輸入/ 輸出數據進(jìn)行加密以及相應的密鑰協(xié)商。以下將對智能卡上的加密算法進(jìn)行分析, 選擇出適合端到端短信加密的算法。 

                      3 基于智能卡的短消息安全機制設計 

                      端到端的短消息安全通信機制要解決安全短消息的數據格式設計、基于智能卡的密鑰協(xié)商機制、消息加密算法的選擇以及通過(guò)智能卡對短消息編輯、加密、發(fā)送和接收的整個(gè)安全流程的設計。 

                      3. 1 安全短消息數據包設計 

                      短消息可以分為上行和下行短消息兩種。其數據格式主要包括協(xié)議數據單元參數和用戶(hù)數據兩部分。在協(xié)議數據參數部分主要定義了短消息的類(lèi)型、源地址、目的地址、協(xié)議標志、編碼方式以及用戶(hù)數據頭等信息。其中TP-PID 域可以區分該短消息是手機接收還是SIM卡接收, TP-MT 標志可以區分上、下行短消息。用戶(hù)數據部分最大可用長(cháng)度為140 Bytes。由于短消息的傳輸協(xié)議數據單元的參數有其固定格式, 要實(shí)現安全短消息, 可以利用的空間只有用戶(hù)數據的有效載荷部分。在這部分, 可以定義安全短消息的數據頭和加密信息以及可選的數字摘要。其中安全短消息數據頭定義了加密短消息的安全參數等信息, 應用程序按要求封裝并根據數據頭解讀短消息。具體數據格式如圖3 所示[ 5] 。

                  安全短消息數據格式

                  圖3 安全短消息數據格式

                      其中, IEI 為信息單元標志, 用來(lái)標志命令包頭和長(cháng)度以及是否有后續消息。在命令包頭中定義了一些安全相關(guān)的參數, 即安全參數標志( SPI) 、密鑰標志( KIC) 、數字摘要等密鑰標志( KID) 、防止重放攻擊的計數器( CNTR) 等。安全數據部分為加密的短消息。其具體的格式如下:

                      3. 2 會(huì )話(huà)密鑰協(xié)商協(xié)議 

                      3. 2. 1 系統設計的指導原則
                   

                      由于智能卡設備自身的特點(diǎn), 如計算能力低、存儲空間較小等, 在其上實(shí)現短信加密時(shí)必須要在安全強度、協(xié)議的安全性與效率之間有個(gè)折中。在選取加密算法和協(xié)議設計時(shí)需要考慮以下兩點(diǎn): 

                      ( 1) 智能卡設備的計算能力和有限的內存。公鑰算法和加密算法的慎重選擇是必要的。
                      ( 2) 短消息的有效載荷。用戶(hù)可用部分, 一般為140Bytes。因此協(xié)議設計必須盡可能高效。盡管有以上限制因素, 但是設計不能以安全為代價(jià)換取效率。安全機制必須能滿(mǎn)足以下幾個(gè)要求:
                      ( 1) 安全;
                      ( 2) 計算的復雜度低;
                      ( 3) 能夠實(shí)現密鑰兌換;
                      ( 4) 易于實(shí)現和使用。 

                  第1頁(yè)第2頁(yè)

                      3. 2. 2 密鑰協(xié)商機制的算法選擇

                      在文獻[ 4] 中, 給出了關(guān)于RSA 和ECC 等公鑰算法在8位智能卡上的加/ 解密性能分析, 如表1 所示。

                      表1 RSA 和ECC 的性能比較

                   RSA 和ECC 的性能比較

                      可以看出, 在沒(méi)有協(xié)處理卡上實(shí)現RSA 算法還是比較困難的, 但是ECC 在同等安全強度下, 在智能卡上的實(shí)現速度是很快的??梢岳脵E圓加密算法來(lái)實(shí)現安全短消息的密鑰協(xié)商機制, 但是在現有的網(wǎng)絡(luò )下要大規模使用公鑰算法來(lái)進(jìn)行密鑰協(xié)商, 必須布置移動(dòng)PKI 設施。因此這類(lèi)算法不適合用于現有的GSM安全短消息的密鑰協(xié)商機制。

                      DH算法基于雙方產(chǎn)生一個(gè)隨機數作為自身的私鑰, 將由該數生成的公鑰發(fā)送給對方; 雙方根據自身的私鑰和對方發(fā)送的公鑰就可以產(chǎn)生公共的會(huì )話(huà)密鑰。其實(shí)現具有簡(jiǎn)單性、方便性。它在智能卡上的實(shí)現難度也較RSA 算法相對容易, 而且無(wú)須在現有的GSM網(wǎng)絡(luò )中布置PKI。所以在該方案中選擇DH算法作為密鑰的協(xié)商算法。 

                      3. 2. 3 基于DH算法的密鑰協(xié)商協(xié)議及其安全性分析 

                      密鑰交換協(xié)議如圖4 所示。 

                      基于智能卡的DH 算法密鑰協(xié)商機制, 要求在卡內預存一對公開(kāi)的參數集T = { g, q} 。其中, q 是素數, g 是生成元, 滿(mǎn)足: g mod q, g2 mod q, ....., gp-1 mod q 是各不相同的整數, 并且以某種排列方式組成了1 ~p - 1 的所有整數[ 6] 。 

                      密鑰x、y 的大小取決于素數q 的選取, 待發(fā)送公鑰X、Y 也是小于q 的數。因此, q 的選取對于算法的性能有較大影響,長(cháng)度越大算法的安全強度越高, 所占用戶(hù)信息長(cháng)度也越長(cháng)。GSM用戶(hù)A 與B 之間要進(jìn)行一次安全短消息通信, 其密鑰協(xié)議過(guò)程可以描述如下: 

                      ( 1) A 判斷是否已有與B 通信的會(huì )話(huà)密鑰Ks, 是否有效。如果有且有效可以發(fā)送加密短消息; 否則進(jìn)行步驟( 2) 。
                      ( 2) A 通過(guò)普通短信發(fā)送一個(gè)隨機數給B。
                      ( 3) B 響應回送一個(gè)隨機數, 并附加此次產(chǎn)生密鑰的有效期, 同時(shí)計算出會(huì )話(huà)密鑰。
                      ( 4) A 根據收到B 的隨機數計算密鑰, 設置有效期。

                      協(xié)議安全性分析如下: 

                      ( 1) 密鑰的有效期:由于算法在協(xié)議實(shí)現中可以設置密鑰的有效期以及僅在需要密鑰時(shí)產(chǎn)生新的密鑰。這在很大程度上減小了對密鑰的分析攻擊。
                      ( 2) 中間人攻擊:DH算法最大的風(fēng)險就是容易受到中間人攻擊: 一個(gè)主動(dòng)的竊聽(tīng)者可能截取A 發(fā)給B 的消息以及B 發(fā)給A 的消息, 他用自己的消息替換這些消息, 并分別與A 和B 完成一個(gè)DH 密鑰交換, 而且還維持了一種假相———A 和B 直接進(jìn)行了通信。在協(xié)議末, A 實(shí)際上是與C 建立了一個(gè)秘密密鑰, B 與C 建立了一個(gè)秘密密鑰。當A 加密一個(gè)消息發(fā)送給B 時(shí), C 能解密它而B(niǎo) 不能; 類(lèi)似地, 當B 加密一個(gè)消息發(fā)送給A 時(shí), C 能解密它而A 不能。如果A 和B 事前真的沒(méi)有聯(lián)系, 并因此沒(méi)用別的方法相互驗證對方的身份, 則很難防止各種假冒攻擊。這種情況在安全短消息中有所緩解。因為在短消息通信的機制中, 在空口部分要做到消息源地址的假冒是非常難的。消息本身具有一定的認證和簽名能力, 短消息的DH 密鑰交換進(jìn)行中間人攻擊是困難的。

                      3. 3 短消息內容的加密 

                      采用AES 算法作為短消息內容加密算法, 在同樣的密鑰長(cháng)度下它具有較DES、3DES 算法更高的安全強度, 而且在現有的各種硬件平臺( 32 位的x86、Alpha、PowerPC、8 位的Smart-Card、ASIC 等) 都有優(yōu)秀的性能。它在具有協(xié)處理器的智能卡上實(shí)現加/ 解密速度也非???。在9000 門(mén)的協(xié)處理、1 000 Hz的條件下, 其一次加密速度為32 ms, 解密速度為36 ms[ 6] 。因此, 筆者推薦使用AES算法實(shí)現短信內容加密。

                      3. 4 安全短消息操作流程( 圖5) 

                      對于基于智能卡加密短消息的發(fā)送與接收要解決兩個(gè)問(wèn)題: 

                      ( 1) 手機編寫(xiě)的短信如何提交給SIM卡, SIM將短信內容加密后提交給手機發(fā)送。
                      ( 2) 手機收到短消息后, 如何判斷是否是由SIM卡加密過(guò)的并交由SIM卡解密。

                  DH密鑰協(xié)商協(xié)議

                  圖4 DH密鑰協(xié)商協(xié)議

                  基于SIM卡的短消息處理流程

                  圖5 基于SIM卡的短消息處理流程

                      圖5 中細箭頭表示明文短消息, 粗箭頭表示加密后的短消息。為了解決上述問(wèn)題, 需要設計基于SIM卡短消息的加密處理流程機制: 利用STK卡生成一個(gè)加密短消息菜單, 當用戶(hù)選中此菜單編寫(xiě)短消息時(shí), SIM卡利用主動(dòng)式命令接收鍵盤(pán)編輯的文字信息, 然后可利用SIM卡的主動(dòng)式命令Send Message來(lái)發(fā)送加密后的短信。當接收端手機接收到此信息時(shí), 會(huì )從消息的TPDU中的PID位判斷出是交由SIM卡處理的消息還是手機終端處理的消息。若是SIM卡加密消息, 則自動(dòng)轉由SIM中相應應用程序來(lái)解析、提取短信內容, 然后利用主動(dòng)式命令在手機終端顯示。消息處理流程如圖5 所示。整個(gè)短消息安全通信機制是在SIM卡上實(shí)現的, 只要該SIM支持OTA 功能, 就可以將該業(yè)務(wù)從服務(wù)器上下載。因此,很易于在現有的GSM網(wǎng)絡(luò )布置實(shí)施。

                      4 結束語(yǔ) 

                      基于SIM卡的短消息加密通信方案, 采用了DH密鑰協(xié)商機制, 可以很好地解決現有GSM明文短消息傳輸所帶來(lái)的安全風(fēng)險; 同時(shí)還無(wú)須在網(wǎng)絡(luò )側布置PKI 設施, 而且對用戶(hù)所使用的手機沒(méi)有特殊要求, 可以通過(guò)OTA 技術(shù)在現有的STK 卡上實(shí)施。因此, 具有簡(jiǎn)單、易用、安全等特點(diǎn)。

                      作者簡(jiǎn)介:
                      賈凡( 1976- ) , 男, 博士研究生, 主要研究方向為移動(dòng)通信安全、電信智能卡安全及P2P 網(wǎng)絡(luò )、信任管理( fan. jia@ 126. com) ; 
                      楊義先( 1961 - ) , 長(cháng)江學(xué)者, 教授, 主要研究方向為現代密碼學(xué)、計算機網(wǎng)絡(luò )安全、信息處理; 
                      彭俊好( 1973- ) , 男, 博士研究生, 主要研究方向為信任模型、網(wǎng)絡(luò )安全、現代密碼學(xué).

                  第1頁(yè)第2頁(yè)

                  本文關(guān)鍵詞:短消息,通信機制,sim卡,sms,智能,消息,通信機制,sim卡,sms,智能卡
                  回到頂部
                  99久热只有精品视频在线17_精品一区二区三区自拍图片_最新国产v亚洲_久久综合九色综合久
                  <strike id="tpvd9"><dfn id="tpvd9"></dfn></strike>

                        <em id="tpvd9"></em>

                          <address id="tpvd9"></address>
                            <dfn id="tpvd9"><sub id="tpvd9"></sub></dfn>

                            <thead id="tpvd9"><noframes id="tpvd9">
                            <ruby id="tpvd9"></ruby>

                                  <thead id="tpvd9"></thead>