SDN数据安全处理机制关键模块的研究与实现

李兆斌，李伟隆，魏占祯，刘梦甜

(北京电子科技学院 通信工程系，北京 100070)(*通信作者电子邮箱lovewiser@163.com)

0 引言

软件定义网络(Software Defined Network， SDN)是网络发展的新趋势，它将传统封闭的网络体系解耦为数据平面、控制平面和应用平面，在逻辑上实现网络的集中控制与管理[1]。OpenFlow协议是控制平面和数据平面之间的交互协议，可以将控制数据由控制平面的控制器下发至数据平面的数据转发设备。目前，企业园区网络、数据中心部署大量基于OpenFlow的SDN，其中承担数据转发功能的开源OpenFlow虚拟交换机Open VSwitch(OVS)更是在部署过程中得到广泛应用。

不过，随着SDN的迅猛发展，其安全问题也受到越来越多的关注，如控制器重要数据遭窃取、控制器因恶意分布式拒绝服务(Distributed Denial of Service, DDoS)攻击导致宕机[2]、被安装恶意应用等，这类问题给SDN的安全和稳定带来极大的挑战[3]。针对这些问题，国内外科研院所及安全企业提出多种SDN安全解决方案。有些解决方案以引入如防火墙、入侵检测系统等传统网络安全设备来解决SDN安全问题为主要思路，这类方案的确能够解决部分安全问题；但是却要求安全设备部署在有确切边界的区域，这违背了SDN结构灵活、可编程、转控分离的核心指导思想。一部分解决方案是由安全设备厂商独自开发新的SDN安全设备，这些新设备能够与SDN契合，同时也能兼顾厂商已部署的传统安全设备；但因各安全企业研发的SDN安全设备标准未能统一，数据安全处理过程也未融入到转发设备的数据处理流程中，给全网安全视图的形成造成阻碍。还有一些解决方案是将虚拟化的网络安全设备与它们的接入模式、部署位置进行解耦，抽象为安全资源池里的资源，智能化、自动化管理安全资源池；然而这类方案的基础是安全设备支持虚拟化，但这一前提在目前很难实现。

相比上述如企业独自开发SDN安全设备亦或是引入传统的网络安全设备防范SDN网络威胁等解决方案，文献[4]通过分析SDN数据转发平面的安全问题，提出了数据流表安全保护的方案，这一方案摆脱了区域限制、设备虚拟化等诸多要求，是解决SDN安全问题的新思路；但是，这一方案却没有考虑如何保护数据转发平面的用户数据完整和不被窃取。

因此，本文针对SDN的数据转发平面的数据泄露隐患和完整性保护问题，通过对OpenFlow协议进行深入分析和扩展，在对OVS数据转发流程[5]进行深入研究的基础上，创新性地提出一种新的基于OpenFlow的SDN的数据安全处理机制——SDN-DataSec(Software Defined Network-DataSecurity)。这一机制将数据安全处理融入到OVS数据转发过程中，在SDN的通用南向接口协议OpenFlow和虚拟交换机OVS中开发实现，包括OpenFlow安全策略解析、安全策略匹配、数据安全处理三个主要过程。SDN-DataSec不但不需要额外添加设备和安全软件，更是可与现有的OVS数据处理流程完全融合。本文首先对SDN现存的数据安全问题进行分析，发现数据平面数据传输时保密性问题；然后结合SDN的分层架构提出SDN数据安全处理机制，并阐述其基本模型和数据安全处理过程；随后重点阐述数据安全处理机制的关键模块和OpenFlow协议开发实现，并分析了加解密操作的处理粒度；最后，搭建软硬件平台对本文设计实现的数据安全处理机制进行有效性和性能开销测试。

1 SDN数据安全问题分析

支持OpenFlow协议[6]的OVS通常包含三个部分，分别是OpenFlow客户端、流缓冲区和流表，每个部分都可能成为数据转发平面中被攻击的目标，常见攻击如下。

1)流表溢出攻击导致数据泄露。OVS因设备性能的不同，导致其只能拥有数量有限的数据包缓冲区，存储有限数量的流表[7]。当OVS接收到数据包后，它将被暂存在缓冲区流中，直到有新规则插入适配成功，或直到流表中已存的流表规则获得响应，因此，攻击者可以通过发送大量未知数据包来使缓冲区和流表饱和，这将导致OVS流表及缓冲模块瘫痪。这种攻击严重损害合法数据包的正常转发，也为攻击者提供了窃取SDN数据包的机会[8]。

