CN110943996A - 一种业务加解密的管理方法、装置及系统 - Google Patents

一种业务加解密的管理方法、装置及系统 Download PDF

Info

Publication number
CN110943996A
CN110943996A CN201911222218.0A CN201911222218A CN110943996A CN 110943996 A CN110943996 A CN 110943996A CN 201911222218 A CN201911222218 A CN 201911222218A CN 110943996 A CN110943996 A CN 110943996A
Authority
CN
China
Prior art keywords
encryption
decryption
data protection
service
protection gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN201911222218.0A
Other languages
English (en)
Other versions
CN110943996B (zh
Inventor
范浩
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Maipu Communication Technology Co Ltd
Original Assignee
Maipu Communication Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Maipu Communication Technology Co Ltd filed Critical Maipu Communication Technology Co Ltd
Priority to CN201911222218.0A priority Critical patent/CN110943996B/zh
Publication of CN110943996A publication Critical patent/CN110943996A/zh
Application granted granted Critical
Publication of CN110943996B publication Critical patent/CN110943996B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes

Abstract

本申请提供一种业务加解密的管理方法、装置及系统，方法应用于局域网络中的SDN控制器，所述局域网络中还包括与所述SDN控制器连接的数据保护网关，所述方法包括：接收所述数据保护网关发送的所述数据保护网关的设备认证信息；利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；若确定所述数据保护网关可信，为所述数据保护网关配置加解密业务报文时所使用的加解密策略。由于SDN控制器可以对局域网中的数据保护网关的可信进行认证，并在认证通过后才为数据保护网关配置业务的加解密策略，使得每个进行加解密的数据保护网关都是安全可信的，进一步提高网络的安全性。

Description

一种业务加解密的管理方法、装置及系统
技术领域
本申请涉及通信技术领域，具体而言，涉及一种业务加解密的管理方法、装置及系统。
背景技术
目前，可以将企业的数据业务部署到局域网中，以确保企业数据的安全。但在一些大规模企业中，其企业中心所在的局域网与分支机构所在的局域网之间需要跨越互联网通信例如跨越IP(InternetProtocol，互联网协议地址)/MPLS(Multi-Protocol LabelSwitching，多协议标签交换)网络。在这种情况下，为确保企业数据的安全，可以在互联网出口部署IPsec VPN网关或者SSL VPN网关，以通过IPsec VPN网关或者SSL VPN网关，加密从局域网发往互联网的企业数据，或者将从互联网接收的企业数据解密。显然，这种互联网出口和出口之间的“点到点”数据加密方式过于简单，安全性不够高。
发明内容
本申请实施例的目的在于提供一种业务加解密的管理方法、装置及系统，用以提高网络的安全性。
第一方面，本申请实施例提供了一种业务加解密的管理方法，应用于局域网络中的SDN控制器，所述局域网络中还包括与所述SDN控制器连接的数据保护网关，所述方法包括：
接收所述数据保护网关发送的所述数据保护网关的设备认证信息；
利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
若确定所述数据保护网关可信，为所述数据保护网关配置加解密业务报文时所使用的加解密策略。
在本申请实施例中，由于SDN控制器可以对局域网中的数据保护网关的可信度进行认证，并在认证通过后才为数据保护网关配置业务的加解密策略，使得每个进行加解密的数据保护网关都是安全可信的，进一步提高网络的安全性。
结合第一方面，在第一种可能的实现方式中，利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信，包括：
判断所述设备认证信息中是否携带有所述SDN控制器预先为所述数据保护网关分配的预共享密钥；
若携带有所述预共享密钥，判断所述预共享密钥是否被篡改；
若未篡改，利用所述设备认证信息中携带的所述数据保护网关申请证书所需的信息，向CA服务器申请所述数据保护网关的设备证书，并判断所述设备证书是否申请成功，其中，所述设备证书申请成功表示所述数据保护网关可信。
在本申请实施例中，在为数据保护网关申请证书前，先利用SDN控制器预先为数据保护网关分配的预共享密钥对该数据保护网关的可信进行认证，可以确保申请证书的数据保护网关都是SDN控制器认为可信的设备，进一步提高安全性。
结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，为所述数据保护网关配置加解密业务报文时所使用的加解密策略，包括：
确定出与所述数据保护网关的业务类型对应的所述加解密策略，将所述加解密策略配置到所述数据保护网关。
在本申请实施例中，将加密的加解密策略配置给数据保护网关，可以确保配置过程中的安全性，防止加解密策略被窃取并破解。
结合第一方面的第二种可能的实现方式，在第三种可能的实现方式中，将所述加解密策略配置到所述数据保护网关，包括：
利用所述CA服务器为所述设备证书分配的密钥加密所述加解密策略，将加密后的加解密策略发送给所述数据保护网关，以使所述数据保护网关利用所述分配的密钥解密所述加密后的加解密策略，并配置所述加解密策略。
在本申请实施例中，由于设备证书申请成功后，数据保护网关可以持有CA服务器为设备证书分配的密钥，那么采用CA服务器为设备证书分配的密钥加密加解密策略可以便于数据保护网关解密。
结合第一方面，在第四种可能的实现方式中，在为所述数据保护网关配置加解密业务报文时所使用的加解密策略之后，所述方法还包括：
周期性的更新所述加解密策略中用于加解密的密钥，其中，任意两个周期对应的所述密钥均不同。
在本申请实施例中，通过周期性的更新加解密策略中用于加解密的密钥，可以进一步提高加解密的安全性。
结合第一方面，在第五种可能的实现方式中，在判断所述数据保护网关是否可信之后，所述方法还包括：
若确定不可信，将所述数据保护网关从所述局域网络中删除。
在本申请实施例中，通过将不可信的数据保护网关从局域网络中删除，可以避免不可信的数据保护网关破坏局域网络的安全。
第二方面，本申请实施例提供了一种业务加解密的管理方法，应用于局域网络中的数据保护网关，所述局域网络中还包括与所述数据保护网关连接的SDN控制器，所述方法包括：
向所述SDN控制器发送自身的设备认证信息，以使所述SDN控制器利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
在所述SDN控制器确定所述数据保护网关可信后，接收所述SDN控制器下发的加解密策略；
利用所述加解密策略对接收到的业务报文进行加解密。
在本申请实施例中，由于SDN控制器可以对局域网中的数据保护网关的可信进行认证，并在认证通过后才为数据保护网关配置业务的加解密策略。这样，局域网络中，每个进行加解密的数据保护网关都是安全可信的，从而进一步提高网络的安全性。
结合第二方面，在第一种可能的实现方式中，利用所述加解密策略对接收到的业务报文进行加解密，包括：
接收客户端发送的所述业务报文；
利用所述加解密策略，对所述业务报文携带的业务内容进行加密，以及在所述业务报文中添加策略加密头部，获得处理后的业务报文；
将所述处理后的业务报文发送到所述局域网络中对端的数据保护网关。
在本申请实施例中，由于对业务报文的加密格式是在业务报文中添加策略加密头部，并不改变业务报文原有的以太头部、IP头部和TCP(Transmission Control Protocol传输控制协议)/UDP(User Datagram Protocol，用户数据报协议)头部，故无需对原有的网络结构进行调整，实现无感知的提高网络安全性。
结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，利用所述加解密策略，对所述业务报文携带的业务内容进行加密，以及在所述业务报文中添加策略加密头部，获得处理后的业务报文，包括：
利用所述加解密策略，将所述业务内容加密成密文，获得携带有所述密文的第一业务报文，以及压缩所述密文，获得携带有所述压缩的密文的第二业务报文；
若确定所述压缩的密文与需要添加的所述策略加密头部的第一长度和小于所述业务内容的长度，在所述第二业务报文中添加所述策略加密头部，通过添加所述压缩后的密文的内容而将所述第一长度增加到与所述业务内容的长度相同，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第一业务报文与所述策略加密头部的第二长度和小于等于预设的长度阈值，根据所述第二长度和对应修改所述第一业务报文的IP头部和TCP头部中的长度字段，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第二长度和大于所述长度阈值，生成与所述第一业务报文对应的两个所述处理后的业务报文，其中，一个所述处理后的业务报文中携带所述密文的一部分，另一个所述处理后的业务报文中则携带所述密文的另一部分，且任一个所述处理后的业务报文的长度均小于等于所述长度阈值。
在本申请实施例中，通过增加报文长度、修改报文的长度字段、以及将报文分割的方式，可以确保添加策略加密头部的业务报文而导致长度增加后仍然能够按原有协议正确发送。
结合第二方面，在第三种可能的实现方式中，利用所述加解密策略对接收到的业务报文进行加解密，包括：
接收对端的数据保护网关发送的所述业务报文；
利用所述加解密策略解密所述业务报文，获得解密的业务报文；
将所述解密的业务报文发送至客户端。
在本申请实施例中，利用加解密策略解密业务报文，可以确保业务报文中的内容被还原，以使客户端能够正确识别。
结合第二方面，在第四种可能的实现方式中，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由所述上一版本的加解密策略处理，判断是否还存储有所述上一版本的加解密策略；
若是，利用所述上一版本的加解密策略，解密所述业务报文。
在本申请实施例中，虽然数据保护网关的加解密策略进行了更新，但数据保护网关还存储有上一版本的加解密策略，那么数据保护网关仍可以处理需要由上一版本的加解密策略处理的业务报文，实现了即使存在更新加解密策略的时间差也能够确保对业务报文的处理不中断。
结合第二方面，在第五种可能的实现方式中，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由所述SDN控制器将要下发的下一版本的加解密策略处理，将所述业务报文缓存；
在接收到所述下一版本的加解密策略时，利用所述下一版本的加解密策略，加解密所述业务报文。
在本申请实施例中，在加解密策略更新前若接收需要更新的下一版本的加解密策略处理的业务报文，由于数据保护网关则可以缓存该业务报文到更新到下一版本的加解密策略再处理业务报文，故在更新加解密策略的存在时间差的情况下，数据保护网关也能够确保对业务报文的处理不中断。
结合第二方面，在第六种可能的实现方式中，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由另一版本的加解密策略处理，且所述另一版本的加解密策略与所述SDN控制器下发的加解密策略之间相差至少两个版本，将所述业务报文丢弃。
在本申请实施例中，若另一版本的加解密策略与SDN控制器下发的加解密策略之间相差至少两个版本，说明需要该另一版本的加解密策略处理的业务报文是不可信的，因此数据保护网关可以将该业务报文丢弃，以确保安全。
第三方面，本申请实施例提供了一种业务加解密的管理装置，应用于局域网络中的SDN控制器，所述局域网络中还包括与所述SDN控制器连接的数据保护网关，所述装置包括：
数据收发模块，用于接收所述数据保护网关发送的所述数据保护网关的设备认证信息；
数据处理模块，用于利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
若所述数据处理模块确定所述数据保护网关可信，所述数据收发模块，还用于为所述数据保护网关配置加解密业务报文时所使用的加解密策略。
结合第三方面，在第一种可能的实现方式中，
所述数据处理模块，用于判断所述设备认证信息中是否携带有所述SDN控制器预先为所述数据保护网关分配的预共享密钥；若携带有所述预共享密钥，判断所述预共享密钥是否被篡改；若未篡改，利用所述设备认证信息中携带的所述数据保护网关申请证书所需的信息，向CA服务器申请所述数据保护网关的设备证书，并判断所述设备证书是否申请成功，其中，所述设备证书申请成功表示所述数据保护网关可信。
结合第三方面的第一种可能的实现方式，在第二种可能的实现方式中，
所述数据处理模块，用于确定出与所述数据保护网关的业务类型对应的所述加解密策略，将所述加解密策略配置到所述数据保护网关。
结合第三方面的第二种可能的实现方式，在第三种可能的实现方式中，
所述数据处理模块，用于利用所述CA服务器为所述设备证书分配的密钥加密所述加解密策略，将加密后的加解密策略发送给所述数据保护网关，以使所述数据保护网关利用所述分配的密钥解密所述加密后的加解密策略，并配置所述加解密策略。
结合第三方面，在第四种可能的实现方式中，在所述数据收发模块为所述数据保护网关配置加解密业务报文时所使用的加解密策略之后，所述方法还包括：
所述数据处理模块，还用于周期性的更新所述加解密策略中用于加解密的密钥，其中，任意两个周期对应的所述密钥均不同。
结合第三方面，在第五种可能的实现方式中，在所述数据处理模块判断所述数据保护网关是否可信之后，
若确定不可信，所述数据处理模块，还用于将所述数据保护网关从所述局域网络中删除。
第四方面，本申请实施例提供了一种业务加解密的管理装置，应用于局域网络中的数据保护网关，所述局域网络中还包括与所述数据保护网关连接的SDN控制器，所述装置包括：
数据收发模块，用于向所述SDN控制器发送自身的设备认证信息，以使所述SDN控制器利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；在所述SDN控制器确定所述数据保护网关可信后，接收所述SDN控制器下发的加解密策略；
数据处理模块，用于利用所述加解密策略对接收到的业务报文进行加解密。
结合第四方面，在第一种可能的实现方式中，
所述数据处理模块，用于接收客户端发送的所述业务报文；利用所述加解密策略，对所述业务报文携带的业务内容进行加密，以及在所述业务报文中添加策略加密头部，获得处理后的业务报文；
所述数据收发模块，用于将所述处理后的业务报文发送到所述局域网络中对端的数据保护网关。
结合第四方面的第一种可能的实现方式，在第二种可能的实现方式中，
所述数据处理模块，用于利用所述加解密策略，将所述业务内容加密成密文，获得携带有所述密文的第一业务报文，以及压缩所述密文，获得携带有所述压缩的密文的第二业务报文；
若确定所述压缩的密文与需要添加的所述策略加密头部的第一长度和小于所述业务内容的长度，所述数据处理模块，用于在所述第二业务报文中添加所述策略加密头部，通过添加所述压缩后的密文的内容而将所述第一长度增加到与所述业务内容的长度相同，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第一业务报文与所述策略加密头部的第二长度和小于等于预设的长度阈值，所述数据处理模块，用于根据所述第二长度和对应修改所述第一业务报文的IP头部和TCP头部中的长度字段，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第二长度和大于所述长度阈值，所述数据处理模块，用于生成与所述第一业务报文对应的两个所述处理后的业务报文，其中，一个所述处理后的业务报文中携带所述密文的一部分，另一个所述处理后的业务报文中则携带所述密文的另一部分，且任一个所述处理后的业务报文的长度均小于等于所述长度阈值。
结合第四方面，在第三种可能的实现方式中，
所述数据处理模块，用于接收对端的数据保护网关发送的所述业务报文；利用所述加解密策略解密所述业务报文，获得解密的业务报文；
所述数据收发模块，用于将所述解密的业务报文发送至客户端。
结合第四方面，在第四种可能的实现方式中，在所述数据收发模块接收所述SDN控制器下发的加解密策略之后，
所述数据收发模块，还用于接收所述局域网络中对端的数据保护网关发送的业务报文；
所述数据处理模块，还用于确定所述业务报文需要由所述上一版本的加解密策略处理，判断是否还存储有所述上一版本的加解密策略；若是，利用所述上一版本的加解密策略，解密所述业务报文。
结合第四方面，在第五种可能的实现方式中，在所述数据收发模块接收所述SDN控制器下发的加解密策略之后，
所述数据收发模块，还用于接收所述局域网络中对端的数据保护网关发送的业务报文；
所述数据处理模块，还用于确定所述业务报文需要由所述SDN控制器将要下发的下一版本的加解密策略处理，将所述业务报文缓存；在接收到所述下一版本的加解密策略时，利用所述下一版本的加解密策略，加解密所述业务报文。
结合第四方面，在第六种可能的实现方式中，在所述数据收发模块接收所述SDN控制器下发的加解密策略之后，
所述数据收发模块，还用于接收所述局域网络中对端的数据保护网关发送的业务报文；
所述数据处理模块，还用于确定所述业务报文需要由另一版本的加解密策略处理，且所述另一版本的加解密策略与所述SDN控制器下发的加解密策略之间相差至少两个版本，将所述业务报文丢弃。
第五方面，本申请实施例提供了一种业务加解密系统，包括：部署在局域网络中的SDN控制器和数据保护网关，所述数据保护网关与所述SDN控制器连接，
所述SDN控制器，用于执行如第一方面或第一方面的任一种可能的实现方式所述的业务加解密的管理方法；
所述数据保护网关，用于执行如第二方面或第二方面的任一种可能的实现方式所述的业务加解密的管理方法。
第六方面，本申请实施例提供了一种具有计算机可执行的非易失程序代码的计算机可读储存介质，所述程序代码使所述计算机执行如第一方面、第一方面的任一种可能的实现方式、第二方面或第二方面的任一种可能的实现方式所述的业务加解密的管理方法。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的一种业务加解密系统的结构框图；
图2为本申请实施例提供的一种业务加解密的管理方法的流程图；
图3为本申请实施例中业务报文的第一结构示意图；
图4为本申请实施例中策略加密头部的结构示意图
图5为本申请实施例中业务报文的第二结构示意图；
图6为本申请实施例中业务报文的第三结构示意图；
图7为本申请实施例中业务报文的第四结构示意图；
图8为本申请实施例中业务报文的第五结构示意图；
图9为本申请实施例提供的一种业务加解密的管理装置的第一结构框图；
图10为本申请实施例提供的一种业务加解密的管理装置的第二结构框图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。
请参阅图1，本申请实施例提供了一种业务加解密系统10，该业务加解密系统10可以部署到企事业单位内部使用的局域网络中，业务加解密系统10可以包括：SDN控制器(即图1中的ICC11，ICC表示Intelligence Control Center，智能控制中心)和数据保护网关(即图1中的DPG12，DPG表示Data Protect Gateway)。
其中，ICC11用于负责对部署在局域网络中的DPG12进行管理，比如验证DPG12是否可信，为可信的DPG12分配加解密策略，以及更新可信的DPG12的加解密策略。
本发明实施例中的DPG12可以部署在局域网络与互联网连接的出口处。根据DPG12的连接对象不同，DPG12的类型也有所不同。例如，DPG12连接局域网络中的终端，则是E-DPG12(Endpoint Data Protect Gateway，端点数据保护网关)，DPG12连接局域网络中的服务器，那么DPG12可以是C-DPG12(Center Data Protect Gateway，中心数据保护网关)。本实施例中，DPG12可以利用加解密策略对需要发送到互联网的业务报文进行加密，以通过互联网将加密的业务报文发送到局域网络中对端的DPG12。对应的，DPG12也可接收到对端的DPG12通过互联网发送的加密的业务报文，并利用加解密策略解密该加密的业务报文，从而将解密后的业务报文发送给局域网络中的终端或服务器上部署的客户端。
下面将通过方法实施例对SDN控制器和数据保护网关的工作进行详细说明。
请参阅图2，本申请实施例提供了一种业务加解密的管理方法，该业务加解密的管理方法可以由SDN控制器和数据保护网关配合执行，具体的，该业务加解密的管理方法可以包括：
步骤S100：数据保护网关向SDN控制器发送自身的设备认证信息。
步骤S200：SDN控制器接收数据保护网关发送的数据保护网关的设备认证信息。
步骤S300：SDN控制器利用设备认证信息对数据保护网关进行认证，以判断数据保护网关是否可信。
步骤S400：若确定数据保护网关可信，SDN控制器为数据保护网关配置加解密业务报文时所使用的加解密策略，否则，将该数据保护网关从局域网络中删除。
步骤S500：数据保护网关接收SDN控制器下发的加解密策略。
步骤S600：数据保护网关利用加解密策略对接收到的业务报文进行加解密。
下面将结合图1对业务加解密的管理方法的各流程进行详细说明。
步骤S100：数据保护网关向SDN控制器发送自身的设备认证信息。
在需要将新的DPG12部署到局域网络中时或者在已部署在局域网络的DPG12的设备证书将要超时老化时，需要该DPG12向ICC11发起可信认证，以确自身目前是否可信。
具体的，若DPG12为需要部署到局域网络的DPG12，在发起可信认证前，DPG12可以向ICC11发送预共享密钥获取请求。ICC11可以响应该预共享密钥获取请求，为DPG12分配一个唯一的预共享密钥，并将该预共享密钥下发给DPG12。这样，DPG12在发起可信认证的过程中携带该预共享密钥，ICC11就可以利用预共享密钥识别该DPG12的身份。换言之，ICC11认证该DPG12的前提为先识别出DPG12的身份。因此，DPG12在获得预共享密钥后，DPG 12便将携带该预共享密钥和申请证书所需的信息的设备认证信息发送给ICC11。
若DPG12为已经部署到局域网络的DPG12，由于DPG12在加入局域网络已经获得的自身的预共享密钥，故DPG12可以直接将携带该预共享密钥和申请证书所需的信息的设备认证信息发送给ICC11。
本实施例中，作为发送设备认证信息的第一种示例性方式，可以预先为DPG12配置报文生成规则，DPG12利用报文生成规则便可以生成携带有设备认证信息的认证报文，并将该认证报文发送给ICC11。
作为发送设备认证信息的第二种示例性方式，可以预先为DPG12配置报文修改规则，DPG12利用报文修改规则可以将终端或服务器发送的经由该DPG12的非ARP(AddressResolution Protocol，地址解析协议)报文拦截，并将报文的内容修改为设备认证信息，使得该报文变成认证报文，进而再将该认证报文发送给ICC11。
此外，在发送认证报文时，若DPG12为E-DPG12，DPG12可以将认证报文发送到局域网络中对端的C-DPG12，并由C-DPG12再将认证报文转发给ICC11。若DPG12为C-DPG12，DPG12则直接将认证报文发送到ICC11。由于认证报文经由C-DPG12转发或由C-DPG12直接发送，ICC11利用认证报文便可以确定出C-DPG12与哪些E-DPG12连接，进而可以绘制出局域网络中由ICC11和各DPG12构成的最新的网络拓扑。
当然，认证报文发送方式也不限于上述方式，例如，在网络拓扑变化时，用户可以将最新的网络拓扑直接配置给ICC11，那么ICC11则无需通过认证报文来确定出最新的网络拓扑。换言之，E-DPG12和C-DPG12都可以将认证报文直接发送给ICC11。
步骤S200：SDN控制器接收数据保护网关发送的数据保护网关的设备认证信息。
ICC11在接收到DPG12发送的认证报文后，ICC11可以将认证报文解封装，从而获得认证报文中DPG12的设备认证信息。
步骤S300：SDN控制器利用设备认证信息对数据保护网关进行认证，以判断数据保护网关是否可信。
ICC11利用设备认证信息，可以对DPG 12的是否可信进行认证。
具体的，ICC11可以利用自身存储的预先为DPG12分配的预共享密钥，去判断设备认证信息中是否携带有ICC11预先为DPG12分配的预共享密钥。
若确定设备认证信息未携带有ICC11预先为DPG12分配的预共享密钥，说明该DPG12不可信。
若确定设备认证信息携带有ICC11预先为DPG12分配的预共享密钥，说明该DPG12的身份是明确的，进而可以利用设备认证信息中DPG12申请证书所需的信息，继续认证DPG12是否可信。
可选的，DPG12可以将DPG12申请证书所需的信息发送给第三方的CA(CertificateAuthority，证书颁发机构)服务器，以使该CA服务器利用DPG12申请证书所需的信息而判断是否为该DPG12颁发设备信息。对于ICC11，在发送DPG12申请证书所需的信息后，ICC11可以判断DPG12的设备证书是否申请成功。
若CA服务器通过验证DPG12申请证书所需的信息而确定DPG12可信，CA服务器可以为DPG12颁发设备证书，并为该设备证书分配的密钥。CA服务器将设备证书和设备证书的密钥发送给ICC11。ICC11对应接收到设备证书和设备证书的密钥，并通过确定接收到设备证书和设备证书的密钥而确定DPG12的设备证书申请成功，该DPG12的设备证书申请成功则表示该DPG12可信。
若CA服务器通过验证DPG12申请证书所需的信息而确定DPG12不可信，CA服务器拒绝为DPG12颁发设备证书，并向ICC11发送证书申请失败信息。ICC11对应接收到证书申请失败信息，从而确定DPG12的设备证书申请失败，该DPG12的设备证书申请失败则表示该DPG12不可信。
步骤S400：若确定数据保护网关可信，SDN控制器为数据保护网关配置加解密业务报文时所使用的加解密策略，否则，将该数据保护网关从局域网络中删除。
本实施例中，ICC11为DPG12配置加解密策略可以分两种情况，一种情况是ICC11为DPG12配置一种新的加解密策略，以使DPG12可以利用该加解密策略对一种新的业务进行加解密；另一种情况是ICC11为DPG12配置的加解密策略用于更新DPG12上原有的一种加解密策略，以使DPG12利用更新的加解密策略继续对原有的业务进行加解密。
针对第一种情况：
由于ICC11掌握了最新的网络拓扑，通过分析网络拓扑，用户可以获知网络拓扑中具有哪些类型的数据业务。这样，用户便可以从未加密传输的数据业务中确定出在当前需求下需要加密传输的数据业务，并确定涉及该数据业务的DPG12。进一步的，用户将该需要加密传输的数据业务的加解密策略配置给ICC11，ICC11便需要将获取的加解密策略再配置给涉及该数据业务的所有DPG12。
针对第二种情况：
ICC11中预设了加解密策略的更新规则，ICC11利用该更新规则可以将ICC11中需要更新的加解密策略更新，例如将更新的加解密策略中加解密所使用的密钥更新，获得更新后的加解密策略。然后，ICC11再将更新后的加解密策略配置给对应的DPG12，以使这些DPG12将自身的加解密策略对应更新。
进一步的，作为将加解密策略配置给对应的DPG12示例性方式，在确定DPG12可信后，ICC11可以利用DPG12的预共享密钥，将加解密策略加密将加密后的加解密策略发送给DPG12，这样就可以确保传输过程中的安全性，避免加解密策略被破解。
需要说明的是，若发送的加解密策略是新配置的策略，那么ICC11需要将加解密策略整个加密并发送给对应的DPG12。若对加解密策略的更新是更新加解密策略的密钥，那么ICC11将加解密策略中更新的密钥加密并发送给对应的DPG12即可，反之，若是对加解密策略的整体更新，那么ICC11仍然需要加解密策略整体加密并发送给对应的DPG12。此外，ICC11对加解密策略中密钥的更新的条件并不限于DPG12发起可信认证，比如ICC11还可以周期性的更新加解密策略中用于加解密的密钥，且任意两个周期对应的密钥均不同。
另外，在确定DPG12不可信后，ICC11可以将DPG12从网络拓扑中删除，以实现将该DPG12从局域网络中删除。
步骤S500：数据保护网关接收SDN控制器下发的加解密策略。
在ICC11下发加密的加解密策略后，DPG12对应接收到该加密的加解密策略。由于DPG12存储有该DPG12的预共享密钥，那么DPG12便可以利用制密钥解密该加密的加解密策略，从而获得解密的加解密策略。
在加解密策略为新配置的策略或为整体更新的策略时，DPG12可以将该加解密策略整体配置，以实现加解密策略的整体更新。而在加解密策略的更新为密钥的更新时，DPG12则对应将更新的密钥配置，以实现更新加解密策略的密钥。
步骤S600：数据保护网关利用加解密策略对接收到的业务报文进行加解密。
由于DPG12中配置了数据业务对应的加解密策略，那么在接收到客户端发送的该数据业务的业务报文时，DPG12便可以利用加解密策略加解密该业务报文。
具体的，DPG12可以将业务报文中添加至与加解密策略相关的PBEC(Policy BasedEncryption，策略加密)头部，而实现识别加密后的业务报文。示例性的，业务报文的结构可以如图3所示。由于添加PBEC头部并未改变业务报文中原有以太头部、IP(InternetProtocol，全称互联网协议地址)头部和TCP(Transmission Control Protocol，传输控制协议)头部，故又可以实现基于数据业务原有的通信协议对业务报文加解密。换言之，即可以实现在局域网络中无感知部署加解密策略。
示例性的，PBEC头部可以包括PBEC头部本身和PBEC头部本身的控制信息(PBECControl Information)。其中，PBEC头部本身的结构可以如图4所示，而控制信息中各字段的释义则可以如下表1所示。
Figure BDA0002301164170000171
Figure BDA0002301164170000181
表1
可选的，业务报文的结构可以如图3所示，DPG12可以将PBEC头部添加到业务报文的TCP头部与业务内容(TCP/UDP Payload)之间。与此同时，DPG12还可以利用加解密策略对业务报文中的业务内容进行加密压缩，从而获得处理后的业务报文。进而DPG12便可以将处理后的业务报文通过互联网发送到局域网络中对端的DPG12。
本实施例中，由于添加PBEC头部会导致业务报文的长度增加，而对业务内容进行加密压缩又会导致业务报文的长度减少，因此既增加又减少则会导致业务报文的长度发生变化。为实现正确的长度发生变化的业务报文发送，需要即添加PBEC头部又加密业务内容的业务报文进行处理。
具体的，如图5和图6所示，在加密获得处理后的业务报文过程中，DPG12可以先利用加解密策略的密钥，将业务内容加密成密文(TCP/UDP Encypted Payload)，从而获得携带有密文的第一业务报文。以及，DPG12再压缩密文，从而获得携带有压缩的密文(Encrypted&Compressed Payload)的第二业务报文。然后，DPG12将压缩的密文的长度与预设的需要添加的PBEC头部的长度相加而确定出第一长度和，这样，DPG12便可以比较第一长度和与业务内容的长度的大小关系。
若确定第一长度和等于业务内容的长度，说明若在第二业务报文中添加PBEC头部，那么获得处理后的业务报文的长度与初始接收到的业务报文的长度相同。因此，DPG12可以在第二业务报文中添加PBEC头部，从而获得处理后的业务报文，并将其发送给对端的DPG12。
若确定第一长度和小于业务内容的长度，说明若在第二业务报文中添加PBEC头部，那么获得处理后的业务报文的长度小于初始接收到的业务报文的长度相同。为实现正常发送，如图7所示，DPG12可以在第二业务报文中添加PBEC头部的同时，在压缩后的密文中添加自定义内容，使得第一长度增加到与业务内容的长度相同，从而获得长度与初始接收到的业务报文相同的处理后的业务报文，并将其发送给对端的DPG12。
若确定第一长度和大于业务内容的长度，说明即使压缩也不能缩短整体长度，故考虑到资源的节约，在后续发送时无需发送压缩的报文，从而省略掉解压环节，以节约资源。在此基础上，为确保报文的正常发送，DPG12需要判断第一业务报文与PBEC头部的第二长度和是否大于预设的长度阈值。
若确定第二长度和小于等于预设的长度阈值，说明若在第一业务报文中添加PBEC头部，获得处理后的业务报文的长度小于等于数据业务原有的通信协议限定的报文的最大长度，即添加PBEC头部后，处理后的业务报文能够正常发送。因此，DPG12可以在第一业务报文中添加PBEC头部，并对应修改第一业务报文中IP头部和TCP头部中的长度字段，从而获得处理后的业务报文，并将其发送给对端的DPG12。
若确定第二长度和大于预设的长度阈值，说明若在第一业务报文中添加PBEC头部，获得处理后的业务报文的长度大于数据业务原有的通信协议限定的报文的最大长度，即添加PBEC头部后，处理后的业务报文无法正常发送。因此，DPG12可以将报文分割发送。如图8所示，DPG12可以生成与第一业务报文对应的两个处理后的业务报文，一个处理后的业务报文中携带密文的一部分(Pre-cutted Encrypted Payload)，另一个处理后的业务报文中则携带密文的另一部分(Left Encrypted Payload)，且两个报文中任一个处理后的业务报文的长度均小于等于长度阈值。最后，DPG12再将每个处理后的业务报文依次发送到对端的DPG12。
本实施例中，DPG12不仅可以加密并发送报文，DPG12也可以将接收的报文解密。
具体的，在DPG12接收对端的DPG12发送的业务报文(对端的DPG12发送的业务报文也需要加密，换言之，对端的DPG12发送的业务报文可以理解为前述的处理后的业务报文)后，DPG12可以分析接收的处理后的业务报文中的PBEC头部，以确定该处理后的业务报文采用前述的哪一种方式加密。
若确定该处理后的业务报文采用前述中报文分割以外的其它方式加密，那么DPG12可以利用加解密策略对应解密该处理后的业务报文，获得解密的业务报文，并将其发送给客户端。
若确定该处理后的业务报文采用前述中报文分割，那么DPG12可以先从接收到报文中确定出能够与该处理后的业务报文拼接的另一业务报文。然后，DPG12可以将能够拼接的两个处理后的业务报文中加密的密文拼接，再利用加解密策略对应解密该密文拼接的业务报文，获得解密的业务报文，并将其发送给客户端。
本实施例中，由于ICC11对涉及同一数据业务的DPG12的加解密策略的更新并不是完全同步的，故会出现有的DPG12的加解密策略已更新而有的DPG12的加解密策略则未更新的情况。为实现在这种情况下，也能够正常的处理业务报文，一方面，DPG12可以将自身使用的最新加解密策略的版本号携带到处理后的业务报文中，另一方面，在DPG12更新加解密策略后，DPG12可以将上一版本的加解密策略再继续保存一段时间。
这样，DPG12在接收到局域网络中对端的DPG12发送的处理后的业务报文时，DPG12可以先分析处理后的业务报文中携带的版本号。
通过分析版本号，若DPG12确定该处理后的业务报文需要由上一版本的加解密策略处理，DPG12则进一步判断当前是否还存储有上一版本的加解密策略。若存储有，利用上一版本的加解密策略解密该处理后的业务报文，否则，则将该处理后的业务报文丢弃。
通过分析版本号，若DPG12确定该处理后的业务报文需要由ICC11将要下发一版本的加解密策略处理，DPG12可以将该处理后的业务报文缓存一段时间，并在缓存的过程中持续判断是否接收到下一版本的加解密策略。若接收下一版本的加解密策略，则利用下一版本的加解密策略解密该处理后的业务报文，否则，在超出缓存时长后便将该处理后的业务报文丢弃。
此外，通过分析版本号，确定业务报文需要由另一版本的加解密策略处理，且该另一版本的加解密策略与DPG12最新的加解密策略之间相差至少两个版本，说明报文发送出错，DPG12直接将处理后的业务报文丢弃。
请参阅图9，基于同一发明构思，本申请实施例中还提供一种业务加解密的管理装置100，业务加解密的管理装置100应用于SDN控制器，该业务加解密的管理装置100包括：
数据收发模块110，用于接收所述数据保护网关发送的所述数据保护网关的设备认证信息；
数据处理模块120，用于利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
若所述数据处理模块120确定所述数据保护网关可信，所述数据收发模块110，还用于为所述数据保护网关配置加解密业务报文时所使用的加解密策略。
请参阅图10，基于同一发明构思，本申请实施例中还提供一种业务加解密的管理装置200，业务加解密的管理装置200应用于数据保护网关，该业务加解密的管理装置200包括：
数据收发模块210，用于向所述SDN控制器发送自身的设备认证信息，以使所述SDN控制器利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；在所述SDN控制器确定所述数据保护网关可信后，接收所述SDN控制器下发的加解密策略；
数据处理模块220，用于利用所述加解密策略对接收到的业务报文进行加解密。
需要说明的是，由于所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
本申请一些实施例还提供了一种计算机可执行的非易失的程序代码的计算机可读储存介质，该存储介质能够为通用的存储介质，如移动磁盘、硬盘等，该计算机可读存储介质上存储有程序代码，该程序代码被计算机运行时执行上述任一实施方式的业务加解密的管理方法的步骤。
本申请实施例所提供的业务加解密的管理方法的程序代码产品，包括存储了程序代码的计算机可读存储介质，程序代码包括的指令可用于执行前面方法实施例中的方法，具体实现可参见方法实施例，在此不再赘述。
综上所述，本申请提供一种业务加解密的管理方法、装置及系统。在为数据保护网关申请证书前，先利用SDN控制器预先为数据保护网关分配的预共享密钥对该数据保护网关的可信进行认证，可以确保申请证书的数据保护网关都是SDN控制器认为可信的设备，进一步提高安全性。
在本申请所提供的实施例中，应该理解到，所揭露装置和方法，可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，又例如，多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
另外，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。
在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (16)

1.一种业务加解密的管理方法，其特征在于，应用于局域网络中的SDN控制器，所述局域网络中还包括与所述SDN控制器连接的数据保护网关，所述方法包括：
接收所述数据保护网关发送的所述数据保护网关的设备认证信息；
利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
若确定所述数据保护网关可信，为所述数据保护网关配置加解密业务报文时所使用的加解密策略。
2.根据权利要求1所述业务加解密的管理方法，其特征在于，利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信，包括：
判断所述设备认证信息中是否携带有所述SDN控制器预先为所述数据保护网关分配的预共享密钥；
若携带有所述预共享密钥，判断所述预共享密钥是否被篡改；
若未篡改，利用所述设备认证信息中携带的所述数据保护网关申请证书所需的信息，向CA服务器申请所述数据保护网关的设备证书，并判断所述设备证书是否申请成功，其中，所述设备证书申请成功表示所述数据保护网关可信。
3.根据权利要求2所述业务加解密的管理方法，其特征在于，为所述数据保护网关配置加解密业务报文时所使用的加解密策略，包括：
确定出与所述数据保护网关的业务类型对应的所述加解密策略，将所述加解密策略配置到所述数据保护网关。
4.根据权利要求3所述业务加解密的管理方法，其特征在于，将所述加解密策略配置到所述数据保护网关，包括：
利用所述CA服务器为所述设备证书分配的密钥加密所述加解密策略，将加密后的加解密策略发送给所述数据保护网关，以使所述数据保护网关利用所述分配的密钥解密所述加密后的加解密策略，并配置所述加解密策略。
5.根据权利要求1所述业务加解密的管理方法，其特征在于，在为所述数据保护网关配置加解密业务报文时所使用的加解密策略之后，所述方法还包括：
周期性的更新所述加解密策略中用于加解密的密钥，其中，任意两个周期对应的所述密钥均不同。
6.根据权利要求1所述业务加解密的管理方法，其特征在于，在判断所述数据保护网关否可信之后，所述方法还包括：
若确定不可信，将所述数据保护网关从所述局域网络中删除。
7.一种业务加解密的管理方法，其特征在于，应用于局域网络中的数据保护网关，所述局域网络中还包括与所述数据保护网关连接的SDN控制器，所述方法包括：
向所述SDN控制器发送自身的设备认证信息，以使所述SDN控制器利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
在所述SDN控制器确定所述数据保护网关可信后，接收所述SDN控制器下发的加解密策略；
利用所述加解密策略对接收到的业务报文进行加解密。
8.根据权利要求7所述业务加解密的管理方法，其特征在于，利用所述加解密策略对接收到的业务报文进行加解密，包括：
接收客户端发送的所述业务报文；
利用所述加解密策略，对所述业务报文携带的业务内容进行加密，以及在所述业务报文中添加策略加密头部，获得处理后的业务报文；
将所述处理后的业务报文发送到所述局域网络中对端的数据保护网关。
9.根据权利要求8所述业务加解密的管理方法，其特征在于，利用所述加解密策略，对所述业务报文携带的业务内容进行加密，以及在所述业务报文中添加策略加密头部，获得处理后的业务报文，包括：
利用所述加解密策略，将所述业务内容加密成密文，获得携带有所述密文的第一业务报文，以及压缩所述密文，获得携带有所述压缩的密文的第二业务报文；
若确定所述压缩的密文与需要添加的所述策略加密头部的第一长度和小于所述业务内容的长度，在所述第二业务报文中添加所述策略加密头部，通过添加所述压缩后的密文的内容而将所述第一长度增加到与所述业务内容的长度相同，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第一业务报文与所述策略加密头部的第二长度和小于等于预设的长度阈值，根据所述第二长度和对应修改所述第一业务报文的IP头部和TCP头部中的长度字段，获得所述处理后的业务报文；
若确定所述第一长度和大于所述业务内容的长度，且确定所述第二长度和大于所述长度阈值，生成与所述第一业务报文对应的两个所述处理后的业务报文，其中，一个所述处理后的业务报文中携带所述密文的一部分，另一个所述处理后的业务报文中则携带所述密文的另一部分，且任一个所述处理后的业务报文的长度均小于等于所述长度阈值。
10.根据权利要求7所述业务加解密的管理方法，其特征在于，利用所述加解密策略对接收到的业务报文进行加解密，包括：
接收对端的数据保护网关发送的所述业务报文；
利用所述加解密策略解密所述业务报文，获得解密的业务报文；
将所述解密的业务报文发送至客户端。
11.根据权利要求7所述业务加解密的管理方法，其特征在于，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由所述上一版本的加解密策略处理，判断是否还存储有所述上一版本的加解密策略；
若是，利用所述上一版本的加解密策略，解密所述业务报文。
12.根据权利要求7所述业务加解密的管理方法，其特征在于，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由所述SDN控制器将要下发的下一版本的加解密策略处理，将所述业务报文缓存；
在接收到所述下一版本的加解密策略时，利用所述下一版本的加解密策略，加解密所述业务报文。
13.根据权利要求7所述业务加解密的管理方法，其特征在于，在接收所述SDN控制器下发的加解密策略之后，所述方法还包括：
接收所述局域网络中对端的数据保护网关发送的业务报文；
确定所述业务报文需要由另一版本的加解密策略处理，且所述另一版本的加解密策略与所述SDN控制器下发的加解密策略之间相差至少两个版本，将所述业务报文丢弃。
14.一种业务加解密的管理装置，其特征在于，应用于局域网络中的SDN控制器，所述局域网络中还包括与所述SDN控制器连接的数据保护网关，所述装置包括：
数据收发模块，用于接收所述数据保护网关发送的所述数据保护网关的设备认证信息；
数据处理模块，用于利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；
若所述数据处理模块确定所述数据保护网关可信，所述数据收发模块，还用于为所述数据保护网关配置加解密业务报文时所使用的加解密策略。
15.一种业务加解密的管理装置，其特征在于，应用于局域网络中的数据保护网关，所述局域网络中还包括与所述数据保护网关连接的SDN控制器，所述装置包括：
数据收发模块，用于向所述SDN控制器发送自身的设备认证信息，以使所述SDN控制器利用所述设备认证信息对所述数据保护网关进行认证，以判断所述数据保护网关是否可信；在所述SDN控制器确定所述数据保护网关可信后，接收所述SDN控制器下发的加解密策略；
数据处理模块，用于利用所述加解密策略对接收到的业务报文进行加解密。
16.一种业务加解密系统，其特征在于，包括：部署在局域网络中的SDN控制器和数据保护网关，所述数据保护网关与所述SDN控制器连接，
所述SDN控制器，用于执行如权利要求1-6任一权项所述的业务加解密的管理方法；
所述数据保护网关，用于执行如权利要求7-13任一权项所述的业务加解密的管理方法。
CN201911222218.0A 2019-12-03 2019-12-03 一种业务加解密的管理方法、装置及系统 Active CN110943996B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911222218.0A CN110943996B (zh) 2019-12-03 2019-12-03 一种业务加解密的管理方法、装置及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911222218.0A CN110943996B (zh) 2019-12-03 2019-12-03 一种业务加解密的管理方法、装置及系统

Publications (2)

Publication Number Publication Date
CN110943996A true CN110943996A (zh) 2020-03-31
CN110943996B CN110943996B (zh) 2022-03-22

Family

ID=69908919

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911222218.0A Active CN110943996B (zh) 2019-12-03 2019-12-03 一种业务加解密的管理方法、装置及系统

Country Status (1)

Country Link
CN (1) CN110943996B (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111770071A (zh) * 2020-06-23 2020-10-13 江苏易安联网络技术有限公司 一种网络隐身场景下网关认证可信设备的方法和装置
CN117061115A (zh) * 2023-10-11 2023-11-14 腾讯科技（深圳）有限公司 密钥协商方法、装置、计算机设备和计算机可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1929373A (zh) * 2006-10-19 2007-03-14 中控科技集团有限公司 工业安全控制系统及其控制方法
CN103051557A (zh) * 2012-12-27 2013-04-17 华为技术有限公司 数据流处理方法及系统、控制器、交换设备
CN104935593A (zh) * 2015-06-16 2015-09-23 杭州华三通信技术有限公司 数据报文的传输方法及装置
CN105284091A (zh) * 2014-05-08 2016-01-27 华为技术有限公司 一种证书获取方法和设备
CN105721317A (zh) * 2016-02-25 2016-06-29 上海斐讯数据通信技术有限公司 一种基于sdn的数据流加密方法和系统
CN105933125A (zh) * 2016-07-07 2016-09-07 北京邮电大学 一种软件定义网络中的南向安全认证方法及装置
US20170331794A1 (en) * 2016-05-11 2017-11-16 Argela Yazilim Ve Bilisim Teknolojileri San. Ve Ti C. A.S. System and method for programmable network based encryption in software defined networks
US20180262473A1 (en) * 2015-09-22 2018-09-13 Hewlett Packard Enterprise Development Lp Encrypted data packet

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1929373A (zh) * 2006-10-19 2007-03-14 中控科技集团有限公司 工业安全控制系统及其控制方法
CN103051557A (zh) * 2012-12-27 2013-04-17 华为技术有限公司 数据流处理方法及系统、控制器、交换设备
CN105284091A (zh) * 2014-05-08 2016-01-27 华为技术有限公司 一种证书获取方法和设备
CN104935593A (zh) * 2015-06-16 2015-09-23 杭州华三通信技术有限公司 数据报文的传输方法及装置
US20180262473A1 (en) * 2015-09-22 2018-09-13 Hewlett Packard Enterprise Development Lp Encrypted data packet
CN105721317A (zh) * 2016-02-25 2016-06-29 上海斐讯数据通信技术有限公司 一种基于sdn的数据流加密方法和系统
US20170331794A1 (en) * 2016-05-11 2017-11-16 Argela Yazilim Ve Bilisim Teknolojileri San. Ve Ti C. A.S. System and method for programmable network based encryption in software defined networks
CN105933125A (zh) * 2016-07-07 2016-09-07 北京邮电大学 一种软件定义网络中的南向安全认证方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
范晓红等: "SDN南向通道的安全性研究", 《北京电子科技学院学报》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111770071A (zh) * 2020-06-23 2020-10-13 江苏易安联网络技术有限公司 一种网络隐身场景下网关认证可信设备的方法和装置
CN117061115A (zh) * 2023-10-11 2023-11-14 腾讯科技（深圳）有限公司 密钥协商方法、装置、计算机设备和计算机可读存储介质
CN117061115B (zh) * 2023-10-11 2024-02-02 腾讯科技（深圳）有限公司 密钥协商方法、装置、计算机设备和计算机可读存储介质

Also Published As

Publication number Publication date
CN110943996B (zh) 2022-03-22

Similar Documents

Publication Publication Date Title
US9461975B2 (en) Method and system for traffic engineering in secured networks
US7131003B2 (en) Secure instant messaging system
US7039713B1 (en) System and method of user authentication for network communication through a policy agent
US20080083011A1 (en) Protocol/API between a key server (KAP) and an enforcement point (PEP)
US20170111179A1 (en) Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange
US8886934B2 (en) Authorizing physical access-links for secure network connections
US7991993B2 (en) Telecommunication system, for example an IP telecommunication system, and equipment units for use in the system
US10587579B2 (en) Varying encryption level of traffic through network tunnels
US9516061B2 (en) Smart virtual private network
US8104082B2 (en) Virtual security interface
US10785196B2 (en) Encryption key management of client devices and endpoints within a protected network
JP4107213B2 (ja) パケット判定装置
CN111787025B (zh) 加解密处理方法、装置、系统以及数据保护网关
US20050160269A1 (en) Common security key generation apparatus
CN113726795B (zh) 报文转发方法、装置、电子设备及可读存储介质
CN110943996B (zh) 一种业务加解密的管理方法、装置及系统
CN111010399A (zh) 一种数据传输方法、装置、电子设备及存储介质
CN114844729A (zh) 一种网络信息隐藏方法及系统
WO2008042318A2 (en) Systems and methods for management of secured networks with distributed keys
CN112637069B (zh) 数据报文的传输方法和装置
EP4156622A1 (en) Method for checking application information, message processing method and device
CN107135226B (zh) 基于socks5的传输层代理通信方法
CN108809888B (zh) 一种基于安全模块的安全网络构建方法和系统
CN110855628A (zh) 一种数据传输方法及系统
US20210014054A1 (en) Cryptography system and method

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant