[發(fā)明專(zhuān)利]軟件握手協(xié)商硬件加解密的CAPWAP隧道DTLS加解密方法

在審

• 申請(qǐng)?zhí)枺?/td>: 201810412369.1
• 申請(qǐng)日: 2018-05-03
• 公開(kāi)（公告）號(hào): CN108616355A
• 公開(kāi)（公告）日: 2018-10-02
• 發(fā)明（設(shè)計(jì)）人: 朱濤;崔興龍
• 申請(qǐng)（專(zhuān)利權(quán)）人: 盛科網(wǎng)絡(luò)（蘇州）有限公司
• 主分類(lèi)號(hào): H04L9/08
• 分類(lèi)號(hào): H04L9/08;H04L29/06;H04L29/08
• 代理公司: 南京利豐知識(shí)產(chǎn)權(quán)代理事務(wù)所(特殊普通合伙) 32256
• 代理人: 王鋒

本發(fā)明公開(kāi)了一種軟件握手協(xié)商硬件加解密的CAPWAP隧道DTLS加解密方法，在創(chuàng)建CAPWAP隧道的過(guò)程中，由CPU進(jìn)行DTLS握手協(xié)商獲得密鑰；在創(chuàng)建控制通道和數(shù)據(jù)通道時(shí)，將所述密鑰及AP設(shè)備信息下發(fā)給ASIC芯片；在報(bào)文轉(zhuǎn)發(fā)過(guò)程中，ASIC芯片根據(jù)所述密鑰對(duì)接收到的CAPWAP報(bào)文進(jìn)行解密之后查表轉(zhuǎn)發(fā)或上送CPU處理，對(duì)于需要加密轉(zhuǎn)發(fā)的報(bào)文，ASIC芯片根據(jù)所述密鑰進(jìn)行加密后轉(zhuǎn)發(fā)。采用本發(fā)明技術(shù)方案，通過(guò)軟件握手協(xié)商方式獲取密鑰，提高了密鑰的安全性；所有報(bào)文的DTLS加解密以及查表轉(zhuǎn)發(fā)操作全部由ASIC芯片來(lái)完成，在提高了轉(zhuǎn)發(fā)效率的同時(shí)，減輕了由CPU進(jìn)行加解密和轉(zhuǎn)發(fā)報(bào)文的負(fù)擔(dān)。

技術(shù)領(lǐng)域

本發(fā)明涉及一種CAPWAP隧道DTLS加解密方法，特別涉及一種軟件握手協(xié)商硬件加解密的CAPWAP隧道DTLS加解密方法，屬于網(wǎng)絡(luò)通信領(lǐng)域。

背景技術(shù)

隨著無(wú)線網(wǎng)絡(luò)的不斷普及和發(fā)展，無(wú)線網(wǎng)絡(luò)的模型也由最初的單AP模型發(fā)展成了現(xiàn)在的AC+AP模型，通過(guò)AC來(lái)同時(shí)管理多個(gè)AP，AP管理多個(gè)無(wú)線終端。如圖1所示的WLAN組網(wǎng)模型，無(wú)線終端設(shè)備STA(STA1～STA4)例如手機(jī)、筆記本電腦、平板電腦等通過(guò)WiFi連接AP設(shè)備(AP1～AP3)；AP一方面轉(zhuǎn)發(fā)STA的數(shù)據(jù)流量，一方面接受AC的控制，包括接收AC下發(fā)的配置和上報(bào)自身的狀態(tài)等。AC主要負(fù)責(zé)控制AP，AC與AP間采用CAPWAP隧道協(xié)議進(jìn)行通訊，它會(huì)與AP間建立兩條CAPWAP隧道，一條是控制通道(UDP端口號(hào)5246)，主要用來(lái)管理AP(包括下發(fā)配置，對(duì)AP版本升級(jí)，獲取AP運(yùn)行狀態(tài)等)；一條是數(shù)據(jù)通道(UDP端口號(hào)5247)，主要用來(lái)轉(zhuǎn)發(fā)STA的數(shù)據(jù)報(bào)文，并對(duì)其進(jìn)行ACL、QoS、IPSG等相關(guān)特性的處理，為了保證AC與AP間數(shù)據(jù)傳輸?shù)陌踩裕珻APWAP協(xié)議支持對(duì)隧道報(bào)文進(jìn)行DTLS加密。