2)传输通道的数据窃取攻击。数据转发平面位于SDN架构的底部，包含大量互相连接、负责转发主机通信数据包的OVS。对于SDN网络来说，只有部分OVS是客户端主机访问网络的直接入口点和出口点，大部分OVS对数据包只作转发等基本操作，而数据包在数据转发面始终处于明态传输，一旦某个OVS受到控制，那么流经它的数据包将很容易泄露[9]。根据这种网络特点，攻击者可以通过简单地将链路附加到OVS的端口或通过未经验证的OVS接入网络来达到窃取SDN网络数据包[10]的目的。

针对SDN网络的安全问题，蔡佳晔等[11]设计了一种基于Sibson距离的DDoS攻击检测架构，该分层式架构通过引入攻击检测算法并采用多个代理控制器有效提升DDoS攻击检测时效性和准确性；但该架构专注于控制器攻击威胁的有效防范，缺少对数据平面交换机的安全研究。Afek等[12]舍弃中间件，基于数据平面提出了抗DDoS攻击的网络平台，通过复杂的流表规则以及交换机与控制器共享网络安全资源的方式增强SDN网络的抗DDoS能力；但该平台内部的安全性能较差，只能抵御外部的攻击。Lee等[13]开发了安全评估框架——DELTA(A Security Assessment Framework for Software-Defined Network)，在深度融合系统论与方法论的基础上开发了能够自动识别新漏洞的模糊检测机制，显著提升了SDN网络的整体安全性；但该框架的解决重点在于控制器和交换机的系统漏洞，对于SDN的传输网络安全问题防范相对薄弱。吴泉峰等[14]设计了一种基于SDN的流接入安全系统(SDN based Flow Access Security System, SDN-FASS)，该系统通过设立接入实体的黑(白)名单的方式实时下发接入控制安全策略，有效地防范网络外部的攻击并能够实时监测SDN网络内部的非法操作；但该系统只针对接入SDN网络的用户实体行为进行审计和监测，用户实体传输的数据安全缺少相关的防护，没有解决数据包明态传输可能带来的安全隐患。针对数据包在数据平面传输时处于明态传输状态、极易被窃取、保密性和完整性无法保证等问题，本文选择以OVS以及OpenFlow协议为研究对象，设计基于OpenFlow的SDN数据安全处理机制，将SDN数据平面中用户数据的明态传输变为安全的密态传输。

2 SDN数据安全处理机制设计

2.1 基本模型阐述

支持OpenFlow协议的OVS可分为用户层和内核层两部分。用户层包含了OVS的守护进程、OpenFlow管理工具以及数据库等[15]。内核层包含OVS的流表以及一个或者多个数据链路处理模块，可以快速地对数据包进行转发等操作。

OVS的主要功能是直接对用户数据进行明态处理和转发，并不负责转发数据的保密性和完整性保护[16]。SDN数据安全处理机制SDN-DataSec基本模型如图1所示，该机制扩展了OVS数据处理流程，添加了数据安全处理、安全解析、加解密处理，实现了数据加密传输，从而提高了OVS传输数据的保密性与完整性。

OVS支持两种类型的流表，即由Ofproto维护的OpenFlow流表和由内核数据路径维护的“Kernel”或“Datapath”流表。内核维护数据路径流表的主要目的是提高性能，以便只将第一个数据包发送到用户空间，并且随后的数据包通过向内核数据路径添加流表来避免影响到用户空间[17]。因此，SDN-DataSec创新性地设计提出数据安全策略，即根据不同数据包匹配条件与安全动作组合而成的策略流表，实现以数据流表形式从控制器下发数据安全策略至转发设备，转发设备根据数据安全策略对数据包进行加解密等安全动作。

图1 SDN-DataSec基本模型

SDN-DataSec模型覆盖控制面与数据转发面，包括控制器与OVS两类设备。其中，控制器主要包括全局安全策略模块和OpenFlow消息处理模块，OVS主要包括OpenFlow消息处理模块、OpenFlow安全策略模块、安全策略匹配模块、数据安全分析模块、数据加解密模块以及包重构模块等。控制器的全局安全策略模块可以根据用户的媒体介入控制层(Media Access Control， MAC)地址或VLAN生成基于数据链路的加解密等安全处理动作，即安全策略，也可以根据传统的IP地址、端口和协议生成基于数据流的安全策略。控制器通过OpenFlow协议向OVS下发包含安全策略的流表，OVS按照控制器下发的安全策略建立安全的数据转发链路，保障OVS之间转发数据的保密性和完整性。

