基于capwap使用共享密鑰的方法及裝置的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明涉及CAPWAP協(xié)議，尤其是涉及一種基于CAPWAP使用共享密鑰的方法及裝置。
【背景技術(shù)】
[0002]傳統(tǒng)的WLAN (Wireless Local Area Networks，無線局域網(wǎng)絡(luò))網(wǎng)絡(luò)都是為企業(yè)或家庭內(nèi)少量移動(dòng)用戶的接入而組建的。因此，通常只需要一個(gè)無線路由器就可以解決問題了。但是當(dāng)無線接入的規(guī)模和密度達(dá)到一定程度之后，傳統(tǒng)的無線路由器在部署和管理上都會(huì)出現(xiàn)問題。
[0003]瘦AP(接入點(diǎn))+AC(接入控制器)是在胖AP之后的另一種架構(gòu)，其中AC負(fù)責(zé)無線網(wǎng)絡(luò)的接入控制，轉(zhuǎn)發(fā)和統(tǒng)計(jì)、AP的配置監(jiān)控、漫游管理、AP的網(wǎng)管代理、安全控制，在該架構(gòu)中瘦AP能單獨(dú)工作，必須和AC配合使用，那么兩者之間就需要有一種協(xié)議可以讓它們能夠進(jìn)行互聯(lián)和溝通。于是，IETF為了解決隧道協(xié)議不兼容問題造成的A廠家的AP和B廠家的AC無法進(jìn)行互通，在2005年成立了 CAPWAP工作組以標(biāo)準(zhǔn)化AP和AC間的隧道協(xié)議(rfc5415、rfc5416)。
[0004]根據(jù)rfc5415描述，為了防止AP和AC之間的數(shù)據(jù)被竊聽，采用DTLS (數(shù)據(jù)包傳輸層安全協(xié)議)對其數(shù)據(jù)包進(jìn)行加解密處理，用來保障網(wǎng)絡(luò)安全通信。rfc5415同時(shí)規(guī)定了 DTLS用于加密CAPWAP報(bào)文時(shí)必須支持的加解密算法TLS_RSA_WITH_AES_128_CBC_SHA，該算法的意義為:DTLS協(xié)議握手階段采用RSA非對稱加解密算法，數(shù)據(jù)傳輸階段采用CBC模式的AES 128加解密算法，同時(shí)采用SHA校驗(yàn)算法保證數(shù)據(jù)的完整性。AES 128算法的密鑰長度為128bits，SHA算法的密鑰長度為160bits。芯片級(jí)支持DTLS加解密模塊，需要每個(gè)AP-AC隧道單方向的數(shù)據(jù)保存128+160 = 288bits的密鑰數(shù)據(jù)，雙向通信則需要保存576bits的密鑰數(shù)據(jù)。一個(gè)AC支持N個(gè)AP，那么消耗的密鑰數(shù)據(jù)存儲(chǔ)也需要N倍，這對芯片內(nèi)部的面積、功耗、成本都是不小的代價(jià)。
[0005]在現(xiàn)有的一個(gè)技術(shù)方案中，DTLS加解密需要用到的密鑰是在DTLS會(huì)話的握手階段，由AP和AC共同協(xié)商得出，在該方案中AC芯片必須為每一個(gè)AP維護(hù)一組加解密的密鑰，有幾個(gè)AP就要維護(hù)幾組密鑰。當(dāng)AP數(shù)量龐大時(shí)，就會(huì)消耗大量的存儲(chǔ)區(qū)域去保存密鑰，從而增大芯片的面積、成本。在現(xiàn)有另一個(gè)技術(shù)方案中，AP和AC之間DTLS加解密的密鑰不通過DTLS握手階段證書的形式來動(dòng)態(tài)協(xié)商，而是通過用戶手動(dòng)將密鑰配置進(jìn)AP和AC，這種就是pre-shared密鑰，AP和AC之間的數(shù)據(jù)，就通過用戶靜態(tài)配置的密鑰進(jìn)行加解密操作。通過pre-shared密鑰，用戶也可以使得多個(gè)AP共享同一個(gè)密鑰。從網(wǎng)絡(luò)安全的角度，為了防止數(shù)據(jù)被竊聽，CAPffAP協(xié)議需要DTLS間歇性地更換密鑰，但是pre-shared密鑰是用戶靜態(tài)配置，除非用戶手動(dòng)更新，否則這個(gè)密鑰不會(huì)變化，安全性降低了。