DTLS加密主要分為兩個(gè)步驟：握手協(xié)商和數(shù)據(jù)報(bào)文加解密。握手協(xié)商主要是進(jìn)行身份認(rèn)證并協(xié)商出一套密鑰，數(shù)據(jù)加解密時(shí)則在發(fā)送端將數(shù)據(jù)明文用密鑰進(jìn)行加密，接收端再根據(jù)密鑰解密出明文進(jìn)行處理。目前主流的CAPWAP DTLS加解密技術(shù)一般采用軟件進(jìn)行處理，例如開(kāi)源OpenSSL庫(kù)，DTLS所有過(guò)程都由軟件進(jìn)行處理，當(dāng)AP上線時(shí)，需要向AC建立CAPWAP隧道，在創(chuàng)建隧道之前，會(huì)先發(fā)起DTLS握手請(qǐng)求，待雙方握手協(xié)商成功并取得密鑰之后，創(chuàng)建隧道，并對(duì)后續(xù)的報(bào)文進(jìn)行DTLS加解密處理；AP或者AC需要通過(guò)隧道發(fā)送報(bào)文時(shí)，需要先在CPU上對(duì)其進(jìn)行加密，轉(zhuǎn)換成密文后再發(fā)送出去；AP或者AC接收到隧道報(bào)文時(shí)，需要先將其上送CPU，待CPU對(duì)其進(jìn)行解密后，再進(jìn)行后續(xù)處理。

DTLS軟件加解密的所有過(guò)程都在CPU上進(jìn)行，一方面當(dāng)報(bào)文數(shù)量巨大的時(shí)候，會(huì)對(duì)CPU造成巨大的負(fù)擔(dān)；另一方面，本來(lái)可以直接通過(guò)ASIC芯片轉(zhuǎn)發(fā)的報(bào)文必須先上送CPU進(jìn)行處理，也造成了隧道轉(zhuǎn)發(fā)效率的降低。

為了減輕CPU的負(fù)擔(dān)，可以采用報(bào)文預(yù)處理的方法，如圖2是AC內(nèi)部ASIC芯片與CPU芯片的報(bào)文轉(zhuǎn)發(fā)處理示意圖，這里ASIC芯片的主要作用是對(duì)AC收到的數(shù)據(jù)報(bào)文進(jìn)行預(yù)處理，例如對(duì)于需要轉(zhuǎn)發(fā)出去的報(bào)文，直接查找ASIC的硬件表項(xiàng)，然后根據(jù)查表結(jié)果直接轉(zhuǎn)發(fā)出去。這樣的好處是一方面報(bào)文無(wú)需再上送CPU，減輕了CPU的負(fù)擔(dān)；另一方面也提高了轉(zhuǎn)發(fā)報(bào)文的效率。但是對(duì)于ASIC無(wú)法處理的報(bào)文，例如不支持加解密功能的ASIC模塊收到加密報(bào)文時(shí)，還是得上送CPU進(jìn)行處理，對(duì)于這種情況，也就無(wú)法體現(xiàn)出ASIC模塊存在的優(yōu)勢(shì)了。

本案申請(qǐng)人在申請(qǐng)?zhí)枮?01511019516.1的發(fā)明專(zhuān)利申請(qǐng)中提出了一種CAPWAPDTLS報(bào)文加解密的芯片實(shí)現(xiàn)方法，以及在申請(qǐng)?zhí)枮?01611270117.7的發(fā)明專(zhuān)利申請(qǐng)中提出了一種CAPWAP控制通道DTLS加解密的芯片協(xié)處理方法，在上述兩個(gè)專(zhuān)利申請(qǐng)中，分別公開(kāi)了CAPWAP數(shù)據(jù)通道和控制通道的芯片級(jí)加解密技術(shù)，當(dāng)ASIC芯片發(fā)送報(bào)文時(shí)，直接由ASIC芯片進(jìn)行加密，當(dāng)ASIC芯片接收?qǐng)?bào)文時(shí)，同樣由ASIC芯片進(jìn)行解密。