2.2 SDN-DataSec数据安全处理过程

本文提出的数据安全处理过程机制，是对OpenFlow协议和OVS、控制器进行深度优化改进后设计实现的。SDN-DataSec中控制器和OVS各模块间的数据处理过程如图2所示。

图2 SDN-DataSec数据处理过程

OVS内核层的Vport数据接收模块负责接收网络数据包，然后将数据发送至核心的Datapath转发处理模块，该模块对数据包头相应元素进行提取，将其与存储在内核的流表进行匹配，如匹配不成功则使用Nelink通道上传至OVS用户层的数据处理模块。若用户层数据处理模块也无相应流表与之匹配，则通过OpenFlow消息处理模块上报控制器，请求数据转发流表。控制器中的全局安全策略模块可根据全局网络安全需求生成并下发数据安全策略。OVS数据安全处理过程如下。

①数据安全策略接收和转译。

OpenFlow安全策略模块主要承担存储、转译控制器下发的数据安全策略任务。OpenFlow协议是控制平面和数据平面之间的可编程接口，允许OVS接收控制器下发的控制信息。OVS内的OpenFlow协议主要由执行数据包查找和转发任务的流表和组表组成。本文设计开发的OpenFlow数据安全策略基于标准的OpenFlow协议，对其进行了扩展，添加新的安全策略执行操作。

在OpenFlow安全策略当中，将具体的每条策略定义为条件和动作的组合，依据条件执行相应的安全动作指令。在宏观上，控制层维护了一个全局的安全策略库，自动地收集网络内受管理的数据转发层设备信息，更新全局安全策略数据库，再将安全策略通过OpenFlow下发到数据转发设备当中。转发设备OVS内的OpenFlow安全策略模块接收到OpenFlow下发的安全策略后，将其转译为OVS本地安全策略逻辑，再发送至安全策略匹配模块。

本文的SDN安全策略下发过程具有较高的兼容性。控制器针对数据平面现有的网络情况制定安全策略并通过OpenFlow发送至相应的OVS,同时控制器与OVS也使用OpenFlow正常交互，下发标准的流表，可及时适应网络拓扑变化，在保留了灵活性的同时也提高了控制器对OVS的全局安全管控能力，降低了网络管理的复杂程度。

②安全策略匹配。

安全策略匹配模块主要负责接收转译后的安全策略以及由用户层数据处理模块发来的未匹配数据包。将接收的数据包与安全策略匹配，若匹配失败则将其发回用户层数据处理模块；若匹配成功，则将相应的数据包及匹配成功的安全策略发送至数据安全分析模块。

③深度解析数据包。

OVS设备对于从端口进入的数据包只能根据流表的匹配项，针对数据包包头某几位特定的关键值(如传输控制协议(Transmission Control Protocol， TCP)和用户数据报协议 (User Datagram Protocol， UDP)地址、端口号等)进行提取。由于OVS没有相应的数据接口对网络数据载荷进行提取，因此无法对数据包整体进行解析。本文对OVS数据处理流程进行了深度的扩展改造后，编写净载数据的提取接口，设计实现数据安全分析模块，该模块不仅能兼容OVS原有的数据包头关键信息提取方法，还可以根据安全策略提取对应的数据包净载信息。

数据安全分析模块接收到安全策略及匹配成功的数据包后，对数据包进行深度解析。根据安全策略执行不同的安全操作，可以解析包头的各项关键信息，同时也可解析提取出Payload净载信息。在成功解析获取数据信息后，数据安全分析模块将解析的数据信息发送至数据加解密模块。

④数据加解密。

OVS在对数据进行转发时完全没有对其所传输的敏感信息进行安全处理，这使得信息在数据转发平面传输没有任何安全防护。本文将密码算法加入到OVS中，开发实现数据加解密模块。

数据加解密模块接收到数据安全分析模块发来的数据信息后，将其进行加(解)密处理，并将加(解)密处理的密(明)文发送至包重构模块。