【發(fā)明內(nèi)容】

[0006]本發(fā)明的目的在于克服現(xiàn)有技術(shù)的缺陷，提供一種基于CAPWAP使用共享密鑰的方法及裝置，以實(shí)現(xiàn)不同的AP和同一個(gè)AC進(jìn)行CAPWAP通信時(shí)，能夠使用共享的DTLS加解密密鑰對CAPWAP數(shù)據(jù)進(jìn)行加解密。
[0007]為實(shí)現(xiàn)上述目的，本發(fā)明提出如下技術(shù)方案:一種基于CAPWAP使用共享密鑰的方法，該方法應(yīng)用于多個(gè)AP和一個(gè)AC進(jìn)行CAPWAP通信的過程中，所述方法包括:
[0008]AC和AP各自通過AC端隨機(jī)數(shù)、AP端隨機(jī)數(shù)和預(yù)主密鑰這三個(gè)數(shù)據(jù)，計(jì)算出主密鑰，從而得到DTLS加解密密鑰；
[0009]AC端芯片存儲(chǔ)每個(gè)AP的DTLS加解密密鑰時(shí)，將當(dāng)前保存的密鑰與AC端芯片的存儲(chǔ)區(qū)域中已保存的所有密鑰比較，若有相同的，則給當(dāng)前AP分配一個(gè)與其密鑰相同的AP的索引值。
[0010]優(yōu)選地，在DTLS握手協(xié)商之前，給AC端分配一個(gè)AC資源池，給AP端分配一個(gè)AP資源池和預(yù)主密鑰資源池。
[0011 ] 優(yōu)選地，在DTLS握手協(xié)商過程中，AC端在所述AC資源池隨機(jī)選擇一個(gè)AC端隨機(jī)數(shù)發(fā)送給AP端，AP端在所述AP資源池隨機(jī)選擇一個(gè)AP端隨機(jī)數(shù)發(fā)送給AC端，AP端在所述預(yù)主密鑰資源池選擇一個(gè)預(yù)主密鑰發(fā)送給AC端。
[0012]優(yōu)選地，所述AC端芯片中存儲(chǔ)的AP的加解密密鑰和其對應(yīng)的索引值之間的映射關(guān)系是根據(jù)AP當(dāng)前正在使用的加解密密鑰動(dòng)態(tài)更新的。
[0013]優(yōu)選地，所述AC端隨機(jī)數(shù)和AP端隨機(jī)數(shù)的長度為32字節(jié)，所述預(yù)主密鑰的長度為48字節(jié)。
[0014]本發(fā)明還提出了一種基于CAPWAP使用共享密鑰的裝置，包括多個(gè)AP和一個(gè)AC，每個(gè)所述AP均包括AP主密鑰計(jì)算單元，所述AC包括AC主密鑰計(jì)算單元、密鑰比較單元和密鑰分配單元，所述AP主密鑰計(jì)算單元和AC主密鑰計(jì)算單元各自通過AC端隨機(jī)數(shù)、AP端隨機(jī)數(shù)和預(yù)主密鑰這三個(gè)數(shù)據(jù)，計(jì)算出主密鑰，從而得到各自的DTLS加解密密鑰；所述密鑰比較單元用于在AC端芯片存儲(chǔ)每個(gè)AP的DTLS加解密密鑰時(shí)，將當(dāng)前保存的密鑰與AC端芯片的存儲(chǔ)區(qū)域中已保存的所有密鑰比較，若有相同的，則所述密鑰分配單元給當(dāng)前AP分配一個(gè)與其密鑰相同的AP的索引值。
[0015]優(yōu)選地，在DTLS握手協(xié)商之前，AC端分配有一個(gè)AC資源池，AP端分配有一個(gè)AP資源池和預(yù)主密鑰資源池。
[0016]優(yōu)選地，所述AC端還包括AC端隨機(jī)數(shù)選擇單元，所述AP端還包括AP端隨機(jī)數(shù)選擇單元和預(yù)主密鑰選擇單元，在DTLS握手協(xié)商過程中，所述AC端隨機(jī)數(shù)選擇單元用于在所述AC資源池隨機(jī)選擇一個(gè)AC端隨機(jī)數(shù)發(fā)送給AP端，所述AP端隨機(jī)數(shù)選擇單元用于在所述AP資源池隨機(jī)選擇一個(gè)AP端隨機(jī)數(shù)發(fā)送給AC端，所述預(yù)主密鑰選擇單元用于在所述預(yù)主密鑰資源池選擇一個(gè)預(yù)主密鑰發(fā)送給AC端。
[0017]本發(fā)明結(jié)合了現(xiàn)有DTLS密鑰通過證書動(dòng)態(tài)生成和靜態(tài)pre-shared(預(yù)共享)配置兩種方式的優(yōu)點(diǎn)，通過預(yù)先給AC和AP分配隨機(jī)數(shù)資源池，使得AC和AP在各自的資源池里面挑選隨機(jī)數(shù)。通過資源池可以保證多個(gè)AP-AC隧道挑選相同的隨機(jī)數(shù)資源，從而計(jì)算得到相同的密鑰?；谶@種方式，多個(gè)AP可以共享同一個(gè)密鑰，相比證書動(dòng)態(tài)生成方式節(jié)省了芯片寶貴的存儲(chǔ)空間，提高存儲(chǔ)空間利用率，降低了芯片成本，相比靜態(tài)pre-shared配置則提高了網(wǎng)絡(luò)安全性。
[0018]因此，與現(xiàn)有技術(shù)相比，本發(fā)明的有益效果是:本發(fā)明使得不同的AP和同一個(gè)AC進(jìn)行CAPWAP通信時(shí)，能夠使用共享的DTLS加解密密鑰對CAPWAP數(shù)據(jù)進(jìn)行加解密，從而在需要嚴(yán)格控制芯片存儲(chǔ)區(qū)域面積和成本的前提下，仍然能通過DTLS保障AP和AC間的安全通信。
【附圖說明】
[0019]圖1是現(xiàn)有DTLS握手協(xié)商流程的原理不意圖；
[0020]圖2是本發(fā)明基于CAPWAP使用共享密鑰的方法的流程示意圖；
[0021]圖3是本發(fā)明實(shí)施例AC端芯片中存儲(chǔ)的AP的加解密密鑰和索引值之間的映射關(guān)系示意圖。
【具體實(shí)施方式】
[0022]下面將結(jié)合本發(fā)明的附圖，對本發(fā)明實(shí)施例的技術(shù)方案進(jìn)行清楚、完整的描述。
[0023]如圖1所示，在現(xiàn)有DTLS密鑰通過證書動(dòng)態(tài)生成的技術(shù)中，DTLS加解密需要用到的密鑰是在DTLS會(huì)話的握手階段，由AP和AC共同協(xié)商得出，即AP和AC密鑰的協(xié)商由步驟SlOl?S113決定。
[0024]具體地，步驟S102和S104中包含AC端生成的一個(gè)32字節(jié)隨機(jī)數(shù)，步驟SlOl和S103中包含AP端生成的一個(gè)32字節(jié)隨機(jī)數(shù)，步驟S105是AC端向AP端發(fā)的數(shù)字證書，一方面用于AP鑒別AC的身份，一方面包含AC的公鑰；AP在步驟S108時(shí)，先在本地隨機(jī)生成一個(gè)48字節(jié)的預(yù)主密鑰，然后用步驟S105得到的公鑰進(jìn)行RSA加密，發(fā)給AC，然后AC通過自己的私鑰將預(yù)主密鑰解密。此時(shí)，AC和AP都記錄了三個(gè)數(shù):AC端隨機(jī)數(shù)、AP端隨機(jī)數(shù)、預(yù)主密鑰。最終的DTLS加解密密鑰則通過這三個(gè)數(shù)計(jì)算得到。AC和AP各自計(jì)算，各自保存在本地。最后步驟Slll和步驟S113是雙方接收用生成的密鑰加密的密