基于capwap使用共享密钥的方法及装置的制造方法
【技术领域】
[0001]本发明涉及CAPWAP协议，尤其是涉及一种基于CAPWAP使用共享密钥的方法及装置。
【背景技术】
[0002]传统的WLAN (Wireless Local Area Networks，无线局域网络)网络都是为企业或家庭内少量移动用户的接入而组建的。因此，通常只需要一个无线路由器就可以解决问题了。但是当无线接入的规模和密度达到一定程度之后，传统的无线路由器在部署和管理上都会出现问题。
[0003]瘦AP(接入点)+AC(接入控制器)是在胖AP之后的另一种架构，其中AC负责无线网络的接入控制，转发和统计、AP的配置监控、漫游管理、AP的网管代理、安全控制，在该架构中瘦AP能单独工作，必须和AC配合使用，那么两者之间就需要有一种协议可以让它们能够进行互联和沟通。于是，IETF为了解决隧道协议不兼容问题造成的A厂家的AP和B厂家的AC无法进行互通，在2005年成立了 CAPWAP工作组以标准化AP和AC间的隧道协议(rfc5415、rfc5416)。
[0004]根据rfc5415描述，为了防止AP和AC之间的数据被窃听，采用DTLS (数据包传输层安全协议)对其数据包进行加解密处理，用来保障网络安全通信。rfc5415同时规定了 DTLS用于加密CAPWAP报文时必须支持的加解密算法TLS_RSA_WITH_AES_128_CBC_SHA，该算法的意义为:DTLS协议握手阶段采用RSA非对称加解密算法，数据传输阶段采用CBC模式的AES 128加解密算法，同时采用SHA校验算法保证数据的完整性。AES 128算法的密钥长度为128bits，SHA算法的密钥长度为160bits。芯片级支持DTLS加解密模块，需要每个AP-AC隧道单方向的数据保存128+160 = 288bits的密钥数据，双向通信则需要保存576bits的密钥数据。一个AC支持N个AP，那么消耗的密钥数据存储也需要N倍，这对芯片内部的面积、功耗、成本都是不小的代价。
[0005]在现有的一个技术方案中，DTLS加解密需要用到的密钥是在DTLS会话的握手阶段，由AP和AC共同协商得出，在该方案中AC芯片必须为每一个AP维护一组加解密的密钥，有几个AP就要维护几组密钥。当AP数量庞大时，就会消耗大量的存储区域去保存密钥，从而增大芯片的面积、成本。在现有另一个技术方案中，AP和AC之间DTLS加解密的密钥不通过DTLS握手阶段证书的形式来动态协商，而是通过用户手动将密钥配置进AP和AC，这种就是pre-shared密钥，AP和AC之间的数据，就通过用户静态配置的密钥进行加解密操作。通过pre-shared密钥，用户也可以使得多个AP共享同一个密钥。从网络安全的角度，为了防止数据被窃听，CAPffAP协议需要DTLS间歇性地更换密钥，但是pre-shared密钥是用户静态配置，除非用户手动更新，否则这个密钥不会变化，安全性降低了。
【发明内容】
[0006]本发明的目的在于克服现有技术的缺陷，提供一种基于CAPWAP使用共享密钥的方法及装置，以实现不同的AP和同一个AC进行CAPWAP通信时，能够使用共享的DTLS加解密密钥对CAPWAP数据进行加解密。
[0007]为实现上述目的，本发明提出如下技术方案:一种基于CAPWAP使用共享密钥的方法，该方法应用于多个AP和一个AC进行CAPWAP通信的过程中，所述方法包括:
[0008]AC和AP各自通过AC端随机数、AP端随机数和预主密钥这三个数据，计算出主密钥，从而得到DTLS加解密密钥；
[0009]AC端芯片存储每个AP的DTLS加解密密钥时，将当前保存的密钥与AC端芯片的存储区域中已保存的所有密钥比较，若有相同的，则给当前AP分配一个与其密钥相同的AP的索引值。
[0010]优选地，在DTLS握手协商之前，给AC端分配一个AC资源池，给AP端分配一个AP资源池和预主密钥资源池。
[0011 ] 优选地，在DTLS握手协商过程中，AC端在所述AC资源池随机选择一个AC端随机数发送给AP端，AP端在所述AP资源池随机选择一个AP端随机数发送给AC端，AP端在所述预主密钥资源池选择一个预主密钥发送给AC端。
[0012]优选地，所述AC端芯片中存储的AP的加解密密钥和其对应的索引值之间的映射关系是根据AP当前正在使用的加解密密钥动态更新的。
[0013]优选地，所述AC端随机数和AP端随机数的长度为32字节，所述预主密钥的长度为48字节。
[0014]本发明还提出了一种基于CAPWAP使用共享密钥的装置，包括多个AP和一个AC，每个所述AP均包括AP主密钥计算单元，所述AC包括AC主密钥计算单元、密钥比较单元和密钥分配单元，所述AP主密钥计算单元和AC主密钥计算单元各自通过AC端随机数、AP端随机数和预主密钥这三个数据，计算出主密钥，从而得到各自的DTLS加解密密钥；所述密钥比较单元用于在AC端芯片存储每个AP的DTLS加解密密钥时，将当前保存的密钥与AC端芯片的存储区域中已保存的所有密钥比较，若有相同的，则所述密钥分配单元给当前AP分配一个与其密钥相同的AP的索引值。
[0015]优选地，在DTLS握手协商之前，AC端分配有一个AC资源池，AP端分配有一个AP资源池和预主密钥资源池。
[0016]优选地，所述AC端还包括AC端随机数选择单元，所述AP端还包括AP端随机数选择单元和预主密钥选择单元，在DTLS握手协商过程中，所述AC端随机数选择单元用于在所述AC资源池随机选择一个AC端随机数发送给AP端，所述AP端随机数选择单元用于在所述AP资源池随机选择一个AP端随机数发送给AC端，所述预主密钥选择单元用于在所述预主密钥资源池选择一个预主密钥发送给AC端。
[0017]本发明结合了现有DTLS密钥通过证书动态生成和静态pre-shared(预共享)配置两种方式的优点，通过预先给AC和AP分配随机数资源池，使得AC和AP在各自的资源池里面挑选随机数。通过资源池可以保证多个AP-AC隧道挑选相同的随机数资源，从而计算得到相同的密钥。基于这种方式，多个AP可以共享同一个密钥，相比证书动态生成方式节省了芯片宝贵的存储空间，提高存储空间利用率，降低了芯片成本，相比静态pre-shared配置则提高了网络安全性。
[0018]因此，与现有技术相比，本发明的有益效果是:本发明使得不同的AP和同一个AC进行CAPWAP通信时，能够使用共享的DTLS加解密密钥对CAPWAP数据进行加解密，从而在需要严格控制芯片存储区域面积和成本的前提下，仍然能通过DTLS保障AP和AC间的安全通信。
【附图说明】
[0019]图1是现有DTLS握手协商流程的原理不意图；
[0020]图2是本发明基于CAPWAP使用共享密钥的方法的流程示意图；
[0021]图3是本发明实施例AC端芯片中存储的AP的加解密密钥和索引值之间的映射关系示意图。
【具体实施方式】
[0022]下面将结合本发明的附图，对本发明实施例的技术方案进行清楚、完整的描述。
[0023]如图1所示，在现有DTLS密钥通过证书动态生成的技术中，DTLS加解密需要用到的密钥是在DTLS会话的握手阶段，由AP和AC共同协商得出，即AP和AC密钥的协商由步骤SlOl?S113决定。
[0024]具体地，步骤S102和S104中包含AC端生成的一个32字节随机数，步骤SlOl和S103中包含AP端生成的一个32字节随机数，步骤S105是AC端向AP端发的数字证书，一方面用于AP鉴别AC的身份，一方面包含AC的公钥；AP在步骤S108时，先在本地随机生成一个48字节的预主密钥，然后用步骤S105得到的公钥进行RSA加密，发给AC，然后AC通过自己的私钥将预主密钥解密。此时，AC和AP都记录了三个数:AC端随机数、AP端随机数、预主密钥。最终的DTLS加解密密钥则通过这三个数计算得到。AC和AP各自计算，各自保存在本地。最后步骤Slll和步骤S113是双方接收用生成的密钥加密的密