⑤数据包重构。

传统OVS设备中已含有包重构模块，但其功能并不能满足数据安全处理需求。本文对该模块进行重新设计，使其具备了对净载信息进行包重构的功能。

包重构模块接收到加解密模块发来的密(明)文后，从数据安全分析模块获取密数据对应的数据包头信息，将密(明)文进行包重构操作。

⑥数据转发。

包重构模块将重构处理后的数据包发回用户层数据处理模块，数据安全处理过程结束，数据包进入OVS正常工作流程，OVS可对其进行相应的转发操作。

3 SDN数据安全处理机制关键模块实现

本文选择Ryu[18]作为控制器，虚拟交换机OVS作为数据转发设备，本文所提出的数据安全处理机制主要工作和创新点聚焦于安全策略匹配模块、数据加解密模块、数据安全分析模块、包重构模块等多个模块的开发实现，OpenFlow协议的扩展及数据安全策略的匹配过程和数据安全处理的完整流程的设计。下面以涉及数据加解密的关键模块为例体现本文机制的创新性和主要工作内容，介绍OVS数据安全处理关键技术的实现以及对OpenFlow协议的扩展方法。

3.1 OVS数据加解密

OVS的数据处理分别在内核和用户两个空间进行，本文开发的数据加解密模块在用户层进行编译执行，该模块主要负责对从数据包中提取的数据信息或关键流表项信息进行加解密处理。用户层与内核层数据处理流程如图3所示。

图3 用户层与内核层数据处理流程

在数据包到达OVS端口时，数据包与内核空间中存在的流表进行匹配。如果匹配成功，则执行相应的动作(Action)对数据包进行处理；否则，使用Netlink套接字将数据包发送到用户空间进行OpenFlow流表查找。如果能够与用户空间维护的流表匹配，则进行相应的处理。如果没有找到匹配项，则将数据包发送到控制器。数据加解密模块的具体函数处理流程如图4所示。

由于OVS的Datapath模块(数据路径)是数据的“必经之路”[19]，本文对该模块进行了深入研究，添加了自定义的加解密动作指令及动作执行逻辑。以下是在Datapath模块中添加的Action操作定义：

enum ovs action attr {

OVS ACTION ATTR OUTPUT,

OVS ACTION ATTR PUSH VLAN,

OVS ACTION ATTR POP VLAN,

OVS ACTION ATTR SDN_ENCRYPT

OVS ACTION ATTR SDN_DECRYPT}；

其中SDN_ENCRYPT、SDN_DECRYPT是新添加的执行动作来支持加密和解密功能。同时为了支持新的动作，还需完成适当的结构定义，如struct ovs action sdn_encrypt等。

图4 数据加解密函数处理流程

为了OVS能够查看并检索到加解密动作，需对Ofproto子模块进行扩展改造，将加解密动作名称添加到该模块中的宏定义动作集中，如下：

#define OFPACTS

DEFINE OFPACT(OUTPUT, ofpact output, ofpact)

DEFINE OFPACT(SET VLAN VID,ofpact vlan vid,ofpact)

DEFINE OFPACT(PUSH VLAN, ofpact null, ofpact)

DEFINE OFPACT(SDN_ENCRYPT,ofpact_null,ofpact,

"sdn_encrypt")

以上完成了数据加解密动作指令Action的添加。为了能够在OVS中执行具体的加解密操作，必须添加执行加解密的逻辑函数，需对Ofp-action模块及Ofproto模块进行适当的扩展，使其兼容新添加的动作指令。不仅如此，为了使添加的动作能够被OVS提取和搜索/匹配流表项，还需对数据库模块目录中的流表项模块、筛选匹配模块进行扩展改造。

3.2 OpenFlow协议扩展

通过对OpenFlow协议的匹配项和动作扩展，添加OpenFlow安全策略模块，可使控制器能够根据安全策略生成数据安全处理策略，并将安全策略下发到OVS中，增强了SDN网络应对安全问题的处理能力。

新添加的基于OpenFlow的安全策略模块处于OVS的数据层面。一方面OpenFlow安全策略模块可以不完全依赖控制器而是在数据层面直接对数据进行相应处理；另一方面OVS中的OpenFlow安全策略模块符合OpenFlow API调用标准，控制器可以对其进行灵活调用以便与控制器中的全局安全策略模块交互。不仅如此，通过扩展OpenFlow协议添加的OpenFlow安全策略模块所产生的流表和原有的OpenFlow流表规则标准相同，可以融入到原有的OpenFlow流表中，保证OpenFlow的流表一致性。

OpenFlow安全策略模块主要工作流程如图5所示，该模块有两种安全策略流表创建方式：

1)主动式。即安全策略流表被提前写入OVS中，使用时OpenFlow安全策略模块根据数据分析模块解析已存在的安全策略进行相应处理。

2)被动式。由控制器通过Packet_out报文将控制器全局安全策略模块产生的安全策略流表下发至各OVS。

图5 安全策略模块主要工作流程

在被动式网络中，若下发的一条安全策略与OVS中目前使用的所有安全策略都不匹配或有冲突，则OVS将该数据信息解析封装为Packet_in报文中并上报给控制器。控制器收到报文后，利用已掌握的全局网络情况再次根据全局安全解析模块决定丢弃或者对数据包进行其他处理，并将更新后的安全策略下发给OVS。OVS收到新的安全策略后，OpenFlow安全策略模块自动更新流表，之后再次处理该类型的数据包时，会有相应的流表与其匹配。

为了保证OVS的OpenFlow安全策略模块可以与控制器正常使用OpenFlow协议进行交互，添加的新动作应与OVS支持的所有OpenFlow协议版本兼容。

3.3 加解密处理粒度分析

在目前OVS的流表使用中，已不仅是单纯的精确匹配了，而是一种精确匹配+带掩码匹配合并在一起的方式。该方式的目的是为了减少Datapath里精确流表的条目数，将部分模糊匹配下放到内核态处理，以减少每次因为不同的包被递送时都要Upcall到用户空间的时间，借此提高效率，因此本文在添加加解密操作后，根据不同数据包类型，在开发实现的数据安全分析模块以及安全策略模块基础上，优化加解密操作，细化加解密操作粒度，提高处理效率，减少处理时间。根据控制器下发的安全策略，加解密处理基本操作粒度如表1所示。

每条策略定义为条件和动作的组合，依据由基本条件字段、细粒度条件字段组成的条件执行相应的安全动作指令。基本条件字段规定本条策略的生存时长，处理数据包数量，具体包括生效时间Duration_sec、所属表项Table_id、优先级Priority、处理的数据包数、空闲超时时间Idle_timeout等，超过设置的空闲超时时间后该策略将被自动删除，空闲超时时间设置为0表示该策略永不过期，从而保证策略实时更新，实时有效。细粒度条件字段包括输入端口号In_port、源/目的MAC地址Dl_src/Dl_dst、源/目的IP地址Nw_src/Nw_dst、数据包类型Dl_type、网络层协议类型Nw_proto等。

表1 基本操作粒度

一条策略需由以上条件辅以执行动作组成，当数据包进入安全策略匹配模块时，即根据细粒度条件对数据包进行筛选：

1)当多个细粒度条件均满足时，即将安全策略与匹配成功的数据包一并发给数据安全模块。

2)当多个细粒度条件只满足其中几项时，即查看是否匹配成功表1中带(*)条件字段，若匹配成功即交由数据安全模块处理。

3)若未匹配成功，则将数据返回用户层数据处理模块进行后续转发等操作。为了保证OVS的OpenFlow安全策略模块可以与控制器正常使用OpenFlow协议进行交互，添加的新动作应与OVS支持的所有OpenFlow协议版本兼容。

4 测试与结果分析

4.1 测试环境

本文提出了数据安全处理机制，与之相关的SDN数据安全研究成果，目前有杭州华三通信公司的SDN安全功能方法和装置[20]和上海斐讯数据通信公司的基于SDN的数据流加密方法和系统[21]均属于相关企业的发明专利，难以比较分析，因此，本文就所设计实现的数据安全处理机制的有效性和性能开销进行相关测试。

测试主机选用Ubuntu15.10系统，2.6.0版本OVS，4.13版本Ryu，测试拓扑如图6所示。

图6 测试拓扑结构

4.2 有效性测试

本次测试OVS1和OVS2传输Host1、Host2通信数据时是否可以针对下发的安全策略对敏感数据进行加解密操作。为方便验证，本次测试中OVS使用基本的异或算法进行加解密操作。

1)Ryu控制器下发安全策略：OVS1对Host1发往Host2的UDP数据包进行加密操作，同时OVS2不作解密操作，直接转发至Host2。

如图7所示，使用抓包工具在Host1处抓包，显示Host1向Host2发出消息：Besti。

图7 Host1发送数据抓取

Fig. 7 Data crawl sent by Host1

使用抓包工具在Host2上抓取来自Host1的UDP数据包，抓取的数据包如图8所示，Besti已被OVS1完整地解析获取并使用密码算法加密成功，重构数据包后再次发送出去。

图8 Host2接收数据抓取

Fig. 8 Data crawl received by Host2

2)Ryu控制器下发安全策略：OVS1对Host1发往Host2的UDP数据包进行加密操作，同时OVS2对Host1发往Host2的UDP数据包进行解密操作，处理后转发至Host2。

如图9～10所示，两台OVS的加密、解密安全策略已经运作，并成功处理数据。同时于Host1处抓包，显示Host1向Host2发出消息：Besti、OVS1、OVS2已运行加密，解密安全策略(sdn_encrypt,sdn_decrypt)，对Host1、Host2往来的通信信息分别进行加密和解密处理，Host2收到完整的数据。

图9 加密策略执行

Fig. 9 Encryption strategy implementation

图10 解密策略执行

Fig. 10 Decryption strategy implementation

4.3 性能测试

1)OVS1、OVS2均执行基本的OUTPUT(转发)动作，OVS1执行其自带的更改VLAN的PUSH VLAN操作，OVS2执行POP VLAN动作；在OVS1、OVS2处分别执行开发的加解密动作处理，然后(如图11所示)统计对比相同数量的数据包所产生的时延情况。本次测试通过发送大量的相同内容数据包测试不同动作产生的时延情况。

图11 3种执行操作的时延对比

由图11可知，当数据包发送数量为200 000时，时延基本一致。在发送量为400 000数据包以后，时延开始变大并且三种动作的时延差距趋于明显。本文加密动作所产生的时延虽略高于基本的转发动作，但与对数据包进行修改处理的PUSH VLAN+POP VLAN时延相近，说明该功能不会对正常的数据交换造成较大影响。

2)OVS1、OVS2均执行基本的OUTPUT(转发)动作；在OVS1、OVS2处分别执行开发的加解密动作处理，并(如图12所示)统计和对比当不同数据包大小时，加解密动作和转发动作的吞吐量情况。

图12 两种操作的吞吐量对比

如图12所示，加解密动作的吞吐量低于OVS的基本动作(转发)，但差距不影响数据的正常传输。

3)OVS1、OVS2分别针对不同类型的数据包(TCP、UDP、IP、MAC)执行转发处理和加解密处理，统计并对比CPU使用情况，如图13所示。注：本次测试中相同类型的数据包大小内容均相同。

图13 两种操作处理不同类型数据包的CPU使用率对比

如图13所示，可知正常转发动作因未对数据进行处理即CPU使用率低，始终低于10%；加解密操作因处理的数据包类型不同，其CPU使用率在45%～60%浮动，CPU使用率高，但仍可正常传输数据。

综合以上测试结果，本文设计并实现数据安全处理机制能够有效地对数据进行加解密操作，并且不会对正常的数据传输造成较大影响。

5 结语

当下软件定义网络对数据的转发均处于“明态”传输模式，网络架构缺乏安全策略，数据信息安全得不到保证，本文针对软件定义网络中的数据泄露问题，设计实现了SDN数据安全处理平台。通过对控制器和OVS的多个功能模块的开发实现，完成了本平台的数据安全策略细粒度匹配和数据安全处理全过程。最后，通过有效性和性能开销测试，结果表明本文提出的数据安全处理机制能够准确、有效地对数据进行加解密处理，时延和吞吐量数据处于正常水平但CPU使用率较高，负载较大。

本文提出的数据安全处理机制虽然能够基本满足SDN网络架构下的数据保密需求，但存在CPU负荷较大的不足，因此进一步的研究方向是深度优化数据安全处理流程，降低负载开销，降低CPU使用率，提高吞吐量，提升性能；深入研究本机制使用同种加(解)密算法能否处理不同类型的数据包，研究密钥分配方式能否深层次融入机制功能当中，研究非对称加(解)密算法和对称加(解)密算法的使用对机制功能的不同影响。